Chapter 4

Writing Requirements

By Yengusie D.
Contents
Introduction
Common Mistakes in Writing
Requirements
Good Requirements
Characteristics of a
Good Requirements
Requirement documents
Requirement Document
What is requirement document
Why Write Requirements Documents?
General principles for writing requirement
Introduction
Writing the requirements refers to the task of
putting together a description of the product from
the business point of view.
It is appropriate to think of this activity as
building a specification: You assemble a
specification, one requirement at a time, rather
than writing it all at once.
 For larger and more formal projects you should
write a software requirements specification (SRS)
Input for requirement specification are outputs
of requirement analysis & negotiation - prioritized
& modeled requirements, assumptions &
constraints, & requirement structure
And outputs of requirement specification is a
Introduction…
Many software requirements specifications
are filled with badly written requirements.
Because the quality of any product depends
on the quality of the raw materials fed into it,
poor requirements cannot lead to excellent
software.
Avoid the following mistakes for writing better
requirements
 Using incorrect terms
Making bad assumptions
 Writing implementation (HOW) instead of
requirements (WHAT)
 Describing operations instead of writing
Common Mistakes in Writing
Requirements
Improper or imprecise terminology -
avoid using the following words or phrases:
etc. state of safe appropriat
and so on the art reliable e
user-
among others robust suitable
any friendly adequate possible
several easy
acceptableaverage
various simple timely
normal
and/or rapid typical
proper
not limited 
toefficient reasonablesecure
as well as improved optimum
or optimal
sufficient
 Common Mistakes in Writing
Requirements…
 Bad assumptions - can happen when:
 no system documentation or user input exists. You
make assumptions in order to proceed, and some
of your “guesses” are wrong.
 system documentation or user input exists, but is
not available to you. This can be caused by politics,
bureaucratic red tape, or incompetence anywhere
in the chain.
 Forcing the design - requirements need to
state what is needed, not how it is to be
implemented. To avoid forcing the design,
continually ask “Why?” This will often turn up the
underlying needs that drove the original
statement.
Common Mistakes in Writing
Requirements…
 Specifying how the user will use the
product rather than what the product
should do for the user.
 Don’t – “The user shall operate the treadmill only
in an upright position.” This is a requirement on
the user, not the treadmill.
 Do – “The treadmill shall only run when it is in an
upright position.” This keeps the treadmill from
operating in an unsafe condition.
 Failing to assign responsibility for a
requirement.
 Don’t – “The treadmill shall be returned to a safe
state whenever an error condition is
encountered.” This is in the passive voice, and
Common Mistakes in Writing
Requirements…
 Over-specifying requirements.
 Don’t – “All source code shall be reviewed by a
safety engineer before inclusion in a release.” This
is overly restrictive. Only the safety critical
portions of the code need to be subject to such
stringent reviews.
 Do – “The source code for all safety critical
functions shall be subjected to a formal inspection
before inclusion in any release.”
 Other mistakes
Using incorrect sentence structure or bad
grammar - requirements should be easy to read
and understand.
Unverifiable - Every requirement must be verified.
 Common Mistakes : Examples
Requirement: The treadmill control module shall
run on an RT214 real-time processor.
Questions to ask: Do we have to have a control
module? Why does the control function have to
run on an RT214 real-time processor?
Better: The treadmill shall initiate emergency stop
within .03 seconds of detecting a critical error.
Requirement: The treadmill shall store the time
and distance traveled in a database after each
session.
Questions to ask: Why does it need to be stored
in a database? Could we store it in a file or in
Read-Only-Memory instead?
 Common Mistakes : Examples…
 Requirement: The treadmill shall be used in a manner
consistent with BPC-243.5.7.
 Questions to ask: Isn’t this a requirement against the
user, not the treadmill? Watch out for references to
external specifications or guides – try instead to write
your own requirements that capture the real needs.
 Better: The treadmill shall comply with BPC-243.5.7,
Section 8, dated 24 August, 2005.
 Best: The treadmill shall power itself off when its
current flow reaches
 Requirement: 90% of
The treadmill its rated
shall have maximum.
a sufficiently
long ramp.
 Questions to ask: Sufficiently for what or whom?
 Better: The treadmill ramp shall be long enough that a
user can run at 10 mph with a 5.5-foot stride and not
 What Makes a Requirement

