In-Depth

Requirements required

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

Most   Popular