Requirements based development

Many years ago the company I worked for delivered a bespoke
application to a customer and I was present at the first live
acceptance test. Part of the way through the test one of the user’s
employees asked how the system could perform some particular
function. “It can’t” was the response; “but
that’s absolutely fundamental to our business”; “but it
wasn’t in the specification”; “but we assumed you knew
that—everybody knows that”; “no, they
don’t” was the ensuing conversation.

I feel free to report this as I was neither the salesman
responsible for the initial sale nor was I responsible for the
specification—but it’s an old story: the specification didn’t
reflect the business requirements and the user and the developer
didn’t speak the same language, although they assumed that they
did. The key, clearly, is the initial statement of requirements: if
this can be made to accurately reflect business needs and it can be
expressed in language that is understandable by both the business
user and the developer then you have a good starting place for
development.

This is hardly new and it has been known for a long time, but
tools to support requirements management have historically focused
on supporting the traceability of functional requirements (that is,
how does this feature we are developing relate back to some
specific technical requirement?) and has tended to leave out
consideration of the business requirement that underpins that
functional need. This is now changing and in this I am going to
discuss one company that is actively taking the business user into
account in its requirements management software.

This company is Compuware and its product is Optimal Trace,
which is based on the company’s acquisition of SteelTrace. This
company focused, from the outset, on capturing requirements rather
than merely managing requirements. Note the importance of this
emphasis: traditional approaches have tended to assume that somehow
functional requirements materialise out of thin air, or that
someone can translate user requirements into a functional
specification in some mystical but explained manner. Optimal Trace,
on the other hand, works on the basis of starting from the business
goals that you wish to achieve and then capturing ‘the
story’ behind those goals, which are then evolved into
functional requirements through an iterative process supported by
the tool.

Of course, there are lots of other features within the product:
support for baselines, parallel development, test case generation,
document generation, the provision of standard templates (you can
also build your own), the ability to associate non-functional
requirements with scenarios or goals, a nice graphical interface
with a flow diagram that is bi-directionally synchronised with a
text-based exposition of what you are doing, and so on. The product
also integrates with a variety of third party tools as well as
Compuware’s own lifecycle tools.

However, the key point is that Optimal Trace is about
business-oriented requirements capture as well as conventional
requirements management and traceability; and while much of the
latter is “me too” stuff, the capture element is not
and provides a distinct differentiator for Compuware.