Requirements Analysis: From Business Views to Architecture [Englisch] [Gebundene Ausgabe]

This book is a compendium of the various analysis techniques that have developed over the last thirty years, organized in terms of an architectural framework. Each technique has a place in the framework, and this placement enables coherent comparison of them all, identifying the strengths and weaknesses of each. Project development teams often spend too little time learning about the actual business problems a system must address. Without a clear understanding of these issues, organizations can easily develop off-target solutions, miss critical windows of opportunity, and get overrun by their competition. On the other hand, development teams that follow a proven process tend to get it right from the beginning, avoiding the costs of repairing or re-releasing software later in the life cycle. Requirements and Analysis is the process of defining your system. This involves obtaining a clear understanding of the problem space--such as business opportunities, user needs, or the marketing environment--and then defining an application or system to solve that problem. Rational Requirements and Analysis solutions help you build it right from the beginning.Foreword by Barbara von Halle, Spectrum Technology Group Inc.

This book is a compendium of the various analysis techniques that have developed over the last thirty years, organized in terms of an architectural framework. Each technique has a place in the framework, and this placement enables coherent comparison of them all, identifying the strengths and weaknesses of each. Project development teams often spend too little time learning about the actual business problems a system must address. Without a clear understanding of these issues, organizations can easily develop off-target solutions, miss critical windows of opportunity, and get overrun by their competition. On the other hand, development teams that follow a proven process tend to get it right from the beginning, avoiding the costs of repairing or re-releasing software later in the life cycle. Requirements and Analysis is the process of defining your system. This involves obtaining a clear understanding of the problem space--such as business opportunities, user needs, or the marketing environment--and then defining an application or system to solve that problem. Rational Requirements and Analysis solutions help you build it right from the beginning.Foreword by Barbara von Halle, Spectrum Technology Group Inc.

The complete guide to requirements analysis for every system analyst and project team member.

Thousands of software projects are doomed from the start because they're based on a faulty understanding of the business problem that must be solved. The solution is effective requirements analysis. In Requirements Analysis: From Business Views to Architecture, David C. Hay gives you a comprehensive overview of the world's best requirements analysis practices, organized coherently to help you choose and execute the best approach for every project. In addition, he guides you through the process of defining an architecture—from gaining a full understanding of what business people need to the creation of a complete enterprise architecture.

Practical solutions will help you:

• Focus more clearly on the goals of requirements analysis
• Represent the fundamental structures and systems environment of any enterprise more accurately
• Identify key information processing gaps and discover which information technologies can best address them
• Clarify the goals of your new system and reflect them more accurately in your models
• Understand crucial people-related issues that impact requirements
• Plan smooth transitions to new systems

Requirements Analysis: From Business Views to Architecture provides the complete process of defining an architecture—so that you can build a rock-solid foundation for your next software project.

David C. Hay has been developing interactive, database-oriented systems since the days of punched cards, paper tape, and teletype machines. He is president of Essential Strategies, Inc., a Houston, Texas-based worldwide consultancy that uses modeling techniques to help construct information strategies and architectures, and defines requirements in a wide range of organizations, including pharmaceutical researchers, news-gathering and broadcasting firms, oil refiners, and government agencies.

Preface

The Inspiration for This Book: Object-Oriented Analysis

Object-oriented programming has, in recent years, radically reduced the amount of time and effort required to build systems. A technology derived from real-time systems, it has been successfully applied to interactive, windows-based user interfaces and the systems they support. One of its appeals is that it is highly modular, allowing pieces to be built and repaired easily without major surgery on an entire system. Moreover, modules can be reused.

In recent years the object-oriented community has ventured into the world of requirements analysis. Numerous books on "object-oriented analysis" have appeared, and the UML has come on the scene as a technique for supporting this.

There are three attendant problems: First, object-oriented programmers, like all programmers, tend to focus on the technology of producing programs, and they find it less interesting to go out and analyze the nature of a business. The skills required to do that are different, so they may be less likely to have them. The idea seems to have arisen that object-oriented designers are natural systems analysts, although this does not necessarily follow.

A second problem is that some authors consider requirements analysis an object-oriented phenomenon. Ideas developed from information engineering and other sources are ignored as though they were irrelevant to the object-oriented world. This has meant, among other things, that disciplines which have been important and valuable to the field for several decades have been simply ignored.

