Umm AL-Qura University

College of Engineering and

Computing at Al-Qunfudhah
Computing Department

Software Engineering
(SE3037)
Chapter 3: Requirements
Elicitation
Outline
• Requirements Elicitation
• Process Requirements Sources
• Elicitation Techniques
Requirements Elicitation
• The aims of the requirements elicitation are to understand the work that
stakeholders do and how they might use a new system to help support that work.

• Also known as requirements capture, requirements discovery, requirements

acquisition and requirement gathering.

• Involves technical staff working with customers to find out about the application
domain, the services that the system should provide and the system’s operational
constraints.

• May involve end-users, managers, engineers involved in maintenance, domain

experts, trade unions, etc. These are called stakeholders.
Problems of Requirements
Elicitation and Analysis
• Eliciting and understanding requirements from system stakeholders is
a difficult process for several reasons:
• Stakeholders don’t know what they really want.
• Stakeholders' express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organizational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may
emerge, and the business environment may change.
The Requirements Elicitation and
Analysis Process
• Requirements discovery
• Interacting with stakeholders to discover
their requirements. Domain requirements
are also discovered at this stage.
• Requirements classification and
organization
• Groups related requirements and organizes
them into coherent clusters.
• Requirements prioritization and
negotiation
• Prioritizing requirements and resolving
requirements conflicts.
• Requirements documentation
• Requirements are documented and input
into the next round of the spiral
Example - ATM Stakeholders
• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulators

7
Viewpoints
• Viewpoints are a way of structuring the requirements to represent the perspectives of
different stakeholders.

• Stakeholders may be classified under different viewpoints.

• This multi-perspective analysis is important as there is no single correct way to analyse

system requirements.

• We may identify viewpoints using :

• Providers and receivers of system services;
• Systems that interact directly with the system being specified;
• Regulations and standards;
• Sources of business and non-functional requirements.
• Engineers who have to develop and maintain the system;
• Marketing and other business viewpoints.
Requirements Elicitation
Techniques
• Requirements elicitation involves meeting with stakeholders of different kinds to discover
information about the proposed system.

• Also, from existing systems and their usage and information from documents of various
kinds.

• There are fundamental approaches to requirements elicitation:

• Interviewing, where you talk to people about what they do.
• Observation or ethnography, where you watch people doing their job to see what artifacts
• Facilitated meetings
• Prototypes
• Stories and scenarios

• You should use a mix to collect information.

Interviewing
• In formal or informal interviewing, the RE team puts questions to
stakeholders about the system that they use and the system to be
developed.

• There are two types of interview:

• Closed interviews where a pre-defined set of questions are answered.
• Open interviews where there is no pre-defined agenda, and a range of issues
are explored with stakeholders.
Interviews
• An interview is a systematic attempt to collect information from a person.

• Interviewing success depends on ability to identify:

• workflows,
• factors that influence the operations of systems, and
• the elements (documents, procedures, policies, etc.) that make up systems.

• Poorly performed interviews may:

• lead to systems which do not meet the needs of the organization
• affect the attitudes of the users and have a negative effect on the entire project
effort
Five Steps of the Interview
Process
• Preparing for the interview

• Planning and scheduling the interview

• Opening and closing the interview

• Conducting the interview

• Following up for clarification

Interviews in Practice
• Normally a mix of closed and open-ended interviewing.

• Interviews are good for getting an overall understanding of what stakeholders do and
how they might interact with the system.

• Interviews are not good for understanding domain requirements

• Requirements engineers cannot understand specific domain terminology;
• Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t
worth articulating.

• To be an effective interviewer:
• Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-
conceived ideas about the requirements.
• Interviewers should prompt the interviewee with a question or a proposal and should not simply
expect them to respond to a question such as ‘what do you want’.
Ethnography
• In ethnography, a social scientist spends a considerable amount of time
observing and analyzing how people actually work.

• People do not have to explain or articulate their work.

• Social and organizational factors of importance may be observed.

• Ethnographic studies have shown that work is usually richer and more
complex than suggested by simple system models.
Perform Ethnography
• Immerse yourselves in the working environment where the system will be used

• Observe the day-to-day work and notes the actual tasks in which participants are involved

• This helps discover implicit system requirements that reflect the actual rather than formal
processes in which people are involved

• Advantage
• Discovers many user tasks and business processes that are too subtle and complex for their actors to
describe easily.

• Disadvantage:
• Expensive (analyst works in client environment)
• Observer should be detached: end-user based, non-judgmental so not appropriate for discovering
organisational or domain requirements
Scope of Ethnography
• Ethnography is particularly effective for discovering two types of
requirements:

• Requirements that are derived from the way that people actually work rather
than the way in which process definitions suggest that they ought to work.
• People may have “short cuts” or use their previous knowledge and experience to better
perform their role which may not be evident.

• Requirements that are derived from cooperation and awareness of other

people’s activities.
• People do not work in isolation and may share information and use dialogue with
colleagues to inform decisions.
Facilitated Meetings
• Purpose: try to achieve a summative effect, whereby a group of people can
bring more insight into their software requirements than by working
individually.

• Advantage:
• Brainstorm and refine ideas that may be difficult to bring to the surface using interviews.
• Conflicting requirements surface early on in a way that lets the stakeholders recognize
where these occur.
• May result in a richer and more consistent set of requirements than might otherwise be
achievable.

• Disadvantage:
• Meetings need to be handled carefully (hence the need for a facilitator) to avoid poor
group dynamics
• Meetings are time consuming (hence the need for a facilitator)
Prototypes
• Valuable tool for clarifying ambiguous requirements.
• Act in a similar way to scenarios by providing users with a context within
which they can better understand what information they need to
provide.
• Wide range of prototyping techniques—from paper mockups of screen
designs to beta-test versions of software products
• Protypes can also be used requirements validation
• Low fidelity prototypes are often preferred to avoid the stakeholder
“anchoring” on minor, incidental characteristics that could limit design
flexibility
• Disadvantage: Choose implementation too early
• Risk: Rough prototype becomes the product
Stories and Scenarios
• People find it easier to relate to real-life examples than abstract
descriptions.
• Stories and scenarios are a description of how the system can be
used for some particular task.
• They describe what people do, what information they use and produce, and
what systems they may use in this process.
• A scenario may include:
• A description of the starting situation;
• A description of the normal flow of events;
• A description of what can go wrong;
• Information about other concurrent activities;
• A description of the state when the scenario finishes.