Professional Documents
Culture Documents
Requirement Elicitation
Requirement Elicitation
TECHNOLOGY
SE321 Software Requirement Engineering
Spring 2023
Course Instructor
Parkash Lohana
Associate Professor
Last week
- Users “wants” Vs “needs”
- User Classes
- User Personas
- User Perspective
SE321 Software Requirement Engineering
Spring 2023
- Product Champion
Week 10 Agenda - Product Owner
- Addressing Conflict
Product Champion
Many years ago I worked in a small software development group that
supported the scientific research activities at a major corporation.
Each of our projects included a few key members of our user community
to provide the requirements. We called these people product champions (
Wiegers 1996).
RQ 6
Who should be a product champion
RQ 7
External product champions
RQ 8
RQ 9
Multiple product champions
One person can rarely describe the needs for all users of an application.
The Chemical Tracking System had four major user classes, so it needed four product champions
selected from the internal user community at Contoso Pharmaceuticals.
Figure illustrates how the project manager set up a team of BAs and product champions to elicit the
right requirements from the right sources.
These champions were not assigned full time, but each one spent several hours per week working on
the project. Three BAs worked with the four product champions to elicit, analyze, and document their
requirements.
(One BA worked with two product champions because the Buyer and the Health and Safety Department
user classes were small and had few requirements.)
One of the BAs assembled all the input into a unified SRS.
RQ 10
RQ 11
RQ 12
RQ 13
User representation on agile projects
RQ 14
Resolving conflict requirements
RQ 15
Resolving requirements disputes
RQ 16
Conflicts
RQ 17
RQ 18
Summary
RQ 19
SE321 Software Requirement Engineering
Spring 2023
- Requirement Elicitation
Week 10 Agenda - Elicitation Techniques
- Prepare for Elicitation
- Performing Elicitation Activities
- Following Up After Elicitation
Requirement Elicitation/Discovery
Requirements elicitation/discovery involves uncovering what the
customer needs and wants.
Some requirements will be obvious (e.g., the POS system will have to
compute sales tax), many requirements will need to be extricated from
the customer through well-defined approaches.
Discovering who the stakeholders are; for example, are there any hidden
stakeholders?
3 kg flour
12 large eggs
3 kg sugar
½ kg butte
At the store you are not sure if she wants white or brown sugar.
So you call her and ask which sugar she wants, and you make
your purchase accordingly and return home.
RQ 22
Encounter with Customer (Cont…)
She is unhappy with your selection. You bought wrong kind of flour;
She informs you that she wanted white and you bought wheat.
Wrong kind of sugar too, dark brown, she wanted light brown ………..so
you are in trouble
RQ 23
Encounter with Customer (Cont…)
You find the white flour and brown sugar, but unsalted butter in a tub,
not in stick, you assume the tub is acceptable to her.
You make purchases and return but now you discovered that you made
new mistakes
RQ 24
Encounter with Customer (Cont…)
So, you go back to store and guiltily return the items, and pick their proper
substitutes.
To calm down your wife’s anger, you also buy some of her favorite chocolate
candy.
But she is still unhappy, now she remembers that she is making omelet and the
dozen eggs wont be enough for both – she needs 18 eggs
She is not pleased with your chocolate, she inform you that she is on diet
So one more time you visit the mart and purchase the needful
RQ 25
Encounter with Customer (Cont…)
Each time your wife discovering a new flaw in your purchase, changing
her mind about the quantity or brand, adding new items, subtracting
others, etc.
RQ 26
Encounter with Customer (Cont…)
First, we need to understand the application domain
RQ 27
Encounter with Customer (Cont…)
Second, customers don’t always know what they want—your wife didn’t
realize that she needed more eggs until after you made three trips to the
store.
Finally learned that even providing customers with more than they ask
for (in this case her favorite chocolate) can sometimes be the wrong thing
to do.
RQ 28
Encounter with Customer (Cont…)
The most important lesson to be learned from this encounter with a
customer is that they can be trouble.
They don’t always know what they want, and, even when they do, they
may communicate their wishes ineffectively.
Customers can change their mind and they may have high expectations
about what you know and what you will provide.
RQ 29
Requirement Elicitation
RQ 31
RQ 32
RQ 33
RQ 34
RQ 35
RQ 36
RQ 37
RQ 38
RQ 39
RQ 40
RQ 41
RQ 42
RQ 43
RQ 44
RQ 45
RQ 46
RQ 47
RQ 48
RQ 49
RQ 50
RQ 51
RQ 52
RQ 53