Requirements Gathering

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
Requirements of Requirements

• Clear
• Measurable
• Feasible
• Necessary
• Prioritized
• Concise

5
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

6
Requirements WILL Change
7
Requirements Engineering Tasks

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

8
Inception

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

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

10
Elicitation via Interviews
11
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!!!

12
Elicitation via Interviews

• The list of involved stakeholders must be
  broad!!!! Use real users.
• Meetings include the SwEngs and the stakeholders
• Use agendas that cover the important points yet
  encourage flow of ideas
• Use wall-stickers, flip-charts,
• 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

13
Elicitation via Use Cases

• Diagrams composed of Actors and Actions

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

15
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

16
Elaboration

• Goal is to create an analysis model
• Model Defines
• information
• functions
• What such a model looks like is the next lecture

17
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

18
Specification and Validation

• Specification yields the SRS
• Format of SRS is the next lecture
• Validation reviews the SRS