|
|
January 8, 2001 |
|
|
Get It Right The First Time
continued...page 2 of 2
By Tom Farre
![]() |
| More on project management: |
|
|
|
Send Us Your Feedback |
By storing requirements and related information in a multiuser database with powerful version controls, automated tools let project members improve the process of eliciting requirements, manage them throughout the development cycle, and communicate requirements changes and project status. They keep everyone pointed in the same direction, working from a common definition of what it is they've agreed to build. To varying degrees, the tools also allow linking requirements to other development tools and processes, creating, in effect, a kind of control panel for the entire project.
Which product features are most important? The answer depends on your company's processes, project size, and type of development projects. Everyone agrees, however, on certain features that would benefit most development teams.
The tools are useful in collaborating with customers and stakeholders to elicit requirements, either through the Web or a client-server interface, and then in providing a structured format for entering requirements into the software requirements specification.
"When I'm defining requirements, I have a template to work from that I know is at the right level of detail," says Cygent's Nakaishi, a RequisitePro user. She also appreciates being able to assign trackable attributes to each requirement, such as author, person responsible, rationale, release number, and, especially, cost and priority. After the marketing team adds its priorities and product development adds its costs, Nakaishi can quickly create reports with priorities and costs filtered to match release schedules and budgets. This helps her decide which requirements to add to the current version, which to defer to a future release, and which to drop altogether--nice insurance against project scope and budget creep.
Requirements attributes also can help track the status of the overall project--the percentage of high-priority requirements that are coded but not tested, for instance. When dealing with hundreds or thousands of requirements, such metrics are nearly impossible to generate from a paper document but easy using the tabular or database interface of requirements-management tools.
At Complete Business Solutions, the collaboration process begins with eliciting requirements from customers and continues during development when clarifications to the requirements are needed. "We need our customers to see the requirements developed, enhanced, and finalized all the way through," says Spiegel, a user of Caliber-RM. "They collaborate through the threaded discussion feature, logging on to see if a devel-oper may have posted questions." Customers can respond inside the tool, which gets percolated to developers writing the code for the first time. Such collaboration allows requirements to constantly change and evolve even after the requirements period is over--a key advantage in satisfying customer needs. Customers also can trace the implementation of their requirements through coding and testing, helping them gauge the software's progress.
This traceability between requirements and different artifacts in the development cycle is arguably the most valuable feature of requirements-management software. Traceability can show how a business requirement ties to the system's functional requirements, to the database structure that will support it, to the code that will support it, to the tests for the requirement, and to the documentation. When the requirements change, the software will trace the impact through every element of the system.
"Our method calls for 100% traceability of quality-control scripts all the way up through requirements, so having an automated test tool and an automated requirements tool allows us to see on any given day our coverage, or where we are," Spiegel says. "You can't do that unless you have a traceable linkage." Such linkage requires integration between the requirements-management tool and other tools. Most vendors promise this to varying degrees, either via a suite of their own development tools or integration with popular third-party tools.
A good example of the power of traceability comes from Landmark Graphics. Integration of its entire suite provides a competitive advantage, so the modules must be tightly coupled to each other. Using what Landmark calls an impact matrix, the traceability feature of Caliber-RM lets project leaders understand which modules would be affected by changing any one of the 250 features it might be evaluating for a future release. "Once you understand the impact on the modules, then you can begin to prioritize," Reed says. "On an individual product, it's easy to prioritize, but with a suite you've got to be sure all the affected products can implement the feature."
Reed touches on another key aspect of requirements management software: impact analysis on changing requirements. Related to traceability, impact analysis helps project leaders understand the impact of any change as they decide whether or not to make it--and with 10% of requirements in a typical project undergoing change at any given time, impact analysis is tough to do manually. Requirements-management tools may include a change-proposal system to help structure the process. Telelogic's Raymond says if you're part of a group working on a project with 5,000 requirements and someone proposes a change, a process is needed to manage that. "Our change-proposal system is a big differentiator," he says.
The user interfaces also vary somewhat. All requirements-management tools feature both a word-processorlike interface for writing requirements and creating the software requirements specification, and a database interface for managing requirements, synchronized with the software requirements specification. With an increasing number of nontechnical users involved in development projects, an easy-to-use interface is key. Rational, for instance, promotes its tight integration with Word as easier to use. Doors/ERS, on the other hand, uses a database approach that presents requirements in a proprietary Wordlike environment, which Telelogic says is more robust. In general, feedback has been good concerning the user interfaces, but it's advisable to have users test the word processing and database interfaces of any product they're considering.
Scalability also is a concern. Requirements management generates surprisingly large amounts of data. so testing under realistic user and data loads is needed to see whether the performance and ease of data manipulation scales as the workload increases.
To get the most out of requirements-management software, experts advise focusing on writing good requirements first. "The processes and tools are connected, of course, but your processes for developing good requirements need to come first," says Process Impact's Wiegers. For instance, most requirements will be expressed in natural language, but they could be vague or contradictory, and no snappy management tool can turn bad requirements into good.
Several factors key to getting requirements right include clearly identifying business objectives from the start: If the objectives are unclear, it's impossible to decide what to build to meet them. Good requirements begin with a sound understanding of all user classes, including occasional users. It's also vital to recognize the characteristics of a good requirement: Is it ambiguous? Is it complete? Another key is creating use cases early on, to help developers understand what the users really need the software to do. Wiegers also advises delving into the quality characteristics of the software--understanding not just what the product needs to do, but how it will do it. "Don't get in a situation where the software meets its functional requirements but is too slow or crashes a lot," he says. "You can still take good requirements and build a bad piece of software."
return to page 1
Back to This Week's Issue
Send Us Your Feedback
Top of the Page