When Choosing a Tool Becomes a Study Project and Why That Rarely Ends Well

Why use an RM tool at all?

Before we talk about selection, we should understand the benefits of such a tool. Requirements management (RM) forms the basis of structured, traceable, and efficient product development regardless of whether it involves software, mechanical engineering, or regulated industries such as medical technology or automotive.

A modern RM tool is much more than just a digital repository for documents. For example, it supports:

• Centrally capturing, structuring, and versioning requirements instead of losing them in scattered files, tables, or emails.
• Making relationships and dependencies transparent so that it is clear which changes affect which areas.
• Ensuring quality checks and traceability, for example, whether all requirements have been tested and approved.
• Promoting communication and collaboration by having all participants work in the same system and see the same information.

In short, an RM tool is the central hub in the development process. It ensures that all participants, from requirements engineers to developers to quality assurance, work together in a structured, traceable, and efficient manner.

‍

The classic case: “Find a tool for us.”

Many companies recognize the benefits and want to introduce an RM tool. But instead of treating the selection as a strategic project, it is often delegated to a single person, often a student.

Typical tasks then sound like this:

• “Research 10 to 15 tools.”
• “Compare the features in an Excel spreadsheet.”
• “Create a shortlist from this.”
• “Recommend the best tool to us.”

At first glance, this approach appears structured and objective. In reality, however, it is often based on false assumptions and therefore rarely leads to a truly useful decision in practice.

‍

Typical pitfalls with this approach

Focus on features instead of real problems

In many student market analyses, tools are compared based on feature lists. This results in a large Excel spreadsheet in which features such as “workflow management,” “traceability,” or “test case derivation” are checked off depending on whether they are available in the tool or not.

The problem with this is that, at best, this list reflects the range of functions, but not the actual usefulness of a tool. This is because the same function can be implemented in two completely different ways in two different tools, ranging from “barely usable” to “intuitive and well thought-out.”

Students usually lack the experience to realistically assess these differences. They often only see whether a feature exists, not how it performs in everyday use. And most importantly, they are usually only familiar with the internal problems of the organization from conversations, if at all, but not from years of practical experience. As a result, tools with extensive marketing often make it onto the shortlist, even though they may be unsuitable for the specific challenges of the company.

Unclear objectives due to vague specifications

Another common mistake is that the selection process often takes place without clearly defined objectives. What exactly should the tool do? Should it merely document requirements? Or should it also support versioning, testing, linking to test cases, reuse, or approval?

It is also often unclear who will be working with the tool later on. Is it just a work aid for requirements engineers, or is it a platform for everyone involved in the development process, from the specialist department to development and testing?

In such cases, students are usually left to their own devices. They are given vague tasks such as “take a look at the market” but no clear guidelines as to what goals are actually to be achieved.

However, clarifying these goals would be essential in order to be able to define meaningful selection criteria in the first place. Without this clarity, people often simply collect whatever they can, with little regard for actual necessity.

Comparing apples with oranges

Without a deep understanding of requirements engineering and how it differs from related disciplines (such as project management or issue tracking), completely different types of tools are often lumped together.

As a result, comparison lists suddenly include tools such as Jira, Confluence, Excel, Trello, or DMS systems alongside genuine RM tools because they can somehow also work with requirements.

This makes the comparison arbitrary and reduces the significance of the evaluation to almost zero. Students usually lack the methodological background knowledge to recognize which tools are actually intended for structured requirements management and which tools are more like stopgap solutions or subcomponents.

Without this technical distinction, there is a risk that the “found” tool will look good but will not meet the actual requirements of an RM tool at all.

No realistic assessment

Even if the objectives and tool candidates were clear, students generally have no real project experience in the organization. They do not know how requirements are recorded and maintained today, what frictions exist in everyday life, who works with requirements and how, and where problems typically arise.

As a result, tools are often evaluated based on their user interface, web presence, or existing demos, but not on how they would work in a specific project context.

In the RM area in particular, however, it is crucial how well a tool integrates into the actual processes and role models of the company. This assessment can only be made by those who are familiar with these processes and can assess the impact of a tool on daily workflows.

No anchoring in the organization

And even if a recommendation is made, what happens next? Implementation often fails because the decision has not been coordinated with internal stakeholders. Management, IT, or specialist departments are unaware of the selection criteria, have never seen the tools, and do not understand why this particular tool was recommended.

The recommendation falls on deaf ears. It is “noted” but not followed up because it has neither internal support nor connectivity.

This reveals a fundamental problem: tool selection has been outsourced to a single individual without real involvement, decision-making authority, or a strategic mandate. Such an approach cannot bring about sustainable change.

‍

