Requirements Elicitation

Muhammad Ramzan

mramzan@fui.edu.pk

04/10/23 RE 2

Week 4

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

04/10/23 RE 3

The elicitation of requirements represents an early but continuous and critical stage in the development of software systems.

The requirements for a software system may be spread across many sources. • the problem 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 engineering or computer science research. • Some of the techniques are derived mostly from the social sciences, organizational

theory, group dynamics, knowledge engineering, and very often from practical experience.

04/10/23 RE 4

The process of requirements elicitation is generally accepted as one of the critical activities in the RE process. • but it’s a difficult part of software development

projects.A recent field study of fifteen RE teams

carried out by Hofmann and Lehner 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.

04/10/23 RE 5

Nature of Req. Elicitation activities

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

The multidisciplinary nature of requirements elicitation only adds to this complexity.

In reality requirements elicitation is a multifaceted and iterative activity that relies heavily on the communication skills of requirements engineers and the commitment and cooperation of the system stakeholders.

One of the main problems facing software development project teams is communication barriers and agreement about the requirements.

04/10/23 RE 6

Issues The main concepts which are clearly defined to one

community of participants can be entirely opaque to members of another.

The fact that this situation exists often goes unnoticed in the course of elicitation unless specific attention is paid to the problem.

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.

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.

04/10/23 RE 7

What is Requirements Elicitation?

Very little uniformity in RE research and practice concerning a standard definition for requirements elicitation.

Requirements elicitation is concerned with learning and understanding the needs of users and project sponsors with the ultimate aim of communicating these needs to the system developers.

Robertson and Robertson refer to this process as “trawling for requirements” to highlight the fact that through this process you are likely to get more requirements than expected.

This implies that gathering a few extraneous requirements initially is always better than gathering less.

04/10/23 RE 8

Requirements elicitation- term

The term suggest that the process is a simple knowledge transfer process where req engineers elicit and document existing customer knowledge

In reality, the process is much more complexIt is not a process of ‘fishing’ for requirements The author prefer the term requirements

discovery to reflect the uncertainties

04/10/23 RE 9

Davis (1993) Avoids the term elicitation and equates this discovery

process to a process of problem analysis and understanding.

Problem analysis is defined as the activity that encompasses learning about the problem to be solved (often through brainstorming and/or questioning), understanding the needs of potential users, trying to find out who the user really is and understanding all the constraints on the solution

But this implies that the activity is only concerned with understanding the details of a specific problem which requires some kind of systems solution

04/10/23 RE 10

Dimensions of requirements elicitation by Kotonya and Sommerville (1998)

Applicationdomain

Stakeholderneeds andconstraints

Problem to besolved

Businesscontext

04/10/23 RE 11

Elicitation activities

Application domain understanding

• Application domain knowledge is knowledge of the general area where the system is applied.

Problem understanding

• The details of the specific customer problem where the system will be applied must be understood.

Business understanding

• You must understand how systems interact and contribute to overall business goals.

Understanding the needs and constraints of system stakeholders

• You must understand, in detail, the specific needs of people who require system support in their work.

04/10/23 RE 12

Requirements Elicitation Techniques

Interviewing and questionnaires Requirements workshops Brain Storming and idea reduction Storyboards Use Cases Role Playing Prototyping

04/10/23 RE 13

Technique: Interviewing

Simple direct technique Context-free questions can help achieve bias-free

interviews Then, it may be appropriate to search for undiscovered

requirements by exploring solutions. Convergence on some common needs will initiate a

“requirements repository” for use during the project. A questionnaire is no substitute for an interview.

04/10/23 RE 14

Technique: Requirements Workshop

The requirements workshop is perhaps the most powerful technique for eliciting requirements.

It gathers all keykey stakeholders together for a short but intensely focused period.

The use of an outside facilitator experienced in requirements management can ensure the success of the workshop.

Brainstorming is the most important part of the workshop.

04/10/23 RE 15

Technique: Brainstorming

Brainstorming involves both idea generation and idea reduction.

The most creative, innovative ideas often result from combining, seemingly unrelated ideas.

Various voting techniques may be used to prioritize the ideas created.

Although live brainstorming is preferred, web-based brainstorming may be a viable alternative in some situations

04/10/23 RE 16

