What is Systems Analysis?

Why Systems Analysis?

Knowledge is the necessary prerequisite for change. Change without knowledge leads to chaos. Effective change, that is, change which works, must be made within the context of an existing environment. The impact of change must be known or reasonably estimated in advance. The more complete our knowledge, the greater our ability to predict the impact of any change. When changing a system, be it a manual or an automated system, we must understand that system in order to be able to understand what must be changed, why the changes must be made, and the best ways in which to make those changes.

Information systems, particularly business information systems, consist of two parts: (a) data and (b) the processes which acquire and manipulate that data for the benefit of the business. The analysis aims at understanding the data and the processes, and determining how both must be changed to provide greater benefit. The changes may be to the data acquired, to the processes, or, more usually, to both. Although both must normally be changed, there are those who advocate examination of processes from which data needs are determined (process-driven analysis) and those who advocate examination of data from which processing needs are determined (data-driven analysis).

The contents of this book are predicated on the assumption that both data and processes must be analyzed concurrently. That is, data needs drive processing needs, and processing needs drive data needs; thus neither can be examined without, nor to the exclusion of, the other. This type of dual-directed analysis requires a variety of tools and techniques, some aimed at data, some at the processes, and some at both. The effective analyst must select the appropriate tools and techniques according to the task at hand.

Introduction

Most organizations must allocate roughly 40 to 60 percent of its Information systems budget for the purposes of post-implementation system maintenance and enhancement. While some of these post-implementation changes are legitimately due to business changes which could not be anticipated when the system was originally designed and implemented, the majority, perhaps 80 to 90 percent, are due to incomplete or inaccurate front-end analysis in the original project.

The typical systems development project works on the 80-20 rule: 20 percent of the time is spent in analysis and 80 percent of the time in implementation. What this rule does not recognize is that after implementation, as many, if not more, resources will be allocated to the maintenance and enhancement efforts as were allocated to the original development project itself. Aside from the analysis needed to add new functionality or to change the old, a good portion of these analytical resources must be spent in determining where the original analysis was either incomplete or, worse, faulty. In effect this effort is expended in redoing or correcting work already supposedly completed.

While it may not seem feasible or practical to spend more time in the analysis phases, doing so will save time and, more important, expense in the long run. Even if the time frame for the project is short, it is feasible and practical to make the time spent doing the analysis more productive and effective. Put a different way, it is possible to make analysts more effective by preparing them for their job with better tools and techniques.

The process of systems analysis is unfortunately not one of science, but one of art. There are no hard and fast rules which, if followed, will produce the perfect analysis, although there are many guidelines which will help produce a better analysis.

There have been many books and articles written on the subject, all claiming to hold the key. These books and articles usually represent one person's, or one group's, method of analysis, a method which worked for them and which by extension they feel will work for everyone else. Many of these methods are presented as the one true way. Unfortunately, there is no one true way; there are many ways, some good, some better--the best being those that work for the particular analyst.

There are many techniques and methodologies of work organization, which if properly understood, selected, and used, will yield the desired result of providing better control over the analysis tasks. There are frameworks for multilevel analysis and design, ones for development of integrated applications within both complex and non-complex environments, and ones which work for simple applications. There are process-driven analytical techniques and data-driven analytical techniques.

These methodologies, while they may provide structure to the analysis process and may provide forms, tables of contents, and checklists to assist the analyst, do not in most cases provide guidance in one crucial area. They assume that the analyst has the information and only needs help in structuring and documenting it. They do not explain how to get the information, and if they do, they do not explain what to do with it once it has been obtained. They describe the need for functional descriptions, but in most cases, fail to define just what a function is, or what information about the function the analyst must gather.

This book will focus on the techniques of data gathering and data evaluation--on analysis. Although analysis is normally followed directly by design, this book will not cover design. It will, however, attempt to explain what the analysis process is all about and what its goals are. It will present, in the form of lists of questions, examples, and techniques, aids which may be used in the analytical environment. These techniques may be used to examine the organizational, functional, process, and data aspects of the firm as a whole, or user applications in particular. Its aim is to provide guidelines and procedures for analysis at any organizational level, and to provide a structure for the information-gathering tasks which are necessary to build effective and efficient business systems. It is meant as a practical guide and is the result of over 20 years of work by the author as both analyst and designer.

