Practical Software Requirements

Jason Bennett has returned after a long hiatus, bringing with him a review of Benjamin L. Kovitz' Practical Software Requirements. Jason's theme has been software engineering, and this review does not disappoint, drawing on themes of what you actually need to accomplish your job. Practical Software Requirements author Benjamin L. Kovitz pages 426 publisher Manning rating 9/10 reviewer Jason Bennett ISBN 1884777597 summary A different perspective on how to gather requirements

Background

Greetings, all. I apologize for my long review layoff, but between June and now, I've managed to acquire a job where I actually have something better to do than write book reviews! Bonus! :-) Regardless, in the course of designing a new system for my company, I needed to write a good requirements document. I thought I knew how to do this, and set about creating the most anal, unreadable piece of technical gobbledygook you've ever seen. Needless to say, this document didn't fly. In desperation, I fished around Amazon.com for some decent requirements books. I already had the IEEE specification for requirements, but I didn't have a book that explained how to use the specification (this should tell you something). My search finally turned up this work, which had some good reviews posted, and the rest is history....

What's the book about?

Kovitz presents a very different view of requirements engineering from the prevailing view. Most approaches to requirements focus on breaking a problem into parts, and with these parts filling in predefined sections of a requirements template. Kovitz disagrees with this approach to requirements, and offers his own. In short, he says that decomposing a problem correctly is hard to impossible without some idea of what the solution is before you begin. Thus, when presented with a problem, you should try and find out what type of problem it is, so that you can relate the problem to ones already solved. From here, Kovitz describes how best to frame problems, and gives some sample problem frames.

Of course, once a problem has been placed in its proper frame, it still must be broken out into its constituent parts so that the requirements can be enumerated. Kovitz describes a process for doing this whereby the denizens of the problem domain are enumerated, along with their relationships. Once these denizens ("sets") are enumerated, along with their individual attributes and relationships, they make up the description of the problem domain. The requirements, then, are the effects the machine is to produce on the previously-described problem domain. Kovitz also advocates a separate interface document, which describes how the machine interacts with the problem domain. The book then ends with a series of chapters on style and structure, and a comprehensive example.

What's Good?

Overall, I found the book to be quite excellent. Kovitz tries to break down the legalistic view of requirements engineering as a top-down fill-in-the-blank exercise, and instead advocates a more flexible system whereby the design is kept separate, but each project has the process attuned to its distinct needs. This is quite a refreshing view, but one that still mandates good software engineering practices that can get any project off to an excellent start. In addition, the author has an online discussion forum where readers can ask questions, and receive direct help from the author. I found this to be an excellent resource, and the author is to be commended for such participation and dedication.

What's Bad?

I have to admit, I had a little trouble applying the ideas in the book. Specifically, I had difficulty deciding what exactly were "sets" in my problem domain, and what their attributes were. It was a simple issue of translating the concepts to the reality of my project. In the end, I don't think my requirements document quite met the standard set in PSR, but it certainly benefitted a great deal from it.

So What's In It For Me?

I haven't been able to give a good software engineering lecture in a while, so I'll jump back on my high horse. All project, especially open source ones, need the solid foundation that can only come from good requirements. If you don't know what you are going to build, you have no chance of building it. Open source projects especially need a paper trail for new participants so that they can quickly come up to speed and understand the direction that the project is headed. Artifacts such as requirements speed this process and give everyone a common framework to draw from. Kovitz's approach provides for readable, coherent documents that allow people to understand what domain they are working in, and what they are trying to accomplish.

Purchase this book at Amazon.

• Table of Contents
• Introduction
• Acknowledgements
• Author Online
• Part I: Groundwork
  1. Problem Solving
  2. Problem Defining
  3. Two Worlds and Three Designs
  4. Problem Framing
  5. Five Problem Frames
  6. Multi-frame Problems
• Part II: Content
  1. Software Development
  2. Two Documents
  3. Classes and Relations
  4. Sequences and Events
  5. Causation and Control
  6. Special Topics
• Part III: Style
  1. Documentation
  2. Organization
  3. Small Details
• Part IV: Examples
  1. Bug Log Requirements
  2. Bug Log User Interface
• Glossary
• Bibliography
• Index