Non-functional requirements can be some of the most important requirements to capture on a project, for they can mean the difference between a highly successful project, and one that is a complete failure.

Wow…that was quite a strong statement. As I look back at it, and ponder if it is really true, I think about the many different projects I’ve been on over the years that either did not pay attention to non-functional  requirements or did not pay enough attention to them. 

And as I ponder the success or failure of those projects, the things that come to mind as problematic with those projects are the “little” things…performance, scalability, ease of use…all of those non-functional requirements that were either missed or glossed over.

I recently helped one of our large customers in the oil and gas industry with an internal project delivery conference that they hold every other year. This conference is targeted at their project managers and business analysts, and it’s an opportunity for these communities to learn new things, to network, to share information. 

I was asked to pull together a presentation on non-functional requirements for one of the breakout sessions for the conference, as this is a topic of interest to both project managers and business analysts.

So what are non-functional requirements? Non-functional requirements are requirements that specify criteria used in evaluating the operation of a system instead of specific behavior as is the case with functional requirements.

There is no agreement within various industry groups on what these types of requirements are called. “Non-Functional Requirements” is what you hear the most. They are sometimes known by other names, including: System Qualities, Quality Requirements, Quality Attributes or Quality Characteristics. 

The Software Engineering Institute (SEI) calls them Quality Attributes. IIBA calls them non-functional requirements. Regardless of the name, all groups are addressing the same thing.

In the BABOK, IIBA has defined non-functional requirements as requirements that document the qualities of a system that are important to:

• The user community, such as usability, learnability, reliability, etc.
• The development community, such as scalability, maintainability, reusability, etc.

Per the BABOK, non-functional requirements are usually organized into categories. Categorization supports the discovery of non-functional requirements by providing a mental checklist of characteristics to consider when performing requirements elicitation. The scheme that the BABOK lists is based on ISO 9126, but the BABOK also states that other categorizations (such as FURPS+) may also be used.

The characteristics that IIBA supports are:

• Reliability
• Performance
• Efficiency
• Operability
• Security
• Compatibility
• Maintainability
• Transferability

Why are non-functional requirements important? Here are some examples from an actual project.

• Issues in portability led to delays to deployment schedule result in sub-optimal resource utilization and delayed benefits realization.
• Poor supportability characteristics lead to inflated time/cost to identify and resolve solution defects.
• Poor deployability characteristics lead to inflated time/cost to install/verify the current solution.
• Stakeholder confidence severely impacted; the stakeholder was then leery to use IT again for future projects.
• Cost overrun was 100% of project budget.

There are many different techniques one can use to elicit non-functional requirements, including:

• Templates in requirements management tools or requirements specification documents can list out the categories of non-functional requirements to consider.
• Interviews with individual SMEs are useful.  Ask about specific types of non-functional requirements and get their response. Also observe as part of the interview if the SME has some assumptions that are truly non-functional requirements.
• Prototyping is another way to capture non-functional requirements, especially around usability.  While many usability requirements may have already been captured, this is a terrific way to refine and further define those non-functional requirements.
• Observations involve watching users to analyze their current behavior. Be on the lookout for basic assumptions that can lead to non-functional requirements, especially around performance, reliability and usability.
• Facilitated sessions are another option.

At the end of the conference we looked at the preliminary feedback that we had collected from the participants. Since I was heavily involved in the construction of this session, I was very curious to see what the participants thought. 

It was very gratifying to see that not only did the session rate as one of the highest in the conference, but this look at non-functional requirements also got numerous call-outs as one of the most memorable take-aways for conference participants.