IBM
Contents Index Previous Next



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.

Figure 636 : Overview of the requirements analysis activity

An overview of the requirements analysis activity is depicted in Figure 636. As can be seen a number of models are used:

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:

  1. 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.
  2. While performing 1 above create a first version of the data dictionary, including lists of actors, use cases and important problem domain concepts.
  3. Create a first version of the requirements object model:
    • Use context diagrams to give an overview of the actors and the system.
    • Use an information model to describe the problem domain.
  4. Create a first version of the use case model.
    • Review and optimize the list of use cases found so far.
    • Describe the details of the most important use cases as text and/or MSCs. If the use cases are complex, HMSCs can be used in combination with plain MSCs. Start with the normal cases and leave the exceptional cases for the moment.
  5. 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
Contents Index Previous Next