Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features
Features       Excerpts       Interviews


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

The Dorset House Quarterly Interviews

Derek Hatley and Peter Hruschka
Authors of Process for System Architecture and Requirements Engineering

ISBN: 978-0-932633-41-5  
©2000  456 pages   softcover  
$59.95 (plus shipping)

DHQ: Strategies for Real-Time System Specification extended structured analysis techniques to real-time systems modeling, yielding the now-famous Hatley/Pirbhai methods. How does this new book, Process for System Architecture and Requirements Engineering, relate to the field of structured analysis and to the rest of the analysis camps out there? Specifically, should object-oriented analysts and information modelers read this book?

HATLEY: First, although the methods described in Strategies were first applied to real-time systems, their scope was always much broader than that. They were intended for and have been applied to systems of all kinds, including information systems and many others. More than anything else, these methods were intended for use by all disciplines involved in man-made systems—in other words, by all engineering disciplines, and by quite a few others besides.

Whether the software developers use O.O. or other methods is largely irrelevant to the use of the H-P methods: In the broader systems scope, the H-P methods provide the glue that binds together whatever methods and techniques are used by the individual disciplines—software or otherwise. So yes, O.O. analysts, information modelers, and everyone else involved in system development should read this book.

The single most significant feature of the methods is not, as is often believed, the addition of the control model to basic SA (though this is very significant): It is the coexistence of the requirements and architecture methods and the models they produce. These two models allow requirements and architecture to be developed separately and concurrently, but with their relationships constantly captured and updated as development progresses. In other methods, requirements and architecture either are inextricably intermingled—so it is impossible later to see which is which—or are developed separately and without their relationships captured—so there is no traceability between them, and updates cause chaos.

HRUSCHKA: For me there is no important distinction between structured and object-oriented approaches. There are just methods out there that are helpful and others that are not helpful. Anybody interested in using models properly should read this book, especially persons outside the "software only" area. We provide a requirements and architecture approach that works for many different technologies, not just for software.

DHQ: You devote an appendix to updating the Hatley/Pirbhai methods, setting the record straight on several misinterpretations, and introducing new features and ways to apply the techniques. What are the most important of these updates, and how will they affect the community of Hatley/Pirbhai users?

HATLEY: One of the more satisfying aspects of the methods and of the first book is that surprisingly few flaws have been found in either, so the appendix has more to do with minor clarifications than major changes. The biggest problem with the use of the methods has been caused in part by inadequate support from automated tools: In particular, most of them chose to support only the requirements method, not the architecture method. The most powerful feature of the two methods is the synergy between them, so if you use only one, you get far less than half the benefit of using both together.

I hope that this synergy message will finally get through, and that more users will realize the full benefits of using both methods.

DHQ: How did you first find out about each other's work and decide to write a book together?

HATLEY: Imtiaz and I met because his then employer, Boeing, was the major commercial avionics customer of my then employer, Lear Siegler. We were both working on what was at that time the latest version of the Boeing 737, and we were both given special assignments to find improved methods for system development. We noticed that our approaches were complementary and compatible, and so the Hatley/Pirbhai methods were born.

Peter Hruschka was involved with us from the very early days, and in fact developed the first tool to support the requirements method. After Imtiaz's untimely death in 1992, Peter was the obvious choice to work with me to finish the book that Imtiaz had started.

HRUSCHKA: While Derek and Imtiaz were putting the methods together, we built a CASE tool, ProMod-Plus, that supported parts of the method. At that time, I was living and working in California. I met Derek and Imtiaz several times to discuss the methods, before the first book was published. I am still proud that our tool supporting the methods was out when the book came out.

DHQ: Your coauthor Imtiaz Pirbhai, one of the original creators of the Hatley/Pirbhai methods, suddenly passed away of a heart attack while the case studies and first drafts of this book were being written. Tell us about Imtiaz and what role his work plays in the book.

HATLEY: Imtiaz's contributions to the methods, to both books, and to the successful adoption of the methods in industry cannot be overstated. He and I were equal contributors to the original methods and to the first book. He was the first of us to move into consulting and training, and he introduced the methods to all of the original major corporate users: companies like Hewlett-Packard, Motorola, and Philips.

The second book was originally Imtiaz's project with Dorset House, but his passing prevented him from finishing it. His brother, Shams, kindly gave us access to the materials Imtiaz had left, and we completed the book from there. It is not the book it would have been had he lived, but we hope it is close to his intentions. Certainly, his main goal was to provide a practical book based on the concepts set forth in Strategies, with real-world case studies to guide the reader. I believe we have met that goal.

HRUSCHKA: I worked together with Imtiaz a lot because my company sold his seminars all over Europe to support our CASE-tool sales. Over the years we became very good friends since we shared the love for cooking and art. I still use a lot of recipes from the Pakistani cuisine that Imtiaz taught me. At the time he passed away so unexpectedly, he planned to write two more books following up the H-P book: one with examples and one with a closer look at the process. I really felt morally obliged to finish his plans—not only because of our friendship, but because I firmly believed that he had the right visions about the system development process in the large. Little written material was left by Imtiaz, but I vividly remember our discussions about the subject while he was teaching in Germany or cooking in my house.

DHQ: Two parts of the book are devoted to in-depth case studies, one for a system that analyzes the environmental purity of groundwater and one for a system that processes airplane reservations input by end-users at an interactive kiosk. What inspired you to select these systems as examples? How will readers be able to reuse the models from these case studies in the systems they develop?

