| 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! | 
