Return to About Requirements

Requirements are captured in many ways. In the government realm, this is usually done through codification into laws, regulations and contracts including Performance and Conformance Specification. In the corporate realm, it often comes in the form of Charters, Bylaws and Policies and Procedures (P&P) and contracts with other entities (see above).

Regardless of where the requirements are captured or by what organizations, they can in general be considered governing statements. The following are some guidance on how to write healthy governing statements and consequently also requirements.

A Governance Statement based on an Engineering Governance Model developed at US Navy SPAWAR¹⁾ is defined as atomic, succinct, absolute and definitive in nature. It contains specific instructions which can be validated through observation, measurement or testing.

• Atomic - A Governance Statement only addresses a single topic. Indicators of non-atomic guidance are use of highly complex sentences, multiple sentences or conjunctions such as and, or, etc.
• Succinct - A Governance Statement are short and to the point. The definition of terms or caveats that explain when a statement is applicable are not acceptable as part of the Governance Statement. Indicators of non-succinct statements are the use of words or expressions such as: consider, when possible, if, etc.
• Absolute - A Governance Statement is evaluatable with one or more non-subjective questions. Indicators of non-absolute statements are those which are subject to the interpretation of the evaluator. For example, “All menus must be user-friendly“. No one produces menu's that they feel are user hostile.
• Definitive - A Governance Statement is precisely worded and explicit in nature. Their words, terms and expressions need to be defined and not subject to interpretation. Indicators of non-definitive guidance are words that are not intuitively obvious to an outside reader. Some words that are examples of non-explicit words are: object, service and function.

Another issue or controversy with specifying requirements is how the statements use imperatives originally defined in RFC2119 - Key words for use in RFCs to Indicate Requirement Levels, words like:

• Shall (Requirement)
• Must (Requirement)
• Will (Requirement)
• Should (Requirement)

A major sticking point is the use of the word Shall²⁾ which basically claims:

• lawyers regularly misuse it to mean something other than “has a duty to.” It has become so corrupted by misuse that it has no firm meaning.
• it breeds litigation. There are 76 pages in “Words and Phrases” (a legal reference) that summarize hundreds of cases interpreting “shall.”
• nobody uses “shall” in common speech. It’s one more example of unnecessary lawyer talk. Nobody says, “You shall finish the project in a week.”

However, the counterargument is that Must should not be use because no one has defined how must is different from shall. Also, shall has held up in court, must has not. ³⁾. So, whether you should use Shall or Must is a matter for the Community of Interest (CoI) to determine, and it should be consistent.

There is an excellent reference in How to Write and Exceptionally Clear Requirements Document⁴⁾.

[char]Review