Requirements, Elicitation And Analysis
The next stage of the requirements engineering process is the requirements elicitation and analysis. In this activity, software engineers work with customers and system end-users to find out about the application domain, what services the system should provide, the required performançe of the system, hardware constraints, and so on
Requirements elicitation and analysis may involve a variety of people in an organization. The term stakeholder is used to refer to any person or group who will be affected by the system, directly or indirectly. Stakeholders include end-users who interact with the system and everyone else in an organization that may be affected by this installation. Other system stakeholders may be engineers who are developing or related systems, business managers, domain experts, and trade union, representatives,
Eliciting and understanding stakeholder requirements is difficult for several reasons:
Stakeholders often don’t know what they want from the computer system in the most general terms. They may find it difficult to articulate what they want the system to do or make unrealistic demands because they are unaware of the cost of their requests.
Stakeholders naturally express requirements in their own terms and with implicit knowledge of their own work. Requirements engineers, without experience in the customer’s domain, must understand these requirements.
Different stakeholders have different requirements, which they may express in different ways. Requirements engineers have to consider all potential sources of requirements and discover commonalities and conflicts.
Political factors may influence the requirements of the system, For example, managers may demand specific system requirements that will increase their influence in the organization.
The economic and business environment in which the analysis takes place is dynamic. It inevitably changes during the analysis process, Hence the importance of particular requirements may change. New requirements may emerge from new stakeholders who were not originally consulted,
A very general process model of the elicitation analysis process is shown in Figure 7. 3. Each organization will have its own version or instantiation of this general model, depending on local factors such as the expertise of the staff, the type of system being developed, and the standards used. Again, you can think of these activities within a spiral so that the activities are interleaved as the process proceeds from the inner to the outer rings of the spiral.
The process activities are:
Requirements discovery: This is the process of interacting with stakeholders in the system to collect their requirements, Domain requirements from stakeholders and documentation are also discovered during this activity.
Requirements classification and organization: This activity takes the unstructured collection of requirements, groups related requirements and organizes them into coherent clusters.
Requirements prioritization and negotiation: Inevitably, where multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritizing requirements, and finding and resolving requirements conflicts through negotiation.
Requirements documentation: The requirements are documented and input into the next round of the spiral. Formal or informal requirements documents may be produced.
Figure 7.3 shows that requirements elicitation and analysis is an iterative process with continual feedback from each activity to other activities. The process cycle starts with requirements discovery and ends with requirements documentation. The analyst’s understanding of the requirements improves with each round of the cycle.
In this chapter, I focus primarily on requirements discovery and the various techniques that have been developed to support this. Requirements classification and organization is primarily concerned with identifying overlapping requirements from different stakeholders and grouping related requirements. The most common way of grouping requirements is to use a model of the system architecture to identify sub-systems and to associate requirements with each sub-system.
This emphasizes that requirements engineering and architectural design cannot always be separated. Inevitably, stakeholders have different views on the importance and priority of requirements, and sometimes these views conflict. During the process, you should organize regular stakeholder negotiations so that compromises can be reached. It is impossible to completely satisfy every stakeholder, but if some stakeholders feel that their views have not been properly considered, they may deliberately attempt to undermine the RE process.
In the requirements documentation stage, the requirements that have been elicited are documented in such a way that they can be used to help with further requirements discovery. At this stage, an early version of the system requirements document may be produced, but it will have missing sections and incomplete requirements. Alternatively, the requirements may be documented as tables in a document or on cards. Writing requirements on cards (the approach used in extreme programming) can be very effective, as these are easy for stakeholders to handle, change, and organize.