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