Requirements

June 26, 2017

How To Evaluate Requirements Management Tools?

We will discuss about requirements management tools in detail here. We will discuss what tool you would need to gather requirements and how to select the right requirements management tool for your team. From the flint stone to the invention of the wheel, from the horse drawn cart to the internal combustion engine, tools have played an important role in shaping – and advancing – our civilisation.

So imagine living one day of your life without using a single tool.

Yeah, I thought so. It would be dreadful!

Then again, you need the right tools for the job at hand. Whatever that job might be. You can’t bring a knife to a gunfight. You can’t bring a bicycle helmet to an ice hockey game.

Tooling is important. But getting the right tools is critical to boost your team’s success.

List of Top 10 Requirements Management Tools of 2020:

Here we have listed top 10 requirements management tools. Requirements management can be tricky especially when you have to track the changes in your requirements. A poor requirements management can lead to scope creeps.

IBM Rational
ReQtest
Jama
GatherSpace
HP ALM
Visure Requirements
ReqChecker
Aha
Blueprint
iRise

How to Select Right Requirements Management Tool?

In this post, I will give you a personal, customised insider’s guide to selecting the right set of Requirements Management tools for your team, programme, project.

We will look at why you need a tooling strategy, and how to get one.
We will review key characteristics you need to look for in tools – like plug-ins, traceability.
We will discuss how the methodology you follow will influence your tooling strategy.
We will, ultimately, discuss the elephant in the room – cost.

Before you begin – what do you need tools for?

Alternatively, do you need any more tools at all?

Many a time, the kneejerk reaction to poor planning and execution is to channel short-term energies into finding tools that can fill the void. And I am talking about the void in your soul, not the void left by lack of good tools to complement your team’s abilities.

“Tooling should be one of the outcomes – a means to an end. Not the end itself.”

Let me explain.

If your project or team’s performance is lagging, this could be due to a host of issues.

Are you running Waterfall in Agile clothing?

Do your team have the right training and experience to perform to potential?

Is your planning robust enough to account for contingencies and eventualities?

Before you go down the tooling route, you need to take stock of your project, programme, team. Identify areas for improvement, and list down the 3 or 5 outcomes you need to achieve to improve in each of these areas.

Tooling should be one of the outcomes – a means to an end. Not the end itself.

A means to an end

For example, if during Testing, there are constant questions about whether a defect is really a defect and not a requirement, this (probably) points to the lack of clear Requirements Traceability.

This issue cannot be fixed just by introducing a shiny new requirements management tool. The solution to this problem will include, among other things, a review of current tooling to establish a way to improve or establish Requirements Traceability – from defect back to test case back to requirement.

You may already have the tools required to achieve this; you don’t necessarily need to go out and buy a new one.

In such cases, I have mostly found that the team are either not aware that their current tool set provides the ability to establish traceability, or don’t consider it a priority.

So find out if you really, really need new tools.

Review your Tooling Strategy – or Write one!

The strength of a good tooling strategy lies in actually having a tooling strategy. Seriously.

Even a bad tooling strategy is better than having none. You will at least be able to dissect it to understand what went wrong.

If you don’t already have a written (not in your head or in the clouds – real rain-giving ones) strategy for the requirements management tools used by your team, then get one written, reviewed and approved by key stakeholders.

If you already have a tooling strategy, then get it reviewed. This review should go hand in hand with the ‘stocktaking’ that you did previously.

Where the review identifies a gap or need for more tooling, pit that against your tooling strategy to see if the gap or need is already addressed.

Going back to the requirements traceability example, you may find that the team use a requirements management tool that also provides sound capabilities for establishing traceability.

Or you may find that the available capabilities do not meet the critical needs highlighted by the review. Or that the team do not have sufficient training to use existing capabilities effectively.

If at the end of an overarching project, team and tooling strategy review, you establish beyond doubt that the current requirements management tool set does not meet your needs, then start your search for the right tools.

Requirements Management Tools – Key features to look for

This is where the overall review you did earlier really delivers vast benefits to your search. When you know what problems you’re trying to solve with tools, you will be able to effectively zero in on the key features you need from yours.

