+1443 776-2705 panelessays@gmail.com

 

3. In "The World and the Machine (Links to an external site.)", Jackson lists "four kinds of denial"—reasons why software engineers are inclined to pay more attention to the machine than the world. Do modern requirements elicitation approaches (see Requirements Elicitation: A Survey of Techniques, Approaches, and Tools) or formalization (see: Deriving Specifications from Requirements: an Example) address these kinds of denial? Are RAMP requirements about the world or the machine? How does this relate to software engineering paying more attention to the machine than the world?

2 Requirements Elicitation: A Survey of Techniques, Approaches, and Tools

Didar Zowghi and Chad Coulin

Abstract: Requirements elicitation is the process of seeking, uncovering, acquir- ing, and elaborating requirements for computer based systems. It is generally un- derstood that requirements are elicited rather than just captured or collected. This implies there are discovery, emergence, and development elements to the elicita- tion process. Requirements elicitation is a complex process involving many ac- tivities with a variety of available techniques, approaches, and tools for perform- ing them. The relative strengths and weaknesses of these determine when each is appropriate depending on the context and situation. The objectives of this chapter are to present a comprehensive survey of important aspects of the techniques, ap- proaches, and tools for requirements elicitation, and examine the current issues, trends, and challenges faced by researchers and practitioners in this field.

Keywords: requirements, elicitation, techniques, approaches, tools, issues, chal- lenges, trends, survey.

2.1 Introduction

The importance of requirements engineering (RE) within software systems deve l- opment has long been established and recognized by researchers and practitioners alike (Chapter 1). The elicitation of requirements represents an early but continu- ous and critical stage in the development of software systems. The requirements for a software system may be spread across many sources. These include the prob- lem owners, the stakeholders, documentation, and other existing systems. Because of the communication rich nature of requirements elicitation activities, many of the effective techniques do not originate from the traditional areas of software en- gineering or computer science research. Techniques for requirements elicitation are derived mostly from the social sciences, organizational theory, group dynam- ics, knowledge engineering, and very often from practical experience.

The process of requirements elicitation is generally accepted as one of the criti- cal activities in the RE process. Getting the right requirements is considered as a vital but difficult part of software development projects [36]. A recent field study of fifteen RE teams carried out by Hofmann and Lehner [31] identified key RE practices that should lead to project success. Effective elicitation of requirements was arguably among the most important of the resulting recommended good RE practices.

Requirements elicitation itself is a very complex process involving many activi- ties, with multiple techniques available to perform these activities. The multi-

disciplinary nature of requirements elicitation only adds to this complexity. Elici- tation is subject to a large degree of error, influenced by key factors ingrained in communication problems. Despite the importance of requirements elicitation within software development, insufficient attention has been paid to this area in industry and software engineering research to date.

In reality requirements elicitation is a multifaceted and iterative activity that re- lies heavily on the communication skills of requirements engineers and the com- mitment and cooperation of the system stakeholders. One of the main problems facing software development project teams is communication barriers and agree- ment about the requirements. The main point is that concepts that are clearly de- fined to one community of participants can be entirely opaque to members of an- other. The fact that this situation exists often goes unnoticed in the course of elicitation unless specific attention is paid to the problem.

The type of the system and the purpose of the project significantly affect the way in which requirements elicitation is conducted. For example it can be said that the method employed for a custom built embedded control system is likely to be substantially different to that of a commercially available inventory management system. The elicitation of requirements can be performed in a variety of settings including the development of web based information systems (Chapter 15) and market driven product lines (Chapter 13), the implementation of large enterprise systems, the selection of commercial off the shelf products (COTS), and the main- tenance of existing and legacy systems. Furthermore project teams may be spread across different geographical locations and from diverse cultural backgrounds. The specific elicitation techniques used for a particular situation often depend on a variety of additional factors including time and cost, the availability of resources, the safety criticality of the system, and any legal or regulatory constraints.

In this chapter we present the state of the art and practice in requirements elicita- tion through an extensive review and analysis of the relevant literature bearing in mind the interdisciplinary and practical nature of this important activity. The aim is to inform the reader of the strengths and weaknesses of some of the current techniques, approaches, and tools used in requirements elicitation today.

The chapter is structured as follows: Section 2.2 introduces the process of re- quirements elicitation, the activities associated with it, and the roles performed during elicitation by the analyst. Section 2.3 surveys a wide variety of techniques and approaches used for requirements elicitation, and includes a comparison of these with respect to each other and the activities they are used for. Section 2.4 provides some examples of methodology based requirements elicitation, and Sec- tion 2.5 presents the types of available tool support for this process. Section 2.6 describes some of the most common issues and pitfalls experienced during re- quirements elicitation, and Section 2.7 is dedicated to the current trends and chal- lenges in this field. Section 2.8 offers some suggestions for future directions in re- quirements elicitation research, and finally Section 2.9 contains a brief summary of the chapter.

2.2 What is Requirements Elicitation?

Currently there is very little uniformity in RE research and practice concerning a standard definition for requirements elicitation. Requirements elicitation is all about learning and understanding the needs of users and project sponsors with the ultimate aim of communicating these needs to the system developers. A substan- tial part of elicitation is dedicated to uncovering, extracting, and surfacing the wants of the potential stakeholders. Robertson and Robertson [54] refer to this process as “trawling for requirements” to highlight the fact that through this proc- ess you are likely to get more requirements than expected. This implies that gath- ering a few extraneous requirements initially is always better than gathering less. This is one of the reasons why prioritization (Chapter 4) and negotiation (Chapter 7) are important parts of RE, especially within market driven RE (Chapter 13) where an overload from the constant influx of large amounts of requirements is a serious issue (Chapter 10). More recently the concepts of inventing and creating requirements have been used to highlight the role of creativity and to emphasize what really goes on during requirements elicitation [43].

2.2.1 The Process of Requirements Elicitation

The requirements elicitation process involves a set of activities that must allow for communication, prioritization, negotiation, and collaboration with all the relevant stakeholders. It must also provide strong foundations for the emergence, discov- ery, and invention of requireme nts as part of a highly interactive elicitation proc- ess. Requirements elicitation involves activities that are intensely communicative. These activities increase in significance when one considers the “culture gap” [62] or basic semantic differences dividing the problem owning and the problem solv- ing communities when attempting to engage in meaningful dialogue [7].

Once again there is very little uniformity in the research literature and practice concerning the names given to the activities often performed during requirements elicitation. However what is generally accepted is that elicitation is the initial stage within the RE process albeit an iterative and integrated one. Typical activi- ties of the requirements elicitation process can be divided into five fundamental types as described below: • Understanding the application domain – It is important when beginning the

process of requirements elicitation to investigate and examine in detail the situation or “real world” in which the system will ultimately reside (some- times called the application domain) [34, 68]. The current environment needs to be thoroughly explored including the political, organizational, and social aspects related to the system, in addition to any constraints they may enforce upon the system and its development. Existing work processes and the related problems to be solved by the system need to be described with respect to the key business goals and issues.

• Identifying the sources of requirements – Requirements may be spread across many sources and exist in a variety of formats [41]. In all software de- velopment projects a number of possible sources for requirements may be identified. Stakeholders represent the most obvious source of requirements for the system. Users and subject matter experts are used to supply detailed in- formation about the problems and user needs. Existing systems and processes represent another source for eliciting requirements, particularly when the pro- ject involves replacing a current or legacy system. Existing documentation about the current systems and business processes including manuals, forms, and reports can provide useful information about the organization and envi- ronment, as well as requirements for the new system and their supporting ra- tionale and importance.

• Analyzing the stakeholders – Stakeholders are people who have an interest in the system or are affected in some way by the development and implemen- tation of the system and hence must be consulted during requirements elicita- tion. Typically stakeholders include groups and individuals internal and ex- ternal to the organization. The customer, and more specifically the project sponsor, is usually the most apparent stakeholder of the system. In some cases however the actual users of the system may be the most important. Other par- ties whose sphere of interest may extend to some part of the system opera- tions, such as those responsible for work process standards, customers, and partners, should also be regarded as stakeholders if affected. One of the first steps in requirements elicitation therefore is to analyze and involve all the relevant stakeholders. An extensive list of potential project stakeholders that should be consulted during this activity is available in the literature (e.g. [3, 54]). The process of analyzing the stakeholders also often includes the identi- fication of key user representatives and product champions.

• Selecting the techniques, approaches, and tools to use – Although some may advocate that just one elicitation technique or a single methodology is sufficient and may be applied to all cases, it is generally accepted that an in- dividual requirements elicitation technique or approach cannot possibly be suitable for all projects. The choice of techniques to be employed is depend- ent on the specific context of the project and is often a critical factor in the success of the elicitation process [48]. Hickey and Davis [28, 29] have inve s- tigated the elicitation technique selection and state that a particular elicitation technique may be selected for a variety of reasons. These include (a) the tech- nique selected is the only one the analyst knows, (b) the technique selected is the analyst’s favorite, (c) the selected technique is the one prescribed by a specific methodology that is being followed for the system development, and (d) the choice of technique is governed solely by the intuition of the analyst to be effective in the current context. Clearly requirements elicitation is best per- formed using a variety of techniques. In the majority of projects several methods are employed during and at different stages in the software develop- ment life cycle, often in cooperation where complementary.

