Introduction to Requirements

Lisa Komidar, SCM/CAPM

PSU World Campus – Learning Design
lmd5@psu.edu
http://lisakomidar.com
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
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
Three types of poor requirements

• Missing

• Irrelevant

• Bad

4
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
IT Pain

Brad Matsugu, 2012

Where to start
• U
​ nderstand 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
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
Different techniques
• One-on-one interviews
• Group interviews
• Facilitated sessions
• Questionnaires
• Prototyping
• Use cases
• Brainstorming

9
One on one interview
• Planned ahead
• Open ended questions
• Probing questions

• Walk through example

10
Group interview
• Two to four people
• Typically same level or role
• Must keep the group focused

• Walk through example

11
Facilitated session
• Five or more users
• Faster approach to get a common set of requirements
• Allow for a longer time

• Walk through example

12
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
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
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
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
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