How to Write Non-Functional Requirements in 6 Steps
Teams build non-functional requirements (NFRs) by identifying system attributes like security, reliability, performance, maintainability, scalability, and usability and then specifying them in clear, measurable terms.
This is important since non-functional requirements (NFRs) are crucial to ensure system effectiveness, usability, longevity, and user satisfaction.
For that reason, this article covers how to write NFRs in 6 steps and who writes them with examples and templates to guide you.
Note: If you want to learn what non-functional requirements are, the differences with functional requirements, and take a deep dive into the types of non-functional requirements, then read Non-Functional Requirements Explained (With Real Examples).
Table of Contents
1. Who Writes Non-functional Requirements?
Non-Functional Requirements (NFRs) are typically written by various stakeholders involved in the project. This usually includes:
- Business Analysts: They often take the lead in identifying and documenting NFRs because they typically deal with clients while being part of the company creating the products. As a result, they have a clear view of the needs, preferences, and expectations of both clients and internal stakeholders.
- System Architects/Engineers: Because of their intimate understanding of the system architecture, limitations, and affordances, their input on NFRs is invaluable.
- Product Owners/Managers: They can help define NFRs based on customer needs, business needs, and market knowledge.
- Quality Assurance (QA) Teams: They can contribute to defining NFRs relevant to quality standards, legal compliance, and testing criteria.
Learning how to write and/or create non-functional requirements is a collaborative effort. So effective communication among all parties is key to accurately defining and implementing them.
2. How to Write Non-functional Requirements in 6 Steps?
Step 1: Identify Scope and Purpose
The scope of a project guides what resources or deliverables you can add or remove as the project progresses based on identified stakeholder needs. It also determines which NFRs the team creates. Poorly scoped projects and non-functional requirements (NFRs) can lead to significant issues like cost overruns, delays, stakeholder dissatisfaction, and even legal problems.
Studies show 85% of construction projects with scope creep exceed their budget, with an average cost overrun of 27%.
As an example, if a system is a real-time video streaming application, then performance-related NFRs (like video fidelity and downtime) would be highly relevant.
Step 2: Gather Input from Stakeholders
The best way to ensure that a system meets business, customer, and market needs is to get input from stakeholders. It also prevents significant issues like cost overruns and legal exposure. Getting stakeholder input is doable in two steps:
- Engaging Stakeholders
Identifying who the stakeholders are at the beginning of a project is crucial. Stakeholders can be classified into primary, secondary, and tertiary groups, depending on their direct impact and influence on the project.
After identifying both internal and external stakeholders, teams can move on to collecting requirements, including non-functional requirements.
- Collecting Requirements
Requirements gathering is how teams collect information from stakeholders to define project requirements, including non-functional requirements.
Requirements gathering techniques include a variety of qualitative and quantitative methods like interviews, brainstorming, focus groups, and surveys. The choice of technique depends on the project’s scope, allotted resources, and stakeholder availability.
The best project management tools also allow teams to collect requirements from other sources like emails, notes, FAQs, and uploaded Word documents.
Teams have now started using cutting-edge AI tools to automate requirements elicitation, making it more efficient and comprehensive.
Step 3: Categorize Non-functional Requirements (NFRs)
Categorizing non-functional requirements (NFRs) guides the design of the product/service and influences its performance, security, and user satisfaction. Poorly categorized NFRs can lead to projects that don’t satisfy stakeholder needs. Here are two ways to categorize NFRs:
- Sorting by Type Non-Functional Requirements (NFRs) can be categorized in three main ways:
- Operational Aspects: These focus on the system’s effectiveness and security under normal conditions. For e.g. The system should serve 10,000 active users simultaneously without a significant drop in streaming quality.
- Revisional Aspects: These ensure the system can adapt to changes with minimal effort. For e.g. The system should scale up to accommodate up to 15,000 users without a major system breakdown.
- Transitional Aspects: These relate to the system’s ability to smoothly transition, such as integrating with other systems or adapting to changes. For e.g. The system should run on all major operating systems (Windows, macOS, Linux) on all form factors (mobile, PC, desktop, tablet) without needing significant change.
These categories help in understanding and managing NFRs during the development of a product, system, or process.
- Sorting by Priority: Once you understand which types of requirements you are writing, it’s time to prioritize them. The method you use depends on your project needs. Some common techniques include MoSCoW, RICE, the priority matrix, and more.
- Sorting by Type Non-Functional Requirements (NFRs) can be categorized in three main ways:
You can prioritize NFRs by several aspects of the business and project, including:
- Business Value: Prioritize NFRs based on their impact on the business value of the system. NFRs that significantly enhance the system’s value should be given higher priority. E.g. for a small city car, an NFR outlining fuel efficiency carries more business value than one determining shock absorber comfort.
- Risk Assessment: NFRs associated with higher risks should be prioritized. For example, security-related NFRs might be given higher priority in a banking system. NFRs outlining the car’s compliance with Euro NCAP safety ratings for side impacts help keep passengers safe from harm.
- Stakeholder Input: Consider the input of stakeholders. Some stakeholders may place more importance on certain NFRs.
- Cost and Time: NFRs that require significant resources or time to implement might be given lower priority, unless they are critical to the system’s operation or business value. E.g. a state-of-the-art infotainment system is a lower priority if it is too expensive to implement.
Legal and Regulatory Compliance: NFRs related to legal or regulatory compliance often have high priority due to the potential consequences of non-compliance. In a famous recent case, carmaker Volkswagen installed “defeat devices” in their diesel vehicles to cheat emissions tests, which violated emissions regulations. The scandal cost the company $30 billion.
Step 4: Define Measures and Metrics
NFRs may be broad and confusing to grasp for some, but they are just as critical to a project’s success as functional requirements. The way we structure a non-functional requirement should indicate a few important pieces like:
- What are you measuring?
- Is it an application, a system, a project, or a process?
- What attributes are you measuring?
- Is it scalability, maintainability, security, or something else?
- What is your goal?
- What metrics are you using to determine success?
You can condense these answers into one statement: “The [insert answer to A] should be [insert answer to B] so that/to [insert answer to C]”
For a scalability related NFR, this statement could read:
- “The system should be scalable to 10,000 users within the next 2 years.”
- “The application should be scalable to handle 10,000 concurrent logins per minute”
Whenever possible, an NFR should have both a metric and a measure.
For instance, if you wanted to build a non-functional requirement using an operational attribute like reliability, you can ask the following questions (and answers):
Questions |
|---|
What are you measuring? |
What attribute(s) are you measuring? |
What is the goal? |
What are the measures and metrics you are using to determine the goals success? |
Answers |
|---|
We are measuring a system. |
We measure reliability. |
We want 100% uptime in the first year. |
Our measure is 100% uptime, our metric is uptime |
You can condense these answers into one statement:
- “The system should be operational so that we see a 100% uptime for the first year of operation in order to meet our 1-year performance guarantee.”
Adding some more information about why this NFR has these criteria as above is an option.
As you can see you can build non-functional requirements using templates. If you are interested in learning how to build NFRs using templates, read Building Non-Functional Requirements Templates.
Despite the template, it’s always possible to forget to add non-functional requirements. You should take appropriate caution in that case.
Step 5: Document your Non-functional Requirements
Documentation serves to inform and provide accountability, acting as a checklist for agreed requirements and a tool for verifying completed work. It allows teams to monitor the evolution and scope of requirements throughout a project’s lifespan, helping to identify any deviations from the original scope. While there’s no standardized document for non-functional requirements, we will cover the three main types of documents here:
- Functional Requirements Document (FRD): This is a formal statement of an application’s functional requirements, typically compiled by a business analyst and supervised by the Project Manager. It serves as a contract between the developer and client, outlining what the application should do.
- Product Requirements Document (PRD): Typically composed by the Project Manager, the PRD communicates the required functionalities for a product release to the testing and development teams. It establishes the product’s purpose, features, and behavior, and drives the efforts of the product teams.
- System Requirements Specification (SRS): This document, usually written by System Architects or Product Owners, describes the features and behaviors of software or a system. It acts as a basis for development, provides a basis for estimating costs and scheduling, and contains critical information related to development, QA, operations, and maintenance.
Tools for Non-Functional Requirements Documentation
Teams need good documentation tools which are easily editable, shareable, and integrated into their workflow like:
- Smart Docs: This allows users to build requirements documents, track changes with version management, and initiate critical reviews of work items, including non-functional requirements.
It also addresses standardization issues by enabling the creation of reusable document templates with a customizable structure, promoting consistency and efficiency in the documentation process.
Document Management System: It is built to handle documents during the entire project duration, performing tasks of uploading, structuring, and versioning of documents and folders.
These and many more tools for extending requirements management within Azure DevOps are available with Modern Requirements4DevOps.
Step 6: Review and Revise
As time goes on, teams, companies, and stakeholders will notice that their list of non-functional requirements will grow and change. This is expected as the needs of an organization adapt and change. This is a crucial step in the management of Non-functional Requirements (NFRs).
For instance, a healthcare application might generate log files that record patient activity or system transactions. Regular cycling of these log files is essential to recover disk space and maintain the application’s performance.
As time goes on, teams, companies, and stakeholders will notice that their list of non-functional requirements will grow and change. This is expected as the needs of an organization adapt and change. This is a crucial step in the management of Non-functional Requirements (NFRs).
For instance, a healthcare application might generate log files that record patient activity or system transactions. Regular cycling of these log files is essential to recover disk space and maintain the application’s performance.
3. How Do Non-functional Requirements Help with Standardization?
Non-Functional Requirements (NFRs) play a crucial role in standardization, particularly in industries where regulatory and compliance issues are paramount. For example, in the medical devices industry, which is heavily regulated, operational attributes such as confidentiality are of utmost importance.
The International Organization for Standardization (ISO) defined specific NFRs that must be strictly followed during any medical device’s development. These requirements are categorized under various ISO standards like:
ASPICE – Software development requirements for automotive manufacturer
- Ensure real-time efficiency under peak loads.
- Comply with automotive safety standards.
- Secure against unauthorized access and data breaches.
- User-friendly interface for drivers and technicians.
- Consistent performance in varied conditions and stress.
ISO 13485 – Quality management systems for medical devices
- Management Controls
- Product Planning
- Quality Process Evaluation
- Resource Control
- Feedback Control
ISO 14971:2007 – Application of risk management to medical devices
- Management Responsibilities
- Risk Analysis Process
- Risk Control
- Risk Management Process
- Risk Management Report
4. Mastering Non-Functional Requirements
Knowing how to write, define, and document non-functional requirements (NFRs) is crucial for project success. Well-defined NFRs impact time management, user satisfaction, and compliance. Teams should focus on clear, measurable system attributes like security, reliability, performance, and scalability. Understanding and managing NFRs enhances system effectiveness, usability, and longevity, ultimately driving project success.
But non-functional requirements are only a part of product or project success. Typically, you will need a requirements management solution that has several features like:
- Smart Docs: Document authoring, formatting, and linking within Azure DevOps.
- Copilot4DevOps Plus: Game-changing AI requirements management tool.
- Smart Reports: One-click generation and sharing of project snapshot reports within Azure DevOps.
- Traceability: Work item traceability within Azure DevOps with Horizontal and Intersectional traceability matrices available.
Modern Requirements4DevOps is an award-winning tool that extends Azure DevOps into a single source of truth.
5. Other Questions We Get Asked About Non-Functional Requirements
Here are the answers to some common questions we get asked about non-functional requirements:
-
- What are some organizational strategies to ensure effective NFR?
Here are some other organizational strategies that can help you maximize their impact. - Prioritize: Plan and create non-functional requirements with the same care as other types of requirements
- Benchmarks: Use industry benchmarks when determining the efficacy of a non-functional requirement. For instance, an industry standard for a website’s load time is 2 seconds. Teams should use tools like GTMetrix and Google Page Speed Insights to compare their website.
- Long-term Mindset: In a DevOps context, a team needs to think in the long term. You should choose the non-functional requirements appropriately.
- Collaboration: Encourage collaboration and communication among team members to ensure everyone understands and works towards meeting the NFRs.
- Training: Provide training to developers on the importance of NFRs and how to effectively implement them in their work. This can help to ensure that NFRs are not overlooked during the development process.
- What are some organizational strategies to ensure effective NFR?
- Who writes non-functional requirements in Agile? System and Solution Architects and Product and Solution Management create non-functional requirements in Agile collaboratively.
- Are non-functional requirements written as user stories? Yes, sometimes you can write non-functional requirements as user stories. For instance, you can write a security NFR as, “As a user, I want my personal data to be encrypted, so that my information is protected from unauthorized access.”