This book will cover the various organizational areas which must be examined during the analysis process and provide a variety of methods for performing that examination. It will provide what the author hopes is a sound framework of procedures, guidelines, and detailed step-by-step tasks which can assist business analysts, systems analysts, user management, and user analysts in developing the information necessary at each phase of the analysis portion of the development life cycle.

Since all analysis needs a framework or plan for accomplishing the necessary work and since there are many frameworks or methodologies in use, this book will discuss methodology in a generalized fashion. The methodology presented is one which can be translated easily into whatever formal life cycle methodology the analyst must use. This methodological framework is provided because one must be used; however it is presented with the understanding that it is not the only valid framework and is thus only a convenience for the presentation of the rest of the material.

This is a book for both the new and the experienced analyst. Many of the techniques are well known, others are relatively new, but all are applicable to some aspect of the analyst's work. Some techniques are espoused by well known firms, but most are in the public domain. All can be used by anyone with a large number of pencils, big erasers, and lots of paper.

Since the analysis process itself differs only slightly between the manual and automated environments, it is immaterial whether the analyst reader is a data processing analyst or a business analyst. It is hoped that this book would be useful for anyone analyzing a business environment, solving a business problem, or devising a change to an existing business environment.  There are some topics where it is useful to make a distinction between the tasks undertaken to develop a new or modified automated application and those task which are undertaken to form a basis for instituting fundamental changes in the business.  For the sake of clarity we will use the term Information Systems Analysis when we are referring to the former and Business Systems Analysis when we are referring to the latter.  When the term Systems Analysis without a qualifier is used the reader can assume that the discussion refers to both types of systems analysis.

What Is a System?

Because the primary medium of the systems analyst is prose and because the intent of analysis is to examine and document, all language and terminology should be as precise as possible. This is not to say that the documentation should be pompous or stilted, but rather that all parties should agree on the meaning of what has been written. For this reason we will use the dictionary definitions as the basis for our discussion of systems, analysis, and systems analysis.

A definition

Using the dictionary definition:

A system is a "group of interacting, interrelated, or interdependent (business functions, processes, activities or) elements forming a complex whole ... a functionally related group of (business functions, processes, activities or) elements, for instance, a network of structures and channels, as for communications, travel, or distribution." (The American Heritage Dictionary, Second College Edition)

"The state or condition of harmonious, orderly interaction."

"A method; procedure."

"To formulate into or reduce to a system."

As with many business terms, the word "system" has many meanings. It means different things in different contexts. In many cases, when two people discuss a system they may be referring to different things. This is especially true when a systems analyst and a user get together. To one the system is that which resides in the computer center and consists of programs and files being processed in an automated fashion. To the other, the system is a complex of procedures, work flows, and tasks which are performed to accomplish the requirements of the business.

To the systems analyst, the system's files are tapes and disks; to the user they are papers, folders, and drawers. Even when the user and the analyst agree that the system is the automated version, their perspectives may be entirely different. To the systems analyst it consists of jobs, programs, files, and software; those things which reside in the machine. To the user the system is what appears on a report or on a computer terminal screen (Figure 1.1).

For the purposes of systems analysis, a system is a business system that is described and viewed from the user's perspective, using the user's words and the user's definitions and understandings of the meaning of those words. This, of course, implies that we as analysts must understand the user's perspective. We must also understand the user's words and the meanings which the user attributes to those words. Simply said, we must speak the language of the user, and we must, at least partially, think like a user. We must be able to "walk in the user's shoes, and sit at the user's table."

This is critical to the establishment of communication between user and analyst and to the success of the analysis project. It is certainly critical to the analyst in the accumulation of that elusive body of facts known as "business knowledge." By extension, this establishment of communication with the user is a major part of the analyst's job in acquiring business knowledge and business understanding.

What Is a Systems Analyst?

A definition

In the same dictionary, analysis is defined as:

"The separation of an intellectual or substantial whole into its constituent parts for individual study." (The American Heritage Dictionary, Second College Edition)

"The stated findings of such a separation or determination."

A definition

A systems analyst by extension is: "One who engages in the study of, and separation of, a group of interacting, interrelated, or interdependent (business functions, processes, activities or) elements forming a complex whole into its constituent parts for individual study."

