The initial expression of requirements for a computer-based system is often informal and possibly vague. Requirements engineers need to examine this often incomplete and inconsistent brief expression of needs. Based on the available knowledge and expertise, assumptions are made and conclusions are deduced to transform this "rough sketch " into more complete, consistent, and hence correct requirements. This paper addresses the question of how to characterize these properties in an evolutionary framework, and what relationships link these properties to a customer's view of correctness. Moreover, we describe in rigorous terms the di#erent kinds of validation checks that must be performed on di#erent parts of a requirements specification in order to ensure that errors (i.e., cases of inconsistency and incompleteness) are detected and marked as such, leading to better quality requirements.
|
332
|
Logic for problem solving
– Kowalski
- 1974
|
|
232
|
A framework for expressing the relationships between multiple views in requirements specification
– Nuseibeh, Kramer, et al.
- 1994
|
|
153
|
Automated consistency checking of requirements specifications
– Heitmeyer, Jeffords, et al.
- 1996
|
|
141
|
Software Requirements & Specifications: A lexicon of Practice, Principles and Prejudices
– Jackson
- 1995
|
|
91
|
Using ViewPoints for Inconsistency Management
– Easterbrook, Nuseibeh
- 1996
|
|
90
|
Tolerating inconsistency
– Balzer
- 1991
|
|
87
|
Managing conflicts in goal-driven requirements engineering
– Lamsweerde, Darimont, et al.
- 1998
|
|
80
|
From Object-Oriented to Goal-Oriented Requirements Analysis
– Mylopoulos, Chung, et al.
- 1999
|
|
78
|
Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems
– Lutz
- 1993
|
|
69
|
The Requirements Apprentice: Automated Assistance for Requirements Acquisition
– Reubenstein, Walters
- 1991
|
|
65
|
Software requirements analysis for real-time process-control systems
– Jaffe, Leveson, et al.
- 1991
|
|
60
|
Knowledge Representation as the Basis for Requirements Specification
– Borgida, Greenspan, et al.
- 1985
|
|
54
|
Verifying and Validating Software Requirements and Design Specifications
– Boehm
- 1984
|
|
39
|
and Bashar Nuseibeh, “Managing inconsistencies in an evolving specification
– Easterbrook
- 1995
|
|
36
|
A framework for formalizing inconsistencies and deviations in human-centered systems
– Cugola, Nitto, et al.
- 1996
|
|
25
|
What does it mean to say that a specification is complete
– Yue
- 1987
|
|
24
|
Viewpoints for Requirements Elicitation: A Practical Approach
– Sommerville
- 1998
|
|
19
|
To be and not to be: on managing inconsistency in software development
– Nuseibeh
- 1996
|
|
16
|
A Survey of Empirical Studies of Conflict
– Easterbrook, Beck, et al.
- 1993
|
|
16
|
A Meta-Model for Restructuring Stakeholder Requirements
– Robinson, Volkov
- 1997
|
|
12
|
AGORA: Attributed goal-oriented requirements analysis method
– Kaiya, Horai, et al.
- 2002
|
|
11
|
Completeness in Formal Specification Language Design for Process-Control Systems
– Leveson
- 2000
|
|
9
|
Performance-related completions for software specifications
– Woodside, Petriu, et al.
- 2002
|
|
6
|
Elaborating, structuring and expressing formal requirements of composite systems
– Dubois, Bois, et al.
- 1992
|
|
5
|
Evaluation method for user requirements documents
– Cordes, Carver
- 1989
|
|
4
|
Consistency in software system development: Framework, model, techniques, and tools
– Hagensen, Kristensen
- 1992
|
|
3
|
Software Requirements: Analysis and Specification, 2nd Edition
– Davis
- 1993
|
|
3
|
Lamsweerde, Requirements analysis: Deriving operational software specifications from system goals
– Letier, van
- 2002
|
|
2
|
Simultaneous checking of completeness and ground confluence, in
– Bouhoula
- 2000
|
|
2
|
A case study: validation of guidance control software requirements for completeness, consistency and fault tolerance
– Sheldon, Kim, et al.
|
|
2
|
Correctness is congruent with quality
– Lott
|
|
