MR Services - Email Monitor, 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:
- 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.
- 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.
- 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.
- 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
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
