Requirement Elicitation & Management

Overview of Requirement Elicitation
IEEE standard 610.12.1990 defines the requirement as • A condition or capability needed by a user to solve a problem or to achieve an objective. • A condition or capability that must be possessed by a system to satisfy a contract, standard, specification or other imposed documents. • A documented representation of a condition or capability. Requirements can be of two types: (i) Functional requirements, related with the identification of functions and data related requirements. (ii) Non-Functional requirements e.g. Resource constraints (processor speed, memory, disk space, network bandwidth, etc.), Security, Price, Platform, etc.

Requirement Engineering can be divided into two parts: 1. Requirements Definition 2. Requirements Management Requirements Definition consists of following stages: 1. Requirements Elicitation, concerned with gathering of requirements. 2. Requirement Analysis, concerned with modeling the requirements to identify errors, inconsistencies, and other defects. The models used are Use-cases, DFDs, ER diagrams, State Transition diagrams. 3. Requirement Documentation, the requirements document is called as SRS(Software Requirements Specification) 4. Requirement Review, deals with how to handle changes in requirements.

Challenges in Requirement Elicitation
• users have incomplete understanding of their needs • users have poor understanding of computer capabilities and limitations • analysts have poor knowledge of problem domain • user and analyst speak different languages • ease of omitting “obvious” information • conflicting views of different users • requirements are often vague and untestable, e.g., “user friendly” and “robust” • requirements evolve over time • unnecessary design information may be given

50

if a system for a supermarket is required. where multiple stakeholders are involved. Requirements collection: This is the is the process of interacting with stakeholders in the system to discover their requirements. Obviously. For example. Conflict Resolution: Inevitably. domain understanding develops furher during this activity. Domain understanding: Analysts must develop their understanding of the application domain. 4. consistent and in accordance with what stakeholders really want from the system. This activity is concerned with finding and resolving conflicts. 6. 51 . Classification: This activity takes the unstructured collection of requirements and organizes them into coherent clusters. requirements will conflict. Requirements checking: The requirements are checked to discover if they are complete. the analyst must find out how supermarket s operate. 2. 3. This stage involves interaction with stakeholders to discover the most important requirements.Requirement Elicitation & Management Requirements Elicitation Activities 1. Prioritization: In any set of requirements some will be more important than others. 5.

system stakeholders for a bank ATM include Account holders. etc. So. their perspectives are not completely independent but usually overlap so that they have common requirements.Requirement Elicitation & Management Requirements Discovery Techniques 1. there are many different viewpoints that should be considered. The principal stages of VORD are: 52 . For example. Different viewpoints on a problem see the problem in different ways. Viewpoint Oriented Requirements Definition(VORD) For any system there are usually different types of end users. Maintenance Engineers. However. Bank Staff. for every system. Database administrators.

which involves discovering viewpoints that receive system services and identifying the specific services provided to each viewpoint. 53 . Common services are provided at higher levels in the hierarchy and are inherited by lower-level viewpoints.Requirement Elicitation & Management (i) (ii) (iii) (iv) Viewpoint Identification. To illustrate event scenarios. The forms used for Viewpoint information and Service information are shown in Figure below 2. Requirements engineers can use the information gained from this discussion to formulate the actual system requirements. which involves identifying objects in an object oriented design using service information which is encapsulated in viewpoints. consider Figure which shows the scenario to ‘Start Transaction’ event. Viewpoint and service information in VORD is collected using standard forms. Scenarios People find it easy to understand and criticize a scenario of how they might interact with a software system. which involves grouping related viewpoints into a hierarchy. Viewpoint structuring. Viewpoint system mapping. Viewpoint documentation. Each distinct interaction event such as inserting a card into an ATM or selecting an ATM service may be documented with a separate event scenario. which involves defining the description of the identified viewpoints and services. The scenario based approaches used are Event scenarios or Use Cases.

