Once development requirements are defined, they need to be managed. A new crop of tools may be the answer.
When it comes to software development, requirements are one of the hardest components to nail down. Theoretically, they are the foundation of all activities--design, development, and testing--because they spell out what the software is supposed to do and how it is supposed to do it. Yet customers seldom have a clear understanding of what their expectations and needs are at a detailed enough level, making setting requirements ever illusive.
| Wrestling with requirements|
|Once development requirements are defined, they need to be managed. A new crop of tools may be the answer. |
|By Linda Hayes |
Software development requirements spell out the business functions, the design attributes, and the performance characteristics of an application. For example, the system may support the order-entry process. From a business perspective, it needs to accept new orders, provide item pricing, and so on. From a design point of view, it may be required to run on a Microsoft Corp. Windows 98 desktop with a SQL Server database on an NT server, while performance requirements demand that it support up to 25 concurrent users processing 10,000 orders per month.
|Requirements are the foundation of all application development activities--design, development, and testing. They spell out what the software is supposed to do and how it is supposed to do it. |
Despite their importance, defining requirements is the most likely activity to get short shrift. At the beginning of application development, few users have fully formed expectations that can be reduced to objective requirements statements. For instance, the simple requirement of accepting orders begs a thousand questions: If the customer is new, can you create a record here or must that be handled in a different application? Who is authorized to set credit limits? On and on it goes, each answer raising another question. This results in an organic development process; the project must respond to constraints and desires as they arise.
And even if you don't start out with all of your requirements neatly defined, it doesn't mean you shouldn't capture them as you go. At a minimum, the project should begin with a list of the top 10 or 20 business functions it absolutely must support, coupled with the design constraints and minimum performance parameters. These points can then be expanded into lower and lower levels of detail. Only the target users can identify these, although systems analysts can help to clarify and quantify them into objective requirements instead of subjective desires. Without this baseline set of expectations, applications can burgeon into a mass of features that fail to deliver key functionality.
The key to making requirements management work over the long term is not just the "requirements" part but also the "management" part. Capturing requirements is a highly effective wake-up call, but the real challenge is to keep them current. Removing obsolete requirements, adding new ones, and modifying others is as never-ending as software support and maintenance.
A development revolution
Although requirements should guide the entire development life cycle, the test group is most likely to tackle the problem of defining them if they do not already exist. Why? Because they have to figure out whether the software is ready, and to do that they have to know what it is expected to do.
In the past, this typically meant capturing requirements into spreadsheets where they could be tied to test cases. But this approach quickly becomes unwieldy for a project of any significant size.
|If software projects are really and truly defined and managed according to their requirements, it would cure a host of ills. |
Luckily, there's a bumper crop of new requirements management tools available that make implementing a test repository more manageable. Caliber-RM from Technology Builders Inc., in Atlanta; DOORS from Quality Systems & Software Inc., in Mount Arlington, N.J.; and Requisite Pro from Rational Software Corp., in Lexington, Mass., are all geared toward trying to wrestle requirements into submission. Most provide a tree structure that allows high-level requirements to be successively broken down into subcategories and instances, then tied to test cases for traceability. These techniques help organize requirements so they can be clarified, tracked, and measured to ensure that the application will meet customers' needs.
A company that develops peripherals and the supporting software bought Caliber-RM to guide it through a large-scale release of new software. The project was so important that the test team had the luxury of getting organized early in the life cycle. They began to capture their requirements during development--after the design phase, but before testing. The company amassed a staggering number of requirements with a minimum of effort.
When the test team presented their work-in-progress to the cross-functional project team, the marketing people gasped. "There is no way we can possibly meet all these requirements and still make our schedule!" they exclaimed. "We'll have to take some of these out." And the developers revolted. "We've already started coding those," they complained. "We can't pull them out now."
Requirements were quantified, and suddenly marketing wanted fewer requirements and developers wanted more. What is happening here?
Hopefully, nothing short of a revolution. If projects are really and truly defined and managed according to their requirements, it would cure a host of ills. Runaway projects, burnt-out developers, frustrated testers, dissatisfied customers--all of these stem from undefined requirements.
You can capture requirements into a spreadsheet, but it takes a powerful product to actually manage them. Will these products, or their competitors and successors make a difference? We can only hope. //
Linda Hayes is CEO of WorkSoft Inc. She was one of the founders of AutoTester. She can be reached at firstname.lastname@example.org.