Book review: "The Software Requirements Memory Jogger" by Ellen Gottesdiener

Introduction

This book, although small in size, is large in scope; namely, to provide a comprehensive reference for requirements activities in all sizes of software development projects. This sounds a tall order but the reader is in safe hands as the author succeeds handsomely.

The book assumes that the reader has some experience of requirements specification of software development: it would not be suitable for a complete novice as the information contained is not only densely packed but the sheer variety of techniques contained means that it would be inadvisable to apply them all on a single project. To be fair, the author provides some excellent guidance on which techniques are best suited to which types of project.

The book is split into the following sections:

  • Stage Setting;
  • Elicitation;
  • Analysis;
  • Specification;
  • Validation;
  • Management;
  • Adapting Practices to Project Types.

Stage Setting gives a straightforward about aligning tcheckhe project with the business's objectives and links to project governance areas such as risk management.

Elicitation gives a summary of how to define the requirements - starting by ensuring that all the stakeholders are identified prior to the requirements-gathering activity; missing stakeholders are a major cause of requirements being missed. The case study is especially useful here as the list of stakeholders is very comprehensive and would be a good checklist for potential missed stakeholders in your current project.

The author also describes a simple mechanism for ranking stakeholder influence/importance to give the appropriate level of involvement.

The elicitation chapter contains a succinct set of interview questions and details on how to run a focus group - information seldom seen in the popular requirements literature.

The chapter on Analysis is the meat of the book: this contains the techniques for creating requirements models such as use cases, context diagrams, process maps and state diagrams among others. Most importantly, the book suggests which are the most appropriate models to use, dependent on the project's circumstances; namely if you are:

  • modelling the business;
  • scoping the project;
  • fleshing out the user requirements;
  • negotiating requirements priorities.

The best parts of the chapter contain information that is hard to obtain in a single volume: namely, what kind of questions to ask the business community in order to derive a data model; the structure and documentation of business rules; and the role of business policies in shaping the requirements. The last category has recently become more important because of increasing legislative and regulatory compliance requirements such as SOX and Basel II.

In addition, there is a detailed section on how to engage the stakeholders in a requirements prioritisation exercise.

The chapter on Specification is interesting, especially for those from the "Agile" community who may be less familiar with the material. The author carefully distinguishes between business requirements, user requirements and software requirements, and then explains where these could be documented. She also gives a good rule of thumb for cross-referencing Use Cases with functional requirements statements . This is useful for those that prefer to start with a high-level Use Case approach but sometimes need to convert to a formal software requirements specification - something the current reviewer has had to do recently.

The Validation part of the book deals with the "play-back" of the requirements to the stakeholders to ensure that the specification is sufficiently complete for the project to continue. Techniques described are: peer review, user acceptance tests (UATs), model validation and prototyping. All are described briefly but well. The inclusion of UATs is interesting but it is not made clear that UATs are essential for the success of any project - not just an optional requirements technique.

After a brief description of the management of requirements through change control and trace mechanisms, the book goes on to describe which requirements practices are best suited to which types of software development project - perhaps the most important part of the book for less-experienced readers. The following types of project are discussed:

  • new development;
  • maintenance (sub-divided into enhancement, correction and adaption);
  • commercial off-the-shelf (COTS).

For each, there are detailed guidelines on which requirements models to use and which documents to produce.

In addition, the author considers whether the project is risk-driven or change-driven.

Risk-driven projects are those that are developing software, the failure of which threatens life or business on a large scale. These types of project tend to have more stable requirements and teams that are geographically dispersed. The author's advice is to consider whether excluding a document set constitutes more risk than including it, and act accordingly.Change-driven projects are those that are less critical and more prone to requirements change, often owing to rapidly-moving commercial environments. In this case, the author suggests leaving out a document set unless it is absolutely necessary - for example, if it is required by an external agency. These types of projects are ideally suited to a more "Agile" approach.

The author concludes pragmatically that the correct amount of documentation is "just enough", but recognises that most projects will lie somewhere between these two and suggests ways of finding the "sweet-spot" between the two.

Summary

Once the mild surprise over the physical size of the book is overcome, then its true worth is rapidly apparent. Experienced practitioners may find a minor quibble or two in their areas of expertise but all will find this book a hugely useful summary of material that was until now only available across many volumes. In addition, the book provides a thumbnail case study to provide continuity between the chapters and the author is careful to provide synonyms for technical terms so that readers can orientate themselves. Thoroughly recommended to all but the most inexperienced, who may be better off starting with one of the standard texts.

Additional Thoughts

We have extensive experience in stakeholder analysis, project scoping and requirements analysis. Please contact us for a no-obligation meeting to discuss matters further.

This is a free monthly newsletter providing commentary on software and business process industry trends industry trends for the wider business community. To subscribe, unsubscribe or change email address, please email info@agiler.com.

Please feel free to send comments or forward this to colleagues and friends who will find it valuable. Permission is granted to reprint as long as it is reprinted in its entirety.

Agilier Ltd is an independent consultancy specialising in providing leading-edge business-change and technology services using Agile techniques.

Copyright © 2006 by Marcus Price

Success Stories

"Agilier's experience in managing business processes made them an ideal candidate to manage functional integration thereby reducing a significant risk to the business. This involved them working with the workstream leads and developing a high-level integrated businesses process against which we planned our programme."

Chris Davies
Programme Manager, EADS Defence and Communications Systems

 

"I was extremely happy with the professional and complete way that Agilier performed their work and would not hesitate to use their services again."

Mike Haynes
Senior Project Manager, Cogent Defence and Security Networks

Book Reviews

News

Our latest writings, or thought-pieces, appear here.

Take a look at our free, time-saving templates in our new section.

Keep in touch with the latest ideas to help your organisation deliver. Click here for more.

RSS Feed Read More...