Which requirements management system to choose: overview of tools

Not every tool can be considered an SUT

To begin with, I would like to say that a full-fledged requirements management system should allow:

• create requirements

• analyze requirements,

• manage requirements changes,

• trace requirements

• issue flexible reporting for different projects.

For example, Jira and Confluence, which are familiar to many, cannot be considered SUTs, because they were originally created for other tasks.

The majority (80%) of the surveyed analysts would like to implement the STS in their work

In parallel with testing the demos, I interviewed 100 colleagues in chats and among acquaintances (all of them work in different companies) to find out their experience of using the SUT and ask questions that interested me. Here's what the survey showed.

It turned out that more than half of the respondents know what a requirements management system is. If I had not immediately discussed that we do not consider Jira and Confluence to be requirements management systems in their pure form, the percentage would have been higher.

It also turned out that almost no one uses such systems at work – for various reasons. In fact, everyone goes their own way: this is confirmed by the fact that at every conference we see a report on the topic “How we organized the writing of requirements in our company.” The unpopularity of using STS is also confirmed by the number and relevance of articles on this topic. For some reason they don't write about this. So, apparently, they don’t use it.

The good news is that most analysts, after being introduced to a requirements management system, believe that it is worth using.

Comparison of tools

Late last year I finished researching various tools. Below are the logos of the tools I reviewed. Perhaps some of them are already familiar to you.

For ease of comparison, I selected 17 indicators and divided them into four groups:

• primary requirements,

• integration with services,

• convenience,

• Additional requirements.

Primary requirements. One of the main tasks of an analyst is writing requirements. Accordingly, first of all, I checked the possibility of writing technical requirements, user stories, and the connection between TT and US.

Integration with services. Since analysts are not the only team that works with documentation, integration with the software and infrastructure of other teams’ work tools is very important. Otherwise, testers, developers and other colleagues simply will not be able to fully use the documentation.

I tested the integration of tools with four services:

• Jira. I considered it as a tool for storing development tasks, because at the time of research it was a working tool in my company. In addition, Jira is still the most popular program for managing developer tasks.

• E.A. I chose it as an architecture storage service because almost everyone knows it.

• Allure and Figma. I chose them because if there is integration with these products, then with slightly less well-known ones it is quite easy.

I also looked at integration with services for storing management tasks, but during the research I realized that the SUT does not integrate with any software.

Convenience. Analysts spend eight hours a day writing requirements, so there must be some beauty in our work? I want the tool to be visually pleasing and intuitive. That's why I evaluated the interface.

I also think it’s important when a service has training videos and technical support that will answer questions if difficulties arise. I don’t want to google it myself and figure out how I used the system. Therefore, I looked at their availability too.

Additional requirements. During the research, another group of indicators was added – these are three important features that I did not take into account at the start, but during the research process I came across in some tools: sandboxes, import from Excel and my own test module.

The result is a comparison table like this.

Jama, Visure, ReqView – the best foreign EMS

After analyzing the table above, I selected the top three services. My crush, of course, is Jama.

Jama. Once a person has tried this software, everything else fades away. The service is thought out to the smallest detail: so much so that you can even insert images and select the subject area in which you work. For example, product development in the automotive industry requires automotive software. Jama Connect for the Automotive Industry is built around key infrastructures that support critical safety standards and regulations in automotive product development and is ISO 26262 certified.

Jama also has a great interface. Everything we love is colorful, clear and structured. See for yourself. Below are screenshots of the Jama interface (source).

I only used the trial version, but I was able to communicate with colleagues from Automotive who used Jama in their work. Their number of technical requirements exceeds not hundreds or even hundreds of thousands, but millions, but the service copes well. What’s also cool is that thanks to the integration capabilities and user-friendly interface, developers love to read the requirements.

If suddenly someone in Russia wants to make similar software, then this is clearly something to follow. It seems to me that the service will not leave anyone indifferent.

Visure. It is simpler and inferior to Jama in terms of convenience, but overall competitive.

With Visure you can create, edit and manage requirements. Requirements can be easily exported to Word and Excel.

In addition to requirements management, Visure allows you to manage testing, track defects and issues, manage changes and manage risks. It provides configuration management, version tracking, a core structure for all artifacts, and allows engineering teams to gain full end-to-end traceability across multiple projects.

There is also the ability to trace source code back to requirements and functionality, track components by project or change history, and security requirements created to mitigate specific high-risk factors.

You can also use Visure to access your tracking dashboard in real time to see the percentage of items that are being tracked or not tracked. This will enable traceability at any level, from high-level customer requirements to software, hardware and mechanical requirements, as well as risk and testing.

