How to Document Nonfunctional Solution Requirements in Your Business Analysis Report

Nonfunctional requirements are just as important to your business analysis as the functional requirements when it comes to defining the look and feel of the solution. Nonfunctional requirements are a challenge because different people interpret them differently from organization to organization (or even from department to department in the organization). You need to understand a lot about the people using the solution and make sure your nonfunctionals document its performance.

You create the nonfunctional requirements based on your elicitations from the users, who they are, and what their expectations of the system performance are.

Make sure you elicit the nonfunctionals while you’re eliciting the functional requirements. A lot of BAs gloss over the nonfunctionals and instead concentrate on the functional requirements. But the nonfunctionals are important because they support the functional requirements, telling you how well something must be done. Eliciting both requirement types at the same time ensures that user requests and requirements are technologically feasible.

When you create nonfunctional requirements, you need to think about things like the following:

• Performance: How well does the system perform? To understand the performance requirements, ask stakeholders questions such as “What are the number of concurrent users?”, “What are the system or query response times?”, and “What is the system’s capacity in terms of memory, disk space, and data volumes?”

  Remember to speak in the language your audience understands. Don’t expect a response if you ask your business stakeholders how many hard disk partitions they need in their solution!

• Security: Who has access to the system, and how much access do they have? To understand the security requirements, ask questions such as “Which users are authorized to perform which functions?”, “What is the privacy of the information being captured and stored?”, and “What features need to be in place to log user access and authenticate users?”

  A useful technique for communicating security access within your solution (the first item in the preceding list of questions) is to create a security matrix. This matrix shows your stakeholders which users can access which processes (sometimes called use cases) within the system.

  

  Credit: Illustration by Wiley, Composition Graphics Services

• Reliability: Reliability is how the system operates based on the expectation of the end-user. Think about buying a car. You probably purchase a car because of the functionality (0–60 mph in 8 seconds, A/C, satellite radio, and so on), but you probably think about going to shop for that new car because of the reliability of the car.

  Similarly, you want to make sure you find out how consistently the business wants the solution to perform and what maintenance and support you need to make sure it stays that way.

  To elicit the reliability requirements, ask questions such as “When is the system expected to be available?”, “What downtime does the system have for the administrators to perform maintenance, and when is the best time to schedule downtime?”, and “What notification do the users need when the system is going down for maintenance? How much advance notice should they receive?”

• Compatibility: Compatibility refers to the extent to which the solution plays nice with other applications. To elicit compatibility nonfunctional requirements, ask questions such as “What common standards, common technology, and protocols exist on the workstation?”; “How well does the solution work with the common build?”; “What kinds of data exchange do you envision?”; and “What information (data) must be exchanged with other systems?”

• Maintainability: Maintainability deals with how easy the system is to maintain and repair. To elicit the nonfunctionals for maintainability, ask questions such as “What is the ability to change one component without affecting others?”, “What effects do the maintenance activities have on customers, users, and employees?”, and “Who performs system upgrades? Who is responsible for interfaces?”

  Business rules are highly likely to change, so when thinking about maintainability, make sure rules aren’t hard-coded.

• Transferability: Transferability refers to the ease with which a system can be transferred to a different hardware or software environment. Some of these concerns are lessening now that many companies are creating browser-based applications, yet these concerns have expanded with the mobile apps (like those you see on your smartphone) and the different versions and standards for e-readers.

  To elicit nonfunctionals, ask questions such as “Can the system be installed in a different environment (for instance, on a Mac and a PC) and in different geographies and different locations?”, “What operating environment is considered the base operating system (OS)? Will the code run the same way on all platforms?”, and “What government regulations need to be addressed?”

  When rolling out a system to different environments, remember that each environment needs to be tested. Rolling out to two environments doubles the testing effort.

• Usability: Usability concerns the ways by which the user is able to learn, operate, and interpret the system results. This category includes ease of entry, learning, and handling, as well as the system’s intuitiveness.

  Think about it this way: The reason you didn’t receive training on how to use a site like Google is because the application has fantastic analysts who concentrate on usability. To elicit usability, ask questions such as “How quickly should the user be able to perform specific functions?”, “How long should a particular task take?”, and “What is the minimum acceptable number of mouse clicks required to perform a task?”

  Stating “The system should be easy to use” isn’t a valid usability requirement. You must define what easy to use means through metrics.

• Metrics and measurements: With any nonfunctional requirement, you must understand what measurement criteria you’ll use to determine whether the requirement is successful and met. You’re defining how well the solution meets the requirements. To elicit the metric, ask questions like “What are some aspects surrounding that requirement that you can measure?” and “What are the acceptable measurement time frames that are acceptable for the stakeholder?”