Projects rarely start out with an orthogonal set of requirements. This unfortunate reality often generates one of the most common early System Engineering (SE) tasks: to “compile” one. Such compilation often proceeds from a diverse array of sources, not all of which agree with each other.
Figure 1 sequences several common stages of requirements compilation. The sequence shown is an “archetype“. Other orders of operation are feasible, depending on the circumstances and type of material. The detailed processes internal to the various stages in Figure 1 can also be composed differently. In all cases, however, the basic ideas remain applicable, as does the objective of the exercise.
Aside
“Compiling” requirements is distinct from “deriving” requirements.
– Compilation assembles an integrated picture of relevant decisions already published by one or more superior authorities. It can discard information that isn’t relevant to the selected conceptual design if one exists at that point, but it invents no new information even though the text of the compiled requirements might not be word-for-word identical to the original versions.
– Derivation invents new material. As an over-simplification, it operates on the basis of existing requirements in the context of a conceptual design1, where that context is under the same Configuration Control layer as are the derived requirements.
In this context, “new material” might mean “new topics”, “new measures”, “new values”, “new circumstances”, or information fitting any combination of one or more field(s) described in Table 1 of the things I think I know about requirements in any context variant identified in Table 2.
Stages of work in the archetypical sequence are discussed below. It should be noted that, in all cases, these are entirely cognitive processes. Bias mitigation is available only to the extent that the supporting rationale is documented.
Aside
The reader will probably have noticed that the sequence shown in Figure 1 doesn’t meet my standard definitions of either “process” or “algorithm“. That’s by design, because it is less than either. Being an archetype, it merely contains pieces that can be assembled into one of those two concepts (perhaps with augmentation).
Survey
A compilation survey identifies the pertinent sources of requirements.
In legacy SE practices, requirement sources were always some form of authoritative documentation, which might (or might not) have been specific to a project, product domain, operational domain, or technology2. More recently, it is also possible for requirements to source to configuration-controlled, authoritatively supplied models3. When working from a model, it might be necessary to survey the source code, inputs, results, or all three.
Compilation surveys are most efficient when conducted by personnel with applicable experience in development of the target product line, because they’re usually familiar with the potential sources and topics. As always, however, over-reliance on experience can lead to unintentional biases in the results of the process. Traceability, of an at-least-informal nature4, is recommended in order to support auditing of the overall compilation process.
For example, a development contract might contain a list of applicable documents: the survey would collect and ascertain their relevance. Depending on how the contract is structured, that survey should also disposition5 documentation that is definitively referenced in the directly allocated body of material.
It is usually necessary to review legally imposed regulations (e.g., the Code of Federal Regulations) to assess applicability to the project at hand. Depending on extant inter-governmental agreements, it might also be necessary to review the analogous regulatory material for more than just one of the countries in which the product will eventually be offered for sale or operation.
The (nominal) end of the survey should occur when a comprehensive list of source material has been assembled, with each being fully understood. It is (however) possible that additional material will be discovered after development is underway: contracts can be modified, new laws can be passed, new regulations can be published, and the “clock” can expire on regulations that are “grandfathered”.
Deconfliction
When more than a single requirement source exists, and the sources are not coordinated by their originators, it is possible for the same topic to be addressed by more than one source. It is, therefore, possible for multiple sources to contradict each other. Conflicts require adjudication and, sometimes, clarification by the issuing authorities. The process is often referred to as “deconfliction”.
A simple example of conflict would be where an applicable General Specification directs the coloring of all doors to be green, but an applicable Safety Standard directs emergency exit doors to be striped in yellow and black. It is not possible for both to be met. Deconfliction provides a venue to resolve the contradiction.
The purpose of this stage has nothing to do with whether the authoritative material negatively influences one or more preferred technologies or designs6. That problem is exclusively left to the tailoring stage, described below.
Although this objective can be addressed at any point in the compilation process, it is shown early in the archetypical sequence because the overall workload is minimized when deconfliction is executed in the broadest context. It is (however) possible that some aspects of deconfliction cannot feasibly be accomplished until after some of the subsequent stages of compilation are (at least prospectively) executed: deconfliction might produce more accurate results with the clarity and focus stemming from topical analysis and parameterization. That sequence is a judgment issue, and the question should be assessed with careful forethought. It is possible that no single sequencing will suffice for the entirety of any given project.
There is always a risk that subsequent compilation tasks will invalidate deconfliction, causing it to be revisited. This is one of the reasons to retain traceability data and deconfliction rationale (it can be a long time before all of the subsequent tasks are complete). It should also be noted that the results sometimes have to be reported in the original context in order for them to be accepted by the authority (customer or regulator). Without traceability, it can be very difficult to reconstruct such frameworks consistently.
Deconfliction often (but not always) directly results in the first decomposition of provisions in the source material. This is because different authorities can group their topics differently and, without decomposition, no adjudication of precedence can be accomplished.
Classification
See the brief exegesis on Classification In the Compilation Context.
Tailoring
Tailoring is the explicit modification of the intent in an authoritative source. In the legacy SE practice, it was usually applied in the context of General Specifications, but could be applied to other forms of documentation.
The tailoring process operates in two basic modes:
– Eliminating provisions that do not apply to the project at hand because of specific product domain, operational domain, or technology. For example, provisions specific to the use of metals would not apply when the developer restricts itself to the use of plastics in the design. This mode does not require prior approval, but usually requires explicit verification (or substantiation) that the provisions do not, in fact, apply.
– Explicit alteration of the source material’s specifics up to and including the stated intent, usually by showing that some other approach achieves some abstract objective to the authority’s satisfaction. For example, a developer can seek to convince a regulator that some new verification approach is at-least-equivalent to the originally mandated version. This mode almost always requires “prior approval” from the original authority7.
In both modes, tailoring produces a new document (or, sometimes, a new model) for which traceability to the original is strongly recommended. The new material replaces at least part of the original, which is not allocated to tasks on the development project.
Topical Analysis
See the foundation page for Topical Analysis.
Parameterization
See the foundation page for Topical Parameterization.
Complementation
See the Technical Requirements page.
Evaluation
See the Evaluation page.
Other examples of Compilation processes.
Footnotes- or, sometimes, concept of operations[↩]
- In order of increasing abstraction.[↩]
- Where, presumably, some or all of the inputs to the model are at the discretion of the developer.[↩]
- What we used to call an “Engineering Notebook”[↩]
- collect and assess for inclusion or exclusion[↩]
- Yes, I have seen people make this assertion.[↩]
- That is, “permission” rather than “forgiveness”.[↩]