The journey's not the destination

Does your software do what it's supposed to do?

(The first part of this article, titled ``Full steam but going nowhere?'' appeared in eWorld dated December 19.)

Jim Heumann

SOME people ``don't have time'' for requirements because they don't really care if they build the right thing.

Perhaps they are working on a project that they feel is doomed due to political or organisational problems, so they think that doing good requirements won't help anyway.

Or perhaps they have chosen to work on a given project for personal reasons, maybe to get experience in a new technology or technique. Whatever the reason, if people don't care, then you have a problem that organisation and tools can't solve.

New and cool

Software projects aren't always trying to solve well-defined problems with known solutions. Many seek to expand the boundaries of what is possible for computers. And if there is no precedent for your system, it is very hard to get potential users to tell you how they want it to work.

In 1978, Dan Bricklin developed VisiCalc, the first electronic spreadsheet, on an Apple while attending Harvard Business School. There was nothing like it at the time; it is unlikely that he could have gotten requirements from ``users,'' simply because there weren't any. Similarly, consider Napster.

It is also unlikely that Shawn Fanning, the 18- year-old Northwestern University dropout who developed Napster in 1999, did extensive requirements gathering before working 18 hours a day for three months to write the original source code and deploy the site -- yet it was a huge success.

It is sometimes said that such systems are ``exploratory software engineering.'' For their first release, extensive requirements gathering is unlikely to add much value. Subsequent releases, however, are a different story.

Once users catch on, they develop certain wants and expectations; developing new features that you think are ``cool'' may not meet those expectations. Asking users what they need, expressing it clearly, writing it down, organising it, and using it to design and implement new functionality can help ensure that a good idea grows instead of fizzles.

Think lifecycle

When people say they don't have time to do requirements, they are usually thinking only about the first release deadline and not about the implications that omission may have for other concerns throughout the project lifecycle, including schedule, architecture and design, test and performance, and usability issues.

Beware `feature creep'

If you don't know what you are supposed to do, how do you know when you are done? A prevalent problem for many software projects is late delivery, often caused by ``feature creep.''

Not having control of what is supposed to go into a given release opens the floodgates to ad hoc requests for more features to develop and implement. Having no means to understand the relative value of each request and make informed decisions can easily lead to ``biting off more than you can chew'' and missing deadlines. With well-defined requirements, you can easily turn down requests for features that do not further your goals and maintain tighter control of project scope.

Give yourself room to grow

Without a high-level understanding of the range of functionality that must go into a system, it is easy to create a design that is not adaptable or scalable. An architecture that meets existing requirements but does not take future changes into account may end up being hard to modify or extend. Well-defined requirements anticipate modifications and changes, providing a framework for a flexible architecture and overall design.

Towards better testing

If you test software without requirements, then you are merely ``making sure the application does what it does'' without crashing. Testers can look for GUI elements that don't work, system crashes, and more obvious problems, but in the end they have no means to verify that the program really meets the user's objectives. One simple definition of quality software is that ``it does what it is supposed to do.''

Requirements specify what a system is supposed to do, so from very early on in the development lifecycle, you can begin testing to ensure that you are actually creating the workable system your user needs.

Spell out priorities

Even if you have functional requirements to design and test against, failures can still occur. If the team doesn't know, for example, how simple the user interface and how fast transaction times must be, how many users the system must support, and who has to maintain the system, then you can easily wind up with an application that provides all of the requested functions but does not solve the problem.

By providing information about non-functional requirements, you can ensure that your system designers and developers won't spend all of their time implementing the functionality without considering other factors that are vital to the system's success.

So now, if you hear people in your organisation saying, ``We don't have time for requirements,'' then consider the implications. If your team is inventing something brand new, then you might be able to get away without gathering requirements. But if, like the majority of organisations, you are working in domains for which models and precedents are plentiful, then it may be worth your while to dig a little deeper and find out what those people really mean. Do they intend to let developers make important decisions outside their respective areas of expertise? Do they understand the difference between a good requirement and a bad one? Do they simply not care what system you develop? Do they understand the potential impact on other areas of the project lifecycle if they don't specify requirements? If you understand what is really going on below the surface, you can respond to such statements in a way that can help make your project rather than break it.

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