Process for System Architecture and Requirements Engineering (Paperback)

~ (Author), Peter Hruschka (Author), Imtiaz A. Pirbhai (Author)

Editorial Reviews

Review

"By the time I was done, I had found most everything I was hoping was in the book." -- Mark Maier, Aerospace Corporation

"I recommend PSARE as the single most important reference for an organization engaged in system architecture and requirements engineering." -- Arthur Gajewski, Visteon Corporation

Product Description

Derek Hatley and Imtiaz Pirbhai -- authors of Strategies for Real-Time System Specification -- join with influential consultant Peter Hruschka to present a much anticipated update to their widely implemented Hatley/Pirbhai methods.

Process for System Architecture and Requirements Engineering introduces a new approach that is particularly useful for multidisciplinary system development: It applies equally well to all technologies and thereby provides a common language for developers in widely differing disciplines.

The Hatley-Pirbhai-Hruschka approach (H/H/P) has another important feature: the coexistence of the requirements and architecture methods and of the corresponding models they produce. These two models are kept separate, but the approach fully records their ongoing and changing interrelationships. This feature is missing from virtually all other system and software development methods and from CASE tools that only automate the requirements model.

System managers, system architects, system engineers, and managers and engineers in all of the diverse engineering technologies will benefit from this comprehensive, pragmatic text. In addition to its models of requirements and architecture and of the development process itself, the book uses in-depth case studies of a hospital monitoring system and of a multidisciplinary groundwater analysis system to illustrate the principles.

Excerpt

"The overall purpose of this book is to present a broad approach to the effective development of systems, especially those involving multiple disciplines-as most systems do. We use a variety of practical, real-world case studies to illustrate the nature of systems and the system development process, and we include system models that can be used in the process.

"The book builds on the methods and techniques originally described in Strategies for Real-Time System Specification. It is based on more than a decade of experience, our own and many others', in the practical application and teaching of the methods and techniques. . . .

"The wide acceptance of the methods -- which have become known as the Hatley/Pirbhai methods -- has been gratifying, but not all practitioners have used them correctly or effectively. . . . Our goal, then, is to share the benefit of our experiences, good and bad, in the hope of improving the overall state of system development and the methods and tools that support it." -- from the Introduction  

See all Editorial Reviews

Product Details

• Paperback: 434 pages
• Publisher: Dorset House Publishing Company, Incorporated; 1 edition (September 2000)
• Language: English
• ISBN-10: 0932633412
• ISBN-13: 978-0932633415
• Product Dimensions: 9.2 x 7.2 x 0.9 inches
• Shipping Weight: 1.7 pounds (View shipping rates and policies)
• Average Customer Review: 5.0 out of 5 stars  See all reviews (2 customer reviews)
• Amazon.com Sales Rank: #651,569 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

30 of 32 people found the following review helpful:

5.0 out of 5 stars Architecture and requirements in tandem, July 19, 2001

By	Charles Ashbacher "([e-mail])" (Marion, Iowa United States([e-mail])) - See all my reviews (TOP 50 REVIEWER)

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.

17 of 18 people found the following review helpful:

5.0 out of 5 stars Author's Introduction., October 27, 2000

By	Derek Hatley (Jenison, Michigan USA) - See all my reviews

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