Requirements

Engineering
Lecture 05
National University FAST
September 19, 2015, 18:00 21:00

Every Project has Requirements

Frederick Brooks eloquently stated the critical

role of requirements to a software project in

his classic 1987 essay, No Silver Bullet:
Essence and Accidents of Software
Engineering:
The hardest single part of building a software
system is deciding precisely what to build. No
other part of the conceptual work is as difficult as
establishing the detailed technical requirements,
including all the interfaces to people, to
machines, and to other software systems. No
other part of the work so cripples the resulting
system if done wrong. No other part is more

Common Requirements
Risks
Insufficient User Involvement
Creeping User Requirements
Ambiguous Requirements
Gold Plating
Minimal Specification
Overlooked User Classes
Inaccurate Planning

High Quality Requirements Process

Fewer requirements defects
Reduced development rework
Fewer unnecessary features
Lower enhancement costs
Faster development
Fewer miscommunications
Reduced scope creep
Reduced project chaos
More accurate system-testing estimates
Higher customer and team member
4

Characteristics of Excellent
Requirements
Requirement Statement Characteristics
Complete
Correct
Feasible
Necessary
Prioritized
Unambiguous
Verifiable

Characteristics of Excellent
Requirements
Requirements Specification Characteristics
Complete
Consistent
Modifiable
Traceable

Requirements Realities
If you dont get the requirements right, it

doesnt matter how well you execute the rest

of the project
Requirements development is a discovery and
invention process, not just a collection process
Change happens
The interests of all the project stakeholders
intersect in the requirements process
Customer involvement is the most critical
contributor to software quality
7

Requirements Realities
The customer is not always right, but the

customer always has a point

The first question an analyst should ask about a
proposed new requirement is, Is this
requirement in scope?
Even the best requirements document cannot
and should not replace human dialogue
The requirements might be vague, but the
product will be specific
Youre never going to have perfect requirements
8