Requirements elicitation
After an initial feasibility study, the next stage of the requirements engineering process is requirements elicitation and analysis. In this activity, software engineers work with customers and system end-users to find out about the application domain, what services the system should provide, the required performance of the system, hardware constraints, and so on.
Requirements elicitation and analysis may involve a variety of different kinds of people in an organization. A system stakeholder is anyone who should have some direct or indirect influence on the system requirements. Stakeholders include end users who will interact with the system and anyone else in an organization who will be affected by it. Other system stakeholders might be engineers who are developing or maintaining other related systems, business managers, domain experts, and trade union representatives.
The activities involved in requirement elicitation and analysis include
Requirements discovery
Requirement classification and organization
Requirement prioritization and negotiation
Requirements specification
1. Requirements discovery
This is the process of interacting with stakeholders of the system to discover their requirements. Domain requirements from stakeholders and documentation are also discovered during this activity. There are several complementary techniques that can be used for requirements discovery.
2. Requirements classification and organization
This activity takes the unstructured collection of requirements, groups related requirements, and organizes them into coherent clusters. The most common way of grouping requirements is to use a model of the system architecture to identify sub-systems and to associate requirements with each sub-system.
3. Requirements prioritization and negotiation
Inevitably, when multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation. Usually, stakeholders have to meet to resolve differences and agree on compromise requirements.
4. Requirements specification
The requirements are documented and input into the next round of the spiral. Formal or informal requirements documents may be produced.
The requirements elicitation and analysis is an iterative process with continual feedback from each activity to other activities. The process cycle starts with requirements discovery and ends with the requirements documentation. The analyst’s understanding of the requirements improves with each of the cycle. The cycle ends when the requirements document is complete.
Definition
Requirement elicitation and analysis is concerned with the process of analyzing requirements to:
Detect and resolve conflicts between requirements.
Discover the bounds of the software and how it must interact with its environment.
Elaborate system requirements to derive software requirements.
Problems in elicitation and analysis
Unawareness
Lack of technical knowledge and unawareness of the technical aspects of the system from the stakeholder’s side. Sometimes they may demand unrealistic things and they do not know what they exactly expecting from the system. Stakeholders express their requirements in the most general terms; it is difficult to find the technical aspects of the system from the general terms. Different people expect different services from the proposed system, requirements engineers has to discover the good sources of requirements and commonalities.
Problems in eliciting requirements
Users not sure
Communication gap
Conflicting requirements
Volatile requirements
Communication gap
Even if the end users and stakeholders are clear about the need for developing the new system, they may find it difficult to express it in a concrete manner due to their less exposure to the computing systems. They may state the requirements in an ambiguous or non-testable fashion. Sometimes the obvious basic requirements may be omitted and they concentrate on explaining the peripheral requirements. The system engineer needs to drive the stakeholders in the right direction throughout the requirements gathering stage so that they focus only on the most important requirements.
Conflicting requirements
This problem increases with the number of stakeholders involved in the project. There may be conflicting needs and priorities for each stakeholder based on the business areas they are covering. For example, a stakeholder from the marketing team will try to provide requirements that will expedite the creation or new products, while the end users of the system will look for efficient screens that help easy data capture. During the analysis phase the requirements analyst and the client should collaboratively discuss and resolve any conflicting requirements from multiple stakeholders.
Volatile requirements
Requirements may get changed during the elicitation stage due to the entry of new stakeholders who have different perspectives of the system. Although this is helpful in clarifying the requirements better, it sometimes creates friction between the requirements engineer and the stakeholders due to continuous change in the scope.
Techniques for requirements elicitation and analysis
Once the requirements sources have been identified, the software engineer can start eliciting requirements from them. This topic concentrates on techniques for getting human stakeholders to articulate their requirements. It is a very difficult area and the software engineer needs to be sensitized to the fact that users may have difficulty in describing their needs, may leave important information unstated, or may be unwilling or unable to cooperate. It is particularly important to understand that elicitation is not a passive activity, and that, even if cooperative and articulate stakeholders are available, the software engineer has to work hard to elicit the right information.
Techniques for requirements elicitation and analysis are:
View point oriented elicitation
Scenarios
Interview
Ethnography
Task analysis
Domain analysis
Brainstorming
Questionnaires etc.
1. View point oriented
View point oriented elicitation approach takes different views given by different stakeholders. All complex systems should therefore be analyzed from a number of viewpoints. A key strength of view point oriented analysis is that it recognizes multiple perspective and provides a framework for discovering conflicts in the requirements proposed by different stakeholders. View points can be used as a way of classifying stakeholders and sources of requirements.
There are three generic types of view points:
Interactor view points: Represents people or other systems that interact directly with the system.
Example: In a bank ATM system examples of interactor view points are bank’s customers and bank’s account database.Indirect view points: Represents stakeholders who do not use the system themselves but who influence the requirements in some way.
Example: In the bank ATM system examples of indirect view point are management of the bank and the bank security staff.Domain view points: Represent domain characteristics and constraints that influence the system requirements.
Example: In the bank ATM system an example of a domain view point would be the standards that have been developed for inter banking communication.
2. Scenario
The scenario technique is a requirement elicitation method that involves describing real-world situations in which users interact with the system. It helps stakeholders visualize how the system should behave in different conditions, leading to better understanding and identification of requirements.
3. Interviews
The objective of conducting an interview is to understand the customer’s expectations of the software.
It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and credibility. Interviews may be open-ended or structured.
In open-ended interviews, there is no pre-set agenda. Context-free questions may be asked to understand the problem.
In a structured interview, an agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview.
4. Ethnography
Software systems do not exist in isolation—they are used in a social and organizational context, and software system requirements may be derived or constrained by that context. Satisfying these social and organizational requirements is often critical for the success of the system. One reason why many software systems are delivered but never used is that they do not take proper account of the importance of these requirements.
Definition
“Ethnography is an observational technique that can be used to understand social and organizational requirements.”
In ethnography, a group of people are studied in their natural settings. The users’ requirements can be well understood by participating in their day-to-day activities for a certain period of time.
The difference between the assumed work and the actual work is most important. Thus, the ethnography is particularly effective at discovering two types of requirements:
Requirements that are derived from the way in which people actually work rather than the way in which definitions say ought the work.
Requirements that are derived from cooperation and awareness of other people’s activities.
Ethnography may be combined with prototyping. The following diagram shows the process of requirement analysis which combines ethnography and prototyping.
5. Task analysis
Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected.
6. Domain analysis
Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements.
7. Brainstorming
An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.
8. Questionnaires
A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled.
Requirements specification
Requirements collected get transformed into structured SRS document. It defines the requirements of the proposed system. The requirement consists of end user’s crude requirements and detailed description of the system requirement. It focuses on the functionality of the system.
Specification is very important as it clearly indicates what the requirements, to develop the project are.
Requirements specification adds on further information to the requirements definition.
Specification is presented with the system models, useful for designing the software. It includes all the specification and constraints on the operations of the system.
Requirement specification methods
There are five different specification methods:
Structured natural language: Defining standard form or template to express the requirement specification using natural language.
Design description language: This method concentrates on operations and constraints of the system. It makes use of programming languages with more abstract features.
Requirement specification language: Various special purpose languages have been designed to express software requirement such as PSL/PSA, Problem Statement Language (PSL), Problem Statement Analyzer (PSA). The advantages of this is special purpose tool support can be developed.
Graphical notations: Best known graphical notation for requirement is SADT. Structured Analysis and Design Technique. It has many complex graphical vocabulary and is mostly used by specialists. Graphical notations help the analyst to read and understand the requirement quickly.
Mathematical specifications: These notations based on formal mathematical concept such as finite state machine or more basic concept such as sets.