Digital Project Manager: An Overview of Modern Requirements4DevOps

The Digital Project Manager: An Overview on Modern Requirements4DevOps

Detailed Overview & Explanation Of Requirements Management Features

What is Modern Requirements4DevOps?

What is Modern Requirements4DevOps? Read on to discover how Modern Requirements4DevOps works—what problems it can help you solve and who uses it, along with a tour of its features, pricing, and integrations.

I’ll also explain how Modern Requirements4DevOps compares to similar tools.

Read the full article on Digital Project Manager.

Introduction to Rights Management

Introduction to Rights Management

What is Rights Management?

Rights Management is a new feature in MR2020 Release to control user access. The project administrator can grant or deny a group of users from accessing an MR module and its functionalities. Currently, Rights Management is available for three MR modules: Smart Docs, Baseline, and Reporting.

The Benefits of Using Rights Management

Flexible and customizable permissions allow project teams to maintain the appropriate balance of collaboration and control.

Whenever a permission change takes place, it will immediately impact every user team/group that is assigned the permissions. This ensures that permission settings can easily be updated and maintained as projects progress and teams change roles.

How to Access Rights Management

Rights Management can be accessed from the Modern Requirements4DevOps extension under Project Settings.

Group Features

The available features which you can set permissions for varies from module to module.

The available Group Features are as follows:

  1. Create /Edit Folder
  2. Delete Folder
  3. Create/Update Artifact
  4. Delete Artifact
  5. Create/Update Meta Template
  6. Save As Template
  7. Smart Report Generation
  8. Smart Report Designer

Permissions Selections

There are typically three types of permission access to choose from for each group feature:

“Allow”

“Deny”

“Not Set”

  1. “Allow”: Explicitly grants users the permission to access a group feature in MR module(s).
  2. “Deny”: Explicitly restricts users from accessing a group feature in MR module(s).
  3. “Not Set”: Implicitly denies users the ability to access a group feature in MR module(s).

Inherited Permissions

Teams/Groups can automatically inherit permission settings from parent Teams/Groups. Permissions Settings explicitly changed in the child teams/groups may override permissions inherited from parent Teams/Groups. Keep the following rules in mind:

  1. Inherited “Allow” values can be overridden to “Deny”.
  2. Inherited “Not Set” value can be overridden to “Allow” or “Deny”.
  3. Inherited “Deny” value cannot be overridden to “Allow”.

Permission Conflicts

When same user exists in more than one teams/groups, the following rules apply:

  1. “Deny” has preference over “Allow”.
  2. “Deny” has preference over “Not Set”.
  3. “Allow” has preference over “Not Set”.

Please watch the detailed tutorial video on Rights Management!

If you have any questions or thoughts about Rights Management, please contact your Customer Success Representative of Modern Requirements and we will be happy to work with you to explore this feature.
Time to Read: 10 minutes

Using MatCal to Perform Mathematical and Logical Calculations in Modern Requirements Management

Using MatCal to Perform Mathematical and Logical Calculations in Modern Requirements Management

What is MatCal?

MatCal is a feature in Modern Requirement4DevOps used to perform mathematical and logical expressions on work items.

Why we need MatCal in Requirements Management

To manage the relationships between work item properties in a smarter way! It eliminates the manual efforts of doing the calculation outside the project environment and avoids risks of introducing incorrect calculation results to your projects.

Let’s look at a simple example here to illustrate a relationship between work item properties.

Business Value and Priority are properties of work item Feature.  Normally, high Business Value leads to high Priority.

With the right configuration, MatCal could help you manage the relationship by automatically assigning Priority value based on the Business Value input.

Industry Use Scenarios

Scenario 1: Automotive Safety Integrity Level (ASIL) in ISO 26262

Scenario 2: Risk rating is automatically assigned according to Severity score and Occurrence score

Scenario 3: Priority rating is automatically assigned according to Severity score and Likelihood score

Please watch the video for extra usage scenarios and tutorials on MatCal!

Table of Contents

Start using Modern Requirements today

✅ Define, manage, and trace requirements within Azure DevOps
✅ Collaborate seamlessly across regulated teams
✅ Get started for FREE—no credit card required

Recent Articles

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 here:

(On the aforementioned page, Azure DevOps Office® Integration 2019 is listed under the Other Tools, Frameworks, and Redistributables section. )

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!

Time to Read: 10 minutes

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. See a full list of bug fixes or read release notes here.