Rules for Brainstorming

Do not allow criticism or debate. Let your imagination soar Generate as many ideas as possible Mutate and combine ideas Idea Reduction

• Pruning ideas that are not worthy of further discussion

• Grouping of similar ideas into one super topic

Prioritize the remaining ideas

04/10/23 RE 17

Storyboarding The purpose of storyboarding is to gain an early

reaction from the users on the concepts proposed for the application.• Storyboards offer an effective technique for addressing the

"Yes, But" syndrome.

Storyboarding• Is extremely inexpensive

• Is user friendly, informal, and interactive

• Provides an early review of the user interfaces of the system

• Is easy to create and easy to modify

04/10/23 RE 18

Technique: Storyboarding

Storyboards identify the players, explain what happens to them, and describes how it happens.

Make the storyboard sketchy, easy to modify, and unshipable.

Storyboard early and often on every project with new or innovative content.

04/10/23 RE 19

Storyboarding Types

04/10/23 RE 20

Technique: Use Cases

Use Cases, like storyboards, identify the who, what, and how of system behavior.

Use Cases describe the interactions between a user and a system, focusing on what they system “does” for the user.

The Use Case model describes the totality of the systems functional behavior.

Early stages: After you have an overview of the use cases, perhaps only by a phrase apiece, expand 10% of them in detail.

04/10/23 RE 21

Technique: Role Playing – variant on use cases Role playing allows stakeholders to experience

the user’s world from the user’s perspective. A scripted walkthrough may replace role

playing in some situations, with the script becoming a live storyboard.

(Class-Responsibility-Collaboration (CRC) cards, often used in object-oriented analysis, are a derivative of role playing.)

04/10/23 RE 22

Technique: Prototyping Prototyping is especially effective in addressing

the “Yes, But” and the “Undiscovered Ruins” syndromes.

A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements.

Prototype the “fuzzy” requirements: those that, although known or implied, are poorly defined and poorly understood.

04/10/23 RE 23

Effective Requirements Elicitation

Is very important because if the customer’s real requirements are not discovered, they are unlikely to be satisfied with the final system

Requirements engineers faced some problems in req elicitation inherent to the multi-dimensional nature of req elicitation

04/10/23 RE 24

Problems of requirements elicitation can be grouped into three categories (Christel & Kang, 1992):

problems of scope, in which the requirements may address too little or too much information;

problems of understanding, within groups as well as between groups such as users and developers; and

problems of volatility, i.e., the changing nature of requirement

04/10/23 RE 25

PROBLEMS OF SCOPE

• the boundary of the system is ill-defined

• unnecessary design information may be given

04/10/23 RE 26

PROBLEMS OF UNDERSTANDING

• 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

• conflicting views of different users

• requirements are often vague and untestable, e.g., “user friendly” and “robust”

04/10/23 RE 27

PROBLEMS OF VOLATILITY

• requirements evolve over time

04/10/23 RE 28

MAIN ACTIVITIES IN RE

Typical activities of the requirements elicitation process can be divided into five fundamental types as described below:

(1) 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 (sometimes called the application domain)

• 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.

04/10/23 RE 29

(2) Identifying the Sources of Requirements – • Requirements may be spread across many sources and

exist in a variety of formats.• Stakeholders represent the most obvious source of

requirements for the system. • Users and subject matter experts are used to supply

detailed information about the problems and user needs. • Existing systems and processes represent another source

for eliciting requirements, particularly when the project 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 environment, as well as requirements for the new system and their supporting rationale and importance.

04/10/23 RE 30

Analyzing the Stakeholders – • Stakeholders are people who have an interest in the system or are

affected in some way by the development and implementation of the system and hence must be consulted during requirements elicitation.

• Typically stakeholders include groups and individuals internal and external 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. For Example….?

• Other parties whose sphere of interest may extend to some part of the system operations, 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.

• The process of analyzing the stakeholders also often includes the identification of key user representatives and product champions.

04/10/23 RE 31

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 individual requirements elicitation technique or approach cannot possibly be suitable for all projects.

• The choice of techniques to be employed is dependent on the specific context of the project and is often a critical factor in the success of the elicitation process .

04/10/23 RE 32

