This is a continuation of Requirement Categories – Part 1: General Discussion and Functional and Performance Requirements.

Operational Requirements: Shifting your perspective, it is useful to next think about how your system will interact with the outside world during all its lifecycle phases   Some life cycle phases  to consider include:

• Transportation:  Given your system needs to be moved and transported, have you addressed what this will involve?  Are special features needed to allow your system to be moved around?  Often the size and weight of a product is predicated on the mode of transportation.  Your system may be subjected to environments unique to the mode of transportation that are quite different than it will see during normal use or storage.
• Facilities:  What are the facility requirements so that your system can perform as needed. Facilities need to be considered for every life-cycle phase including manufacturing, testing, and storage.  Each may have unique handling, lifting, support/test equipment, and environments.
• Training and personnel:  What are the training and personnel considerations that reflect on how the product is designed and built?  The army does this real well…a 3 year enlistee cannot take 6 years to train. Training and personnel are hard requirements to write, but are often needed to reduce operational costs.
• Maintenance:  How are we going to maintain…in-house, send it out. What access is needed, what information needs to be generated by the system to help with diagnostics, what type of tools or test equipment will be used?  Unique interfaces may be needed to support maintenance.
• Environmental:  operational, non-operational, storage, etc. Address both induced environmental conditions as well as natural environment.   Also, include requirements related what your product is allowed to do to its operational environment: vibration, noise, heat, EMI/EMC, etc.
• Logistics:  What supplies and consumables need to be brought in and how often.
• Users:  Who is going to use the product.  Are they going to be able to do what they need to do during all lifecycle phases in all applicable operational conditions?

Each organization needs to define how they want this portion of their specification set up, but you need these, and possibly sub-areas as part of your checklist to ensure that none of these types of requirements are missed.  Operational requirements often cause problems if ignored because they can represent large costs, especially over the life-cycle.  In addition, each of these operational areas may result in unique requirements for your product and also will involve interactions between your system and other systems (interfaces).

Like functional and performance requirements, the operational requirements should be a natural fallout of your efforts in developing scenarios, use-cases, and operational concepts.  You should have addressed all of the above areas as part of these efforts before writing your requirements.

-ilities.  We call those requirements that end in “-ilty” (maintainability, interoperability, scability) “-ilities”.  -ilities  are often the biggest cost drivers and cannot be taken lightly, nor should you just cut and paste these requirements from one document to another without serious debate.  These are also often referred to as “Quality” requirements.  For your domain, you should define which –ilities need to be considered by all products your organization produces and make these part of your standard requirements document template.

Defining -ilities is very important to the overall success of project.  The sad thing is that they are often overlooked by both the customer and the developer.  -ility requirements  tend to impact the whole system and the cost to implement can be significant when compared to the other categories of requirements.  However, it is often the case that the -ility requirements are notdefined by those that use functional models.  In fact, the customer often assumes and expectes the ilities to be defined and implemented even though the customer did not explicitly include these requirements in the requirement set.  Thus the product or system may pass verification of the explicitly defined requirements but fail validation when the customer’s expectations are based on implicitly defined –ilities that were never documented.  Thus it is important that  –ilities be defined and documented so that what is ultimately delivered is what the customer needed.

Below is a partial list of –ilities.  Search Wikipedia for “-ilities” for a more complete list with definitions.  Someone has taken the time to not only define each of the –ilities, but have also provided examples.  Not all of these need apply to your system.

Maintainability:  meantime to repair (MTR), tools needed to repair.  Specific attributes of software that relate to ease of maintenance of the software itself, mode for troubleshooting, diagnostics, etc.

Operability:  ease of everyday operations…start automatically, cease operations, number of actions to do something

Availability:  What are your expectations for how often the product is available for use? 24×7, x% of time during peak periods?

Supportability:  what will it take to keep it up and running

Manufacturability:  Manufacturing requirements/constraints, need to retool.  Design of for assembly, design for manufacture, etc.

Reliability:  Life-time, failure rate, mean time to fail (MTTF).

Security and Safety:  Look for experts in these areas to get the requirements.  For many software systems security and safety are a major concern.  There are many standards and regulations dealing with both security and safety.

Interoperability:  The ability of software and hardware on different machines from different vendors to share data.

Go to Requirement Categories – Part 3: Physical Characteristics and Design and Construction Standards Requirements for the last blog in this series.

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.