Why the underlying fallacy is dangerous

The decision to “outsource” tool selection – whether to students, IT, or a single specialist – often stems from an understandable desire:

People want to relieve themselves of the burden.

“We don't have time for it internally”, “We don't know enough about tools”, “Let's explore it first and decide later”. We hear statements like these often. Behind them is usually the desire to approach the issue in a structured way, but without making it a top priority.

But that is precisely the flaw in thinking: choosing an RM tool is not a purely operational decision, but a strategic one. It affects not only the question of which software is used, but also how a company will work with requirements in the future. And in doing so, it changes processes, roles, responsibilities, and often the corporate culture.

Unlike typical office tools, an RM tool is not simply a tool that you install, train on, and then use. It has a profound impact on product development processes:

• It changes how requirements are recorded, discussed, and approved.
• It reveals who makes decisions and who is responsible for what.
• It highlights where there are ambiguities, redundancies, or conflicting goals.

An RM tool thus acts like a magnifying glass – on both good and bad processes. And that is precisely why selecting one requires a high degree of internal discussion:

Which working methods do we want to retain? Where do we want to become more efficient? Who will need to work together in the future? What are our priorities?

If this discussion is avoided and responsibility is instead handed over to a single person or even an external force, the most important ingredient for a successful tool introduction is missing: a common understanding.

Because without this internal clarity...

• no tool will solve the existing problems – because they have not been clearly identified,
• no tool will be truly accepted – because it does not fit the actual needs,
• no decision will be supported – because no one is truly responsible for it.

What remains is a nice comparison report, a theoretically sound recommendation – and the reality that nothing changes in everyday work.

‍

How to do it better

The good news is that it is entirely possible to make an informed choice of requirements management tool – even without huge budgets or months of market analysis. However, it is crucial that responsibility for this lies where the impact will be felt: with those who will be working with the tool and those who are responsible for the processes.

Students can provide valuable support in this process, e.g., through research, prototypes, or accompanying documentation. But the selection itself should never be made without involving the organization and its specific challenges. A goal-oriented selection process essentially comprises five steps:

1. First understand the problem, not the market

Before even considering a tool, it must be clear: What is not working well today? Where are friction losses, additional expenses, or misunderstandings occurring?

These questions cannot be answered by internet research only by talking to those involved: specialist departments, developers, testers, project managers.

This problem-oriented approach is crucial in order to derive the requirements for a tool not from a general list of features, but from specific needs. Only then can a decision be made as to which functions are really relevant and which are not.

2. Define use cases instead of counting functions

Instead of comparing a long list of features, specific scenarios should be formulated, e.g.:

• How do we record requirements in the team?
• How do we manage changes and versions?
• How do we check the quality of requirements?
• How do we identify contradictions or duplicate content?
• How do we derive tests or specifications from this?

These so-called use cases help to evaluate tools in terms of their suitability for everyday use – not just on paper, but based on what is actually needed in the company.

3. Involve stakeholders early and actively

An RM tool does not only affect a single role. It becomes the linchpin for many stakeholders, from product idea to development to quality assurance. That is why it is essential that all affected groups are involved from the outset:

• What do they need specifically?
• Where are the sticking points today?
• What would constitute progress from their point of view?

These perspectives are crucial and also ensure that the tool will be accepted later on, because no one feels left out.

4. Don't compare, try it out

Depending on your prior knowledge, you can usually quickly identify two or three suitable tools. These should then not only be studied in brochures, but also tried out in the context of a real project.

The aim is not to test as much as possible, but to test as realistically as possible. A well-prepared pilot with real requirements, real processes, and real user groups provides more insight than any 100-line comparison matrix.

5. Make the decision where the responsibility lies

Ultimately, it must be clear that introducing an RM tool is a strategic decision. It changes working methods, processes, and responsibilities. Therefore, it should not be delegated to individuals or even external parties, no matter how committed or competent they may be.

Responsibility must lie with the specialist departments, IT, and project management and, ideally, be actively supported by management.

Students can play a valuable role in this process, for example as a source of inspiration, providing methodological support, or documenting the process. But they should not be left alone with the expectation of recommending a business tool that they themselves will never use productively.

‍

Conclusion: The tool decision is too important to delegate

An RM tool is not just any software. It influences how a company collects requirements, makes decisions, and develops products. The decision to use such a tool should therefore not be delegated to individuals, and certainly not to students or external parties.

Instead, clarity is needed about the goals, the user group, the desired benefits, and the courage to evaluate tools not only according to their functions, but also according to their suitability for everyday use.

Because in the end, what counts is not how complete the Excel spreadsheet was, but how well the tool supports the work in the project.

‍