End-to-end traceability allows for faster time to market and lower testing and development costs. It is an essential platform for engineering teams building complex products and systems in highly regulated industries. Take a look at the Visure interface (source).

ReqView. One of the key benefits of ReqView is its robust tracking features. Users can establish relationships between different requirements, creating parent-child relationships and dependencies. This makes it easier to track how changes to one requirement may affect others, providing better control over the scope of the project.

ReqView provides flexibility in customizing the attributes and templates used to document requirements. This allows organizations to tailor the tool to their specific requirements collection processes and patterns.

What's also cool is that ReqView allows multiple team members to work on requirements documents simultaneously in real time.

Devprom and Tekhekspert are worthy Russian analogues

Unlike foreign services, a license to use these tools can be purchased.

Devprom. The program allows you to jointly create full-fledged requirements from the browser, document UML models, formulas and algorithms, and view changes in models and formulas.

The software is distinguished by convenient work with the register of requirements: discussion, review and approval of requirements in a team. It also allows you to quickly and easily assign tasks to developers and testers.

Regarding the requirements aspects, Devrom has requirements versioning and baselines, requirements tracing to design artifacts, loading and unloading requirements in Word, Open Document, HTML, PDF, Excel formats using custom templates.

There is a fully customizable process for working on requirements, an extensible data model, and collection and visualization of metrics for analyzing problems and increasing productivity. Judge for yourself (Devrom interface source):

“Technical expert”. For me, the service became a kind of discovery. It allows you to create requirements from regulations, technical specifications and other technical documents. The system automates the work of specialists in coordinating and approving requirements. There are many functions for working with requirements:

• establishing connections and tracing between requirements,

• installation of dependencies,

• automatic control of relevance,

• requirements change management

• creation of editions (revisions), classification, discussion and approval.

Combining requirements into a single hierarchical structure allows you to get a complete picture of the product or process. Structuring requirements into levels significantly improves understanding of the final goal, increases interaction between development participants, and helps avoid duplication of work.

Multi-user work with requirements allows you to conduct discussions with experts, managers, customers, coordinate and approve requirements, and distribute tasks between performers.

Tracking changes in requirements, establishing a direct connection between the requirement and the basis document, as well as daily automatic updating allow you to track the slightest changes and take the necessary measures in a timely manner.

The program allows you to generate reports and search for similar requirements. In addition to all that has been said, there is also an API for interacting with third-party systems (CAD, PLM and others). There are also disadvantages, for example, data export is only possible in the ReqIF format.

Alternatives to SUT

If managers in your company do not yet see the need to purchase an STS, but with further growth of the product this may be required, you can already use the services described below at the initial stage. This will simplify the transition to a requirements management system in the future.

Requirements Yogi plugin for Confluence. You may have heard about it or are already using it. The plugin is good for describing features, allows you to track changes in features, understand the product as a whole, and create baseline requirements. If the product is complex and multi-layered, then this plugin is also convenient to use.

However, Confluence will not support describing all the technical and functional requirements for a product.

If you suddenly purchased such a plugin, I advise you to try it anyway. It also has a demo version.

Excel. At my previous job, we used good old Excel because it can handle those hundred million rows. He really stands up to them.

But this is not its only advantage. Excel also has references to user requirements, architecture documents, features and technical requirements, and testing. Therefore, all teams participated in filling out these documents. It’s also cool that different “ball” resources support multi-user modification of documents of this type.

We did not come up with our own template – we were based on the templates of the best SUTs. Used requirement ID, requirement version, description. They were already more detailed, with references to user cases and planning (we had quarterly PI planning). Each feature was maintained in a separate file, which we called a workbook.

Using Excel helped streamline requirements writing and reduce the development backlog from six months to two.

I also think it’s important to add that sometimes you can do without ATS. For example, in the case of an MVP, it is enough to write brief requirements, release the product to the market and see if anyone needs it.

Main

• A full-fledged requirements management system should allow you to create and analyze requirements, manage requirements changes, trace them, and issue reporting that depends on the project.

• Jama, Visure, Reqview are the best SUTs according to the research results.

• Devprom and Tekhekspert are worthy Russian analogues.

• In addition to the SUT, you can use the Requirements Yogi plugin for Confluence or good old Excel.

• Sometimes you can do without SUT. For example, when creating an MVP.

We invite you to a meeting of positive analysts.

It will take place on June 20 from 19:00 to 22:00 in St. Petersburg at the address: Kazanskaya street, 7, FREEDOM space. Three reports await you:

● Is there a place for a systems analyst in Agile?

● From analyst to manager. When we really need to go there.

● What is expected from an information security analyst.

There will also be tabletops, a buffet and communication with like-minded people. Participation is free. Register and come!

Tatyana Markina

Head of the security control systems design group, Positive Technologies