Modern Requirements4DevOps is a fully-featured Requirements Management tool built into Azure DevOps. By partnering with Microsoft, Modern Requirements is able to offer a fully integrated solution within Azure DevOps, TFS, and VSTS. The Modern Requirements solution provides the ability to: Create documentation without leaving an Azure DevOps project Construct Diagrams, Mockups, and Use Case models that the user can connect requirements directly to Build…
N/A
OpenText ALM/Quality Center
Score 7.6 out of 10
N/A
OpenText™ ALM/Quality Center, formerly from Micro Focus, serves as the single pane of glass for software quality management. It helps users to govern application lifecycle management activities and implement rigorous, auditable lifecycle processes.
We tried the Modern Requirements4DevOps AddIn to see if it brings a added value to our development. I have to say that I would distinguish between types of projects in which it is beneficial and in which it is probably "over engineering". Certainly, bigger development projects with higher complexity are more suitable than small and not really complex projects. However, for the bigger projects Modern Requirements4DevOps definitely helps to deal with the complexity as it adds way more contextualisation to the various entities. It really helps to understand which requirements led to which action in a diagram or task during development. It helps to control the complexity and inform all team members along the project.
For an organisation that has completely adopted SAFe structure including naming terminology, it is less appropriate and apart from that. It can suit any organisation out there, and it can solve all your problems one way or another by customising it. It is a robust and highly scalable solution to support all the business needs. It improves a lot of productivity and visibility.
If you have a mix of automation & manual test suites, HPALM is the best tool to manage that. It definitely integrates very well with HP automation tools like HP Unified Functional Testing and HP LoadRunner. Automated Suites can be executed, reports can be maintained automatically. It also classifies which test suites are manual & which are automated & managers can see the progress happening in moving from manual to automated suites. In HPA ALM all the functional test suites, performance test suites, security suites can be defined, managed & tracked in one place.
It is a wonderful tool for test management. Whether you want to create test cases, or import it, from execution to snapshot capturing, it supports all activities very well. The linking of defects to test runs is excellent. Any changes in mandatory fields or status of the defect triggers an e-mail and sent automatically to the user that the defect is assigned to.
It also supports devops implementation by interacting with development tool sets such as Jenkins & GIT. It also bring in team collaboration by supporting collaboration tools like Slack and Hubot.
This tool can integrate to any environment, any source control management tool bringing in changes and creates that trace-ability and links between source control changes to requirements to tests across the sdlc life-cycle.
The requirements module is not as user friendly as other applications, such as Blue Bird. Managing requirements is usually done in another tool. However, having the requirements in ALM is important to ensure traceability to tests and defects.
Reporting across multiple ALM repositories is not supported within the tool. Only graphs are included within ALM functionality. Due to size considerations, one or two projects is not a good solution. Alternatively, we have started leveraging the template functionality within ALM and are integrating with a third party reporting tool to work around this issue.
NET (not Octane) requires a package for deployment to machines without administrative rights. Every time there is a change, a new package must be created, which increases the time to deploy. It also forces us to wait until multiple patches have been provided before updating production.
Because it lets me track the test cases with detailed scenarios and is clearly separated in folders. Also the defect filter helps me filter only the ones that have been assigned to a particular area of interest. The availability of reports lets me see the essentials fields which I might be missing the data on and helps me to work on these instead of having to go through everything.
It is a great tool, however, it got this rating because there is a lot of learning that takes a lot longer than other tools. There are no mobile versions of ALM even with just a project summary view. I believe ALM is well capable of integration with other analytics tools that can help business solutions prediction based on current and past project data. This is Data held in ALM but with no other use apart from human reading and project progress. ALM looks like a steady platform that I believe can handle more dynamic functionality. You could add an internal communication platform that is not a third party. Limit that communication tool to specific project members.
Modern Requirements4DevOps is an AddIn for Azure DevOps Server (Microsoft Azure DevOps) and extends the native features of Azure DevOps in the area of Requirements Engineering, Requirements Management and Reporting. Azure DevOps already contains tons of valuable features. However, for bigger and more complex projects Modern Requirements4DevOps extends Azure DevOps by further features. Thus we used both products alongside.
We have other tools in our organization like Atlassian JIRA and Microsoft Team Foundation Server, which are very capable tools but very narrow in their approach and feature set and does not come even close to the some of the core capabilities of HP ALM. HP ALM is the "System of Record" in our organization. It gives visibility for an artifact throughout the delivery chain, which cut downs unnecessary bottlenecks and noise during releases.
Better communication --> thus less misunderstandings
More Transparency about requirements --> adds context and helps to build a common understanding
Traceability of Requirements --> we used the baseline also to look into the history of requirements to understand how certain requirements have changed
