The goal of the requirements engineering process is to create and maintain a system requirements document.

The overall process includes four high-level requirements engineering sub-processes. These are concerned with assessing whether the system is useful to the business (feasibility study); discovering requirements (elicitation and analysis); converting these requirements into some standard form (specification); and checking that the requirements actually define the system that the customer wants (validation). Figure 7.1 illustrates the relationship between these activities. It also shows the documents produced at each stage of the requirements engineering process.

Although structured methods have a role to play in the requirements engineering process, there is much more to requirements engineering than is covered by these methods. Requirements elicitation, in particular, is a human-centred activity and people dislike the constraints imposed by rigid system models.

7.1Feasibility studies
A feasibility study is a short, focused study that aims to answer a number of questions: I. Does the system contribute to the overall objectives of the organisation? 2. Can the system be implemented using (current technology and within given cost and schedule constraints? 3. Can the system be integrated with other systems which are already in place? Carrying out a feasibility study involves information assessment, information collection and report writing. The information assessment phase identifies the information that is required to answer the three questions set out above. Once the information has been identified, you should talk with information sources to discover the answers to these questions. Some examples of possible questions that may be put are: I. How would the organisation cope if this system were not implemented? 2. What are the problems with current processes and how would a new system help alleviate these problems? 3. What direct contribution will the system make to the business objectives and requirements? 4. Can information be transferred to and from other organisational systems? 5. Does the system require technology that has not previously been used in the organisation? 6. What must be supported by the system and what need not be supported?

7.2 Requirements elicitation and analysis

The next stage of the requirements engineering process is 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 performance of the system, hardware constraints, and so on. Requirements elicitation and analysis may involve a variety of people in an organisation. 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 organisation that may be affected by its installation. Eliciting and understanding stakeholder requirements is difficult for several reasons: I. Stakeholders often don't know what they want from the computer system except in the most general terms. 2. Stakeholders naturally express requirements in their own terms and with implicit knowledge of their own work. 3. Different stakeholders have different requirements, which they may express in different ways. 4. Organisational and political factors may influence the system requirements.

5.The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

Figure 7.3 The Requirements elicitation and analysis process

The above figure 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 process activities are: 1. 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. 2. Requirements classification and organisation This activity takes the unstructured collection of requirements, groups related requirements and organises them into coherent clusters. 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 subsystems and to associate requirements with each sub-system. 3. Requirements prioritisation and negotiation Inevitably, where multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritising requirements, and finding and resolving requirements conflicts through negotiation. Inevitably, stakeholders have different views on the importance and priority of requirements, and sometimes these views

conflict. During the process, you should organise regular stakeholder negotiations so that compromises can be reached. 4. Requirements documentation The requirements are documented and input into the next round of the spiral. Formal or informal requirements documents may be produced. 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.