The Smart Docs Module

The Smart Docs Module

The full replacement for Microsoft Word when managing requirements

In this article we cover the features and benefits of the Smart Docs module. 
Designed to bridge the gap between document creation and requirements management, Smart Docs empowers users with documentation capabilities within Azure DevOps. This means your documents now live within your team’s project, and your team can finally benefit from a complete and central source of truth.

What is Smart Docs?

Smart Docs is an online document authoring system that is built directly into Azure DevOps. As part of
the Modern Requirements4DevOps Enterprise Edition, this module stands as a full replacement for
Microsoft Word when managing requirements.
There are many engaging ways to use Smart Docs.
The most obvious way this tool can benefit your team is by allowing you to create living requirements
documents within Azure DevOps. What do we mean by living requirements documents? If you have ever
used Microsoft Word as part of your requirements management process you have undoubtedly had to
deal with the pains of changing requirements. Changing requirements is in and of itself typically
something teams can handle, but when a requirement is in “some document” which lives “somewhere”
… teams can go mad.
Building living requirements documents means that you can create a Smart Doc and include your
requirements within that document. If you update a requirement from the Smart Doc interface, or make
changes to a requirement in the backlog, that requirement will be updated everywhere. This means no more hunting for documents which contain the requirements you have changed.
The documents we see teams using include, but are not limited to:
  • Business Requirements Documents
  • System Requirements Documents
  • Functional / Non-functional Requirements Documents

What value does Smart Docs offer?

As a purpose-driven tool, Smart Docs has been uniquely designed to tackle real-world issues our users
are currently facing, or which they have already faced in the past. By working closely with our
community, and strategically incorporating feedback, we have built a tool that offers the following
unique value proposition:
  • Documents (and their versions) created in Smart Docs are saved within your Azure DevOps
  • project.
  • Removes the need for all third-party applications and document repositories.
  • Documents are updates automatically as requirements change anywhere in Azure DevOps.
  • Documents can be versioned, compared, output, and reviewed, directly from with Azure DevOps.

What are the Use Cases for Smart Docs?

When we asked a group of prospects how important documentation is to their requirements management process, we found that most teams value documentation to a high degree.
We also found however, that teams found documentation to be the first thing to “fall by the wayside” when a project gets going.
When asked why this was the case, teams responded that it was the most difficult asset to maintain, and
that document creation required a large amount of time copy and pasting and the asset was often being
maintained separately from their requirements.
The following represents only a few Use Cases for Smart Docs.
My team currently copy/pastes requirements from Azure DevOps to Microsoft Word in order to create
This takes a lot of time and is an error-prone process that we can’t rely on.
Using Smart Docs removes the need to copy and paste requirements to and from Microsoft Word. By
building up and maintaining your documentation in your project, you can trust that everything is always
up-to-date and ready for exporting.
My team has stopped using documentation because of the duplicate work required to create both
requirements and documents separately.
By using Smart Docs your team can now choose to build their requirements in Azure DevOps and drag
them into any document, or type a new requirement into their document and it will automatically show
up in your project’s backlog. As a true central source of truth model, Smart Docs will allow your team to
build everything once and use it wherever they need. Including in a document.
We only use documentation to get reviews from Stakeholders.
By using Smart Docs you can take advantage of the online document reviews we offer by using Smart
Docs in tandem with our Review module. If you are doing document reviews any other way you could
encounter the following obstacles.
  • One person is responsible for the entire review.
  • There can be multiple Stakeholders.
  • The person responsible for the review must consolidate the changes each Stakeholder would
  • like made to the document.
This produces a final document that needs to go through the approval process again.
The cycle repeats – in some cases for weeks.
With our document reviews, your team can collaborate and see all requested changes before a
document is altered. These changes can then be approved, and a final document created in one cycle.

How do I use Smart Docs?

A completed Smart Doc is an easy to navigate collection of both context sections and requirements.
Teams use Smart Docs everyday for the benefits it adds over a Microsoft Word driven process. 
Here are some of the ways your team can use Smart Docs. 
Make a Meta Template:
Before your team jumps head-first into Smart Docs, you will want to create a Meta Template. Meta Templates offer you the ability to construct a structure to your document. You can choose where team members can place context elements (Sections), and where they can add specific requirements in your document. This is a one-time operation and can be used with multiple documents built on the same structure.
Add Context to your Documents
Teams can add context to Documents by adding in a rich-text Section.
Once a Section is added to your document you can add rich text to it the same way you do in Microsoft Word.
This allows you to have free form control over the content that gets added into any given Document.
Create a Reusable Document Template
Many teams currently have a requirements document sitting on their Desktop which includes all the necessary elements that that document needs to include. For instance, your team might have a “BRD Template” they open which already has the Introduction, Scope, Risks, and a placeholder for Business Requirements already laid out to get started quickly. Our reusable templates offer the same ability, allowing users to quickly get started with a Document Template of their choice.
Add Requirements to your Documents
You can add requirements into your document in one of two different ways using Smart Docs.
  1. You can publish requirements into your Azure DevOps project simply by building onto your document. This allows you to add to your project from a document-driven workflow.
  2. You can insert requirements that are already in your project into any document.
All requirements added to documents will reflect any changes made elsewhere in the project. This means if you need to change a requirement in the backlog, those changes will already be reflected in the latest version of your document – no more need to update requirements in several places.
Explore Version Management
You can manage document versions easily using our built-in version management tools. Versions can be created manually or automatically depending on how you plan to use your documents. The version management tool comes complete with a Compare feature which enables you to compare any two versions of a document and see an easy to understand red-line view of the changes.
Have your Document Reviewed
You can send documents to Stakeholders (for free) for them to review. Using our Review module, document reviews enable all your document reviewers/approvers to collaborate in the same space. This way teams can see who has approved/rejected a work item and why. Teams can then discuss changes before any change is enacted.
Output Documents
Last but not least, all of the document you create in Smart Docs can be easily exported as Word, PDF, or HTML. We allow nearly limitless customization of your document when saving as Word, and provide you options to configure different attributes of a requirement to include in your report.
Time to Read: 5 minutes

MR Email Service & Dirty Flag

MR Services - Mail, Custom ID, Dirty Flag

The extra features of Modern Requirements4DevOps

In this article we cover some of the extra features that are available in the Enterprise Plus edition of Modern Requirements4DevOps. These features are called MR Services.

These features provide added control over changes made to work items, allow you to connect your project to an email service, and help you add increased traceability and usability to your project.

Modern Requirement Email Monitor Service

The Email Monitor feature provides access to your project through a medium that does not exist in Azure DevOps. That is, it allows you to communicate with your project via email. Teams often encounter situations where they are emailing about a Work Item that should be created, and often they are able to use emails to drive towards a conclusive requirement that should be added into their project.

With the Email Monitor feature your team can now turn this external communication into a Work Item directly.

By enabling the Email Monitor feature in the Modern Requirements4DevOps extension panel, you can specify an email address that can intercept and build any requirements that are emailed to it.

Use Case for Email Monitor Service

The most common use case for the Email Monitor feature is as follows:

I have a large organization and I would like all members of my organization to add any bugs they find in my software to my Azure DevOps project.

With Email Monitor fully configured with the, any member of my organization can simply send an email to and I could specify that a bug should be created in my project.

