Software rework, as everyone knows, is a scourge of many software development and maintenance efforts. This has been the case since software was first developed. A major reason for software rework has been a lack of quality and detail in elicited software requirements. This has been known for many years, but unfortunately knowing the issue and fixing the issue are two different things. This unresolved rework issue has many consequences, including the likelihood of project failure and the cost of software development and maintenance.

According to the 2007 IAG Requirements Survey, 100 Fortune 500 companies found that only 32% of them employ requirements practices that make the likelihood of project success “probable,” while the remaining 68% enter every project with an “improbable” likelihood of success. Those companies with poor requirements and business analysis capability had three project failures for every project success, and companies with poor requirements spent, on average, $2.24 million more per project than those employing best requirements practices. Clearly, increasing the probability of project success and reducing project costs are in order, again.Software rework is not actually a problem but a symptom of many problems. When one tries to solve symptoms instead of problems, the problem often does not get solved. One of the problems causing software rework is lack of detail in a software requirement description. Many times the content of a requirement is too abstract and often lacking any context or proper context. Unfortunately, those who might try and utilize a poorly described requirement might have to guess and therefore become a requirement victim instead of a requirement beneficiary. These victims are primarily designers, coders and testers. The other victims of poor requirements are the rest of the stakeholders.

Knowing that a software requirement is a specification of what must be implemented both functionally and non-functionally helps. Many misinterpret specification in that definition to mean a specification document. That is unfortunate. Specification in this context should be interpreted as “the act of making specific.”

A requirement hierarchy is very helpful when eliciting and documenting specifications of what must be implemented functionally. In creating the hierarchy, the thought should be that abstract requirements have children of less abstract requirements and so on until the requirement cannot be decomposed anymore. If one tried to decompose a detail requirement (the last child level in a hierarchy) they could not but would naturally have to describe how the requirement should be implemented. That is the conceptual line between requirements and design, where the “what” turns into the “how.” Note that when modeling use cases, the system steps should be modeled to the detail level often in internal and external extension use cases.

An analogy might help those trying to create a better requirements hierarchy or explain what a better requirements hierarchy structure should look like. Think of decomposing a United States dollar into pennies. A dollar is one hundred pennies and one hundred pennies is a dollar. The dollar is abstract and the penny specific. There are other “levels” between the dollar and the pennies and these other levels are less detailed abstractions. Using Dr. Karl Wieger’s software requirement level model from his book “Software Requirements” to complete the analogy, the flow of abstract to detail requirements would be business requirements, then user requirements and then functional requirements. Business requirements are like dollars that might have children of fifty cent pieces. Business requirements might decompose or trace to user requirements. User requirements (the quarter level) might be use cases. Initial sentences of system functionality in a use case might be the nickel level, and lastly, detail sentences of system functionality from the nickel level might be pennies. The idea is to go from “dollars” to “pennies” as quickly as possible. Note that the adoption of an Agile development approach ensures going to the “penny level” only on functionality for the sprint currently being developed.

Reducing rework means eliciting, documenting, validating, designing, coding and testing “penny level” requirements proactively in the Agile sprint currently being developed. That way the system design will “work (no or few bugs)” as well as “do what it is supposed to do (implement validated requirements).” A measure of quality is the gap between the two. Proactively, a software requirement is called just that: a software requirement. A software requirement that is discovered reactively after development is called a bug. Most software bugs are written at the “penny” level. I think we know why…

In conclusion, the suggestion is to get the requirements to the penny level for the Agile sprint currently under development to save millions of dollars of rework costs. Saving millions with pennies, now that is a good idea. Did the designers, coders and testers of this world just collectively sigh “Amen”?

A partial hierarchy example from “dollar level” to “penny level”:

1. The system shall enable maintenance of all travel reservations. (dollar level)

1.1. The system shall enable maintenance of all flight reservations. (fifty cent level)

1.1.1. The system shall allow travelers to book a flight reservation. (quarter level)

1.1.1.1. The system shall prompt for flight selection criteria. (nickel level)
1.1.1.2. The system shall validate flight selection criteria. (nickel level)

1.1.1.2.1. The system shall ensure 6 is the maximum number of seats for a refundable ticket. (penny level)
1.1.1.2.2. The system shall ensure 180 days is the maximum number of days between flight reservation booking and flight departure. (penny level)

1.1.2. The system shall allow travelers to view flight itineraries. (quarter level)

1.2. The system shall enable maintenance of all car reservations. (fifty cent level)

1.3. The system shall enable maintenance of all cruise reservations. (fifty cent level)