A Survey on Requirements Elicitation

Contents

1. Introduction

2. Conceptions and Guidelines
2.1 Requirements Elicitation Process Model
2.2 Guidelines for Requirements Elicitation

3. Framework for Understanding Elicitation Approaches
3.1 Problem
3.2 Methods
3.3 People
3.4 Type
3.5 Solution

4. Categorization of Requirements Elicitation Approaches
4.1 Interview-Oriented Approaches
4.2 Objective and Goal-Oriented Approaches
4.3 Viewpoint Analysis-Oriented Approaches
4.4 Scenario Analysis-Oriented Approaches
4.5 Others

5. Related work and Further Readings

6. Conclusions

References

Appendix A

List of Figures

Figure 1: The three dimensions of RE

Figure 2: Requirements elicitation process model

Figure 3: Dimensions of survey

Figure 4: A portion of the KAOS conceptual meta-model

Figure 5: Some concepts of the elevator system

Figure 6: Viewpoint structuring for ATM example

Figure 7: Abstract viewpoint classes

Figure 8: ATM viewpoints

Figure 9: Event scenario for ‘cash withdrawal‘

Figure 10: A portion of KAOS meta-model extended to model scenarios

Figure 11: Architecture entering scenario evaluation phase

Figure 12: Sample requirements discussion for meeting scheduler

List of Tables

Table 1: CTTS achievem. goals, agents, stakeholders, obstacles and scenarios

Table 2: Goal schema model for G7

Table 3: Sample use case

Table 4: Scenarios for ’No conflicts’

Table 5: Summary of numbers of user responses by category

Table 6: Requirements elicitation taxonomy

Table 7: Summary

Abstract

The first step during the software development, requirements engineering, is very critical because of the high effort (in time and costs) that has to be made to correct mistakes detected later that have been made in this early phase of software life-cycle. In order to support the aim of high-quality software, the goals of requirements engineering are developing a complete as possible specification, providing integrated representation for malisms and accomplishing a common agreement on the specification.

The very first activity that has to be passed through is requirements elicitation. There are existing three main problems: the problem of defining the scope, the problem of understanding the users ’ needs and the problem of requirements volatility over time. You can follow several heuristics and guidelines to find solutions to these problems. In addition, several techniques and methodologies have been suggested to support the process of requirements elicitation. They differ in several ways: the kind of problem they intend to solve, the methods used for achieving this aim, the kind of people involved, the level of abstraction and precision the requirements have to be formulated in.

In this report, a selection of these techniques and methodologies is chosen and they are classified into a classification scheme worked out. The techniques and methodologies can coarsely be divided into four classes: interview-oriented approaches, objective and goal analysis-oriented approaches, viewpoint analysis-oriented approaches, and scenario analysis-oriented approaches. There are others that do not fit into this division, but provide nevertheless help for requirements elicitation. The developed classification scheme highlights the differences between the existing techniques. It should serve as an overview of existing techniques and methods as a guideline for analysts and developers for finding an appropriate method for problems at hand.

1. Introduction

The software industry has gained a reputation of not delivering software in time, within budget and with the required quality. Most quality problems are due to failures of the software. Most of these often cost intensive errors are not implementation errors but errors made in the early phase of software life cycle which impact the complete software process. Their identification and correction is a problem that is not trivial.

A recent study of the Standish Group¹ revealed the following figures: 31.1% of software projects will be cancelled before they ever get completed. In the United States, $250 billion are spend each year on IT application development. It is estimated that $81 billion are spend for cancelled software projects. 52.7% of projects cost 189% of their original estimates. For every 100 projects that start, there are 94 restarts. The average overrun of software projects is 222% of the original time esti- mate.

IT executive managers have been surveyed for their opinions about why projects succeed. The Top 3 answers were (in % of responses): user involvement (15.9%), executive management support ( 13.9%), and clear statement of requirements (13.0%). The survey participants were also asked about the factors that cause projects to be challenged. The Top 3 answers were (in % of responses): lack of user input (12.8%), incomplete requirements & specifications (12.3%), and changing requirements & Specifications (11.8%). The Top 3 factors about why projects are impaired and ultimately canceled were (in % of responses): incomplete requirements (13.1%), lack of user involvement (12.4%), and lack of resources (10.6%).

Many errors emerge because of the complexity of the problem. Just in large software projects there is the difficulty of acquiring all requirements that are demanded for the system and to integrate them in the different phases of the development process. Requirements engineering tries to cover this task. It comprises requirements elicitation, negotiation, requirements specification/documen- tation and validation/verification. We will focus on the starting point of requirements engineering, called requirements elicitation, also found in literature as requirements acquisition, requirements definition or requirements analysis (there is no uniform definition of these terms, so they are some- times used with another meaning). We use the two terms ’requirements elicitation’ and ’require- ments acquisition’ interchangeable.

