2020
Continue readingHow to Use Requirements Traceability Matrix to Improve Project Quality
Understanding the Admin Panel: Licensing and Module Configurations
As an administrator, you can control how users access and interact with their Modern Requirements4DevOps projects by applying admin settings.
Continue reading6 Ways to Reduce the Risk of Missing Non-Functional Requirements
Register to learn more about how to reduce the risk of non-functional requirements.
Continue readingParticipate in Requirements Authoring Using Email Monitor
Participate in Requirements Authoring Using Email Monitor
The Email Monitor feature provides access to creating Work Items in your Azure DevOps project through a medium that that is not native to Azure DevOps. That is, it allows you to communicate with your project via email. Teams often encounter situations where they are emailing about requirements, change request or bugs 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.
For use cases and the configuration process of Email Monitor, please watch the video.
You can access the configuration page of Email Monitor by going to the Collection/Admin settings – Modern Requirement4DevOps Extension – Services – Email Monitor.
By enabling the Email Monitor feature in the Modern Requirements4DevOps extension panel, you can specify a Monitor Email address that can intercept and create any work item that are emailed to it. Since the system will try to capture every email sent to the Monitor Email, it is a good idea to use your Monitor Email solely for the purpose the Email Monitor.
You are also required to provide an Admin Email address just in case when the system could not recognize the emails and a notification email will be sent to the Admin Email.
You can specify what WorkItem Types you want to create in your project from those captured emails.
Titles of the emails sent to the Monitor Email will always be mapped into the titles of Work Items to be created.
Team Project (Default) allows you to choose a default project where you want to add the Work Items to.
Add on Creation and Add on Update help you configure when you want to add the requirement to the project.
For the Description Field:
If the Add on Creation is checked, it means the system will use the initial email to create a new work item and the email body will become the description of the created Work Item.
If Add on Update is checked, it means the existing description of the created Work Item will be overridden by future replies regarding the same Work Item.
For the History Field：
If the Add on Creation is checked, it means the body of the initial email will be mapped to the Discussion section of the created work item.
If Add on Update is checked, then all back and forth replies regarding the same Work Item will be added to the Discussion section.
Sender Name, Sender Email, and Email Body allow you to set what content you want to add in associated Description or the Discussion section.
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 relevant stakeholders can simply send an email to bugs@myorganization.com and I could specify that a Bug Work Item 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.
Some other scenarios you might be interested in
Adding Work Items to projects other than the default project
If sender does not specify a particular project name in the email body, the mapped email will be added to the default project. If senders want to add the requirement to another project under the same collection, they will need to include [ProjectName=GCD] in the email body (GCD is a sample project name).
Multiple Work Item Types
We understand that your project stakeholders might want to add more than one types of Work Items by using Email Monitor. This can be achieved too! You can simply select multiple WorkItem Types. For instance, now I select User Story in addition to Bug. When your team send emails to the monitor email box, they can use [WIT=bug] or [WIT=user story] in the email body to specify which Work Item type the created requirement should be. Without specifying the Work Item type in the email body, the system will try to map the email to the Work Item type which falls into the Work Item category you have selected in the WI Category section.
Adding extra content to an existing Work Item
After the initial email was captured by the system, by default, all future replies can be added as discussions of same Work Item. In addition to that, senders can add [wiid=1997] (1997 is a sample Work Item ID) in the email body to add new content to the targeted existing Work Item.
Of course, you can use more than one of those special commands in an email based on your needs.
Managing Suspicious Requirements with Automatic Flagging
Managing Suspicious Requirements with Automatic Flagging
Dirty Flag / Suspect Link is a component of MR Services (formerly called MR Agent) that is used to identify work items that might be affected by the changing of a linked work item so that relevant stakeholders may review the impacted work items. For example, if a user story changes in the active states, then the related test cases would be marked as suspect.
The Suspect Link feature contributes to your project’s success by making the impact of Work Item changes both query-able and, generally, more noticeable. You can consider this feature as one method of doing an impact assessment on changing work items within your project.
How does Dirty Flag / Suspect Link work?
This feature works by allowing you to monitor Work Items which meet certain preconditions. When these Work Items change, the monitor feature will mark any linked Work Items as suspect.
Let’s consider an example:
User Story 1 has just been moved to the ‘Completed’ state. If the Suspect Link 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, the configured work items directly linked will be flagged by the Dirty/Suspect.
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. You can also personalize the Column Options in the Work Items and Backlogs module to view a group of Work Items in which some may be marked by the Dirty Flag.
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.
Dirty Flag tags could be manually removed when relevant stakeholders have reviewed the impact and made necessary updates. The best practices we recommend here is to add another comment explaining that now the Dirty Flag is removed due to necessary updates have been accomplished or no updates are required.
For more details and the configuration process of Dirty Flag/Suspect Link, please watch the video.
How to Make Your Requirement IDs More Descriptive and Distinctive Using Custom ID
How to Make Your Requirement IDs More Descriptive and Distinctive Using Custom ID
Modern Requirements4DevOps offers the functionality to add Custom ID’s to Work Items. The intent of this feature is to make a Work Item field more readable and recognizable. For example “PX-REQ-00001” for the first requirements work item in Project X.
Our Custom ID feature offers the same benefits alongside the added benefits of using the Custom ID in the Queries module.
Custom ID’s can be setup as a custom property that exists on each of your Work Items. The Custom IDs is not designed replace the work item ID, instead it complements it.
The Custom ID property offers an easy method of identifying several 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 based on different Work Item types. For example, a Requirement Work Item type’s code could be REQ, a User story Work Item type’s code could be US, and a Bug Work Item type’s code could be BG.
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 1 or 10000 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. Scope guarantees the custom ID will be unique within the scope.
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 type code + number.
For more details and the configuration process of Custom ID, please watch the video.
Facilitate the Medical Device Design Controls with Modern Requirements
Achieve quicker compliance, shorter development cycle times, and faster value delivery
Continue readingDigital 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.
Now Released: Modern Requirements4DevOps 2020
Now Released: Modern Requirements4DevOps 2020
Details of Modern Requirements4DevOps 2020's Core Enhancements!
User friendly, short cycle times, ability to author requirements online, compliance reporting, and reduced development rework. These are just a few of the phrases that have been used by our customers to describe the aptitude of several modules within the Modern Requirements4DevOps application. New features and enhancements have been made to the modules with our 2020 release.
Here we will share a few highlights made to a few of our modules within Modern Requirements and some tool enhancements for your convenience. Modules that we will be outlining are:
- Rights Management
- Review Enhancements
- Smart Docs Enhancements
- Smart Reports Enhancements
- Baseline Enhancements
- MatCal (New!)
1. Rights Management: You asked, and we listened. You can now manage User Access. A user (must have collection/project Admin) rights can now manage user access to both modules of Modern Requirements4DevOps, and the features within each module. Setting these permissions is as easy as one-two-three… steps to set permissions:
- Access your project
- Go to Project Settings
- Scroll down to Extension > click on Modern Requirements4DevOps
This is what you will see:
From this screen, you will be able to set the *Group and/or *Team permissions (located on the left panel). There are two ways to set permissions, you can either do it in the “*Common Settings” or within “*Modern Requirements4DevOps Modules” individually (located on the right panel of the permissions tab). Here you can set permissions for the features of each modules.
The permission options available are:
- Create/Edit Folder
- Delete Folder
- Create/Update Artifact
- Delete Artifact
- Create/Update Meta Template
- Save as Template
- Smart Reporting
- Report Designer
Currently, Rights Management is supported for three modules: Smart Docs, Baseline and Reporting.
Rights Management Video
For further details on what’s new in Rights Management and its functionality please refer to the video.
2. Review Enhancements: The Review module allows you to communicate, review, and approve within the project environment and facilitate change when necessary. Enhancements have been made to Review module. Here is a list of a few of the new features:
- Read-only rights to non-participants of review
- Auto Bulk generation of review Audit Reports
- Audit Reports Format- Word/PDF
Read-only rights to non-participants of review: With this enhancement you now have the ability to configure rights for non-participants where they can view review details in read-only mode.
Non-participants users: Users that are neither the approver nor the reviewer.
Auto Bulk generation of review Audit Reports: This enhancement will allow you to generate Audit Reports of all reviews in a project at once in bulk or project wise from admin panel.
You can select project(s) and provide details here to generate the audit reports of their existing reviews automatically
Audit Reports Format – Word/PDF: System now gives you the ability to select format in which you want to generate the audit reports in. You can select either word or PDF version.
The purpose of Approval Audit report is to provide details of all the work items in a Review. It provides complete status regarding who has approved or rejected the review work items along with the comments and decisions
How to configure settings:
- Go to Admin/Collections Setting
- Scroll down to Extensions
- Choose Modern Requirements4DevOps2020
- Go to Review tab (look for the option you want to make the changes to)
Review Management Video
For further details on what’s new in Review Management and its functionality please refer to the video.
3. Smart Docs Enhancements: Smart Docs is a tool that bridges the gap between document and information management by authoring requirements in a document view online. New features have been added to Smart Docs, some of the highlights are as follows:
- Full Screen Support
- Right Panel UI Update
- Inherit Parent Properties Update
Full Screen Support: In order to have a better user experience and larger display you can now view Smart Docs in full screen mode. Which means a better view when building your online requirement documents.
Right Panel UI Update:
- For your convenience a cross icon has been added to the right panel UI. Which means you can now close the right panel directly through the panel itself.
- If this was not enough, we have also added expand/collapse capability to the “*find” query area for a better user experience.
- Also, in order to provide more space to show more work items, “Add child/sibling” and “Select all/ unselect all” buttons have been removed. Remember, you can still drag and drop your work items into the document section.
Inherit Parent Properties Update: This is an update with which by default, the check box to inherit parent work item properties in child work item will be shown ‘un-checked’.
Note: If no properties are selected from the drop-down option, then no properties will be inherited in the child work item.
Smart Docs Video
For further details on what’s new in Smart Docs and its functionality please refer to the video.
4. Smart Reports Enhancements: Smart Report enables users to format their reports according to the work items structure. It is accessible from many of the ADO and Modern Requirements4DevOps modules. Here is a list of some of the tool enhancements made to Smart Report module:
- Upload macro-enabled Word template
- Retain selection of last uploaded Word template
- Retain selection of last Smart Part
Upload macro-enabled Word template: Smart Report now allows you to upload and execute Macro-Enabled Word document (.docm) as well as Macro-Enabled Word Template (.dotm) files in Smart Report through “Upload word template”. It will make your user-friendly option of uploading word templates even more of a breeze.
Retain selection of last uploaded Word template: Guess what… Smart rReport has now become smarter, it will now retain the last selection that you made while uploading your word template.
Retain selection of last Smart Part: Well we did not stop at remembering the last selection for the word template… Enhancements have been made where the system will now also retain the selection of your last Smart Report Part as well. Well, it is winning all the way for report creators.
Smart Report Video
For further details on what’s new in Smart Reports and its functionality please refer to the video.
5. Baseline Enhancements: Baseline allows you to take a snapshot of your requirements at a point in time to allow better control and track changes. Here is how it will make your work experience even better:
- Retain work item selection on tab switching
- Comparison ID on Baseline comparison
Retain work item selection on tab switching: System will now remember the last work item selection when navigating between different tabs within baseline. What does that mean? Well, while working with a baseline (specially with a large one), navigate to Compare or Detail tab and back to View tab if you have forgotten which work item you were working with… Worry no more, because the system will remember it for you.
Comparison ID on Baseline comparison: Enhancements have been made so you can now view work item revisions only where work items exist within both baselines being compared. For example: if a work item doesn’t exist in one of the baselines, no revision ID will be displayed, instead “-” will be displayed in Rev.ID or Comp.Rev.ID column. This rule will also be applied in the difference report.
Baseline Video
For further details on what’s new in Baseline and its functionality please refer to the video.
6. MatCal (New): A new feature has been introduced to Modern Requirements to perform mathematical and logical expressions. Sounds exciting? Well, we are excited about it. Here’s why:
- It will allow you to have work items field(s) automatically calculated based on input of other field(s) of the same work item(s)
- It can be applied to any work item fields, including numerical, Boolean, and textual types of work item fields
What you need to do: Provide your formulas to a Modern Requirements Customer Success team member and we will be happy to configure it on your behalf.
MatCal Video
For further details on MatCal and its functionality please refer to the video.
For a detailed list of all enhancements and features please made in 2020 release, please refer to Modern Requirements4DevOps 2020 Release Notes.
We are excited to announce that Modern Requirements4DevOps 2020 is now available for download!
- Already a Modern Requirements4DevOps user? Click here to download now!
- Not currently using Modern Requirements? Try for free!
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:
- Create /Edit Folder
- Delete Folder
- Create/Update Artifact
- Delete Artifact
- Create/Update Meta Template
- Save As Template
- Smart Report Generation
- Smart Report Designer
Permissions Selections
There are typically three types of permission access to choose from for each group feature:
“Allow”
“Deny”
“Not Set”
- “Allow”: Explicitly grants users the permission to access a group feature in MR module(s).
- “Deny”: Explicitly restricts users from accessing a group feature in MR module(s).
- “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:
- Inherited “Allow” values can be overridden to “Deny”.
- Inherited “Not Set” value can be overridden to “Allow” or “Deny”.
- Inherited “Deny” value cannot be overridden to “Allow”.
Permission Conflicts
When same user exists in more than one teams/groups, the following rules apply:
- “Deny” has preference over “Allow”.
- “Deny” has preference over “Not Set”.
- “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.