At the same time, the email that triggered the bug’s creation is also sent to the relevant people of that project. The relevant members can now participate in the discussion of that Work Item via email, and all email communications will be added to the discussion properties of that Work Item within your project.

This unique feature allows people to contribute to your project’s success without needing to fully access your Azure DevOps project. External parties can now become part of the discussion about a Work Item, and does not require you to provide that person access to your project.


Dirty Flag / Suspect Links

The Dirty Flag / Suspect Link feature contributes to your projects success by making the impact of Work Item changes both query-able and, generally, more noticeable.

This feature is meant to implicitly highlight any requirements that might be affected by the changing of a linked requirement. You can consider this feature as one method of doing impact assessment on changing requirements within your project.

How does Dirty Flag / Suspect Links work?

This feature works by allowing you to monitor Work Items which meet certain conditions. When these Work Items change, the monitor feature will mark any linked Work Items.

Let’s consider an example:

User Story 1 has just been moved to the ‘Completed’ state. If the Dirty Flag / Suspect Links can be configured to trigger a flag if any changes are made to user stories in a “Completed” state (i.e. a change to a field such as ‘Description’)

This means that if User Story 1’s Description field is changed in the future, it will flag all of the requirements that are linked to it with a Dirty Flag.

This allows your team to easily identify if a requirement that matches a certain set of criteria (which you specify) changes. Once identified, all directly linked Work Items will be flagged by the Dirty Flag / Suspect Link capability.

To continue with our example, if User Story 1’s Description field changed, we could Dirty Flag all of the directly linked Test Cases that might need to be changed to test the new criteria changes.

The Dirty Flags that get set on those Test Cases would take the shape of a Work Item tag.

Tags show up in the Standard Work Item editor of Azure DevOps.

In the case of the Dirty Flag tag that is set on Work Items, the tag that is applied includes both the changed Work Item’s ID, and revision, so that your team can easily identify which requirement was it that changed and fired the Dirty Tag / Suspect Link functionality.

Custom IDs

Many applications offer the functionality to add Custom ID’s to Work Items. The intent of this type of feature is to make a field more readable and recognizable.

Our Custom ID feature offers the same benefits alongside the added benefits of using the Queries module.

Custom ID’s can be setup as a custom property that exists on each of your Work Items.

The Custom ID property offers an easy method of identifying all the necessary information of a given Work Item all within one field. It also proves to be an incredibly useful tool for identifying a requirements source in cross-project queries.

By allowing you to consolidate the information into one field you make a Work Item more approachable to less involved users. The Custom ID capability adheres to the following guidelines:

  1. Work Items can be assigned a unique code. For example, a Requirement Work Item type’s code would be REQ and a User story Work Item type’s code would be US.
  2. You can create the starting number that your Work Item types will increment from thereafter. For example, you can dictate that User Story Custom ID numbering should start at 00001 and it will increment every User Story’s Custom ID by thereafter.
  3. You can also add an optional project prefix for any Custom ID. For example, a project name such as “Project X” could have the prefix PX assigned to it.
  4. Finally, you can choose to include the Scope of any Work Item. The ID number is not repeated in the scope; the scope can be Team, Project or Collection.

Using the example covered in the above guideline, a Custom ID for the first (00001) Requirement Work Item in Project X would be “PX-REQ-00001” – which is a concatenation of the project prefix + Work Item code + number

Time to Read: 5 minutes

Request a Demo!

  • Schedule a demo with one of our trained product experts.
  • Receive a personalized demo that mimics your team's process
  • Engage our experts on topics such as workflow or best practices.

Reduce UAT Efforts

50% Reduction in UAT efforts

Proven Time Saving

80% time saving on creating Trace Analysis

Streamline Approvals

Significant reduction in approval delays

Increase Performance

50% requirements productivity improvement

Reduce Rework

10-fold reduction in development rework

Simplify Compliance

40% reduction in compliance reporting efforts

Modern Requirements 2019: Update 2

Release Notes

Modern Requirements4DevOps 2019 - Update 2

Welcome to Modern Requirements4DevOps 2019 Update 2! Many improvements and enhancements have been added in this release. The following is an annotated version of the release notes to help guide users through the update to Modern Requirements4DevOps. 


A completely new tool has been added to Modern Requirements to assist you in your project traceability and management needs. The MR Artifact Tool!

The MR Artifact Tool is accessible from the context menu of any work item. This tool lists all Modern Requirements artifacts that the work item is associated with! Now users can now quickly access which Modern Requirements artifacts are utilizing the work item selected.  

This tool currently can trace work items that are contained in Smart Docs, Reviews, and Baselines.

The Compare Tool, used for direct comparisons between work item revisions has, for lack of a better work, been revised!

RevisionIDs are now further demarcated by new properties. The new properties are Last Approved and Last reviewed. These properties will apply themselves to revisions of work items that have undergone review during their life cycle.

These properties will be displayed next to the RevisionID in the dropdown menu of the Compare Tool.

When using the Compare Tool, the tool will automatically populate a default revision into the dropdown menu. When a dropdown menu is opened, the Last Approved and Last Reviewed work items will be shown respectively at the top of the list. They will be followed by the remaining revisions shown in descending order (newest to oldest). 

When the Compare Tool is invoked, the left dropdown menu will always display the relevant revision of the work item. When opened from the Backlog, this field will be populated with the latest revision. When launched from a Review, this field will default to the revision of the work item that was included in the review. If accessed from a Baseline, this field will display the revision of the work item as it was at the time the baseline was created.

The right dropdown is the compare revision field. If the work item has taken part in a review, this field will default to the Last Approved revision.

If an approved revision does not exist, this field will default to the Last Reviewed revision.

If the left dropdown defaults to the latest approved revision of a work item, the right dropdown will remain empty.

The Compare Tool can be accessed from a newly created work item. However, without any revisions the right dropdown will again be empty.

When invoking the Compare Tool from within the Compare Baseline tab, the tool functions differently. The comparison is no longer automatic as the user is manually comparing the work item between two baselines. The dropdowns within the tool will instead default to the revision of the work item included in each compared baseline.

While using the Compare Tool, the user can interact with either dropdown and make any comparison between revisions.

Smart Docs

Smart Docs has increased in functionality with the addition of three new features…

Child work items created in Smart Docs can now automatically inherit properties of their parent!

Smart Docs’ Meta Template Designer now allows users to configure work items with inheritable fields. When creating a sub/child work item on-the-fly from a parent node, values from configured fields can be inherited from the parent. This rule is not applied when inserting existing work items.  

Smart Editor has also introduced a new feature with read-only fields.

Individual fields can be defined as read-only within the process template. Smart Editor will also treat these fields as read-only.

Modern Requirements Stakeholder interaction with Smart Docs has further improved with the introduction of the option to open work item. Previously stakeholders could not open work items – now they can!

When enabled, Stakeholders invited to the project will be able to open items in Azure DevOps’ standard editor.

Stakeholders can access this feature from both the Document and Compare tabs of Smart Docs.

Additional enhancements have been made to the current features of the Smart Docs module.

The Meta Template Designer now gives users the ability to update saved Document Templates. Previously, this functionality only applied to meta templates; now document templates can also be updated!

This provides users with the ability to make on-the-fly changes to any of their document templates.

Functionality includes:

  • Change work item hierarchy
  • Rename Templates
  • Delete Templates
  • Clone templates; create a unique version of template to edit