Requirements elicitation is the very first step in the software life cycle. It is defined as ‘the process of acquiring all the relevant knowledge needed to produce a requirements model of a problem do- main‘. This implies that implicit knowledge about the problem domain has to be made explicit in order to bridge the gap between the user/customer and the developer of a (software) system.

Because of the initial character for the software development process (how can we decide how it is done without knowing what should be done?), requirements elicitation is a very critical step. The whole system is build on the specification, the document that is the final representation of the re- quirements. Mistakes made here have their negative impact up to the end of the software process, they are often detected until the complete system is presented to the customer.

There are three main problems that can be identified and which complicate the elicitation step. The first one is the problem of scope which manifests in two ways: On the one hand it is not given that the requirements engineer knows which persons are included in the system in different roles (users, customers, etc.), which each of them has an imagination what the system should do. On the other hand the developer has to know the system’s technical boundaries that can inhibit to fulfil the sta- keholders’ wishes entirely.

The second problem that arises is the problem of understanding because of several reasons. Often users and customers have a vague and incomplete understanding of their needs. The user and de- veloper are both experts in their domain and speak different languages. What can be implicitly clear to one party can be totally unknown to another. Even if it is recognized that some facts have to be stated explicitly, it is not said that the concerned person can articulate it correctly.

The third one is the problem of volatility. Requirements change over time. New requirements can appear due to the dynamics of the development process or vague goals can be clarified during elicitation process. Additionally conflicts between different stakeholders concerning their needs can lead to the change of the requirements.

Beyond, another problem is the lack of formality in expressing users' needs and therefore the dif- ficulty in deciding if everything of importance is grasped correctly. Formal verification cannot be applied to prove consistency between the requirements and their representation in a specification.

These are reasons why many approaches in requirements engineering try to avoid the elicitation step and assume a complete, correct and unambiguous set of requirements what in reality is not given.

Before defining the requirements elicitation process, requirements elicitaion should be put into the broader context of requirements engineering. We follow Pohl‘s three dimensional framework for requirements engineering [Poh96].

The initial input of the requirements engineering process can be characterized by three dimensions: specification, agreement and representation. Typically, the problem is understood opaquely in the beginning. The stakeholders involved in the requirements engineering process have different back- grounds and needs towards the new system, and therefore conflicting and heterogeneous personal views are prevailing. Besides this, the different needs and wishes are expressed using informal lan- guages.

The desired output of the requirements engineering process can also be pictured with the help of the three dimensions: At the end of this process there should be a complete requirements specifi- cation including all possible requirements. Furthermore, a common agreement on the requirements specifying the system functionality should be aspired. Due to the fact that the requirements speci- fication is the input document for system design, requirements have to be expressed formally to support verification and enable automated support for later development stages (e.g., code gener- ation).

Abbildung in dieser Leseprobe nicht enthalten

Figure 1: The three dimensions of RE

The task of requirements engineering can be seen in bridging this gap when opposing the initial input to the desired output. Thus, three main goals can be identified (this process is visualized in figure 1, the curved line could be a possible course of a RE process):

- developing a complete as possible system specification out of an opaque system understanding
- providing integrated representation formalisms and supporting the transformation between them
- accomplishing a sufficient common agreement on the final specification allowing personal views.

According to Pohl there are four tasks of requirements engineering: elicitation, negotiation, spec- ification/documentation, and validation/verification. Elicitation makes knowledge (requirements) about the system explicit and thus leads to a better understanding of the problem. The main influ- ence in the three dimensional framework is the specification dimension. Thus requirements elici- tation can be visualized by the bold line in figure 1. Negotiation makes existing conflicts, argumentations and rationales explicit and assures that the ‘right‘ decisions are made and establi- hes an agreement between the various stakeholders. The main influence is on the agreement dimen- sion. Specification/documentation deals with the representation of existing viewpoints in different representation formats, assures consistency and cross-references between the various representa- tion, and establishes a (partially) formal requirements specification. It stresses the representation dimension. Validation/verification assures that the right problem is being tackled at any time in the process, checks the internal consistency of the specification and controls if the specified require- ments are consistent with the user/customer intentions. All three dimensions are concerned.

There are existing a fair number of approaches that dedicate to the topic of requirements elicitation. It is the aim of this work to present a selection of these approaches and to compare them according to a scheme that will be developed throughout the next chapters. It should serve as characterization for existing approaches and as a guideline what approach fits best for solving the problems in requirements elicitation in a particular case. Perhaps it could be sensible combining a number of these approaches. If deficiencies of existing approaches are uncovered, important aspects that have been neglected so far, it could be a starting point for further research.

