Online Sample Chapters
Introduction to Requirements Analysis
Requirements Analysis: Dealing with Data
Downloadable Sample Chapter
Click here for a sample chapter for this book: 0130282286.pdf
Table of Contents
Foreword.
Preface.
Introduction.
1. A Framework for Architecture.
The Zachman Framework. The Architecture Framework. The Analysis Process. Implications.
2. Managing Projects. Introduction. Summary of Development Phases. About Strategy. About Requirements Analysis. Process One: Define Scope. Process Two: Plan the Process. Process Three: Gather Information. Process Four: Describe the Enterprise. Process Five: Define What Is Required of a New System. Process Six: Determine the Existing Systems Environment. Process Seven: Plan for Transition. Summary.
3. Column One: Data. Views of Data. A Brief History of Data Architecture. Advanced Data Management—Meta-data. Graphics—Data Modeling. Using Entity/Relationship and Object Models. Normalization. Data Modeling Conventions. Entity/Relationship Model Validation. The Requirements Analysis Deliverable—Column One. Data and the Other Columns. Conclusion.
4. Column Two: Activities. From the Business Owners' View to the Architect's View. Approach. Function Hierarchies. Dependency Diagrams. Data Flow Diagrams. IDEF0. The UML Activity Diagram. Interaction Diagrams. Use Cases. A Word About Business Process Re-engineering. Detailed Function and Process Documentation. Implications of Analyzing Activities. The Requirements Analysis Deliverable—Column Two. Activities and the Other Columns.
5. Column Four: People and Organizations. How to Organize the Enterprise (Row One). Row Two: The Business Owner's View. Row Three: The Nature of a (Human) System. Implications of This Model. System Use. Requirements Analysis Deliverable—Column Four. People, Organizations, and the Other Columns.
6. Column Three: Locations. Row Two—Geography. Row Three—Network (and the Other Columns). The Requirements Analysis Deliverable—Column Three.
7. Column Five: Timing. Introduction. Row One: Scope. Row Two: The Business Owner's View. Row Three: The Architect's View. The Requirements Analysis Deliverable—Column Five. Timing and the Other Columns. Conclusion.
8. Column Six: Motivation. Introduction. Row One: Scope. Row Two: Business Owners' Views. Row Three: Architect's View. Requirements Analysis Deliverable—Column Six. Motivation and the Other Columns. Conclusion.
Appendix A. The Zachman Framework. Appendix B. A Comparison of Data Modeling Techniques. Appendix C. The Business Rules Group Motivation Model. Appendix D. The Business Rules Group and David C. Hay Modified Motivation Model. Glossary. Bibliography. Index.
Preface
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 area of knowledge equally well or equally completely. Indeed, the chapters are of very different lengths. Moreover, each is written in a somewhat different style, depending on the kinds of information available for that column.
We've had a lot more experience modeling data, for example, than we have in modeling locations or even people and organizations. Mr. Codd gave us a mathematical basis for modeling data that does not exist for any of the other columns. For the others, we are trying to establish discipline, but it doesn't come easy.
A colleague of mine once remarked that he would like a book "to assist people like me who don't have time to learn anything that's not new". I would like this to be such a book. It will show you what's already been invented and point you in the direction of things that have not.
It is the joy and aggravation of our times to have the opportunity to be in on an industry that is building itself before our very eyes. At its best, this book is no more than a snapshot of what we know in the year 2002 of the modern era. With luck, future editions will have a great deal to add. The homework assignment for every reader of this book is to be diligent in expanding this body of knowledge.
The Important Stuff
Arguments about which technique is better are not what this book is about. It attempts to present a wide range of techniques and asks you to choose the best ones for your particular situation. So far in our history, the most models are available for modeling data and modeling activities. The most important chapter here, however, is not about modeling either of those. Chapter 6 is about understanding people and organizations, the roles they play in the success of an enterprise, and the importance of communications channels in making that success happen. This, alas, is something that has not been very well or very systematically addressed in our industry.
For this reason, the chapter digs back twenty years to the field of cybernetics, and it uses insights from this field to discuss the communications channels that constitute the lifeblood of an organization. Specifically, it describes the way we use "amplifiers" and "attenuators" (filters) to manage the proliferation of "variety" (complexity) that confronts every business. Managing variety, after all, turns out to be what everyone's job is all about. Buried in the middle of that chapter is an expression of the true purpose of the requirements analysis process:
Requirements analysis is the examination of an organization to determine the most effective amplifiers and attenuators to build. What are needed? How are those now in place ineffective or counter productive? What should they look like, given the purpose and organization of the enterprise?
Amplifiers and filters? What are those? I hear you ask. To learn more about them, you are just going to have to read Chapter 6.