Unit 3

REQUIREMENTS ENGINEERING PROCESSES 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. They are: 1. Assessing whether the system is useful to be business (feasibility study) 2. Discovering requirements ( requirements elicitation and analysis) 3. Converting this requirements into some standard form ( specification) 4. Checking these requirements actually define the system that customer wants ( validation) The relationship among these activities is shown: The above relationship also shows the documents produced at each stage of requirements engineering process. The activities which are defined in above figure are concerned with the discovery, documentation and checking of requirements. The process of managing the changing requirements is called requirements management. An alternative perspective on the requirements engineering process is given with 3-stage activity where the activities are organized as on iterative process around a spiral. The amount of time and effort devoted to the each iteration depends on the stage of the overall process and type of the system being developed. Early in the process, most effort will be spent on understanding high level business and non-functional requirements and the user requirements. Later in the process, in the outer rings of spiral, more effort will be devoted to the system requirements engineering and system modeling. This spiral model accommodates approaches to development in which the requirements are developed to different levels of detail. The number of iterations around the spiral can vary, so the spiral can be exited after some or all the user requirements have been elicitated. If the prototyping activity shown under requirements validation is extended to include iterative development, in this model allows the requirements and the system implementation to be developed together. Some people considers requirements engineering to apply a structured analysis model such as object-oriented analysis, this involves analyzing the system and developing a set of graphical models, such as use case models that then serve as a system specification. This set of model describes the behavior of system, and are annotated with additional information( example: describing performance or reliability. Feasibility Studies:

For all new system, the requires engineering process should start with feasibility study. The input to feasibility study is a set of Preliminary business requirements An outline description of the system and How the system is intended to support business processes. The results of feasibility study should be a report that recommends whether the documents specifying that the current system is capable/incapable of satisfying business requirements or not. A feasibility study is a short, focused study that answers to a number of questions. Does the system contributes to the overall objectives of the organization. Can the system be implemented using current technology and with in given cost and schedule constraints? Can the system be integrated with other systems which are already in place? Hence, once we gain informed related to above mentioned facts, we have completed half of our requirements. Carrying out a feasibility study involves Information assessment Information collection and Report writing The information assessment phase identifies the information that is requited to answer the three questions set out above. Once this information has been identified, you should talk the information that discover the answers to these questions. How would the organization cope, if this system were not implemented? What are the problems with current processes and how would a new system help alleviate these problems? Can information be transferred to and from other organizational systems? Does the system require technology that has not previously been used in the organizational? What must be supported by the system and what need not to be supported? Normally, you should try to complete a feasibility study in two or three weeks. Once you have the information, you write the feasibility study report. This recommends whether the system development should continue or not. In these report, you may propose changes to the scope, budget and schedule of the system and suggests further high-level requirements for the system. Requirements elicitation and analysis: The next stage of the requires engineering is requirements elicitation and analysis. In these activities, software engineers work with customers and system end-users to Find out the application domain, what services the system would provide. The required performance of the system Hardware constraints and so on. Requires elicitation and analysis may involve a variety of people in the organization. The term stack holder is used to refer to any person or group, who will be affected by the system directly or indirectly. Elicitation and understanding stack holders requirements is difficult for several reasons:

Stack holders often dont know what they want from the computer system except in the most general terms. They dont know about what they want the system to do and cost of their requests. Stack holders naturally express requires in their own terms and with implicit knowledge of their own work. Different stack holders have different requires, which they may express in different way Political factors may influence the requires of the system The economic and business environment in which the analysis takes place is dynamic i.e; inevitably changes during the analysis process. Every general process model of the elicitation and analysis process is shown in below figure. Each organization will have its own version are instantiation of this general model, depending on local factors such as Staff Type of system being developed and standards used The process activities that are included in spiral is as follows: Requirements discovery: this is the process of interacting with stake holders in the system to collect the requirements. Domain requirements and documentation are also discovered during this activity. Requirements classification and organization: as all the requirements are collected and documented, now it has to be organized orderly. For this purpose, all the related requirements are grouped, often these groups as referred as clusters. Requirements prioritization and negotiation: multiple stake holders are involved, requirements will conflict. This activity is concerned with providing priorities to these requirements (prioritization)and resolving conflicts between them(negotiation). Requirements documentation: the requirements are documented and input into the next round of the spiral. formal or informal requirements documents may be produced. The process cycle starts from requirements discovery and ends with requirements documentation. Requirements classification & organization identifies the overlapped requirements from different stake holders and grouping related requirements .this grouping is to used a model of the system architecture that identifies sub systems and to associate requirements with each sub system. In the requirements documentation stage the requirements that have been elicitated are documented in such a way that can be used to help with the further requirements discovery. At this stage, the requirements may be documented as tables in document or on cards. Writing requirements on cards can be very effective, as these are easy for stakeholders to handle, change and organize. Requirements discovery: Requirements discovery is the process of gathering information about the proposed and existing system and distilling the user and system requirements from the information. You interact with stake holders through interviews and observations, and may use scenarios and prototypes to help with requirements discovery. Techniques of requirements discovery includes Interviewing Scenarios and

Etmography Other techniques for requirements discovery that may be used includes structured analysis methods and system prototyping. Stake holders ranges from system end-users through managers and external stake holders such as regulators who certify the acceptability of the system. Requirements sources can be all represented as system view points. Each view points presents a sub set of the requirements for the system. Each view point provides a fresh perspective on the system, but this perspectives are not completely independent-they usually overlap with some common requirements. View point oriented approaches organizes both requirements elicitation and requirements themselves using view points. A key strength of view point oriented analysis is : It recognizes multiple perspective and provides a framework for discovering conflicts in the requirements proposed by different stake holders.