8 Part 8: Annex
8.1 Method References
8.1.12 Requirements Analysis
Usage
Determining Requirements, Preparing External Hardware Module Specification, Preparing Logistic Support Specification, Preparing External Software Module Specification, Preparing External Unit Specification, Preparing Overall System Specification, Preparing System Specification
Reference
Purpose
The objective of the analysis of requirements is the identification, description and quality assurance of requirements. For the analysis of requirements the following methods may be used:
Use Case Modeling
The objective of this method is to collect and present the functional requirements for a system from the point of view of external operating units ("actors"). The requirements have to be described in the form of use cases. A use case may be concretized in a number of scenarios. External operating units (for example staff, »Project Leader or administrator) represent roles that may be played by actual persons, machines, computer tasks or other systems.
A use case will be initiated by an operating unit, and its description will contain the dialogs or interactions between this operating unit and the system that are "required" to work on a task. For the description of the interactions a sequence of actions and events is defined that are triggered by the initiating operating unit, the system or other operating units. Only those actions or events have to be defined that are visible from the point of view of the operating unit, but not details that describe how the system is intended to work internally.
The »System Specified use cases represent as a whole the application-oriented functional requirements for the system. For a complete description, if possible all identified use cases should be specified in this form.
Interview Technique
One possibility for the identification of the requirements is the interview technique. It is used to question future users in a specified and formalized process. It is assumed that with this interview technique it is possible to form different groups and to inquire about utilization potentials that are difficult to quantify, that are quantifiable and that are supplementary. For such an approach the involvement and active cooperation of all areas concerned is absolutely necessary for the quantification of the utilization potentials. Although it is possible to assume in advance fictitious values when this cooperation is lacking, those values subsequently may be questioned very easily by the affected areas. A defined interview method is the "Structured Hierarchical Interviewing for Requirement Analysis" (SHIRA), which sets in very early. SHIRA tries to understand the concrete meaning of product attributes, such as "simple", "innovative", "controllable" or "impressive", for a possible software product.
Dialog Design Modeling
The aim of "Dialog Design Modeling" is to model the structure of a user dialogue with screen masks, leaving the layout of the screen masks out of consideration. The masks may only be typified (the type may be for example an input mask).
System Behavior Models
The aim of the preparation of system behavior models is to use a model to specify the requirements for the dynamic behavior of a system considering in particular the influence of (external) events on the system and possible concurrencies within the system. This model is used in particular for the alignment with the requirements of the user and the exact definition with regard to completeness, unambiguity etc.
Cost-Benefit Analysis for Requirements
In the analysis of requirements often a cost-benefit analysis for the prioritization of the requirements is made. This is an analysis with the goal to make a recommendation whether the expected benefit of the realization of an requirement will justify the expected costs. This makes it easier to eliminate requirements of lesser importance.
Use of facilitation techniques
Sometimes, an unconventional approach is necessary in order to successfully deal with the heterogeneity of the stakeholders participating in the elicitation of requirements. Facilitation techniques serve the purpose of enabling the develompent of unusual creative ideas. However they are not suited to elicit detailed descriptions of the precise behaviour of a system. Albeit facilitation techniques can serve to overcome obstacles which the own way of thinking and the missing familiarity with someone elses thinking can pose to the elicitation of requirements.
The following facilitation techniques may be apt depending on the situation:
- Brainstorming,
- Brainstorming paradox (results, which are not to be achieved, are collected),
- 6-3-5 method (Brainstorming in writing: 6 participants develop 6 ideas each, these are distributed until each participant has posessed each card once),
- Change of perspective (each participant considers the problem from a different previously defined perspective),
- Walt Disney method (the participants are classified into the groups dreamer/visionary, realist and critic),
- Bionic/biosociation (finding of proper associations to the problem and discussion of solution possibilities for the analogon).
Use of observation techniques
The user has the most knowledge of how tasks of his daily work can be tackled. Nevertheless it happens often that the user - consciously or unconsciously - does not provide suitable descriptions of his activities. Observation techniques are used to give the requirements engineer an insight into the world of the user. These techniques may be very time consuming, but they offer the potential for the requirements engineer to really understand the tasks the user has to cope with and thus for the requirements engineer to phrase his own requirements to support these tasks.
The following observation techniques may be used:
- Field observation (the requirements engineer observes the user in his daily work),
- Apprenticing (the requirements engineer learns the tasks of the user and applies them).