Chapter 1: Introduction

“The beginnings and endings of all human undertakings are untidy, the building of a house, the writing of a novel, the demolition of a bridge, and, eminently, the finish of a voyage.”

— John Galsworthy Over the River, 1933

1. Why systems analysis is interesting; 2. Why systems analysis is more difficult than programming; and 3. Why it is important to be familiar with systems analysis.

Chances are that you groaned when you first picked up this book, seeing how heavy and thick it was. The prospect of reading such a long, technical book is enough to make anyone gloomy; fortunately, just as long journeys take place one day at a time, and ultimately one step at a time, so long books get read one chapter at a time, and ultimately one sentence at a time.

1.1 Why is systems analysis interesting?

Long books are often dull; fortunately, the subject matter of this book — systems analysis — is interesting. In fact, systems analysis is more interesting than anything I know, with the possible exception of sex and some rare vintages of Australian wine. Without a doubt, it is more interesting than computer programming (not that programming is dull) because it involves studying the interactions of people, and disparate groups of people, and computers and organizations. As Tom DeMarco said in his delightful book, Structured Analysis and Systems Specification (DeMarco, 1978),

[systems] analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult. In a word, it is fascinating. Once you’re hooked, the old easy pleasures of system building are never again enough to satisfy you.

This may come as a surprise to you if you have any experience writing computer programs. [1] Programming is enormous fun, and it’s enormously satisfying to see a program execute successfully, especially after spending several hours debugging it. It’s hard to imagine that things could be even more rewarding and exciting when you begin to move away from the computer and the writing of computer programs to study the overall system in which the programs play a part. But by the end of this book, I hope to have convinced you that the real challenge, and the real joy, of working with computer systems is that of carrying out systems analysis. No matter what profession you decide to pursue, it will be important for you to understand what systems analysis is all about. If you work in the computer industry as something other than an electrical engineer or hardware designer, there is a good chance that your career will progress from programmer to systems designer to systems analyst before you finally move on to the ranks of management. [2]

This book is intended for two audiences: first, the person who is new to the field of systems analysis, and, second, the experienced systems analyst who needs to acquaint himself with systems modeling tools and techniques that have evolved over the past decade. Many readers will be university computer science students who have completed earlier courses on computer programming; some may be students in a business training program.

However, the book should be equally readable by people who have finished their university training and who are now working in industry. Many people in the computer industry spend their first several years working as a computer programmer, and then suddenly find themselves promoted to a position of systems analyst, without ever being told what systems analysis is all about or what a systems analyst does. If you are in such a position, this book is for you. You should also find the book useful if you began working as a systems analyst in the 1970s or 1980s and never had an opportunity to learn about classical analysis methods such as structured analysis, or the newer methods such as object-oriented analysis.

More and more often today, people outside the computer profession are finding it necessary to become familiar with the field of systems analysis. If you are a business person or a manager, there isagood chance that you will be involved in a systems analysis activity. You will have systems analysts working for you, spending their time trying to understand what kind of automated system you want them to build. Similarly, if you are an administrator, a clerk, a scientist, a politician, an engineer, or an accountant — or virtually any other professional in today’s society — there is a good chance that you will spend a significant amount of time during your career interacting with systems analysts who will be designing and specifying sophisticated computer systems for you. The more you know about what these people do, and what they expect of you, the better off you will be.

Even if you have no expectation of working in a white collar job — that is, even if you expect to be an artist, a writer, a musician, or an athlete — you should know what systems analysis is all about. Citizens in every walk of life are affected by computer systems of all sorts. Even if you never intend to build a computer system or have one built for you, it is inevitable that you will be using computer systems for your banking, for your education, for your interactions with the IRS and Social Security, and for virtually every aspect of your interactions with modern society. As John Gall says in Systemantics (Gall, 1977),

No one, these days, can avoid contact with systems. Systems are everywhere: big systems, little systems, systems mechanical and electronic, and those special systems that consist of organized associations of people. In self- defense, we must learn to live with systems, to control them lest they control us. As Humpty Dumpty said to Alice (though in another context): “The question is: which is to be master — that’s all.”

To emphasize this point even more, keep in mind that the computer industry represented approximately 8% of the United States GNP in 1985; by 1990, it was expected to represent as much as 15% of the GNP. [3] Almost every product built today by American business has one or more computers embedded within it, and almost every service provided to the marketplace by American business is based on or controlled by a computer system.

A major purpose of this book is to teach you about systems analysis: what it is and how one goes about doing it. But there is more: my real purpose is to excite you, to make you so eager to begin practicing systems analysis that you will want to rush through the last pages of the book and begin working on your first project. Seymour Papert recalls in Mindstorms (Papert, 1980),

I found particular pleasure in such systems as the differential gear, which does not follow a simple linear chain of causality since the motion in the transmission shaft can be distributed in many different ways to the two wheels depending on what resistance they encounter. I remember quite vividly my excitement at discovering that a system could be lawful and completely comprehensible without being rigidly deterministic.

