|
The problem we have is not a spec writing problem in isolation from our analysis and design problem space it is the merging of these and the inadequate capture of our intention through “sloppy” requirements writing. Operators are not part of the SYSTEM being procured but they are part of the system being designed. This distinction is non-trivial and I believe the root of the disconnect. I believe we all would agree that a specification must specify what the SYSTEM (HW & SW) must do. The problem is when design implementation calls for operators to perform significant aspects of required functions using the system rather than, the system doing these tasks autonomously. This distinction must be captured clearly in the spec to avoid misunderstanding between customer and contractor (and the lawyers). It is correct to say that we should not have “operator requirements” in the spec (although it is acceptable) however we must then address the sloppy requirements capture that necessitates placing caveats on these ambiguous requirements. Here are 3 strategies in descending order of “purist” preference: 1 .Correct the poorly worded requirements to remove ambiguity between what the system does and what the operator does. 2. Include companion “will” statements that indicate what our expectation of what the operator’s role is. 3 .Write companion assumptions and get customer buy off on our assumptions. As with most things in life doing it right the first time is always the cheapest, fastest, best. |