• Eliciting the requirements from stakeholders and other sources – Once the sources of requirements and the specific stakeholders have been identi-

fied, then begins the actual elicitation of the core requirements using the se- lect elicitation techniques, approaches, and tools. During this activity it is im- portant to establish the level of scope for the system and investigate in detail the needs and wants of the stakeholders, especially the users. It is also essen- tial to determine the future processes the system will perform with respect to the business operations, and examine the ways in which the system may sup- port them in order to satisfy the major objectives and address the key prob- lems of the business.

It is important to remember that requirements elicitation does not occur in a

vacuum. It is strongly related to the context in which it is conducted and specific characteristics of the project, organization, and environment [11]. In practice the budget and schedule of the project have a significant effect on the process and the way in which it is performed. The structure and maturity of the organization will determine how requirements are elicited, as will the way in which the system will interact with users and other systems. The level of volatility within a project must also be considered, as this will directly affect the quality of requirements and the elicitation process itself.

Typically the process begins with an informal and incomplete high-level mis- sion statement for the project [69]. This may be represented by a set of fundamen- tal goals, functions, and constraints for the target system, or as an explanation of the problems to be solved. In order to develop this description, stakeholders and other sources of requirements are identified and used for elicitation. These pre- liminary results form the basis of further investigation and refinement of require- ments in a typically iterative and incremental manner.

Over the years a number of process models have been proposed for require- ments elicitation [13, 39, 58]. For the most part these models provide only a ge- neric roadmap of the process with sufficient flexibility to accommodate the basic contextual differences of individual projects. The inability of these models to pro- vide definitive guidelines is a result of the wide range of task that may be per- formed during requirements elicitation, and the sequence of those activities being dependent on specific project circumstances. The variety of issues that may be faced and the number of techniques available to use only makes it more complex.

In most cases the process of requirements elicitation is performed incrementally over multiple sessions, iteratively to increasing levels of detail, and at least par- tially in parallel with other system development activities. In reality its completion is often determined by time and cost constraints rather than achieving the required level of requirements quality and completeness. Typically the result of this process is a detailed set of requirements in natural language text and simple diagrammatic representations with additional information including descriptions of the sources, priorities, and rationales.

2.2.2 Roles of the Requirements Engineer during Elicitation

During requirements elicitation the requirements engineer (also sometimes re- ferred to as the systems analyst or business analyst) may play a variety of roles and assume different responsibilities. These responsibilities and roles are depend- ent on the project, people, context and organization involved. A substantial part of elicitation involves exploring the problem domain and the requirements that are situated in that domain. Furthermore the requirements engineers often need to per- form some typical aspects of project management. Not only do they have to man- age the process of elicitation, but they also have to communicate it effectively to the stakeholders. This involves among other things, decision-making (Chapter 12), prioritization (Chapter 4), and negotiation (Chapter 7).

Requirements engineers often play the important role of facilitator. When elicit- ing requirements by group work sessions, they are not only required to ask ques- tions and record the answers, but must guide and assist the participants in address- ing the relevant issues in order to obtain correct and complete requirements information. They are also responsible for ensuring that participants feel comfort- able and confident with the process, and are given sufficient opportunity to con- tribute. This role represents a significant part of the skill and expertise required by the analyst in order to perform effective requirements elicitation.

During elicitation conflicts between elicited requirements and stakeholders themselves are inevitable. In many cases the prioritization of requirements from different stakeholders groups is a source of much debate and dispute. When these situations occur the analyst is often playing the role of a mediator and is respons i- ble for finding a suitable resolution through negotiation and compromise. It is im- portant that the analyst is sensitive to all the political and organizational aspects of the project when mediating discussions related to the system.

Frequently requirements engineers are responsible for documenting the re- quirements elicited. This role is particularly important as it represents the produc- tion of results from the elicitation process, and forms the foundation for the subse- quent project phases. Evaluation of the elicitation process and the work performed by the analyst is based on these resultant artifacts, which in some cases may form the basis of contractual agreements.

