1. Requirements Engineering Processes

2. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements elicitation and analysis Requirements validation Requirements management l Techniques for Requirements Elicitation

3. Definitions l Requirements are the descriptions of the services provided by a system for the customer and The constraints under which it operates and is developed. l REP is the process of Discovering, Analyzing, Documenting and Validating the requirements of the system; Each software development process goes through the phase of requirements engineering

4. Requirements engineering processes l The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.

5. The requirements engineering process Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility report System models User and system requirements Requirements document

6. Phases of Requirements Engineering Process

7. Feasibility study l A feasibility study decides whether or not the proposed system is worthwhile. l A short focused study that checks If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are used.

8. Elicitation and analysis l Sometimes called requirements elicitation or requirements discovery. l A people-intensive process. l Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. l May involve end-users, managers, engineers involved in maintenance, domain experts, etc. These are called stakeholders.

9. Problems of requirements analysis l Stakeholders don’t know what they really want. l Stakeholders express requirements in their own terms. l Different stakeholders may have conflicting requirements. l Organisational and biased factors may influence the system requirements. l The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

10. Requirements validation l Concerned with demonstrating that the requirements define the system, that the customer really wants. l Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

11. Requirements checking l Validity. Does the system provide the functions which best support the customer’s needs? l Consistency. Are there any requirements conflicts? l Completeness. Are all functions required by the customer included? l Realism. Can the requirements be implemented given available budget and technology l Verifiability. Can the requirements be checked?

12. Requirements management l Requirements management is the process of managing changing requirements during the requirements engineering process and system development. l Requirements are inevitably incomplete and inconsistent New requirements emerge during the process as business needs change and a better understanding of the system is developed; Different viewpoints have different requirements and these are often contradictory.

13. Techniques for Requirements Elicitation l Interviewing l Brainstorming l Prototyping l Requirement Workshop l “When people talk, listen completely. Most people never listen.”

14. Interviewing Interviews are the commonly used and most popular method for requirements elicitation. In this method the analyst and the engineers of the requirements engineering process discuss with the different types of stake holders to understand the requirements of the system and the objective they have to fulfil in the system. There are typically 2 main types of interviews 1. Closed Interview: In this interview the requirements engineer prepare some predefined questions and he tries to get the answers for these questions from the stake holders. 2. Open interview: In this interview the requirements engineer does not prepare any predefined questions, and he tries to get the information from the stakeholders in open discussions. He mostly concentrates on finding the stake holders expectations on the system.

15. Brainstorming l Brainstorming is a techniques used to generate new ideas and find the solution to a specific issue. l This is conducted as a conference with six to ten members. l The members are from the different departments and domain experts are also included. l This conference is headed by the organizer, who states the issue to be discussed. l The conference is generally held in a round table fashion. l Every member person is allotted with certain time interval to explain their ideas. l Notepads are provided to all members to write their ideas and suggestions. l The team of brainstorming will then decide the best idea by voting from the group and that idea is selected as the solution to the issue discussed in the conference.

16. Brainstorming can be used to answer the following questions What exactly the system should provide ? What are the business and organization rules required to follow ? What type of questions should be there in the interviews and questionnaires? What are the risk factors effect the proposed system development and what to do avoid that?

17. Prototyping l The Prototype is the representations or visualizations of the actual system parts. l The prototype is designed in the early stages of the implementation of the project. It provides the General idea of the actual system functions and the work flow. Prototyping is used to gather the requirements from the users by presenting GUI based system functions. l Main aim of Requirements Elicitation is to gather the requirements before the product is developed. But it is difficult to discover the additional requirements until it comes in to usage or some body is actually using it. l The process of gathering the requirements from the stakeholders and the end users is limited and it is difficult to discover their expectations and the requirements on the new product with out providing some model that resembles the appearance of the real product.

18. l A prototype represents the actual product in both functional and graphical sense. l It provides the flexibility to the users and the stake holders to work with the initial version of the product to understand the system and discuss them to think of the additional and missed requirements. l Prototyping is a most expensive than the all other methods of requirements elicitation

19. Requirements workshop l A requirements workshop is a structured, facilitated event in which a carefully selected group of stakeholders work together to discover, create, verify, and document predefined requirements deliverables, or work products. l The group is comprised a balanced mix of business and IT people and is led by a neutral facilitator.

20. l The most successful workshops are collaborative. This means that the group joins together to create work products designed to achieve their common goal. l These workshop participants are productive because collectively they have the right mix of skills and knowledge to create the work products. l Members of the group act interdependently, relying on one other’s knowledge, experience, skills, and perspectives – they are motivated to act together.

22. Key points l The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management. l Requirements elicitation and analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation. l Systems have multiple stakeholders with different requirements.

23. Key points l Social and organisation factors influence system requirements. l Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability. l Business changes inevitably lead to changing requirements. l Requirements management includes planning and change management.