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.

In the tech industry, the "tell me a story" approach to product requirements – personas, user stories, use cases, visualizations, etc. –  has made a bigger impact than many people may realize. Not only has this new type of content resolved many problems that existed with requirements, but it has led to a brand new way of looking at requirements. By thinking of requirements as stories, it's easier to figure out what kinds of requirements we need, and why we need them.

A tale of two mini-series
The fundamental question when writing any kind of story is, "What are you trying to convey?" I was thinking of exactly that question while I was watching the HBO mini-series The Pacific. I probably wasn't the only person to expect The Pacific to be the same kind of story as Band Of Brothers, just transplanted from the European to the Pacific theater of operations. I was wrong.

As it turns out, the new series has a very different kind of story to tell. Band Of Brothers depicted the experience of combat, in (literally) gory detail. While The Pacific does have more than enough battle scenes, it also tries to show military life beyond the battlefield. For example, one episode focused on the painful romantic choices that young people stationed in faraway lands have to make. Another episode depicted something rarely seen in war movies, the psychiatric casualties of war. Far more than Band Of Brothers, The Pacific shows more of the atrocious things that young men under brutal, terrifying conditions are capable of doing.