Analysts are often required to assume the various roles of the developer com- munity during requirements elicitation. This includes system architects, designers, programmers, testers, quality assurance personnel, implementation consultants, and system maintenance administrators. This is often due to the fact that these stakeholders have not yet been assigned to the project at the requirements elicita- tion stage. Despite this the decisions made during this phase of the project will significantly affect these stakeholders and the subsequent phases of development.

All the requirements elicited must be validated against the other stakeholders, other systems, each other, and then compared with previously established goals for the system. By this it is meant that the requirements describe the desired fea- tures of the system appropriately, and that those requirements will provide the necessary functions in order to fulfill the specified objectives of the target system.

This process typically involves all the identified stakeholder groups, and results in further elicitation activities.

2.3 Techniques and Approaches for Requirements Elicitation

For over two decades now much of the research and practice within RE for soft- ware systems has been largely directed towards improving the complex process known as elicitation through the application and development of various tech- niques, approaches, and tools. Many of these methods have been borrowed and adapted from other disciplines such as the social sciences, and only a select few have been developed specifically for eliciting software requirements [14].

It is important to explain what we mean by the terms “technique” and “ap- proach” as for each of them there exists a number of different uses for them in practice and multiple definitions in the literature. A “technique” is a way of doing something or a practical method applied to some particular task. An “approach” on the other hand is a systematic arrangement, usually in steps, of ideas or actions intended to deal with a problem or situation.

In reality there are literally hundreds of different techniques and approaches from a variety of sources that can and have been employed for requirements elici- tation. Below we present only some of those that are more widely used. Although not exhaustive, we believe this selection is representative of the range described in the literature and practiced in industry today.

Interviews Interviews [1, 32] are probably the most traditional and commonly used technique for requirements elicitation. Because interviews are essentially human based social activities, they are inherently informal and their effectiveness depends greatly on the quality of interaction between the participants. Interviews provide an efficient way to collect large amounts of data quickly. The results of interviews, such as the usefulness of the information gathered, can vary significantly depending on the skill of the interviewer [23]. There are fundamentally three types of interviews be- ing unstructured, structured, and semi-structured, the latter generally representing a combination of the former two.

Unstructured interviews are conversational in nature where the interviewer en- forces only limited control over the direction of discussions. Because they do not follow a predetermined agenda or list of questions, there is the risk that some top- ics may be completely neglected. It is also a common problem with unstructured interviews to focus in too much detail on some areas, and not enough in others [45]. This type of interview is best applied for exploration when there is a limited understanding of the domain, or as a precursor to more focused and detailed struc- tured interviews.

Structured interviews are conducted using a predetermined set of questions to gather specific information. The success of structured intervi ews depends on knowing what are the right questions to ask, when should they be asked, and who

should answer them. Templates that provide guidance on structured interviews for requirements elicitation such as Volere [54] can be used to support this technique. Although structured interviews tend to limit the investigation of new ideas, they are generally considered to be rigorous and effective.

Questionnaires Questionnaires [21] are mainly used during the early stages of requirements elici- tation and may consist of open and/or closed questions. For them to be effective, the terms, concepts, and boundaries of the domain must be well established and understood by the participants and questionnaire designer. Questions must be fo- cused to avoid gathering large amounts of redundant and irrelevant information. They provide an efficient way to collect information from multiple stakeholders quickly, but are limited in the depth of knowledge they are able to elicit. Ques- tionnaires lack the opportunity to delve further on a topic, or expand on new ideas. In the same way they provide no mechanism for the participants to request clarifi- cation or correct misunderstandings. Generally questionnaires are considered more useful as informal checklists to ensure fundamental elements are addressed early on, and to establish the foundation for subsequent elicitation activities.

Task Analysis Task analysis [9, 53] employs a top-down approach where high-level tasks are de- composed into subtasks and eventually detailed sequences until all actions and events are described. The primary objectives of this technique is to construct a hi- erarchy of the tasks performed by the users and the system, and determine the knowledge used or required to carry them out. Task analysis provides information on the interactions of both the user and the system with respect to the tasks as well as a contextual description of the activities that take place. In most cases consider- able effort is required to perform thorough task analysis, and it is important to es- tablish what level of detail is required and when components of the tasks need to be explorer further.

Domain Analysis Examining the existing and related documentation and applications is a very use- ful way of gathering early requirements as well as understanding and capturing domain knowledge, and identification of reusable concepts and components. These types of investigations are particularly important when the project involves the replacement or enhancement of an existing legacy system. Types of documen- tation that may be useful for eliciting requirements include design documents and instruction manuals for existing systems, and hardcopy forms and files used in the current business processes. Application studies often also include looking at both upstream and downstream systems, as well as competitive or like solutions. In most cases these studies involve other elicitation techniques such as observi ng the exiting system in use and interviewing the current users.

Domain knowledge in the form of detailed descriptions and examples plays an important part in the process of requirements elicitation. Approaches based on this

type of information are often used in conjunction with, and as the input to other elicitation techniques. For example analysts use previous experience in similar domains as a discussion template for facilitating group work and conducting inter- views. Analogies and abstractions of existing problem domains can be used as baselines to acquire specific and detailed information, identify and describe possi- ble solution systems, and assist in creating a common understanding between the analyst and stakeholders. These approaches also provide the opportunity to reuse specifications and validate new requirements against other domain instances [61]. Problem Frames [35] in particular provide a method for detailed problems exami- nation in order to identify patterns that could provide links to potential solutions.

Introspection The technique of introspection [23] requires the analyst to develop requirements based on what he or she believes the users and other stakeholders want and need from the system. Despite being employed by most analysts to some extent, this technique is mainly used only as a starting point for other requirements elicitation efforts. Introspection is only really effective when the analyst is not only ve ry fa- miliar with the domain and goals of the system, but also expert in the business processes performed by the users. In cases where the analyst is forced to use this technique more, for example when the users have little or no previous experience with software systems in their work environment, a type of facilitation introspec- tion should take place via other elicitation techniques such as interviews and pro- tocol analysis.

Repertory Grids Repertory grids [38] involve asking stakeholders to develop attributes and assign values to a set of domain entities. As a result the system is modeled in the form of a matrix by categorizing the elements of the system, detailing the instances of those categories, and assigning variables with corresponding values to each one. The aim is to identify and represent the similarities and differences between the different domain entities. These represent a level of abstraction unfamiliar to most users. As a result this technique is typically used when eliciting requirements from domain experts. Although more detailed than card sorting, and to a lesser degree laddering, repertory grids are somewhat limited in their ability to express specific characteristics of complex requirements.

Card Sorting Card sorting requires the stakeholders to sort a series of cards containing the names of domain entities into groups according to their own understanding. Fur- thermore the stakeholder is required to explain the rationale for the way in which the cards are sorted. It is important for effective card sorting that all entities are in- cluded in the process. This is possible only if the domain is sufficiently understood by both the analyst and the participants. If the domain is not well established then group work can be used to identify these entities. Class Responsibility Collabora- tion (CRC) cards [5] are a derivative of card sorting that is also used to determine

program classes in software code. In this technique cards are used to assign re- sponsibilities to users and components of the system. Because entities represent such a high level of system abstraction, the information obtained from this tech- nique is limited in its detail.

Laddering When using laddering [30] stakeholders are asked a series of short prompting questions, known as probes, and required to arrange the resultant answers into an organized structure. A primary assumption when employing laddering is that the knowledge to be elicited can actually be arranged in a hierarchical fashion. For this technique to be effective, the stakeholders must be able to express their under- standing of the domain and then arrange it in a logical way. This knowledge, which is often displayed using tree diagrams, is reviewed and modified dynami- cally as more is added. Like card sorting, laddering is mainly used as a way to clarify requirements and categorize domain entities.

,

Deriving Specifications from Requirements: an Example

Michael Jackson

AT&T Bell Laboratories

and MAJ Consulting Ltd

101 Hamilton Terrace

London NW89QX England

[email protected] att.com

[email protected]

Abstract

A requirement is a desired relationship among phenomena of the environment of a system, to be

brought about by the hardware/software machine that will be constructed and installed in the environment. A specification describes machine behaviour suffi-

cient to achieve the requirement. A specification is a

restricted kind of requirement all the environment

phenomena mentioned in a specitlcation are shared

with the machinq the phenomena constrained by the speciilcation are controlled by the machine; and the specified constraints can be determined without refer-

ence to the future. Specflcations are derived from re-

quirements by reasoning about the environtnen~ using

properties that hold independently of the behaviour of the machine. These ideas, and some associated tech-

niques of description, are illustrated by a simple ex-

ample.

1 Introduction

Sotisvare development is concerned with the con- struction of machines of a particular kind those that

can be implemented by a general-purpose computer,

which then becomes the desired machine. Many prob-

lems can be solved by these means [Jackson 94], in-

cluding problems in process control, message

switching, text manipulation, decision support, and

other fields. For example, an information system is a

machine that models a r