1.
RReeqquuiirreemmeennttss EExxcceelllleennccee ffoorr tthhee RRiigghhtt RReeaassoonnss
The goal of requirements excellence can be best reached using a value‐add
perspective. Driving requirements improvement from a “we need to do better”
generalization without target goals leads to “one size fits all” improvements that
may not serve the needs of an organization.
Introduction
As a requirements practitioner, tell me if this
story sounds familiar. A vendor is attempting
to promote a requirements software product.
The discussion begins with a reference to the
current state of affairs. Facts are listed as
evidence that there is a general state of failure
in software projects. Very often the infamous
Standish Group statistics from the Chaos
Report are trotted out. The next step is
pointing to requirements related problems as
the major culprit in project failures. Some
vendors show requirement problems as risk
factors in project failure, while others apply
blame directly. The equation is simply spelled.
We do a bad job of writing requirements and
as a result projects fail because of our
weaknesses.
What has been our response? More often
than not, we accept the criticism knowing we
can do better and promise to mend our
wicked ways. We promise to improve our
requirements because if we do not, projects
will fail. We accept the argument put forth
completely. If we’re feeling particularly
sensitive, we add a mea culpa, mea culpa, mea
culpa.
Action follows judgement and very often a
vendor product is purchased. Generalized
arguments in the framework of ‘we need to do
better’ launch the path to requirements
improvement.
Purpose
There are three primary objectives of this
article:
To challenge assumptions on the project
failure requirements linkage rolled out time
and time again.
To point out weaknesses in a “we need to
do better” improvement approach.
To illustrate that the goal of requirements
excellence can be best reached using a
value‐add perspective.
Challenging Assumptions
Consider the following points the next time a
vendor trots out the Standish Group statistics
and points out requirements as the weak link in
software project success.
1) Project success (and conversely project
failure) in the Chaos Report is defined from
a Project Management Professional (PMP)
perspective. A label of failure is assigned
when the delivery of a project exceeds the
triple constraints (time, cost, and
resources). That may be fine from a project
manager view but, as business analysts, our
bottom line is overall product success. It is
not always a one to one alignment. Ask
yourself this question, when considering
the issue of requirements failure, have the
requirements contributed to delivery of a
product that meets the needs of the
business?
Think outside the PMP box when you
consider the question of project success.
Scott Amber1
conducted a survey of
software industry professionals on the
subject of project success.
1
www.ambysoft/surveys/success2008.html
MRR Consulting, 2009 Page 1 of 4

2. RReeqquuiirreemmeennttss EExxcceelllleennccee ffoorr tthhee RRiigghhtt RReeaassoonnss
Challenging Assumptions (continued)
The following views were expressed by
the majority of the respondents:
a. Meeting the actual needs of
stakeholders is more important than
building the system to specifications.
b. Delivering high quality is more
important than delivering on time
and on budget.
c. Providing the best Return On
Investment is more important than
delivering under budget.
Ask yourself, how do you define project
success?
2) The cancellation of a project should not
automatically be treated as a negative. In
fact, we should applaud a project
cancellation when downstream
requirements analysis illustrates the ROI
no longer exists. We should congratulate
the Business Analyst when a solid
requirements effort determines the
business need can be met without
software development.
3) Simple analysis tells us that there is a
difference between correlation and
causation. Ask the vendor next time to
show the root cause research (Pareto
Analysis) applied to reach the conclusions
illustrated. As Business Analysts it is our
obligation to apply critical thinking and
challenge statements rolled out as
truisms.
Take the points just listed into consideration
the next time the Standish Group statistics are
rolled out. It is a much safer proposition to
state that solid requirements facilitate the
success of a project and product. Excellence in
requirements by itself is not a panacea for all
that ails a project.
The ‘We Need to Do Better’ Approach
The ‘We Need to Do Better’ approach typically
involves a broad‐brush, across the board
application of resources in response to a
judgment of requirements failure. Training is
rolled out, tools are delivered, and processes
are redefined. The latest ‘industry’ trend and
popular theory invariably gets incorporated.
Management reacts by throwing resources at a
problem with an expectation that requirement
improvements will result.
The following are two of the weaknesses that
apply to the ‘shotgun model of requirements
improvement’.
1) Resources are not aligned to respond to the
specific requirement challenges on an
organization. In many instances, training
provided is ‘industry standard’ with
elements that have no immediate relevancy
to Business Analyst’s in the client
organization. As an example, Entity
Relationship Modeling while beneficial to
new development projects has little
immediate benefit to application support
Business Analysts. Another example of
resource misalignment is introducing new
technology tools in a situation where
requirement challenges are actually rooted
within soft skills. The last illustration is the
usage of traditional SDLC project
environment as the primary model for
requirements improvement. If Business
Analysts reside predominantly in an
enhancement and support world then the
bulk of organization changes should reflect
this reality.
2) Requirements improvement is treated as an
end in itself. The Promised Land is better
elicitation, better modeling, better
documents, better traceability, and better
analysts. What’s not to like? Consider this
question. Does having better models always
facilitate the process of communication? In
some organizations, the answer is no.
Producing industry compliant UML models
adds little value if the business or
development team does not speak or utilize
the language. Our Agile brethren have a
solid point when they talk about the value
of working software over comprehensive
documentation.
2
Last point, I have had the
2
Agile Manifesto, 2001.
MRR Consulting, 2009 Page 2 of 4

