We recently introduced the what, why, and how non-functional requirements, a specific technology guardrail for making better technology decisions. Let's continue that journey and dig into how to write non-functional requirements effectively.
If you need a quick refresher, please review the what, why, and how article referenced above, but in summary, non-functional requirements describe how a solution needs to be built, installed, or operated to work optimally in an organization's environment. They are typically used for a technology solution but can be equally effective when defining processes.
Writing Non-Functional Requirements That Work
The best practices for non-functional requirements are the same as those for functional requirements.
In addition to these practices for writing effective requirements, there are a few techniques specific to non-functional requirements.
Sometimes specific requirements only apply in certain conditions. Determining which ones to include can be handled in multiple ways, some of which impact how you write the non-functional requirements.
- Phrase the requirement so that the condition is apparent. “Run desktop components on Citrix” only applies if desktop components are in scope.
- Add an “if” statement to clarify. “Provide a self-service portal for password resets (if not managed in AD Azure)” only applies if AD Azure is not employed. In this example, there is another requirement to “Authenticate all users using AD Azure“
- Include a review process where a Solution Architect provides concierge service and assists with identifying which requirements apply.
There are also non-functional requirements for which some parameters depend on other solutions, business drivers, or user preference. For these, you also have options on how to write the non-functional requirements to address this.
- If there are a finite set of options (e.g., disaster recovery tiers), create multiple versions of the requirement and use an “if” statement to guide selection.
“Recover from a disaster in less than 4 hours (if business processes are criticality level 2)”
- If the choices are not finite, then write with a default metric that should be modified base on the context.
“Must respond to each request in less than 3 seconds for up to 300 simultaneous users.” The metrics can be modified as appropriate based on the context and user needs.
Getting Started with Non-Functional Requirements
Like the other technology guardrails, we recommend taking a pragmatic approach to rolling out non-functional requirements. Writing the non-functional requirements is a critical step but not the only step needed for success. You should first establish a baseline set of requirements, then iterate and improve from there.
Step 1: Gain Executive Support
Having top-down executive support will make this all much more effective. Non-functional requirements are a beneficial change to the organization, but change none-the-less and change is difficult! Management support can help grease the skids. Put together a presentation that pitches the benefits and explains the impact of the changes, then hit the road on an executive tour! Once you win hearts and minds, ensure there is a top-down communication of support. Keep the faith. Obtaining executive sponsorship is the most challenging part of the journey.
Step 2: Select a Framework
Select a set of non-functional requirement categories to help brainstorm and to validate coverage. There are plenty out there; you need to decide which works best for you. Here are a few:
- ISO/IEC 25010:2011 Systems and software Quality Requirements and Evaluation (SQuaRE) provides a comprehensive taxonomy of software quality characteristics and is our preference.
- Roxanne Miller proposes a model in The Quest for Software Requirements
- Wikipedia's Non-Functional Requirements article has a ridiculously long list of categories.
You can customize any of the above to suit your organization or create your own categories if preferred.
Step 3: Facilitate a Workshop
Use your non-functional requirement categories to determine who the best subject matter experts and technology decision-makers would be to brainstorm a starter list of non-functional requirements. Next, gather everyone in a room (virtual or physical) and go! Here's your workshop outline:
- What are non-functional requirements? Put together a light training deck. Or contact us. 🙂
- Review of NFR categories. Describe your non-functional requirement categories and use those for your brainstorm.
- Brainstorm NFRs! Don't worry about writing the non-functional requirements correctly; just get the ideas. Prompt with pain points and strategic technology direction.
Step 4: Write Your Non-Functional Requirements
Use the tips above for writing non-functional requirements based on the inputs of the workshop. Prioritize everything using “MoSCoW” convention (Must, Should, Could, Won't), then drop the Coulds. For non-functional requirements, we recommend adopting Musts for your “shall not pass” requirements (e.g., can't implement into production without them) and Shoulds for the rest. Nobody has time for Could non-functional requirements. Let them go.
Step 5: Reduce list to less than 50
Non-functional requirements are not free in terms of cost or time. Implementations will need to plan for both, which will be a change if projects are not already doing that, and potentially a significant difference. You are best off not sending them running for the hills with a tome of scary-looking technical requirements. Villagers with torches and pitchforks will not help you create value with non-functional requirements so start realistically.
Step 6: Gain Approval
While the benefits outweigh the effort, you are still introducing a new process, new scope, and, yes, new effort. That means the appropriate level of change control is required, like having an official board ratify the functional requirements. Ideally, you approve from an IT perspective (“we think these are the right NFRs”) and business perspective (“we trust IT and are willing to back this change”). The IT approval can be an architecture review board, IT governance body, or a leadership team. The business approval should be the highest and most broadly influential group available to you. Prepare for this! Ensure you can explain the benefits, risks, and implications of each non-functional requirement.
Step 7: Communicate
Don't claim victory yet. If a non-functional requirement is approved in the woods and nobody hears it, did it really get approved? Doesn't matter. If nobody hears it, you needn't have bothered. You need to publish the non-functional requirements along with the great material you put together on benefits, risks, and implications someplace readily accessible. Project processes will need refining to include the non-functional requirements are a standard part of product evaluation and implementation. You will also need to train any business and IT stakeholders that make technology decisions on the non-functional requirements and the processes for using them.
Let the Non-Functioning Begin!
There you have it! You have written your non-functional requirements, shouted them from the mountaintop, and can sit back and enjoy the improved technology decision-making. Not quite, but you have made the first important step. As with all technology guardrails, education and governance will be required, and periodic recalibration to ensure you have non-functional requirements that are guiding the organization in the right direction.
Best of luck on your non-functional requirement journey. We have done this quite a few times, so contact us if we can be of any assistance!