In-Depth

Q&A: How to manage requirements

• By Dan Romanchik
• September 29, 2003

In the world of modeling, design and development, it is important to define the requirements of an application before you begin. But requirements change. So it is just as important to manage how the requirements change as it is to define them in the first place. Dan Romanchik asked Paul Raymond (above), VP in charge of requirements management products at Telelogic, to share his views on this topic.

Q: What mistakes do app development teams most commonly make when developing software requirements documents?

A: The first mistake 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 they know what is needed better than the end user.

Q: Application development is so complex today that it is almost impossible to get the requirements right the first time. The problem, then, is one of managing changes. What are some of the mistakes companies make in managing changing requirements?

A: It’s important to understand what the end user wants to accomplish. Don’t accept design changes at face value. Ask what the change is intended to achieve and then investigate the best way to get that result.

Another mistake would be to wait until the end of the development process to look for feedback. Teams should ask how everything is working early and often. It’s much less expensive to make changes during the initial stages of development than in the later stages.

Changes also affect the way a system works -- they have an impact on design, documentation and testing procedures. It’s critical that change be managed from a total system perspective.

Q: What features should firms look for when purchasing requirements management tools? Why are these features important?

A: There are a number of features that companies should look for, including:

* Systems that support flexible processes as opposed to a rigid approach that forces conformity to a singular way of doing things;

* Tools that work the way you already work. If your company works with documents rather than databases, then your RM tools should work this way as well;

* Vendor process support that is requirements-driven rather than development-driven;

* The ability to look beyond standard evaluation to project how the system will perform when it has to manage large amounts of data;

* A user interface can display a lot of data, not just store it in a database;

* Ease of use that allows all the information to be displayed in one window, rather than having the user flip from window to window to get the information they need; and

* Traceability that supports today’s complex, iterative development and that recognizes that requirements change from one phase to another.

Q: What can application development teams do to improve the way they define and manage requirements?

A: I’ve mentioned several of these already, but to summarize:

* Listen to end users. Don’t assume that you know what’s needed.

* Ask for confirmation when you’re doing interviews. Make sure you understand what’s been said and record it accurately.

* Involve everyone in the process, not just test engineers. You’ll have a much better chance of getting things right the first time.

* Question every task that’s been assigned and ask “Why are we doing that?” and “Is there a requirement for it?”

* Realize that it is no longer possible to gather a complete set of requirements specifications up front and set them in stone for the duration of the project. The development process must allow requirements specifications to evolve as a project progresses.

Want to read more about defining software requirements? Check out Dan Romanchik’s review of “Managing Software Requirements, 2nd Edition: A Use Case Approach” by Dean Leffingwell and Don Widrig from the September issue of ADT.

Please see the following related story: “Is UML heading for fragmentation?” by Richard Adhikari, or click here to go to Web-only material on UML.