How to Write
SMART
Requirements
Presented for the
January 2013 IIBA Columbus Chapter by:
Kate Gwynne, CBAP
Associate Director of Business Analysis for Resource
[email protected]
2
3
The average amount of project rework that takes place.
4
How can we reduce rework?
5
How can we reduce rework?
1. Incorporate a change management process to manage
scope creep
2. Set expectations with clients and stakeholders
3. Manage risks and issues
4. Utilize the right project methodology (waterfall, iterative, agile)
5. Improve requirements communication
6. Manage requirements traceability
What exactly is a
requirement?
6
What exactly is a
requirement?
7
A
condition or capability needed by a
stakeholder to solve a problem or achieve an
objective.
A
condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or
other formally imposed documents.
Business requirements
 Address
 Identify
the business problem or goal.
why the project is being undertaken.
 Are
statements that leads the company to
increase revenue, decrease costs, or enhance
service.
 Detailed
Business Requirements are the solution to
the business problem.
8
User requirements
 Address
user related issues, needs, or
expectations.
 Identify
how the user will interact with the
 Express
from the user’s point of view.
system.
 User
Requirements are driven by the tasks an
end-user needs to perform or a capability they
want.
9
System requirements
•
•
•
•
•
Functional
Capabilities of the
solution
Conditions that must
exist
Express behavior of
solution
Feature-driven
Specific action and
response




Non-Functional
Environmental conditions
under which solution
must remain effective
Describe quality of
solution
Service- and
performance-driven
Also known as Quality of
Service or Supplementary
Requirements
10
11
Why bother with
requirements at all?
The cost of missed
and inaccurate requirements
12
$$$$$$
$$$$$$
$$$$$$
$$$
$$
$
Planning * Requirements * Design * Build * Test * Deploy * Support
13
So what makes a
good requirement?
14
So what makes a
good requirement?
Attainable
Complete
Consistent
Correct
Allocatable
Does not prematurely
determine solution
Requirement
Verifiable
Feasible
Measurable
& Testable
Understandable
Necessary
Unambiguous
Traceable
Prioritized
15
Understandable
Complete
Unambiguous
Necessary
Correct
Attainable
Consistent
Measurable
Allocatable
& Testable
Feasible
Verifiable
Does not prematurely
determine solution
Prioritized
Traceable
16
Specific
Requirements are:
Concise & Complete
17
Specific
18
Requirements are:
Concise & Complete
Does this requirement contain the proper amount of
detail – no more or less than what is needed?
Is this requirement free from FANBOYS, which could mean
too much detail or multiple requirements?
For-And-Nor-But-Or-Yet-So
Are all terms and acronyms in this requirement defined in
the document?
Measurable
Requirements are:
Testable & Unambiguous
19
Measurable
20
Requirements are:
Testable & Unambiguous
Can this requirement be interpreted only one way,
regardless of the reader’s perspective?
Is it clear how the final solution can be tested to prove
that this requirement is met?
Is this requirement free from adjectives or adverbs that
could make it subjective to the reader?
Accurate
21
Requirements are:
Correct & Consistent
The past, present,
and future walked
into a bar;
it was tense.
Accurate
22
Requirements are:
Correct & Consistent
Does the requirement reference the right system(s) or
application(s)?
Has this requirement been elicited from a valid source
of information?
Is this requirement written in an acceptable format for
the intended audience?
Relevant
Requirements are:
Necessary & Feasible
23
Relevant
24
Requirements are:
Necessary & Feasible
Is this requirement needed in order for the solution
(product, process, or system) to function properly?
Is this requirement within the scope of the project?
Is this requirement possible to achieve, given what is
known about the systems, resources, budget, and due
date?
Traceable
Requirements are:
Identifiable & Linked
25
Traceable
26
Requirements are:
Identifiable & Linked
Is this requirement uniquely identifiable through a
numbering hierarchy?
Can this requirement be traced to any appropriate
parent or child requirements?
If this is a technical requirement, can it be traced back
to one or more business requirements? If it’s a business
requirement, can it be traced back to the client goals or
business problem?
27
How do you know when you’ve
written SMART requirements?
28
How do you know when you’ve
written SMART requirements?
When your project team says so.
29
Requirements
Review
A Requirements Review is not . . .
30
A Requirements Review is . . .
D
e
v
G
a
l
SME
Get the right people in the room or on the phone to review requirements
from their groups’ perspective. They should provide
feedback that will help them do their jobs more efficiently.
31
To summarize,
SMART requirements . . .
•
Improve product quality
o
•
Reduce rework
o
•
Which satisfies the end-users
Which makes for a happy project team
Deliver on-time and in-budget projects
o
Which satisfies the sponsors
32
Benefits of
SMART requirements and requirements reviews . . .
Enables early
detection of
requirement
defects
Enhances
project team
communication
Expands
bandwidth for
BA, Dev, and
QA
Reduces
Rework
Improves
quality and
consistency of
requirements
Enables
requirements
users to provide
valuable
feedback