The Community Blog for Business Analysts

Candase Hokanson
Candase Hokanson

What is good enough when it comes to a requirements management tool?

At Seilevel, we updated and re-published our Requirements Management (RM) Tool Study this past year, looking at over 150 tools and over 200 criteria. We did this in phases with the subset of tools making it though each phase getting smaller and smaller until we ran 21 tools through the full evaluation criteria to rank them. This tool study is a great resource if your company is looking to implement an RM tool for the first time.

But what about if your company already has an RM tool in place or has multiple that you need to decide between? The tool study report doesn’t really address how a company can look at their current tool or tools to see how they compare and if they would meet the needs of the company. You could, of course, just take the total scores and ask which one is higher or how your tool’s score ranks, but that doesn’t necessarily mean that the tool you have in place wouldn’t be “good enough” for your company’s purposes.

So, what does it mean for an RM tool to be “good enough.” Well that depends. It depends on what your requirements methodology emphasizes and what is important to ensuring you minimize the risks to your projects through the use of the tool.

Because “good enough” varies from company to company, I took our RM tool study and categorized each of the 200+ criteria into one of ten categories, or features. With these features, I then created a capabilities dashboard that shows a heat map of how each of the top 21 tools fared in the 10 features as a percentage of the total points available in that feature. With this view, you can either find or add your RM tool and see how it compares in specific categories to the other tools we evaluated to determine if the tool you have is “good enough” for your process.

The 10 features are:

  • Requirements Specification and Prioritization: Can you add, edit, delete and prioritize requirements easily?
  • Traceability/Dependencies: Can you create relationships between requirements and change the data model to reflect the traceability needed in your organization?
  • Stakeholder Management, Review and Collaboration: Can you give feedback on requirements or initiate workflows to approve requirements?
  • Change Control: Can you baseline requirements, track changes after a baseline or revert a requirements set back to a baseline?
  • Visual Modeling: Can you create and edit models in the tool or link requirements to visual models?
  • Import/Export and Reporting: Can you import/export to and from Word, Excel, Visio or other sources and can you report on the requirements, models or subset of either group?
  • Requirements Process Support: Can you set up your own templates and object types to support a methodology with things like checklists, issues, risks or constraints?
  • Task/Iteration Management: Can you track development tasks on requirements, set release or iteration dates or create agile burndown charts?
  • Licensing, Support and Tool Administration: How flexible is licensing for the tool, are there adequate support materials and how difficult it is to maintain the tool?
  • Scalability, Integrations and Ease of Use: How intuitive is the tool, can it scale and what integrations does it offer?

With these ten buckets, the heat map is shown below (click to expand). Typically, you would want to narrow in on a few tools or a few features. For example, if you know you have JIRA in place today, but Traceability and Dependencies are the most important feature to your organization, you would see that JIRA only received 60.4% of the total traceability and dependency points. Or if support of visual modeling and requirements process is most important to your organization, you might narrow down your list to TopTeam Analyst, Modern Requirements Tool Suite and Blueprint.

With this view, you can add one more dimension to your RM tool quest and maybe answer the question of “Is our RM tool good enough?” If the answer is yes, you have the heat map to socialize that message and if the answer is no, you can use this to help build the case for a new RM tool.

This entry was published on Jun 17, 2016 / Candase Hokanson. Posted in Tools. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  24 members liked this article

Related Articles

COMMENTS

Rich Wheeler posted on Wednesday, August 3, 2016 11:00 PM
RM tools come in different flavors. Many come with tangential features that make them more appropriate for one discipline than for another. For example, an RM might facilitate product innovation, Model-Based Systems Engineering, project management, or automated verification testing. Some of the criteria in the table might apply to one flavor while being irrelevant to another. I admire the work that went into the table, but without being able to weight the data, it really isn't that helpful.

Also, one critical factor is buried and another is missing. Learning curve is vital to adoption, but it is lumped in ("Ease of Use") with Scalability and Integration, which, to me, are not related. Cost (including cost of training and training time), which is missing, is important to strained budgets and critical to small businesses.
Rich Wheeler
Ronel Ellis posted on Monday, March 26, 2018 8:15 PM
The challenge I have been facing with RM tools and our current environment, is that requirements are not written this formally in many cases. A set of requirements may only live for as long as the user story is up on the board. I would love to see organisations where they have successfully managed requirements in an official tool whilst following an agile methodology. Have anyone had much success in this area?
Ronel Ellis
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC