CHAPTER 3

REQUIREMENTS ENGINEERING
• Requirements engineering is a process that
involves all of the activities required to create and
maintain a system requirements document.
• There are 4 generic, high level requirements
engineering process activities:
• Feasibility Study
• The elicitation and analysis of requirements
• The specification of requirements and their
documentation. (Discussed in chapter 5)
• Requirements validation
 THE EXPECTATION GAP – A RUDE SURPRISE TO
EVERYONE

• Without adequate customer involvement, the inescapable outcome at the end of the project
is an expectation gap, a gap between what customers really need and what developers deliver
based on what they heard at the beginning of the project
• Requirements also get out of date because of changes that occur in the business, so ongoing
interactions with customers are vital
• So how to minimize the gap ?
• The best way to minimize the expectation gap is to arrange frequent contact points with
suitable customer representatives.
3
• Each contact point affords an opportunity to close the expectation gap: what the developer
builds is more closely aligned with what the customer needs
 • The input to the feasibility study is an outline
description of system and how it will be within an
organization.
• The results should be a report, which recommends
whether or not it is worth carrying on with the
requirements engineering and system development
process.
• A feasibility study is a short, focused study which aims
to answer a number of questions:
1. Does the system contribute to all objectives of the
organization?
2. Can the system be implemented using current
3.1 technology and within given cost and schedule?
Feasibility study 3. Can the system be integrated with other systems which
(initial) are already in place?
 • Some people consider requirements engineering to be
the process of applying a structured analysis method,
such as object-oriented analysis. This involves analyzing
the system and developing a set of graphical system
models, such as use case models, which then serve as a
system specification. The set of models describe the
behavior of the system and is annotated with additional
information describing, for example, the system’s
required performance or reliability.
3.1
Feasibility study
(initial)
 • In this activity, technical software development staff work
with customers and system end-users to find out about:
1. The application domain.
2. What services the system should provide
3. The required performance of the system
4. Hardware constraints, …
3.2 • Stakeholder is a term used to refer to anyone who should
Requirements have some direct or indirect influence on the system
elicitation and requirements.
analysis • Stakeholders include
1. End-users: who will interact with the system and everyone
else in an organization who will be affected by it
2. Engineers: who are developing or maintaining other
related systems
3. Business managers.
4. Domain experts
5. Trade union representatives….
 REQUIREMENTS ELICITATION
• The heart of requirements development is elicitation
• Elicitation is the process of identifying the needs and constraints of the various
stakeholders for a software system
• Elicitation includes activities related to collecting, discovering, extracting, and
defining requirements.
• Elicitation is used to discover business, user, functional, and nonfunctional
requirements, along with other types of information.
• Requirements elicitation is perhaps the most challenging, critical, and
communication-intensive aspect of software development. 7
 FEW THINGS BUSINESS ANALYST
MUST CONSIDER ..

• To facilitate clear communication, use the vocabulary of the business domain instead of forcing
customers to understand technical jargon. Record significant application domain terms in a
glossary, rather than assuming that all participants share the same definitions
• Customers must understand that a discussion about possible functionality is not a commitment to
include it in the product
• The output of requirements development is a common understanding of the needs held by the
diverse project stakeholders. When the developers understand those needs, they can explore
alternative solutions to address them
8
 • Elicitation and analysis is a difficult process because:
1. Stakeholders often don’t really know what they want from
the system, their demands may be unrealistic because
they are unaware of the cost of their requests.
2. Stakeholders’ requirements depend on their own work.
3.2 Requirements engineers, without experience in the
customers’ domain, must understand these requirements.
Requirements 3. Stakeholders’ may express the requirements in different
elicitation and ways. Requirements engineers have to discover
analysis commonalities and conflicts.
4. Political factors may influence the requirements of the
system. They may come from managers who want some
requirements that increase their influence in the
organization.
5. The economic and business environment is dynamic
during the analysis process.
3.2
Requirements
elicitation and
analysis • Requirements elicitation and analysis process activities
are:
1. Domain understanding.
2. Requirements collection. (From stakeholders)
3. Classification: this activity takes the unstructured
collection of requirements and organizes them into
coherent clusters.
4. Conflict resolution.
5. Prioritization: this stage involves interaction with
stakeholders to discover the most important
requirements.
6. Requirements checking: to discover if they are
complete, consistent.
REQUIREMENTS ELICITATION ACTIVITIES

11
 • Sources of information during the requirements discovery
phase include
- Documentation,
- System stakeholders, and
Requirements - Specifications of similar systems.
elicitation - Application domain.
(discovery) and • You interact with stakeholders through interviews and
analysis observation and you may use scenarios and prototypes to
help stakeholders understand what the system will be like.
• In addition to system stakeholders, we have already seen
that requirements may also come from the application
domain and from other systems that interact with the
system being specified.
 STAKEHOLDERS & CUSTOMERS

• A stakeholder is a person, group, or organization that is actively involved in a project, is affected

