Requirements Gathering

How do we find out what we are supposed

to be building?
 Why good Specs are Essential:

$
It is VERY expensive to fix problems late in the process. It
is very cheap to rewrite or clarify a written spec.

What costs $1 to fix at ReqGathering

$5 in the design stage
$10 in the coding stage
$20 in the unit testing phase
$200 after delivery

2
Starter Questions
What is a "requirement"?

How do we determine the

requirements?

3
Types of Requirements
Functional
ex - it must email the sales manager when an inventory
item is "low"
Non-Functional
ex - it must require less than one hour to run
Explicit
ex required features
Implied
ex software quality
Forgotten
ex exists in current process
Unimagined
4
Questions
What makes a particular
requirement good or bad?

Why is requirements engineering

difficult?

5
Requirements of Requirements
Clear
Measurable
Feasible
Necessary
Prioritized
Concise

6
Req Gathering Problems
Accommodating changing reqs
Being complete, without being constraining
Conflicting views
Ease of omitting obvious info
Identifying the experts and getting
authority to talk to people
Incomplete understanding of the problem
on the part of the user/customer
Sticking with what and not how
Determining what is critical
Avoiding mission creep 7
Requirements WILL Change

8
Requirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management

Software Engineering: A Practitioners Approach by Roger Pressman

9
 Inception
Project starts due to a business
decision
Software Engineer Asks:
Why do you want this
What is the basic problem

Who wants a solution

Nature of solution
Example Questions:
Who is behind the request for work?
Who will use the solution?
What will be the economic benefit of success?
Is there another source for the solution? 10
Elicitation Methods
Interviews
Use Cases
Formal Requirement Engineering
Techniques

11
Elicitation via Interviews

12
Elicitation via Interviews
Difficulties:
Ill-defined project scope
Unnecessary details that confuse
Not sure what they need
Poor understanding of capabilities
Omitting the obvious
Requirements that conflict with other
peoples requirements
Requirements Change!!!
13
Elicitation via Interviews
Recommended Practices:
The list of involved stakeholders must be
broad!!!
Be sure to use real end-users.
Use agendas that cover the important points yet
encourage flow of ideas
Ahead of time, the participants should build a
partial list of the functions, performance criteria,
environment factors,
Start with scope and context, move to functions
Use visuals such as wall-stickers, flip-charts,
Meetings with stakeholders should include the
SwEngs
14
 Elicitation via Use Cases
Diagrams composed of Actors and Actions
Logout

Anonymous
User
Registered
Create Account
User

Manage Account

Credit Card
System
15
Elicitation via JAD
Joint Application Design
JAD Sessions Participants:
Executive Sponsor
Project Leader
Facilitator trained and experienced
Recorder
Participants
Observers developers who sit on sideline and dont talk
Outputs of sessions:
Data flow diagrams
Data requirements
List of assumptions
etc
16
Elicitation via QFD
Since 1966, Quality Function Deployment (QFD) has been used world wide
in nearly every industry and sector to:
1. Prioritize spoken and unspoken customer wows, wants, and needs;
2. Translate these needs into actions and designs such as technical
characteristics and specifications; and
3. Build and deliver a quality product or service by focusing various business
functions toward achieving a common goal and customer satisfaction.
www.qfdi.org

QFD uses interviews, surveys, and data (problem reports)

to build a table of requirements called the Customer
Voice Table.
Functional Deployment value of each function
Information Deployment identify the input and output
Task Deployment examine system behavior
Value Analysis prioritize the requirements

17
Elaboration

http://www.camsp.com/cornerstone/assets/images/resources/when_use_maps_sm.png
Goal is to create a model that defines:
1. information
2. functions

Models could be
ER Diagrams
Use Cases
Data Flow Diagrams
all of the above

18
Negotiation
Goal is to resolve requirements that are
Conflicting
Costly
Unrealistic

1. Identify the subsystems stakeholders

2. Determine their win conditions
3. Negotiate their win conditions into win-
win conditions for everyone

19
Specification and Validation
Specification yields the SRS
Format of SRS is our next class

Validation reviews the SRS

20
Review of Tonight
Requirements Engineering Tasks
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
21