Why was I making this point about requirements and defects, again?
Oh yes: to drill a big gaping hole in the reasoning provided by Boehm on the defect-cost-increase curve, leveraging Lean Startup and modern-day Agile thinking tools, but also an old favorite of mine in the sociology of science.
Boehm 1981: "If a software requirements error is detected and corrected during the plans and requirements phase, its correction is a relatively simple matter of updating the requirements specification."
The phrase "simple matter of updating the requirements" is eerily reminiscent, in its naïveté, of the much-derided "Simple Matter of Programming" (see the Jargon File).
It's certainly possible that some of the errors that are found during the process of agreeing to some version of a requirements document are in fact relatively simple to correct.
It's a far cry from that, to inferring that all defects that arise from thinking about the requirements of a software project can be a) detected exclusively through the activity of reading and rereading the requirements document, and thinking about it, and b) corrected by the simple expedient of making a change to the document.
A requirements document is generally the outcome of a long negotiation, which has significant political components. The cost of some changes to a requirements document may well be much higher, and in some cases as high as the abandonment of the entire project.
For instance, Latour observes of the Aramis project (which you can think of as a prehistorical "systems engineering" project) that some requirements of this public transportation system were intrinsically political: it was billed as a personal rapid transit system, i.e. one which would take you from your place of residence to your place of work (or other desired destination), but with the reliability and cheapness of mass transit: this was to be achieved by a sophisticated system of building software-linked "virtual trains" out of small (six-seater) individual cars.
But this "requirement" was at once one of the exciting aspects of the project, and one of the many reasons suspected for its downfall: it turned out to be incompatible with many other (implicit) requirements, such as the hardware-orientedtechnical culture of the transport authority (RATP), concerns that small cars would make passengers more vulnerable to assaults and insecurity (which has always been a major political issue in France), and the difficulty of entrusting so much of the system's function to a "software" component, at a time when software was deemed much too unreliable for safety-critical applications; a concern which was borne out by field tests, and ultimately resulted in partially abandoning this "requirement".
For another example, consider the insights provided by the "Lean Startup" Agile approach: it asks how much of your requirements document you can expect to be correct, if you never once "get out of the building" to actually meet with the prospective users of your product or service, and find out what actual problems they are experiencing and would be willing to pay money to get rid of?
Clearly the answer is "not much". You can rid your requirements of some "defects" such as contradictory statements, ambiguities and the like - logical errors - but to purge your requirements of business ignorance is another matter altogether.
How much does that typically cost? A heck of a lot, if you go the usual route of market surveys and focus groups. Even taking the time to interview users should be considered a significant cost, and at any rate an argument that "a simple matter of updating the document" is definitely not the only thing to be considered as a cost of "fixing requirements defects".
It may cost a lot less to actually build a small subset of your proposed product, try it out on a representative sample of your intended users, and "fix the requirements" if the hypothesis that users would actually be interested in your product is not borne out by the evidence - the solution advocated by Lean Startup.
Which is yet another take on what the term "empirical" can mean in software development...
Oh yes: to drill a big gaping hole in the reasoning provided by Boehm on the defect-cost-increase curve, leveraging Lean Startup and modern-day Agile thinking tools, but also an old favorite of mine in the sociology of science.
Boehm 1981: "If a software requirements error is detected and corrected during the plans and requirements phase, its correction is a relatively simple matter of updating the requirements specification."
The phrase "simple matter of updating the requirements" is eerily reminiscent, in its naïveté, of the much-derided "Simple Matter of Programming" (see the Jargon File).
It's certainly possible that some of the errors that are found during the process of agreeing to some version of a requirements document are in fact relatively simple to correct.
It's a far cry from that, to inferring that all defects that arise from thinking about the requirements of a software project can be a) detected exclusively through the activity of reading and rereading the requirements document, and thinking about it, and b) corrected by the simple expedient of making a change to the document.
A requirements document is generally the outcome of a long negotiation, which has significant political components. The cost of some changes to a requirements document may well be much higher, and in some cases as high as the abandonment of the entire project.
For instance, Latour observes of the Aramis project (which you can think of as a prehistorical "systems engineering" project) that some requirements of this public transportation system were intrinsically political: it was billed as a personal rapid transit system, i.e. one which would take you from your place of residence to your place of work (or other desired destination), but with the reliability and cheapness of mass transit: this was to be achieved by a sophisticated system of building software-linked "virtual trains" out of small (six-seater) individual cars.
But this "requirement" was at once one of the exciting aspects of the project, and one of the many reasons suspected for its downfall: it turned out to be incompatible with many other (implicit) requirements, such as the hardware-orientedtechnical culture of the transport authority (RATP), concerns that small cars would make passengers more vulnerable to assaults and insecurity (which has always been a major political issue in France), and the difficulty of entrusting so much of the system's function to a "software" component, at a time when software was deemed much too unreliable for safety-critical applications; a concern which was borne out by field tests, and ultimately resulted in partially abandoning this "requirement".
For another example, consider the insights provided by the "Lean Startup" Agile approach: it asks how much of your requirements document you can expect to be correct, if you never once "get out of the building" to actually meet with the prospective users of your product or service, and find out what actual problems they are experiencing and would be willing to pay money to get rid of?
Clearly the answer is "not much". You can rid your requirements of some "defects" such as contradictory statements, ambiguities and the like - logical errors - but to purge your requirements of business ignorance is another matter altogether.
How much does that typically cost? A heck of a lot, if you go the usual route of market surveys and focus groups. Even taking the time to interview users should be considered a significant cost, and at any rate an argument that "a simple matter of updating the document" is definitely not the only thing to be considered as a cost of "fixing requirements defects".
It may cost a lot less to actually build a small subset of your proposed product, try it out on a representative sample of your intended users, and "fix the requirements" if the hypothesis that users would actually be interested in your product is not borne out by the evidence - the solution advocated by Lean Startup.
Which is yet another take on what the term "empirical" can mean in software development...