3. RReeqquuiirreemmeennttss EExxcceelllleennccee ffoorr tthhee RRiigghhtt RReeaassoonnss
opportunity to work in multiple CMM
Level 3 organizations which score well on
requirements maturity but in practice do
not always deliver what the business
seeks. I have learned quite simply that at
the end of the day producing a
requirements document par excellence
buys me very little if it does not facilitate
delivery of a solution that meets the
needs of my business partner.
Let me be clear here. I have no argument with
focusing attention on requirements
improvement. Quite frankly, this is a step
forward for many organizations. The discipline
of requirements as a neglected step‐child in
the software product lifecycle finally gets
attention. After all, how can an organization
really expect to improve requirements when
no priority or importance is applied?
The challenge here is that the discipline of
business analysis rarely gets time and money
allocated. Consequently, we need to be both
frugal and smart in applying the resources
pointed our way. We do not want to be in a
situation of having applied effort over a period
of time without receiving demonstrable
results from a business perspective.
The Value‐Add Approach
In a value‐add approach, excellence in
requirements is pursued not as an end in itself
but instead as a means to add value to the
business. Requirements are viewed as an
enabler to delivering solutions that meet
business needs.
In a value‐add approach, resources in
requirements improvement are applied only
where it can be demonstrated that the
investment will lead to results that benefit the
organization.
Value‐Add: The Project Perspective
In a valid‐add environment, requirement
processes are reviewed and tailored on
enterprise‐critical projects to optimize the
likelihood of project success. Requirement
artifacts are customized and adjusted to add
maximum value to all requirement stakeholders.
This means moving from simple template
completion towards the production of artifacts
that not only wow the customer but build
confidence that their goals will be met.
Requirements become a difference maker not
an activity completion.
Value‐Add: The Non Project Perspective
The value‐add perspective treats requirements
effort in a non‐project environment as an equal
partner in an improvement program. Process is
differentiated between enhancements and
production support and evaluated carefully to
ensure that demonstrable value‐add is provided
to each requirement process step and artifact.
Value‐Add: The Tool Perspective
The introduction of new tools in the value‐add
approach demands evaluating each tool to
determine what capabilities it provides to an
organization and how those capabilities
harmonize with both the requirements process
and the organization context. Introducing for
example Telelogic Doors to enable traceability
adds little value if the defined SDLC does not
enforce traceability.
Value‐Add: The Training Perspective
The value‐add approach demands simply that
training be tailored to meet the specific needs of
an organization. Each technique introduced and
concept expounded has placement in the client
defined environment. A value‐add approach
demands review of the courseware before
delivery.
MRR Consulting, 2009 Page 3 of 4

4. RReeqquuiirreemmeennttss EExxcceelllleennccee ffoorr tthhee RRiigghhtt RReeaassoonnss
MRR Consulting, 2009 Page 4 of 4
Summary
To summarize, the value‐add approach means
not accepting requirement improvement as a
‘one size fits all’ equation. It means insisting
that each element is tailored to meet the long
term wear needs of the organization. It means
moving from ‘good to great’.
Take a look at your organization. Are
requirements a difference‐maker in the
solution delivery process or simply a set of
requirements to be marked with a check for
completed? If it is the latter, consider
evaluating the need for a requirements
improvement change using a value‐add
perspective. Do not accept vendor
propositions based on generic solutions but
instead insist on strong tailoring to ensure
your value‐add needs are met.