1. Introduction to Requirements
Lisa Komidar, SCM/CAPM
PSU World Campus – Learning Design

2. Poor Requirements = Project Failure
According to Wrike.com, 38% of project failures is due to poor requirements.
Effects of poor or lack of requirements
Knowledge of testing needs
Flawed design
Missing user needs
Poor quality
Late delivery
Can you name a few? 2

3. Attributes for good requirements
Complete - they very thoroughly describe the criteria
Correct - they are accurate and true
Feasible - they can be accomplished and individual requirements do not contradict each other.
Necessary - they are truly needed for the system to function properly and they are really what the client wants.
Prioritized - in the case that not all parts of the system can be implemented at the same time, it's important to be able to distinguish "absolutely necessary" from "nice to have".
Unambiguous - they are clear and cannot be misinterpreted
Verifiable - once implemented, it can be confirmed that the system has met the requirement through observation and testing 3

4. Three types of poor requirements
Missing
Irrelevant
Bad

5. Impacts of poor requirements
Scope creep negatively affecting budget and completion time
Low utilization of resources and higher overheads
Inadequate business process design (due to insufficient details about activities)
Poor design and ergonomics of the user interface, resulting in lower productivity
Inadequate software specification, resulting in lower developer productivity
Poor specification amplifies the negative effect of poor requirements when it comes to software testing, leading to higher costs and lower quality of the solution
Time-consuming and costly code rework
Difficulties in solution integration. 5

6. IT Pain
Brad Matsugu, 2012

7. Where to start ​Understand the business need using the project charter
Analyze the gaps as defined in the scope statement
Understand functional vs. non-functional
Functional
tasks the software must perform
scope of the system
product boundaries
connections to adjacent systems
business rules
Non-Functional
look and feel
operating environment
cultural, legal and political issues 7

8. Where to really start
Domain Experts - people who are very knowledgeable and work in the area of the system that is being built
Users - people who will actually be the ones using the system once it's built
Find out the limitations of existing systems and software
Find out where the users' time is spent
Find out what they like and don't like
User shadowing
Review similar software programs 8

9. Different techniques One-on-one interviews Group interviews
Facilitated sessions
Questionnaires
Prototyping
Use cases
Brainstorming 9

10. One on one interview Planned ahead Open ended questions
Probing questions
Walk through example 10

11. Group interview Two to four people Typically same level or role
Must keep the group focused
Walk through example 11

12. Facilitated session Five or more users
Faster approach to get a common set of requirements
Allow for a longer time
Walk through example 12

13. Questionnaires A good way to get information from remote users
Typically covers a large number of users who will have minor input
Much more informal 13

14. Prototyping A more modern approach
Prototype built on preliminary requirements
Show this to client
Modify prototype based on feedback
Circle back until product meets business needs 14

15. Use cases Also known as user stories
As <user>, I want to <action> so I can <result>
Defines a definition of done
Walk through example 15

16. Brainstorming Set aside a longer period of time All users together
Tools
Whiteboards
Stickies
Online collaboration such as box notes or google docs
Generate ideas
Prioritize
Agreement
Walk through example 16

17. Combining Brainstorming, User stories, prototyping
Allow for a longer period of time to be able to capture all requirements
What you give up front will save you in the end!
Full project team
Stakeholders
Developers
UX Design
Accessibility
Start at a higher level and work down to fine details
For larger projects, start with high requirements and break them out into your phases. Then applying an agile approach, work on a single phase.
Walk through! 17