Passer au contenu

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.

Avec la fonction Surveillance des courriels, votre équipe peut maintenant transformer cette communication externe en un élément de travail directement.

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.

Cas d’utilisation du service de surveillance de courriels

Le cas d’utilisation le plus courant de la fonction Email Monitor est le suivant :

J’ai une grande organisation et j’aimerais que tous les membres de mon organisation ajoutent tout bogue qu’ils trouvent dans mon logiciel à mon projet Azure DevOps.

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.

Cette fonctionnalité unique permet aux gens de contribuer au succès de votre projet sans avoir à accéder pleinement à votre projet Azure DevOps. Des parties externes peuvent maintenant participer à la discussion sur un Élément de Travail, et ne vous obligent plus à donner accès à votre projet.

 

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.

En vous permettant de consolider l’information dans un seul champ, vous rendez un élément de travail plus accessible aux utilisateurs moins impliqués. La capacité Custom ID suit les directives suivantes :

  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. Vous pouvez aussi ajouter un préfixe de projet optionnel pour n’importe quel ID personnalisé. Par exemple, un nom de projet comme « Projet X » pourrait avoir le préfixe PX.
  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

Temps de lecture : 5 minutes

Demandez une démonstration!

Réduire les efforts de l’UAT

Réduction de 50% des efforts de l’UAT

Économie de temps éprouvée

80% de gain de temps sur la création d’une analyse de traces

Approbations simplifiées

Réduction significative des délais d’approbation

Augmenter la performance

50% des besoins d’amélioration de la productivité

Réduction de la refonte

Réduction de 10 fois dans la refonte du développement

Simplifier la conformité

Réduction de 40% des efforts de rapport sur la conformité