| The
overall purpose of Process for System Architecture and Requirements Engineering
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. Updated Methods The
book builds on the methods and techniques originally described in Strategies
for Real-Time System Specification [Dorset House, ISBN: 0-932633-11-0,
1988]. 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. When
Strategies was written, we were working in the avionics engineering field,
but since then, we have helped to introduce the methods, and have taught and facilitated
their use, on a wide variety of projects, ranging from communications systems
to biomedical systems, and from three-person projects to those of a hundred people
and more. The wide acceptance of the methods—which became
known as the Hatley/Pirbhai methods—has been gratifying, but not all practitioners
have used them correctly or effectively. There have been several changes over
the years in the methods and their use, and several CASE (computer-aided system/software
engineering) tool developers have sought to automate the methods. Besides a few
notable exceptions, most of these tools have fallen far short of doing the job
adequately. 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. System Development
Process An important feature of our approach is that it applies
equally well to all technologies, and thereby provides a common language for developers
in widely differing disciplines. Another important feature is the coexistence
of the requirements and architecture methods, and of the corresponding models
they produce. Our approach keeps these two models separate, yet it fully records
their ongoing and changing interrelationships. This feature is missing from virtually
all other system and software development methods, and from most CASE tools, because
most of them automate only the requirements model. We are not alone in our focus
on the system development process: It is also the focus of a great deal of work
throughout the industry. What's in a Name? When
we wrote Strategies, we did not formally introduce a name for the methods
it describes. Practitioners eventually referred to them as the "Hatley/Pirbhai
methods," or simply the "H/P methods." This presents us with a
dilemma: First, many more people than the two original authors have now contributed
to the methods, and at the very least the name should include that of the third
author, Peter Hruschka; second, the methods themselves do not represent the entirety
of Strategies, and they represent even less the entirety of this book.
What we describe in both books is a process for which the methods provide
support. Our solution to this dilemma is to formally adopt separate names for
the methods and for the process. Accepting the reality that the industry has de
facto adopted a name for the methods, we propose changing that name to the "Hatley/Hruschka/Pirbhai"
or "H/H/P" methods. For the process, the title of this book is about
as good a description as we can think of: Process for System Architecture and
Requirements Engineering. Its one flaw is its length, so we propose to use
its acronym: PSARE, pronounced sari, as in the traditional southern Asian
garment. Audience and Structure The
intended audience for this book includes system managers, system architects, system
engineers, and managers and engineers in all of the diverse engineering technologies,
such as mechanical, electrical, electronic, hydraulic, chemical, manufacturing,
computer hardware, and computer software. This book may also be used as a text
for graduate courses in system engineering. It is intentional that no exercises
are included: Practical examples from the students' own experiences are much better
than "canned" exercises in a book. However, the case studies in Parts
I and II can serve as exercises for students to study, critique, extend, and modify. There
are two main parts in this book, and an important appendix:
-
Part I: Concepts: An introduction to the system approach, to system
models, to the system development process, and to the application of the models
to the process. A hospital monitoring system is used as an illustrative case study.
-
Part II: Case Study-Groundwater Analysis System: An in-depth look
at the development of a highly multidisciplinary system. -
Appendix:
Summarizes changes, improvements, and misconceptions regarding the methods and
their use since Strategies for Real-Time System Specification was written.
This appendix should be particularly helpful to those who have already used the
methods, and need a quick update on what is different about them in this book.
A Participative Case Study on the
Web While we were writing this book, software development went
through some radical changes. In response, we decided to move the book's third
case study to the Web. This case study is of an automated airline quick-ticketing
system (QTS) that is user-interface driven and very software-intensive. We consider
the Web to be the right medium for this case study because the UML and other software
notations are still changing, with new versions almost every year. The Website
is www.psare.com, and it will include a forum where those interested can discuss
issues, the methods, the QTS, and other systems and models as we develop them. A
Caveat Our commitment should be to developing quality systems
that will satisfy the customers' needs. Very often, that end goal is missed. Methods
and automated tools are only vehicles to reach that goal. Automated tools automate
methods; the methods precede their automation. Our commitment should be first
to the process of satisfying customer needs, then to the methods that facilitate
that process, and finally to the tools that automate the selected methods. Even
though we use automated tools to present our case studies, please remember
Methods and automated tools are of no use without properly qualified people
who are using a well-defined development process, and who are dedicated to satisfying
customer needs. |
