 |
||
 |
||
|
|
||
Internet Business
|
|
Programming SpecificationsKnowing how to create a complete specification for your software or web programming project Businesses often, at some point during operation, realize that getting a customized piece of software or that web based application developed, will greatly enhance their productivity. But more often than not, things go pear-shaped when the client feels he isn't getting what he requires from his developer, and no matter how hard he tries to express his needs, the developer keeps getting it wrong. A horrible statistic says that about two-thirds of all software projects (including web applications), are completed not to specification, but the client just takes what he gets because it will cost too much to continue development. Approximately 80% of all development projects either go over budget or behind schedule. Scary as it stands, but the root cause of almost all these problems can be traced back to an incomplete requirements analysis phase of development. This article is meant to give clients some insight into what they can do to ensure that their developer knows exactly what they want. Requirements elicitation is the process of expressing your requirements in a way that leaves nothing to the imagination. If anything is left ambiguous, it will almost certainly be misinterpreted. An example of an ambiguous requirement that I recently received from a client was "The user must able to record the information of a shopper on that page." My first reaction was a series of questions; What user? What information? What method of capture and in what format? A more defined method would have been: "The administrative user must be able to enter the details of the shopper (as submitted in the email application) into a form with fields for all information in the email, and be captured into the SQL database, as per document xxx". Something similar was eventually put together by consultation, but it took an extra three days, as that wasn't the only ambiguous statement. Expressing a requirement itself is unfortunately not enough. The format in which it is done is also important. Now, obviously, the majority of people interested in having software developed aren't software programmers, so no developer can realistically expect you to speak the lingo. But what you can do is divide the project into separate chunks, functionally speaking. If you want a web store developed, the chunks could be product catalogue, shopping basket, customer data capture and payment and checkout. Then you can break it down further. For example, with the product catalogue, you will probably need sub sections such as adding products, adding stock, removing products, editing product details, etc. It is once you get down to the fundamental need, that it needs to be expressed clearly. You do not need to use geek-speak, simply describe as accurately as possible what it is you would envision doing physically at that point in the program. Each division you make is essentially a new section or sub section in your requirements document. So Section 1 will be Product Catalogue, Section 1.1 will be Adding New Product, Section 1.2 will be Deleting Product, Section 2. will be Shopping basket, etc. While it might seem doing this is making the developers job easy ... it is. The easier you make it for the developer to understand what you want, the greater the chances you will actually get what you want. Any good developer will consult constantly with you about your requirements, but some don't. Gareth McCumskey is the Managing Director of Nexus Interactive, an IT Solutions company designed to provide all IT products and services a company will need, integrating IT needs with one provider.
|
|
