A friend of mine recently sent me the following email after he read our blog post How to Refer to Other Documents within your Requirement Document

“I’m intrigued that the conversations seem to concentrate almost exclusively on “functional” requirements and their associated performance parameters.  I’ve found, over the years, that we get into lots of trouble with the “non-functional” requirements – mass, power, cooling, environments, logistics, EEE, etc. ”

Requirement Categories

When organizing your requirements, we find it useful to have more granularity than just “functional” and “non-functional” requirement categories.  We also advocate organizing your requirements using a comprehensive requirement document template/outline.  This template/outline not only serves as a checklist for completion for the Requirements phase, but also provides you assurance that you have covered all your bases and you have not missed any requirements.    The basic outline we use at the system level is as follows (note that you can add sub paragraphs for the various sub-categories that apply to your particular system domain.):

• Functional/Performance
• Operational
• -ilities
• Physical Characteristics
• Design and Construction Standards

In this post I will provide a more detailed discussion on the functional and performance requirements, and in part 2 and 3, I will go into more detail for other categories.

Note:   Some requirements can be put into more than one of requirement category.  For example a functional requirement may address an operational consideration.  The important point is that you have identified the requirement.  Where you put it is up to you, as long as you are consistent in that type of requirement’s placement.

Rule of thumb:  Rules that some organizations use are:

• If the function deals with a primary function/purpose/capability of the system, address it in the Functional/Performance section.
• If the function deals with a secondary concern during operations in order to accomplish the primary functions, document the requirement in the operational section.

For example, a function that involves installation but does not have anything to do with a primary purpose of the system it would be documented in the Operational section.

Functional/performance Requirements: We tend to write these best – they are what the system has to do to fulfill its Need.  These can also include interface requirements when the function involves an interaction with an external system.  Functional requirements are unique and are the heart of what your system is expected to do and capabilities it needs to have.  Performance requirements tell us how the function will be done – how well, how often, how much, how many, etc.  When documenting your performance requirements make sure they trace to the functional requirement they apply to.

It is a natural thought process to first think about functional and performance requirements. There are many approaches to developing functional and performance requirements including functional decomposition and functional modeling.  Often if you have developed detailed scenarios, use cases, or operational concepts, you can look at the verbs and identify the functions.

For example:  In one of your scenarios, you address your system’s monitoring the work environment.  In the scenario, several functions are identified that have to do with the stakeholder expectations for “monitoring”.  These functions include recording and displaying temperature, humidity, and airflow data as well as controlling the values of these items to within a defined range.  Thus from the scenario, you can write functional requirements for the three functions involved in monitoring: recording, displaying, and controlling.  Then for each of these you would define specific performance requirements of how frequently the data is sampled and displayed, how much history is expected to be maintained, and specific parameters for the range the measurements are to be kept within.

While very important, if you focus just on functional and performance requirements, you will be missing many other requirements that you need to define for your system.  That is why we advocate using the other categories as well.

I am trying to keep each blog post to a reasonable size, so I will end this post here and pick up the more detailed discussion of the other system level categories in Requirement Categories – Part 2:  Operational and –ility Requirements and Requirement Categories – Part 3: Physical Characteristics and Design and Construction Standards Requirements.

If you have any other questions on requirements, feel free to ask your question on our “Ask the Experts” page and we will do our best to provide a timely response.