Reusing Requirements – Part One

Reusing Requirements - Part One

Learn how to Reuse Requirements in Azure DevOps

Azure DevOps is an incredible platform that provides a single-source of truth. 
For many teams that statement alone is enough for teams to consider using the world’s leading ALM platform for their requirements management as well. Being able to tie development tasks to requirements, and those to Test Cases is hard to pass up. 

But what if you don’t care about having all of the features of a full ALM platform?
What if you only need a solution for your Requirements Management needs? 

You can use all of the rich features of Modern Requirements4DevOps to turn your Azure DevOps project into a full-featured Requirements Management solution. One of these features is the ability to reuse requirements across different projects, collections, and servers using the Modern Requirements4DevOps Reuse tool.

Looking to reuse requirements? 
You’re in the right place. 

What you’ll learn in this short article:

  1. Benefits of reusing requirements
  2. The three methods of reusing requirements
  3. How reusing requirements can be used effectively

The Benefits of Reusing Requirements

When we talk about the benefits of requirements reuse there is one thing that needs to be addressed first. 
The most common question I get from hardware teams is “How could this possibly benefit teams who aren’t software-related?” 

So before we begin, requirements reuse is not just for software teams.

Requirements reuse is a topic that often catches people’s attention. 
This is because in the world economy we are seeing companies dramatically increasing in specificity. This leads to companies building products within a specific domain, or around a given solution, and really narrowing in on the few things they can be really successful at. 

This means that as you build projects, solutions, or systems, often a company can usually reuse elements of a previous project that could have been similar. This is where requirements reuse fits into the picture. 

Teams who build web applications might build a new project using the same technologies or setup as a project they tackled previously. They may also adopt a similar interface structure, backend architecture, etc.
By enabling a team to reuse those requirements in the next project they are able to reduce the amount of overhead required in getting started in a new project. 

For some people this might already be obvious.
What might not be obvious, however, is that reuse can also be a great way of handling requirements that are scoped above the project level. This would include non-functional requirements, or risks that need to be considered as a company-wide mandate. This would even go so far as to allow your team to reuse requirements whose purpose is strictly regulatory or compliance-centric. This functionality can be extended to software and hardware teams alike, and can even help teams product teams devoted to a physical component or deliverable.

In this article I’ll show you the three ways in which you can reuse requirements from one project to another, and in a later article we will discuss how you can build up requirements repositories can act a master copy of a given set of requirements. 

 

The Three Ways of Reusing Requirements.

When discussing the reusing of requirements there are three major items to consider.

  1. How do I copy requirements to a new project?
  2. How do I clone requirements in the same project?
  3. How do I do both of those operations with a list of requirements? 

In Azure DevOps there is only limited functionality for the first two options. 

But when you add Modern Requirements4DevOps into your Azure DevOps environment, requirements reuse meets its full potential. 

Watch the video to see how.

Author: Dustin Heathers
Time to Read: 10 minutes

Three Basic Ways of Reusing Requirements

In this video we cover the three basic ways of using reusing requirements using the native Azure DevOps modules, and the Modern Requirements4DevOps Reuse tool. 

 

How to Reuse Requirements Effectively.

After watching the above video it is obvious that the Modern Requirements4DevOps Reuse tool is effective for reusing requirements.
It offers full control over the requirements you are choosing to reuse, allows you to apply customization to those requirements, and allows you to link the requirements to the source work item. It also includes the essential benefit of being able to reuse requirements across different servers, collections, and projects. 

This means no matter where you want to send requirements, you can do so using the Modern Requirements4DevOps Reuse tool. 
But there are some ways that you can use the Reuse tool more effectively. 

The first notable mention is by pairing the reuse tool with the Modern Requirements4DevOps Baseline tool. 

What is a Baseline?
Many teams use Baselines of requirements and don’t even realize they do. 

A Baseline is a snapshot of Work Items at a given point in time. 
For many teams they simply use Microsoft Word documents as Baselines as they have at some point created documentation. 

When talking about capturing requirements at a given time, there are many reasons why the Modern Requirements4DevOps feature is better than the traditional Microsoft Word approach. With Modern Requirements4DevOps Baselines, you are able to capture any single, or set of, requirements as they were on any date of your choosing. 

This means if you want to capture your requirements as they are two weeks ago, you can easily create a Baseline for those requirements on that date. This lends itself directly to the benefits of the Reuse tool added by Modern Requirements4DevOps.

 By combining the Reuse tool with our Baseline, you can not only choose the set of requirements you want to reuse but also the version of those requirements as well. This allows you to take the best and most applicable version of your requirements forward to your next project. 

The next notable mention is to us the prefix / postfix / and other operations effectively when reusing requirements.

When reusing requirements the Modern Requirements4DevOps Reuse tool allows you to customize how the requirements being reused will appear in their destination project. 

The screen which allows you to do this can be seen below:

 

Using the above feature will allow you to easily add a prefix or postfix to the requirements once they reach your chosen destination project. 
As seen above, you can also choose to send these requirements to a specific area path (like hardware or software for instance), or even into a given iteration so you can decide when these requirements get handled. 

The most commonly used feature in the field options however, is the ability to add a tag. 
Often when you are sending requirements from one project to another you want to be be able to easily identify and trace those requirements in your destination project. Adding a Tag will allow you to do this. 

For example, if you were sending requirements from Project A to Project B, you could add a tag such as “imported from Project A”.
This would tag the work items you created in Project B to be easily located and dealt with. 

What is the link with Source Work Item Option?

This option allows you to establish a link between the work item you are reusing and the work item you create in your destination project. 

