lecture duration: 180’

Instructor: Dao, Nguyen Thi Anh

International School - DTU
Email: nguyenthianhdao@duytan.edu.vn

1.1 © by CMU Dao

Dao
Nguyen
Nguyen
 Contents
1. Learn the required gathering and eliciting
techniques.
2. Identify stakeholders’ environment and needs.
3. Stakeholders drive requirements elicitation and
prioritization.
4. How do you evaluate whether you are properly
capturing the stakeholders ideas and needs.

1.2 © by CMU Dao

Dao
Nguyen
Nguyen
 Requirements Engineering

Requirements Engineering consists of:

1. Requirements Development:
Requirements Elicitation(Gathering)
Requirements Analysis
Requirements Specification
Requirements Verification &Validation
2. Requirements Management:
ƒ Requirements Baseline
ƒ Requirement Change Management
ƒ Requirements Traceability
1.3 © by CMU Dao
Dao
Nguyen
Nguyen
 Requirements Engineering

1.4 © by CMU Dao

Dao
Nguyen
Nguyen
 Requirements Development
 ƒ stablish common understanding among stakeholders and
E
developers.
 ƒIdentify business problems or issues.
 ƒUnderstand stakeholders’ needs and expectations.
 ƒFill in the gap between the needs and expectations.
 ƒDiscover the “unstated” expectations.

1.5 © by CMU Dao

Dao
Nguyen
Nguyen
 Requirements Development
 ƒEstablish requirements from stakeholders’ views.
 ƒEstablish scenarios: How stakeholders will use the system.
 ƒExplain the context for using the product.
 ƒValidate that needs and expectations are being met.

1.6 © by CMU Dao

Dao
Nguyen
Nguyen
 Wants vs. Needs

Ozkaza’s Definition:

Wants = How the Stakeholders define the problem.

Needs = How Software Engineers define the solution.

The ideal situation is a good match between the two.

1.7 © by CMU Dao

Dao
Nguyen
Nguyen
 Wants vs. Needs

Al Davis’s Definition:
Wants = The Stakeholders wish to have.
Needs = The Stakeholders must have.

The ideal situation will satisfy both, but in reality the Software
Engineer must satisfy all of the needs and some of the wants.

1.8 © by CMU Dao

Dao
Nguyen
Nguyen
 Relationships Of Requirements

1.9 © by CMU Dao

Dao
Nguyen
Nguyen
 Requirements Development Process

1.10 © by CMU Dao

Dao
Nguyen
Nguyen
 Definitions

ƒRequirements Elicitation
Techniques or methods used by Software Engineers to
determine the needs of stakeholders (customers and users), so
that systems can be built with a high probability of satisfying
those needs.
ƒRequirements Analysis
The techniques of deciding which features are appropriate for
the product based on stakeholder needs.

1.11 © by CMU Dao

Dao
Nguyen
Nguyen
 Definitions

ƒRequirement Specification
The techniques of documenting the external behavior of a
system that will be built based on the features selected during
the analysis process.
ƒRequirement Verification & Validation
The techniques of ensuring that a requirements specification
meets the stakeholders’ needs.

1.12 © by CMU Dao

Dao
Nguyen
Nguyen
 Requirements Elicitation*
• The process through which the stakeholders and the
developers of a software/system discover, review, articulate,
and understand the stakeholders’ needs and the constraints on
the software/system and the development activity.

1.13 © by CMU Dao

Dao
Nguyen
Nguyen
 Questions To Ask …

ƒ What is the problem to be solved?

ƒ What are the constraints?
• Cost
• Deadlines
• Performance
• Platform, Technology…

1.14 © by CMU Dao

Dao
Nguyen
Nguyen
 Questions To Ask …

ƒ What are the needs?

ƒ
• Successive refinement (Iterative)
• Technical feasibility
• Financial justification

1.15 © by CMU Dao

Dao
Nguyen
Nguyen
 Understand Stakeholders’ Needs

ƒ Draw pictures – stay in Problem space.

ƒ Create scenarios – use-cases.
ƒ Tell stories about how you think it works.
ƒ Process modeling and simulation.
ƒ Prototype.
ƒ Verify your assumptions with stakeholders.
ƒ Listen, Listen, and Listen!

