Most source material is not written with a clear division between “product” and “work”. This distinction is important in the SE context because legacy experience found that “work” could be subtly biased toward particular contractors, sometimes leading to serious corruption issues. A clear separation between “the dingus we want”, “what work we want done”, and “how we want things done” makes it easier to expose and mitigate those biases. As the gatekeeper for requirements, the task of separating these from each other is usually within the purview of System Engineering.
As an abstract distinction1, “product” characteristics are those that can be verified by considering the design itself in isolation from how it was developed, while “work” can be understood only by examining the Engineering deliverables related to the development effort. In this context “Engineering deliverables” excludes the reporting of results from direct inspection, test, demonstration, and analysis with respect to formally allocated technical requirements. Other usages of those four concepts, however, are usually included in the Engineering deliverables2.
Although the distinction between “product” and “work” might seem trivial, execution of this stage is not always straightforward:
– SoW can imply the existence of one or more technical requirement topics, against which requirements must be written in order to effect the intent;
– Even if technical topics are clearly distinguished at project start, it is possible that their parameterization and evaluation might not be available at that time. This can generate related SoW: to parameterize those topics and develop related values (see the exegesis about TBD). Such tasks usually require careful time-phasing. Contract definitization is sometimes held open until that work is complete.
– There are Engineering processes and practices that can reasonably be construed as either characteristics of the design or as developmental SoW. In the legacy DoD practices, these would typically be found in the “Design and Construction” section of MIL-STD-490 format specification. Some other specification formats exclude such concepts. This is a gray area, requiring judgment, expectation management, and consensus building within and between the interested parties.
– Verification of compliance with allocated technical requirements could, in its entirety, be construed as SoW. By convention, legacy practices do not construe it that way: the means by which a requirement is verified are considered an aspect of the design’s characteristics3. Lower-tier SoW can, however, often be traceable back to upper-tier Verification Requirements…that can get complicated!
– This issue implies (correctly) that technical issues and work issues can cross the technical/SoW boundary during verification rollup of the dingus.
– It is, in fact, possible for lower-tier SoW verifying a particular technical requirement to be “let” to a subcontractor specializing in the requisite verification method. In that case, no stand-alone technical requirements are associated with the SoW at all.
In the legacy, my usual practice for parsing the provisions of documents into such categories was to highlight a copy of the text. More recently, I have typically created databases (with fancy drag-and-drop User Interfaces) in support of that process. Here, however, I don’t want to inadvertently stipulate any particular set of data structures, so have returned to my earlier practice for all related examples . The color key is as follows:
Identifies work to be done. Usually resides in a Statement of Work.
A special case of SoW, being meta-instructions for analyzing requirements (e.g., tailoring, deconfliction, or allocation). These sometimes find their way into the requirements rationale.
Technical Characteristics of CI describe the design. Usually resides in a requirements document (specification or otherwise).
Technical Standards describe processes to be implemented in the development or manufacture of the design. Usually resides in a Process Standard (or equivalent).
All other text NOT containing relevant requirements is struck out.
The preceding distinctions are matters of intent, not document location. Non-SoW can be found in the SoW for either of two reasons:
1) The SoW can override lower-tier documentation. Therefore we can legitimately find technical characteristics and process descriptions in the SoW.
2) Where a process is specific to a particular project, the author of the SoW may elect to not manage separate documentation to define it. In that case, the author can legitimately include that language in the SoW directly.
Whether executed using drag-and-drop User Interfaces or with old-fashioned color-coding, it is important to retain this material as part of the requirements rationale. No other mechanism will admit to objective review of these decisions in their original context.
As a broad generalization, the most important items below are those that would be “analyst” SoW. Those items tell the analyst what attention should be paid to the rest of the material when reading it. The second group of things to be dealt with are the other SoW, because those might admit to a programmatic option to do something completely different from the procedural requirements that are found in the material being analyzed. Only after determining that “nothing different” will be done (which is a programmatic decision) should the rest of the relevant material (or relevant material ) be turned into explicit, traceable requirements.
Footnotes- See my standard caution about abstractions![↩]
- Insofar as they contribute for the rationale used to arrive at the design.[↩]
- that is, “if you didn’t prove it this way, I won’t accept that your design has the characteristic”.[↩]