A couple of common Spec and Requirements Writing Traps; Operator Requirements and “Shall be capable of...”
These are examples of poor spec generation and poor requirements writing.
Some Thoughts on “Operator” RequirementsEvery system is a combination of Hardware, Software and human operators. Consider a toaster, even the best toaster doesn’t unwrap the bread, put it in the toaster and “operate” the controls. The system (toaster) is useless without the operator yet we don’t think of the operator as part of the system. A delivered system consists of the hardware and software items that the contractor provides to the procurement agency under the contract. However, THE SYSTEM CANNOT OPERATE WITHOUT OPERATORS hence (I think) the quandary; how do we reconcile customer requirement like the system shall “turn bread into toast” without levying requirements on the operators? We have a couple of requirements writing strategies to help us, but first we must understand our intended design well enough to migrate the customer’s intention into a contractual specification (A-Spec). This requires analysis. The first analysis step is to define the context of the system. What is internal and what is external? There can be multiple perspectives on this, procuring agency, operating agency, using agency, but the ONLY one that matters is the contractors. Of course the contractors perspective must be accepted by the procuring agency, operating agency, using agency, etc, which is why we have SFRs, PDRs, CDR, and a multitude of TEMs, demos and working groups. The goal is to have consensus on what the system is and does. THIS IS THE NUMBER 1 GOAL OF SYSTEMS ENGINEERING — reaching internal and external consensus on what the system is and does. Requirements are never generated in isolation from system architecture. System architecture consists of HW, SW and human elements. Both requirements and architecture must be decomposed.
System designers may/must allocate responsibilities to Hardware, Software AND operators. With a toaster the allocation to the operator can be unstated, it is understood. Given the complexity of the systems we usually develop, what is the systems responsibility and what is operator responsibility must be unambiguously communicated, understood and agreed to. We have some requirements writing strategies to help us but Operations Concepts, system modeling (like scenario analysis — threads and Use Cases) and prototypes all help the communication. Requirements Writing StrategiesRequirements writing strategies include using phrases like “Upon operator input the system shall...”. This phrase clearly indicates that the system is not doing something automatically. Without this the customer(s) could legitimately argue that we agreed to provide an automatic function when none was intended. Expectations of automatic or autonomous action by the system are typically very costly, if possible at all. The second is to use “will” statements, “The operator will...”, this indicates that the designers and architects of the system clearly intend that the function following the will, is not being performed by the system. That function might be unwrapping the bread and putting it in the toaster, or it might be calculating the required delta V to perform a maneuver. A “will” in the spec defines performance of units outside the system, and is contractually binding. Since “wills” are not requirements they need not be verified. Assumptions can be used to document the contractors understanding of acceptable implementation and to aid reaching customer concurrence, but un-validated assumptions have no weight. The analysis necessary to craft
proper specs is non-trivial |