In 1991, for example, James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen published Object-Oriented Modeling and Design. This book presented an object-modeling notation along with a methodology called the "Object Modeling Technique", or OMT. The notation consisted of symbols for the same concepts that Clive Finkelstein and James Martin had presented ten years earlier in their work on information engineering. OMT is concerned with object classes (entity types), associations (relationships), and attributes.

The methodology, while it purported to be a significant departure from "traditional software development approaches" Rumbaugh et al. 1991, p. 146, was very similar to information engineering. Like information engineering, it was based on the principles of "shifting of development effort into analysis", "emphasis on data structure before function", and a "seamless development process". These are precisely the principles that had already been articulated by Messrs. Finkelstein and Martin. One significant difference is that OMT is much more oriented toward an iterative approach.

Deep in Chapter 12 the book does give credit to Peter Chen as the inventor of entity/relationship modeling, and it recognizes that object-modeling's techniques are descended directly from entity/relationship modeling Rumbaugh et al. 1991, p. 271. But this is not obvious from the language in the rest of the book.

Modern requirements analysis is in fact the combined work of many people who have been contributing to the industry for over 30 years. The role of requirements analysis in the system-development life cycle is more important than ever, even with the advent of object-oriented technologies. Contrary to what some say, it has not changed fundamentally with the advent of these techniques.

Object orientation has indeed contributed to requirements analysis, but it has less to do with it than some perceive. The requirements analysis process is intended to identify business requirements for information technology, not to determine the technology used to solve those requirements. A properly done requirements specification should be able to guide designers using any technology.

The third problem comes from authors who insist on including "object-oriented features" in the requirements process. "Control objects" and "interface objects" are artifacts from object-oriented design, but they are often (inappropriately) described as part of the requirements analysis process.

The fact of the matter is that the process of identifying requirements is fundamentally different from the process of applying technology to address those requirements. It should be possible to identify requirements without necessarily knowing (except in the most general terms) what technology will be applied to address them. The same set of requirements might be satisfied by an object-oriented application, by an application implemented with Oracle Corporation's relational tools, or by a set of COBOL programs.

About the Book

Rather than viewing requirements analysis from the perspective of a particular implementation technology, this book views it as fundamentally an architectural process. Specifically, it sets out to answer the question: How do we identify and understand the architecture of an enterprise, so that whatever systems we build for it can truly support that architecture? To do this, it attempts to bring together as many as possible of the best techniques and approaches from the entire history of systems development (including some that originated in the object-oriented world), and it will argue the relevance of all of these in developing object-oriented and other kinds of systems.

Merriam Webster defines "architecture" as "a unifying or coherent form or structure" Merriam Webster, 2001. When the present book describes an architecture for requirements analysis, it is describing the structure of the entire requirements process. The book is informed by the work of John Zachman, who has described the architecture of systems development as a matrix, with the perspectives of the players in the development process as rows, and the things to be seen from each perspective as columns. The various techniques presented are organized in terms of the cells in such a matrix.

This book's premise is that requirements analysis is the translation of a set of business owners' views of the enterprise to a single, comprehensive architectural view of that enterprise. After some introductory chapters, there is a chapter on each of the dimensions (what, how, where, who, when and why) of the two perspectives.

While the book's focus is on these two rows, attention must be paid to the "scope" perspective that puts all our efforts in perspective. Also, where it is useful to our understanding (notwithstanding the remarks above), reference is occasionally made to the implications for technology designers of what we learn.

While, in one sense, this book will cover ground explored by others, it is unique because it describes in one place the full range of artifacts that can be delivered in an analysis project. This should give the book a completeness not found in most. It addresses not only analysis of data and process, but also the analysis of data networks, people and organizations, events, and motivation.

This is not the kind of book that you can read through like a mystery novel. The Introduction and Chapters 1 and 2 provide an overview of the field and should be read first. The remaining six chapters provide both a roadmap and a reference guide. The roadmap describes 12 of the 36 cells in the Architecture Framework and how they relate to each other. The reference guide is to the myriad of techniques that are available for each cell. If there is a technique you've heard of and you would like to know both more about it and how it fits into the general scheme of things, you should be able to find it here.

Note that Mr. Zachman's great insight was to provide a framework for organizing what we know. That we don't know everything equally well becomes quickly apparent when we try to populate the matrix. You will observe as you go through the book that the various chapters do not describe each...