Group: requirement specification

topics > computer science > Group: programming

good requirement specifications
importance of information hiding for requirement specification
path expression
programming language standards
requirement specification by assertion
requirement specification by behaviors
requirement specification by diagrams
requirement specification by function
specification errors
specification is infeasible
program module
program design
program proving
software engineering

abstract data type
abstraction in programming
automated tests of specifications and designs
Cleanroom software development
communication protocols
design documentation
design languages
executable code from specifications and designs
execution with program stubs
formal methods and languages
interface between program modules
program proving is infeasible
programming environment
proving concurrent programs
reusable programming
reverse engineering of software
software lifecycle
software models of reality
software review
specification and design of distributed systems
user-centered design


Requirements specifications solidify software performance goals before programs are designed, provide standards for measuring the software product, and give design documentation for program maintenance. They should be abstract, implementation independent, defined in terms of external results, specified with environmental requirements, general enough for alternative implementations, formal enough for consistency proofs, and understandable by software customers, system designers and programmers. Understandable requirements usually indicate informal specifications while provable requirements require more formal methods. Standardized methods may allow informal specifications to customers and formal specifications of system modules. Specifications encourage structured programming with top down design. Formal specifications may be unjustified because of their high cost and low flexibility. (cbb 5/80)

Requirement specifications are common in other fields. They work best for conventional or large-scale projects. They define an abstraction which the product implements. (cbb 11/92)

Subtopic: requirements are important up

Quote: rational design requires a requirements document [»parnDL2_1986]
Quote: once a specification problem is understood, progress is rapid and the specification becomes smaller
Quote: requirements necessary for good design and tests [»postRM5_1987]
Quote: specification best for conventional projects or large-scale projects [»boehBW5_1984]
Quote: formal specification took about 30% of total effort [»hallA9_1990]
Quote: software elements should be implementations of well-understood specifications, not as arbitrary executable texts [»meyeB10_1992]
Quote: environment specifications specify intended use of an abstract type; similar to usage restrictions specified by a manufacturer [»silbA2_1980]
Quote: we need an external model to portray the properties of a complex system; the model itself is a system [»handP_1981]

Subtopic: what to build up

Quote: subjective quality is deciding what to build; must have a baseline, want more of linear elements, and excited by features [»cockA3_2008]

Subtopic: requirements are difficult up

Quote: it is hard to decide what a program does and specify it precisely and clearly [»hoarCA_1974]
Quote: requirements and proofs are inherently global; a changed requirement may require redoing most of the proofs; verification gets dropped [»berrDM10_2002]
Quote: discourage change if want comprehensive requirements before coding starts [»berrDM10_2002]
Quote: writing a good formal specification is difficult and time consuming; the hardest parts are understanding the object to be specified and developing the mathematical abstractions [»birrAD_1991a]
Quote: unlike physical systems, software is not continuous; small changes can cause large failures; small requirement changes can cause large design changes [»wegnP_1979a]
Quote: evolve feature set during product development; may change 30% or more over life of project [»cusuMA10_1999]

Subtopic: collecting specifications up

Quote: dig for requirements; they are buried under assumptions, misconceptions, and politics [»huntA_2000]
Quote: an analyst shouldn't ask very precise questions with yes/no answers since the 'noise' contains much useful information [»weinGM_1982]
Quote: need better ways to elicit and define requirements incrementally; not a language or structured analysis [»pottC9_1993]
Quote: need methods to keep track of the myriad, informal notes about requirements; these form a shared memory for analysts and customers [»pottC9_1993]
Quote: need tools for formal specifications; maintain consistency, browse, derive interactions and consequences, teach methodology [»guttJV9_1985]

Subtopic: requirements as assumptions up

Quote: commonality analysis produces a dictionary of terms, commonalities (global assumptions), variabilities (varying assumptions), parameters for each variability, and issues [»guptNK1_1997]

Subtopic: requirements document up

Quote: in manufacturing a succession of blueprints, drawings and specifications capture the relevant requirements [»rossDT1_1977a]
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: Larch divides a specification into mathematical abstractions and program interfaces [»birrAD_1991a]
Quote: Larch shared and interface languages for incremental construction of readable specifications from other specifications; includes theorem prover for semantic checking [»guttJV9_1985]

Subtopic: legal specification up

Quote: a legal contract specifies how much the contractor will do and how little is acceptable to the client; protects both sides [»meyeB10_1992]
Quote: specificational information is like a law; determinate, non-negotiable, harmonious, automatic; suitable foundation for coordination [»turvMT_1984]
Quote: most requirements techniques incorrectly view software development as a contract; software is now a commodity [»pottC9_1993]

Subtopic: formal specification up

Quote: formal specifications are concise, explicit, unambiguous, abstract, and lead to an implementation; generally beneficial [»boweJP4_1995]
Quote: a specification is a formal description of the interface between a system and its environment
Quote: specifications specify the system and its attributes; e.g., functions, data elements, interfaces, security, performance, packaging [»joneTC4_1979a]
Quote: a specification is realizable iff the system has a winning strategy; i.e., the system wins under all legal environment behaviors [»abadM1_1993]
Quote: use a formal specification for synchronization primitives on a multiprocessor; otherwise difficult questions about their precise semantics [»birrAD_1991a]
Quote: use formal semantic specifications for schema abstractions of algorithms and abstract data types; e.g., data flow, logic, axiomatic theories [»krueCW6_1992]
Quote: software specification requires a more rigorous formalism than natural language [»meyeB1_1985]
Quote: formal specification finds and nearly eliminates certain errors, forces you to think hard about the system, and are practical [»hallA9_1990]

