There are three widespread problems with software requirements that need better solutions than are presently customary for software projects:
- Many requirements are dangerous or toxic and should be eliminated.
- Some clients insist on stuffing extra, superfluous features into software.
- Requirements are never complete and grow at rates greater than 1% per calendar month.
Software engineers have an ethical and professional obligation to caution clients about these problems and to assist clients in solving them, if possible. In other words, software engineers need to play a role similar to that of physicians. We have a responsibility to our clients to diagnose known requirements problems and to prescribe effective therapies.
Once user requirements have been collected and analyzed, then conformance to them should occur, of course. However, before conformance can be safe and effective, dangerous or toxic requirements have to be weeded out, excess and superfluous requirements should be pointed out to the users, and potential gaps that will cause requirement creep should be identified and also quantified. The users themselves will need professional assistance from the software engineering team, who should not be passive bystanders for requirements gathering and analysis.
Unfortunately, requirements defects cannot be removed by ordinary testing. If requirements bugs are not prevented from occurring, or not removed via formal inspections or other methods, test cases that are constructed from the requirements will only confirm the errors rather than find them. (This is why years of software testing never found and removed the Y2K problem.)
Another issue is that for some brand new kinds of innovative applications, there may not be any users other than the original inventor. Consider the history of successful software innovation such as the APL programming language, the first spreadsheet, and the early Web search engine that later became Google.
These innovative applications were all created by inventors to solve problems that they themselves wanted to solve. They were not created based on the normal concept of "user requirements." Until prototypes were developed, other people seldom even realized how valuable the inventions would be. Therefore "user requirements" were not completely relevant to brand new inventions until after they have been revealed to the public.
Given the fact that software requirements grow and change at measured rates of roughtly 1% to 4% per calendar month during the subsequent design and coding phases, it is apparent that achieving a full understanding of requirements is a difficult task.
Software requirements are important, but the combination of toxic requirements, missing requirements, and excess requirements makes simplistic definitions such as "quality means conformance to requirements" hazardous to the software industry.
After Delivery
The issue of "growing requirements" is frequently underappreciated. Once software applications have been delivered to clients or customers, requirements do not stop growing and changing. For most applications, growth is continuous for as long as the applications are in use. They tend to grow at rates of up to about 15% per calendar year forever.
Because requirements and applications continue to grow, this means that application size increases, too, whether measured with function points, logical code statements, or any other metric.
To illustrate this continuous growth, the following table shows typical growth of a large Java application, based on my research.
| Measurement Intervals | Function Points | Logical Code Statements in Java |
1 Size at end of requirements |
10,000 |
530,000 |
2 Size of requirements creep |
2,000 |
106,000 |
3 Size of planned delivery |
12,000 |
636,000 |
4 Size of deferred features |
- 4,800 |
- 254,400 |
5 Size of first delivery to clients |
7,200 |
381,600 |
6 Size after year 1 usage |
12,000 |
636,000 |
7 Size after year 2 usage |
13,000 |
689,000 |
8 Size after year 3 usage |
14,000 |
742,000 |
9 Size after year 4 usage (mid-life kicker) |
17,000 |
901,000 |
10 Size after year 5 usage |
18,000 |
954,000 |
11 Size after year 6 usage |
19,000 |
1,007,000 |
12 Size after year 7 usage |
20,000 |
1,060,000 |
13 Size after year 8 usage (mid-life kicker) |
23,000 |
1,219,000 |
14 Size after year 9 usage |
24,000 |
1,272,000 |
15 Size after year 10 usage |
25,000 |
1,325,000 |
These numbers indicate larger-than-average growth at year 9 and year 13. For commercial software, it is necessary to add significant new features in order to stay current with competitive applications. These are called "mid-life kickers."
As can be seen, requirements growth never stops for as long as software applications are being used unless the developer withdraws support due to the release of a new product of the same type. Of course, some applications continue well past 10 years. For example, the U.S. Air Traffic control system have been in use for more than 30 years.
So Then…
Software requirements have been a very weak link in the chain of software engineering technologies. Because requirements are always incomplete and always contain errors, it is the responsibility of the software engineering team to ensure that state-of-the-art requirements methods are used. Users are not trained in requirements methods and cannot provide requirements that are complete and error-free without assistance from trained requirements experts, plus state-of-the-art requirements tools. Most importantly, software engineers should expect — even embrace — that this dialog with users about requirements will go on long after applications are delivered and running.
Capers Jones is a Vice President and the Chief Technology Officer of Namcook Analytics LLC. He collects data on software quality and productivity topics. He has written more than a dozen books on software quality, best practices, estimation, and measurement.
Andrew Binstock is on vacation.