• Hickey and Davis have investigated the elicitation technique selection and stated that a particular elicitation technique may be selected for a variety of reasons. • (a) the technique 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 performed using a variety of techniques. In the majority of projects several methods are employed during and at different stages in the software development life cycle, often in cooperation where complementary.

04/10/23 RE 33

Eliciting the Requirements from Stakeholders and Other Sources –

Once the sources of requirements and the specific stakeholders have been identified, the actual elicitation of the core requirements then begins using the selected elicitation techniques, approaches, and tools.

During this activity it is important 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 essential to determine the future processes the system will perform with respect to the business operations, and examine the ways in which the system may support them in order to satisfy the major objectives and address the key problems of the business.

04/10/23 RE 34

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 .

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

04/10/23 RE 35

Requirements Elicitation Activities

Identifying Actors Identifying Scenarios Identifying Use Cases Refining Use Cases Identifying Relationships between Actors

and Use Cases Identifying Initial Analysis Objects Identifying Nonfunctional Requirements

04/10/23 RE 36

Identifying Actors Actors – person or machine using the system in a particular role Actors usually correspond to existing roles within the client

organization Related roles can be grouped together according to viewpoints Guide Questions

• Which user groups are supported by the system to perform their work?

• Which user groups execute the system’s main functions?

• Which user groups perform secondary functions, such as maintenance and administration?

• With what external hardware or software system will the system interact?

04/10/23 RE 37

Identifying Scenarios Scenario

• “A narrative description of what people do and experience as they try to make use of computer systems and applications” [Carrol, Scenario-based Design, 1995]

• Informal description of a single feature from the viewpoint of a single actor

Types of Scenarios• As-is scenarios – describes current situation

• Visionary scenarios – describes future system

• Evaluation scenarios – describes user tasks for evaluating the system (acceptance criteria)

• Training scenarios – introduces new users to the system

04/10/23 RE 38

Heuristics for Identifying Scenarios Ask yourself or the client the following questions:

• What are the primary tasks that the system needs to perform?

• What data will the actor create, store, change, remove or add in the system? Who else can modify this data?

• What external changes does the system need to know about?

• What changes or events will the actor of the system need to be informed about?

However, don’t rely on questionnaires alone. Insist on task observation (ethnography) if the system

already exists• Ask to speak to the end user, not just to the software contractor

• Expect resistance and try to overcome it

04/10/23 RE 39

Identifying Use Cases

Use Case• Specifies all possible scenarios for a given functionality

• Initiated by an actor Motivations for use cases

• Generalizing related scenarios help developers define the scope of the system

• The role of each user of the system is clarified Use Case Descriptions

• Entry and exit conditions

• Flow of events

• Quality requirements

04/10/23 RE 40

Heuristics: How do I find use cases?

Select a narrow vertical slice of the system (i.e. one scenario) • Discuss it in detail with the user to understand the user’s

preferred style of interaction Select a horizontal slice (i.e. many scenarios) to define

the scope of the system. • Discuss the scope with the user

Use illustrative prototypes (mock-ups) as visual support Find out what the user does

• Task observation (Good)

• Questionnaires (Bad)

04/10/23 RE 41

Order of steps when formulating use cases First step: name the use case

• Use case name: ReportEmergency

Second step: Find the actors• Generalize the concrete names (“Bob”) to participating actors

(“Field officer”)

• Participating Actors:

• Field Officer (Bob and Alice in the Scenario)

• Dispatcher (John in the Scenario)

Third step: Then concentrate on the flow of events• Use informal natural language

04/10/23 RE 42

Identifying Use Cases

Writing Guide• Choose proper name – use verb phrases; indicate user’s

objective

• Name actors with noun phrases

• Clearly distinguish actors’ actions from system’s actions

• Use active voice to phrase steps in flow of events

• The causal relationship between steps should be clear

• Describe complete user transaction

• Describe exceptions separately

• Do not describe the user interface

• Use cases should not exceed 2-3 pages – break up using <<include>> and <<extends>> relationships

04/10/23 RE 43

Relationships Between Actors and Use Cases Relationships between actors and use cases

• <<initiate>>• <<participate>>• Determines access rights

• Who can initiate a functionality• Who else is involved in this functionality

Relationships between use cases• Heuristics for making use cases shorter and simpler to understand• <<include>>

