Creating Non-Functional Requirements Documents
In this article you will explore documenting non-functional requirements with the goal of building an understanding of what documentation is and why we build documents.
What is a Non-Functional Requirements Document?
Documentation is an important part of the requirements management process. The purpose of a document is to output specific information about a project to be shared with stakeholders. Like many aspects of requirements management, documentation isn’t a standardized process. Teams approach documentation in several ways. How, when, and which documents are implemented within a process varies from team to team. If documentation is part of your process however, you’ll likely create a variety of document types and revisions to these documents over the lifetime of a project.
TABLE OF CONTENTS
- What is a Non-Functional Requirements Document?
- Document Types
- Functional Requirements Document (FRD)
- Product Requirements Document (PRD)
- System Requirements Specifications (SRS)
- Why Include Non-Functional Requirements in Documents?
- How Would a Tool Like Modern Requirements4DevOps Help With The Management of NFRs Within Documents?
- Interested in Seeing for Yourself?
The main purpose of documentation is to inform. However, documentation has some indirect advantages. For instance, documentation provides accountability. Documents are an easy way to create accountability for yourself to meet the requirements that were agreed upon. From the stakeholder’s standpoint, documentation adds a level of security as these documents act as a checklist for agreed upon requirements. Documentation can be used to verify if work was not completed or if they are being delivered what was paid for.
Another advantage to documentation is it allows teams to monitor the scope of requirements throughout the life of a project. Over the lifespan of a project requirements evolve. An individual requirement, for example, might become more clearly defined later in its life. As documents are recreated or updated over the course of the project, requirements can be compared between document versions. This enables members of a team to identify requirements that may be deviating from their original scope.
There is no standardized document that is built specifically for non-functional requirements. However, this doesn’t mean that you can’t build non-functional requirement specific documentation within your own process. Instead, non-functional requirements are typically included within a larger document type.
Several requirements documents exist which are built to highlight specific details of a project. For example, documents can be built for business requirements (BRD), technical requirements (TRD), and numerous other aspects of requirements management.
In relation to the documentation process, non-functional requirements are usually included within functional requirements documents (FRD), product requirements documents (PRD), and software requirements specifications (SRS) documents.
Document Types
Let’s take a basic look at a few of the document types listed above that include non-functional requirements to develop a better understanding of why these documents are created.
Functional Requirements Document (FRD)
The Functional Requirements Document is a formal Statement of an application’s functional requirements. An FRD is typically complied by a business analyst based on several interactions with clients and stakeholders with the goal of requirements elicitation. The creation of the FRD is conducted under the supervision of the Project Manager.
Non-functional requirements are typically found within their own section in an FRD. This section usually follows the functional requirements and will be labeled “non-functional requirements”. However, in some documents non-functional requirements may be categorized by system attributes (such as ‘Operational Requirements’) or listed under terms like ‘Non-Business’ requirements.
- Essentially a “contract” between product/system developer and client
- Developers are held accountable to the requirements in the document
- Demonstrates the value of product/system in terms of business objectives and processes
- Leaves no room for anyone to assume anything which is not stated
- What the application should do NOT how it works
- No reference to specific technologies
Product Requirements Document (PRD)
The Product Requirements Document is typically composed by the Project Manager. The PRD is used to communicate to the testing and development teams what functionalities are required to be in a product release.
Keep in mind the differences between functional and non-functional requirements. Non-functional requirements do no direct a product in terms of what the product should do. They address product attributes which determine how a product feels and other technical specifications that contribute to user experience. Product Requirements Documents are granular. The intent of these documents is to provide the overall direction for the product. Therefore, functional and non-functional requirements are addressed within their own sections of a PRD.
- Establishes a product’s purpose, features, capabilities, and how it behaves
- Defines user profiles, goals, and tasks
- Drives the product teams’ efforts related to sales, marketing, and support
- Product functionality addressed in document is supported by use cases
- Serves as the document of record that a release is based on
System Requirements Specification (SRS)
A System Requirements Specifications document is created to illustrate and describe the features and behaviors of software or a system. In most cases, SRS documents are written by System Architects or Product Owners who are experts in the domain. However, during the initial requirements gathering process Product Owners work alongside clients.
Non-functional requirements are once again found within their own section within the System Requirements Specifications document.
- Describes the functionality the product needs to fulfill all stakeholders/business/user needs
- Acts as a basis for all teams involved in development to follow
- Provide a basis for estimating costs, risks, and development scheduling
- Built to assess requirements before the more specific system design stages with a goal of reducing rework
- Contains critical information related to: development, QA, operations, and maintenance.
- Acts as a development checklist; helps to inform decisions about product lifecycle (the need for change to existing requirements to meet user/whatever needs)
- Prevent project failure
Why Include Non-Functional Requirements in Documents?
The real issue with the documentation process in requirements management is lack of standardization. Certain document types are more common than others. However, the structure and contents of these documents vary from team to team. Additionally, teams always have the option of approaching documentation on an ad hoc basis. As mentioned earlier, a team could approach documenting non-functional requirements within their own specific document.
The lack of standardization seems like a benefit that provides flexibility within the documentation process. Unfortunately, there are some negatives to this flexibility. Lack of standardization can result in non-inclusion of work items. Regarding non-functional requirements this can be detrimental to a products success as they define a products user experience.
To put this into perspective, consider a situation where you have tried two similar products. There is a good chance that you found you liked one of the two products better even though both products performed their intended functions. This is very likely because the product you gravitated to has a better user experience. User experience is driven by non-functional requirements. Building non-functional requirements that are well-defined, measurable, and testable allows teams to quickly and definitively measure the success of any project.
By including non-functional requirements within documentation provides these requirements greater visibility to be reviewed and refined. This visibility can also influence the creation and evolution of functional requirements within your document.
How Can Modern Requirements4DevOps Help Manage Non-Functional Requirements Within Documents?
Modern Requirement’s Smart Docs tool allows users to build the framework of their requirements documents directly within their Azure DevOps environment. When building a Smart Doc, requirements including non-functional requirements, can be inserted into the Smart Doc directly from the project Backlog. Additionally, non-functional requirements can be authored on-the-fly when building a Smart Doc.
Smart Docs is also equipped with a full version management tool that empowers users with the ability to version their Smart Doc at any time. Using version management, changes to work items like non-functional requirements can be tracked by comparing versions and exported as change forms.
Review management is also integrated within the Smart Docs tool. Modern Requirements4DevOps provides a single application review solution that promotes collaboration within the team to review and revise work items. By initiating reviews, team members and stakeholders can critically review work items. Regarding non-functional requirements specifically, reviews are a critical component of the management process as these work items can be used to gauge a project’s success. Being able to conduct reviews seamlessly alongside document creation promotes a strong workflow focused on building well-defined requirements.
Is lack of standardization within your own documentation process problematic? Smart Docs provides a solution to this industry wide issue with the ability to create reusable document templates. Using the Meta Template Designer tool, Smart Docs users can customize the structure of their documents. By building a customized structure for your document, users can decide what work items can be included and where they can appear within their document. Structured, reusable document templates enforce consistency and promotes efficiency (reducing document rework) within your team’s documentation process.
Interested in Seeing for Yourself?
With Modern Requirements4DevOps you can build requirements documents directly from within your Azure DevOps environment. Check out this Functional Requirements Document built with Smart Docs!
Experience for yourself how our Modern Requirements toolbox can empower Microsoft’s industry leading Azure DevOps into a single application requirements management solution.
Try Modern Requirements in the cloud here.
Author: Dane Crawford
Time to Read: 5 minutes
Related Articles