In the next chapter, requirements elicitation is introduced by establishing a requirements elicitation process and suggesting several guidelines which should serve as clues for effective requirements acquisition. Chapter 3 presents dimensions for a requirements elicitation taxonomy which are de- rived from the process model and the guidelines. In chapter 4, an overview of existing requirements elicitation methods is given and they are characterized according to the developed scheme. Chapter 5 presents the related literature and further readings. In chapter 6 the approaches are analyzed and conclusions are drawn for further work on this field of research.

2. Conceptions and Guidelines

In this chapter, a common understanding should be given of how the elicitation process can look like and what should be taken into account when eliciting requirements. First a requirements elicitaion process model is developed that defines several steps fundamental for requirements elicitation. In order to give support for practice, some guidelines are presented that can serve as instructions for developers during the elicition process. .

2.1 Requirements Elicitation Process Model

An ideal requirements elicitation process makes sure that the requirements have all desired attributes as defined for instance in the IEEE Recommended Practice for Software Requirements Specification, which defines good software specifications as being [IEE93]:

- Correct

An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet.

- Unambiguous

An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a minimum, this requires that each characteristic of the final product be described using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term should be included in a glossary where its meaning is made more specific.

- Complete

An SRS is complete if, and only if, it includes the following elements:

a) All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements placed by a system specification should be acknowledged and treated.
b) Definition of the responses of the software to all realizable classes of input data in all realizable class of situations. Note that it is important to specify the responses to both valid and invalid input values.
c) Full labels and references to all figures, tables, and diagrams in the SRS and defini- tion of all terms and units of measure.

- Consistent

Consistency refers to internal consistency. If an SRS does not agree with some higher level document, such as a system requirements specification, then it is not correct.

- Ranked for importance and/or stability

An SRS is ranked for importance and/or stability if each requirement in it has an identifier to indicate either the importance or stability of a particular requirement.

- Verifiable

An SRS is verifiable if, and only if, every requirement stated therein is verifiable. A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirment. In general any ambiguous requirement is not verifiable.

- Modifiable

An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style. Modifiability generally requires an SRS to

a) Have a coherent and easy-to-use organization with a table of contents, an index, and explicit cross-referencing
b) Not be redundant; that is, the same requirement should not appear in more than one place in the SRS
c) Express each requirement separately, rather than intermixed requirements.

- Traceable

An SRS is traceable if the origin of each of its requirements is clear and if it faciliates the referencing of each requirement in future development or enhancement documentation. Two types of traceability are recommended.

a) Backward traceability (that is, to previous stages of development). This depends upon each requirement referencing its source in earlier documents.
b) Forward traceability (that is, to all documents spawned by the SRS). This depends upon each requirement in the SRS having a unique name or reference number.

In different approaches the elicitation process is seen varying. Most of them have a subset of the following steps in requirements elicitation process that fulfil the postulate for a good requirements specification:

1. Identify the system environment and the relevant sources of requirements

This is the first step of isolating the system boundaries with regard on the interaction between the system and its environment. Relevant sources can be humans that play different roles as to the software product (user, developer, customer, etc.). Or information can be gathered from documents and forms or from former projects and legacy systems that are similar to the current one.

2. Gather facts and wishes concerning the system

As seen above gathering the facts is one of the problems in requirements elicitation espe- cially if the source of information are humans. In this case a common approach is use of interviews in different forms, ranging from brain storming sessions to questionnaires. But full understanding cannot be guaranteed in this way. The elicitation of indirect knowledge is poorly supported as well as it is not possible to ensure that the interviewee has complete understanding of his needs. The central task is communication, not only in the form of interviews, but also in the form of observations and simulating environments (e.g., prototyping). The people involved in the system’s environment have to express their needs and wishes. Fact gathering from documents is not as critical when performed in a structure way.

3. Structure and document the facts

When information is gathered it is often done in an unstructured way. Considering an open ended interview for example, the analyst has as result a recording of what the inter- viewee said. He first has to extract the essential information and document it in a structured way. This document should include all important activities and data (which are the activities and data without their knowledge the system will not fulfill the require- ments) and is analyzed to be self-consistent. It is high level, integrated in the problem domain and because of its origin in communication with the user stated in user-specific terms.

4. Validate the facts

