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.

Requirements vs. Needs
So what comes first: the requirements, or a notion of an implemented system? Neither, actually. A business need comes first—a source of irritation, an opportunity, a way to do things more efficiently. Doesn't really matter, but it is important to realize that any app worth building must meet a need.

So you're probably asking, what's the difference between a need and a requirement? To a certain extent it is word play, but word play with a purpose. That purpose is to focus your thoughts on the bigger picture of how the system will be used before writing the requirements. This informal step before committing to a set of requirements is called needs analysis.

Needs analysis starts with the realization that something could be done differently—for example, a productivity enhancement to increase the call rate in a call center. From that initial mission statement, you can rapidly identify the areas that need further development. This exploratory phase is also characterized by asking probing questions: Who will use the application? What level of skill will it require? Who is responsible for its development? Who will sponsor the project? What is the business case for the investment, and how will it integrate with the existing infrastructure?

Once these questions have been answered the same way twice in a row, it is probably time to move to a more formal requirements process. However, it is the informal needs analysis that gets you to that point. If you want to look at this using a house-building metaphor, requirements form the foundation for a solid project, whereas needs analysis corresponds to preparation of the building site.

Plan for the Macro Lifecycle
Needs and requirements form the start of the application development lifecycle, but there is a higher-level lifecycle, too. This macro level exists at the corporate level and uses applications and infrastructure as the building blocks. While many companies consider their infrastructure and legacy systems to be core business assets, few of them actively plan how new systems will join that select band.

Some applications start life as a quick hack in Excel VBA, only to become business-critical. Often departments hack together their own VBA solutions because they can't get the resources they need from the harried central IT service. Alternatively, they do it deliberately to stay under the radar of the IT folks, who would probably have a fit because there are no backups, no integration, no security, or any of the other concerns of enterprise developers.

At the other end of the scale, projects that start as massive, high-investment megaprojects fade into obscurity as the business moves in a different direction. This is clearly a huge drain on corporate resources and can be avoided by better integration between business and IT planning.

Let us call this macro-level lifecycle the application roadmap. Such a business-driven plan provides a much better perspective of what a company is most likely to need. The idea is to manage systems before they become critical legacy problems and to avoid installing white elephants. This kind of course-grain planning has a scale of years and does not address how systems are built. It looks at how corporate systems need to evolve in line with management expectations. It needs to track what vendors are likely to do in the future, predict market trends, and even track the competition.

An example might show migration of systems off an old mainframe onto newer platform, at the same time as planning for retiring NT 4.0 machines in favor of Windows Server 2003. At an infrastructure level, the roadmap might show a move to Web services over the next five years.

Many managers are uncomfortable with this kind of planning because it is largely speculative and definitely will change. Developing this kind of roadmap is quite different from planning the conventional lifecycle and is beyond the scope of this article. It is, however, important from the prospect of putting the development lifecycle in a business context.

About the Author
Richard has been steadily moving away from code into the heads of business people. He is now CEO of Prosumer Solutions, which is changing the economics of Web app development through Business RAD. He holds a Ph.D. in computer science from the University of Edinburgh. You can contact him at richard.marshall@prosumersolutions.com.