Subtopic: examples up

Quote: defensive programming not necessary with Eiffel since all preconditions are guaranteed by the client [»meyeB10_1992]
Quote: specify system by step-wise refinement of predicate transition nets and regular expressions; tested with model of an automated warehouse [»bellF6_1991]
Quote: consistent and complete algebraic specification of abstract data types; e.g., a symbol table [»guttJV6_1977]
Quote: Trio-based development of a pondage power plant control system 15% less expensive than traditional approach; higher requirements costs [»ciapE1_1999]
Quote: programmers and implementers use the formal specification of Modula-3 threads [»birrAD_1991a]
Quote: an untrained user found an error in the formal specification of Modula-3 threads; another error was missed for a year
Quote: used TRIO formalisms for industrial projects; required formalism experts that often include the formalism developers [»ciapE1_1999]
Quote: used HDM to check system specifications, multilevel security, and implementation correctness [»silvBA_1981]
Quote: in DELTA, an object's sequential actions are specified by a prime task which is a separate entity [»handP_1981]

Subtopic: abstract specification up

Quote: with abstract specifications, can easily invent alternative solutions and check them with the same verification conditions [»brinP9_1978]
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

Subtopic: software specification up

Quote: a software unit's specification is the definition against which the unit is developed, tested, marketed, taught, used, and maintained [»belaLA_1979]
Quote: commands indicate action to be performed; indicational information does not provide details; details by specificational information [»turvMT_1984]
Quote: software specification is overlooked or confused with definition of objectives or design [»meyeB1_1985]

Subtopic: program families up

Quote: FAST organizes software production around families of systems; identify family requirements and abstractions, create a language for specifying individual requirements, and generate software for family members [»guptNK1_1997]

Subtopic: requirements by decision trees up

Quote: decision trees define audit requirements; each node retrieves a data entity for comparison with other data; leaves represent reports or corrective actions [»guptNK1_1997]

Subtopic: hierarchical specification up

Quote: every specification is an implementation of a higher level specification
Quote: level principle--active entities at one level are data structures at a lower level; e.g., process vs. context block [»finkRA_1986]
Quote: an electronic test system may have many levels of specification, e.g., run smoothly, rpms, voltage [»cheaTE_1976]

Subtopic: control theory up

Quote: describe real-time and interactive systems by control theory [»parnDL_1997]

Subtopic: use-case specification up

Quote: subject-oriented programming--decompose design into design subjects, one per requirement; model each subject with an object-oriented design language; may overlap [»clarS11_1999]
Quote: inspection by usage-based reasoning validates design and requirement documents by manually executing high priority use cases [»thelT8_2003]

Subtopic: problems with specification up

Quote: the hardest part of building software is deciding what to build; the client does not know what he wants [»brooFP_1986]
Quote: requirement specification requires a working system or prototype
Quote: full formal development with machine-checked proofs is too expensive except for failure-critical applications
Quote: the program designer must impose performance constraints on the analyst; requires a preliminary design before analysis begins [»roycWW8_1970]
Quote: algrebraic specification should scale; at any level, its size and complexity is independent of the size and complexity of the system being described [»guttJV6_1977]
Quote: algebraic specification requires formal training in computer science; may limit its use

Group: requirement specification up

Topic: good requirement specifications (36 items)
Topic: importance of information hiding for requirement specification (23 items)
Topic: path expression (14 items)
Topic: programming language standards (10 items)
Topic: requirement specification by assertion (28 items)
Topic: requirement specification by behaviors (16 items)
Topic: requirement specification by diagrams (27 items)
Topic: requirement specification by function (20 items)
Topic: specification errors (10 items)
Topic: specification is infeasible (46 items)
Topic: standards
(12 items)

Related Topics up

Group: formalism   (9 topics, 478 quotes)
Group: program module   (10 topics, 336 quotes)
Group: program design   (13 topics, 454 quotes)
Group: program proving   (10 topics, 311 quotes)
Group: software engineering   (18 topics, 470 quotes)
Group: testing   (18 topics, 557 quotes)

Topic: abstract data type (64 items)
Topic: abstraction in programming (67 items)
Topic: automated tests of specifications and designs (12 items)
Topic: Cleanroom software development (38 items)
Topic: communication protocols (62 items)
Topic: design documentation (43 items)
Topic: design languages (12 items)
Topic: executable code from specifications and designs (18 items)
Topic: execution with program stubs (5 items)
Topic: formal methods and languages (53 items)
Topic: interface between program modules (55 items)
Topic: program proving is infeasible (47 items)
Topic: programming environment (46 items)
Topic: prototyping (18 items)
Topic: proving concurrent programs (37 items)
Topic: reusable programming (77 items)
Topic: reverse engineering of software (6 items)
Topic: software lifecycle (13 items)
Topic: software models of reality (24 items)
Topic: software review (80 items)
Topic: specification and design of distributed systems (14 items)
Topic: user-centered design
(65 items)

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