Research in requirements engineering has produced an extensive body of knowledge, but there are four areas in which the foundation of the discipline seems weak or obscure. This article shines some light in the “four dark corners, ” exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary for sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements engineering to be successfully completed.
|
1713
|
Statecharts: A Visual Formalism for Complex Systems
– Harel
- 1987
|
|
477
|
Conjoining specifications
– Abadi, Lamport
- 1995
|
|
319
|
A field study of the software design process for large systems
– Curtis, Krasner, et al.
- 1988
|
|
292
|
S.: Goal-directed requirements acquisition
– Dardenne, Lamsweerde, et al.
- 1993
|
|
207
|
A Specifier’s Introduction to Formal Methods
– Wing
- 1990
|
|
193
|
Object Identity
– Khosafian, Copeland
- 1986
|
|
181
|
Requirements Specification for ProcessControl Systems
– Leveson, Heimdahl, et al.
- 1994
|
|
168
|
A Rational Design Process: How and Why to Fake It
– Parnas, Clements
- 1986
|
|
161
|
Specifying Software Requirements for Complex Systems: New Techniques and Their Applications
– Heninger
- 1980
|
|
141
|
Software Requirements & Specifications: A lexicon of Practice, Principles and Prejudices
– Jackson
- 1995
|
|
129
|
A Simple Approach to Specifying Concurrent Systems
– Lamport
- 1989
|
|
126
|
System Development
– Jackson
- 1983
|
|
125
|
Recognizing safety and liveness
– Alpern, Schneider
- 1987
|
|
119
|
Krypton: A Functional Approach to Knowledge Representation
– Brachman, Fikes, et al.
- 1983
|
|
117
|
Conjunction as composition
– Zave, Jackson
- 1993
|
|
101
|
Program life cycles and laws of software evolution
– Lehman
|
|
97
|
Consistency Checking of SCR-Style Requirements Specifications
– Heitmeyer, Labaw, et al.
- 1995
|
|
91
|
A Logical Approach to Discrete Math
– Gries, Schneider
- 1993
|
|
82
|
M.: “The Z Notation: A Reference
– Spivey
- 1992
|
|
78
|
On the Inevitable Intertwining of Specification and Implementation
– Swartout, Balzer
- 1982
|
|
73
|
SCR*: A toolset for specifying and analyzing requirements
– Heitmeyer, Bull, et al.
- 1995
|
|
69
|
Functional documentation for computer systems engineering
– Parnas, Madey
- 1991
|
|
62
|
Language support for the specification and development of composite systems
– Feather
- 1987
|
|
53
|
Structuring Z specifications with views
– Jackson
- 1995
|
|
46
|
Specification Techniques for Data Abstractions
– Liskov, Zilles
- 1975
|
|
45
|
An Operational Approach to Requirements Specification for Embedded Systems
– Zave
- 1982
|
|
39
|
Theories Underlying Requirements Engineering: an overview of NATURE at Genesis
– Jarke, Bubenko, et al.
- 1993
|
|
37
|
Software Development with Z: A Practical Approach to Formal Methods
– Wordsworth
- 1992
|
|
36
|
Deriving specifications from requirements: An example
– Jackson, Zave
- 1995
|
|
36
|
Documentation of requirements for computer systems
– Schouwen, Parnas, et al.
- 1993
|
|
32
|
O-O Requirements Analysis: An Agent Perspective
– Dubois, Bois, et al.
- 1993
|
|
24
|
Specifying a Real-Time Kernel
– Spivey
- 1990
|
|
19
|
Principles of Good Software Specification and Their Implications For Specification Languages
– BALZER, GOLDMAN
- 1979
|
|
18
|
From Organization Models to System Requirements - A `Cooperating Agents
– Yu, Bois, et al.
|
|
13
|
Strens, ‘The ordit approach to organisational requirements
– Dobson, Blyth, et al.
- 1994
|
|
10
|
Towards a Derivational Style of Distributed System Design
– Feather
- 1994
|
|
10
|
Deriving specifications from requirements
– Johnson
- 1988
|
|
9
|
On concepts and strategies for requirements and information analysis
– Bubenko
- 1983
|
|
9
|
A modal (action) logic for requirements specification
– Jeremaes, Khosla, et al.
- 1986
|
|
7
|
Analyzing Timing Requirements
– Atlee, Gannon
- 1993
|
|
7
|
Domain modeling for software engineering
– ISCOE, WILLIAMS, et al.
- 1991
|
|
5
|
Information Systems: Modelling, Sequencing, and Transformations
– Jackson
- 1978
|
|
5
|
A problem-solver for making advice operational
– Mostow
- 1983
|
|
5
|
Time considered irrelevant for real-time systems
– TURSKI
- 1988
|
|
4
|
Composite system design: the good news and the bad news
– Feather, Fickas, et al.
- 1991
|
|
2
|
Dardenne et al. 93] Anne Dardenne, Axel van Lamsweerde, and Stephen Fickas. Goal-directed requirements acquisition. Science of Computer Programming XX:3-50
– Dobson, Blyth, et al.
- 1988
|
|
2
|
Dubois et al. 93] Eric
– Bois, Petit
- 1994
|
|
2
|
and Pamela Zave. Deriving specifications from requirements: An example
– Maibaum
- 1995
|
|
2
|
Turski 88
– Turski
- 1982
|
|
2
|
Wing 90
– Wing
- 1992
|
