Life Begins at Requirements
Few people have the same notion of what requirements are and where they fit into the big picture.
by Richard M. Marshall
Posted October 15, 2003
Most people agree that an application's life begins with its requirements. Requirements tell the developer what the end user wants the app to do.
But that's about all folks will agree on. Beyond the high-level objective of defining an application's purpose, few people have the same notion of what requirements are and where they fit into the big picture. You can achieve real gains in this area because it's the highest leverage point in the whole development cycle. Get it right here, and the rest of the job is easy. Get it wrong, and you'll be taking change requests for months.
Finding the "Right" Requirements
There is an amazing diversity of ideas about what constitutes a set of requirements, let alone what makes good requirements. Everything from a few words scribbled on a Starbucks napkin to full-scale UML models are candidates. As with many things in IT, and despite what some gurus might say, there is no "right" form of requirements. The correct form for requirements will vary from project to project. You can use two simple criteria, however, that will tell you if a set of requirements is right for a given project.
Given that the key function of requirements is to communicate between end users and developers, the first key to determining if requirements are right is simple: Do both the end users and the developers understand them? I'd contend that few end users will really understand a UML model, and that it is inappropriate to make them learn. Equally, scribbles on a napkin might have captured the idea at the moment of conception, but you can be sure that the developer will have forgotten what they mean by the time it comes to cutting code. You must find a method in between; you can choose from many commercial requirements tools that might suit your needs (see Resources).
The great advantage of ensuring that both the developers and the users can understand the requirements is that you can arrive at the acceptable compromise between what is desired and what is possible (see Figure 1). If the requirements are too technical, the users can't argue their case, but if they are not grounded in reality, implementing them will be impossible.
The second criterion that will tell you if your requirements are right: Is the content any good? One easy way to determine this is to go through the requirements one by one, checking whether they can be verified. This will ensure that most fuzzy, ambiguous, or pointless requirements are shaken out early in the process. The classic example is a requirement that a system be "user-friendly." That can't be verified because each person has his or her own concept of what "user-friendly" is. And remember that some people think DOS is user-friendly. That requirement would be better stated as, "Novice users must be able to use the app efficiently for their jobs without the need for training."
You have to be relentless when looking at requirements, and you should avoid trying to figure out what the original author meant. You'll get it wrong, and that's how projects start to diverge from the original specification. Using a requirements tool, you can tag each requirement with a validation method. Using DOORS, for example, you can add a "Validation" attribute for each requirement and record a test method immediately. A requirement for data validation on a data entry field could then be tagged with examples of valid and invalid data. Testers and test planners can incorporate this directly into their work. Any requirements that can't be verified will create problems.
Back to top