REQUIREMENTS MANAGEMENT: HOW IT

BENEFITS YOUR BUSINESS

TERRA FIRMA JULY 2013

In 2001, a group of researchers set out to develop a definitive list of risk factors as a reference tool for
i

project managers . They had a significant incentive their preliminary research indicated that:

25% of projects were cancelled outright without delivering anything of value

80% of projects overran their budgets, with an average budget overrun of 50%

75% of large system projects delivered operational failures, with the final product either not
functioning as specified or not being used.

ii iii iv

The researchers recruited three expert panels of project managers with extensive experience working
on major projects; one group in Hong Kong, one in Finland and one in the United States. Each group
collaborated to produce a ranked list of project risk factors, which was combined into a single ranked list.
Poor requirements management made it into the Risk Top Ten twice: at number two (requirements not
thoroughly defined) and number six (constant changes to requirements). More recently, CIO magazine
estimated that up to 71% of projects which failed did so because of poor requirements management.

THE HIGH COST OF PROJECT FAILURE

The cost of project failure is high: the Standish Group has estimated that total waste on project overruns
in the United States alone was $US55 billion per annum and a more recent McKinsey Report identified
vi

total cost overruns of $US66 billion across 5,400 projects studied. To put this in perspective, there are
182 countries in the International Monetary Fund: the 20112012 GDP for 106 of those countries was
less than $US66 billion. When you think that a relatively small group of people (5,400 project teams) can
lose more money on a single project than an entire country can generate in a 12 month period, the
scope of the problem becomes evident.
How does that apply to your organisation? Lets assume that the average budget overrun of 50% has
remained constant. That means that for every $100 your organisation spends on projects, you are

Terra Firma Pty Ltd

Page | 1

getting approximately $66 of value and losing roughly $33 in cost blowouts. Consider your current year
budget for IT upgrades, change initiatives and other projects. Can you really afford to waste 33% of that
money?

MANAGING REQUIREMENTS TO ENSURE SUCCESS

The concepts of requirements and requirements management have been around since the early days of
software engineering over this period, a number of methodologies have been developed to improve
the requirements management process.
Essentially, each methodology describes a four step process:
1. Requirements elicitation, when requirements are gathered from stakeholders and documented.
2. Requirements analysis, when the requirements are checked for clarity, completeness and
consistency. At this point, the business analyst begins to engage with stakeholders to prioritise
and validate the requirements.
3. Requirements documentation and validation, when requirements are logged or documented
and the stakeholder input is finalised and agreed.
4. Requirements traceability, where the outputs of the project are monitored and measured to
confirm that they meet the requirements.

ELICITATION
A well-run elicitation phase helps to ensure that all requirements are identified. This allows the
requirements to be defined appropriately and reduces the risk of constant or ongoing changes to the
requirements.
During the elicitation phase, the business analyst works with the project stakeholders to develop a list of
requirements that the project must deliver. There are different schools of thought on the amount of detail
required to complete this stage: some projects have thousands of documented requirements, whereas
an Agile project might only have half a dozen, documented as user stories.
During the elicitation phase, keep an eye on the level of detail in the requirements. In some cases, a
project is derailed by too much detail. This often happens when the stakeholders have had bad
experiences with projects which have under-delivered in the past: they decide that the best way to avoid
this happening again is to provide minutely detailed functional requirements covering every possible
feature of the project and to insist that every requirement is absolutely essential to success. The end

Terra Firma Pty Ltd

Page | 2

result is usually an unwieldy mess of confused and sometimes contradictory requirements that cannot
possibly be met by any deliverable.
Other common pitfalls during the elicitation phase are gathering too little information or not ensuring that
requirements meet the key characteristics of a requirement (as sent out in the Business Analyst Body of
vii

Knowledge (BABOK)) . In this case, the project will either spin its wheels while the developers try to
clarify vague requirements or deliver something which is the development teams approximation of what
they thought the user wanted.
These issues can be corrected relatively easily by meetings with stakeholders. Use a root cause
analysis or similar technique to find out what is driving the over or under performance, and work with all
parties to bring the process back on track. This problem can also be identified and corrected during the
analysis phase.

