Review: Software Requirements, Third Edition

Software Requirements, Third Edition

By Karl Wiegers and Joy Beatty
Published by Microsoft Press, 2013

Review by Robert L. Glass

Subsequent editions of computing books trouble me. I’m never quite sure whether I ought to be reviewing what’s new about the book, or the whole book, original parts and new parts together. And, to make that issue more complicated, I'm never quite sure what it is that’s new about the book, so I’m normally condemned to reviewing the whole thing. And, to be honest, I suppose I’m a little bit jealous. None of MY books has ever made it to a third edition!

But that dilemma is eased somewhat with this book. It starts right out by explaining what’s new in its subject field since the previous edition. That’s slightly different from what’s new about this edition, but I think one can assume that there’s a correlation between what the authors see as new about their field, and what they’ve done to the previous edition to bring it up to date.

OK, so what’s new about the requirements field that prompted the authors to produce a third edition?

• The field has become a professional discipline, with certification and support organizations.
• Requirements support tools are maturing.
• Increasingly, agile approaches impact everything about the computing field, requirements especially included.
• There is increasing use of visual models.

I don’t know how many pages were in the previous editions, but this one is HUGE! Getting up toward 700 pages, enough that just holding the book up to read and review it becomes a chore! Still, that’s a good thing, right? You’d rather such a book contains too much information than too little.

And what’s my bottom line here? Two things: I have to admit that I personally know and like the lead author of this book, and I would be embarrassed if I had to say nasty things about it (although I have been frequently known to do just that!). But fortunately, I don’t have anything nasty to say. I in fact like the way the book is organized, and I like what it contains.

Some particularly likeable things:

Each new topic begins with a realistic and often contentious conversation between two or more principals on a relevant project. It’s a comfortable way to be introduced to a topic.

The book focuses not just on relevant conversations, but relevant projects / case studies. It has a feeling of realism.

It feels astonishingly thorough. Here are just some of the topics it covers: use cases, business rules, requirements specifications (note: that is not your standard Computer Science formal specs discussion), representation techniques, quality requirements, prototyping, prioritizing, validation, requirements reuse (that’s a fascinating concept all by itself!), and requirements management.

It presents a bill of rights, and a bill of responsibilities, for the customers that requirements analysts deal with.

Rights:

Business Analysts (BAs) should learn the customer’s language.
BAs should learn about the business itself and its objectives.
BAs should record the requirements appropriately.
BAs should explain their practice and the expected deliverables.
You the customer have a right to change your requirements.
There must be mutual respect.
BAs must be prepared to listen to what’s wrong with the current solution.
BAs must be prepared to provide increased ease of use vs. the current approach.
BAs should be prepared to suggest reusable approaches.
BAs must provide a new system that meets needs and expectations.

Responsibilities:

Customers must educate BAs as needed.
Must provide sufficient time to provide/clarify requirements.
Must be specific and precise.
Make timely decisions.
Respect developers’ assessments.
Set realistic priorities.
Review work products.
Establish acceptance criteria.
Promptly communicate changes.
Respect the requirements development process.

It provides/describes a list of 50 requirements engineering good practices, and imbeds them in a process framework within which they can be applied.

It discusses approaches that can be used for six different kinds of projects: agile, enhancement, packaged, outsourced, business process automation, business analytics, and embedded real-time (that’s quite a comprehensive spectrum of possible projects!).

There are lots of appropriate warnings about the result of not following good requirements practices: resulting rework can consume 30–50% of project cost, and errors in requirements drive 70–85% of rework cost.

This book says it is focused on “principles that work in practice,” and I am happy to say that I believe it has accomplished precisely that. For example, wouldn’t you love it if every project on which you worked applied those rights and responsibilities provided above?!

This review originally appeared in The Software Practitioner, a bimonthly newsletter written by and for people who build software for a living. It is not written by journalists (who typically know too little about software) or theorists (who know too little about practice).