The facts gained in the previous step have to be validated. The aim of this step is to ensure internal correctness and consistency of the requirements and to support traceabil- ity. This comprises the identification of viewpoints, association of data with activities and persons involved (traceability is simplified), resolution of conflicts, checking consis- tency, ensuring feasibility and keeping cost and schedule conditions. The validation process can produce completely new requirements, can imply the refinement of high level objectives to low level requirements and is an important step for finding non-func- tional requirements.

5. Outline the requirements in an appropriate representation

In order to be able to communicate with the customer/user, you have to chose an appro-priate representation. In this phase the requirements are presented in a more formal way, but understandable for the client. The aim is to support communication to find out if their needs and wishes are really met.

Abbildung in dieser Leseprobe nicht enthalten

Figure 2: Requirements elicitation process model

The process above is iterative. When validating the facts for example, you can recognize that a sta-keholder has not been taken into account and you have to go back to the step 1. New requirements which occurred during validation have to be formulated and documented. If the customer does not agree with some of the requirements outlined in the representation, his needs and wishes have to be gathered anew. In addition, new requirements that are not the result of validation can appear in every phase of the software life cycle and have to be included into elicitation development process. Figure 2 shows the relationships between the particular steps of the process.

When comparing the elicitation process to the requirements engineering process introduced in chapter 1, it can be noticed that the elicitation process model includes a specification phase (step 4) and a validation phase (step 5), whereas these steps occur separately in the requirements engineering process. This is not a contradiction when considering the aim of these steps: in the whole process of requirements engineering, specification and validation apply to an external use as basis for the design phase, whereas specification and validation in requirements elicitation are backward and serve for communication with different stakeholders in order to capture requirements. In addition, the requirements elicitation process only covers one of the three dimensions in Pohl’s requirements engineering model, the specification dimension, whereas agreement and (formal) representation are covered by later phases in requirements engineering.

2.2 Guidelines for Requirements Elicitation

To acquire requirements for the system to be developed, you first must identify the problems that have to be solved. In order to give support for achieving this aim, several guidelines for require- ments elicitation are outlined here. A fairly high number of the steps in requirements elicitation can be supported by these principles and guidelines, particular techniques and methodologies are pre- sented in chapter 4.

The following record comprises 12 general issues that should be taken into account when starting the elicitation process. These guidelines are primarily extracted from [SS97] and reflect good practice. They are a support for the elicitation process and can be related to the first step of the elicitation process model where the system environment is determined.

- Be sensitive to organizational and political considerations

If you have a look on the organizational and political coherencies the system is embedded in, you can get a better understanding for some proposed requirements and can identify important sources of information.

- Identify and consult system stakeholders

A stakeholder is any person who profits in a direct or indirect way from the system. During requirements elicitation you should identify these persons and consult them to detect their requirements.

- Record requirements sources

Due to the fact that requirements can change or are perceived to be ambiguous, it is helpful to know their sources. A requirements source is any stakeholder, group or document who have suggested requirements. Traceability should be established in order to trace back to the requirement’s source more easily.

- Define the system ’ s operating environment

The operating environment defines the host computer and other hardware and software systems that interact with it. Defining it in advance helps avoid installation problems and reveal system constraints.

- Use business concerns to drive requirements elicitation

Business concerns are high-level goals that have to be achieved to make a contribution to the customers who spend money for it and should be documented in order to explain how the system contributes to the overall business objectives. They are more general than the particular business case for the system. Using the concerns for driving requirements elicitation can ensure that the customers’ needs will be met. An approach that follows this guideline is goal and objective analysis (see chapter 4.2).

- Look for domain constraints

Domain constraints are requirements that have their origin in the application domain of the system, e.g. the braking capabilities of a train. You should study and understand them as part of requirements elicitation process. If you do not take them into account, design faults are likely to lead to critical situations when the system is in use.

- Record requirements rationale

Recording requirements rationale helps you understand the reasons why a requirement has been specified. It represents a link between the requirements, the problem, and the source the requirements are derived from.

- Collect requirements from multiple viewpoints

Every person that is affected by the system has its own expectations of it and thus influence the requirements. Examples for such viewpoints are users, managers, developers, and non-human influencing sources as a external database. These viewpoints are important for gathering all necessary information and represent potential sources for requirements (see chapter 4.3).

- Prototype poorly understood requirements

If stakeholders do not fully understand their needs, it can be reasonable to build a demon- stration system in order to explore their real wishes. End-users can experience with this system to refine their ideas about the system requirements. This is the only effective way of creating user interfaces.

- Use scenarios to elicit requirements

Scenarios are examples for a single type of interaction of the system with its environ- ment. End-users can simulate the dynamical behavior using the scenario. It is the most intuitive way for users of expressing their interaction with the system (see chapter 4.4).

- Define operational processes

