Requirements Elicitation: In requirements engineering, requirements elicitation is the practice of obtaining the requirements of a system from users, customers

and other stakeholders. The practice is also sometimes referred to as requirements gathering. The requirements are gathered by interacting with user via techniques like interviews, prototyping, etc. Types of Requirements 1) Functional: main features of a system 2) Non-Functional: additional features e.g. look of the interface 3) Known : user have some idea about a particular requirement 4) Unknown: user doesnt have any idea e.g. language to be used for development. Requirement Elicitation Techniques 1. Interviews/Questions & Answers 2. Prototyping a) Throw-away : prototype is thrown away after customer is satisfied, and the actual system is build from scratch. b) Evolutionary: prototype is developed into the final system produced. 3. Ethnography: requirements gathering through observation. The requirements engineer visits and observes the environment of the customer where the software has to perform the services. This technique is often used with the conjunction of other requirements engineering techniques like interview. 4. Scenarios : scenarios are different ways in which a system can be used e.g. during Login we provide a wrong password. a) As-is scenario: describes a current situation. b) Visionary scenario: describes a future system. c) Training scenario: tutorials used for introducing new users to the system. d) Evaluation scenario: define a task against which system is to be evaluated. Advantages Interviews: it is the most basic technique to know the user requirements Prototyping: customer is able to specify requirements with more clarity. Ethnography: useful to collect quality attributes. Much effective when to determine social and organizational factors in solution to the problem. Scenarios: people can relate to scenarios more easily than abstract statement of what they require from the system. Limitations Interviews: customer may not be able to clearly express his needs due to lack of technical knowledge. Prototyping: Additional cost of creating the prototype Ethnography: Mostly results of observations are wrong. Scenarios: May include details irrelevant to design; for a large & complex systems, there may be too many scenarios to be designed.

Other Activities concerned with Requirements Brainstorming involves a meeting of people with innovative ideas. Joint Application Development(JAD): elicitation of requirements is done in one single workshop session in which all stakeholders participate. Quality Function Deployment(QFD) is a quality management technique that concentrates on maximizing customer satisfaction. QFD says that 3 types of requirements are to be identified: i) Normal: explicitly stated by customer ii) Expected: not explicitly stated but absence nay cause dis-satisfaction iii) Exciting: beyond customer expectations. Facilitated Application Specification Techniques(FAST) This approach encourages creation of joint team of customers and developers. i) Meeting is conducted at a neutral site and attended by both customer & developer. ii) Rules are established. iii) A facilitator controls the meeting. iv) A definition mechanism like work sheets is used. v) Purpose is to identify the problem and propose different solutions.

Requirements Model: The model used for requirements elicitation in OOSE is the UseCase model. Requirement Elicitation Activities 1) Identify actors : actors are persons who interact with the system. 2) Identify scenario: a scenario is an instance of a use-case e.g. for a login use-case one scenario is successful login and other is failed login. 3) Identify use-cases: a use-case describes an intent of the user, a use-case specifies all possible scenarios for a given piece of functionality. 4) Identify relationships b/w use-cases : uses, extends & includes Uses : one use-case always uses the functionality provided by another use-case Extends : one-use case optionally uses the functionality provided by the other use-case, and also may add additional behavior at extension points. Includes : a behavior which is shared by two or more use-cases, can be factored out into a separate use case 5) Refine use-cases: access rights are given i.e. which actor can invoke which usecase, common functionality among use- cases are factored out. 6) Identify non-functional requirements 7) Identify participating objects: identify objects to be used in the system.

Use Case model for Library Management System

Every use-case in the use-case diagram is to be explained textually. Use-case Template 1. Introduction 2. Actors 3. Pre-condition 4. Post-condition 5. Flow of Events 5.1 Basic Flow 5.2 Alternate Flow 6. Special Requirements 7. Related Use Cases

Managing Requirement Elicitation The results of requirement elicitation activities are documented in Requirements Analysis Document(RAD). This document serves as a contract between the client & developer. This document is reviewed by stakeholders, before being finalized. The requirements may change during the development process. To handle these changes we have a well defined Change Management Process consisting of 6 activities 1. Identify potential change: understand what change is to be made. 2. Analyze change request: determine feasibility of change 3. Evaluate change: change committee makes a Y/N decision 4. Plan change: plan how the change can be implemented 5. Implement change 6. Review & Close change: verify & test the change

Challenges of Requirements Elicitation 1. Problems of understanding: user may not be fully aware of his needs or may not be able to express his needs clearly. 2. Problems of volatility: requirements may change over time.