• For factoring out common functionality• Explicitly invoked from the including use case

• <<extend>>• For specifying exceptions• Entry conditions of the extending use case determine when it is used

• Caveat: use discretion when applying these decompositions (a few longer use cases are sometimes easier to understand than many short ones)

04/10/23 RE 44

<<Include>>: Functional Decomposition Problem:

• A function in the original problem statement is too complex to be solvable immediately

Solution: • Describe the function as the aggregation of a set of simpler

functions. The associated use case is decomposed into smaller use cases

ManageIncident

CreateIncident HandleIncident CloseIncident

<<include>>

04/10/23 RE 45

<<Include>>: Reuse of Existing Functionality Problem:

• There are already existing functions. How can we reuse them? Solution:

• The include association from a use case A to a use case B indicates that an instance of the use case A performs all the behavior described in the use case B (“A delegates to B”)

Example: • The use case “ViewMap” describes behavior that can be used

by the use case “OpenIncident” (“ViewMap” is factored out)

ViewMapOpenIncident

AllocateResources

<<include>>

<<include>>

Base UseCase

SupplierUse Case

Note: The base case cannot exist alone. It is always called with the supplier use case

04/10/23 RE 46

<Extend>> Association for Use Cases Problem:

• The functionality in the original problem statement needs to be extended.

Solution: • An extend association from a use case A to a use case B indicates

that use case B is an extension of use case A. Example:

• The use case “ReportEmergency” is complete by itself , but can be extended by the use case “ConnectionDown” for a specific scenario in which the user cannot communicate with the dispatcher

ReportEmergency

FieldOfficerfConnectionDown

<<extend>>

Note: The base use case can be executed without the use case extension in extend associations.

04/10/23 RE 48

Identifying Initial Analysis ObjectsTop Level Use Case

A and Bare called

ParticipatingObjects

Level 1

A B

Level 3 Use Cases Level 3 Level 3 Level 3

Operations Level 4 Level 4

Level 2 Use Cases Level 2 Level 2

04/10/23 RE 49

Use Cases can be used by more than one object

Top Level Use Case

Level 2 Use Cases

Level 3 Use Cases

Operations

ParticipatingObjects

Level 2

Level 1

Level 2

Level 3 Level 3

Level 4 Level 4

Level 3

A B

04/10/23 RE 50

Identifying Initial Analysis Objects Identify the participating objects to create the initial analysis object

model Maintaining glossary of objects minimizes potential confusion in

terminology between users and developers Heuristics

• Terms the needed clarification (by developer or user)• Recurring nouns in use cases• Real-world entities and resources that system must track• Use cases• Data sources or sinks• Artifacts with which user interacts• Use application domain terms

Cross-check• Eliminate ambiguity: verify that objects with the same name refer to the same

concept• Maintain consistency: verify that objects do not refer to the same concept using

different names• Eliminate objects not involved in any use cases

04/10/23 RE 51

Identifying Nonfunctional Requirements

Quality Requirements• Usability

• Reliability/Dependability

• Safety

• Security

• Survivability

• Performance

• Response Time

• Throughput

• Availability

• Accuracy

• Supportability

• Adaptability

• Maintainability

• Portability

Pseudo Requirements• Implementation

• Interface

• Operations

• Packaging

• Legal

04/10/23 RE 52

Identifying Nonfunctional Requirements

Heuristics• Use a taxonomy (e.g., FURPS+) to generate

checklists

• Give different checklists to users in appropriate roles

• Checklists vary depending on application domain

04/10/23 RE 53

Constraints (Pseudo Requirements)

Constraint: • Any client restriction on the solution domain

Examples:• The target platform must be an IBM/360• The implementation language must be COBOL• The documentation standard X must be used• A dataglove must be used• ActiveX must be used• The system must interface to a papertape reader

04/10/23 RE 54

The Process of Requirements

ElicitationThe requirements elicitation process involves a set

of activities that must allow for communication, prioritization, negotiation, and collaboration with all the relevant stakeholders.

Requirements elicitation involves activities that are intensely communicative.

These activities increase in significance when one considers the “culture gap” or basic semantic differences dividing the problem owning and the problem solving communities when attempting to engage in meaningful dialogue.