The aim of a computer system is often to give assistance for business processes (e.g., producing customer reports) or technical activities (e.g., navigating an aircraft). Defining these processes reveals process requirements and requirements constraints.

- Reuse requirements

If it is possible to reuse requirements from another system of the same application area, it saves money and time and reduces the risks of producing requirements that are diffi- cult to handle.

In the following chapters approaches are presented that support elicitation in greater detail. But even without any methodological support it is reasonable to follow these guidelines in order to get a better understanding (and therefore as result a more complete and correct requirements specification) of the problem and its domain.

3. Framework for Understanding Elicitation Approaches

In the past, several approaches were proposed in order to support the requirements elicitation process. Most of them focus on the problem of the interaction and communication between the users/ customers and the software system development team.

Because of the difficulty that the result of requirements elicitation has to be understood by the users/customers, the requirements have to be expressed in their ’language’ or at least in an informal way that is accepted and comprehended. This process of elicitation and presentation of requirements has to be performed manually.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3: Dimensions of survey

An overview of existing requirements elicitation approaches should be given in the following. First some dimensions are elaborated in order to characterize these approaches as follows (see figure 3):

- PROBLEM
- METHODS
- PEOPLE
- TYPE
- SOLUTION

The dimensions for the survey have been worked out during an intensive recherche of literature. Two sorts of approaches have been considered: On the one hand, articles have to be taken into ac- count that give a theoretical overview of the research field of requirements engineering and espe- cially requirements elicitation. One of these papers is [CK92] that was basis for the dimension ‘problem‘. The dimension ‘methods‘ was extracted partially out of [LK95] and [Arm96]. On the other hand, some dimensions arose during the examination of approaches that deal with particular techniques and methodologies for requirements elicitation. The dimension ‘methods‘ was comple- mented when the approaches were tried to be ordered. Hence, several groups emerged that com- pleted this dimension. The dimension ‘people‘ also was the result of the analysis of these approaches. It was seen that different groups of people are involved in the requirements elicitation process. In most cases, the user and the analyst play a central role, in [Hol90] for example, the cus- tomer and developer are included, in [Rum94], experts are seen as a source of information. The dimension ‘type‘ finally was formed out of the cognition that each approach has its own require- ment towards the precision of input. The values for this dimension were motivated by the different concepts of objective and goal analysis and were elaborated in order to pass for a criterion to rate this precision of input.

In the remainder of this section, these dimensions are explained in more detail. First a motivation is given why this dimension has been chosen and thereafter the possible values for the particular dimensions are illustrated. A summary of the dimensions and their possible values can be found in appendix A.

3.1 Problem

As seen in the first chapter, there are three main problems one is faced with when eliciting requirements. It is important to know if these problems (or at least some of them) are covered by the examined approach.

Problems of requirements can be grouped into three categories:

- problems of scope,
- problems of understanding, and
- problems of volatility.

Problems of scope relate to the boundaries of the developed system that are identified. The boundaries should be chosen adequate to the system’s needs, not too wide and not too limited. The organizational aspect determines which and how many people should be involved, the environmental aspect fixes the hardware and software constraints and interface definitions, the project context includes the attributes of different stakeholders and constraints imposed by them.

Understanding of requirements is the central problem in requirements elicitation. People involved in the requirements process have a variety of backgrounds. So they often speak different languages, what is initially clear for one group can be absolutely foreign for another. Especially the difference between customer and developer is an important point. The understanding of the requirements is also made difficult by the large amount of information needed in many software projects. What is more is the fact that even if you can detect implicit information, it often can’t be expressed by the informant.

During the software development process, requirements can change. There are several reasons for this volatility. New requirements during development phase can appear, imprecise requirements can be clarified in a later process step, conflicts among requirements arise that need a new requirements definition for solution, or environment can change.

3.2 Methods

In order to give a first impression which paradigm the considered approach follows, five groups of methods have been identified. The aim of every group is described below.

In the past years, several groups of requirement elicitation methods and approaches have been established. The aim of this dimension should be a coarse distinction into five classes of approaches, although concrete methods can cover more than one class:

- Interviews
- Objective and Goal Analysis
- Viewpoint Analysis
- Scenario Analysis
- Form Analysis

The most intuitive form of gathering information from the customers and users is the interview. It ranges from unstructured and informal techniques like brainstorming and open ended interviews up to structured interviews and questionnaire interviews. Brainstorming can be valuable for ex- tracting new innovative ideas and delivers a number of possible solutions from different partici- pants but has its weakness in the unstructured and informal way of representing the gathered facts.

[...]

---

¹. The figures are taken from the Standish Group and can be found at: http://www.standishgroup.com/chaos.html