In-Depth
Requirements required
- By Rich Seeley
- December 1, 2003
Does your organization need requirements management? While it is a part of
most notions of best practices, it is still sometimes derided as unnecessary
baggage. Requirements champions can point to millions of dollars that are written
off each year in failed software projects; as often as not, they contend, sloppy
initial requirements were at the root of the problem.
Requirements tools vendors include IBM Rational and the RequisitePro product,
Telelogic and its Doors/Enterprise Requirements Suite (ERS), Borland Software
Corp. with StarTeam and CaliberRM (via its purchase of StarBase), Computer Associates
(CA) International Inc. (through a partnership with Integrated Chipware Inc.
and its RTM Workshop product), and others.
Perhaps the biggest trend at play in requirements is due to the rise in incremental
development. Vendors and users have both seen the massive projects that once
called for requirements management give way to smaller efforts that might eventually
add up to a "large project."
"There used to be a big-bang approach to development where you gathered
all requirements up front and had adequate resources," noted Paul Raymond,
vice president, requirements management tools at Telelogic, Irvine, Calif. "Now,
with aggressive development schedules and constantly changing requirements,
customers have moved to incremental or iterative approaches." That means
smaller chunks of functionality are handled at any given time. Telelogic has
moved to address this issue with the latest release of its Doors requirements
toolset, Raymond said.
Telelogic is among the list of requirements management vendors with a strong
lineage in mission-critical embedded development. Some viewers still see this
as the best bet for requirements.
But whether projects are big or small, effective communication is the key to
requirements management, Raymond and others agree. But it can also be a stumbling
block.
"The next company I talk to that has a complete set of up-to-date requirements
will be the first one," said Linda Hayes, CTO and vice president of engineering
at Worksoft Inc., a Dallas-based software quality testing tools vendor. "I've
never ever seen those. The only exception is in the bet-your-life, bet-your-planet,"
she said referring to the medical and defense industries. "But both of
those are regulated so they have no choice. I think that's the only reason you
see it there."
Representatives of vendors for requirements management tools who were interviewed
for this article did not refute Hayes' take on the state of the art, although
some were optimistic about the future of adoption in requirements management.
They generally agreed with her when she said, "The irony of it is that
everybody knows you need them. Everybody knows they're important. So the question
is why don't people have them?"
Her view is that the problem is not so much a lack of tools and technology,
as a lack of understanding of what requirements are and how to go about developing
them.
If you drew a technology adoption curve, you would not find requirements management
tools at the peak, admitted Dave Locke, program director for IBM's recently
acquired Rational tools. Yet he and others working in this area see potential
gains. Good requirements are fundamental to success, they agree.
"I've been working in requirements management for a long time now,"
Locke said. "This is a fundamental problem with software engineering. There
are many aspects that could make your application better. But if you don't know
what you're going to build and you don't manage what that is, how can you build
the right thing, ever?"
Sticky notes as art
Jeff Evans, program manager for software configuration management (SCM) at Merant
Inc., a Hillsboro, Ore.-based change management tool vendor, sees a requirements
management evolution on the horizon. He compared the current status of the technology
with where help desk applications were when writing problems on sticky notes
was considered state-of-the-art.
"Help desks have been around for a long time, so they're very much evolved,"
he said. "Most companies have a help desk. In fact, most of them don't
use Post-It notes anymore; they have a real help desk. Requirements management
is at the other end of that scale. It's still very new. People are still learning.
What is the best way to do it? Even among those writing the requirements, a
lot of them don't know how to write a good requirement yet. Companies are using
off-the-shelf common tools like Microsoft Word and Excel."
IBM Rational's Locke does not deny that there is a shelfware problem with requirements
management tools, but he believes it is solvable. "Fundamentally, the reason
it becomes shelfware is that people don't see the value," he said. "We
provide a lot of pieces that help people to adopt, embrace and move forward
not only on the automation front, because we're selling development tools, but
also on the software engineering front."
Besides its tools, IBM Rational has developed engineering best practices that
Locke said can be used with or without his company's tools. The best practices
specifically for requirements management provide answers to the questions development
teams have when they begin the process for the first time, he explained. This
helps to fill the education gap that everyone agrees is a major problem.
"I'm supposed to go build a requirements specification," Locke said.
"What does that mean? What should I be thinking about? What should be the
format? Who do I give it to after I'm done? How do I get it approved?"
Building accountability into the tools is another way to overcome the shelfware
problem and
ensure requirements management-related tasks get done, said Merant's Evans.
He advocates setting up a process and workflow that makes it virtually impossible
for members of the development team to ignore requirements tasks.
"The way to do it is relatively simple from our perspective," he
said. "Having built-in process and workflow means that when something is
submitted, it actually gets assigned to a person -- it shows up in their queue.
When they see their work to be done that day, they actually [can] see [that]
'Oh, it looks like I'm supposed to be working on this.' By default, that literally
walks them down the path of what they need to do at any given point in time."
Evans sees a lack of process and workflow as the problem with using just a
word processor or spreadsheet. "A tool that's so open-ended that it doesn't
have process and workflow built into it -- there are no requirements built into
it, and you can kind of use it any way -- is problematic from the standpoint
of repeatability and quality," he noted.
He argues that tools with process and workflow built-in help to solve two common
problems with requirements management: a lack of understanding of what needs
to be done, and a failure to make use of the tools.
"You actually do need a tool that walks you through to some degree so
that you know what the next step is and when it gets completed," Evans
said. Workflow keeps the job moving from person to person, he explained, so
that a QA person, for example, does not have to go back to a programmer to ask
that a bug be fixed.
"Upon them changing the status, it actually notifies the next person in
line," he said. "There are different ways to police it, but the real
way to make sure you're policing it is to make sure you're dealing with process
and workflow."
However, Worksoft's Hayes said unrealistic expectations and the pressures under
which most projects begin, tend to torpedo requirements management processes
before the tools ever get installed.
"The phenomenon is this," she said. "The schedule for the project
is never based on the amount of work to be done. In my experience, it's based
on some kind of external factor. We have a competitive need. We have a customer
need. We have a corporate announcement. We're going public. There's some sort
of market-driven need for whatever this solution is. So, typically, that's what's
driving the schedule."
And this is where the perceived need for speed kills the requirements management
process.
Too much of a good thing
IBM Rational's Locke agrees that requirements documents can get out of hand.
"People tend to overload documents," he said. "We recommend keeping
the documents much shorter. Continue to use documents because it is a good communications
vehicle. We [also] recommend adding screen shots and some workflow diagrams,
if appropriate, to help communicate with the user."
In Locke's view, the end user should be the focus of the requirements document.
"Fundamentally, one of the approaches that we think is important is a technique
called use cases. Basically, that's a fancy word for telling the story of how
the user is going to interact with the application. And we keep them short and
simple."
He recommends writing a brief description in Microsoft Word of how the user
will use the new application and then extracting the requirements into the management
tool.
Another technique that both Locke and Worksoft's Hayes recommend is holding
moderated elicitation meetings to discuss the application. This brings together
the development team and the business users to determine a reasonable list of
requirements.
This helps to solve what Hayes sees as a fundamental problem on the business
side. "You go to a business person and ask about requirements and you get
an instant 'deer in the headlights,'" she said. "Requirements is a
term of art. They say, 'What do you mean?'"
Poor communications is a fundamental flaw in the early stage of developing
requirements, which can plague the entire development process in the view of
Hamilton Hayes, product manager for modeling tools at Computer Associates, Islandia,
N.Y.
He lists common mistakes developers make, including incomplete definition and
documentation, inconsistent and incomplete review, poor or missing impact analysis,
poor cross-team coordination and control, and inadequate management visibility.
Hayes said the first mistake is that "somebody didn't define what it is
that the system is supposed to do or how it was supposed to do it. This leads
to incompleteness in the requirements and, in many cases, incompleteness in
the documentation."
Another common error, he noted, is inconsistent and incomplete review. "It's
relatively widespread. Somebody went to the effort of writing requirements down
and it didn't get an adequate review in terms of peers working on other modules
that are related or a review from the people responsible for defining requirements
from a regulatory point of view," he explained.
IBM Rational's Locke sees the need for speed as another culprit in poor communications.
"In a typical project environment -- very fast-paced, keep things going,
get it out, get it right -- they write the documents with everything but the
kitchen sink in there. They hand it over to engineering and [engineers] can't
really see what the most important things are because they probably can't do
it all," he said. "[Also,] they can't communicate effectively with
the end user and other stakeholders because they've thrown everything into one
or two documents. We believe you should break it down into user-oriented areas
-- What is it that the user is trying to accomplish? -- and from there you'll
capture a smaller portion in that given document of an area and write the story
from the user perspective of what's going to happen. From there, you'll actually
capture the requirements in the context of that story."
To deal with the complexity, CA's Hayes recommends working in an iterative
process. "The realization that this is an iterative process is key,"
he said. "There are two things that come out of that. One is that you need
to have a methodology in terms of your overall life-cycle management that allows
you to do iterative [development]. Whether it's traditional systems broken down
into chunks, or rapid application development or extreme programming, you have
to pick the right method for the application.
"If you're an organization doing complex development, it's important to
understand what methodologies work for what project and what phases," he
continued. "To do that, I need good documentation I can manage change in
easily, and traceability between my requirements and the design."
But at the end of the day, it is also important that developers enhance what
IBM Rational's Locke calls "soft skills."
"The soft skills of requirements management are just as important or maybe
more important than the hard skills," he said. "How do I run a requirements
management workshop? How do I get stakeholder buy-in? How do I know who the
right stakeholders are? How do I push management back when they want more? A
lot of those soft skills are important. In fact, one of the required readings
for one of our courses is "How to Negotiate" because a lot of requirements
management is negotiation, how to interface with people to make it happen. That
is a fundamental key to making requirements more successful."
The first mistake requirements gatherers tend to make, said Telelogic's Raymond,
"is to not consider every type of end user. A requirements management document
must take into account all users within the system -- from support to maintenance
-- to be effective."
The second common mistake is to not listen properly. "Development teams
often assume that they know what is needed better than the end user," said
Raymond.
Merant's Evans sees the eventual acceptance of requirements management tools
and best practices coming when their value in increased productivity and efficiency
are realized.
"People are beginning to, or will soon begin to, look at the gains that
can be made in this area," he concluded. "They've already cleaned
up a lot of other parts of the company. I believe this is one of the next ones."
Requirements are crucial
"Requirements are crucial to any successful project," said Chad Mason,
manager of QA at Choice Hotels International, Silver Springs, Md., which employs
a variety of IBM Rational software development tools in its various processes.
"You need to have the right people in place and you also need to have the
right tools in place," he added.
Choice Hotels used to have more manual testers, said Mason, but testing is
much more automated. "We have very skilled test developers, each with more
apps to test," he said. He is not familiar with people who are down on
the idea of requirements, but he is familiar with people who have "had
to deal with that."
"Here, everybody appreciates doing things right," he noted.
In the Rational world, UML use cases are often intrinsic to the software process.
The skills involved in creating such use cases are similar in some respects
to the skills required of good requirements writers. Does Mason feel these use
cases help his group to create test requirements?
"With some apps we support, all documentation is in use case [format].
That's the way the development team creates their app. We've found they are
excellent to develop test cases from," he said.
Yet Mason's message is more complex, and echoes others' views on the requirements
process and use cases.
"They are excellent to develop test cases from as long as the use case
is written well," said Mason, adding that this is true of any type of requirements.
Also see:
Interview with Linda Hayes