In our example, we needed to establish Requirements Traceability. So that is the problem you are trying to solve. Tools like JIRA and ReQtest provide exceptional requirements traceability.

Narrow down your requirements management tools search to those that plug most (if not all) holes uncovered by the review.

The fundamental features that your requirements management tool should cover:

Requirements Capture and Documentation (JIRA, ReQtest, RTC)
Review History and Version control (JIRA, ReQtest)
Distribution, Approval and Sign-off features (RTC)
Ability to elaborate down to multiple levels (epic, story, sub-story, acceptance criteria, test scenario, test case, test script) (JIRA, ReQtest, RTC)
Establish links to other sources (JIRA, ReQtest, RTC)
Highlight dependencies (JIRA, ReQtest, RTC)
Document upload (JIRA, ReQtest, RTC)
Traceability – link requirements with dashboards, test cases, defects (ReQtest, JIRA, RTC)
Visually express status of each requirement – requirements, design, development, testing, implementation (ReQtest, JIRA, RTC)
Allow collaboration with other tools or plug-ins (ReQtest, JIRA)

Rank the features you need from 1 to 10 (or more). As long as a tool meets the top 5, it should make your shortlist. From there, it’s a matter of time before other factors (below) dictate which one you pick.

What methodology do you use?

Do you want to use a spreadsheet to run an Agile project? Why?

I’ve said this previously – sometimes the choice of methodology you use to deliver IT projects will be influenced/constrained by your circumstances and limiting factors. So, it is alright to use the methodology that works best for you, your team and your situation.

Be mindful, then, that the methodology your team follow will/should directly influence the requirements management tools they use for delivery.

For projects using Agile methodologies, there are a plethora of tooling options out there. We won’t get into a comparison of which one’s better than the other. The key is to focus on what’s right for you, and what’s in it for you.

“Be mindful, then, that the methodology your team follow will/should directly influence the requirements management tool they use for delivery.”

Make sure that IT methodology is part of your decision when looking for requirements management tools that fit your needs.

The elephant in the room – Cost

It’s easy to go overboard on your spending on tools. That’s the main thing you should be looking to address.

Do you really need a data center-hosted solution from Atlassian, or should you consider using the Atlassian cloud instead?

Questions like these depend on the type of data you’re handling, and the regulations surrounding these. Not to forget the country and industry you’re operating within.

It’s possible that you are, or working for, a bank. There are restrictions on what a bank can put on the cloud, and how this information needs to be protected. So then, depending on the size of your team, and the value of the system, data, product, business, you need to make a value-driven decision to either go for an in-house data center-hosted solution, or not.

Again, if you are innovating (think Elon Musk) and working on a top secret product that you expect to revolutionise the market, you may naturally be averse to putting it on the cloud.

Most often, and unless you’re in a heavily regulated industry, it is OK to choose a tool that comes with cloud-hosted services. We are in the twenty first century after all, and everything’s on the cloud. And it’s as safe as you want it to be.

Now for the feature set. Do you really need that shiny, flashy add-on feature that doubles the price you pay for each user? Do you absolutely have to have that ‘pro’ upgrade for your bunch of business analysts? Do you absolutely have to have a desktop client or can your team do with web access?

Let us also consider the number of users that will engage with these tools.

How big is your team? 15, 20, 200, 1500?
How big and how fast do you expect your team to grow?
What are the organisational, industry factors that will drive this growth?

There is no use paying for 500 users when all you want is about 50 to use it on a daily basis.

Most tools provide you flexi-pricing options. Packages let you strap on more users for increasingly lesser cost. To top that, if you are really considering a number that’s significantly larger (for you or for the seller), you can negotiate a pricing model that works for everyone.

In summary

Tools are just that – tools. The onus is really on you and your team to reap the most out of your efforts with these tools. Getting the right tools for the job is important. Making the most of it is paramount.

Remember that with Agile, the only agile requirements management software you need are a whiteboard, sticky pad and a marker. So rationalise your tooling needs, and focus on maximising their potential.

Employ the best people. A good team can do wonders with the worst of tools. Not the other way around. Ever.

What is your experience with Requirements Management tools? Which ones do you think are the best and Why? Share your comments below.