The politics of requirements management

Abstract

There are all sorts of requirements management, engineering, and specification methods out there. Most if not all were created by people who like precision, diagnosticity, and rigor-and who care about the software design and development process to the relative neglect of other, more organizational processes. Requirements management is a political process, not a technical one. Programmers need user and software requirements specifications to write good code. And many contracting officers need to see requirements documentation before they'll pay invoices. But requirements management's real importance lies in its other functions: to control expectations, to focus or diffuse blame for the inevitable, and to provide air cover for the otherwise well-meaning but naive programming teams that actually think they're satisfying user requirements. Let's step back a moment and ask some fundamental questions about where software projects come from. Some are obviously well bred: users (end users and business partners) discover some real problems that can be solved by modifying a computer program somewhere. Others come from strategic decisions about a company's line of business. But most come from preferences, from intuition about value, from the stores of pet projects we all carry around with us, or from programmers' lists of changes they'd like to make but weren't initially funded to implement. The author opines that requirements data is highly perishable, often inaccurate, and frequently manipulated to serve all-but-invisible political agendas. In short, most projects could not pass a purposeful requirements analysis test to save their life.