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 Harbour, 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 last decade or so, organisations 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 inn a common direction: Take requirements more seriously. In Forrester's Q1 2011 Application Development and Delivery Organisation 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 visualisation, and even resuscitated older ones like model-based requirements.
Currently, smelling a market opportunity, vendors have devised all kinds of cunning new tools. Some are highly specialised, the right tool for a specific job, like Balsamiq and iRise for visualisation. 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 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, non-functional requirements, roadmaps, prioritisation, 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 in haste to our portfolio, 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 mind-set 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.
Posted by Tom Grant
Related Forrester Research
The Six Most Meaningful Metrics To Prove And Improve App Dev's Business Value
Business People Play Critical Roles On Business Technology Project Teams
Best Practices For Software Road Maps
High-Value Requirements Are Changing App Dev And Delivery