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.