1. Requirements gathering
Presented by: Debbie Clark, CMA-CPA Chief Operating Officer

2. Gathering requirements are essential to the success of any project

3. “60%–80% of project failures can be attributed directly to poor requirements gathering, analysis, and management.”  - Gartner Group
“Poorly defined requirements have led to a persistent miscommunication between business and IT that largely contributes to a 66% project failure rate for these applications, costing U.S. businesses at least $30B every year.” – Forrester Research
“The cost to fix a defect after delivery is more than 100 times the cost to fix it in the requirements and design phase.” – Gartner Group
“70% of software defects are introduced in the requirements phase.” – National Institute of Standards and Technology (NIST)
Facts to ponder

4. Just What is a “Requirement?”
(1) A condition or capability needed by a stakeholder to solve a problem or achieve an objective
(2) A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification or other formally imposed document
(3) A documented representation of a condition or capability as in (1) or (2) above.
Two Essential Questions We Must Ask Of All Requirements:
Does it support the problem we’re trying to solve?
Will it help us realize a productivity gain?
Just What is a “Requirement?”

5. Types of requirements

6. What is a “GOOD” requirement?
Complete – express a whole idea or statement
Correct – technically and legally possible
Clear – unambiguous and not confusing
Verifiable – it can be determined
Necessary – should support one of the project goals
Feasible – can be accomplished within cost and schedule
Prioritized – tracked according to business need levels
Consistent – not in conflict with other requirements
Traceable – uniquely identified and tracked
Modular – can be changed without excessive impact
Design-independent – do not pose specific solutions on design

8. Requirements Elicitation
Elicited, not “gathered!”
To elicit is to:
Draw forth or bring out
Call forth or draw out
Requirements elicitation is an active effort to extract information from stakeholders and subject matter experts
Elicitation is not a step or task you do at a certain point. It is a set of techniques you apply, appropriately during the requirements phase
Ask lots of open ended questions
Use phrases and words that are easy to understand
Avoid biased or loaded questions
Don’t hesitate to move the interview along with guiding questions
Ask for the opportunity to follow up after the interview to fill in any gaps you may have
Requirements Elicitation

9. techniques Interviews with stakeholders Conduct workshops
Questionnaires
Prototyping
Observation
Brainstorming
Mind Mapping
Use Case Scenarios
Gap-Fit Analysis
techniques

10. Determine business processes/workflows
Describe the steps of the business processes
Current state (As-is)
Future state (To-be)
Use swim lanes presentation to illustrate the workflow
Determine gap between current and future states that fit requirements (gap/fit)

11. Validate and Document Requirements
Goal: To receive client verification for documented system requirements.
End Result: Use Cases that can be used for system development.
How to do it:
Clearly document all requirements in use case format.
Arrange a final requirements meeting to go over these with the client in person.
Validate and Document Requirements

12. Use cases
Use Cases are sequences of actions that an actor (usually a person, but certainly can be an external entity like another external system or a device) performs with an expectation of achieving a particular result; gets value.
Written as a flow of steps
Actor does something
System does something
Actor does something else
System does something else
Made up of one main flow and a number of alternate and/or exception flows (some of which can branch back to the main flow)

13. The Use Cases are clearly the major artifacts of Requirements Gathering efforts.
Use Cases – great for communications
contain the essence of desired interactions.
no jargon as found in DFDs, ERDs, etc.
Particularly good for Functional and to a much lesser degree (in some cases) non-functional requirements. (performance, extensibility, maintainability, backup, recovery, security, persistency, distribution, etc.) But these latter requirements are normally documented in a Supplementary Specification Document…
Good for ensuring requirements traceability – because they are used for design, testing, construction, delivery, and ...
When used to drive the lifecycle, they assure stakeholders that all use cases are being addressed in the development effort.
 Use cases discourage premature design. If the use cases narrative has several steps before responding to the user, this is a tip off that we are undertaking too much designing…STOP!
Remember: these are still the WHATS of the application!
Role of Use Cases

14. Requirements Prioritization
The highest single part of building a software system is deciding precisely what to build…no other part of the work cripples the resulting system if done wrong. No other part is more difficult to rectify later. ~ Frederick P. Brooks
Not all requirements carry equal weight
High/Critical – Critical requirement without which product is not acceptable to stakeholders
Medium/Important – Necessary, but deferrable requirement which makes produce less usable but still functional
Low/Desirable – A nice feature to have if there are resources, but the product functions well without it.