Recommended Business Analysis Technique: Nonfunctional Requirements Analysis

The BABOK® Guide recommends that business analysts use the nonfunctional requirements technique on their projects. Let’s take a closer look at this technique and how this is actually done. Nonfunctional requirements define the overall qualities or attributes of the resulting solution or solution components. They constrain how the solution requirements are to be met by the solution itself as well as stating the qualities of behavior or quality attributes that your stakeholders want. Nonfunctional requirements augment the description of solution functionality by stating the solution’s characteristics in various dimensions that are important to the users or the developers. The BABOK® Guide recommends using a set of seven categories for your nonfunctional requirements:

Reliability: Reliability focuses on the solution’s availability when the stakeholders need it. You should also look at the solution’s ability to recover from errors or failures.

Performance Efficiency: Performance efficiency looks at the time it takes to perform activities and the resource utilization levels for the solution.

Operability: Operability measures the extent to which your stakeholders can recognize whether or not a solution meets their needs and how usable the solution actually is.

Security: Security looks at the solution’s ability to store information and protect its information from unauthorized use. Authentication of solution users and audit reporting is also considered.

Compatibility: Most solutions today need to operate effectively and either co-exist or interact with other solutions in the same environment.

Maintainability: Maintainability focuses on how easy it will be to change one solution component without affecting other components. You also need to consider component reuse, ease of diagnosing problems, and the ability to implement changes without causing unexpected failures.

Transferability: You need to determine whether your solution can be migrated to, installed in, and uninstalled from different environments as needed.

You should consider using a checklist for eliciting and developing your nonfunctional requirements. It is easiest to capture the functional and nonfunctional requirements at the same time. Checklists can assist you in organizing your nonfunctional requirements by category and to make sure you are not missing anything. Here’s an example from me:

  • Reliability (mean time between failures [MTBF])
  • Availability (expected hours of operation)
  • Maintainability (ease with which components can be replaced)
  • Performance (must return prompt within two seconds)
  • Environmental conditions (such as dirty, dark, or dusty environments)
  • Accessibility (different navigation for novice, experienced, and disabled users
  • Ergonomic (use of specific colors to reduce eye strain)
  • Safety (signals loud enough to be heard but not to harm hearing)
  • Security (physical and system access defining who is authorized to do what
  • Facility requirements (require special electrical or phone capabilities)
  • Transportability (weight limits of handheld units)
  • Training (any tutorials or textbooks required)
  • Documentation (online help, reference manuals)
  • External interfaces (support industry-standard protocols)
  • Testing (support remote diagnostics)
  • Quality provisions (minimum required calibration intervals)
  • Policy and regulatory (government requirements, constraints)
  • Compatibility to existing systems (support analog phone lines)
  • Standards and technical policies (conform to electrical codes)
  • Conversion (will support data from older versions of system)
  • Growth capacity (will support x end users across y years)
  • Installation (ability to put the new system into service)

Your nonfunctional requirements will need to be documented after they are gathered and analyzed. Usually they are typically documented alongside (or in the same section as) the functional solution requirements that they constrain. That makes sense, since the functional and nonfunctional requirements are both subsets of your solution requirements. I recommend documenting your nonfunctional requirements alongside the functional requirements they constrain or impact in some way. The exception is any global constraints. For these I typically use a separate section of my requirements document since global constraints impact all of the solution requirements in some way.

Well, that is our closer look at yet another successful technique used by business analysts, performing nonfunctional requirements analysis as part of your project.  Most project requirements consist of both functional and nonfunctional requirements, so business analysts use this technique a great deal. I usually elicit and analyze both types of requirements together, and try not to miss anything important!  Give me a shout if you have another BABOK® technique you would like to explore in more detail!

Susan Weese

Business analysts are increasingly becoming the critical liaisons between business and solution development (oftentimes IT), so they must communicate and relate with equal effectiveness throughout all levels of an organization. Download this free White Paper to see which five common obstacles business analysts face and how to address them to ensure success.

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.