the action taken is to return card. 3. Validate user. a use-case identifies the actors involved in an interaction and names the type of interaction. The customer inputs his/her PIN. Invalid Card. for which PIN is requested again.e. If an incorrect PIN is again input. Use cases are a scenario-based technique for requirements elicitation which were first introduced in the Objectory method (Jacobson et al.Requirement Elicitation & Management Figure shows that when a card is inserted. An analyst immerses himself in the working environment where the system will be used. The second stage i. In first stage i.e. 1993). For the first two exceptions. if the card is valid control can move to the next stage. In their simplest form. has exception Incorrect PIN. The day-to-day work is observed and notes made of actual tasks in which the participants are involved. the card is retained by the machine.. For the third exception. the customer’s PIN is requested. and Stolen Card. Request PIN. the card is returned. there are three possible exceptions: Timeout. 54 . The value of ethnography is that it helps discover implicit system requirements which reflects the actual rather than formal processes in which people are involved. Ethnography Ethnography is an observational technique that can be used to understand social and organizational requirements. A use case encapsulates all possible scenarios for that specific use-case.

air traffic controller may use an awareness of other controller’s work to predict the number of aircraft which will be entering their control sector. Therefore. an automated ATC system should allow controllers in a sector to have some visibility of the work in adjacent sectors.Requirement Elicitation & Management Ethnography is particularly effective at discovering two types of requirements: i) Requirements that are derived from the way in which people actually work rather than the way in which process definitions say they ought to work. as it cannot always identify new features which should be added to a system. air traffic controllers may switch off an aircraft conflict alert system which detects aircraft with intersecting flight paths even though normal control procedures specify that it should be used. They then modify their control strategies depending on that predicted workload. Their control strategy is designed to ensure that these aircraft are moves apart before problems occur and they find that the conflict alert alarm distracts them from their work. For example. ii) Requirements that are derived from cooperation and awareness of other people’s activities. Ethnography is not a complete approach to elicitation and it should be used with other approaches such as use-case analysis. For example. 55 .

Compatibility requirements: requirements that depend on other systems ii. toss of a coin 56 . Enduring requirements: Stable requirements derived from the core activity of the customer organization.Requirement Elicitation & Management Requirement Classification 1. iii. 3) Third Party Resolution: participants appeal to outside source Types of third party resolution i) Judicial: cases presented by each participant are taken into account ii) Extra-judicial: a decision is determined by factors other than the cases presented (e. requirements derived from health-care policy i. 2) Competition: maximizing your own gain. iv. Conflict Resolution Basic approaches to conflict resolution 1) Negotiation: participants attempt to find a settlement that satisfies all parties as much as possible. Volatile requirements. Requirements which change during development or when the system is in use. relative status of participants). etc. e.g.g. Mutable requirements: requirements that change due to the changing of system’s environment Emergent requirements: requirements that emerge as understanding of the system develops during the system development. Consequential requirements: requirements that result from the introduction of the computer system that result to new process which may generate new requirements. nurses.g. a hospital will always have doctors. In a hospital. iii) Arbitrary: e. 2. no regard for the degree of satisfaction of other parties.

For each requirement. we have to decide: How important is this to the customer? How much will it cost to implement? How risky will it be to attempt to build it? The most basic approach for requirement prioritization is Cost-Value approach. The requirements having high importance and low cost is given higher priority.Requirement Elicitation & Management Requirement Prioritization Customer may have way too much requirements. 57 .

4. Impact Analysis: After initiation. Evaluation: The Configuration Controller collects the impact analysis and calls for a meeting of Change Control Board(CCB). The initiator also describes why such a change is required to the system. Reject. have been made. impact on current activities.g. what versions will be changed and what quality control steps will be taken on each item that will be changed. Partially Approved. The CCB may take one of the following decisions: Approve. The requirements management process consists of following steps: 1. Execution: Execution phase includes all the quality control steps that were planned in the Implementation Plan for the CRF. The initiator describes the changes required with respect to what is documented in SRS. what benefits are expected with changes. 2. Planning: Once the CRF is fully or partially approved. 6. and senior designers from the development team. additional time. The CCB comprises of Project Manager. 3. what difficulties will be faced without the change. additional resources. Configuration Controller. Closing: The CRF is marked as closed after verifying that all changes that were required 58 . technical feasibility.Requirement Elicitation & Management Requirements Management Requirements Management deals with how to handle the changes in requirements . Keep Pending for next CCB or performs further impact analysis. 5. etc. the Configuration Controller along with the project manager hands over the CRF to various members of project team to evaluate the proposed change from various perspectives e. the Configuration Controller fills up the Implementation Plan including the base-lined items need to be changed. Initiation: A change in requirement is initiated by filling up the Change Requirement Form(CRF).

Sign up to vote on this title
UsefulNot useful