News

Q&A: How to manage requirements

• By Dan Romanchik
• August 18, 2003

It's certainly important to define the requirements of an application before a development project begins but, as we all know, requirements change. It is, therefore, just as important to manage how the requirements change as it is to define them in the first place. I asked Paul Raymond, vice president in charge of requirements management products at Telelogic (with offices in Malmo, Sweden and Irvine, Calif.) to share his views on this topic.

Q. What mistakes do application 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. Applications development is so complex today that it's 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 inevitably 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 companies 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 of the information to be displayed in one window, rather than having the user flip from window to window to window to get the necessary information;

* 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 already know what's needed.

* Ask for confirmation when you're doing interviews. Make sure you understand what's been said and have recorded 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.

For other Programmers Report articles, please go to www.adtmag.com/article.asp?id=6265