positively or negatively by its process or outcome, or can influence its process or outcome.
Stakeholders can be internal or external to the project team and to the developing organization
• Stakeholder analysis is an important part of requirements development
• A customer is an individual or organization that derives either direct or indirect benefit from a
product
• Be careful, some stakeholders are not customers
• User requirements should come from people who will actually use the product, either directly
or indirectly. These users (often called end users) are a subset of customers. 13
 STAKEHOLDERS & CUSTOMERS

• Direct users will operate the product hands-on.

• Indirect users might receive outputs from the system without touching it themselves, such as a
warehouse manager who receives an automatic report of daily warehouse activities by email.
• Users can describe the tasks they need to perform with the product, the outputs they need, and the
quality characteristics they expect the product to exhibit.

14
STAKEHOLDER EXAMPLES

15
 REQUIREMENTS ELICITATION TECHNIQUES
• There are always many types of information to be discovered, and different stakeholders will prefer
different approaches
• Elicitation techniques include both:
• Facilitated activities, in which you interact with stakeholders to elicit requirements, and
• Independent activities, in which you work on your own to discover information
• Facilitated activities primarily focus on discovering business and user requirements. Working directly
with users is necessary because user requirements encompass the tasks that users need to accomplish
with the system.
• To elicit business requirements, you will need to work with people such as the project sponsor.
• The independent elicitation techniques supplement requirements that users present and reveal
needed functionality that end users might not be aware of.
• Most projects will use a combination of both facilitated and independent elicitation activities.
• Requirements elicitation techniques examples: interviews, workshops, focus groups, observation,
questionnaires, system interface analysis, user interface analysis and document analysis. 16
 1. Interviews
2. Viewpoint-oriented elicitation.
3. Workshops
4. Scenarios.
Techniques for
5. Ethnography.
requirements
6. Structured analysis.
elicitation and
7. Prototyping
analysis
There is no perfect and universally applicable approach to
requirements analysis. Use several of these approaches to
develop a complete understanding of the requirements.
 1- INTERVIEWS
• Interviews are easier to schedule and lead than large-group activities such as requirements
workshops.
• If you are new to an application domain, interviews with experts can help you get up to speed
quickly. This will allow you to prepare draft requirements and models to use in other
interviews or in workshops
• Interviews are appropriate for eliciting business requirements from executives who do not
have a lot of time to meet.
• These are useful tips for conducting elicitation interviews as well:
• Establish rapport
• Stay in scope
• Prepare questions and straw man models ahead of time
• Suggest ideas
• Listen actively
18
 • Formal or informal interviews with system stakeholders are
part of most requirements engineering processes.
• In these interviews, the requirements engineering team
Interviewing puts questions to stakeholders about the system that they
currently use and the system to be developed.
• Requirements are derived from the answers to these
questions.
 Interviews may be of two types:
1. Closed interviews, where the stakeholder answers a pre-
defined set of questions.
2. Open interviews, in which there is no pre-defined
Interviewing agenda. The requirements engineering team explores a
range of issues with system stakeholders and hence
develop a better understanding of their needs.
• In practice, interviews with stakeholders are normally a
mixture of both of these.
 • Completely open-ended discussions rarely work well. You
usually have to ask some questions to get started and to
keep the interview focused on the system to be developed.
• Interviews are good for getting an overall understanding of
what stakeholders do, how they might interact with the new
system, and the difficulties that they face with current
Interviewing
systems.
• People like talking about their work so are usually happy to
get involved in interviews.
• However, interviews are not so helpful in understanding the
requirements from the application domain.
 It can be difficult to elicit domain knowledge through
interviews for two reasons:
1. All application specialists use terminology and jargon that
are specific to a domain. It is impossible for them to
discuss domain requirements without using this
terminology. They normally use terminology in a precise
and subtle way that is easy for requirements engineers to
misunderstand.
Interviewing
2. Some domain knowledge is so familiar to stakeholders
that they either find it difficult to explain or they think it is
so fundamental that it isn’t worth mentioning.
For example, for a librarian, it goes without saying that all
acquisitions are catalogued before they are added to the
library. However, this may not be obvious to the interviewer,
and so it isn’t taken into account in the requirements.
 • Interviews are also not an effective technique for eliciting
knowledge about organizational requirements and
constraints because there are subtle (hidden) power
relationships between the different people in the
organization.
• Published organizational structures rarely match the reality
Interviewing
of decision making in an organization but interviewees may
not wish to reveal the actual rather than the theoretical
structure to a stranger.
• In general, most people are generally reluctant to discuss
political and organizational issues that may affect the
requirements.
 Effective interviewers have two characteristics:
1. They are open-minded, avoid pre-conceived ideas about
the requirements, and are willing to listen to
stakeholders. If the stakeholder comes up with surprising
Interviewing requirements, then they are willing to change their mind
about the system.
2. They prompt the interviewee to get discussions going
using a springboard question, a requirements proposal, or
by working together on a prototype system.
 • Saying to people ‘tell me what you want’ is unlikely to
