Full steam but going nowhere?

Jim Heumann

HAVE you ever heard someone say: ''We don't have time to gather requirements. If we don't start coding right now, we'll never meet our deadline.''

Such statements - not uncommon - represent important clues about the culture and maturity of an individual or a team. When someone says the above, what does that really mean, and what are the implications?

''Requirement'' has many definitions; each method, process, methodologist, and pundit seems to have a unique twist on it. All would probably agree, however, that requirements should clearly state what a given software project is to build and deliver. In other words, the above statement can be read as: ''We don't have time to figure out what we need to build and deliver. If we don't start coding now...''

Unlikely that someone would make that statement out loud, isn't it? What is really going on when people say they don't have time to do requirements? What it means is one of these:

''I already know the requirements - or I can figure them out on the fly.''

''The requirement specifications I've worked with in the past have been so bad - I'm better off without them.''

''I don't care what we build, as long as we get it done on time (and collect our money).''

''This application idea is so new (or so unique) that we just can't pin down requirements in advance.''

"I already know"

This is the ''kindest'' interpretation. But, what it really means is, ''My developers know the requirements or can figure them out.'' If the specifications about what to build are not written down and agreed upon, then it is developers who will make the call on what gets implemented.

What's wrong with that? One reason why it is no longer acceptable to do things in this so-called ''old-fashioned way'' is that projects today are more complex than they used to be. And they are more complex in two domains: the problem domain and the implementation domain.

We have software for managing bull breeding, navigating automobiles, detecting fraud in cellular phone use, and for other specialised purposes; most developers cannot possibly know or understand the problems to be solved in these particular areas. And as application areas have grown more complex, so has programming. Distribution, concurrency, real-time, interrelated components, new languages, and other issues that developers must consider in order to create a robust system, all place pressure on them to become more and more expert at writing code. Also, these new demands mean that developers have even less time and capacity for figuring out the problem the system needs to solve. Another reason not to rely on developers to figure it out is that they have a conflict of interest. They have deadlines, sometimes based on their own estimates, sometimes on others'. If you give them a very vague statement of what to do, they will have many choices about how to implement the functionality. It would be natural for them to choose the one that most closely matches their main goal - which is usually meeting the deadline.

Past experiences with bad requirements

Bad requirements come in many forms, but the bottomline is that they either don't provide enough information to really build anything or they provide information that is misleading or contradictory. But remember: Just because you had to work with bad requirements in the past doesn't mean it always has to be that way. Helpful guidelines, techniques, and tools are available for useful requirements.

Good and bad requirements

According to the IEEE 830 Documentation Standard for a Software Requirements Specification, the criteria for a high-quality requirements set are as follows:

Unambiguous - Every statement has one interpretation. Terms are clear and well-defined.

Complete - All significant requirements are included. No items have been left for future definition.

Verifiable - All features specified as part of the project have a corresponding test to determine whether they have been successfully delivered.

Consistent - Conflicting terminology, contradictory required actions, and impossible combinations are notably absent.

Modifiable - Redundancy is absent; index and contents are correct.

Traceable - Each referenced requirement is uniquely identified.

Correct - Every stated requirement represents something required of the system to be built. This may sound obvious, but it is surprisingly easy to include extraneous requirements, or requirements that really pertain to a separate system entirely.

How do you recognise bad requirements? Compare them against the criteria above; if they don't match, then beware.

I recently came across the following requirement in an actual project requirements document I was reviewing: ''The application must be extremely fast and powerful.'' This is a poor requirement because ''fast'' and ''powerful'' are highly subjective terms.

Organisation and tools can help

In some instances, requirements are not intrinsically bad, but they are unusable because there are so many of them - and they may be poorly organised. Traditional software requirements specifications often contain thousands of declarative statements that ''The system shall'' do something. It is very hard for anybody to understand several thousand things at once. Classifying and organising the requirements can help. Splitting up the big list into smaller lists in a hierarchy that identifies explicit relationships represents a big step forward in understandability and usability. Writing the functional requirements as a user-oriented ''story'' can also help. Cases provide a mechanism to highlight how a given ''actor'' uses the system and what the system does in response. This goal-oriented approach puts the requirements in context and helps to make them easier to understand.

Having the requirements in a specialised requirements database rather than in a collection of unrelated documents makes them much easier to organise, search, and sort. People filling different roles in a software development team can ''slice and dice'' them any way they choose. A project manager can use the requirements to help keep the project on track, using the tool to find information about how many requirements have been implemented, how many new ones added, and how many have changed during the last week. Tools won't help you write good requirements, but they can help you organise them and find the information you need.

To be continued

(The author is Requirements Management Evangelist, Rational Software.)

Please e-mail us at eworld@thehindu.co.in if you have queries on computer usage or if you find an interesting way of using the computer.