Topic: good requirement specifications

topics > computer science > programming > Group: requirement specification

program design

importance of information hiding for requirement specification
separate a module's interface specification from its implementation
specification errors

Subtopic: goals up

Quote: the ordering of goals for the Internet is important: survivability, multiple types of services, ..., accountability [»clarDD8_1988]

Subtopic: understandable and precise up

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 up

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 up

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 up

Quote: need specification standards with pragmatics, formating, naming conventions, language restrictions [»tretJ9_2001]

Subtopic: information hiding up

Topic: importance of information hiding for requirement specification

Subtopic: change up

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 up

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 up

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 up

Quote: when writing requirements want to state questions before trying to answer them; otherwise prejudiced towards easily answered questions [»heniKL1_1980]

Subtopic: testable up

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 up

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 up

Quote: formalization of XML Schema used for XQuery and XPath specifications; one of the first

Subtopic: specification errors up

Quote: latent specifications in text by naming conventions, assertions, etc.; e.g., lock.. and unlock.., free.. and release..

Related Topics up

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)

Updated barberCB 1/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.