Defining Requirements

Any discussion on the subject of managing software development will spend many words emphasizing the importance of defining the requirements for the software before the software is developed. All of them will say that requirement definitiion is the key to successfully managing the development of software projects.

They’re all right. It is the most important aspect of successful software development.

Probably the single most significant area in which custom software development differs from standard software development is in the definition of requirements.

With standard software development, requirements should be defined based on the advice of the marketing group. The marketers should talk to the customers or the potential customers and find out what they are looking for in some software. If the marketing people talk to ten customers and nine of them say that they are more likely to buy the software if it has a particular feature, then you add that feature. On the other hand, if none of the customer wants a feature you don’t add it. If some relatively small, but non-zero, percentage of customers claim that they are more likely to buy your software if it has a particular feature, you do an evaluation of the cost of adding that feature relative to the additional revenue likely to be realized by adding that feature.

This is an obvious process to use. It is amazing that it is not always used.

I worked for a few years for a company that basically allowed the programmers to decide the features to be included in their standard software. The company had a very week marketing department, so the programmers read the software literature and added the newest and greatest bells and whistles they found there, without really any regard as to whether or not any customers really wanted those features. Of course, some of the features they added were things that the customers actually wanted. But the customers had no particular desire for some of the other features that the programmers added. A lot of the cost of developing new features was invested in things that didn't add any sales revenue. Of course, as new features are added the software becomes more complex. The more complex it is, the harder it is to test. Very complex software sometimes requires test cases that are not actually used. The bottom line is that extra features may lower the reliability of the software. If those features do not result in increased revenue, then they should be avoided.

If you invest enough resources into the development, you will add a sufficient number of features to get some software sales. But if those features are not things that your customers are really looking for, then you are probably not going to make much of a profit while you are doing so.

This company sold hardware as well as software and the availability of the standard software improved hardware sales so the company remained profitable (mainly from the sales of their hardware). But they always missed their software profitability goals. This was particularly frustrating because the company’s competitors made more profit on their software than they did on their hardware.

It appears that their competitors actually talked to their customers before investing their resources into a new product.

As important as talking to the customer is when developing a standard software product, it is critical when defining requirements for a custom software solution. The reason that customers purchase a custom software solution is to efficiently and effectively solve a problem that they are experiencing. Therefore it is absolutely necessary for those who are developing that solution to understand the customer’s problem.

We will now discuss the specific steps that should be taken in order to effectively define the requirements of custom software projects.