The Unrecognized Success Of The Requirements Tool Market

The just-published overview of the requirements tool market is, at bottom, a story of unrecognized success. The requirements tool market has grown rapidly along several measures, including the number of vendors, the scale of adoption, and (the primary focus of the overview) the number of business problems that these tools are designed to address. From a small niche in the software market, requirements tools have grown and evolved, sometimes merging with other applications, to the point where it's hard to talk about them as "requirements tools" in the strictest sense of the term.

When colleague Mary Gerush and I dove into the primary research, we were immediately struck by the number of vendors that have crowded into a space that, to be honest, was not too long ago treated as a bit obscure and unexciting. The longer we looked at the market, the more little vendors appeared in the landscape. We'd heard of long-standing specialty vendors like Ryma, Blueprint, and iRise, but names like TraceCloud and AcuNote were new to us. The big vendors, too, have seen opportunities in this space, sometimes buying (for example, IBM's acquisition of Telelogic), sometimes building (such as Microsoft's Sketchflow tool).

Something was happening in this market, and at least a piece of the explanation was clear from the moment we started talking to vendors and users. Very few of these applications were exactly like the first generation of requirements tools, such as MKS Integrity and Borland (now Micro Focus) Caliber, and most of the newer tools bore little resemblance to each other. Although they share the title "requirements tool," they don't deal with the same aspects of requirements.

To illustrate, let's put Accept Requirements side-by-side with Atlassian JIRA. Accept Requirements addresses many of the business issues around requirements, such as their role in justifying and explaining the rationale for undertaking a project. Development teams are able to use the requirements as a guide for building new technology, as they would other tools with the word requirements in their names. Accept's tool deals with other issues, too, such as the flow of ideas for projects and the place of these projects in the company's overall portfolio. (Hence the integration with Accept's other tools, Ideas and Portfolios.)

In contrast, Atlassian JIRA isn't even called a requirements tool, but that's how many technical teams use it. As an issues and projects tracking tool, JIRA includes content that becomes part of requirements. JIRA also has the advantage of being the sort of tool that developers may already use, or would be open to using.

JIRA's integrations with other Atlassian tools serve a different purpose than the integrations that Accept has built. For example, JIRA content that appears in the Confluence wiki helps with the execution of projects, by sharing information about projects with people inside and outside the team. The JIRA/Confluence connection is not designed to deal with business issues as explicitly as the troika of Accept Requirements, Ideas, and Portfolio does.

Different business problems require different tools to address them. Some development teams struggle with internal communications, so they look to one tool, or a combination of tools. Another team finds itself undertaking projects for all the wrong business reasons, so they look at different tools for help. Are they all requirements tools? Certainly, if that's what people think they're using them to manage. However, we may need to revise the nomenclature eventually to capture exactly how big and diverse this segment is. 

But what caused this sudden interest in how these business problems affect requirements? Or how requirements contribute to the resolution of the problems? That's a much bigger question than I can answer in one blog post, so I refer you to the official market overview for the time being. In a future post, I'll talk a little bit about the reasons why the requirements tool market experienced sudden growth and diversification.


Accept and Jira

My company uses both Accept and Jira/Confluence. The Product Managers and Business Line Owners along with senior stakeholders use Accept to manager requirements at the Business Requirements level (strategic initiatives, themes, offerings, features). Our developers and business analysts use Jira to manage the detailed development-level requirements...what I wouldn't give to have a single system.

Accept is getting closer to a robust feature set that will satisfy the needs of both business and development. They offer a great requirements hierarchy in a very straightforward format, while Jira does not, which effectively prevent requirements traceability. In my opinion, key features that Accept has to get into the product in order for development to adopt is drag and drop functionality, virtual user story boards, and much better reporting. For the most part, I get the sense that they know these are high priority features. On the other hand, it doesn't appear that Atlassian has noticed that many of their customers would adopt Jira as an enterprise requirements tool if they would enhance the product so that business users could use it easily. Jira's usability and feature functionality rule that out as an option for my company and probably many others. I think Atlassian is missing the mark on capturing enterprise-wide adoption.

What about real functional requirements?

What about real functional requirements? You know, like "The system must have the ability to calculate sales tax by county and state."

Actual elicitation of requirements will be the hardest for tools to address. Requirements come from working face to face with the business people who want something. I await something that makes this work easier in some way.

Agile tooling

Tom, as an Agile believer, how do you think that those tools really support the methodology?

You have been talking about JIRA here. Do you feel that the Agile add-on (GreenHopper) provides decent capabilities? Would you recommend something else?