Good?
A good requirement is written clearly enough
that you can implement it, and you will know
when it has been done correctly.
This means:
“Not good” requirements are still okay as inputs
to requirements analysis.
Once your project has finished requirements
analysis, all of the requirements in the spec and
any new ones you add need to be “good”.
Good requirements have the following
categories of characteristics
Applicable to individual requirements:
Correctness, Necessity, Clarity, Focus, Feasibility,
What Makes a Requirement
Good?...
Don’t expect to create an SRS in which
every requirement exhibits all of these
desired characteristics.
No matter how much you scrub, analyze,
review, and refine the requirements, they
will never be perfect.
However, if you keep these characteristics in
mind, you will produce better requirements
documents and you will build better
products.
Correct – A requirement has to be correct.
 The information used to create it has to be
correct and has to reflect reality.
Characteristics of a Good
Requirements…
Necessary – A requirement has to be
necessary.
If it wasn’t included, what’s the worst that could
happen? If you and the users are willing to accept
those consequences, then it probably isn’t really
necessary.
Clear – A requirement has to be clear and
unambiguous.
 If it can be interpreted in more than one way, then
the product is indeterminate (you don’t know
exactly what you’re building), and you’ll never
know when you’re done.
Three words to use carefully:
Shall – specifies a feature or function that is
required in the product and which the product
development team must provide. REQUIREMENT
Characteristics of a Good
Requirements…
Should – specifies a desired or optional feature or
function of the product. The product development
team can choose not to implement the feature or
function and still develop an acceptable product.
CONSTRAINT or SUGGESTION
Examples
Shall – “The maximum speed of the treadmill
shall be 10 mph.” The treadmill must be built to
enforce this limit.
Will – “The treadmill speed will not exceed 10
mph.” This is a statement of fact – no one is
responsible for this happening.
Should – “The treadmill speed should not
exceed 10 mph.” The treadmill can be built to
exceed this limit if it has to, but it would be
better if it did not.
Characteristics of a Good
Requirements…
More Clarity in a Requirement
Write requirements simply and use the language of
the problem domain so that users can tell you if
they’re correct or not. To insure clarity:
do formal inspections of the requirements.
whenever possible, write high-level test cases to
accompany any requirements you want to “add”.
Focus(not amalgamated) – A requirement has to
focus on one thing.
Don’t write one requirement that specifies multiple
needs – instead, break it up into several
requirements.
Don’t – “The meter shall display a minimum of -
999 and a maximum of 999 volts.”

Characteristics of a Good
Requirements…
Precise
The bounds of the requirement should be
evident and unambiguous. In the case of
numerical bounds, it ought to be evident
whether the end-points are included or not.
A great contributor to precise requirements is
consistency in the means used to represent
bounds. Words such as “inclusively” and
“exclusively” should be used with care so they
are consistent.
Examples
The system shall accept valid employee ID
numbers from 1 to 9999.
Are all numbers between 1 and 9999 valid? Is 2
 Characteristics of a Good
Requirements…
Feasible – A requirement must be
feasible/practical.
If you cannot implement it with the budget,
schedule, resources, and other limitations that are
available to your project, then either it must be
dropped or the project has already failed. Designers
and developers need to work with the requirements
analysts to figure this out.
Verifiable – A requirement has to be
verifiable/testable.
Once a solution for a requirement has been
implemented, you need some way to know if the
design and implementation are correct. If you can’t
test the requirement, then the product is
Characteristics of a Good
Requirements…
Ask for a template before you begin, or use
existing requirements as an example (either
from this project or from a similar one).
Examples of Supporting Documentation
The originator – where did this requirement come
from? If there are questions during design or
implementation, who will you talk to? The
originator should include the name and title of the
person or document that was the original source.
The originator’s priority – what priority does he/she
give to each of the requirements they provided?
Explanatory comments - what does the
development team need to know in order to
understand this requirement? Include text that
expands operational details, translates obscure
language, or further explains the conditions that
 Good Requirements: Examples
Requirement: The treadmill shall run on 10 or 220
VAC power.
Questions to ask: Is this a typo? Shouldn’t it be
“110 or 220”?
Requirement: The treadmill shall have 3-inch thick
Better: The treadmill shall run on 110 or 220 VAC
BU47 foam padding covering the frame and control
power.
panel to reduce the damage of any impact.
Questions to ask: Is this really necessary? Can
you use the treadmill with this in place? Will
anyone buy it?

Requirement:
Better: Get ridThe treadmill
of this shall support a
requirement.
maximum load of three.
Questions to ask: Three what? This is ambiguous
and unclear.
 Good Requirements:
Examples…
Requirement: The treadmill shall not start
unexpectedly.
Questions to ask: Unexpectedly? If it works as
designed, but starts when the user increases the
velocity setting (even though the on/off switch is
off), is that unexpected?
Better: The treadmill shall never start when the
Requirement: The treadmill shall run continuously
power control is set to “off”.
for 5,000 hours at 5 mph without failing.
Questions to ask: How are we going to test this?
Is it possible? Is it necessary?
Better: The treadmill shall have a Mean Time
Between Failure (MTBF) of less than X with . . .
Characteristics of Set of Good
Requirements
Complete
The set of requirements must be complete. If
requirements are missing, then the product will
also be incomplete. It is likely that the missing
requirements will turn up at inopportune times
and cause problems throughout the project life
cycle.
How Do We Find Missing Requirements?
one way to find missing requirements is to
have a checklist of the kinds of requirements
you have created on similar projects, or to
which similar systems are subject. As you
review this list, you will discover missing
requirements.
Characteristics of Set of Good
Requirements…
Consistent
The set of requirements must be consistent. If
there are requirements in your specification
that conflict with each other, then the product
will not be able to meet all of your
requirements. Inconsistencies must be
resolved in order for your project to succeed.
Updateable
They must be updateable. If you have to
change a requirement (create, edit, or delete),
you must be able to evaluate the impact of
that change on all of the other requirements.
Organize your requirements into categories by
their scope or purpose. When one requirement
Characteristics of Set of Good
Requirements…
Traceability
The set of requirements must be traceable.
You must be able to tie a derived requirement
back to its origin, and you must be able to
trace a requirement to the hardware/software
that implements it, as well as to the test cases
that verify it. The traceability to test cases tells
you if you have tested your product against
each requirement.
Prioritization
Each requirement has to be ranked against the
others according to its implementation
importance. You can’t have everything be a top
priority.
 Writing Requirements...
Problems with requirement writing are
use of complex conditional clauses which are
confusing
sloppy and inconsistent terminology
writers assume readers have domain knowledge
Requirements are read more often than they
are written. You should invest time to write
readable and understandable requirements
Do not assume that all readers of the
requirements have the same background and
use the same terminology as you
Allow time for review, revision and re-drafting
24
of the requirements document
Guidelines for Writing Quality
Requirements
There is no formulaic way to write excellent
requirements.
It is largely a matter of experience and
learning from the requirements problems you
have encountered in the past.
Here are a few guidelines to keep in mind as
you document software requirements.
Keep sentences and paragraphs short. Use the
active voice. Use proper grammar, spelling,
and punctuation. Use terms consistently and
define them in a glossary or data dictionary.
To see if a requirement statement is
sufficiently well defined, read it from the
Guidelines for Writing Quality
Requirements…
 Write requirements at a consistent level of
detail throughout the document.
 Avoid stating requirements redundantly in the
SRS.
Requirement authors often struggle to find the
right level of granularity. Avoid long narrative
paragraphs that contain multiple requirements.
Define standard templates for describing
requirements
Use language simply consistently and
concisely
Use diagrams appropriately
Supplement natural language with other
description of requirements
Guidelines for Writing Quality
Requirements…
The requirements also need to be written so that
the product designers and other technicians can
build precisely what the client wants.
To ensure correctness, and to make the
requirement testable, the analysts add a fit
criterion to each requirement.
A fit criterion is a quantification or measurement of
the requirement so the testers can determine
precisely whether an implementation meets the
requirement.
Example
Requirement: The product shall be user-friendly.
Fit Criterion: New users shall be able to add a road,
27 change a road, and delete a road within 30 minutes of
their first attempt at using the product.
 What Is a Requirements
Document?
The software requirements document is a written
statement of what the software will do.
Requirements document states what the software
will do.
The requirements document describes:
The services and functions which the system should
provide
The constraints under which the system must
operate
Overall properties of the system i.e.. constraints on
the system ’s emergent properties
Definition of other systems which the system must
integrate with.
Information about the application domain of the
 Why Write Requirements
Documents?
 Although writing a complete requirements
document is time-consuming, there are many
advantages to having one.
 can avert misunderstandings down the road and
save time that later might be wasted in rework.
 help set expectations about what will and will not
be accomplished in the current development cycle.
 Serves as a guide to development and testing
throughout the project.
 If you have a list of everything your product should
do, it's easier to create a product that does
everything you wanted
 help you schedule time and resources more
efficiently and to plan your project more accurately.
 Who Uses the Requirements Document
and Why?
 There are many distinct roles in each software
development project.
Below are list of the project roles and the reasons
for each role to use the requirements document.
 Requirement document...
The requirements document should
include an introductory chapter
user requirements for a system and a
detailed specification of the system requirements.
Write a requirement based on a template,
e.g. IEEE830-1993
The IEEE standard is a generic standard which is
intended apply to a wide range of requirements
documents
 In general, not all parts of the standard are
required for all requirements documents
Each organization should adapt the standard
32 depending on the type of systems it develops
 Requirement Document- IEEE/ANSI
830-1993

33
 Requirement Document- IEEE/ANSI
830-1993

34