Home > Store

Requirements Analysis: From Business Views to Architecture

Register your product to gain access to bonus material or receive a coupon.

Requirements Analysis: From Business Views to Architecture

Book

  • Sorry, this book is no longer in print.
Not for Sale

Description

  • Copyright 2003
  • Edition: 1st
  • Book
  • ISBN-10: 0-13-028228-6
  • ISBN-13: 978-0-13-028228-6

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 spacesuch as business opportunities, user needs, or the marketing environmentand 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.

Sample Content

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.

Updates

Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020