J.E.D.I
1. Is each requirement consistent with the overall objective for the system or product? 2. Have all requirements been specified at the proper level of abstraction? That is, do
some requirements provide a level of technical detail that is not appropriate at the stage?
3. Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?
4. Is each requirement bounded and clear? 5. Does each requirement have attribution? That is, is a source generally, a specific
individual noted for each requirement? 6. Do any of the requirements conflict with other requirements?
7. Is each requirement achievable in the technical environment that will house the system or product?
8. Is each requirement testable, once implemented? 9. Does the requirement model properly reflect the information, function and behavior of
the system to be built? 10.Has the requirements model been partitioned in a way that exposes progressively
more detailed information about the system? 11.Have the requirements pattern been used to simplify the requirements model? Have
all patterns been properly validated? Are all patterns consistent with customer requirements?
These and other questions should be asked and answered to ensure that all work products reflect the customers needs so that it provides a solid foundation for design and
construction.
3.2.7 Management
It is a set of activities that help the project team identify, control, and track requirements and their changes at any time as the project progresses. Requirements management
starts once they are identified. Each requirement is assigned a unique identifier. Once requirements have been identified, traceability tables are developed.
The Requirements Traceability Matrix RTM is discussed in the Requirements Traceability Matrix section of this chapter which will help software engineers manage
requirements as the development process progresses.
Software Engineering 69
J.E.D.I
3.3 Requirements Analysis and Model
During elaboration, information obtained during inception and elicitation is expanded and refined to produce two important models- requirements model and analysis model. The
requirements model provides a model of the system or problem domain. In this section, we will be discussing the requirements model and how it is built.
3.3.1 The Requirements Model
Rational Rose defines the Requirements Model as illustrated in Figure 3.1
2
. It consists of
three elements, specifically, Use Case Model, Supplementary Specifications, and Glossary.
Use Case Model
It is used to describe what the system will do. It serves as a contract between the customers, end-users and system developers. For customers and end-users, it is used
to validate that the system will become what they expect it to be. For the developers, it is used to ensure that what they build is what is expected. The Use Case Model consists
of two parts, namely, the use case diagrams and use case specifications.
1. The use case diagram consists of actors and use cases. It shows the functionality
that the system provides and which users will communicate with the system. Each use case in the model is describe in detail using the use case specifications. The use
case specifications are textual documents that specify properties of the use cases such as flow of events, pre-conditions, post-conditions etc. The UML diagramming
2 Object-oriented
Analysis and Design Using the UML
, Rational Rose Corporation, 2000, page 3-5
Software Engineering 70
Figure 3.1 Requirements Model
Use-Case Model
Actor Actor
Use Cases
Use-Case Specifications
Supplementary Specification
Glossary