Changes made to Document Templates can be applied to all Smart Docs using the template. After changes are made, a user just needs to use the “Update all Templates” feature in the Smart Docs toolbar.

A major change has been made to the aesthetic form of Smart Docs.

Both text and image wrapping have been improved in Smart Docs as all included data will now properly be wrapped to the successive line.

This is a purely aesthetic change. However, this change should greatly improve the readability and the way an individual will visually consume the output document.

Smart Docs’ title, HTML fields, large images, and tables will all benefit from this improvement.  

Review Management

Some very functional additions have also been made to the Review Management module.

As a review initiator, you will now be able to Submit Comments without needing to be a reviewer – a review initiator is a reviewer by default.

Two new types of Audit Reports have been added to the Review Management module.

Approval Audit Report:

Report includes complete details of approval actions applied to the work items in the review

  • Details will include if a work item was approved or rejected and by which user profile, response comment, review action, additional comments, and added linked work items.

Review Results Report:

Report Includes the complete details of review actions applied to the work items in the review

  • Details will include if a work item is reviewed and by which user profile, response comment, review action, additional comments, and added linked work items.

It should be noted that the existing Review Audit Report will be retitled as Legacy Audit Report.

 Users still have access to Legacy Audit Report option.

The Review Management module has received several enhancements to its core functionality.

The way Modern Requirements handles Review metadata has been completely overhauled. When creating a review, the corresponding metadata will now be saved in your repo (source control).

Review metadata was previously stored within the HTML field of a Feedback Request work item.

Update 2 has also brought changes to the operational process of Review Management.

The previous review creation process was slow and link heavy; three links were created for each work item included in a review.

In Update 2, when a review is created, links will no longer be created between the Feedback Requests and work items included in the review.  

Additionally, a Feedback Response work item will no longer be created by the system when a user provides a review response (approval/submit review).

The new process is more efficient and link-free to mitigate Azure DevOps’ restriction of 1000 links/work item limit.  

Additionally, automation has been improved when completing common actions within reviews.

When using the Link work item feature to link a work item to an approval or rejection, the link will be made directly to the work item the user is currently reviewing.

Comments provided in the Details tab will be automatically added to the Feedback Request work item along with the profile information of the comment poster.

Upon the completion of a review, a comment will be added to the Feedback Request work item along with the profile information of the participant.

When reviews have been closed, no further action can be taken for approval and commenting. This will prevent review stakeholders from being able to add additional comments or link work items to the closed review.

Changes have also been made to update the UI of the Review Request popup form.

  • When initiating a Review from Smart Docs, work item section will no longer be shown
  • When previewing a Review, the list of selected work items will no longer be shown
  • The body of an email generated during a Review will no longer contain the list of selected work items


The Baseline module has improved its capabilities with the addition of new features to improve trace and manage your work items.

When comparing Baselines, users can now configure which individual link types trigger a change indicator. Previously, users only had the option to disable the trigger or have it applied for all link types. This configuration can be found within the Admin Panel.

Difference Reports have been enhanced to only show fields that have been configured as trigger for change indicators. Previously, the Compare Tool UI and the Difference Reports were not in sync.

With the inclusion of tracking link type changes between baselines, Difference Reports will include the ability to report on link type changes. 

The Copy/Reuse Baseline Tool has also received some boost in functionality.

The system will automatically copy the area/iteration path of the source project and set it to the copied work items if the identical values exist in the target project.

As seen In this example, as the work item is copied, the work item’s iteration path is copied from the source project and set in the target.

Smart Report

As with previous iterations of the Smart Report Tool, users can upload and apply Word templates to their reports. Update 2 introduces the ability to Inherit Word Styling when Smart Reports are exported to Microsoft Word and a Word template is applied.

From the template, Smart Reports will inherit styling for headings, font size, underlined or bold text, font color, indentation, and alignment.

This option can be found in the “Style Sheet” dropdown menu.

Admin Panel

Improvements have also been made regarding how Modern Requirements data is handled.

Modern Requirements data will now automatically sync to Azure DevOps Server (TFS) source control for single-Sign on build deployments.

To use this capability, add a Collection-level user’s credentials to the General tab of the Modern Requirement4DevOps Admin Panel.

If credentials have not been provided, the user will be prompted with a notification message.

Modern Requirements data will sync with both GIT and Team Foundation Version Control.


Modern Requirements recognizes that our client’s projects will scale, and their requirements management software should scale with them.

Modern Requirements4DevOps throughput performance has been greatly optimized. Update 2 introduces the ability to support large sets of data in work item heavy modules. Large data support has been added to Review Management, Baseline, and Smart Report.

Reviews and Smart Reports can now be created with a maximum of 10,000 work items.

Users can now create Baselines that include up to 100,000 work items.  

Additional improvements in throughput to features of Baseline include:

Copy work items

  • 5,000 work items in Azure DevOps Server
  • 2,000 work items in Azure DevOps Service

Difference Reports

  • 10,000 work items in Azure DevOps Server
  • 3,000 work items in Azure DevOps Service

Rollback work items

  • Can perform this operation on 10,000 work items

Completing operations using large sets of data can sometimes be time consuming. Modern Requirements recognizes that your time is valuable and has already implemented features to improve efficiency.

Time consuming operations no longer slow you down. These operations are now completed in the background and provide users the option of being notified by email when completed.

This feature has been integrated into the Review Management module and is available when conducting the Approve/Reject All feature on large sets of work items. The system will automatically identify when the operation will take more than one minute and notify the user.

Smart Report is also supported by this feature. If generating the Smart Report does not instantly occur, a background process will be initiated. Regarding Smart Report, notification email’s will contain links that enable the user to save their output report to Word or PDF.

Bug Fixes

Functionality and user experience are core elements in Modern Requirements design philosophy.

Several bugs were address and fixed with the release of Update 2. To see a full list of bug fixes or want to read the full release notes please click here.

Building Non-Functional Requirements Templates

Building Non-Functional Requirements Templates

Eliciting, authoring, and managing non-functional requirements (NFR’s) can be a daunting and time-consuming task. Most people who read the previous sentence will likely agree 

NFR creation can be a difficult task and creating non-functional requirements that are both quantifiable and measurable is an issue we’ve seen many teams struggle with.  

Building great non-functional requirements is however, worth the effort. 

Customizable Reports in Azure DevOps

Non-functional requirements provide teams with a means to gauge the success of a project, process, or system. They allow your team to capture measurable ways with which you can discuss, analyze, and evaluate the different attributes of your project. 

Because of the value NFR’s provide to a project, we often see teams engaging in long and complicated processes to create NFR’s that are barely meaningful or relevant at project end.  

Today, we’re going to change that. 

In this article we cover both the value of creating NFR’s, as well as show you how you can employ some simple tools and techniques to reduce the time required for quality NFR creation. 

Why Are Non-Functional Requirements Worth Building?

Non-functional requirements provide your team with all of the success measures of a product, project, system, process, or application. When a good non-functional requirement is created, a team will be able to not only identify if a project is successful but will also be able to easily identify how far from success a project might be.  

Great non-functional requirements can be instrumental to a project’s success in many different ways aside from being a success measure. NFR’s can help teams understand the overall goals of a project, help align the project’s outcome with business goals, and much more.  

Suffice it to say that quality NFR’s can contribute greatly to project success, and the way we evaluate that success. But that doesn’t mean they are easy to manage, elicit, or author.  

