Warning: Missing argument 1 for get_post(), called in /homepages/40/d113440603/htdocs/barbarabea/wp-content/plugins/constant-contact-forms-by-mailmunch/public/class-constantcontact-mailmunch-public.php on line 122 and defined in /homepages/40/d113440603/htdocs/barbarabea/wp-includes/post.php on line 362

Mr. Jim’s Theory of Functional Requirements

The Theory

Functional requirements specify what the system should do.

And the only thing a digital system can do is change the value of a data item. If the system reads a data item but does not store the value somewhere, it has not really “done” anything.

In a hardware system a data item is a bit, or a register or a memory location.
In a software system a data item is a variable.

Since the only thing a digital system can “do” is change the value of a data item, every functional requirement should name the data item that is changed. As a consequence, every functional requirement could be written as “the system shall set the data item name to …”.

The remainder of the functional requirement should specify the processing that is needed to create the new value for the data item that is to change.

It turns out that a functional requirement is the human readable equivalent to an assignment statement. This equivalence has been enshrined in process documents by NASA’s Goddard Space Flight Center and by the Space and Naval Warfare Systems Command. Both have items in their requirements review checklist that direct the reviewers to verify that all the “functional requirements [have] been stated in terms of inputs, outputs and processing”. The equivalence was also explained in more detail in “Requirements Statements Are Transfer Functions: An Insight from Model-Based Systems Engineering” by William D. Schindel.

It also turns out that all of the nouns used in a functional requirement are names of individual data items or names of collections of data items.

Let’s call the data item that is changed the output of the functional requirement. All the other nouns will be called inputs.

If a data item name that is an input to a functional requirement is a system input it should be defined in some kind of system interface document. If an input is not a system input, it must be the output of some other functional requirement. Otherwise, the functional requirement is using a data item name that is undefined. OOPS!

This actually happens a lot in functional requirements. The three biggest causes for undefined inputs are
• missing functional requirements
• the use of synonyms
• failure to name the output.

The synonym issue is easily taken care of with a glossary.

The missing functional requirement issue is also easy to correct, but only after you identify that a functional requirement is missing. In my experience with several sets of functional requirements that have been reviewed multiple times, and have even be implemented, about 30% of the implemented functional requirements are missing from the requirements document.

The failure to name the output data item is harder to correct. First the output needs a name and the requirements sentence needs to be rewritten to use it. Then the requirements that use the output data item need to be found and their sentences need to be rewritten to use the name.

If the data item name that is the output of a functional requirement is a system output, it should be defined in some kind of system interface document. If the output is not a system output, it should be used as an input to one or more functional requirements. Otherwise, the effort to produce the output is wasted and either the functional requirement is superfluous or there is a missing functional requirement. Most of the time there is a missing functional requirement. The only exception I am familiar with is debugging information. Sometimes a system will record extra information in a “read only” manner. Rather like the black box recorder on an airplane.

In requirements, it has long been the custom to do traceability. Every requirement, except those at the very highest level should be traceable from a higher level requirement, their parent requirement. Likewise, every requirement except those at the very lowest level should be traceable to one or more lower level requirements, their children. This is vertical traceability. It is very important. It is also handled very well by existing requirements management tools.

A new concept, which is derived from the theory of functional requirements, is horizontal traceability. That is where the output of a requirement is used as the input to some other requirement. This leads to the idea of a “complete” set of functional requirements. “Complete” in the sense that all of the system outputs can be traced horizontally through a chain of functional requirements back to the system inputs. It is OK to have unused system inputs, but it is not OK to have undefined system outputs.

And a complete set of functional requirements is the foundation upon which you can build a testable definition of an unambiguous functional requirement. Almost all the requirements books say that one of the attributes of a well written requirement is that it is unambiguous and therefore only has one possible interpretation. In my experience, a functional requirement is unambiguous when it is reviewed by three people and there are fewer than five interpretations. Which is to say that none of the requirements books gives a testable definition for what makes a requirement “unambiguous”. Having a complete set of functional requirements, each of which is equivalent to an assignment statement is the starting point that leads to a testable definition of “unambiguous”.

See the Unambiguous Functional Requirements page for the complete definition.

The Impractical Application

Without some kind of automated assistance, checking that all the inputs to a functional requirement are either system inputs or the output of some other functional requirement is infeasible. Possible in theory, but falls apart in practice because the effort required grows very quickly as the number of requirements increases. Beyond a dozen or so, it becomes cost prohibitive. This also holds true for checking that the output of all the functional requirements is either a system output or an input to some other functional requirement. Infeasible twice over.

The Practical Application

The Requirements Completeness Excel Macro is a partially automated tool for checking that a set of functional requirements is “complete”. The user must identify the data item names (noun phrases) and enter them into the spreadsheet. After that the macro can match up all the inputs with outputs and all the outputs with inputs. Any mismatches are identified by turning the cell red and an error message is inserted in the status column. A bit of a pain, but in practice it is a very cost effective way to find and fill in most of the missing functional requirements.

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>