Group:
program design
Topic:
importance of information hiding for requirement specification
Topic:
separate a module's interface specification from its implementation
Topic:
specification errors
| |
Subtopic: goals 
| Quote: the ordering of goals for the Internet is important: survivability, multiple types of services, ..., accountability [»clarDD8_1988]
|
Subtopic: understandable and precise
| Quote: a good specification is at a high enough level to be understandable and precise enough to be complete; difficult to achieve [»swarW7_1982]
| | Quote: a specification should not be ambiguous [»meyeB1_1985]
| | Quote: a specification should not contain contradictions [»meyeB1_1985]
| | Quote: formal specifications are concise, explicit, unambiguous, abstract, and lead to an implementation; generally beneficial [»boweJP4_1995]
| | Quote: a Japanese computer, the TAC, used the same order codes and subroutine library as the EDSAC; only source was this book [»wilkMV_1951]
| | Quote: write interface assumptions in prose; errors seldom occurred in both assumptions and programming constructs [»britKH3_1981]
| | Quote: formal requirements are often meaningless to end users; everything is based on the designer's explanations, just as before; specialized, isolated participants [»huntA_2000]
| | Quote: organize a requirements document as a reference document instead of an introductory narrative; worth the expense; easy lookup [»parnDL2_1986]
|
Subtopic: completeness
| Quote: the specification of a system unit must be complete, correct, accessible and compatible [»belaLA_1979]
| | Quote: a design should be well structured, simple, efficient, adequate, flexible, practical, implementable, and standardized [»parnDL8_1985]
| | Quote: a requirements specification is consistent, correct, understandable, complete, and a foundation for design and test [»hsiaP11_1993]
| | Quote: a specification should discuss every feature of the problem [»meyeB1_1985]
| | Quote: a requirements document includes the host specification, interface specifications, a specification for each output value, timing and accuracy constraints, likely changes, and undesired event handling [»parnDL2_1986]
| | Quote: describe a routine accurately; include preconditions, postconditions, validity conditions, accuracy, time taken, and method [»turiA3_1951]
|
Subtopic: nonfunctional requirements
| Quote: a requirements specification includes nonfunctional requirements such as performance, portability, and reliability
| | Quote: designers should design the data processing modes, data base, execution time allocations, interfaces, processing modes, input/output processing, and operating procedures [»roycWW8_1970]
|
Subtopic: specification standard
| Quote: need specification standards with pragmatics, formating, naming conventions, language restrictions [»tretJ9_2001]
|
Subtopic: information hiding
| Topic: importance of information hiding for requirement specification
|
Subtopic: change
| Quote: during the specification stage, must recognize that specifications will change in the implementation stage [»hallA9_1990]
| | Quote: a small change to requirements (features) may lead to widespread change of design (interfaces, classes, methods)
| | Quote: evolve feature set during product development; may change 30% or more over life of project [»cusuMA10_1999]
|
Subtopic: simplicity
| Quote: dig for requirements; they are buried under assumptions, misconceptions, and politics [»huntA_2000]
| | Quote: everything should be as simple as possible but no simpler [»lampBW10_1983]
| | Quote: perfection is reached when there is nothing to take away [»lampBW10_1983]
|
Subtopic: style
| Quote: requirements: standard format, checklist, models, avoid paragraphs, user's vocabulary from a data and function dictionary [»postRM5_1987]
| | Quote: a specification should not contain forward references to undefined features [»meyeB1_1985]
|
Subtopic: question before answer
| Quote: when writing requirements want to state questions before trying to answer them; otherwise prejudiced towards easily answered questions [»heniKL1_1980]
|
Subtopic: testable
| Quote: a specification should only contain realistic features that can be validated [»meyeB1_1985]
| | Quote: good requirements are testable, unambiguous, unique, and use visible inputs and outputs [»postRM5_1987]
|
Subtopic: error specification
| Quote: unexpected events represent about half of the effort in writing specifications; what happens when something goes wrong? [»parnDL10_1976b]
| | Quote: in a specification, can define what is unacceptable; e.g., no single failure losing all from more than one instrument [»neugW_1982]
| | Quote: a specification should specify run-time checks and how to respond to detected errors [»parnDL_1977]
| | Quote: restrictions on the sequence of invoking operators of an abstract data type; e.g., open, write, close [»silbA2_1980]
|
Subtopic: examples
| Quote: formalization of XML Schema used for XQuery and XPath specifications; one of the first
|
Subtopic: specification errors
Quote: latent specifications in text by naming conventions, assertions, etc.; e.g., lock.. and unlock.., free.. and release..
[»englD10_2001]
|
Related Topics
Group: program design (13 topics, 454 quotes)
Topic: importance of information hiding for requirement specification (23 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: specification errors
(10 items)
|
