ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1918 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Use Cases Requirements in Context
Daryl Kulak&Eamonn Guiney
0 201 65767 8
Ian Bolland
modelling languages
Appeared in:
Requirements gathering has historically been one of the main problems in software development and poor requirements gathering has been one of the main causes of project failure. The traditional specification is too verbose, usually contains much duplication, often misses important requirements (particularly non-functional ones) and almost always contains premature design decisions.

The main part of the book describes a four-stage iterative process for requirements gathering, based on Use cases. It describes the iterations as Facade, Filled, Focused and Finished. The Facade iteration attempts to determine the scope of the proposed system, the actors and a list of use cases that may be required. At this stage the use cases are just placeholders. The Filled iteration elaborates each of the candidate use cases, identifying triggers, preconditions, the basic course of events, the business rules and the exception cases. It also collects and documents non-functional requirements, such as perform-ance, integrity, robustness and maintainability. At the end of this stage, you will have collected a large set of requirements for a system that would satisfy everybody - except the person who has to pay for it.

The third, Focused, iteration separates the essential from the nice-to-have. It prioritises the use cases and removes duplicate processes. It also attempts to identify use cases, or parts of use cases that do not fit well with the remainder of the system and which could be made a separate project. The final, Finished, iteration integrates the non-functional requirements, adds user interface requirements, prototyping the user interface if necessary, finalises the scope of the system and packages the use cases for design.

The real benefit of this book is not its coverage of UML notation, which is slender, nor in the details of its methodology, which is just one amongst many. It provides interesting discussions of subjects that are often ignored; How many iterations do I do? How fine-grained should a use case be? Why should the UI be left until last? It also has coverage of many of the classic mistakes of requirements analysis.

If I were preparing a reading list of books on requirements gathering, this would not be at the top. I would probably want a general methodology-independent book on the problems of requirements specification; Jerry Weinberg has written several excellent books on this subject. I would also want a reference book on whatever methodology I was using, such as Booch et al on UML/RUP. However, for those with time and money to spare, this book provides useful alternative insights into the requirements gathering process.