A strong application starts with gathering solid requirements, yet over and over again, industry surveys are showing...
that requirements management is one of the biggest challenges that organizations face.
Colleen Frye reports in Agile, virtualization help with long-standing challenges:
Requirements, no matter the methodology, continues to be a persistent problem for organizations, as does process improvement and testing. When asked which part of the application lifecycle their organizations have the most difficulty with, requirements gathering, followed by process improvement and software testing/QA, topped the list for the past two years.
What are vendors doing about it? In this interview we talk to Forrester analyst Mary Gerush, author of the report, Right Tools. Write Requirements. Right On!
SSQ: What top trends have you been seeing in requirements management tools, and why are these important?
Mary Gerush: You mention RM tools, so I'm not sure if you are including requirements definition tools in that bucket, but I'll assume that you are. The market is segmented based on my research, although the market is evolving very dynamically due to the increased recognition of the cost of poor requirements and a heightened focus on the business analyst (BA) role. Having said that, here are some trends I'm seeing:
Historically, requirements management tools have been heavy-weight and required significant ramp-up time, so when I've talked to clients who have invested in some of the heavy-weight tools, in many cases, those tools have become shelfware due to usability issues (and also commonly lack of BA skills and processes). Over the last one to two years, however, vendors have invested in improving usability, making the tools easier to learn and use. Requirements definition tool vendors are also emphasizing ease of use.
Because today's teams are distributed (even if on two floors in the same building), tool vendors are focused on providing collaboration capabilities, such as Wikis, commenting, and discussions, to help teams stay in sync.
The market leaders are adding SaaS models to their offerings, and there are a number of newer vendors offering requirements definition and management tools either solely on-demand (with pretty attractive pricing models) or both on-demand and on premise. I'm still seeing most of my clients choosing on-premise models, but I expect the use of SaaS in this area to increase.
Most organizations don't use just one methodology; they may use a combination of waterfall, Agile, and RUP, or a hybrid version (so not "pure" waterfall or "pure" Agile), so while there are tools purpose-built for Agile methods, other vendors are crafting their products to be customizable for the customer's processes.
Support for modeling, prototyping, simulations
This trend affects the requirements definition tool arena primarily. Requirements management tools have been around for awhile, so their functionality is fairly well-defined. The requirements definition market, however, is relatively new, and it's growing as organizations recognize that they need to get requirements right and that requirements definition is a creative process, requiring that BAs elicit, analyze, document, and validate requirements in a more iterative way and with more pictorial artifacts - not just text-heavy business requirements documents. Some of these tools are really cool (and make me want to be a BA again!)
SSQ: How is collaboration being used in requirements management tools and why is it important?
Gerush: Today's teams are different from those of the past. They are diverse, distributed, and work for different companies (often with competing priorities). As I mentioned above, requirements vendors are emphasizing collaborative tools, such as Wikis, discussions, commenting, annotating, and viewing via lightweight readers to keep teams in sync.
SSQ: Some requirements management tools have a lot of bells and whistles, configurability, and flexibility. However, then a lot of work must be done to configure or customize your tools to match your processes. How do customers feel about this?
Gerush: That's a great question. I talk to so many clients that are just getting the BA shops in order, so tools other than Microsoft are a far-off dream. But clients definitely need usable products with short ramp-up and small learning curves; otherwise, the tools become shelfware. I do see tool vendors recognizing this and working to improve usability as I mentioned above.
SSQ: If an organization is a smaller shop that is only one methodology (for example, Scrum) would it be better to shop for a tool that is Scrum specific or to get a tool that is more configurable?
Gerush: The answer to this question (of course) is: "It depends." It depends on what problem they need to solve and their preferred practices. The market overview documents some of the variables shops should evaluate before investing. For example, if they know they will never use another methodology, it might be wise to invest in one of the purpose-built Agile tools , but if that's not a certainty, I would look for a solution that is process agnostic. I do believe though that the Agile tool vendors are looking for ways to evolve their products to fit other scenarios, but I haven't done a lot of research in that area.