Using Requirements Specifications to Define Goals
Requirements specification involves
refining the project goals so you can decide what must be achieved to satisfy
Requirements specification takes place
before the formal commencement of a project to help identify and select the
right for a solution and technology.
Note: Also known as a feasibility study
or project analysis.
More typically however some requirements
are thrown together (maybe in a proposal) and the real requirements
specification occurs only after the project has started.
Functional requirements are the obvious
day-to-day requirements which end-users and stakeholders will have for the
product. They revolve around the functionality that must be present in the
project for it to be of use to them.
A functional requirement typically
states as “the system X must perform function Y”. This is known as an
‘assertion’. An assertion asserts or affirms a necessary or desirable behavior
for the system or product in the eyes of a stakeholder.
Without clear assertions requirements
are nothing more than vague discussions which have a regrettable tendency to
clutter up your desk and your mind.
Compare the two following, contrasting,
• Financial system must produce a
detailed customer invoice
• Producing an invoice for customers is
important. Invoices should contain all the pertinent information necessary to
enable a customer to supply payment for goods.
The first is a functional requirement
stated as an assertion. It indicates that the financial system is responsible
for producing a detailed customer invoice which contains all the information.
While it could be more specific, the reader is left in no doubt as
to what the financial system must do in order to be a successful financial
The second could be the introduction for
a chapter in an accounting book. Although it states that invoices are important
it gives no indication of whom or what is responsible for producing them. It
then rambles on about what goes in an invoice which everyone already knows
anyway. Such a statement does not belong in a requirements specification.
The second ‘requirement’ compounds the
problem by looking solid but really being vague and ambiguous. What does
pertinent information mean? To enable a customer to supply payment is
superfluous since that's what an invoice is for. The statement, while accurate,
contributes nothing towards our understanding of what the system must do to be
Here are some more ‘better’ statements
• A customer account record must contain
a unique account reference, a primary contact name, contact details and a list
of all sales to the customer within the past sales year
• Contact details must consist of a
phone number, an address and an optional email address
• For each contact up to five separate
phone numbers should be catered for
It is essential to consider other
requirements too; these are called “non-functional requirements” which, to my
mind, is a bit of an oxymoron. The point however is valid, there are 'obvious'
requirements that your end-users may not think about it.
Performance -Performance covers areas
like responsiveness, throughput and speed of operation. What is the minimum
performance that will satisfy your client?
- Usability - How “easy-to-use” will the
finished product is? For example do you cater for disabled or handicapped users?
Generic ease of use should be considered. More than one product has failed by
supplying full functionality with an obscure or convoluted interface.
- Reliability - Reliability requirements
deal with the continuous availability of the product to users. They should state
what availability is necessary and desirable.
- Security - In products which deal with
confidential or sensitive information, security considerations should be taken
into account. Requirements for different levels of access, encryption and
protection should be gathered.
- Financial - Financial considerations
which will determine the success or failure of the project. For example a bank
or investor might specify certain financial constraints or covenants which must
be satisfied during the project.
- Legal - There may be legal requirements
that must be met due to the environment in which your product will operate.
Consult a legal expert for these.
- Operational - There may be a number of
day-to-day operational issues that need to be considered. Failure to accommodate
these will not delay project launch but may limit or halt its uptake by
end-users once it has been launched.
- Specialist -There might be special
requirements that are dependent upon the nature of the project or the nature of
the business. You should considered these separately and state them explicitly
in design docs.
- Stakeholders - Stakeholders are an
integral part of a project. They are the end-users or clients, the people from
whom requirements will be drawn, the people who will influence the design and,
ultimately, the people who will reap the benefits of your completed project.
It is extremely important to involve
stakeholders in all phases of your project for two reasons. Firstly, experience
shows that their involvement in the project significantly increases your chances
of success by building in a self-correcting feedback loop. Secondly, involving
them in your project builds confidence in your product and will greatly ease its
acceptance in your target audience.
There are different types of
stakeholders and each type should be handled differently:
1. Executive - Executive stakeholders are
the guys who pay the bills. Typically they are managers or directors who are
involved with commercial objectives for the project. They should restrict
themselves to commercial considerations and be actively discouraged from being
involved in technical design, their experience and skills are vastly different
to that of 'typical' end-users.
2. User - These are the guys that are
going to use your product. No one knows more about what the product is supposed
to do when it hits their desks than they do. No one ! Including you ! You may
think you know better but if you don't listen to them you're kidding yourself.
3. Expert - Sometimes you need input from
experts in other fields. People like graphic designers, support reps, sales or
lawyers and accountants.
How to Capture Requirements
Requirements capture is the process of
harvesting the raw requirements of your stakeholders and turning them into
something useful. It is essentially the interrogation of stakeholders to
determine their needs. This can take many forms, with questionnaires or
interviews being the most popular. The usual output is a 'requirements
specification' document which details which of the stakeholder requirements the
project will address and, importantly, which it will not.
The focus in requirements capture must
be in gathering of information. Keep your ears open and your mouth shut! Listen
carefully to what people want before you start designing your product. Later you
can focus on how things are to be achieved for now you need to find out what
must be achieved.
In reality this is difficult to achieve.
Technical people complain that stakeholders often “don't know what they want”.
This is not true. Stakeholders know exactly what they want – they want less
hassle, easier jobs and so on. The problem is that they can't design the system
for you, they can't tell you how to achieve what they want. The trick in
requirements specification is to take what the stakeholders give you and distil
it into something you can use to help you make decisions on how to implement
their wishes. One way to think of this is as finding the ideal solution to the
stakeholder’s current problems.
Requirements capture also needs to be
fast. Projects have a tendency to bog down at this stage and to produce reams of
documentation, but no useful output. Requirements capture should not produce
endless tomes detailing the answer to every possible question but should provide
enough clarity for the project team so that the objectives are clear.
Questionnaires are a typical way of
gathering requirements from stakeholders. By using a standard set of questions
the project team can collect some information on everyone's needs. While
questionnaires are efficient for rapidly gathering a large number of
requirements their effectiveness can be limited since it is a one way process.
If you don't ask the right questions, you don't get the right answers. There is
also no way to seek clarification or resolve conflict. To resolve this,
questionnaires are usually used in conjunction with other methods, such as
The same questions posed in a
questionnaire can be put across a table in an interview. The benefit of the
interview is that it allows more exploration of topics and open ended discussion
on the requirements for the project. It's a two way process.
Interviews can either be structured as
single or group sessions. Particular stakeholders can be interviewed
individually or a group session can be used thrash out ideas amongst a larger
number of stakeholders (and hopefully obtain consensus). In a group session you
can use a formal structure or a more open style where ideas are thrown around, a
brainstorming session. The best ideas that survive can be adopted by the project
team as part of the requirements.
The down-side to interviews is that they
are time and people intensive. Not only must the interview be set up and
conducted but minutes must be taken, distributed and reviewed, and it may be
necessary to hold one or more follow-up meetings. Using questionnaires and
interviews is a common and efficient practice; questionnaires can be distributed
beforehand and an overview of the stakeholder’s requirements collected. The
interviews are then focused and directed towards the clarification of those
Another method of requirements capture
is direct end-user observation or evaluation.
The purpose of user observation is to
capture requirements that the end-users may not be consciously aware of. For
example individuals using a check processing system in a large finance system
may conduct a number of manual steps outside of the system that could be
automated. Because they don’t regard these steps as being part of the system
they will not mention them when questioned about the incumbent system. Only by
direct observation will the development team become aware of the importance of
You can either use free-form observation
or you can take a typical group of end users are set a series of tasks and
monitor their processing of these tasks. Notes are made on the way they conduct
the tasks, any obstacles they encounter and you could even video tape it (if
Direct user observation is particularly
powerful because, unlike the first two methods of requirements capture, it
relies on observed fact and not upon opinions. It is however, the most resource
intensive of the three techniques.
One or more requirements may contain
elements that directly conflict with elements of other requirements. For
example, a performance requirement may indicate that a core system must be
updated in real time but the size and scope of the system (as defined by other
requirements) may preclude this. Updating such a large system may not be
possible in real time.
One of the most effective ways of
resolving conflicts between requirements is to impose some form of
prioritization. This allows the potential for negotiation since it provides a
basis for assessing conflicting requirements. For example if, from the previous
example, the requirement for real time updates was rated at a much higher
priority than the inclusion of full customer data, then a compromise could be
reached. The main ‘online’ database could contain only the barest essential of
customer details (allowing real time updating) and a separate ‘archive’ database
could be established which contained customer histories.
You need a way of documenting your
requirements for your project team. Stakeholders are also often asked to sign
off their requirements as a confirmation of what they desire. Often this is
where money starts to change hands.
Documenting requirements is much more
than just the process of writing down the requirements as the user sees them.
The requirements specification is an essential link in the total design of the
whole project and attempts to give meaning to the overall goals of the project.
Whatever form of requirements
documentation is used it should cover not only what decisions have been made but
also why they have been made. Understanding the reasoning that was used to
arrive at a decision is critical in avoiding repetition.
For example, if a particular feature has
been excluded because it not feasible, this must be recorded.
If not, then the project risks wasted
work and repetition when a stakeholder requests the feature be reinstated later
in the project.
Documenting the decision process is also
useful from a stakeholder's point of view. It allows the stakeholders to better
understand what to expect from the final product. A basic statement of
requirements without any underlying discussion can be difficult for a layman or
end-user to understand.
One useful acronym for defining
requirements is SMART:
Specific - A goal or requirement must be
specific. It should be worded in definite terms that do not offer any ambiguity
in interpretation. It should also be concise and avoid extraneous information.
Measurable - A requirement must have a
measurable outcome; otherwise you will not be able to determine when you have
Achievable - A requirement or task should
be achievable; there is no point in setting requirements that cannot
realistically be achieved.
Relevant - Requirements specifications
often contain more information than is necessary, concise and coherent.
Testable - To be of value requirements
must be testable. You must be able to prove that the requirement has been
satisfied. Requirements which are not testable offer no way to determine if they
have been delivered.
The Language and Layout of Requirements
Requirements specifications have
multiple audiences. They are used by the project team to deliver the project,
and they are used by stakeholders to verify what is being done. While I advocate
including contextual information to illustrate why a particular decision was
taken there needs to be some way of easily separating the discussion from the
So I apply the following rules of thumb:
• For each requirement there should be
an “assertion”; in essence, a decision
• Where assertions are documented they
should consist of a single sentence which states what a product “must” or
• “Must” indicates a necessary
requirement / “should” indicates a “nice-to-have”.
• There must be simple (visual) way to
distinguish assertion from discussion
Below is an example with some discussion
and the assertion highlighted with italics:
Usability – usability of the system
is seen as very important to adoption of the system. The client raised some
concerns about the time scales required to implement usability testing but the
project team as a whole supported extending the time line for the development
phase to include usability testing.
The system must be simple and easy to
use and must follow the standard UI style as laid out in the company design
In this case the discussion is preserved
for future reference but the requirement stands out distinctly from the body of
the text. A project member reading the specification can skip through it and
pull out the requirements quickly and easily. A manager reading through the
document can do the same but also can review the context of the decision to
understand how it came about.
While you can specify specification in
textual form, more graphical methods are available. As the saying goes, a
picture is worth a thousand words, and this is both a blessing and a curse.
While representing information with a picture or diagram can be extremely
informative it can also be extremely confusing. Diagrams can often imply
requirements without actually stating them and leave details open to
For this reason I see graphical methods
as supporting standard textual methods of description. They should be used
wherever appropriate, where the graphical nature of a representation will more
closely represent the nature of the requirement. If you find it difficult to
explain in words the nature of a particular structure or process then by all
means insert an appropriate diagram.
The emphasis must be on concise,
accurate representations, so use whatever combination of graphical and textual
elements seems right to you.
Sample Requirements Specification
The most common method is to break down
the requirements in an outline fashion as used in a document or manual.
1. Current product status – all parties
highlighted the need for a clear and public indicator of the current status of a
2. Dates - dates for each major
milestone were also recognized as necessary. Although some of these dates will
remain in the public domain others will be available only to “private” users.
Private users will have the ability to publicize dates as they see fit.
The dates specified are:
2.1 Development sign off
2.2 Testing sign off
Even more structure can be put into the
document by splitting up requirements categories:
1. Functional Requirements
1.1. Product list – the system
should produce a list of products available or under development
1.2. Current product status –
all parties highlighted the need for a clear and public indicator of the current
status of a product. There should be a simple flag which indicates at-a-glance
whether the product is ready for release.
1.3. Dates – for each product,
dates for each major milestone must be shown. Although some of these dates will
remain in the public domain others will be available only to “private” users.
Private users should have the ability to publicize dates as they see fit.
The relevant dates are listed below:
1.3.1. Design sign off
1.3.2. Development sign off
1.3.3. Testing sign off
2.1. Performance – the system
must be updated daily and information available to all international users
within 1min of the information being posted by head office.
2.2. Usability – usability of
the system was seen as very important to adoption of the system. The system must
be simple and easy to use and must follow the standard UI style as laid out in
the company design handbook.
2.3. Security – access to
schedule information must be controlled on a per-user basis. Access to the
information should not be available to any external customers or companies.
It is best to be as specific as possible
but remember the 10th commandment and be flexible. If your project doesn’t
warrant this level of detail then don’t include it; or you will spend all your
time writing documentation. Find a happy medium between detail and effort that
suits you and your organization’s needs.
Project Management Tutorials:
Project Management Templates
Here are some Project Management templates you can get
on our partner's site.
Management Kit provides the documentation required to
control changes to the scope, deliverables and resources within
the project. The Change Request template allows staff to raise a
change request within the project.
Project Planning Kit provides you with all of the
project management templates, documents and forms required to
plan a project by helping you to schedule time, cost and
Quality Management Kit includes a suite of templates
used to assure and control the quality of deliverables within a
Start a new project by documenting a business case, undertaking
a feasibility study, defining the project scope, recruiting key
staff and locating them within a project office.
Manage time, cost, quality, change, risks and issues during the
execution of your project, as well as supplier procurement and
Helps close your project by handing over deliverables and
documentation to the customer, terminating supplier contracts
and releasing resources back to the business.