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.
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.
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.
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.
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.
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:
You can customize any of the above to suit your organization or create your own categories if preferred.
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:
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.
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.
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.
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.
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!
