Revolutions take two forms. The most familiar kind is the noisy, conspicuous, disjunctive event that marks a clean break from the past. Yesterday, George III was our monarch. Today, he's not. The other kind of revolution is a more gradual and subtle event, when multiple forces pointing in the same direction push people into a new world. The shock of Pearl Harbor, the power vacuum left by a devastated Europe and Japan, a reinvigorated economy, and an aggressive superpower adversary made Americans feel, for the first time, that they needed to be far more deeply involved in international affairs than ever before. Without any formal declaration, Americans became internationalists after 1945.

Something like that second kind of revolution has happened with software requirements. Over the past decade or so, organizations grew increasingly worried about the problems that took root in bad requirements. The problems took many forms (portfolios filled with applications no one was using, users unhappy with the software that complicated their lives more than helped them, ideas that no one vetted carefully, etc.) and arose from just as many sources.

All of these discontents pointed in a common direction: Take requirements more seriously. In Forrester's Q1 2011 Application Development And Delivery Organization Structure Online Survey, "improvements of requirements" appeared at the top of the list of initiatives that would improve software development the most.

via Mike Gilpin

It's a real pleasure for me to be able to bring you some insights that emerged from the Forrester Leadership Board's Application Development & Delivery Council during 2010. My colleague Julia Spencer, an Advisor to the council, has written up these insights, which I have pasted in below, but we are inviting you to enter the discussion as well. Thanks, Julia, for bringing us this wisdom and for helping us get a peek inside this exclusive community of application delivery leaders:

From Julia Spencer:

During 2010, the Forrester Leadership Boards’ (FLB) Application Development & Delivery Council (AD&D Council) tackled many issues, including that of defining and managing requirements for more-effective application delivery. As a Council Advisor, I receive many questions about requirements, such as “How do you define a quality requirement?” I’d like to share some best practices revealed during our Member Meetings in Las Vegas, Nevada, and Lisbon, Portugal, and our highly interactive CouncilTel (FLB group discussion) on software requirements.

I’d love your feedback: Which best practices have worked for you? What is missing from the list?

First: What are requirements, and why do they matter?

I have learned that the word “requirements” means different things to different people, and some struggle to define the word altogether.

I knew it was only a matter of time before someone used Xtranormal.com to good effect. Always a trailblazer, The Cranky Product Manager posted some videos about interviewing for a PM position.

And then I couldn't resist...

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.