1. Four Dark Corners of Requirements Engineering
Pamela Zave
Michael Jackson

2. REFERENCE
P. Zave and M. Jackson, Four Dark Corners of Requirements Engineering, ACM Transactions Software. Eng. and Methodology,6(1)
Intelligent Systems Lab

3. What is a machine in this paper
Throughout this paper
we use "system" only to refer to a general artifact that might have both manual and automatic components, such as an "airline reservation system."
Whenever we are referring to the computer based artifact that is the target of software development, we use the more precise term "machine."
Intelligent Systems Lab

4. 4 Dark Corners
All the terminology used in requirements engineering should be grounded in the reality of the environment for which a machine1 is to be built.
It is not necessary or desirable to describe the machine to be built. Rather, the environment is described in two ways:
as it would be without or in spite of the machine
as we hope it will become because of the machine
Assuming that formal descriptions focus on actions
The primary role of domain knowledge in requirements engineering is in supporting refinement of requirements to implementable specifications
Intelligent Systems Lab

5. The purpose of the paper
not to promote any particular notation, method, or tool, still less to propose new ones.
to clarify the nature of requirements engineering,
to show the importance of certain information that is often absent or implicit,
to solve some persistent foundational problems.
These results can be used to evaluate and improve current and future approaches to requirements engineering.
Intelligent Systems Lab

6. Selection of the four areas of inquiry
have not been chosen randomly
Together they explain the precise nature of
requirements,
specifications,
and domain knowledge,
precise nature of the relationships among them
establish minimum standards for what information should be represented in a requirements language.
make it possible to determine exactly what it means for requirements engineering to be successfully completed
Intelligent Systems Lab

7. Four corners mark a foundation
Terminology and Applicability
Notation
Completion
Intelligent Systems Lab

8. Terminology and Applicability
This terminology applies to all software development projects, although projects differ in emphasis and some projects require imaginative application of the above definitions.
The point is that requirements, specifications, and domain knowledge always have the same relationship to each other.
Intelligent Systems Lab

9. Terminology and Applicability (cont)
The environment is the portion of the real world relevant to the software development project.
The machine is a computer based machine that will be constructed and connected to the environment, as a result of the software development project.
A designation is an informal description of the meaning of an atomic formal term referring to the environment.
A definition is a formal description of an atomic term, using other defined or designated terms.
Intelligent Systems Lab

10. Terminology and Applicability (cont)
A statement (assertion, property) in the indicative mood describes the environment as it would be without or in spite of the machine.
A statement (assertion, property) in the optative mood describes the environment as we would like it to be because of the machine.
A shared action is an action in the environment in which the machine also participates.
An unshared action is an action in the environment in which the machine does not participate.
An environmentcontrolled action is an action in the environment that is controlled, performed, or initiated by the environment.
Intelligent Systems Lab

11. Terminology and Applicability (cont)
A machine controlled action is an action in the environment that is not controlled, performed, or initiated by the environment.
The intention is that such an action will be controlled by the machine when it is connected to the environment.
A requirement is an optative property, intended to express the desires of the customer concerning the software development project.
A statement of domain knowledge or domain assumption is an indicative property intended to be relevant to the software development project.
A specification is an optative property, intended to be directly implementable and to support satisfaction of the requirements.
Intelligent Systems Lab

12. Notation
Formal representations used in requirements engineering should obey these four rules.
If a requirements language is insufficient in this regard, its users should be able to augment or supplement it as necessary.
Intelligent Systems Lab

13. Notation (cont) Each atomic term must be designated or defined.
This means that everything said is said about the environment, since all atomic terms are grounded in the environment.
Each action type must be identified as belonging to exactly one of the following categories
Intelligent Systems Lab

14. Notation (cont)
Whenever necessary to express relevant properties of the environment, actions in all three categories must be constrained.
Each property or assertion must be identified as a requirement, statement of domain knowledge, or specification.
Intelligent Systems Lab

15. Completion
If the five following criteria are satisfied, then requirements engineering, in the strongest sense, is complete
Intelligent Systems Lab

16. Completion (cont)
There is a set R of requirements. Each member of R has been validated (checked informally) as acceptable to the customer, and R as a whole has been validated as expressing all the customer’s desires with respect to the software development project
There is a set K of statements of domain knowledge. Each member of K has been validated (checked informally) as true of the environment
Intelligent Systems Lab

17. Completion (cont)
There is a set S of specifications. The members of S do not constrain the environment, they are not stated in terms of any unshared actions or state components, and they do not refer to the future
A proof for rationality of requirements
There is a proof that S and K are consistent. This ensures that the specification is internally consistent and consistent with the environment. Note that the two proofs together imply that S, K, and R are consistent with each other
Intelligent Systems Lab