ANALYSIS
Analysis ensures that the requirements are thoroughly defined before being signed off. This also
reduces the risk of constant, ongoing changes to the requirements.
Analysis may occur concurrently with or following the elicitation phase. During this phase, the
requirements are checked for clarity, consistency and completeness. The business analyst may also
begin to engage with the stakeholders to validate and rank the relative importance of the identified
requirements.
Projects may run into difficulty here if stakeholders insist that every requirement is equally important, or
if there are significant differences in the importance that different stakeholder groups place on
requirements. The first issue is likely to lead to time and budget overruns, as the development team
attempts to build the perfect product. The second is likely to lead to conflict (and time and cost
overruns!) as the project team try to work out whose high priority requirements get built and whose are
shelved for later releases.
The good news is that these issues can be resolved quickly and cheaply by negotiation. If necessary,
the project sponsor or another senior person should be asked to mediate until a satisfactory prioritisation
has been agreed on.

DOCUMENTATION AND VALIDATION

This is the final opportunity for the business analyst to ensure that the requirements have been
thoroughly defined. Once requirements have been documented, signed off and passed to a
development team, the cost of changes escalates (as does the risk to the project from each change).

Terra Firma Pty Ltd

Page | 3

During this phase, the business analyst documents the requirements and obtains stakeholder
agreement that the requirements accurately reflect their needs. A well-defined requirement has the
viii

following characteristics:

Unitary (only addresses one thing)

Complete (fully stated, no missing information)

Consistent (does not contradict any other requirement or other authoritative document)

Atomic (no ands or buts remember, it must be unitary)

Traceable (meets a business need identified by stakeholders)

Current (has not been made obsolete by time or project progress)

Unambiguous (can only mean one thing)

Verifiable (possible to demonstrate that the requirement has been met by the deliverable).

During the analysis phase, any requirements that do not meet the characteristics of a good requirement
can be taken back to stakeholders and refined with relatively little cost to the project. Perform a careful
review before signing off and releasing requirements to the development team for action!

TRACING
Throughout the development phase, the business analyst confirms that the deliverables meet the
documented requirements. This is usually done through the various testing processes, which involve a
tester completing a series of steps to demonstrate that a deliverable meets one or more requirements.
As development proceeds, the cost of remedying defects or shortfalls against requirements becomes
higher. Ideally, the project should control against this risk by implementing stringent quality control
procedures to ensure that each deliverable is measured against the requirements during development
and prior to release.
A sound requirements change process also reduces risk, by eliminating unnecessary changes to
requirements and ensuring that the impact and risks of any required changes is fully understood.

Terra Firma Pty Ltd

Page | 4

CONCLUSION
Bad requirements management is a common cause of project failure, leading to significant financial
losses. Careful requirements management and a swift response to any issues will mitigate this risk.

AUTHOR CONTRIBUTIONS: Andrea Tappe

Schmidt, R., Lyytinen, K., Keil, M. And Cule, P., Identifying Software Project Risks: An International Delphi Study, Journal of
Management Information Systems, 17, 4, pp 536
ii
Gibbs, W.W., Softwares chronic crisis, Scientific American, 271, 3 (September 1994), 86-95
iii
Johnson, J., Chaos: the dollar drain of IT project failures, Application Development Trends, 2, 1 (January 1995), 41-47
iv
Walkerden, F. And Jeffery, R. Software cost estimation: a review of models, processes, and practice, Advances in Computers,
Vol 44, San Diego; Academic Press, 1997, pp 6294
v
Lindquist, C., Fixing the Software Requirements Mess, CIO, 15/11/2005,
http://www.cio.com/article/14295/Fixing_the_Software_Requirements_Mess_?page=2&taxonomyId=3038 accessed 11 March
2013
vi
Standish Group (2004). CHAOS Report. West Yarmouth, Massachusetts: Standish Group
vii
Business Analyst Body of Knowledge (BABOK)
viii
Business Analyst Body of Knowledge (BABOK)

CONTACT US
If you require assistance with Requirements Management, Terra Firma can help. Our
experienced consultants can guide you through elicitation, analysis, documentation and
traceability.

Contact us today at info@terrafirma.com.au.

Terra Firma Pty Ltd

Page | 5