And as Sir Arthur Stanley Eddington said in Space, Time and Gravitation: An Outline of the General Theory (Eddington, 1987),

We have found that where science has progressed the farthest, the mind has but regained from nature that which the mind put into nature. We have found a strange footprint on the shores of the unknown. We have devised profound theories, one after another, to account for its origin. At last we have succeeded in reconstructing the creature that made the footprint. And lo! it is our own.

Another purpose of the book is to make you understand and appreciate that we live in a world of systems — and systems within systems, which are part of even larger systems. Thus, everything we do in our personal and professional lives has an impact on the various systems of which we are a part. This “systems thinking” approach is not only vital for professional systems analysts, but for all members of modern society.

Alas, this book cannot make you an experienced systems analyst, any more than a book on music theory can make you an experienced pianist. By the end of the book, you will be armed with a tremendous amount of technical information that will help you develop accurate models of complex systems, and you will know the step-by-step techniques for carrying out a systems analysis effort. But you will still need a great deal of real-world work to learn the people skills: how to interview a variety of disparate users to understand the true essence of a system; how to present the results of your systems analysis work so that everyone can see a credible estimate of the costs and benefits of developing a new system; and how to distinguish problems from symptoms. As Barry Boehm pointed out in his classic work, Software Engineering Economics (Boehm, 1981):

Each of us as individual software engineers has an opportunity to make a significant positive impact on society, simply by becoming more sensitive to the long-range human relations implications of our work, and by incorporating this sensitivity into our software designs and products.

www.yourdon.com ©2006 Ed Yourdon - rev. 051406 It takes some practice to do this well, and to learn how to balance human relations concerns with programming and quantitative economic concerns. The big thing to remember in doing so is to keep our priorities straight between programming, budgetary, and human considerations.

1.4 The organization of this book

This book is organized in four major parts, followed by a series of appendixes. Part I serves as an introduction to the entire book; it begins, in Chapter 2, with an introduction to the concept of systems and to the nature of systems analysis. In this chapter, we will see that information systems are usually composed of people, hardware, software (computer programs), procedures, data, and information. Chapter 3 describes the people who are typically involved in the development of a modern information system — the users, managers, operations personnel, members of the quality assurance group, and the like — as well as the special role and responsibilities of the systems analyst. Chapter 4 introduces two popular modeling approaches that systems analyst use: structured analysis and object-oriented modeling approaches. Chapter 5 introduces the procedures (or methodology) that the systems analyst follows when developing a system.

Even if you think you know many of these things already, there are some chapters in Part I that are important for you to read, for they set the tone for the rest of the book. Chapter 2, for example, introduces and discusses the fundamental axioms and principles that we can expect to find in all systems analysis work: the development of system models, the notion of iteration, and the notion of top-down partitioning. And Chapter 6 outlines the major issues facing systems analysts today: issues of productivity, system quality, maintainability, and strategic use of information. Finally, Chapter 7 summarizes the major changes that took place in the field of systems analysis during the tumultuous decade of the 1990s.

Part II discusses systems modeling tools in detail. Individual chapters cover the topics of dataflow diagrams (Chapter 9), object-oriented models (Chapter 10), data dictionaries (Chapter 11), process specifications (Chapter 12), and state-transition diagrams (Chapter 13). Chapters 14 and 15 discuss various other modeling tools that systems analysts use when studying a system: PERT charts, Gantt charts, flowcharts, HIPO diagrams, structure charts, and so on. As we will see, these modeling tools allow us to selectively focus on individual aspects of a system whose characteristics are important to understand: the functions that the system must perform, the data that it must keep track of, and its time-dependent behavior. Even if you never see a computer after you finish reading this book, the modeling tools in Part II will be useful in whatever you do. You will find that modeling tools can be useful to model (or describe or “picture”) virtually any kind of system: biological systems, business systems, ecosystems, manufacturing systems, political systems, material-flow systems, and so on. We live in a world of systems, and much of our daily life is spent trying to comprehend and work with the many different systems with which we come in contact; modeling tools are enormously helpful in this respect.

Part III is concerned with the process of systems analysis — that is, the steps that a systems analyst goes through when constructing a system model. Here, too, the information you learn in this part of the book will be useful regardless of your ultimate profession; but the material is definitely slanted toward the construction of automated information systems. We will see that the process, or methodology, for building a system involves the development of several different types of models, the last of which is the product or output of systems analysis. In many business organizations, this product is known by such names as a “functional specification,” or a “business requirements document,” or a “business systems design.”

www.yourdon.com ©2006 Ed Yourdon - rev. 051406 Regardless of its name, it becomes the input to the person (or people) who are responsible for actually building the system — that is, designing the overall architecture of computer hardware and software and ultimately writing and testing the computer programs.

This leads us to Part IV: life after systems analysis. We will explore the transition from systems analysis to systems design and briefly discuss the final details of programming and testing. Since most automated information systems have a lifetime of several years (and often several decades), we will also discuss the subject of maintenance in Chapter 24; but our concern will not be with maintenance programming, but rather with the maintenance of the product of systems analysis. The last chapter deals with the future: evolutionary changes in the field of systems analysis that we can expect to see during the 1990s and on into the next century.

Appendixes at the end of the book deal with separate issues that may or may not affect you when you begin working as a systems analyst. Appendix A, for example, deals with the subject of automated tools for developing systems analysis models. Appendix B discusses estimating formulas and metrics used to calculate the size, duration, and cost of a project. Appendix C discusses the economics of cost-benefit calculations. Appendix D covers the subject of walkthroughs and inspections, which are often used to review the technical products of systems analysis. Appendix E discusses interviewing and data-gathering techniques, particularly those interviews that take place between user and systems analyst. All of these have been arranged as appendixes so that experienced systems analysts can skip them easily; beginning students can turn to the appendixes whenever convenient to cover topics that will surely emerge during real-world projects.

Appendices F and G present two case studies: one is a business-oriented system, and one is a real-time system. If you are a first-time student, at the end of each chapter you should look at these case studies to see how newly learned principles can apply in real-world situations. In fact, you should read the introduction and background of each case study now so that you will be familiar with the nature of each application.

Each chapter has a number of questions and exercises to help you review what you have learned. Some exercises are labeled “Research Project,” which means that they address issues that are not covered directly in the chapter but that are relevant in the real world of systems analysis. Some of the questions are intended for classroom discussion; there are no right or wrong answers, but there are answers that are more easily defended than others! So much for introductions. Let’s get started! We will begin by talking about the nature of systems.

1. Tom DeMarco, Structured Analysis and Systems Specification. Englewood Cliffs, N.J.: Prentice-Hall, 1979, page 6. 2. John Gall, Systemantics. New York: Quadrangle/The New York Times Book Company, 1977, page xiii. 3. Barry Boehm, Software Engineering Economics. Englewood Cliffs, N.J.: Prentice- Hall, 1981. 4. Seymour Papert, Mindstorms. New York: Basic Books, 1980. 5. Edward Yourdon, Nations at Risk. Englewood Cliffs, N.J.: YOURDON Press, 1986. 6. Sir Arthur Stanley Eddington, Space, Time and Gravitation: An Outline of the General Theory. London: Cambridge University Press, 1987.

1. If you are under 30 years of age, it’s hard to imagine that you have not written a computer program; after all, virtually every school and college now teaches something about computer programming. But you may not have written a really complicated computer program. If you haven’t spent at least a month working on the same program — working 16 hours a day, dreaming about it during the remaining 8 hours of restless sleep, working several nights straight through trying to eliminate that “one last bug” from the program — then you haven’t really written a complicated computer program. And you may not have the sense that there is something exhilarating about programming. (By the way, everyone in the industry will tell you that you should not be building large, complex computer programs — and that the object of the game is to build simple, comprehensible programs. This is true: but imagine the mental energy and the sleepless nights that must have gone into the creation and development of something like the Macintosh MacPaint program, or the first version of Lotus 1-2-3.)

2. There are a variety of other career paths that you might follow, too. You might specialize in the area of telecommunications and network design; or you might concentrate on database design, or “data administration.” While most of this book assumes that you will be concerned with application systems (payroll, inventory, accounting, or real-time applications like missile guidance, telephone switching, and process control), you might also concentrate on systems programming projects — for example, compilers or operating systems. All of this is likely to represent your second or third job in the computer industry: chances are that you’ll start in the business as a junior programmer (where you will be expected to know how to write relatively simple programs, or make maintenance changes to existing programs), and then progress to senior programmer before finally being promoted to the position of systems analyst. As a systems analyst, you will be expected to have broader skills than that of a programmer: in addition to knowledge of computer hardware and software, you will be expected to be able to communicate well with noncomputer people, and you will be expected to be familiar with their business applications.

3. For more details on this, as well as other discussions of the impact of computers on society, see Nations at Risk (Yourdon, 1986).

1. Explain how systems analysis might be useful in your job or profession even if you are not planning to become a programmer or systems analyst. 2. Research Project: How many people are employed as systems analysts in the United States today? What is their average salary? What is their average level of education? 3. Research Project: Is there a shortage of programmers and systems analysts in the United States? Try to find industry surveys or government surveys (e.g., from the U.S. Commerce Department or the National Science Foundation) that predict the nation’s requirements for systems analysts over the next ten years. 4. Give ten examples of systems that you deal with or interact with in your day- to-day life. 5. Would you be studying the subject of systems analysis if you didn’t have to? If your answer is “No,” explain why you think the material won’t be useful or relevant. Find someone else studying this same material and engage in a constructive debate about the general usefulness of systems analysis. 6. Do you think it is important for non-computer people (people who do not work in the computer field as a profession) to study systems analysis? How expert do you think they should be in the subject? 7. Why is systems analysis likely to be more interesting than programming? Do you agree with this point of view? 8. What things must a systems analyst learn besides the technical skills of building system models? 9. How can modeling tools of the kind presented in this book be useful for studying non-computer systems?