result in useful information. They find it much easier to talk
in a defined context rather than in general terms.
• Information from interviews supplements other
information about the system from documentation
describing business processes or existing systems, user
Interviewing observations, etc.
• Sometimes, apart from the information in the system
documents, the interview information may be the only
source of information about the system requirements.
• However, interviewing on its own is liable to miss essential
information and so it should be used in conjunction with
other requirements elicitation techniques.
 • Different viewpoints see the problem in different ways.
• Viewpoint-oriented approaches to requirements
engineering recognize these different viewpoints and use
them to structure and organize both the elicitation process
Viewpoint- and the requirements themselves.
oriented • A key strength of viewpoint-oriented analysis is that it
elicitation recognizes the existence of multiple perspectives and
provides a framework for discovering conflicts in the
requirements proposed by different stakeholders.
Example: VORD method: (viewpoint-oriented requirements
definition)
 2-WORKSHOPS

• Workshops: a structured meeting in which a carefully selected group of

stakeholders and content experts work together to define, create, and refine
models and documents that represent user requirements.
• Workshops often include several types of stakeholders, from users to developers to
testers.
• Workshops are useful for:
• Eliciting requirements from multiple stakeholders concurrently.
• Working in a group is more effective for resolving disagreements than is talking
to people individually.
• Helpful when quick elicitation is needed because of schedule constraints.
27
 WORKSHOPS

Who is the workshop facilitator?

Who is the scribe?
Can BA play three roles?
28
 2-WORKSHOPS
• Following are a few tips for conducting effective elicitation workshops
• Establish and enforce ground rules
• Fill all of the team roles
• Plan an agenda
• Stay in scope
• Time box discussions
• Keep the team small but include the right stakeholders
• Keep everyone engaged
29
 3-FOCUS GROUPS
• A focus group is a representative group of users who meet in a facilitated elicitation activity to
generate input and ideas on a product’s functional and quality requirements.
• Focus group sessions must be interactive, allowing all users a chance to voice their thoughts.
• Focus groups are useful for exploring users’ attitudes, impressions, preferences, and needs.
• They are particularly valuable if you are developing commercial products and don’t have ready
access to end users within your company.

30
 3-FOCUS GROUPS
• How do you select participants in workshop?
• Include users who have used previous versions or products similar to the one you’re
implementing
• Select a pool of users who are of the same type (and hold multiple focus groups for the
different user classes)
• Or select a pool representing the full spectrum of user classes so everyone is equally
represented
• Participants in focus groups normally do not have decision-making authority for
requirements.
• Follow tips as ones in workshops.
31
 • People usually find it easier to relate to real-life examples
rather than abstract descriptions.
• Scenarios can be particularly useful for adding detail to an
outline requirements description.
• They are descriptions of example interaction session.
• Each scenario covers one or a small number of possible
Scenarios interactions.
• Different forms of scenarios have been developed and they
provide different types of information at different levels of
detail about the system.
• The scenario starts with an outline of the interaction and,
during elicitation, details are added to create a complete
description of that interaction.
 A scenario may include:
1. A system state description at the beginning of the
scenario.
2. A description of the normal flow of events in the
scenario.
Scenarios 3. A description of what can go wrong and how this is
handled.
4. Information about other activities which might be
going on at the same time.
5. A description of the state of the system after
completion of the scenario.
Scenarios
 • Scenario-based elicitation can be carried out informally
where the requirements engineer works with stakeholders
to identify scenario and capture details of these scenarios.
Scenarios • Scenarios may be written as text, supplemented by
diagrams, screen shots, etc.
• Alternatively, a more structured approach such as event
scenarios or use-cases may be used.
 • It is an observational technique that can be used to
understand social and organizational requirements.
• The value of ethnography is that it helps discover implicit
system requirements which reflect the actual rather than
the formal processes in which people are involved
• Users may find it difficult to articulate their work. They
Ethnography understand their own work but may not understand its
relationship to other work in the organization.
• Social and organizational factors which affect the work but
which are not obvious to individuals may only become
clear when noticed by an unbiased observer.
• An analyst immerses himself or herself in the working
environment where the system will be used.
 • Ethnography is particular effective at discovering two types
of requirements:
1. Requirements that are derived from the way in which
people actually work rather than the way in which
process definitions say they have to work.
2. Requirements that are derived from cooperation and
awareness of other people’s activities.
Ethnography For example:
✓ An employee may change his policy of work depending on
predicted workload.
✓ A work group may self-organize so that members know of
each other’s work and can cover for each other if someone
is absent. This may not be mentioned during an interview
as the group might not see it as an integral part of their
work.
 • The difference between the assumed and the actual work
was the most important reason why these office systems
had no significant effect on productivity.
• Ethnography may be combined with prototyping.

Ethnography
 • Ethnographic studies can reveal critical process details
which are often missed by other requirements elicitation
techniques.
• Because observation elicitation technique focus on the
end-user, it is not appropriate for discovering
organizational or domain requirements which ethnography
Ethnography
can.
• It cannot always identify new features which should be
added to a system.
• Ethnography is not a complete approach to elicitation, and
it should be used with other approaches such as used-case
analysis.