Topic: good requirement specifications
Topic: information hiding
Topic: requirement specification by function
Topic: separate a module's interface specification from its implementation
Topic: specification errors
| |
Subtopic: no unnecessary details
Quote: a requirements document should contain everything needed to write acceptable software and no more [»parnDL2_1986]
| Quote: an interface should capture the minimum essentials of an abstraction, without generalization [»lampBW10_1983]
| Quote: a specification should not contain unnecessary details; otherwise all future implementations must provide it [»shawM3_1980]
| Quote: designers must specify modules with exactly the information that they want the programmers to have [»parnDL8_1971]
| Quote: specifications provide exactly the information needed to use and develop a program [»parnDL5_1972, OK]
| Quote: the original definition of FORTRAN arrays specified a memory layout; caused trauma when later changed the layout
| Quote: a data item in a hardware interface description has essential characteristics and arbitrary details; the later may differ over devices [»heniKL1_1980]
| Quote: code is not a specification because it does not separate what is required from ways of achieving it
| Subtopic: no representation or implementation
Quote: good requirements are simple, abstract needs [»huntA_2000]
| Quote: code is not a specification because it does not separate what is required from ways of achieving it
| Quote: a requirements specification must treat the system as a block box [»hsiaP11_1993]
| Quote: a requirements specification includes functional requirements that show external behavior in terms of input and output
| Quote: often a model is used as a specification or description; e.g., a finite state machine for a communication protocol; this does not state the requirements [»parnDL_1997]
| Quote: UML and other object-oriented design languages align well with code and poorly with requirements [»clarS11_1999]
| Quote: Y2K happened because data processing implemented existing practices w/o date abstractions [»huntA_2000]
| Quote: a specification allows different implementations of a program module [»liskB_1996]
| Quote: a specification allows one to use a program module before it is defined
| Quote: a list of attributes may be a description or a specification; a specification may provide a choice; e.g., "the volume is a cubic meter" [»parnDL_1997]
| Subtopic: use names to hide details
Quote: names in a Larch interface specification tie together traits in the Shared language and programs in the programming language [»guttJV9_1985]
| Quote: essential information in a specification must not rely on arbitrary details; e.g., use mnemonic names instead of numbers or sequences [»heniKL1_1980]
| Subtopic: use error bounds
Quote: in a specification, specify numbers with error bounds; otherwise the designers may assume that the numbers are precise and inflexible [»neugW_1982]
| Subtopic: specification flaws
Quote: a specification should only contain relevant information; no noise, remorse or redundancy [»meyeB1_1985]
| Quote: remorse in a specification is adding to the description of a feature outside of its definition [»meyeB1_1985]
|
Related Topics
Topic: good requirement specifications (36 items)
Topic: information hiding (50 items)
Topic: requirement specification by function (20 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: specification errors (10 items)
|