By Topic

The politics of requirements management

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$31 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)
Andriole, S. ; Safeguard Sci. Inc., USA

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 good 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

Published in:

Software, IEEE  (Volume:15 ,  Issue: 6 )