Working with Requirements

This is the foundation page for the topic of Requirements

Driven by the DoD acquisition practices from which legacy practices sprang, System Engineering (SE) generally works with three broad categories of requirement.  Other than the basic definition, these flavors of requirement have little in common1.  To the extent that they’re in-scope to SE, the concepts and practices are accessible through the links embedded in each definition.

Laws of a sovereign entity

Legal and regulatory requirements2 take precedence over all other types of requirement.  Here, I set aside the special case of National Emergencies3.  Not intending to lawyer anything, this website makes no effort to expound further on this flavor of requirement.

Operational requirements

These are the province of the End User.  Operational requirements are abstractions of specific practices or objectives held by the End User.  The practices and objectives might be either strategic or tactical from the End User’s perspective.  The practices and objectives might also be either real or desired, to be effected in  at the End User’s discretion.

Acquisition requirements

These govern the purchase of services to design, qualify, and produce systems, being the province of the Acquisition Customer.  These requirements are further divided into three types:

Contractual requirements

These are the Terms and Conditions (T&C) binding a contract‘s parties, leaving them liable to court action4 when left unmet.  The T&C take legal precedence over the other two types of acquisition requirements.

Work requirements

These are provisions in a project-specific Statement of Work (SoW).  The requirements of the SoW5 have lesser precedence than those of the T&C.  The SoW addresses the work done by organization, institutions, and people to the extent it is called by the applicable contract.

Technical requirements

Technical requirements are those found in specifications and certain process standards that are called by the SoW or by the T&C.  These are the requirements to be met by the target system being procured, including (but not limited to) the hardware, software, and procedures.  Technical requirements are subordinate to provisions of the SoW, being effected only to the extent called therein.

Afternote

Because certain kinds of technical requirement can be found in standards, and “standards” are about process rather than directly about product, it is possible for there to be “gray area” between SoW requirements and technical requirements.  To make matters worse, a SoW can itself contain technical requirements that (because of the precedence issue) can over-ride the provisions of either specification or standard.

Unfortunately, the SoW precedence issue is not the worst case.  Because it is of higher authority, the T&C can over-rule the SoW…and regulations and laws can out-rank that.

The ugly truth is, a good System Engineer has to be at least conversant with all of these requirements when working at the “top” of a project.  Good System Engineers are not, unfortunately, born: they can only be trained.

Footnotes
  1.   So this page is much shorter than you might otherwise expect![↩]
  2.   that also carry the force of law[↩]
  3.   In which case System Engineers should bloody well better do what needs to be done and sort out the blame later.[↩]
  4.   Usually civil.[↩]
  5.   Whether incorporated directly or by reference.[↩]