February 28, 2021
Hot Topics:

Wrestling with requirements

  • By Linda G. Hayes
  • Send Email »
  • More Articles »

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

October 1999

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.

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.

Page 1 of 2

This article was originally published on October 1, 1999

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date