Process for System Architecture and Requirements Engineering

Rating:
Summary: Author's Introduction.
Review: Amazon insisted that I give my book a rating - what would you do?

This book is an update and expansion of Strategies for Real-time System Specification, which was written by the late Imtiaz Pirbhai and me, and published in 1987.

The original book has been widely used throughout the USA and the World. This new book updates the material in the first, and adds comprehensive, practical case studies that the first book lacked.

The new book is accompanied by a web site - www.psare.com - which you are welcome to visit. There we will develop on-line case studies, and conduct a discussion forum on those case studies and on the book.

Derek Hatley

Rating:
Summary: Architecture and requirements in tandem
Review: The requirements of a software system are similar to the demands that people make in negotiations. In a negotiation, both sides know that the party making the demands is asking for much more than they expect to achieve. However, the side receiving the demands does not know which of the demands will be negotiated away and which are inviolable. While the similarities do exist and knowing them can be helpful, there are some fundamental differences.
When a client comes forward with a set of features considered requirements, even they rarely know what is essential and what can be delayed or eliminated. I have personally witnessed a customer arguing passionately for a feature, literally screaming that it was essential. But, after being told that inclusion would lead to an extended delay, they agreed to accept the product without it and after use, quietly forgot about the formerly essential requirement.
I was impressed with this book from the moment I first opened it and read the section heading, "What exactly are requirements anyway?" At first glance, this may appear to be a "Duh" question, but in fact pursuing it leads to a great deal of wisdom. Requirements are ephemeral creatures, constantly being altered by market forces, technical complexity, time deadlines and many other factors too numerous to mention. A list of initial "requirements" generally must be whittled down to those absolutely essential if there is to be any hope of completion.
Determining the project features is not something that can be done based only on desires. There are dependencies between requirements and of course there is a vast difference between the difficulty of implementing different features. There is a tightly linked feedback loop between the requirements and the architecture. As reality alters the requirements, forcing a change in the architecture; changes in the architecture based on feature implementation will feed back to alter what can be done, hence changing the requirements. The Hatley/Hruschka/Pirbhai (H/H/P) approach described in this book defines a coexistence between the requirements and architecture so that they may be iterated in tandem. This process makes more sense than almost anything else I have read recently. It formalizes what is in fact done in all but the most simple of projects.
There is a natural strain to the creative process, but in software it has grown to the point where it is a hurdle that is almost impossible to overcome. While it may sound like an oxymoron, formalizing and limiting the creative process will make it more efficient, if for no other reason than all will have a better idea what the result is supposed to be. I strongly recommend this book and have included it in my list of best books of the year.