What link does it create? 
It links your new destination work item to your original work item via the “Related” link. 
In the below image you can see a Bug I have sent from one project to another, using both the prefix “TEST – ” and the “Link to source work item” options set. 

Using the “Link to source work item” feature allows you to easily trace requirements back to where they were pulled from. 
While there are many use cases for this feature when moving requirements directly from project to project, this more advanced use cases are for when you are moving requirements from a library or repository into a project instead. 

Want to experience reuse's full potential?

Try Modern Requirements4DevOps for free today. 
We offer you the ability to try our Requirements Management solution in your own Azure DevOps environment, or in an environment we supply that includes sample data. 

Try it today!

Documenting Azure DevOps Test Plans

Documenting Azure DevOps Test Plans

Document your Azure DevOps Test Plans from your project!

Let’s face it, building your documents for your Azure DevOps Test Plans can be a heavy task. 

The same thing is true for requirements that live within your Azure DevOps project, but Azure Test Plans poses a unique challenge. Because Modern Requirements4DevOps adds the “Smart Doc” module to the lineup of Requirements Management features that you can use inside your project, you can create documents out of all your requirements. This, if you’re a BA, is nothing less than a delight. 

But whether you’re a BA building a Test Strategy for your team to outlines your testing approach, or you’re a Test Lead documenting the specific Test Plans that will run and what they cover, the task of connecting your Testing Work Items to your documents can be… interesting. 

That’s why in this article we cover a brief overview of how Azure DevOps Test Plans module works, as well as how you can document your test outcomes easily. As we cover these two topics you will also learn a bit about the architecture of Azure DevOps itself and we’ll dive into how understanding this can make you better at understanding Azure DevOps as a whole.

So stay tuned and read until the end! 

Looking for the quick overview and don’t care about the specifics? Skip down to the video!

Otherwise, this is what you can expect to learn in this article:

  1. What is Azure DevOps Test Plans?
  2. How does Test Plans work?
  3. How do I choose a Test Suite type?
  4. Building my first Test Plan
  5. Running my first Test Plan
  6. Seeing the outcomes of a Test Plan
  7. Documenting my Test Plan
So if you’re sticking with me, let’s get started. 
 

What is Azure DevOps Test Plans?

Azure DevOps (ADO) is a great place for your Quality Assurance team to build out their Test Plans for a given project. The important thing to note here is that by bringing your Testing Team onto the Azure DevOps platform,  you can effectively use your ADO project as one single-source of truth.

You can have your Devs using the Repos and tying development work to requirements, you can have your business analysis teams building requirements and attaching test cases, and you can have your QA team using those Test Cases, and requirements made by the BA team, to run all of your Testing. 

Now Azure DevOps Test Plans can be used for both Automated and Manual testing. 

I, however, do not come from an automated testing background and can therefore only speak to Azure DevOps Test Plans as it pertains to Manual Testing. Therefore, in this article, the Azure DevOps Test Plan hub will be discussed as the place for manual testing.

What I will say, however, is that Test Plans are an incredible place for your team to do their manual testing needs for many reasons. 

The main benefit is that by deploying your manual testing operations from here, you can directly interact with the Test Cases that were already built inside of your Azure DevOps project. This means if you have individuals tasked with building Test Cases who fall into your Business Analysis team, their contributions will be easily pulled into your testing workflow. This capability adds a great benefit for teams who have BAs that are capable of building Test Cases for the QA team – if you’re a BA who does this, you will see how it works later in the article. 

Test Plans also offer some incredibly helpful manual testing features that will help your testers provide meaningful input on the outcome / results of their tests. This output goes far beyond the ability to mark a specific test step as passed or failed, but also provides an interactive window for both marking the outcome of individual test steps, capturing live screenshots and recordings, as well as provide comments that are directly tied to the run of that test case.  

This means when you review any Test Runs which you have completed, you will be able to easily identify what your tester was experiencing when they marked an individual test step as blocked / failed. The level of insight that comes with using Azure Test Plans means that even an external manual testing team can contribute thoughtfully, and allow teams to identify and interpret failed results easily.  

That’s why Azure Test Plans are a great place for your manual testing.

How does Azure DevOps Test Plans work?

There is one obvious reason for Azure DevOps Test Plans to have thousands of Google searches a month. 

That reason, is that having your Testing team working in the same environment as your Business Analysis team and Development team, you create a single-source of truth for everyone working on a project. But many of those searches are about “How does ADO testing work?!”.

It really isn’t complicated to any degree, but in my experience many teams are coming from a proprietary, in-house built application they use for Testing. For this reason, teams often need an intro to how the magical Azure DevOps Test Plans work.

Let’s get into the details. 

Test Plans is a hub that allows you to create, you guessed it, Test Plans. 

I’m not talking about the Documents that you might be thinking of, but we will get into these later. 

Test Plans works by allowing you to create a container (Test Plan) to group your Test Suites. You first create a Test Plan, then break it down into the associated Test Suites. The terminology here can be a bit confusing, as many teams choose to use the word “Test Plan” in ways that sound egregious to other teams… so let’s cover them both. 

What is a Test Plan? 
A Test Plan is a container to group Test Suites in. 

What is a Test Suite?  
A Test Suite is a collection of Test Cases. 

In Azure DevOps, you will first create your Test Plan and then you will create your Test Suites inside of it.
Now, when you create a Test Suite inside your Test Plan there are three options. 

Take a look at the graphic below to explain the differences between each:

Author: Dustin Heathers
Time to Read: 20 minutes