1.16 © by CMU Dao

Dao
Nguyen
Nguyen
 Iterative Process

ƒ Each step leading to obtaining a requirement statement is:

• An opportunity to engage the stakeholders in the process.
• A reduction in stakeholders’ resistance.
• An increase in the probabilities for project success.
• An opportunity for better collaboration.

1.17 © by CMU Dao

Dao
Nguyen
Nguyen
 Iterative Process

ƒ Each step leading to obtaining a requirement statement is:

• A stepping stone toward the problem-solving goal.
• A relationship creation that you must nurture.
• An essential piece of the system that you are building.
• An education process for both you and the stakeholders.

1.18 © by CMU Dao

Dao
Nguyen
Nguyen
 Elicitation Techniques

Techniques or methods used by software engineers to

determine the needs of stakeholders, so that systems can be
built with a high probability of satisfying those needs.

1.19 © by CMU Dao

Dao
Nguyen
Nguyen
 Elicitation Techniques

There are many elicitation techniques:

1. Interview
2. Questionnaire
3. Storyboarding

1.20 © by CMU Dao

Dao
Nguyen
Nguyen
 Elicitation Techniques

There are many elicitation techniques:

4. Brainstorming
5. Prototyping
6. Observing user at work
7. Scenario analysis of user tasks

1.21 © by CMU Dao

Dao
Nguyen
Nguyen
 Interviews

ƒ Interviewing is a good technique to gather information.

However, the experience, understanding, and bias of the
stakeholder being interviewed influence the information
obtained.
ƒ Software engineers should use questions that do not suggest a
particular response.
• For example:
Who is the owner for this system?
What is the reason for wanting to solve this problem?
What environment is this product likely to encounter?
What kind of product precision is required?

1.22 © by CMU Dao

Dao
Nguyen
Nguyen
 Interviews

The most popular technique:

• Asking questions of stakeholders about the problem to
be solved and their needs. Listening to their response
and documenting them for analysis.
• Very useful when stakeholders are subject matter
experts, know the problem well, are accessible and
willing to spend time to be interviewed.
• Software Engineers have to be trained in interview
techniques to be effective.

1.23 © by CMU Dao

Dao
Nguyen
Nguyen
 Interviews

1.24 © by CMU Dao

Dao
Nguyen
Nguyen
 Ask for Outcomes, Not Solutions

1.25 © by CMU Dao

Dao
Nguyen
Nguyen
 Questions To Ask
• ฀ hat is the client’s problem?
W
 What, precisely, is the problem to be solved?
 ƒWhen does the problem occur?
 What generates the problem?

1.26 © by CMU Dao

Dao
Nguyen
Nguyen
 Questions To Ask
• ƒ re they new or old? Or Transient?
A
 ƒWhere does the problem occur?
 What are the problem domain boundaries?
 ƒHow is the problem handled now?
 ƒWhy does the problem exist?

1.27 © by CMU Dao

Dao
Nguyen
Nguyen
 Good Question, Bad Question
•ƒ Question:
• When a car suddenly brakes in front of your car, you have to
slow down and not hit it, right?
ƒ Answer:
• Yes, of course.
ƒ What is the requirement here? You learn absolutely nothing!

1.28 © by CMU Dao

Dao
Nguyen
Nguyen
 Good Question, Bad Question
•ƒ Question:
• What happens when a car suddenly brakes in front of your car?
ƒ Answer:
• If that car is too close, I have to do something or else a crash may
happen. I guess all cars need a warning light when braking. If
the car is far away, I may not have to do anything. The only
time brakes are used is when the closing speed is too high for
the distance and yet within the capabilities of the system to
slow down. But I guess if a collision is imminent, I should brake
very hard.

1.29 © by CMU Dao

Dao
Nguyen
Nguyen
 Questionnaire
•

1.30 © by CMU Dao

Dao
Nguyen
Nguyen
 Questionnaire
• ƒ istributing pre-defined questions to a sample of stakeholders.
D
Tallying the results as inputs for further analysis.
 Very useful when stakeholders population is large and
