Software Requirements Specifications : A How to Guide for Project Staff

Every failed software project has a confession buried somewhere in its post-mortem. It usually reads something like this: we didn't really understand what the users needed. Or: the requirements kept changing. Or, most damningly of all: we built exactly what they asked for, and it wasn't what they wanted.

Requirements failure is the original software sin. It is the problem that sits upstream of every other problem — the miscommunication that multiplies across months of development, compounding silently until it erupts at delivery, when it is far too late and far too expensive to fix. Industry surveys have placed the cost of poor requirements at the top of the list of reasons software projects fail for decades. The diagnosis has not changed. What has often been missing is the cure.

Software Requirements Specifications is that cure, delivered in the disciplined, practical language of someone who has spent a career at the intersection of technology and human organisation.

Grounded in two of the field's most authoritative IEEE standards — IEEE Std 830 Guide to Software Requirements Specifications and IEEE Std P1233 Guide for Developing System Requirements Specification — this guide walks project staff, business analysts, developers, and customer representatives through the entire requirements capture process, from the first general conversation about what a system should do to the fully signed-off Software Requirements Specification that forms the legal and technical baseline for design and testing.

The book opens with a frank, historically grounded diagnosis of why requirements capture so often goes wrong. The user-developer cultural divide is not a minor inconvenience — it is a structural problem, documented since the early 1970s and still unresolved in most organisations. Drawing on decades of research, the author maps nine distinct categories of gap between users and developers: perspective gaps, ownership gaps, foresight gaps, communication gaps, expectation gaps, credibility gaps, and more. Understanding these gaps is the first step to closing them, and this book shows exactly how.

From that foundation, the methodology unfolds across three core documents. The Requirements List captures, in plain business language, every capability, feature, and characteristic the customer needs — prioritised by urgency, classified by criticality, cross-referenced and linked. The Statement of User Requirements translates those raw needs into a structured, high-level narrative that developers can work from and customers can still understand — a document that is, crucially, the right tool for a feasibility study before a single resource is committed. And the Software Requirements Specification delivers the complete, unambiguous, technically rigorous definition of every functional and non-functional requirement the system must meet.

Each of the eight qualities that a good SRS must possess — correct, unambiguous, complete, verifiable, consistent, modifiable, traceable, and operable through maintenance — is explained and illustrated in detail. Multiple approaches to organising the specific requirements section are provided, from organisation by mode, by user class, by object, by feature, by stimulus and response, and by functional hierarchy, allowing the methodology to flex to projects of any size or structure.

The result is a guide that transforms the most treacherous phase of software development from an art form dependent on luck and personality into a repeatable, manageable, and auditable professional discipline. If you have ever delivered the wrong thing to the right people — or watched someone else do it — this book is the map you needed before the journey began.