Software Requirements, Third Edition
Karl Wiegers and Joy Beatty
(Microsoft Press – paperback, Kindle)
A lot changes in 10 years, particularly in the world of software development. The previous edition of this book appeared in 2003, and I never knew about it while I struggled over software requirements documents and user manuals as a technical writer for several big and small companies.
In those days, pulling information out of software engineers was on par with pulling their wisdom teeth using needle-nosed pliers. And management seldom was helpful. Sometimes, I would be sitting at my desk, working on some project, and a high-level delegation suddenly would arrive.
“We are releasing a new software update tomorrow,” the delegation leader would announce. “And we need some documentation written. Here is the latest requirements document. We need for you to expand it into a release document. Oh, and some kind of user manual.”
Fortunately and unfortunately, the software release almost always slipped from tomorrow to the next week and then to the next month as bugs emerged during final testing. While the customer grumbled or screamed, I had time to produce new documents from the software requirements, plus interviews with any engineer I could grab and threaten to name in the materials that I would send out to customers.
It was all seat-of-the-pants stuff. Now, after retiring several years ago, I can only wish I had had this well-written “best practices” guide to creating, managing, and making best use of software requirements documents.
Software Requirements, Third Edition covers a lot of ground in its 637 (print-edition) pages. The 32 chapters are organized into five major parts:
- Part I – Software Requirements: What, Why, and Who
- Part II – Requirements Development
- Part III – Requirements for Specific Project Classes
- Part IV – Requirements Management
- Part V – Implementing Requirements Engineering
The book’s two authors, each an expert in software requirements development, emphasize that a software requirements document can be a shining beacon of guidance and clarity or a confusing array of ill-defined features and functions–or it can be something that hovers perilously between good and bad.
The writers emphasize: “Many problems in the software world arise from shortcomings in the ways that people learn about, document, agree upon and modify the product’s requirements….[C]ommon problem areas are information gathering, implied functionality, miscommunicated assumptions, poorly specified requirements, and a casual change process. Various studies suggest that errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product….Inadequate user input and shortcomings in specifying and managing customer requirements are major contributors to unsuccessful projects. Despite this evidence,” they warn, “many organizations still practice ineffective requirements methods.”
Indeed, they add: “Nowhere more than in the requirements do the interests of all the stakeholders in a project intersect….These stakeholders include customers, users, business analysts, developers, and many others. Handled well, this intersection can lead to delighted customers and fulfilled developers. Handled poorly, it is the source of misunderstanding and friction that undermine the product’s quality and business value.”
The intended primary readership for the book includes “business analysts and requirements engineers, along with software architects, developers, project managers, and other stakeholders.”
In my view, Software Requirements, Third Edition should be read by an even bigger audience. This includes anyone who works in software development, anyone who manages software developers, anyone who sells software development services, plus other key personnel in companies that create, sell, or buy specialized or customized software products or services. The buyer must understand the software requirements process just as keenly as the seller. Otherwise, the software development company may try to hide behind certain jargon or definitions or introduce new processes or changes previously undefined as a delaying tactic, particularly if it has fallen behind schedule or otherwise is failing to deliver what it has promised.
A well-structured, well-worded, well-managed requirements document can help save time, money and, most importantly, the reputations of the companies and people on all sides of a software project. This important, newly updated book shows exactly how such documents can be created, managed, and maintained.
— Si Dunn
Books, Commentary, & More 