Test Plan 1:

Test plans contain test suites.
Test suites can be of three types. Read each of the following suites to see the three different types.

 

  • Test Suite 1
  • Test Suite 2
  • Test Suite 3

Test Suite 1 – Req-based
Requirements-based test suites are the simplest and most traceable. They pull in all of the Test Cases for a given Requirement. 

 

  • Test Case 1
  • Test Case 2

Test Suite 2 – Query Based
Query-based test suites pull in a group of tests from your project, irrespective of what requirements the test cases are linked to. 

 

  • Test Case 3
  • Test Case 4

Test Suite 3 – Static Based
Static-based test suites are used either as containers to group other test suites, or to group a specific set of test cases. 

 

  • Test Case 5
  • Test Case 6
  • Test Suite 1
  • Test Suite 2

Depending on which Test Suite you have chosen to create, building a Test Suite will allow you to pull in all of the Test Cases that you want to Test. Once you have your Test Suites created, and the Test Cases inside, you will be able to execute the entire Suite and that will become a Test Run. 

But before you get to running your Test Suites (therefore creating a Test Run), you need to really understand what each of these Suites offer. 

How do I choose a Test Suite type?

If you just found yourself asking this question, don’t worry… you aren’t lost. It’s easy at this point, and some options can simply be better than others. 

So which Suite do I choose? It’s a great question and the answer is situation dependent.
Let’s quickly discuss the Use Cases and the benefits of each of these Suite types.

Remember: Test Suites (of any type) can only include Test Cases.

1) Requirements-based Test Suite


A Requirements-based suite is one which pulls in all of the Test Cases for that requirement. 
This means when you go to build a Suite you will not be choosing Test Cases. You will instead simply choose the Requirement.

What happens next is the real magic. 
Any Test Cases that have already been built and connected to that requirement get pulled in and populate your Test Suite. You can then run all of the Tests for that given requirement and see from each Test Run (found under the Test Plans tab on the left side of your screen) and conclude that the requirement has been fully met and has passed or that it needs work due to it failing. 

Why is that magic? 
Remember earlier how I said that Requirements-based Test Suites pull in all of the created Test Cases for a given requirement? That means if your BA was able to add in the relevant Test Cases for a requirement when they created it, or if your developers were able to construct the relevant Test Cases when tying in their development work to a requirement… your QA team doesn’t need to redo this work. This is the benefit of a single-source of truth model wherein your teams can benefit from the work of another team easily. 

What’s more is that if your Test Lead decides while building a Requirement-based Suite that they would like to create more Test Cases for that requirement, then the Test Cases they create will be automatically linked to the requirement itself. That means whether Test Cases are being built from the BA or Dev side, or whether they are being added to a Requirement by a Test Lead, every team can contribute to the same group of Work Items. 

If you use Requirements-based Test Suites, your team can create Traceability Matrices that show you not only how your Test Cases align with your requirements, but can also show you whether a Test Case has passed or failed for any given requirement. 

For this reason, and a few more, I often tell people that Requirements-based testing is the simplest and most traceable.

As for the Use Case for Requirements-based testing, I would suggest using this method of Testing when you have the Test Cases for any given requirement tied directly to that requirement. This will allow you to easily bring in the available Test Cases that have already been contributed. 

 

2) Query-based Test Suite


Next up is Query-based Testing which has a slight difference from the Requirements-based Testing mentioned above. Query-based Test Suites afford teams the ability to create a Test Suite using any criteria available. 

What this means is that when you are creating this type of Test Suite, it asks you how you want to pull in Test Cases, and allows you to construct an ad-hoc query to do so. This means you are not concerned with how Test Cases are connected to specific requirements, and instead allows you to pull in the Test Cases that match a specific criteria. 

It is important to note, that this does not use the queries your Business Analysis team would create in Azure DevOps; however, the interface for constructing this ad-hoc query is nearly identical.

When would you use a Query-based Test Suite? 
In some cases, teams will run tests on all of the Test Cases that are currently in a given iteration, or run tests on everything with a given tag, and these conditions are not necessarily tied directly to a given requirement. 

The idea behind Query-based Test Suites is that you can easily include any Test Cases from your project that you would like to test, irrespective of their affiliations with Requirements. 

 

3) Static Test Suite


In Azure Test Plans you can have nested Test Suites. 
Static Test Suites are used as containers for other Test Suites, or as a place to create Test Cases ad-hoc. 

Most of the time you will be using Static Test Suites as a means of grouping Test Suites together.  

Building your first Test Plan

Building your first Test Plan is simple. 

The Test Plan you create in Azure DevOps Test Plans will allow your team to begin structuring how Tests will be run to ensure that your project fulfills the quality standards. As described above, you will be creating a Test Plan, which will include your individual Test Suites. 

Perhaps you want to build a Test Suite for all of the requirements in a given iteration. 

This will be the example we cover in this article. 

One way of tackling this is to build your Test Plan called “Given Iteration Test Plan”. To do this go to the Test Plan tab on the left of your Azure DevOps interface, and select “+ New Test Plan”.

Next, you want to name this Test Plan “Test Plan for Iteration 1”.
You can then select if you would like this specific Test Plan to be for a given area path or iteration, otherwise you can leave this blank (in these example images I have left those two fields as the default options.)

We now have our Test Plan created and are brought to the Test Plan to create our Test Suites. 
Recall that our purpose here is to assure ourselves that all of the requirements from a given iteration are tested fully. So let’s add in the Test Suites for each of these requirements (these will be Requirements-based Suites).

