Software Requirements: How Much is Too Much?

by Paul Johnson

Every developer or project manager at some level has to deal with solving the requirements problem: how do we build software for a client that will be what the client envisions?  In many cases, a client may know some of the important pieces of the application that they need, but in most cases not all the intricate details will be known.

A huge amount of time can be dedicated to writing a document that encompasses everything that will be done in the development effort down to the minutest detail.  But is that really necessary?  Will that deliver the best product?  In the end, that is the standard for how a project is judged: the satisfaction of the client.  A tome of software requirements does not a happy client make.

In some cases, very detailed requirements are necessary.  One project I worked on was a CPAP machine that needed to be approved by the FDA.  It seemed like it took longer to update the requirements document than it did to make the code changes in many cases.  But it was important to have this level of detail; having it allowed us to prove that each requirement had been fully tested and prove that the device functioned as designed.

At the other extreme, some projects I have worked on have no documentation at all.   These are usually in house projects that don’t have the same intense external scheduling and cost pressures.  Often these require unnecessary time as well, because many iterations of the software need to be made before the client actually gets what they had envisioned.  Sometimes this is the best way to develop, because writing requirements down may be a waste of time.  Many times people don’t get that much out of them anyway because they have visual minds.  They need to see the actual product before they can decide whether or not it meets their needs.

Ideally requirements will be loose enough to allow for some freedom in design decisions so as not to inhibit the innate ability of the team to have the product organically grow out of development process but concise enough to not force extra iterations.  Having requirements also facilitates drawing up a schedule, which in many cases is just as important as completing the project itself.   Another key is client acceptance: if there are no requirements, how can you say you delivered what the client wanted?  My advice would be to break a project into digestible chunks, not bite size portions.  The bigger the document is the more that will need to be maintained.


Print This Post Print This Post

Explore posts in the same categories: Technology

Tags:

You can comment below, or link to this permanent URL from your own site.

Comment:

Security Code: