USMAN INSTITUTE OF

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

Week 10: User Perspective (Cont..)

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

 The product champion approach provides an effective way to structure

that all-important customer-development collaborative partnership
RQ 5
The Product Champion

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

Week 10: Requirement Elicitation

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

 Elicitation is not like harvesting low-hanging fruit from a tree.

 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?

 Elicitation also involves determining the NFRs, which are often

RQ overlooked. 21
Encounter with Customer
 Suppose your wife (or substitute “husband,” or whoever) asks you to go
to the store to pick up the following items because she wants to make a
cake:

 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 butter, she wanted unsalted

 Wrong kind of sugar too, dark brown, she wanted light brown ………..so
you are in trouble

 So you go back and return the flour, sugar, and butter

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

 White flour you bought is bleached; she wanted unbleached

 Butter in tub is unacceptable

 Now she is very angry with you for your ignorance

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

 We could go on an on with this example

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.

 But does this situation has to do with requirement engineering and

stakeholders?

 The situation illustrates many points about requirements engineering.

RQ 26
Encounter with Customer (Cont…)
 First, we need to understand the application domain

 In this case, having a knowledge of baking would have informed you

ahead of time that there are different kinds of butter, flour, and sugar
and you probably would have asked focusing questions before embarking
on your shopping trip.

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.

 And there is yet one more lesson in the story:

 never make assumptions about what customers want—you thought that the tub butter
was acceptable; it wasn’t.

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

 Because stakeholder interaction is so important especially the

stakeholders for whom the system is being built—the customers.

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