Here we need to point out two things:
1) The goal is to create a Test Plan that tests all of the requirements for a given iteration. Therefore, we want to pull in the Test Cases that already exist for these requirements, or attach new Test Cases to this requirement if we add to our Test Suite.

2) We don’t want to bring in requirements, we want to bring in the Test cases associated to requirements. This point is just a reminder that even when you build a Requirement-based Suite, you are creating a group of Test Cases not requirements. 

So let’s create Test Suites (groups of Test Cases) for each of the requirements in iteration 1. 

Above you can see the query you would need to build to pull in the Iteration 1 requirements, then you can simply click “Run Query” as shown above. 

Now let’s just stop for one moment.

When we run the query we will see all of our Iteration 1 Work Items, and we will only select a few. 

But the question you should ask yourself before moving on is: “how many Test Suites will I create if I select 4 requirements from this list?”

The answer to the above question is 4. 

When you are selecting the requirements, remember that you are simply saying I want to have a Requirements-based Test Suite for each of these requirements’ Test Cases. 

Let’s take a look at the outcome of clicking the blue “Create Suites” button above. 

If you click the image above, you can open it and see that Test Suite for the work items 306 and 307 Test Cases in them. This is shown by the (1) and the (3) respectively. 

Running your first Test Plan

Now that you have a Test Suite for all of the necessary requirements, you can either begin assigned Testers, or add in Test Cases to fill out the Test Suites for those requirements. 

If you read the article above, this is a great time to reiterate the benefits of Requirements-based Test Suites. 
Requirements-based Test Suites use the existing Test Cases that might have been built for a given requirement, and connect any new Test Cases created in the Test Suite to your requirement. 

This means more traceability and a more connected workflow between your teams.

Now how do you run your Test Plans? 

That’s easy. 

You do a Test Run. 

I know that for some people another “Test something” added to their vocabulary might feel like overkill.
But it’s this simple. Test Plans have Test Suites which are a group of Test Cases. 
When a manual tester chooses to run those Test Suites to see if it passes or fails, that action of “running the Test Case(s)” will create a Test Run. A Test Run is the outcome of running one or multiple Test Cases. 

Let’s do a Test Run of one of our Test Suites. 

For our Test Run, we will be running all three Test Cases in this suite.
We will do our Test Run for the web application we are currently building. 

I am launching this from the Chrome Browser, and I would suggest you to do the same. 
If you do not have the extension enabled and connected to your project, I would encourage you to install the chrome extension here

Once you select “Run for web application” a new window will be launched for your Test Run (see below). 

This window can be dragged beside the window containing the web application you are currently testing. 
You can then see the individual Test Steps that must be run and pass or fail each as you go through your Test Steps. If you fail a given Test Step, you will be able to add your comments as to why a given step failed. 

You can even record the screen, capture screenshots, or do a video showing the failure. 
This information will be attached to the Test Run. Remember that – it will be important to know in the future. 

By allowing your team to provide meaningful contributions, you will be able to easily identify and address the issues with an application. You will be able to see exactly how the functionality is different from the expected results. 

Once a tester has completed a Test Case, regardless of whether it passed or failed, they are then ready to go to the next Test Case in their Test Run. To do this they simply click “next >” shown below. 

Once a tester has completed their Test suite they can simply Save and Close their Test Run and you will be able to see their outcomes in the “Runs” tab of Azure DevOps Test Plans. 

Seeing the outcome of a Test Plan

Let’s say you’ve ran the following Test Plan (Requirements-based Test Suite 307) from our example above with the following results:

You can choose to use this same screen to identify what passed and what failed, but if you want to see the contributions of your testers you will be using the Runs view on found under Test Plans (see left hand side of above picture).

Here you can see the Test Run that “Needs Investigation”. 
Click on the Test Run you see in “Recent test runs” and you will see the following the Test Run page with three tabs. Those tabs are “Run summary”, “Test results”, and “Filter” and you can see them below. 

One thing to note about Test Runs, is that this is the place wherein you will find the attached screenshots, recordings, videos and/or comments that are added by your testers. As you will notice above, those items though are not found in the “Run summary” tab. 

To see the contributions of your testers, you will need to navigate to the “Test results” tab shown below.

From here you will select your failed Test Case, and you will be given all of the information that was collected by a given tester for that Test Case during their Test Run. You can see that information below:

That’s it. 

That’s how you would perform your basic manual testing in Azure DevOps Test Plans and see the contributions of your testers within your Azure DevOps project. 

Now if you want to use the feedback that has been given by your testers, you can create bugs by going to the previous screen showing a failed Test Case and “Create a Bug”. Doing so will allow you to build a bug that is has a relationship called “Test Result” (shown below) that links directly to the Test Run failed Test Case. 

Documenting your Test Plan

We’ve laid the foundation for manual testing above: You build your Test Plan, bring in your Test Suites, then run your Test Suites and view the results in the Runs tab of Azure DevOps Test Plans. 

This will give you all of the necessary control over doing manual testing and enacting bugs and changes through the results of your Test Cases. But what if you need to document all of this? 

The reason we cover an example of building a Test Plan, Test Suites, doing a Test Run, and showing the results is because there’s more to the picture here when it comes to documenting. 

Azure DevOps doesn’t have a great reputation when it comes to taking the work items you create within your project and allowing you to turn those into documents. That’s why in the rest of this article we are going to cover moving all of this content you’ve seen into a document format using our Smart Docs module. 

The first thing to point out is that much of the deeper-dive information regarding a given failure of an individual Test Suite, or the Test Plan as a whole is found in the Azure DevOps project itself. But, Azure DevOps will help you create a document for your Test Plan that will include all of the links to the necessary places (like the Test Run showing the details of a failure) inside your project. 

Below is how you export a given Test Suite’s results in document format:

When you export this document you can choose “Print” to create a PDF that looks similar to the screenshot below:

Note all of the different links you can see in the above screenshot. 
What’s important about these links is that they will help you step through to the full details of a given outcome. 

For example, you can see where Test case 1578 (found near the bottom of the screenshot above) has the Latest Test Outcome as a link titled “Failed”. This link will take you the Test Runs page where that Test Case failed, and you can see the contributions of your testers there.

But maybe this document provided by Azure DevOps is not enough. 

Maybe you would like to create the common version of a Test Plan document that contains all of the context surrounding a given Test Plan. 

This can be done using Modern Requirements4DevOps. 

If you need to build a document that outlines the Scope, Risks, Purpose, Strategy, and more… you might think to use Microsoft Word. But the Modern Requirements4DevOps Smart Docs feature will allow you to build up all of the context surrounding an individual Test Plan, while also allowing you to tie in your Test Results too. 

The below video will show you how.

Building Test Documents from Azure DevOps

In this video we cover how you can build the documentation surrounding your Test Plans from within your Azure DevOps project using Modern Requirements4DevOps Smart Docs module. 

 

Importing Requirements to Azure DevOps

Importing Requirements into Azure DevOps

Learn how to easily import requirements (and some assets) into your ADO project

When moving to Azure DevOps, or when working offline away from your existing Azure DevOps project, you need a way to bring your newly created requirements into Azure DevOps.

Many teams face the issue of getting the requirements they have created in Excel, Word, and elsewhere into Azure DevOps. Luckily there are a few simple ways to do this without having to worry about adding a lengthy copy/paste session to your process! 

In this article, we’ll cover a few different ways to import requirements.

One of these options is free, and some are features provided by adding Modern Requirements4DevOps to your Azure DevOps project. 

The topics in this article are as follows:

  1. Importing Requirements from Microsoft Excel
  2. Importing Requirements from Microsoft Word
  3. Importing Diagrams and Mockups into Azure DevOps

Importing Requirements from Microsoft Excel

Whether you have all or some of your existing requirements in Excel, or you are looking to export requirements from an in-house tool to a .csv file, there is a free way to import your requirements to your Azure DevOps project. 

This is a free solution – provided you already have Azure DevOps and Excel.

The first step is to make sure you have the Microsoft Excel add-in called “Team tab.”

You can download this add-in directly from the link below:
https://go.microsoft.com/fwlink/?LinkId=691127

If you clicked the link above, you will have the ability to turn on your Excel team tab. 

When enabled, this extension allows you to connect an Excel sheet directly to a given project in your Azure DevOps Organization. 

When you enable it you will have two primary functions available to you:
1) You will be able to publish requirements to your project from Excel
2) You will be able to pull requirements from your project to Excel

This means you can work on your requirements from either interface and connect the changes to your project. i.e. if you pull requirements into Excel and make changes, you can publish those changes backup to your requirements in your project. 

After you have run the installer you downloaded you are ready to enable the extension.

Enabling the Team tab in Excel:

  1. Open Excel
  2. Create a Blank Sheet 
  3. Click File
  4. Click Options
  5. Click Add-ins
  6. Choose COM Add-ins from the drop down near the bottom of the window
  7. Select “Team Foundation Add-In and select Okay. 
If you have issues with this process, follow this link.
 
If you now see the Team tab in Excel, you’re ready to import requirements! 

Using the Excel Team tab

In this video, we cover how your team can use the Import capabilities provided by the Excel Team tab Add-in.

 

Importing Requirements from Microsoft Word

The second way to import requirements into your project is through Microsoft Word. 

This feature is a “Preview Feature” available with any Enterprise Plus Modern Requirements4DevOps license. This means any user in your organization with an Enterprise Plus license will be be able to access and use the Word Import Feature. 

If you aren’t currently using Modern Requirements4DevOps, you can try this Word Import Feature by trying Modern Requirements4DevOps today!

Give it a try!

So how does Word Import work? 

Warning: As a Preview Feature, you should expect that this might not be prettiest solution, and will typically require some coding knowledge. But not much – and if you can borrow a developer familiar with xml (or any other scripting language) for 20 minutes, you should be just fine.

Word Import works by having a well-formatted Word document which uses different Headings to represent the different Work Items / Requirements and their properties in your document. 

For example, let’s take an example of a BRD you might already have in Word format.

You likely have your Introduction, Overview, Scope, and other context elements using the style of Heading 1

You might then have your Epics, Features and User Stories in this document as well. Your document might look like this:

Heading 1 – Introduction
-> Paragraph – All of the text for the Introduction goes here…

Heading 1 – Overview
-> Paragraph – All of the text for the Overview goes here…

Heading 1 – Scope

-> Paragraph – All of the text for the Scope goes here…

Heading 1 – Requirements
-> Heading 2 – Name of Epic
–> Heading 3 – Name of Feature
—> Heading 4 – Name of User Story
—-> Paragraph – Description of the User Story above

Now, your document might be a little different but that’s okay. The principles you are about to learn are the same. 

Word import requires a document (shown above) and a ruleset (explained below).

Typically an admin will create a ruleset that your team will use for importing documents, and it will only have to be done once. So if you have a document already created and your admin has created a ruleset you’re good to go. 

If your admin needs to create a ruleset, read on. 

Creating a ruleset is incredibly simple and is done by editing an XML file. 
The XML file you create will determine how the Word Import tool parses your document for:
1) Which pieces of the document are work items?
2) Which pieces of the document are properties of a given work item?

If you are working through this in real-time, it might help to download this ruleset file as a starting point and watch the following video:

Using the Sample Ruleset to Start

In this video, we cover how to use the sample ruleset file to import a simple requirements document. Please remember creating a ruleset is typically a one-time process. 

 

Importing Diagrams and Mockups into Azure DevOps

Diagrams, Mockups, and Use Case models can be incredible tools for authoring and eliciting requirements. 

This is why with Modern Requirements4DevOps, your team can easily build all of these visualizations directly from within your project. This allows you to benefit from a single-source of truth model where everything is built into your project. 

But maybe you already have Diagrams and Mockups that you would like to add to your Azure DevOps project and connect to requirements. Is it possible to import these assets?

The answer is yes.

Both our Mockup tool and our Diagram tool will allow you to easily bring existing Mockups or Diagrams into your Azure DevOps project. 

To do this, simply save your asset as a .png or .jpeg file from your chosen Mockup/Diagram tool. 
You can then upload your created asset to either the Modern Requirements4DevOp Simulation tool (mockups) or Diagram tool (diagrams). 

You might be thinking, but if we upload it as .png or .jpeg then how can we edit our Diagrams and Mockups? Well, you can’t. But there’s a reason you should do this even still. 

If you want to connect a single Diagram to 25 requirements without using Modern Requirements, you will have to open all 25 requirements and connect them to each individual requirement. 

When you update your Diagram in the future, you will have to reopen all 25 requirements and change the attachment. 

With Modern Requirements4DevOps however, you are able to create a Diagram work item that you can link all of your necessary requirements directly to using the right panel. This means you will be able to have your Diagram in one place, and when that Diagram needs updating, you can easily add in your updated image, and connect your attachment to that single work item. 

Conclusion

In this article we covered three distinct ways that you can import both requirements and their assets to your Azure DevOps project. 

You can import requirements through Excel or Word, or import your existing Diagrams and Mockups. 

If you are interested in using Modern Requirements4DevOps to support your requirements management process, consider giving our product a try here!

Author: Dustin Heathers
Time to Read: 10 minutes

Introduction to Requirements in Azure DevOps

Azure DevOps Tutorial:
An Introduction to Requirements in Azure DevOps

Everything you need to start requirements work in ADO

If you have recently decided to move your Requirements Management team to Microsoft’s industry-leading Azure DevOps then congratulations! 

You have just made the decision to bring your team into the only single-source of truth models that exists for requirements management. You’ve signed up for a world where Developers, Requirements Management, and Quality Assurance Teams all working and collaborating in the same space!

With over 150 million users, Azure DevOps already supports many teams who are using Microsoft’s industry leading ALM platform to host Code Repositories, or Test Plans. But to move your Requirements Management Team into Azure DevOps alongside these existing teams can take a little planning. 

In this article I will cover how your Requirements Management team can get started working in Azure DevOps faster than ever before. 

These are the topics we will be covering:

  • What is a Process Template? 
  • Setting up a Process Template
  • How much customize-ability is there in Azure DevOps?
  • How do you Manage requirements as your project progresses?
  • How do you add and interact with Requirements you create in Azure DevOps?
  • How do Developers interact with your Requirements?
  • Is it possible to facilitate Reviews in native Azure DevOps?
  • What else can Azure DevOps do? 

As we go through this article, there will plenty of Azure DevOps tutorial videos provided for you to follow along and get started with Azure DevOps quickly! 

So get a coffee, grab a free Azure DevOps account, and take the first step to enjoying projects with a single-source of truth.

What is a Process Template?

The first step to understanding Azure DevOps is to recognize and discuss this thing called the
Process Template

Is a Process Template difficult to grasp?

Not really. 

Think about the names your team currently gives to requirements. 

If you are an Agile shop, your team likely recognizes requirements as Epics > Features > User Stories. 
If your team follows SCRUM, then you may be more familiar with Epics > Features > Product Backlog Items.
For Waterfall & Compliance teams, you are likely used to the lowest level requirements being called Functional & Non-Functional Requirements. 

So what is a Process Template?
It is what Azure DevOps uses to define your requirements at each level.

If your team wants to use an Agile Process template, that’s perfectly doable. Simply add that your Backlog should contain Epics as the top level, Features in the level underneath, and User Stories underneath that. 

But what if you want custom properties?
That’s easily done by customizing your Process Template too!

You can add whatever customizations to your project that you want and it is really not that hard. 
See the video below for setting up a custom Azure DevOps Process Template. 

Setting up a Process Template

Setting up a Process Template allows your team to take full control of the Requirements / Work Items in your project. You can alter the Properties of Work Items and even add Rules and Custom Triggers. 

 

Can I customize my Azure DevOps project?

Absolutely. 

The power of using Azure DevOps for Requirements Management comes from the concept of being flexible to a fault. 
Any and every team that handles requirements can use Azure DevOps to do so. Does it always work straight out of the box? No it doesn’t always, but that doesn’t mean it can’t.

For many Azure teams the basic Process Templates provided by Azure DevOps will allow theme to accomplish their entire Requirements Workflow without needing to make custom changes. 

But every team has their knacks and some may want Azure DevOps to support them – I’m looking at you folks who use Rejection Criteria over Acceptance Criteria. 

Yes, you. 

The good news is that your project can be customized as heavily as needed by editing your Process Template. But, you should always gather your team together before doing so and nail down exactly what your process looks like, and how it should be reflected in Azure DevOps. 

Quick Aside (shameless plug incoming): 
Azure DevOps also has a tonne of addins that can change your interactions with your project heavily. 
One such addin is our Modern Requirements4DevOps solution which turns your Azure DevOps project into a complete Requirements Management Platform. Our tool brings all of the assets you already make outside of Azure DevOps, into your project. I’m talking Documents, Diagrams, Trace Matrices, Reviews and Approvals (with e-signatures), Baselines and more.

Check us out if you’re interested!

 

Adding and Interacting with Requirements in Azure DevOps.

In my time as a Solutions Consultant for Modern Requirements4DevOps, I recognized that many teams wanted me to answer one question before discussing anything else. 

How do I add Requirements, and then how do I interact with them? 

My response – “Great question!”
Microsoft’s Azure DevOps allows you to create and connect with your requirements in a few different ways. 

After you have setup your Azure DevOps Process Template, you are ready to add requirements into a project you create. The typical place to add requirements in native Azure DevOps is the Backlog View. 

The Backlog supports the ability to create requirements at different levels of the hierarchy. 

The Azure DevOps Backlog

Click the image to the right to see how a fully filled out Backlog looks in Azure DevOps. 

(click to expand image)

When you built your Process Template you were able to choose how your Backlog is Structured (seen below).

By creating the structure of your Backlog, you are effectively creating how your requirements will decompose in the Backlog. In the Agile example above, the requirements are structured as:

Epic > Feature > User Story

This means that we can view and visit three tiers of the Backlog. 
We can view our requirements from the highest level by selecting the Epic level in the dropdown on the top right. We could also choose to see our lowest level requirements, which might be helpful when moving requirements into an iteration, by visiting our lowest level requirements (in this case User Story from the same dropdown).

At each level you are able to create a new Work Item by clicking the aptly named “New Work Item” button above the list of requirements. 

If you create your top-level requirements, you are then able to breakdown that requirement into it’s “sub requirements.” You do so by selecting the “+” button beside your newly created requirement.

Adding Requirements (Video)

Click the video to the right to see how you can easily add and interact with requirements that you create directly within the Azure DevOps Backlog. 

 

Now that we can see that creating requirements is simple, I should point out that the operation of adding requirements to Azure DevOps can be performed from the Backlog, Queries, or Sprints tabs of the left. This means that you can compose new requirements and break them down into their sub-requirements quickly and easily. 

How do Developers interact with Requirements in Azure DevOps?

The best part of using Azure DevOps as a Requirements Management Solution is that it provides a single-source of truth for your developers, requirements team, and quality assurance. 

But knowing how your developers can connect with your requirements is the first step. 

In Azure DevOps your developers can build Task Work Items which can be connected directly to their development work. If they are using the “Repos” functionality of Azure DevOps, they can add their Github or TFVC repository to their project to make it easily accessible. They can then tie their pushes, pulls, branches, commits, and more to their Task Work Items (or any other Work Item!).

As teams tie their development work into part of the process, they can make their development more visible and traceable to requirements themselves. 

But. 

Development work is usually initiated by a “thing” that must get done. 
That “thing” is a requirement that developers will interact with from Sprints/Iterations tab of Azure DevOps. 

Developers will visit the current iteration, find out what needs to get done (requirement) and turn it into how it is going to get done (task). In the below video I describe exactly how this process looks.
I have also included a quick video on setting up Dashboards and Sprints in case you are interested! 

Setting up Dashboards & Sprints

Setting up Dashboards and Sprints is a good starting point when handling requirements in Azure DevOps. This allows both Requirements teams and development team the chance to get started. 

 

How Devs Interact with Requirements

This video outlines how your developers can easily interact with project requirements and break them down into the associated tasks.

 

Can I do Reviews/Approvals in native Azure DevOps?

Teams often need a method of reviewing requirements to see what changes need to be made.
Often teams will require some sort of sign-off for the changes that have been made, or they will simply use reviews to facilitate discussion and collaboration.

In Azure DevOps, the method of facilitating changes top requirements includes emailing lists of requirements to the interested parties using the email feature within the Queries tab. While this feature does have some limitations, it does allow your team to exchange requirements and collaborate before making final change. 

Looking for better reviews?
Need compliant e-signatures?
Interested in automation tools?

When teams send requirements to internal team members, or to external Stakeholders, they are able to have documents reviewed and looked at before a change is finalized and made. To see this in action watch the quick video below:

Reviewing Requirements

In this video we cover how your team can send requirements to internal and external members of the team for review.

 

What else does Azure DevOps offer?

Azure DevOps offers plenty of functionality for both Development and Quality Assurance teams. 

When it comes to Azure DevOps however, your team may still feel like more can be done. That’s exactly why we’ve partnered closely with Microsoft and have become their go-to partner for Requirements Management tools. 

Our solution is built to offer teams using Azure DevOps the ability to do everything they need for Requirements Management within their project. We allow you to create a single-source of truth model for your team by helping your team create the assets they already use from within their Azure DevOps project!

Want to learn how your team can create: 

  • Documents, Diagrams and Question Lists from within your project?
  • End-to-end Traceability Matrices in 30 seconds or less?
  • Baselines that help you identify and manage changes to requirements?
  • and more?
Try Modern Requirements4DevOps today and experience the benefits of having one single-source of truth model for all of your teams working within the same space!
 
Author: Dustin Heathers
Time to Read: 15 minutes

The FAQ Module

The FAQ Module

The solution for upfront requirements gathering

In this article we cover the features and benefits of the FAQ module.

This module was designed to help teams who gather requirements at the start of their requirements management process. By creating question lists teams can easily capture and reuse their knowledge of the elicitation process to ask the right questions that yield the best requirements.

What is the FAQ module?

The FAQ module is a repository of question lists that your team can construct, edit, change, template, and use to elicit requirements. By using the FAQ module to build up a knowledge base for your team, you can be confident that any team member can engage with stakeholders in an effective manner.

By building the best set of questions on that domain, your team can ensure that they are always eliciting the best possible set of requirements.

The main benefit of this module is that it allows your team the opportunity to build up a knowledge base that can be used by both experienced BA’s, as well as by those who might need to elicit requirements in an unfamiliar domain. The FAQ module comes already stocked with over 3000 questions that cover many different topics.

These topics include multiple ISO Compliance templates, as well as templates on Non-Functional Requirement topics such Scalability, Reusability, or Operability that can be used for elicitation.

For many teams this module will replace their Excel-based question lists they may have used in the past.

To stay in line with the other modules in the Modern Requirements toolset, the FAQ module takes what used to be a disconnected process and connects it directly with your project. This means your teams can easily add requirements into your project simply by supplying answers to the questions in your FAQ question list.

What Value does the FAQ module offer?

The value of our FAQ module can be described in two simple points.

  • The FAQ module helps create better requirements by guiding the elicitation process, leading to a greater likelihood of project success.
  • The FAQ module reduces the time spent on elicitation throughout your project, allowing your team to get started building sooner.

By using the valuable knowledge of experienced BA’s, you can create domain-specific question templates that help structure the elicitation process. This means you can send any BA of any experience level into a room with a stakeholder and feel confident they will create complete and actionable requirements.

By no longer needing to construct question templates and then copy elicited requirements to your RM tool, your team can move through the elicitation process faster. This means more time spent iterating on more accurate requirements and less time spent copy and pasting user stories that are likely to need more work.

What are the Use Cases for the FAQ module?

When we talk to our community about their use of the FAQ module, they often describe the ways in which this module has streamlined their process and made the elicitation phase of projects easier to navigate.

Even with teams who traditionally don’t use question lists, after joining our community they will tell us how much added value they see from being able to consolidate the knowledge of everyone on their team into one cohesive list.

Here are the Use Cases we have seen for the FAQ module.

USE CASE 1

My team currently gathers requirements up front and moves iteratively through our project thereafter. We currently use Excel during the requirements gathering phase, but it means that we are copying requirements to our tool of choice afterwards.

By being a team who gathers requirements up front, this provides a perfect opportunity to use a question list designed for that domain. But using Excel as a means of facilitating this question list is a recipe for a long copy-paste process later down the road. 

Copy/paste processes are generally error-prone and lengthy. It is often during these already long copy/paste processes that a team member will recognize they have missed a property of a work item that they need stakeholder input on.

In this case, using the FAQ module means you will have the question list in your Azure DevOps project already. When you ask your Stakeholder your question you will be able to answer that question in your FAQ question list and it will automatically create a requirement for you.

You can then open that requirement directly and pursue any follow up questions that you might have while you are still with your Stakeholder. This saves time and makes the elicitation process more thorough, while preventing your team from missing opportunities to get the right information at the right moment.

USE CASE 2

My team works in a compliant/regulated space and we need to ensure we are building the full set of requirements to remain compliant and auditable.

One of the best features of the FAQ module is that you can use many of our pre-built compliance-related templates to elicit requirements. Our pre-built templates have been created in partnership with many of our existing customers, as well as through partnerships with thought-leaders in these spaces.

In this case, teams with access to the FAQ module can speak to domain experts and consultants and build the question list that will help them create all the requirements necessary for compliance and regulation. Once created, these question lists can be reused in several projects and can be deployed again and again.

 

How do I use the FAQ module effectively?

The FAQ module provides incredible benefits for teams inside the elicitation phase of their project. Here are some of the ways you can use the module to facilitate project success.

 

Use the Pre-built Question List Templates

When users need a template on either Non-Functional Requirements, or on ISO topics, they can get started quickly by using one of our built-in templates. These templates already contain many of the most important questions about these topics. Users can start with a pre-built template and remove questions that are not relevant and/or add in new questions that necessary.

Build your own Question List Templates

If one of our pre-built templates does not satisfy your need, teams can easily build question lists from scratch. By starting with a blank template, your team can easily build up a comprehensive set of questions that make eliciting requirements a simple and more efficient process.

Once a question list is built it can be reused across projects to help with your elicitation phase down the road.

Build Question Lists that less experienced members of your team

By building question lists you are effectively providing guidance for any member who might be less familiar with a domain, solution, or system. These lists are then a great tool for guiding newer BA’s, or experienced BA’s from a different domain, during the elicitation phase. Teams understand that the quality of the questions we ask at the start of a project directly reflect in the quality of the requirements we elicit.

By building question lists with our FAQ module, you can ensure that you are getting the best possible requirements the first time.

Author: Dustin Heathers
Time to Read: 5 minutes

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.
USE CASE 1
My team currently copy/pastes requirements from Azure DevOps to Microsoft Word in order to create
documentation.
 
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.
USE CASE 2
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.
USE CASE 3
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.
Author: Dustin Heathers
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 bugs@myorganization.com, any member of my organization can simply send an email to bugs@myorganization.com 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

Author: Dustin Heathers
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. 

General

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

Baseline

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.

Scalability

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 www.modernrequirements.com 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.