The Roles of the Systems Analyst

It is as difficult to define a single role for the systems analyst as it is to define a single activity which personifies the title. This is because at various times the analyst will play some or all of the following roles.

Reporter. A reporter, regardless of the medium, is a journalist whose primary task is to write, as objectively as possible, about the details and facts of an event of interest.

Detective. A detective, whether official or private, is one whose primary task is to uncover the facts of an event and to determine responsibility for the event.

Consultant. A consultant is one whose task is to provide assistance to a client in the form of services, advice, or guidance about a specific client-related task.

Diagnostician. A diagnostician is one whose primary task is to examine the facts of an event or problem presented, and, based upon past experience or research, determine the underlying cause for that problem or event.

Investigator. An investigator is similar in nature to a detective, except the scope of event under examination may be narrower, and an investigator is usually not responsible for determining responsibility.

Organizer. An organizer is one who must provide sequence and order to activities and events, and must assume responsibility for the proper execution of those activities and events.

Puzzle solver. The puzzle solver is one who either puts things together from component pieces or determines solutions from clues and hints.

Evaluator. An evaluator is one who tests, rates, or evaluates facts for accuracy, completeness, or correctness and assigns various relative weights to them.

Simplifier. A simplifier is one who looks at complex objects, events, or environments and breaks them down into less complex units. May also be one who provides easy-to-understand explanations for complex problems.

Indian scout. An Indian scout is one who is usually the first on the scene and who looks for hidden dangers or for the correct path through the wilderness (of the corporate environment). The Indian scout may also be the first one to find hidden dangers and may draw the first fire.

Artist. An artist is one who interprets events and environments and extracts their hidden meaning. The artist may also portray things as they are, as they seem to be, or as one wishes them to be. The artist may not necessarily work from existent reality but may form a picture of the desired reality.

Sculptor. A sculptor is an artist who works with a physical medium drawing meaningful form from raw materials or in some cases from worthless materials.

Concerns of the Systems Analyst

Analysts are key members of the development team. They are the ones who determine scope, direction, approach, and in many cases duration. Although the development team as a whole may have an administrative manager who will be responsible for the entire project, including those non-analytical portions such as implementation and testing, personnel and resource allocation, schedule adherence, status report preparation, and in some cases making presentations, it is analysts who run the team during the initial phases and who direct the activities through the final detail design and specification process.

Specifically the analysts may have responsibility for any one or all of the following.

1. Guiding the activities of the development team during its formative phases<
2. Developing in-depth "business knowledge"
3. Understanding the user's problems from the user's viewpoint
4. Identifying and defining the business problems
5. Developing a business orientation to understand the concerns and problems of the user
6. Developing practical, cost-effective business solutions for user problems
7. Identifying, evaluating, and recommending alternatives for design and implementation
8. Identifying and obtaining resolution for all outstanding functional and user-related problems and issues which face both the user and developer prior to implementation
9. Identifying all areas where additional research is needed, performing that research, and documenting the results
10. Ensuring that the development team maintains an objective approach to the project
11. Developing clear and accurate documentation
12. Communicating the identified user's needs to the development staff in the form of clear problem definitions and accurate specifications
13. Preparing reports and presentations for user and developer management.
14. Ensuring that the organization's standards and procedures are followed during life cycle of the project
15. Ensuring that any deliverables are up to professional and industry standards

Information Systems Analysis as a Task of Data Processing

Most firms of any size process large volumes of information. The larger the firm, the more voluminous and complex the information it processes. That information is the lifeblood of most firms. Many firms, especially in the financial service sectors of the economy, are 100 percent information processors. Many of these firms are highly automated and could not exist for more than a day without computers. Whole industries are so automated that without computers they would cease to exist.

Because of this dependence on automated processing, most business systems are a combination of manual and automated activities, with the emphasis on the automated part. The rise in popularity, accessibility and capability of personal computers and their almost geometric increase in power and capacity, have made it economical to automate even small, limited scope tasks.

For these reasons, in most organizations, systems analysis activities are no longer solely a function of the data processing organization. While the job title systems analyst is a data processing job title, and systems analysis is performed as a part of the data processing application development activity it is performed by members of many other parts of the organization as well. Regardless of where they report, systems analysts must have a data processing orientation.