Let’s take a look at the primary technique teams use today to build better non-functional requirements faster.  

The Primary Technique for Building Better Non-Functional Requirements Faster - Templates

When building non-functional requirements, teams implement templates in order to create these work items more quickly with greater consistency.

By definition, a template is anything that serves as a model which others can copy and reuse.  

Typically, templates are created as a pre-set format for a document, file, or simply the format every NFR can be created using. Once implemented, the format provided by a template does not need to be recreated every time it is needed, and users can simply pull up a template and get started quickly.  

This leads us to the most obvious benefits of using non-functional requirements templates 

Templates save time and increase consistency! 

When teams begin building a repeatable process, they often turn to templatein order to remove the need to constantly recreate document or file formatsInstead, reusing the same pieces of a document, file, or structure as a template allows your team to reduce rework and capitalize on the benefits of greater consistency. 

While time being saved and consistency being increased are great direct benefits that templates provide, there are many not so obvious indirect benefits that templates provide as well 

The Indirect Benefits of Non-Functional Requirements Templates

The largest indirect benefit from using templates is the ability to create a simple to follow, structured approach to building files, documents, and requirements.  

By providing a templated structure, users who interact with a given file or document have an easier time identifying where to input each specific piece information, and what format that piece of information should adhere to.  

This type of direction not only improves the accuracy of the content of being worked on, but also reduces the time required for NFR creation, document reviews, and requirement approvals. This is in part since supplying a template also increases standardization and use familiarity with the asset being created. 

Templates create a two-fold level of simplicity in regard to NFR work items. Building the work item is simplified as data just needs to be input within the correct fields of the template. Additionally,  the template presents information in a more consumable fashion once the work item is built.

 As the process becomes simpler, it also becomes more approachable.  This means templates also make NFR’s and their documentation easier to create for new, or less familiar, Business Analysts. 

This discussion of templates, however, might have already started to give off a sense ambiguity. 

Are we talking about employing templates for documents?  

Are we talking about employing templates for NFR creation? 

Are we talking about employing templates that outline the properties of an NFR? 

Put simply, yes. 

A non-functional requirements template could be used in any of these areas to bolster your non-functional requirements authoring, elicitation, and management. 

An NFR template might be used to organize and manage NFRs, help a team with document creation, or even in the actual construction of NFR’s.  

If you’re looking for a simple method to construct high quality NFR’s, check out our Two Simple Steps to Creating Non-functional Requirements article found here! 

Whichever way your team uses templates to build NFR’s, you can rest assured that building non-functional requirements yields an incredible return and can be done faster and easier than ever before. 

Properly Equipping Your BA’s With Elicitation Templates

Requirements elicitation, or the gathering of requirements, has never been a simple process. It is however, something that many people encounter every day in the work place.  
For example, if someone asks you to build or complete something you might ask some questions. What should this thing do (functional requirement), and how should this thing be in terms of security, usability, or accessibility (non-functional requirement).  

A well-equipped business analysts (BAwill similarly ask questions that are designed to tease out the necessary functional and non-functional requirements of any project, process, or system. BA’s primarily use questions as their medium of engagement with Stakeholders. Through this type of close collaboration with Stakeholders, BAs create a forum that helps Stakeholders express what it is they want from their product.  

During a conversation with a BA, a Stakeholder will express what features they want and what their product should do (functional requirements) as well as how they want the user experience to feel (non-functional requirements).  

BA’s often employ several time-tested elicitation techniques when engaging with Stakeholders. During the elicitation process some of these techniques might include: 

  • questionnaires 
  • mind-map brainstorming  
  • use cases creation 
  • document creation and review
  • and more… 

Each of these techniques have two things in common.  

  1. First, they all are used for the elicitation of requirements.  
  1. Second, each of these techniques can capitalize on the use of templates.

Let’s think about how questionnaires can benefit from becoming, or using, templates. 

We know that to elicit the proper requirements, the proper questions must be asked.  
This is where the knowledge of a veteran BA becomes a greater asset, as they have been through the elicitation process numerous times. They have the benefit of experience and may know better which questions to ask in relation to specific industries, products, or technologies.  

This experience and knowledge can be easily captured with a non-functional requirement questionnaire template. Experienced BAs can compile well-thought-out question lists or question templates that will focus on specific functions (FRs) or system attributes (NFRs), and passively guide the team’s elicitation process even if they are not directly involved 

These questionnaire templates can then provide structure and consistency to the elicitation process, ensure the correct questions are being asked, and also reduce the likelihood of important questions being missed.   

There are plenty of examples where templates can help teams benefit from the knowledge they already have within their team. 

Let’s look at more examples of how templates are being used today in different elicitation and authoring tasks.  

Why Teams Have Historically Used Tables as Requirements Templates

Many teams continue to implement non-functional requirement templates in the form of a table to author and house requirements. 

The use of tables typically stems from the needs of users to organize and maintain their requirements in one place.  Before the use of explicit Requirements Management tools, table were used to help define naming and numbering conventionsto help track and trace requirements, as well as help by providing fields for any number of properties. 

Tables have historically worked well as templates as they are simple to organize and make it easy to manage the content within the tableTables have traditionally held the added benefit of providing an approach to export the information from table to other areas such as document creation.  

What is that export approach? Copy and paste.  

For teams that use tables as templates, the requirements typically get copy and pasted from table and are then inserted into document. Typically, the requirement is copy and pasted field by individual field into a template designed specifically for the document (another example of templating!) 

But while tables used to be a robust solution for managing requirements that contain a variety of fields, they have some significant downfalls in today’s world of explicit RM tools. 

Tables are often disconnected compilations of important information and can often be siloed off from other tools and processes. Often this results in tables becoming an extra step in your RM process, and extra asset that someone has to take ownership of to manage, update, and maintain.  

But this doesn’t have to be the case.  

With Microsoft’s Excel Team tab extension, teams can easily connect the tables they have used in the past with their Azure DevOps project. They can easily map every requirement field, property, and identifier to the Azure DevOps work item that gets created in their project. 

But how does Azure DevOps help with NFR’s? 

How Does Azure DevOps Handle Non-Functional Requirements?

First, Azure DevOps is flexible.  

Microsoft’s ALM platform allows you to easily add any types of work items your team needs to a project.  

Non-functional requirements are just one of the work item types you can add to a project.  

What is a “work item type”?  

Work items are an ADO-based authoring template for the type of requirement they represent.  

Some examples are functional requirements, transitional requirements, user stories, or even non-functional requirements. Whatever taxonomy your project requires, Azure DevOps will support it and each of the work items you create will have their own set of properties, states, and relationships which can be chosen and customized. 

With a non-functional requirement, you can configure any fields or property that your team requireto help with the management of your project. As mentioned previously, mapping the requirements you already have in a table is simple with the Microsoft Teams tab Excel extension [provide link].  

But what can you do with NFR’s once they are in Azure DevOps (ADO), and how does migrating the creation of NFR’s to ADO help your team? 

Let’s look at the tools.  

Modern Requirements4DevOps: Smart Docs – Customizable NFR Document Templates

The creation of documents depends on an organization’s policies, processes, expectations, and requirements of the stakeholders, and can even be built to house your non-functional requirements. 

Documents provide an easy way to create accountability for meeting the agreed upon requirements for a project. They afford a level of security for the stakeholders as documents can act as a checklist for agreed upon requirements, which can easily be cross-referenced to determine if stakeholders are getting what they paid for or if work was not completed. 

Another major benefit of proper documentation is that requirements often evolve throughout a project’s lifecycle. A requirement might become more clearly defined later in its life, or it might simply evolve in a manner that yields different expectation of your product.  

Queue the addition of non-functional requirement documents to your process. 

As requirements evolve, so too will the expectations for your project. This means the success indicators of your project, a.k.a. non-functional requirements, will have to be reviewed and changed.  

Using our Smart Docs module of the Modern Requirements4DevOps suite, a user can easily construct a fully versionable requirements document directly from their Azure DevOps project. This means users can easily make, and track changes to requirements from a user-friendly document interface.  

New requirements can also be easily created in your project from within a document’s interface, or you can choose to insert existing requirements directly into your document. This means you can easily drag/drop your non-functional requirements directly into an easily exportable document without leaving Azure DevOps and without a need for copy/paste.  

Let’s extend the idea of importing your existing NFR’s that live in tables into Azure DevOps, and then cover how you can turn these NFR’s into documents using Modern Requirements.  

First you import into Azure DevOps your non-functional requirements from your table using the Microsoft Team tab extension for Excel. Then you simply query all non-functional requirements and drag/drop them into your document.  

It’s that simple.  

But let’s say you now want to add structure to a document so that non-functional requirements can only be added in specific areas of the document.  

We support that too! 

There is a template designer built directly within the Smart Docs module, that helps you dictate what work item types are allowed where in your documentsThis means anyone building a document, NFR-based or otherwise, can easily adhere to the structure your template provides and create consistent documentation. 

Modern Requirements4DevOps: Smart Docs – Reusable NFR Document Templates

Reusable document templates are an asset to any team.  In fact, you likely already use these today.  

A reusable document template provides your team with an already populated document that lays out what a document should look like. This type of template helps authors easily figure out where specific information should go, and what contextual elements should make up the document created.  

Think about that Word document you already have on your Desktop. It likely already has a placeholder for things like Introductions, Scope, Goals, as well as where you should put specific requirements. This is a reusable document template.  

The main reason document templates are used is to increase efficiency and cut down on rework within the document manufacturing process.  

Luckily for teams who currently use multiple applications for their RM and documenting processes, there is a solution that can be used for both. Modern Requirements with Azure DevOps.  

The reusable document templates you create with Modern Requirements + Azure DevOps, can be configured to hold any field or property you need to show within your document. You can save any document as a reusable document template, which can automatically populate fields such as Introduction, Goals, NFR Requirements, and more. 

You can build documents in just a few clicks that can help your team get started quickly when building any sort of documentation! This means your team can benefit not only from your documents and requirements living in the same space, but also increase efficiency, create structure, increase accuracy, and create consistency within your document creation process.   

Modern Requirements4DevOps: FAQ Module – Customizable and Reusable Questionnaire Templates

Non-functional requirements are much more abstract than their functional counterparts.  

This makes them harder to draw out as you’re not simply pointing at the system and telling it what to do, instead you are asking questions about how the system should be and using NFR’s to represent that. 

As discussed earlier in this article building strong NFRs are based on asking the right questions.  

So, what if you are new to requirements management or have little experience? Where do you start? MR4DevOps addresses this situation with our comprehensive FAQ module.  

The FAQ module is a series of focused question templates directed at specific system attributes which are categorized by the three primary aspects of the product; operational, revisional, and transitional.  

Additionally, the FAQ module contains question templates for the elicitation of NFR for compliance and risk based medical device development. As users answer the questions from thtemplate, they automatically create a non-functional requirement directly into the Backlog. 

The questionnaire templates included in the FAQ module are beneficial to BAs with all levels of experience. Veteran BAs can modify existing lists by adding their own questions or create their own question list from scratchBy doing so, BA’s are able to capture their experience and knowledge of the elicitation process and pass it along to other members of the team.  

Modern Requirements4DevOps: Smart Report – Configurable Report Templates

MR4DevOps provides a great solution to one of ADO’s major oversights; the lack of an integrated reporting tool.  

When using tools like FAQ, or Smart Docs, to author and manage your non-functional requirements, Smart Report will be the tool that you use to output your requirements. Smart Report allows you to output requirements as PDF, HTML, or Microsoft Word where you can apply your own predesigned header/footer and even Table of Contents or title page as well.  

Looking to make a report for your project’s NFRs?  

The Smart Report tool is equipped with an advanced report template designer. The template designer allows you to build and save custom report templates based on work item type. This enables you to build a unique NFR template that shows whichever properties and fields of an NFR that you wish to include in the report; this information is pulled directly from the work item! 

This template can be applied to any group of selected or queried NFRs and used whenever you are required by your reporting process. The benefit of the reporting tool is it empowers you with the ability to create instant, structured, and consistent requirements reports. 

Interested in Seeing for Yourself?

Modern Requirements4DevOps offers several solutions to assist with the elicitation, authoring, and management of non-functional requirements. 

Would you like to have a closer look into designing templates with Modern Requirements or interested in finding out what other tools can improve your process? Book a product demonstration today!

Experience for yourself how our Modern Requirements toolbox can empower Microsoft’s industry leading Azure DevOps into a single application requirements management solution.

Head over to to learn more about our company and products.

Request a Demo!

  • Schedule a demo with one of our trained product experts.
  • Receive a personalized demo that mimics your team's process
  • Engage our experts on topics such as workflow or best practices.

Reduce UAT Efforts

50% Reduction in UAT efforts

Proven Time Saving

80% time saving on creating Trace Analysis

Streamline Approvals

Significant reduction in approval delays

Increase Performance

50% requirements productivity improvement

Reduce Rework

10-fold reduction in development rework

Simplify Compliance

40% reduction in compliance reporting efforts

Creating Non-Functional Requirements Documents

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. 

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.

What are non functional requirements: How do I build them?

What are non functional requirements:

How do I build them?

Creating consistent and worthwhile non-functional requirements can be a difficult process. In this article we cover how a simple 2-step template help your team build the requirements that will help you determine project success.

Client approval of Requirements in Azure DevOps

Building non-functional requirements tends to be a major point of contempt for many different teams from many different backgrounds and methodologies.

When building non-functional requirements, one of the major difficulties is identifying what a specific non-functional requirement (NFR) is being built for, and then how to easily articulate this.

In our in-depth what are non-functional requirements article, we cover in more detail what non-functional requirements are, and how building great NFR’s can help your team, stakeholders included, easily gauge the success of a project, process, or system from a particular viewpoint.

But even with that knowledge, defining these requirements can still be difficult task to complete.

For that reason, we’ve created this article to help you understand the more granular details of NFR creation and to give you both a template and examples that will help your team write NFR’s easily in only two simple steps.

Defining Project Attributes Using Non-Functional Requirements

To properly discuss examples of non-functional requirements (NFRs), we first need to understand the scope of this type of requirement.

Unlike their functional counterparts, non-functional requirements cover an incredibly broad scope. While a functional requirement specifies what a system should do exactly in a given scenario, the non-functional requirement instead specifies the overall qualities a project, system, or process should exhibit.

While these non-functional requirements might not “do anything specifically”, they do however outline concretely the attributes a system, process, or project must have on completion. Non-functional requirements will then be used to measure the overall success of a given project, process, or system, and provide measurable insights into how close to completion our project might be.

As time goes on, teams, companies, and stakeholders will notice that their list of non-functional requirements will continue to grow. This is expected, as NFR’s will need to be created, changed and adapted as the needs of an organization change.

What can incite changes or additions to our list of NFR’s?

The need to add new NFR’s, or to change existing NFR’s, can stem from incidents such as: organizational changes, changes in implementation, or even changes in business needs.

Regardless of how small or extensive these changes may be, a team can easily identify how implementing a change might affect their success measures by re-evaluating their NFR’s. Teams may notice that a small implementation change, could lead to a completely new NFR that will help them identify a project’s success.

As teams continue to expand their list of non-functional requirements, you might be wondering how do they keep this expanding NFR list organized?

Teams keep their NFR’s organized by using categories with which they can evaluate overall success. A typical grouping of non-functional requirements would be Operational, Revisional, or Transitional. This means that teams will be able to easily identify the successes of a project from any of these perspectives.

You might have a specific non-functional requirement in mind right now and might be trying to identify whether it fits into the Operational, Revisional, or Transitional category.

Below we provide a breakdown of these categories into their relevant aspects.
This is the first step in building a non-functional requirement.

STEP 1 - Identify the Project Attribute for which you want to build a success indicator (non-functional requirement) for.

When building non-functional requirements, the first thing a team must consider is whether they are tackling the NFR’s that relevant to the project. This makes the first step of the process simple.

Identify the project attribute for which you want to build success indicators.
Since attributes fall into categories, here is a helpful list that will breakdown some of the Operational, Revisional, and Transitional aspects of a project.

Operational attributes:

  • Security
  • Accessibility
  • Efficiency
  • Reliability
  • Survivability
  • Usability
  • Availability
  • Confidentiality
  • Integrity
  • Safety


Revisional attributes:
  • Flexibility
  • Maintainability
  • Modifiability
  • Scalability
  • Verifiability
Transitional attributes:
  • Installability
  • Interoperability
  • Portability
  • Reusability

Typically, NFRs fall into either the operational, revisional, or transitional attribute categories and are developed and refined by business analysts, developers, and project stakeholders.

NFRs can be product oriented, addressing specific attributes such as performance (aka how quickly and how much of something a system can complete) or the project’s costs.
Some NFRs are created to address criteria such as product longevity and growth, which are based on attributes such as the modifiability of a product.
Other non-functional requirements could be process facing attributes that define aspects of a product such as its reusability.

Each of these non-functional requirements will fall into their own category; the examples above would be Operational, Revisional, and Transitional respectively.

After we have decided which attribute from these categories we are building success indicators for, we then move into writing our actual NFR’s.

STEP 2 - Construct your Non-functional Requirement.

NFRs may be broad and confusing to grasp for some, however they are just as critical to a project’s success as functional requirements.

While the functional requirement defines what a system should do, a non-functional requirement will define how we measure the success of any given piece of a system.

Therefore, the way we structure a non-functional requirement should indicate a few important pieces.

Non-functional requirement template

A – What is it are you measuring; is this an application, system, project, process?

B – What attribute are you measuring; is this scalability, maintainability, security…?

C – What is the goal, and what are the measures and metrics you are using to determine the goals success?

“The [insert answer to A] should be [insert answer to B] so that/to [insert answer to C]

 For example:

Scalability Non-functional Requirements
“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

In our what are non-functional requirements article, we cover the importance of a non-functional requirement having both a measure and a metric when possible.

Let’s consider building a non-functional requirement using the attribute reliability.

First, we know that reliability is an operational attribute.
Operational attributes of a project are concerned directly with the operational functions of the project from both the system and the user’s perspective. Reliability as an attribute refers to a systems ability to consistently perform to its specification within its intended environment.

As we are trying to establish an NFR, or success indicator, for our system, understanding that this is an operational attribute helps us understand how we can make our NFR measurable to make it achievable.

This requires the application of both a measure and a metric where possible. Some common examples of a metric that would apply to reliability is mean time to failure, probability of failure, or a level of uptime per degree of time.

If we wanted to create a Reliability non-functional requirement using our NFR template, we can ask the following questions:

A – What is it are you measuring? We are measuring a system.

B – What attribute are you measuring? We are measuring reliability.

C – What is the goal, and what are the measures and metrics you are using to determine the goals success?  We want 100% uptime in the first year. Our measure is 100% uptime, our metric is uptime/first year.

 “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.”

You can see that we have added more information about why this NFR has these particular criteria. Although this is an optional part of building non-functional requirements, it can be helpful to link an NFR to an initiative in order give it more context.

How Non-Functional Requirements help with Standardization

There are many instances where the creation of NFRs is required by regulation.

The best example of this is the highly regulated medical devices industry.

Specific requirements have been well defined by The International Organization for Standardization (ISO), and these well-defined non-functional requirements must be strictly adhered to during the development of medical.

Let’s take a look at how these requirements are categorized, and discuss some tools used to build compliant NFR’s quickly and easily.

ISO 13485 – Medical Devices – Quality Management Systems – are comprised of NFRs based on:

  • Management Controls
  • Product Planning
  • Quality Process Evaluation
  • Resource Control
  • Feedback Control

ISO 14971: 2007 – Medical Devices – Application of Risk Management to Medical Devices – are requirements related to:

  • Management Responsibilities
  • Risk Analysis Process
  • Risk Control
  • Risk Management Process
  • Risk Management Report

Modern Requirements tools for building compliant NFR’s

Due to the broad and complex nature of NFRs even creating examples of non-functional requirements is a difficult task. This can be especially true for novice business analysts (BAs) and even for veteran BAs who are gathering non-functional requirements in an unfamiliar space. The elicitation of the correct NFRs is integral to asking the right questions.

The creation of NFRs can be a difficult task. The scope of NFRs are both broad and complex and as a result even coming up with an example can be a difficult task.

This is an issue that many novice business analysts (BAs) face. NFR creation might also be a concern to veteran BAs who are gathering non-functional requirements in an unfamiliar space.

Modern Requirements4DevOps offers several tools that assist users with the elicitation, authoring, and management of non-functional requirements. 

Modern Requirements4DevOps’ FAQ module enables users with the ability to review focused question lists based on specific attributes of each of the four aspects of a project. These question lists provide the user with examples of questions that can be asked to elicit strong non-functional requirements based on each attribute. The tool is preloaded with over 2500 questions found within 29 topics. By answering questions, users are building their non-functional requirements. Questions can be answered using existing backlog work items or new backlog items can be created right from within the module. Users also have the freedom to make new questions and build their own custom question lists.

Interested in seeing for yourself?

Try Modern Requirements4DevOps today, and build non-functional requirements using pre-built question lists that address topics such as ISO compliance, and more!

Experience for yourself how our Modern Requirements toolbox can empower Microsoft’s industry leading Azure DevOps into a single application requirements management solution.

What are non-functional requirements?

What are Non-Functional Requirements?

As the use of non-functional requirements has evolved, the differences between functional and non-functional requirements have become much less apparent.

In this article we discuss the ways many ways in which having proper, measurable, and well-defined non-functional requirements can lead your projects to success.

What does your team need to know about
Non-Functional Requirements?

There is an argument to be made that non-functional requirements are as important as functional requirements. Perhaps they are even more important. The implementation of well-defined non-functional requirements can be used to gauge the overall success of a project. Unlike functional requirements that direct the system on a functional level, non-functional requirements create the basis for a how a system feels.

This represents itself in what is generalized as “user experience”. Well-defined non-functional requirements are easily measurable and can be tested. This way they can be used to evaluate a project’s success and give teams insight on how close their project comes to success. Additionally, well-defined non-functional requirements provide teams with the ability to test the outcome of a system, project, or process against their success factors.

So, what are non-functional requirements? To answer this question, we need to comprehend what a non-functional requirement is composed of. Developing an understanding of the differences between a functional and non-functional requirement is the best place to start.

Functional Vs Non-Functional

The traditional comparison between functional and non-functional requirements is as follows:

Functional requirements apply to the specific behaviors of a system, whereas non-functional requirements form measurable criteria that can be used to gauge the success of an overall system, solution, or product.

Functional vs Non-Functional Requirements

Functional Requirements – What should it do?

Functional requirements are often simple to define, measure, and test, and they can be most easily described as requirements which instruct a specific system to perform a specific function.

When comparing non-functional and functional requirements, functional requirements are typically less abstract and generate very little confusion. Often if you asked someone to write a requirement, the default requirement they would create would be a functional requirement.

It might be easiest to think of functional requirements as the “WHAT SHOULD IT DO” aspects of your system. For example: As a user, when I launch the application, I should be provided with a user login screen.

Non-Functional Requirements – How should it be?

Non-functional requirements are traditionally the requirements that are more difficult to define, measure, test, and track. In many cases this can lead to teams using only functional requirements or having to constantly evaluate their non-functional requirements for correctness.

Despite this, properly constructed non-functional requirements are instrumental in understanding the successes of a given project, process, or system. This is because the role of any non-functional requirement is to act as the descriptor of success for a project, process, or system.

We can view non-functional requirements then, as the set of requirements that define the “HOW SHOULD IT BE” aspects of your system. 

For example: All help text, in-application and documentation, will be provided in English, French, and Spanish.

When defining purposeful non-functional requirements (NFR’s), teams should begin by defining their non-functional requirements for a wide variety of system attributes. These attributes are categorized within three following aspects of a system:

  1. Operational NFR’s
  2. Revisional NFR’s
  3. Transitional NFR’s

Each aspect of your system will fall into either these operational, revisional, or transitional categories of requirements. Many familiar attributes fall into the operational category, such as security, accessibility, and usability. Many other attributes exist that are focused entirely on the health and longevity of a product or system such as scalability, testability, and maintainability.

By building non-functional requirements categorically, and by ensuring you are covering every aspect of each category, non-functional requirements can be built that provide a goal for the system, process, and/or products that your team is involved with creating.

In a way, both functional and non-functional requirements are goals that dictate what needs to be achieved by the system, process, or product. However, building non-functional requirements specifically that are well-defined, measurable, and testable allows teams to quickly and definitively measure the success of any project.

Quantitative Vs Qualitative

For non-functional requirements to help teams measure the success of a system, a non-functional requirement must first and foremost be measurable.

Because non-functional requirements are built to define attributes or qualities of a system, they are by nature qualitative. This can lead teams to building only qualitative NFR’s without considering the application a quantitative measurement might have.

For instance, let’s take the example of a non-functional requirement that could be made quantitative to reinforce the purpose of NFR’s.

Qualitative NFR – “The system should be scalable to handle enterprise expansion.”

Although this is a valid non-functional requirement it is not an easily measured requirement, nor is it testable. By adding quantitative values to this non-functional requirement, we can make a more definitive measure of success for that requirement.

Quantitative NFR – “The system should be scalable to 10,000 users within the next 2 years.”

By quantifying the non-functional requirement, we make a requirement that is more easily measured and tested which can translate to a better understanding of what the success of a project should look like. As teams draw closer to project end, quantitative non-functional requirements can provide a better picture of how close a project is to being successful.

A simple solution to moving towards proper NFR definition is to replace any subjective measurement (i.e. good or great) and replace these with well-defined quantitative values.

Admittedly, building well defined non-functional requirements can be tricky, and the scope of non-functional requirements in general can be massive.

For instance, a non-functional requirement can be built that says a system should automatically display in the local language of where it is being used. Another valid NFR can also apply to the aesthetic of a product, i.e. the application’s UI color scheme should match our company’s branding.

Finding quantitative values for these types of non-functional requirements can seem like a daunting task, but it is important to note that not all NFR’s require quantitative values.

If we intend to make better non-functional requirements, it is important to understand what the quantitative value will represent and how will that make our requirement more measurable.

Measure Vs Metric

Non-functional requirements must be measurable.

In our previous section we covered how adding a quantitative value can help an NFR become both measurable and testable. When we build NFR’s with quantitative values, we must do so mindfully by providing both a measure and a metric when possible.

So how do measures differ from metrics and how do we apply this?

When we evaluate the success of a non-functional requirement, we do so by taking a measurement. A measurement will produce a numerical observation that includes a value (the degree of something) accompanied by a relationship that describes what that value represents.

When building NFR’s, providing a measure will allow us to see the target value used to determine how close a system comes to fulfilling an NFR.

The relationship that exists between that value and our goal will be our metric.
When building NFR’s, we use metrics to evaluate what a particular value actually means in relation to our goal.

Let’s look at how we can apply this knowledge to improve the NFR’s that we create.

With this simple example we can see how adding quantitative values with both a measure and metric can yield easily testable, and measurable NFR’s which dictates the success of a project.

There are however instances where providing both a metric and a measure might not apply to a non-functional requirement. For instance, let’s revisit the example from our previous section.

“The system should be scalable to 10,000 users within the next 2 years.”

This NFR is better than the qualitative version of the same requirement.
However, there is no applicable metric for this non-functional requirement, nor is there a need for one. The goal of building better NFR’s is to create testable, and measurable criteria for our non-functional requirements that help us determine project success.

The quantitative requirement provided above does not include a metric but is still fully measurable and testable. We can for instance, measure in two years whether a system supports an ecosystem of 10,000 users.

Defining proper non-functional requirements allows us to test and measure the success of any given project, process, or system. By being able to define the success of these, we are more easily able to gauge the quality of the software we produce.

Software Quality

Having definitive non-functional requirements provides teams with the ability to assess the quality of the software they produce.

Software quality assurance has become more important than ever.
With distributed teams, multi-functional teams, and more software applications being depended on than ever before, any contribution to the quality of software being produced is a major one.

So far, we covered that non-functional requirements help to identify the overall goals of a system, process, or product. We also know that well-defined, quantitative NFR’s allow teams to easily assess a project’s degree of success in specific areas.

But what are these areas?

When building non-functional requirements, we do so by identifying the aspect of our system we want to set goals for. An aspect could be durability, reliability, or scalability and we could build specific non-functional requirements that help us ensure the quality of what we create based on that context.

As we build NFR’s for each aspect of our system, we increase our ability identify how well our software performs in that context.

For example:

If we have 50 quantitative non-functional requirements that detail how our system should perform in terms of reliability, if all these NFR’s are met at project completion then we can feel confident that the quality of our software will be high in that aspect (reliability).

As NFR’s are built to address individual aspects they provide a context for us to use when assessing a software’s quality. The aspects that are typically addressed for non-functional requirements can yield many contexts with which to evaluate a project.

It is for this reason that we categorize attributes that are used to derive non-functional requirements (such as scalability, reliability, durability, etc.) into three major categories.

Categorizing Non-Functional Requirements

Non-functional requirements need to be categorized.

By categorizing NFR’s, teams can easily contextualize which aspects of their system are meeting their software quality expectations.

Recall that system aspects are how we group our requirements into non-functional topics such as reliability, durability, and scalability. When we know the aspects that relate to our system, we can more easily define the relevant non-functional requirements for our project. We can then use those NFR’s to assess the success of a project in the context of that aspect.

While aspects of a system such as scalability, durability, and reliability offer non-functional topics in which we group requirements, there are several system aspects that can be grouped together to form a greater context with which we can gauge the success of our project.

There are three categories we use to group the non-functional aspects.

There is no rule that says each category must be considered during the development of a product, system, or process. However, the development of well categorized non-functional requirements will greatly improve the quality of your product and allow teams to easily gauge the project success from any context.

Let’s look at a couple of the common aspects that teams address when categorizing their non-functional requirements.


Scalability is a revisional aspect of a piece of software, a product, or a process.

Scalability refers to the ability of a product to scale (either up or down) to meet the usage demands imposed by its user base. Scalability should be considered during the design phase of any product. If a product or system is well received, it should be ready to scale.

Project planning without proper consideration of scalability could hinder your product from doing well. Therefore, scalability requirements are important to consider during the early stages of your products development.

Scalability requirements are non-functional requirements and should therefore be both measurable and easy to track. Establishing strong scalability requirements can help your team define how to measure the success of your system’s ability to scale.


The system shall be scalable to support 10,000 concurrent users while maintaining the performance requirement of a 0.1 second response time. 

Scalability can relate to concurrent users, throughput, storage, or anything within the architecture of software that surpasses base specifications of the product. This is not a basic requirement of any product. However, it provides flexibility to a product to appropriately react to growth and changing user demands.


Survivability is an operational aspect of a piece of software, a product, or a process.

Survivability refers to the ability of product or system to continue to operate and recover when experiencing a failure. This could be a failure caused by physical damage to a product or a digital attack on a system such as a DoS attack.

Non-functional requirements are an important part of the development of software, but also play a crucial role in gauging the success of hardware components as well. Survivability NFR’s for example, when built properly will directly impact how teams gauge the success of a physical product’s build quality and durability.

Example (software):

The system can prevent users from accessing a function of the system that is experiencing failure while still granting users access to unaffected functions.

Example (hardware):

The product will still operate at 100% of its functional capacity if it is submerged in water up to 30 meters for 1 hour.

Survivability requirements are can in fact be seen frequently in product marketing.

Many non-functional requirements can be spun as major selling features for a product. For example, the water-resistant rating of watches and electronics such as cellphones and cameras.

Some cellphones are marketed as being able to operate when submerged up to 3ft for 30 minutes. From a product development standpoint, this is a survivability based non-functional requirement that has been achieved and is now being used as a primary selling feature of a product!

Non-Functional Requirements and Azure DevOps

In Azure DevOps teams can leverage the platform’s flexibility to make requirements of any type.

Non-functional requirements are simply a work item type which any team can create in Azure DevOps. Teams can configure non-functional requirements to house any variation of configurable fields, allowing your non-functional requirements to contain any data that would be important to your team.

As non-functional requirements are simply a created work item in Azure DevOps, they are stored and treated no different than any other requirement (epic, feature, user story, ect.).

Azure DevOps also supports the ability to configure your project backlog to easily show non-functional requirements where needed in your project.

But is that enough?

The Role of Modern Requirements4DevOps When Building Non-Functional Requirements

Modern Requirements4DevOps (MR4DevOps) offers several solutions to aid in the non-functional requirements management process. There is a tool for every stage of an NFR’s lifecycle; elicitation, authoring, document creation, and management.


Building strong NFR’s is based on asking the right questions. Due to the abstract nature of NFR’s this might not be a simple task. What if you are new to the requirements gathering process? MR4DevOps addresses this by enabling users to elicit their NFR’s with the FAQ module.

The FAQ module is a series of focused question lists grouped by system attribute and categorized by the three aspects of the product: Operational, Revisional, and Transitional. By answering questions from the list, you are authoring well-defined NFR’s that are added to your Project Backlog. Users can modify existing lists by adding or removing questions and have the option of creating their own custom FAQ lists. The FAQ module also contains question lists for the elicitation of compliance and risk based NFR’s for medical device development.

Smart Docs

If documentation is part of your non-functional requirements process, MR4DevOps’ Smart Docs provides you with a single application solution to your requirements documentation needs.

Smart Docs enables users to build non-functional requirements documents directly within Azure DevOps. Insert existing NFR’s directly from your Backlog or author new NFR’s on-the-fly while you build your Smart Doc. Smart Docs can be built with unrestricted style using the Smart Editor’s rich text editing functions. If your documentation process demands structure and consistency, reusable templates can be tailored to your specifications using the template designer. Additionally, a full version management feature is integrated directly into Smart Docs allowing users to quickly produce and output change documents.


Storing your well-defined NFR’s within a repository for later reuse is a best practice in requirements management. However, retrieving stored requirements and implementing them within a new project is widely considered to be a bulky process. MR4DevOps solves this problem with its highly efficient Reuse tool.

This tool allows users to copy existing work items from a project and insert them into new or existing projects within your collection or even across servers! You will never have to rebuild your Well-defined NFR’s again.

Manage and store your NFR’s directly within Azure DevOps. The Reuse Work Item tool gives users freedom from managing external repositories, using outside applications, and the tedious copy and paste process.

Trace Analysis

In terms of project management, accurate traceability of your non-functional requirements is one of the biggest challenge’s encountered by teams. Manually creating traceability matrices is a tedious, time-consuming, and error prone process. Projects typically evolve at a rate that renders these matrices constantly outdated. MR4DevOps’ Trace Analysis tool empowers users with the ability to create traceability matrices that show project coverage within seconds.

The Trace Analysis tool allows you to display and manage end-to-end traceability of your NFR’s. Trace any relationship that exists between your project’s NFR’s and any other requirement. Relationships between NFR’s and other project requirements can also be created using the Trace Analysis tool.

The MR4DevOps provides an effective solution to one of the bulkiest processes in requirements management. Reclaim time lost to traceability. With MR4DevOps traceability matrices can be built within seconds and are never out of date.


There is truth in the argument that non-functional requirements are as important as functional requirements; perhaps even more important. Non-functional requirements have far greater depth and implications on your project than their functional counterparts. Non-functional requirements truly drive your product or system’s user experience and gauge the success of any project.

Hopefully this article helped you answer the question of what non-functional requirements are and presented some substantive evidence for the importance of non-functional requirements to your project.

MR4DevOps can help you elevate your NFR management capabilities with a set of tools that offer you support at every stage of your project.

Request a Demo!

  • Schedule a demo with one of our trained product experts.
  • Receive a personalized demo that mimics your team's process
  • Engage our experts on topics such as workflow or best practices.

Reduce UAT Efforts

50% Reduction in UAT efforts

Proven Time Saving

80% time saving on creating Trace Analysis

Streamline Approvals

Significant reduction in approval delays

Increase Performance

50% requirements productivity improvement

Reduce Rework

10-fold reduction in development rework

Simplify Compliance

40% reduction in compliance reporting efforts