geographically distributed.
 Assume that all questions can be pre- determined, and
stakeholders understand them well.
 Work well to ascertain opinion trends about specific, well-
defined requirements.

1.31 © by CMU Dao

Dao
Nguyen
Nguyen
 Brainstorming
•

1.32 © by CMU Dao

Dao
Nguyen
Nguyen
 Brainstorming
•This technique involves:

ƒ Idea generation: The goal is to identify as many ideas as

possible.
ƒ Idea reduction: The goal is to rank the ideas into those
considered most useful by the group.
ƒ Brainstorming is a powerful technique because the most
creative or effective ideas often result from combining
seemingly unrelated ideas. This technique encourages original
thinking and unusual ideas.

1.33 © by CMU Dao

Dao
Nguyen
Nguyen
 Brainstorming
• ƒ ssembling all stakeholders in one location, encourage
A
participation for all present, allowing every idea to be stated
aloud so others can leverage off them and document them for
analysis.
 Effective when stakeholders are subject matter experts, each
brings their expertise about certain aspects of the problem to
discuss in the meeting with the common goal of leveraging
each other’s knowledge to come up with a full picture of the
requirements.

1.34 © by CMU Dao

Dao
Nguyen
Nguyen
 Prototyping

 ƒA technique for building a quick and rough version of a

desired system or parts of that system.
 ƒThe prototype illustrates the capabilities of the system to users
and designers. It serves as a communications mechanism to
allow reviewers to understand interactions with the system.
 ƒPrototyping sometimes gives an impression that developers are
further along than is actually the case, giving users an overly
optimistic impression of completion possibilities.

1.35 © by CMU Dao

Dao
Nguyen
Nguyen
 Prototyping

ƒ Constructing a partial implementation of a system in a quick

manner, to gain feedback for the requirements process, and
then discard the prototype.
• Very effective to reduce the risk associated with inadvertently
building the wrong system.
• Good for “proof of concept”.

1.36 © by CMU Dao

Dao
Nguyen
Nguyen
 Prototyping

• Could convert poorly understood requirements into much better

ƒ
understood requirements.
• Effective way of communication of requirements to stakeholders.
• Time constraints.
• Sometimes prototype implementation became part of the new
system.

1.37 © by CMU Dao

Dao
Nguyen
Nguyen
 Storyboarding
•

1.38 © by CMU Dao

Dao
Nguyen
Nguyen
 Storyboarding
 A storyboard is a set of drawings depicting a set of user
activities that occur in an existing or envisioned system or
capability.
 Storyboards are a kind of “paper prototyping”.
 Customers, users, or developers start by drawing pictures of
the screens, dialogs, toolbars, and other elements they believe
the software should provide.
 The activity continues to evolve until real requirements and
details are worked out and agreed upon. Another related
technique is storytelling: the writing of stories to envision new
products and services based on perceived user needs and the
possibilities offered by emerging technologies.

1.39 © by CMU Dao

Dao
Nguyen
Nguyen
 Storyboarding
ƒ Using physical media such as paper, cardboard to represent
sequential states of the environment for discussion, then using
scenarios and use cases to determine details, documents them
for analysis.
• Very effective when stakeholders are subject matter experts and
have knowledge of the problem.
• Effective for enhancing an existing system.
• Assume problem is well known by stakeholders.
• Does not work well for brand new systems or if it starts with
completely blank slates and no ideas on how the system is
supposed to work.

1.40 © by CMU Dao

Dao
Nguyen
Nguyen
 •

1.41 © by CMU Dao

Dao
Nguyen
Nguyen
 Requirements Elicitation Guidelines

ƒ. Define the project’s vision and scope

1
2. Identify user classes
3. Identify appropriate representatives from the user classes
4. Identify requirements decision makers and their decision making
process
5. Select elicitation techniques that you will use

1.42 © by CMU Dao

Dao
Nguyen
Nguyen
 Requirements Elicitation Guidelines
6.Apply elicitation techniques to develop and prioritize the use
ƒ
cases for a portion of the system
7.Gather information about quality attributes and other
nonfunctional requirement from users
8. Elaborate the use cases into necessary functional requirements
9. Review the use - case descriptions and functional requirements
10. Develop the analysis models, if needed, to clarify elicitation
participants’ understanding of portions of the requirements
11. Develop and evaluate user interface prototypes to help visualize
requirements that are not clearly understood

1.43 © by CMU Dao

Dao
Nguyen
Nguyen
 Requirements Elicitation Guidelines
•ƒ
12. Develop conceptual test cases from user case
13. Use the test cases to verify use cases, functional requirement,
analysis models, and prototypes
14. Repeat step 6 to step 13 before proceeding design and
construction of each portion of the system

1.44 © by CMU Dao

Dao
Nguyen
Nguyen
 Summary
• ƒ licitation is an iterative process.
E
 ƒThere are many elicitation techniques.
 ƒSoftware Engineers must learn all elicitation techniques and
select the best to use.
 ƒSoftware Engineers need to understand stakeholders’
environment and needs.

1.45 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•

1.46 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•
Can you summarize this within 20 minutes?
QUESTIONS:
1. A
ƒ fter an interview to gather requirements with an
accountant at the company, we should share our interview
summary notes with the person we interviewed, before telling
the manager what was said during the interview.
a) True
b) False

1.47 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•
QUESTIONS:
2. Which one of the following is usually not invited to Joint
Application Development (JAD) sessions to determine
requirements?
a) User
b) Tester
c) Scribe
d) Sponsor

1.48 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•
QUESTIONS:
3. How is brainstorming different from conducting surveys?
Brainstorming sessions
a) Usually involve a smaller group of participants
b) Gets a lot of opinions from many different people
c) covers the technology used for the development
d) all of the mentioned.

1.49 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•
QUESTIONS:
4. Describe using interviews to gather requirements for a new
hotel reservation system. Describe the main disadvantage of
interviews to gather requirements.

5. Describe a situation where creating a “survey” would be a

good way to gather requirements for a new banking system.
Describe two benefits of using a survey in this case to gather
requirements

1.50 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•
ANSWERSƒ:
1. Answer: a
Explanation: To ensure that we recorded and understood
everything correctly...
2. Answer: b
Explanation: A Tester’s role is seen as after coding phase
rather than in the requirements phase.

1.51 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•
ANSWERSƒ:
3. Answer: a
Explanation: Brainstorming is a group or individual creativity
technique by which efforts are made to find a conclusion for
a specific problem by gathering a list of ideas spontaneously
contributed by its member(s).The idea is to quickly reach to
an approved solution ASAP.

1.52 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•
ANSWERSƒ:
4. Describe using interviews to gather requirements for a new hotel
reservation system.
Describe the main disadvantage of interviews to gather requirements.
Talk to individual people to find out what they do and hear their
suggestions.
Takes a lot of time to set up or organize,…and then conduct interviews.
Usually only interview one person at a time. What if some tell you
different things – how do you go back and discuss,…

1.53 © by CMU Dao

Dao
Nguyen
Nguyen
 Class Exercise
•
ANSWERSƒ:
5. Describe a situation where creating a “survey” would be a good way
to gather requirements for a new banking system. Describe two benefits
of using a survey in this case to gather requirements.
A system for a bank. Where there are lots of customers and you want to
get input from lots of people. You create one document and mail/email
or use a website to make it available to many people and they can
complete it when it is convenient to them.

1.54 © by CMU Dao

Dao
Nguyen
Nguyen
 Please watch the video
•

1.55 © by CMU Dao

Dao
Nguyen
Nguyen
 References

• Nguyen, Tam T. T. (2014). Requirements

Engineering.CMU-SE 214-2020S-REF. pp. 34-40
Readings:
 Axel van Lamsweerde, (2009). Requirements
Engineering.CMU-SE 214-2020S-REF.Chapters 4.
 Axel van Lamsweerde, (2009). Requirements
Engineering.CMU-SE . Chapters 3.1-3.3.
Please watch the video at the link below:
https://www.youtube.com/watch?v=SS3k1X6r7s0

1.56 © by CMU Dao

Dao
Nguyen
Nguyen
 Questions & Answers

1.57 © by CMU Dao

Dao
Nguyen
Nguyen