I often get asked ‚what is the best tool for requirements engineering and requirements management?‘ The answer is not so simple because what starts out as a question about a tool only for one group of people quickly turns into a question about the underlying process and organization. If you want the whole truth and nothing but the truth about introducing these tools suites into an organization you should read this post.

The list of high level product features for such a requirements management tool starts small and then gets longer very quickly, becoming a list for a tool suite for application life cycle management.

• Requirements management: to maintain all derivatives of requirements e.g. features, product requirements, epics, stories, etc.
• Specification management: to maintain the different versions of the specification for products.
• Baselining and configuration management: to manage the versions of all artifacts that belong together.
• Document generation: Organizations have to decide whether they want to write and manage requirements and specifications in the tool or just manage documents. Writing requirements in the tool requires a lot of people to change their way of working because they love their MS Office. If the requirements and specifications are written in the tool, then it needs a flexible document generator.
• Test Management: for managing test cases, planning test cycles, and managing test executions.
• Release Management: for bundling requirements into releases and sprints or test cycles thus managing the scope of a release or sprint.
• Project management: to overview the quality status of the work products as well as the productivity status of the team.
• Traceability among all of the artifacts including the strategic objectives. But, this comes at a cost! See my comment in LinkedIn.
• Defect management

Integrated way of working collaboratively

In order to achieve the idealized business value that these product features are aiming towards, a sometimes new way of collaboration is required. There are only a few organizations that are already working or want to work in such an integrated way in which all stakeholders agree that such a tool is necessary, that it provides a value to themselves, and a business value to the organization itself. Only then, they will be willing to fully commit to the introduction of such a tool.

Stakeholders

Since such an integrated tool requires multiple groups of people to collaborate, all stakeholder roles have to be taken into account. These are e.g.

• Product managers and product owners
• Project managers
• Release managers
• Change managers
• Business analysts
• Requirements engineers
• Testers
• Developers

This list is already long but unfortunately only shows that the effort for introducing this kind of tool suite should not be underestimated.

Them vs. us

Often, such a tool is only wanted by one group of stakeholders, like requirements engineers, because they sometimes have to manage hundreds of requirements, or testers, because their life would be a lot easier if they know what to test.

The real challenge for these two roles is to convince the other to change their work habits without gaining much. This will result in situations in which they might be saying ‚they want us to change so they can have an easier life!‘ Their next statements will be ‚we have to use their tool but they didn’t even ask us whether we want their tool‘ and ‚where is my benefit?‘

Change the organization first before introducing a tool

Organizations that believe they can accelerate change through a tool will fail. It is as simple as that. Do not try it. Do not even think about it.

Project view vs. life cycle view

Most stakeholders want to use a project view: requirements and all other artifacts are grouped as projects. While that seems to be good for the project it might not be too good for the organization because products and their requirements have a longer life cycle than the projects creating or modifying them.

Organizations have to decide which approach suits their needs.

A fool with a tool…

Organizations that introduce any new tool and try to force stakeholders to change will not be successful. You will need a lot of force to introduce the tool and to be sure that it will remain once the main stakeholders are no longer responsible or are not with the organization anymore. The organization then will fall back to the old way of doing the daily business.

It’s the tool’s fault…

Since there is so much change involved for everyone and the learning curve is long, organizations have to cope with a reduction of productivity for a long time. Everyone will argue that it is the tool’s fault that they cannot finish the same amount of work as before the introduction of the new tool. In some cases they might deliberately try not to learn so they can keep their old way of working – the one they know and love.

The effect I have personally seen is that a department head allowed a team member to NOT use the new tool in order to cope with the work. Once that Rubicon has been crossed the introduction of the tool and any other tool following will fail because everyone will go back to the old way of working.

The tools

Finally! So, you really need such a tool? I mean really really need not just want? Do all stakeholders have the same need? Okay, then here are some of the tools and my judgement about their suitability for requirements engineering and requirements management.

Microsoft Office

Don’t get me started! This is and will “always” be everyone’s favorite set of tools. Obviously, it doesn’t fulfill the above requirements – not even the bare minimum – but it is so familiar to use, it works everywhere, and is so easy to take with you to read. All other tools will have to provide a similar flexibility but will most likely fail.

Atlassian Jira and Confluence

Jira used to be a tool for task management only. It has become the hype tool suite of the agile community because it is cheap and seemingly easy to use. But, requirements are not tasks: tasks can be thrown away once done but requirements should remain.

I have seen projects that made this combination work but requirements management is a challenge. To create a feature tree one would have to use a plugin called Structure. This plugin allows to move issues into a tree-like structure after they have been created, making this a two-step task. Using Confluence for writing requirements could be done but managing them will prove difficult.

I also have not seen test management done right with this tool suite. And, forget document generation.

VersionOne

Another want-to-be. This has to be the worst of the huge tool suites. I don’t even look into that tool anymore but rather wait for the export into a better tool in which I can read the requirements or that will allow me to create a Word file having the same structure as within the tool.

Sparx Enterprise Architect

In situations in which modeling is necessary (and in complex situation this should always be done) Sparx EA is a pretty good and relatively cheap tool.

If you are into visualizing your requirements then this is the tool. Unfortunately, it is not good in requirements management. But, it has a very flexible document generator.

Polarion

I have heard good things about Polarion from a requirements perspective. Supposedly, one can write in a Word file and the content will constantly be uploading. That sounds pretty nice. Other than that, I have not experienced the suite.

HP ALM or QC

HP ALM (formerly known as Quality Center and Test Director) originates from test management. The requirements module is very solid, even though in version 11 the editor is awful, really awful.

But, for managing requirements it is very good. It has a lot of quirks and you have to license the ALM not the QC version. The ALM version is a solid but expensive tool suite.

In version 12 HP has supposedly completely updated the user interface for entering requirements. From what I saw in presentations, it feels like writing a Word document.

Agosense

Agosense used to be an integration platform that allows to combine best-of-breed tools. So, for instance, one could use Jira, HP, and Sparx and use Agosense for synchronizing data between tools.

In the last year, Agosense presented their first tool requirements management. From what I saw in presentation, it looks rather solid.

Best-of Breed

Do not use best-of-breed without integrating them! You will fail.

Best approach

A change like this can be done successfully! There are just so many mistakes you can make. This is not just about changing how to manage your requirements but about changing the organization.

First, you need to understand John Kotter’s story about the melting iceberg. Second, you have to plan and execute that organizational change really well. Get agreement and participation from the top of the organization, through the chain of command down to every affected person in the organization for the whole transition – not just for the start. Every person in the chain of command is affected as well and each has a lot of power to help or to hinder your endeavor.

A change must be driven from inside the organization. The leadership team of the change must understand how change is done, so send them to this excellent course about Change Management at the ZFU International Business School.

If you choose outside help, which in general is a good idea, then always remember that they will leave once their job is done.

This will be a very long ride. Enjoy it on the way.