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.