![]() |
![]() |
![]() |
![]() |
![]() |
Requirements Analysis Phase
After the prestudy/conceptualization phase it is time for the first iteration through the activities in the SOMT method. This will go through the requirements analysis, system analysis and system/object design and sometimes also the implementation activity. This first iteration is in some sense the most important part of the project since it involves both an analysis of the requirements on the system and the development of an architecture that will meet these (and future) requirements. If this first iteration is successful the further elaboration and refinement of the system will work without any catastrophes. If the first iteration is not successful, e.g. an insufficient understanding of the requirements leading to an inappropriate system architecture, there are loads of problems ahead.
The requirements analysis phase starts the first iteration. The activities of this phase are of course centered around the analysis of the requirements as detailed in Requirements Analysis. When this phase is finished the analysis team must have established a common vocabulary and a common understanding of the system's desired behavior. The deliverables are first versions of the models associated with the requirements analysis:
- The textual requirements
- The data dictionary
- The requirements object model, including both information models of the problem and context diagrams
- The use case model
- The system operations model
The most important of these are the use case model, the requirements object model, including the context diagrams, and the data dictionary. Together these describe the major behavior of the system and define a vocabulary describing the application and its environment. The textual requirements are hopefully part of the input to the requirements phase and it is often useful to elaborate these further mainly in the case where the original requirements are too unstructured or incomplete. The system operations are useful if the level of abstraction in the use cases are not found to be detailed enough.
In practise most of the time during the requirements analysis is usually spent designing the use cases, using these as a means to investigate the intended behavior of the system. It is impossible to completely cover the entire set of behaviors in the requirements analysis. Finding the right trade-off between the completeness of the use cases and the time and effort spent in requirements analysis is an important aspect of this phase. A recommended practise from [33] is that the use cases should cover `approximately 80% of the primary scenarios along with a representative selection of the secondary ones'. The use case model (as well as the other models) will be further extended and refined during the elaboration phase so it is important to force the requirements analysis phase to a completion when a sufficient level of understanding has been reached.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |