Requirements Engineering: A Good Practice Guide

by Ian Sommerville, Pete Sawyer

Requirements engineering is the process of discovering, documenting and managing the requirements for a computer-based system. The goal of requirements engineering is to produce a set of system requirements which, as far as possible, is complete, consistent, relevant and reflects what the customer actually wants. Although this ideal is probably unattainable, the use of a systematic approach based on engineering principles leads to better requirements than the informal approach which is still commonly used. This book presents a set of guidelines which reflect the best practice in requirements engineering. Based on the authors' experience in research and in software and systems development, these guidelines explain in an easy-to-understand way how you can improve your requirements engineering processes. The guidelines are applicable for any type of application and, in general, apply to both systems and software engineering. The guidelines here range from simple 'common sense' to those which propose the introduction of complex new methods. The guidelines and process improvement schemes have been organised so that you can pick and choose according to your problems, goals and available budget. There are few dependencies between guidelines so you can introduce them in any order in your organisation. Guidelines presented in the book
* are consistent with ISO 9000 and CMM
* are ranked with cost/benefit analysis
* give implementation advice
* can be combined and applied to suit your organisation's needs
* are supported by a web page pointing to RE tools and resources

Genres: Programming, Software, Reference

408 pages, Paperback

First published April 28, 1997

Reviews

[Steve Whiting · Rating 4 out of 5]

It's like reading a little slice of ancient history....

This was the original edition, from 1997, and oh my, the world has moved on a lot since then. An awful lot of the ideas in this book have been embedded into the requirement definition in my employer, and I would suspect throughout large portions of the industry. As a result, the book now reads like a long list of blindingly obvious points.

There are still a few worthwhile reminders in there - documenting the why and who of requirements, and construction of conflict tables to track competing requirements, but otherwise from a 2009 perspective, it's pretty thin fare.

Now, it reads more like a piece of computational archeology than a useful text book. It's almost quaint to look back at a world with no UML, no Use Cases, no Agile/XP, where new-fangled object modelling is regarded with suspicion, where providing email to participants in a requirements exercise is non-mainstream enough to be worth mentioning, and where using a relational database for requirements (a Good Idea, in my view) is regarded with caution because it would require multiple tables (!) and performance would suffer.

I don't think a modern organisation would benefit from this (edition of this) book, unless their requirements process was absolutely anarchic and dysfunctional - and even then, there are far better books out there.