Requirements%20Gathering

1
Requirements Gathering

• How do we find out what we are supposed
• to be building?

2
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

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

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management
• Software Engineering A Practitioners Approach
  by Roger Pressman

9
Inception

• Project starts due to a business decision
• Software Engineer Asks
• What is the basic problem
• Who wants a solution
• Nature of solution

10
Inception

• Project starts due to a business decision
• Software Engineer Asks
• What is the basic problem
• Who wants a solution
• Nature of solution

• First 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?

11
Elicitation Methods

• Interviews
• Use Cases
• Formal Requirement Engineering Techniques

12
Elicitation via Interviews
13
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!!!

14
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

15
Elicitation via Use Cases

• Diagrams composed of Actors and Actions

Logout
Anonymous User
Registered User
Create Account
Manage Account
Credit Card System
16
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

17
Elicitation via QFD

• Since 1966, Quality Function Deployment (QFD) has
  been used world wide in nearly every industry and
  sector to
• Prioritize spoken and unspoken customer wows,
  wants, and needs
• Translate these needs into actions and designs
  such as technical characteristics and
  specifications and
• 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

18
Elaboration

• Goal is to create a model that defines
• information
• functions
• What such a model looks like
  is the 2nd half of tonight

http//www.camsp.com/cornerstone/assets/images/res
ources/when_use_maps_sm.png
19
Negotiation

• Goal is to resolve requirements that are
• Conflicting
• Costly
• Unrealistic
• Identify the subsystems stakeholders
• Determine their win conditions
• Negotiate their win conditions into win-win
  conditions for everyone

20
Specification and Validation

• Specification yields the SRS
• Format of SRS is the 2nd half of tonight
• Validation reviews the SRS

21
Review

• Requirements Engineering Tasks
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management