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

Requirement Elicitation & Management

Requirements Elicitation Activities

1. Domain understanding: Analysts must develop their understanding of the application

domain. For example, if a system for a supermarket is required, the analyst must find out how supermarket s operate.
2. Requirements collection: This is the is the process of interacting with stakeholders in the

system to discover their requirements. Obviously, domain understanding develops furher during this activity.
3. Classification: This activity takes the unstructured collection of requirements and

organizes them into coherent clusters.

4. Conflict Resolution: Inevitably, where multiple stakeholders are involved, requirements

will conflict. This activity is concerned with finding and resolving conflicts.
5. Prioritization: In any set of requirements some will be more important than others. This

stage involves interaction with stakeholders to discover the most important requirements.
6. Requirements checking: The requirements are checked to discover if they are complete,

consistent and in accordance with what stakeholders really want from the system.

51

Requirement Elicitation & Management

Requirements Discovery Techniques

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

52

Requirement Elicitation & Management

(i) (ii) (iii) (iv)

Viewpoint Identification, which involves discovering viewpoints that receive system services and identifying the specific services provided to each viewpoint. Viewpoint structuring, which involves grouping related viewpoints into a hierarchy. Common services are provided at higher levels in the hierarchy and are inherited by lower-level viewpoints. Viewpoint documentation, which involves defining the description of the identified viewpoints and services. Viewpoint system mapping, which involves identifying objects in an object oriented design using service information which is encapsulated in viewpoints.

Viewpoint and service information in VORD is collected using standard forms. The forms used for Viewpoint information and Service information are shown in Figure below

2. Scenarios People find it easy to understand and criticize a scenario of how they might interact with a software system. Requirements engineers can use the information gained from this discussion to formulate the actual system requirements. The scenario based approaches used are Event scenarios or Use Cases.

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. To illustrate event scenarios, consider Figure which shows the scenario to Start Transaction event.
53

Requirement Elicitation & Management

Figure shows that when a card is inserted, the customers PIN is requested. The customer inputs his/her PIN, if the card is valid control can move to the next stage. In first stage i.e. Request PIN, there are three possible exceptions: Timeout, Invalid Card, and Stolen Card. For the first two exceptions, the action taken is to return card. For the third exception, the card is retained by the machine. The second stage i.e. Validate user, has exception Incorrect PIN, for which PIN is requested again. If an incorrect PIN is again input, the card is returned.

Use cases are a scenario-based technique for requirements elicitation which were first introduced in the Objectory method (Jacobson et al., 1993). In their simplest form, a use-case identifies the actors involved in an interaction and names the type of interaction. A use case encapsulates all possible scenarios for that specific use-case. 3. Ethnography Ethnography is an observational technique that can be used to understand social and organizational requirements. An analyst immerses himself in the working environment where the system will be used. The day-to-day work is observed and notes made of actual tasks in which the participants are involved. 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.
54

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. For example, 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. 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. ii) Requirements that are derived from cooperation and awareness of other peoples activities. For example, air traffic controller may use an awareness of other controllers work to predict the number of aircraft which will be entering their control sector. They then modify their control strategies depending on that predicted workload. Therefore, an automated ATC system should allow controllers in a sector to have some visibility of the work in adjacent sectors. Ethnography is not a complete approach to elicitation and it should be used with other approaches such as use-case analysis, as it cannot always identify new features which should be added to a system.

55

Requirement Elicitation & Management

Requirement Classification
1. Enduring requirements: Stable requirements derived from the core activity of the

customer organization. e.g. a hospital will always have doctors, nurses, etc.
2. Volatile requirements. Requirements which change during development or when the

system is in use. In a hospital, requirements derived from health-care policy

i.

Mutable requirements: requirements that change due to the changing of systems 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. Compatibility requirements: requirements that depend on other systems

ii.

iii.

iv.

Conflict Resolution
Basic approaches to conflict resolution 1) Negotiation: participants attempt to find a settlement that satisfies all parties as much as possible. 2) Competition: maximizing your own gain, no regard for the degree of satisfaction of other parties. 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.g. relative status of participants). iii) Arbitrary: e.g. toss of a coin

56

Requirement Elicitation & Management

Requirement Prioritization
Customer may have way too much requirements. 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.

57

Requirement Elicitation & Management

Requirements Management
Requirements Management deals with how to handle the changes in requirements . The requirements management process consists of following steps:
1. Initiation: A change in requirement is initiated by filling up the Change Requirement

Form(CRF). The initiator describes the changes required with respect to what is documented in SRS. The initiator also describes why such a change is required to the system, what benefits are expected with changes, what difficulties will be faced without the change.
2. Impact Analysis: After initiation, 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.g. technical feasibility, additional resources, additional time, impact on current activities, etc.
3. Evaluation: The Configuration Controller collects the impact analysis and calls for a

meeting of Change Control Board(CCB). The CCB comprises of Project Manager, Configuration Controller, and senior designers from the development team. The CCB may take one of the following decisions: Approve, Reject, Partially Approved, Keep Pending for next CCB or performs further impact analysis.
4. Planning: Once the CRF is fully or partially approved, the Configuration Controller fills

up the Implementation Plan including the base-lined items need to be changed, what versions will be changed and what quality control steps will be taken on each item that will be changed.
5.

Execution: Execution phase includes all the quality control steps that were planned in the Implementation Plan for the CRF. have been made.

6. Closing: The CRF is marked as closed after verifying that all changes that were required

58