Typically, the data processing organization within most firms acts as a provider of automation support services, rather than as developer or producer of the products and/or services of the firm. Although the term data processing originally included work in both the manual and automated environments, today its role is to develop, install, maintain, and operate automated, or semi-automated, centrally built and maintained processing systems.  In today’s environment data processing tends to refer to the centralized mainframe support organization, although almost anyone with a personal computer can technically be considered a data processor.

In many firms systems and operations functions are combined under one senior executive. These automated systems assist the clerical, financial, and record-keeping operations of the firm; in many instances, they replace them.  This distinction between automated and manual systems, between centralized processing and local/personal processing however is blurring as the use of personal computers, becomes more and more widespread, and more and more a part of the business activities of the firm.

For the most part, early automated systems were oriented to the administrative functions of the firm, although as the level of automation of these functions has increased, the focus of the data processing staff has shifted to systems which assist the operational functions. Today it is hard to find an area of the firm which is not serviced by some level of automation.

Systems projects have been categorized in many ways: by size, by type, by scope, and by function. In order to understand the function of analysis, one must understand the variety of perspectives within which the analysis is performed.

Information Systems Projects Categorized by Scope

Information Systems development projects can be categorized by scope into (a) those which are usually sponsored by a single user and focus on a single application or group of applications and (b) those which are more global, integrated systems development projects covering multiple functional areas of the firm as well as multiple processing streams. These projects may also cover management information systems (MIS), decision support systems (DSS), management support systems (MSS), Business Process Reengineering, System Modernization, etc..

The former type of project is usually instigated by a user request for service, a user-recognized problem, or at times by a proposal by the data processing area in response to an analysis which uncovered either a problem or an opportunity for automation. The latter is usually begun as part of some strategic initiative of the firm's senior management, again, either from a user or from data processing.

In terms of scope and size, the former usually have a limited duration, anywhere from 6 months to 2 years. The latter have a much longer duration, sometimes extending to 3 and 5 years. These differences in levels of duration reflect the size and scope of the two different types of projects, in terms of both the analytical and the implementation efforts.

Business Systems Projects As A Method Of Organizational Change

Business systems analysis projects come in many forms, many sizes, may be initiated for a wide variety of reasons, and may be designed to achieve a wide variety of goals.  In today’s business environment, with many firms struggling to maintain their competitive edge, or in some cases to achieve one, the catch-words are business process reengineering, continuous improvement, system modernization, reinventing the business, and corporate restructuring.  These activities all have at their heart some form of business process analysis, and all use accepted tools and techniques of the system analyst.  They differ from traditional information systems analysis in that their goal is not necessarily to build a new automated system, but rather to develop a blueprint under which system development and maintenance projects will be initiated.

There are two different approaches used by firms to achieve change in the way they do business and to achieve greater efficiency and productivity.  The first is characterized by radical changes with extensive impact on current operations, the second is characterized by more evolutionary or gradual changes usually with low impact on current operations.  In most cases a firm will use one or the other of the approaches, in rare cases a firm will attempt both.  One of these approaches - popularized as Business Process Reengineering (BPR) is a method for achieving radical change in the organization.  The other approach - popularized as either Total Quality Management (TQM) or Continuous Improvement (CI) is a method for achieving gradual change within the organization.

Business Process Reengineering

Business Process Reengineering relies heavily on the development of data and process models and on Computer-Aided Software Engineering (CASE) tools to build and maintain those models.  Business Process Reengineering projects tend to be very large, long term, firm-wide and top-down.  That is they begin with the firm’s senior management, or in some cases its Board of Directors,  who determine what new directions the firm should take, what products and services to initiate or discontinue, what shape the firm’s management structure will assume, and what responsibilities each senior manager will have.

BPR projects are often conducted by teams of outside consultants who specialize in performing those studies.  These consultants may be assisted by representatives from the firm who provide information and assistance during the Current System Analysis phase.  However since the goal of BPR is radical change, current operation knowledge is rarely sought during the subsequent phases.

Business Process Reengineering has also been called Business Restructuring, and Reinventing The Business.

A Definition

Computer Aided Software Engineering (CASE) products, also called Computer Aided Systems Engineering, Computer Assisted Software Engineering and Computer Assisted Systems Engineering. CASE products are collections of software tools assembled by a vendor to help the analyst, designer and developer:

1. to produce diagrams and models
2. to analyze component relationships>
3. to produce code
4. to manage component and model versions
5. to produce reports
6. to document the results of their analysis and design in narrative form.

A CASE product can consist of a single tool or it can consist of several tools.  Each tool produces a different type of model, or performs a different service or function within the suite.  CASE products may contain one or more of the following:

1. organization chart tools
2. calendaring tools
3. communications tools for file transfer between sites and between work stations
4. electronic mail tools
5. process and data modeling tools
6. a facility for storing information developed during the modeling process - usually called a Dictionary or an Encyclopedia
7. a word processing tool
8. a graphic printing tool
9. a presentation production tool
10. automatic source code generation tools
11. database code generation tools
12. a project management and planning tool
13. testing tools
14. tools to measure, collect, analyze and report project statistics
15. tools to capture design logic from existing application code

The above is only a partial list of currently available tools..  Many CASE products contain tools which are limited in function and are design to support a specific analysis design or development life cycle activity.  Those that offer support for  a greater range of life cycle activities, and do not always easily pass information between themselves.  For instance the data modeling tool may not share data with the process modeling tool, although both may share data with the reporting and graphics tool. 

Specific CASE tools and tool use will be discussed in more detail in later chapters.

A Definition

Integrated CASE (I-CASE) products are designed to allow the tools contained within them to communicate with each other and to transfer analysis, design and development data between them.  Thus the data modeling tool may share data with the process modeling tool and both will share data with the code generation tools.  the measurement tools may collect data from both and both may support the testing tools.

Rarely however,  will one CASE product permit and facilitate the transfer of data from its storage facility to that of another CASE product.  Thus once a design is begin in one CASE too it is difficult or in some cases impossible to transfer that design information to another CASE product with completely reentering all the information

Total Quality Management

A major component of most quality programs is the emphasis on both internal and external process improvement projects. Each project is normally highly focused, usually on a single process, or a single problem, and normally has a narrow set of goals.  Most continuous improvement projects follow a fixed set of steps and employ a standard set of tools.  Improvement projects stress metrics before, during, and after project activities begin to measure the effectiveness of the solution.

A Definition

Metric - a standard of measurement.   The term is most often used to identify  things that will be measured rather than the measurement process or the individual readings or points.  Some examples of metric might be:  lines of code, number of phone calls, number of resignations, or number of tests.

Internal process improvement projects focus on administrative, overhead and production floor processes. External operations and processes activities stress attention to customer satisfaction and focus on improvements in performance or activities that provide a positive benefit to customer service.

Quality projects work within the existing business processing framework to improve how specific processes work, to make them more efficient, more responsive, or to eliminate a known problem, a known bottleneck or unnecessary complexity in the process.  In some cases the process itself will be eliminated.  Continuous improvement projects normally focus on a single process, a single activity, or a single problem.  Continuous Improvement projects are of short duration

Quality projects are conducted at all levels within the firm, concurrently and by existing staff.

The Physician's Analogy

Regardless of their method of initiation, all projects must begin with the process of systems analysis. Systems analysis for a development project is similar in many ways to a case history developed by the physician when a new patient, or a patient who hasn't been seen in a while, comes in with a problem, or just for a routine checkup. This case history serves as the basis for the subsequent examination, diagnosis, and treatment.

The physician must be sure that the patient's history is taken in complete detail, including any known or suspected problems, habits, lifestyle, and other medically related information.

To develop a "case history" analysts must systematically and thoroughly document the "case history" of the current user environment, including the development of a dictionary or glossary of terminology and definitions as it has been presented to them and as they understand it. This documentation, which represents a view of the current user environment, when validated and agreed to by the user as accurate, constitutes the foundation for the next and all succeeding phases of both the analysis and design, and the implementation phases.

Just as the physician follows taking the case history with his or her own examination, so too the second process of systems development processes comprises a review, examination, and analysis of the findings and documentation collected during the first phase.

This review concentrates on making determinations, recommendations, and suggestions as to: