| home | about us | services | products | clients | news | careers | contact us |
|
"Why you should be writing your software requirements down" Program requirements are the raw materials with which you design and build your software. The quality of any given product depends on the quality of its raw material. Without a written specification to work from, the program can take on a life of its own as new features creep in, code balloons and designs become out of date. From the business side, without a clearly defined end point, how can you tell when you've finished? Or will you just spend another few days finishing off the customers' request for a whole new feature free of charge? By writing your software requirements down into a document you provide not only a base from which to work but also the ability to manipulate and group items together. Suddenly what seemed to be a mixture of customers' requests and comments becomes an ordered and coherent direction for the software. Perhaps you've found that two requirements are mutually exclusive or that there isn't enough detail on another. You can review a written document with the customer, clarify missed points and obtain a sign off. It's rather hard to do this when it's all in your head. If you don't like lists and documents because you prefer a more visual approach, try using mind maps (http://www.mindjet.com, Mind Maps - Tony Buzan) or other similar visual tools. The important thing about formally writing requirements down is that re-using the information gives your brain another opportunity to review and reorder the information. This process often produces the beginnings of a design as well as further questions to ask the customer. By the way, written requirements provide something to test the product against! Now that you've written them down, how good are they? Did you know that you could have the biggest single impact on your software quality by starting with high quality requirements? See next month's article for hints and tips on improving
the requirement statements in your Software Requirements Specification
(SRS). Peter Brown | ||