HATLEY: The first case study was chosen as an example of the point I just made—that systems are multidisciplinary, and that all the technologies those disciplines represent are equally important. This particular case study, on a groundwater analysis system, is based on an actual biomedical analysis system that receives samples of bodily fluids—such as blood and urine—and automatically analyzes them for infections and other abnormalities. This system, though of fairly modest size, includes mechanical transports, hydraulics, pneumatics, laser optics, chemistry, electromechanical devices, and—oh by the way—computer hardware and software!

The second case study illustrates systems that interact strongly with the user; in other words, they are user-interface driven. This type of system is becoming increasingly common and increasingly important with the advance of technology into our everyday lives, so we felt this case study would be very timely and valuable.

While it is not possible to illustrate every type of system in a single book, our hope is that these two case studies, together with illustrations throughout the rest of the book, will provide a broad enough base of practical applications for everyone to find at least a starting point for their particular developments. In addition, the two case studies provide illustrations of fairly complete, complex system models and how they are developed.

HRUSCHKA: The first case study was inspired by a real project with a similar problem statement. We just transposed it to a different application area to protect the original system. I really can't answer the question for the second one, since Imtiaz came up with that. I suspect that it was his wish for more efficient services in the airline ticket business; since he was travelling so much, easier access and more user-friendliness were high on his wish list. The second case study shows how to approach a user-interface-driven system.

The following Q&A's are only available here, on www.dorsethouse.com!

DHQ: Strategies for Real-Time System Specification, published in 1987, remains one of Dorset House's most popular books ever, and the Hatley/Pirbhai methods are implemented in many CASE tools. What's your reaction to the success of the book, the methods, and the tools?

HATLEY: Both Imtiaz Pirbhai and I were surprised and delighted with the success of the first book and the methods, and they changed our lives from being engineers working for large corporations to being consultants and trainers for industry.

You are correct that many tools set out to automate the methods, but most did not do it well, and that has been our one major disappointment since Strategies was published. Two tools now do support the methods well: TurboCASE/Sys by StructSoft (www.turbocase.com) and Axiom/Sys by STG (www.stgcase.com).

HRUSCHKA: The H/P-methods were the first to balance functions (data flow diagrams) and behavior (state transition diagrams) and the first ones to add a strong architecture method (still pretty unique in the market despite all the object-oriented methods). Nearly all of my work either concentrates on good requirements modeling (or business modeling) using different viewpoints or solid architectures for larger systems.

In the new book we added the third view (or some people consider it to be the first view): the data view (Class Models). In the last years I did a lot of requirements work for an insurance company, a bank, a product manufacturer, and a government agency. In all these projects you have to balance the use of the various views: some need more dynamic models, others need more static models, but none of them could ignore the different viewpoints altogether.

The other part—architectures—is really becoming my bread-and-butter line. Nearly any project I work with has meanwhile became so large, that this new profession "System Architect" or "Software Architect" is urgently needed. Since we can`t clone ourselves, we hope that the book teaches many more designers how to become good architects.

DHQ: This book presents a process for building system architecture models and system requirements models. Who should read this book: systems people or software people?

HRUSCHKA: Mostly systems people or software people, that have learned that software alone does nothing (without hardware, without the environment that it is embedded in, without people around it). We try to emphasize the systems thinking approach, even if the software is 80 percent of the solution. Because forgetting the other 20 percent can be fatal to such software systems!

HATLEY: I'm glad you phrased this question as you did, because you reflected an erroneous way of thinking that pervades the industry. The system development world is not divided into just systems and software and their respective people. There is a whole army of disciplines involved in system development, all equally important, and all needing to work and communicate with each other. This, as I mentioned earlier, is where the real strength of the H/P methods lies. The many disciplines involved in system development tend to have their own ways of working and their own terminologies, and this can and does lead to all kinds of misunderstanding and confusion. The H/P methods provide a unifying language through which all disciplines can communicate.

So, who should read this book? Every discipline that is involved in a given system's development: certainly systems and software people, but many others besides.

DHQ: So what are all these other disciplines?

HATLEY: The engineering disciplines include mechanical, electrical, electro-mechanical, hydraulic, pneumatic, chemical, civil, manufacturing—and that's just for starters! Some systems include as many as seven or eight different disciplines, and for those systems those disciplines are all equally important.

DHQ: In twenty words or less—or more!—tell us what trends are most interesting to you in the systems and requirements fields. How does your book address these trends?

HATLEY: The industry is finally waking up to the fact that system engineering, not software, is the focal point for system development—a seemingly self-evident statement that we tried to drum home in the first book, and, by comparison, use a whole marching band to emphasize in the second!

HRUSCHKA: Too many projects fail by ignoring the importance of system and software architecture. We make architecture—based on solid requirements—the focal point of the development process.

Well—27 words!

DHQ: Thanks, Derek and Peter!

AddThis Social Bookmark Button





COPYRIGHT NOTICE: The material contained in this file may be copied or distributed freely, provided that the material is copied or distributed in its entirety, including this Copyright Notice. This material is Copyright © 2002 by Dorset House Publishing Co., Inc. No use may be made of the material without acknowledgment of its source: Dorset House Publishing Co., http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.






New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044

Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal