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.
This quiet revolution in requirements is the topic of a recently published research document by Yours Truly. Many problems have inspired many new practices and disciplines, such as visualization, and even resuscitated older ones like model-based requirements. Correctly smelling a market opportunity, vendors have devised all kinds of cunning new tools. Some are highly specialized, the right tool for a specific job, like Balsamiq and iRise for visualization. Others combine many capabilities in Swiss army knife-like fashion, such as Blueprint and eDev. And there are a lot of these new requirements-focused companies, many of which didn't exist 10 years ago.
So what is the common direction in which all these problems and practices and tools are going? Value.
Throughout the entire software development life cycle, there is one place where you can (or should) find the definition of the software's value: requirements. They describe in the syntax of use cases, personas, nonfunctional requirements, road maps, prioritization, and other terms why the software will be valuable for the technology consumer, and why there's a compelling reason for the technology producer to build it.
When requirements do a bad job of defining value, software development and delivery run a much higher risk of failure. We add new software to our portfolio in haste and repent at leisure. We build software that works but doesn't work for the people using it. We fail to communicate what realistic usage of the software looks like to the people testing it. We release new capabilities too slowly for our customers to solve their problems with it or too quickly to adapt to it.
The entire value chain needs a common vision of what we're building, for whom we're building it, and what kind of benefit it provides to both producer and consumer. Without it, smart people with good intentions and mad skillz are just as likely to guess the wrong test to write, the wrong user experience to design, or the wrong item to put at the top of the backlog as the right one. That's the change of mindset that has put requirements at the top of the list of priorities and made the people responsible for requirements willing to invest in new practices and tools.