![]() |
![]() |
![]() |
![]() |
![]() |
Requirements Analysis Overview
The purpose of the requirements analysis is to establish an understanding of the application domain and to capture, formalize, analyze and validate the user requirements on the system to be built. For this purpose the system is viewed as a black-box and only the objects and concepts visible on the system boundary and outside the system are modeled.
The input to this activity can of course be very different depending on the application, from an extensive requirements specification provided by a customer to some more or less vague ideas not documented on paper. In any case the result of the activity should be the same: An understanding of the problem domain that the system is to be operating within and an understanding of the role the system is to fulfill in this environment, i.e. the requirements on the system to be built.
In many cases the requirements analysis can be divided into two activities:
The problem analysis concentrates on understanding the problem domain the system is going to operate in, without any reference to the system itself. The system requirements analysis focuses directly on the functional requirements on the system, viewed as a black box.
An overview of the requirements analysis activity is depicted in Figure 636. As can be seen a number of models are used:
- Textual requirements model as described in Textual Requirements. Some requirements are supplied as input to the activity, others may be produced within the activity.
- Data dictionary, further described in Data Dictionary.
- Use case model, described by text, plain MSCs, or plain MSCs in combination with HMSCs. The use case model shows the system and the actors interacting with the system. It is described in Use Cases.
- Requirements object model using object model notation. This model includes both a problem domain model and context diagrams showing the system and the external actors that interact with the system. The requirements object model is described in Requirements Object Model.
- System operations model, see System Operations.
The requirements analysis is a highly iterative process where the different tasks creating the different models are iterated over and over again but the following outline can give some guideline on how to structure the work:
- Study any textual requirements that are provided as input and other sources of information that are available, e.g. read text books about the problem domain and talk to potential users of the system. This may also include rewriting (or creating from scratch) the textual requirements to make them more complete or structured.
- While performing 1 above create a first version of the data dictionary, including lists of actors, use cases and important problem domain concepts.
- Create a first version of the requirements object model:
- Create a first version of the use case model.
- Refine and extend the requirements object model and use case model until the use cases and their exceptions cover a sufficient part of the requirements. Add state charts to the requirements object model if the behavior of an object needs to be considered. When needed use system operations to define the details of the interactions between the actors and the system.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |