Skip to content

Review and Baseline

Common Questions and Tutorials

Review & Baseline

Intro to Reviews and Baselines

What are Reviews & Baselines and how should we use them?

As the world moves towards more Agile-based methodologies, requirements are changing faster than ever. Handling changes in requirements is often a disorganized, and disconnected process.  

This is why we have created an online Review module to collaboratively facilitate changes to your requirements, and easily capture those changes using our integrated Baseline module.


Step 1) Building a Review

Facilitating Requirements Change in Azure DevOps

Getting approval on work items has always been a lengthy process that requires a lot of oversight and constant management. Building a Review with Modern Requirements is simple, and can be done on both Documents and simple lists of work items. 

Watch the video to see how an online review can help your team’s approval process.


Step 2) Understanding a Review Workflow

Facilitating Requirements Change in Azure DevOps

A well-established review workflow is important to moving requirements through their life-cycle as your project progresses. In this video we cover some of the ways you can interact with our online reviews and create an intuitive workflow for those you include in your review.


Step 3) Creating a Baseline to Capture Requirements

Managing Requirements Change in Azure DevOps

Baselines allow you to capture requirements as they are at a given time.
It’s that simple. 

In this video we show you how simple it is to capture requirements by building a Baseline from both the Baseline module and the backlog.
Watch the video to get started.

Step 4) Using Baselines Effectively

Managing Requirements Change in Azure DevOps

In this video we discuss the functionality that comes with building Baselines. 
We cover how you can use Baselines to send requirements to another project, how to rollback the requirements in a Baseline, and how to compare one Baseline to another.

By the end of the module you will understand the process of identifying how requirements have changed between two periods of time. 

Step 5) Reusing Requirements by Reference

Managing Requirements Change in Azure DevOps

Reusing requirements by reference is a quick way to introduce existing requirements to your project by simply building links with them. By doing this, you could have direct access to those work items and review all the associated content, links, and attachments without actually copying them within or across projects.


Step 6) Reusing Requirements by Copy

Managing Requirements Change in Azure DevOps

In Azure DevOps, there is very limited functionality for copying requirements, or other work items, from one project to another. But when you add Modern Requirements4DevOps into your Azure DevOps environment, requirements reuse meets its full potential. When discussing the Reusing Requirements by Copy, there are three major approaches to consider. Watch the video to see different approaches to reuse requirements by copy.


Merge Copied Baselines

Managing Requirements Change in Azure DevOps

A Baseline is a snapshot of selected work items at a point in time. So, no matter what changes we have made to the baselined work items, the saved snapshot won’t change. Even if we have merged the baselines, the changes are done against the latest versions of the work items, not to the baselines themselves. Watch the 5-minute video to learn more. 


Common Questions

About Review and Baseline

A Baseline is simply a snapshot of any list of work items.

Why is this useful? 

A Baseline allows you to identify and manage the changes in requirements.
You can use Baselines to roll back a full set of work items if necessary. This allows you to capture all of your Release or Iteration work items and roll them back if the requirements go awry. 

You can also send a Baseline of work items to a new Server, Collection, and Project which means you can now reuse requirements from one project to another. We also support the ability to create repositories or libraries of reusable requirements!

Baselines can also be compared to each other.
This means you can easily capture requirements between two separate releases and compare how the requirements have changed over the course of two releases. 

Baselines are powerful tools, and by keeping them easy to make, your team can have all of these benefits with very little added effort!

There are many great times to create a Baseline. 

From a workflow perspective there are a few great times where creating a Baseline can be very effective. 

The goal of a Baseline is to capture change.
This means that if you are creating a review (facilitating change) you may choose to make a Baseline before you send requirements for approval, and then after to capture how requirements changed during that process.

You can also use the Baseline tool to compare how requirements have changed over larger courses of time. This might be identifying how requirements have changed over the course of an iteration, or how requirements changed between two releases. 

Missed a Baseline?
No worries!

When you create a Baseline you not only choose the work items you would like to capture, but you can also choose on which date from the past you would like to capture them at. 

This means if you forgot to make a Baseline for the starting point of iteration one, you can easily capture those requirements from the day iteration one started easily. 

You absolutely can.

Baselines typically store a group of requirements. This makes a Baseline a perfect way to group the requirements you want to reuse in another project together. We have included the ability to “Copy Baseline” directly into our Baseline module for this very reason. This feature lets you take your Baseline and send it to another project. 

The Reuse tool has several great functions.

Primarily, the Reuse tool allows you to select any group of requirements and reuse them in another project.

This tool supports: 
– pulling in Baselines from another project into your current project
– sending requirements from your current project to another project
– building up repositories and/or libraries of requirements


There is a process you can employ which allows your team to change the source work item, aka the work item you have been pulling into your projects from a repository, and have those changes be reflected everywhere you have pulled that requirement into. 

Azure DevOps at its core works by explicitly linking work items to each other.

This means that if you Reuse a work item, you can tick “Link with Source work item” and you will be able to see an explicit link back to your Source work item. You can see this in the Traceability Matrix, or simply open up the work item to see a link to its Source. 

Reviews can be initiated in many different places throughout the application. 

The main places people tend to build Reviews from are:

  1. Native Azure DevOps – you can create reviews from the backlog, sprints, or query views
  2. Smart Docs module – you can create document reviews from the Smart Docs module
  3. Review Module – you can create a review from scratch directly from the module itself.

There are different reasons you might want to invoke a review from these places and as you use Modern Requirements you will find times where one is more effective than another. 

Reviews are stored within the Review module itself. 

As a review is completed, closed, or cancelled, it will be archived in its appropriate folder, but it never leaves the Review module itself. 

Reviews are free to participate in, even for Stakeholders! 

Anyone with an account that can access your team’s project can participate in a review. This means you can have anyone with an account participate as a Reviewer or Approver provided they have project access.

While participating in a review, comments are the driving force of the review. 

When you set someone as a “Reviewer” in your review, they will only be able to provide comments that direct how that work item should change. 

Everyone in the review will be able to see everyone’s comments. This means a conversation is needed to facilitate the changes to requirements. After enough comments, an “Approver” will mark a requirement as “Approved” or “Rejected”, and they will be able to say why using comments of their own. 

After this, the person who sent the review knows exactly which requirements need to change and how. They can then open up a requirement and make the necessary changes. 

In the case of an Approver needing to change how they have marked a requirement, they can easily mark a rejected work item as approved and vice versa. This action is no different that marking that requirement as such originally. 

Our Review module is CFR 21 Part 11 Compliant. 

We offer the option to require e-signatures for people to be able to approve or reject any given work item.

We even allow your team to create Single-Click Audit Reports that show, with timestamps, all of the actions that have been taken during the Approval process.

Subscribe to our Monthly Newsletter!

Our newsletter gives new insights into long-standing best practices and how they are evolving in today’s BA world. We give insight into the hottest Requirements topics. Never miss an article or a webinar again by subscribing today!
Requirements Management Tools for Services and Technology industries

Subscribe to our Monthly Newsletter!

Wait! Before you go:

Want to see how ModernRequirements4DevOps works?

We’ll give you a quick Demo!