1 INTRODUCTION TO SYSTEM ANALYSIS AND DESIGN 1.1 INTRODUCTION Systems are created to solve problems.

One can think of the systems approach as an organized way of dealing with a problem. In this dynamic world, the subject System Analysis and Design (SAD), mainly deals with the software development activities. 1.2 OBJECTIVES After going through this lesson, you should be able to . define a system . explain the different phases of system development life cycle . enumerate the components of system analysis . explain the components of system designing 1.3 DEFINING A SYSTEM A collection of components that work together to realize some objectives forms a system. Basically there are three major components in every system, namely input, processing and output. Output Input Processing Fig. 1.1: Basic System Components 2 :: Computer Applications In a system the different components are connected with each other and they are interdependent. For example, human body represents a complete natural system. We are also bound by many national systems such as political system, economic system, educational system and so forth. The objective of the system demands that some

output is produced as a result of processing the suitable inputs. A well-designed system also includes an additional element referred to as control that provides a feedback to achieve desired objectives of the system. 1.4 SYSTEM LIFE CYCLE System life cycle is an organizational process of developing and maintaining systems. It helps in establishing a system project plan, because it gives overall list of processes and sub-processes required for developing a system. System development life cycle means combination of various activities. In other words we can say that various activities put together are referred as system development life cycle. In the System Analysis and Design terminology, the system development life cycle also means software development life cycle. Following are the different phases of system development life cycle: . Preliminary study . Feasibility study . Detailed system study . System analysis . System design . Coding . Testing . Implementation . Maintenance The different phases of system development life cycle is shown in Fig. 1.2 below.

System Study Maintenance Feasibility Study Software Implementation Development System Analysis Life Cycle Testing System Design Coding Fig. 1.2: Phases of System Development Life Cycle Introduction to System Analysis and Design :: 3 INTEXT QUESTIONS 1. Write True or False for the following statements. (a) A collection of components that work together to realize some objectives forms a system. (b) System life cycle is not an organizational process of developing and maintaining a system. (c) In the system analysis and design terminology the system development life cycle means software development life cycle. (d) Coding is not a step in system development life cycle. (e)

System analysis and system design are the same phase of system development life cycle. 1.5 PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE Let us now describe the different phases and related activities of system development life cycle. (a) Preliminary System Study Preliminary system study is the first stage of system development life cycle. This is a brief investigation of the system under consideration and gives a clear picture of what actually the physical system is? In practice, the initial system study involves the preparation of a System Proposal which lists the Problem Definition, Objectives of the Study, Terms of reference for Study, Constraints, Expected benefits of the new system, etc. in the light of the user requirements. The system proposal is prepared by the System Analyst (who studies the system) and places it before the user management. The management may accept the proposal and the cycle proceeds to the next stage. The management may also reject the proposal or request some modifications in the proposal. In summary, we would say that system study phase passes through the following steps: . problem identification and project initiation . background analysis . inference or findings (system proposal) (b) Feasibility Study In case the system proposal is acceptable to the management, the 4 :: Computer Applications next phase is to examine the feasibility of the system. The feasibility study is basically the test of the proposed system in the light of its workability, meeting users requirements, effective use of resources

and of course, the cost effectiveness. These are categorized as technical, operational, economic and schedule feasibility. The main goal of feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility study, the cost and benefits are estimated with greater accuracy to find the Return on Investment (ROI). This also defines the resources needed to complete the detailed investigation. The result is a feasibility report submitted to the management. This may be accepted or accepted with modifications or rejected. The system cycle proceeds only if the management accepts it. (c) Detailed System Study The detailed investigation of the system is carried out in accordance with the objectives of the proposed system. This involves detailed study of various operations performed by a system and their relationships within and outside the system. During this process, data are collected on the available files, decision points and transactions handled by the present system. Interviews, on-site observation and questionnaire are the tools used for detailed system study. Using the following steps it becomes easy to draw the exact boundary of the new system under consideration: . Keeping in view the problems and new requirements . Workout the pros and cons including new areas of the system All the data and the findings must be documented in the form of detailed data flow diagrams (DFDs), data dictionary, logical data structures and miniature specification. The main points to be discussed in this stage are: . Specification of what the new system is to accomplish based on the user requirements. . Functional hierarchy showing the functions to be performed by

the new system and their relationship with each other. . Functional network, which are similar to function hierarchy but they highlight the functions which are common to more than one procedure. . List of attributes of the entities these are the data items which need to be held about each entity (record) Introduction to System Analysis and Design :: 5 (d) System Analysis Systems analysis is a process of collecting factual data, understand the processes involved, identifying problems and recommending feasible suggestions for improving the system functioning. This involves studying the business processes, gathering operational data, understand the information flow, finding out bottlenecks and evolving solutions for overcoming the weaknesses of the system so as to achieve the organizational goals. System Analysis also includes subdividing of complex process involving the entire system, identification of data store and manual processes. The major objectives of systems analysis are to find answers for each business process: What is being done, How is it being done, Who is doing it, When is he doing it, Why is it being done and How can it be improved? It is more of a thinking process and involves the creative skills of the System Analyst. It attempts to give birth to a new efficient system that satisfies the current needs of the user and has scope for future growth within the organizational constraints. The result of this process is a logical system design. Systems analysis is an iterative process that continues until a preferred and acceptable solution emerges. (e) System Design

Based on the user requirements and the detailed analysis of the existing system, the new system must be designed. This is the phase of system designing. It is the most crucial phase in the developments of a system. The logical system design arrived at as a result of systems analysis is converted into physical system design. Normally, the design proceeds in two stages: . Preliminary or General Design . Structured or Detailed Design Preliminary or General Design: In the preliminary or general design, the features of the new system are specified. The costs of implementing these features and the benefits to be derived are estimated. If the project is still considered to be feasible, we move to the detailed design stage. Structured or Detailed Design: In the detailed design stage, computer oriented work begins in earnest. At this stage, the design of the system becomes more structured. Structure design is a blue print of a computer system solution to a given problem having the 6 :: Computer Applications same components and inter-relationships among the same components as the original problem. Input, output, databases, forms, codification schemes and processing specifications are drawn up in detail. In the design stage, the programming language and the hardware and software platform in which the new system will run are also decided. There are several tools and techniques used for describing the system design of the system. These tools and techniques are: . Flowchart .

Data flow diagram (DFD) . Data dictionary . Structured English . Decision table . Decision tree Each of the above tools for designing will be discussed in detailed in the next lesson. The system design involves: i. Defining precisely the required system output ii. Determining the data requirement for producing the output iii. Determining the medium and format of files and databases iv. Devising processing methods and use of software to produce output v. Determine the methods of data capture and data input vi. Designing Input forms vii. Designing Codification Schemes viii. Detailed manual procedures ix. Documenting the Design (f) Coding The system design needs to be implemented to make it a workable system. This demands the coding of design into computer understandable language, i.e., programming language. This is also called the programming phase in which the programmer converts the pro

Introduction to System Analysis and Design :: 7 gram specifications into computer instructions, which we refer to as programs. It is an important stage where the defined procedures are transformed into control specifications by the help of a computer language. The programs coordinate the data movements and control the entire process in a system. It is generally felt that the programs must be modular in nature. This helps in fast development, maintenance and future changes, if required. (g) Testing Before actually implementing the new system into operation, test run of the system is done for removing the bugs, if any. It important phase of a successful system. After codifying the programs of the system, a test plan should be developed and on a given set of test data. The output of the test run should the expected results. Sometimes, system testing is considered a of implementation process. Using the test data following test run are carried out: . Program test . System test Program test: When the programs have been coded, compiled and brought to working conditions, they must be individually tested with the prepared test data. Any undesirable happening must be noted and debugged (error corrections) System Test: After carrying out the program test for each of the programs of the system and errors removed, then system test is done. At this stage the test is done on actual data. The complete system is executed on the actual data. At each stage of the execution, the results or output of the system is analysed. During the a is an whole run match part

result analysis, it may be found that the outputs are not matching the expected output of the system. In such case, the errors in the particular programs are identified and are fixed and further tested for the expected output. When it is ensured that the system is running error-free, the users are called with their own actual data so that the system could be shown running as per their requirements. (h) Implementation After having the user acceptance of the new system developed, the 8 :: Computer Applications implementation phase begins. Implementation is the stage of a project during which theory is turned into practice. The major steps involved in this phase are: . Acquisition and Installation of Hardware and Software . Conversion . User Training . Documentation The hardware and the relevant software required for running the system must be made fully operational before implementation. The conversion is also one of the most critical and expensive activities in the system development life cycle. The data from the old system needs to be converted to operate in the new format of the new system. The database needs to be setup with security and recovery procedures fully defined. During this phase, all the programs of the system are loaded onto the users computer. After loading the system, training of the user

starts. Main topics of such type of training are: . How to execute the package . How to enter the data . How to process the data (processing details) . How to take out the reports After the users are trained about the computerized system, working has to shift from manual to computerized working. The process is called Changeover. The following strategies are followed for changeover of the system. (i) Direct Changeover: This is the complete replacement of the old system by the new system. It is a risky approach and requires comprehensive system testing and training. (ii) Parallel run: In parallel run both the systems, i.e., computerized and manual, are executed simultaneously for certain defined period. The same data is processed by both the systems. This strategy is less risky but more expensive because of the following: . Manual results can be compared with the results of the computerized system. Introduction to System Analysis and Design :: 9 . The operational work is doubled. . Failure of the computerized system at the early stage does not affect the working of the organization, because the manual system continues to work, as it used to do. (iii) Pilot run: In this type of run, the new system is run with the data from one or more of the previous periods for the whole or part of the system. The results are compared with the old system results. It is less expensive and risky than parallel run approach. This strategy builds the confidence and the errors are traced easily without affecting the operations.

The documentation of the system is also one of the most important activity in the system development life cycle. This ensures the continuity of the system. There are generally two types of documentation prepared for any system. These are: . User or Operator Documentation . System Documentation The user documentation is a complete description of the system from the users point of view detailing how to use or operate the system. It also includes the major error messages likely to be encountered by the users. The system documentation contains the details of system design, programs, their coding, system flow, data dictionary, process description, etc. This helps to understand the system and permit changes to be made in the existing system to satisfy new user needs. (i) Maintenance Maintenance is necessary to eliminate errors in the system during its working life and to tune the system to any variations in its working environments. It has been seen that there are always some errors found in the systems that must be noted and corrected. It also means the review of the system from time to time. The review of the system is done for: . knowing the full capabilities of the system . knowing the required changes or the additional requirements . studying the performance. If a major change to a system is needed, a new project may have to be set up to carry out the change. The new project will then proceed through all the above life cycle phases. 10 :: Computer Applications INTEXT QUESTIONS

2. Fill in the blanks. (a) System study is the _____________ stage of system development life cycle. (b) Analysis involves a ____________ study of the current system. (c) All procedures requirements must be analysed and documented in the form of data flow diagrams, data dictionary, ___________ and miniature specifications. (d) _____________ is a blue print of a computer system. (e) In ___________ run the new system installed in parts. (f) In parallel run computerized and ____________ systems are executed in parallel. 1.6 WHAT YOU HAVE LEARNT In this lesson a systematic approach to solve any given problem is explained. Phases of system such as preliminary system study, detailed system study, system analysis, design, coding, testing, implementation and maintenance are explained. Computer based systems are defined. System development life cycle is discussed in detail. The different phases of the development of system are explained in detail. 1.7 TERMINAL QUESTIONS 1. Define a system. Explain the components of a system. 2. How do you explain system development life cycle? 3. Discuss the importance of system analysis and design in the development of a system. 1.8 KEY TO INTEXT QUESTIONS 1. (A) True (b) False (c) True (d) False (e) False 2. (a) first (b) detailed (c) logical data structure (d) structure design (e) pilot (f) manual NOS : Certificate in Computer Applications

| Home | Table of Contents | Up: Online Course Material LESSON 29 Introduction to System Analysis and Design

29.1 INTRODUCTION Systems are created to solve problems. One can think of the systems approach as an organized way of dealing with a problem. In this dynamic world, The subject System Analysis and Design, mainly deals with the software development activities. 29.2 OBJECTIVES After going through this lesson, you should be able to: * * cycle * * understand a system understand the different phases of system developments life know the components of system analysis know the components of system designing

29.3 Defining A System A collection of components that work together to realize some objective forms a system. Basically there are three major components in every system, namely input, processing and output. s1.gif (1492 bytes)

In a system the different components are connected with each other and they are interdependent. For example, Human body represents a complete natural system. We are also bound by many national systems such as political system, economic system, educational system and so forth. The objective of the system demand that some output is produced as a result of processing the suitable inputs. 29.4 SYSTEM LIFE CYCLE

System life cycle is an organisational process of developing and maintaining systems. It helps in establishing a system project plan, because it gives overall list of processes and subprocesses required developing a system. System development life cycle means combination of various activities. In other words we can say that various activities put together are referred as system development life cycle. In the System Analysis and Design terminology, the system development life cycle means software development life cycle. Following are the different phases of software development cycle: * * * * * * * * System study Feasibility study System analysis System design Coding Testing Implementation Maintenance

The different phases of software development life cycle is shown in Fig.29.1 s2.gif (3376 bytes) Fig. 29.1 Different phases of Software development Life Cycle

29.5 PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE Let us now describe the different phases and the related activities of system development life cycle in detail. (a) System Study System study is the first stage of system development life cycle. This gives a clear picture of what actually the physical system is? In practice, the system study is done in two phases. In the first phase, the preliminary survey of the system is done which helps in identifying the scope of the system. The second phase of the system study is more detailed and in-depth study in which the identification of users requirement and the limitations and

problems of the present system are studied. After completing the system study, a system proposal is prepared by the System Analyst (who studies the system) and placed before the user. The proposed system contains the findings of the present system and recommendations to overcome the limitations and problems of the present system in the light of the users requirements. To describe the system study phase more analytically, we would say that system study phase passes through the following steps: * problem identification and project initiation * background analysis * inference or findings (b) Feasibility Study On the basis of result of the initial study, feasibility study takes place. The feasibility study is basically the test of the proposed system in the light of its workability, meeting users requirements, effective use of resources and .of course, the cost effectiveness. The main goal of feasibility study is not to solve the problem but to achieve the scope. In the process of feasibility study, the cost and benefits are estimated with greater accuracy. (c) System Analysis Assuming that a new system is to be developed, the next phase is system analysis. Analysis involved a detailed study of the current system, leading to specifications of a new system. Analysis is a detailed study of various operations performed by a system and their relationships within and outside the system. During analysis, data are collected on the available files, decision points and transactions handled by the present system. Interviews, on-site observation and questionnaire are the tools used for system analysis. Using the following steps it becomes easy to draw the exact boundary of the new system under consideration: * Keeping in view the problems and new requirements * Workout the pros and cons including new areas of the system All procedures, requirements must be analysed and documented in the form of detailed data flow diagrams (DFDs), data dictionary, logical data structures and miniature specifications. System Analysis also includes sub-dividing of complex process involving

the entire system, identification of data store and manual processes. The main points to be discussed in system analysis are: * Specification of what the new system is to accomplish based on the user requirements. * Functional hierarchy showing the functions to be performed by the new system and their relationship with each other. * Function network which are similar to function hierarchy but they highlight the those functions which are common to more than one procedure. * List of attributes of the entities - these are the data items which need to be held about each entity (record) (d) System Design Based on the user requirements and the detailed analysis of a new system, the new system must be designed. This is the phase of system designing. It is a most crucial phase in the development of a system. Normally, the design proceeds in two stages : * preliminary or general design * Structure or detailed design Preliminary or general design: In the preliminary or general design, the features of the new system are specified. The costs of implementing these features and the benefits to be derived are estimated. If the project is still considered to be feasible, we move to the detailed design stage. Structure or Detailed design: In the detailed design stage, computer oriented work begins in earnest. At this stage, the design of the system becomes more structured. Structure design is a blue print of a computer system solution to a given problem having the same components and inter-relationship among the same components as the original problem. Input, output and processing specifications are drawn up in detail. In the design stage, the programming language and the platform in which the new system will run are also decided. There are several tools and techniques used for designing. These tools and techniques are: * Flowchart * Data flow diagram (DFDs) * Data dictionary

* Structured English * Decision table * Decision tree Each of the above tools for designing will be discussed in detailed in the next lesson. (e) Coding After designing the new system, the whole system is required to be converted into computer understanding language. Coding the new system into computer programming language does this. It is an important stage where the defined procedure are transformed into control specifications by the help of a computer language. This is also called the programming phase in which the programmer converts the program specifications into computer instructions, which we refer as programs. The programs coordinate the data movements and control the entire process in a system. It is generally felt that the programs must be modular in nature. This helps in fast development, maintenance and future change, if required. (f) Testing Before actually implementing the new system into operations, a test run of the system is done removing all the bugs, if any. It is an important phase of a successful system. After codifying the whole programs of the system, a test plan should be developed and run on a given set of test data. The output of the test run should match the expected results. Using the test data following test run are carried out: * Unit test * System test Unit test: When the programs have been coded and compiled and brought to working conditions, they must be individually tested with the prepared test data. Any undesirable happening must be noted and debugged (error corrections). System Test: After carrying out the unit test for each of the programs of the system and when errors are removed, then system test is done. At this stage the test is done on actual data. The complete system is executed on the actual data. At each stage of the execution, the results or output of the system is analysed.

During the result analysis, it may be found that the outputs are not matching the expected out of the system. In such case, the errors in the particular programs are identified and are fixed and further tested for the expected output. When it is ensured that the system is running error-free, the users are called with their own actual data so that the system could be shown running as per their requirements. (g) Implementation After having the user acceptance of the new system developed, the implementation phase begins. Implementation is the stage of a project during which theory is turned into practice. During this phase, all the programs of the system are loaded onto the user's computer. After loading the system, training of the users starts. Main topics of such type of training are: * * * * How How How How to to to to execute the package enter the data process the data (processing details) take out the reports

After the users are trained about the computerised system, manual working has to shift from manual to computerised working. The following two strategies are followed for running the system: 1. Parallel run: In such run for a certain defined period, both the systems i.e. computerised and manual are executed in parallel. This strategy is helpful because of the following: o Manual results can be compared with the results of the computerised system. o Failure of the computerised system at the early stage, does not affect the working of the organisation, because the manual system continues to work, as it used to do. 1. Pilot run: In this type of run, the new system is installed in parts. Some part of the new system is installed first and executed successfully for considerable time period. When the results are found satisfactory then only other parts are implemented. This strategy builds the confidence and the errors are traced easily. (h) Maintenance

Maintenance is necessary to eliminate errors in the system during its working life and to tune the system to any variations in its working environment. It has been seen that there are always some errors found in the system that must be noted and corrected. It also means the review of the system from time to time. The review of the system is done for: * knowing the full capabilities of the system * knowing the required changes or the additional requirements * studying the performance If a major change to a system is needed, a new project may have to be set up to carry out the change. The new project will then proceed through all the above life cycle phases. Top 29.6 What You Have Learnt In this lesson systematic approach of any given problem is explained. Computer based systems are defined. System development life cycle is discussed in detail. The different phases of the development of system life cycle are explained in detail.

29.7 Terminal Question 1. Define a system. Explain the components of a system. 2. What do you understand by system development life cycle? 3. Discuss the importance of system analysis and design in the development of a system?

Systems Analysis & Design Introduction | Specification of Information Systems | Methodologies for Systems Development | Strategy in Analysis & Design | An Example | References My experience has shown that many people find it hard to make their design ideas precise. They are willing to express their ideas in loose, general terms, but are unwilling to express them with the precision needed to make them into patterns. Above all,

they are unwilling to express them as abstract spatial relations among well-defined spatial parts. I have also found that people aren't always very good at it; it is hard to do..... If you can't draw a diagram of it, it isn't a pattern. If you think you have a pattern, you must be able to draw a diagram of it. This is a crude, but vital rule. A pattern defines a field of spatial relations, and it must always be possible to draw a diagram for every pattern. In the diagram, each part will appear as a labeled or colored zone, and the layout of the parts expresses the relation which the pattern specifies. If you can't draw it, it isn't a pattern. Christopher Alexander (1979) in The Timeless Way of Building. One anxiety inherent in the design methods is the hierarchical nature of complexity. This anxiety moves in two directions, escalation and infinite regression. I will use a story, "The Warning of the Doorknob," to illustrate the principle of escalation. This has been my experience in Washington when I had money to give away. If I gave a contract to a designer and said, "The doorknob to my office doesn't have much imagination, much design content. Will you design me a new doorknob?" He would say "Yes," and after we establish a price he goes away. A week later he comes back and says, "Mr. Eberhard, I have been thinking about that doorknob. First we ought to ask ourselves whether a doorknob is the best way of opening and closing a door." I say, "Fine, I believe in imagination, go to it." He comes back later and says, "You know, I have been thinking about your problem, and the only reason you want a doorknob is you presume you want a door to your office. Are you sure that a door is the best way of controlling egress, exit, and privacy?" "No, I'm not sure at all." "Well, I want to worry about that problem." He comes back a week later and says, "The only reason we have to worry about the aperture problem is that you insist on having four walls around your office. Are you sure that is the best way of organizing this space for the kind of work you do as a bureaucrat?" I say, "No, I'm not sure at all." Well, this escalates until (and this has literally happened in two contracts, although not exactly through this process) our physical designer comes back with a very serious face. "Mr. Eberhard, we have to decide whether capitalistic democracy is the best way to organize our country before I can possibly attack your problem."

On the other hand is the problem of infinite regression. If this man faced with the design of the doorknob had said, "Wait. Before I worry about the doorknob, I want to study the shape of man's hand and what a man is capable of doing with it," I would say, "Fine." He would come back and say, "The more I thought about it, there's a fit problem. What I want to study first is how metal is formed, what the technologies are for making things with metal in order that I can know what the real parameters are for fitting the hand." "Fine." But then he says, "You know, I have been looking at metal forming and it all depends on metallurgical properties. I really want to spend three or four months looking at metallurgy so that I can understand the problem better." "Fine." After three months he will come back and say, "Mr. Eberhard, the more I look at metallurgy, the more I realize that it is the atomic structure that's really at the heart of this problem." And so, our physical designer is in atomic physics from the doorknob. That is one of our anxieties, the hierarchical nature of complexity. Eberhard (1970) quoted in Teague & Pidgeon (1985) and Yourdon (1989). Introduction The work of Christopher Alexander, a mathematician-turned architect, has had a subtle and yet a profound impact on the methodologies for the development of information systems in business. The main idea in architecture, espoused by Alexander, is that buildings and cities can be designed from the combination of certain basic patterns. Such patterns can be documented as diagrams which, in the architectural domain, specify spatial relationships. In the domain of business (and accounting) information systems development, the task is to create languages for describing and manipulating patterns to create systems that meet the needs of business. In this note, we shall study the way in which information systems are specified, and the methodology of Systems Development Life Cycle (SDLC) that is often used in the development of accounting information systems. Return to Contents Specification of Information Systems

Why specifications? Specification of any system before its development is crucial. Specifications perform for information systems the same function that blue-prints and engineering specifications perform for physical structures. Specifications serve as benchmarks for evaluating designs as well as their implementation. They also facilitate quality assurance via verification (are we building the system right, ie., do the design and implementation meet the specifications?) and validation ( are we building the right system, ie., does the system meet the user needs?). Components of specifications Specification of an information system is given by their * * * * Structure: How it is organised. Function: What it does. Behavior: How it responds to events and stimuli. Data: Its meaning and organization.

Most CASE tools co-ordinate information systems projects through a project or system dictionary. The function of the dictionary is to standardise the use of terms throughout the organisation and to serve as a repository of all common information in the project. It enforces consistency as well as (relative) completeness of the specifications, and facilitates verification & validation of such specifications. It also serves as a means of communication between the different persons on the information systems building team.The figure below shows the various components of the specifications and the modeling techniques utilised. We will be studying some of those techniques in this course. Return to Contents Methodologies for Systems Development There are many methodologies for the development of information systems: Systems Development Life Cycle (SDLC), Data StructureOriented design, Object-Oriented design, Prototyping, among others. We shall, however, be concerned here primarily with SDLC. Systems Development Life Cycle: Referred to variously as the waterfall model and linear cycle, this methodology is a coherent description of the steps taken in

the development of information systems. The reason why it is referred to as the waterfall model should be obvious from the following figure (from Horner, 1993): The methodology SDLC is closely linked to what has come to be known as structured systems analysis & design. It involves a series of steps to be undertaken in the development of information systems as follows: * Problem definition: On receiving a request from the user for systems development, an investigation is conducted to state the problem to be solved. o Deliverables: Problem statement. * Feasibility study: The objective here is to clearly define the scope and objectives of the systems project, and to identify alternative solutions to the problem defined earlier. o Deliverables: Feasibility report. * Systems analysis phase: The present system is investigated and its specifications documented. They should contain our understanding of HOW the present system works and WHAT it does. o Deliverables: Specifications of the present system. * Systems design phase: The specifications of the present system are studied to determine what changes will be needed to incorporate the user needs not met by the system presently. The output of this phase will consist of the specifications, which must describe both WHAT the proposed system will do and HOW it will work.of the proposed system. o Deliverables:Specifications of the proposed system. * Systems construction: Programming the system, and development of user documentation for the system as well as the programs. o Deliverables: Programs, their documentation, and user manuals. * System testing & evaluation: Testing, verification and validation of the system just built. o Deliverables: Test and evaluation results, and the system ready to be delivered to the user/client. The figure below provides an illustration for the above description. The waterfall model has many attractive features: * Clearly defined deliverables at the end of each phase, so that the client can take decisions on continuing the project. * Incremental resource committment. The client does not have to make a full committment on the project at the beginning.

* Isolation of the problem early in the process. It does, however, have some drawbacks: * Requires an all-or-nothing approach to systems development. Does not allow incremental development. * Requires very early isolation of the problem. In the real world, often the problems are uncovered in the process of development of systems. Return to Contents Strategy in Analysis & Design The understanding and management of complexity is perhaps the most important task of the designer of an information system. It is carried out bearing in mind the strategies of abstraction as well as hierarchical ordering (divide & conquer). In the real world, an accounting information systems designer (systems designer for short) is rarely called upon to analyse and design a system from the scratch. Usually, such a system does exist, but the client (user) is not quite satisfied with it. The systems designer starts with the documentation of the existing accounting system, if it does not exist. Often, documentation pertaining to the existing system is contained in the audit workpapers pertaining to the auditor's study of control risk assessment. However, since such documentation is not prepared with a view to design a system, it is used only as a starting point in building the documentation to aid systems design. In this document, we shall study how abstraction and hierarchical ordering strategies are used to manage the complexity of analysing and designing the functions of an information system. The methodology of structured systems analysis & design provides a roadmap for the development of functional specifications for an accounting information system, shown in the Figure below.

The functional specifications are documented graphically in Dataflow Diagrams (DFDs) described in the next section below. STEP 0: (Defining the scope of the system under study.) This accomplished by drawing the context diagram for the system.

STEP 1: (Documentation of how the existing system works.) This is accomplished by drawing the Physical DFDs of the existing system. These DFDs specify the current implementation of the existing system, and would answer questions such as: * * * * * Who performs the tasks? How they are performed? When or how often they are performed? How the data is stored (media)? How the dataflows are implemented (media)?

These physical DFDs may be levelled, or, if the system is not very large, prepared all on a single DFD. STEP 2: (Documentation of what the existing system does.)This is documented in Logical DFDs of the existing system. Deriving these logical DFDs of the existing system from the physical DFDs involve abstraction of all implementation details. Since the systems designer would not like to be tied down by the current implementation of the system, all such details are abstracted. These logical DFDs are usually levelled in order to reduce the perceived complexity of the system, and balanced in order to assure consistency in the design. STEP 3: (Documentation of what the proposed system will do.) After step 2, the systems designer will examine why the existing system does not meet the user requirements, and how it can be modified in order to meet such needs. The result is a set of logical DFDs which describe what the modified (proposed) system will do. These functional specifications are devoid of implementation considerations, and therefore rather abstract specifications of the proposed system. These logical DFDs are also levelled and balanced. STEP 4: (Documentation of how the proposed system will work.) The logical DFDs of the proposed system derived in step 3 above are then examined to determine which implementation of it meets the user requirements most efficiently. The result is a set of physical DFDs of the proposed system. They answer questions such as: * * * * * Who will perform the various tasks? How they will be performed? When or how often they will be performed? How the data will be stored (media)? How the dataflows will be implemented (media)?

In this step, man-machine boundaries are drawn, and media selected for all dataflows & datastores. The function of any information system can be expressed in terms of transformation (processing) of certain inputs (which are data) into outputs (which are data too) where memory (which too consists of data) may need to be consulted (or updated). This suggests that two crucial elements in a system's description are data and processing of data. A complete description of an information system demands description of both these elements. In fact, we can reduce this, in a mundane fashion to the equation: System = Data + Processing of data While it is impossible to describe an information system exclusively in terms of data or its processing, it is possible to study a system's functions (what the system must do) in terms of the transformations it must perform of the data which is modeled separately. A coherent description of the information system, however, would require that the models of data and its processing are not inconsistent. An information system's functions, which describe its processing aspects, is modeled in the structured systems approach, as dataflow diagrams.Such a model of an information system is, for obvious reasons, referred to as functional model or process model. A dataflow diagram consists of external entities (represented by rectangles), processes (represented by either rounded rectangles or circles), data stores (represented by either an open rectangle or two parallel lines) and dataflows (represented by arrows). Return to Contents An Example A Toy Sales Order Entry & Processing System: I give below the functional specifications for a toy sales order entry and processing system. The specifications given are for the logical aspects of the system only, and therefore are, incomplete. They are also incomplete in that the behavior model is absent. They are given as illustrations only. They consist of: * * * * Context diagram levelled logical dataflow diagrams Relation specifications for a Relational Database Specifications for the dataflows

* Process descriptions in raw prolog code. (Prolog is a relational language. The code is given here, since prolog code is generally easily grasped). The code given here, with very minor changes, should be executable. I will not provide the physical DFDs below, since they are implementation dependent, and I have not based this toy system on any real-world accounting system. We have yet to discuss the data models and databases. We will not be discussing programming aspects of systems. Therefore, the database specifications are given as a prelude to our class discussions on databases later in the semester. The code is given just for the purpose of appreciation. We are talking about a very small firm that considers orders from customers for one item. You should be able to add bells and whistles as you wish. The situation considered is rather unrealistic, but it makes important points about specifications for an accounting system and its documentation. Table of Contents * * * * * * * Context Diagram Level 0 Logical Dataflow Diagram Level 1 Logical DFD: Sales Order Entry Sub-system Level 1 Logical DFD: Sales Order Processing Sub-system Dataflow Specifications Datastore Specifications Process Specifications

Context Diagram: (Sales Order Entry & Processing System) Return to Table of Contents (Example) Level 0 Logical Dataflow Diagram:(Sales Order Entry & Processing System) Return to Table of Contents (Example) Level 1 Logical Dataflow Diagram:(Sales Order Entry Sub-system) Return to Table of Contents (Example) Level 1 Logical Dataflow Diagram:(Sales Order Processing Subsystem) Return to Table of Contents (Example) Dataflow Specifications

Syntax: dataflowName(attribute1, attribute2,.....) order(CustomerName, CustomerAddress, Item, Quantity) pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) weDontSell(CustomerName, CustomerAddress, Item) sorryBadCredit(CustomerName, CustomerAddress) approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) sorryNotInStock(CustomerName, CustomerAddress, Item) acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) billOfLading(CustomerName, CustomerAddress, Item, Quantity) invoice(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) Return to Table of Contents (Example) Datastore Specifications Syntax:relationName(attribute1, attribute2,......) priceList(Item, Price) customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit) inventoryMaster(Item, QuantityOnHand) salesOrderMaster(CustomerName, Item, Quantity, OrderPrice) billOfLading(CustomerName, Item, Quantity) openInvoices(CustomerName, Item, Quantity, OrderPrice) customer(CustomerName, CustomerAddress) order(CustomerName, CustomerAddress, Item, Quantity) Return to Table of Contents (Example) Process Specifications: Syntax:prolog clause /* Orders are priced by multiplying the quantity ordered by the */ /* price for the item on the price list */ pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) if order(CustomerName, CustomerAddress, Item, Quantity), priceList(Item, Price),

orderPrice is Price * Quantity. /* */ /* We don't sell the item ordered by the customer if such item is not on the price list */

weDontSell(CustomerName, CustomerAddress, Item) if order(CustomerName, CustomerAddress, Item, Quantity), not priceList(Item, _). /* A customer order for an item is approved if the order is priced */ /* and the account balance after the order is less than the credit limit */ approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) if pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice), customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit), NewBalance is Balance + OrderPrice, NewBalance < CreditLimit. /* */ /* */ /* */ A customer order is rejected on account of bad credit if the order is priced and the account balance after the order exceeds the credit limit for the customer

sorryBadCredit(CustomerName, CustomerAddress) if pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice), customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit), NewBalance is Balance + OrderPrice, NewBalance >= CreditLimit.

/* A customer order is accepted if it is approved and the quantity on */ /* hand of the item ordered is at least as much as the quantity ordered */ acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) if approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice), inventoryMaster(Item, QuantityOnHand), QuantityOnHand >= Quantity. /* A sales order is prepared if a customer order is accepted */

salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) if acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice), /* */ A bill of lading is prepared if a sales order is prepared

billOfLading(CustomerName, CustomerAddress, Item, Quantity) if salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice). /* */ An open invoice is prepared if a bill of lading is prepared

openInvoices(CustomerName, Item, Quantity, OrderPrice) if billOfLading(CustomerName, CustomerAddress, Item, Quantity). /* A customer's account is updated by adding the order price to the */ /* current balance in the account if open invoice is prepared */ updateCustomerAccountsForInvoices

if openInvoices(CustomerName, Item, Quantity, OrderPrice), retract(customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit)), NewBalance is Balance + OrderPrice, assert(customerMaster(CustomerName, CustomerAddress, NewBalance, CreditLimit)). Return to Table of Contents (Example) References Alexander, C. (1971). Notes on the Synthesis of Form, 2d ed. Cambridge, MA: Harvard University Press. Alexander, C. (1979). A Timeless Way of Building. New York, NY: Oxford University Press. Eberhard, J. (1970) "We Ought to Know the Difference", in Engineering Methods in Environmental Design and Planning, Gary T. Moore, ed. Cambridge, Mass.: MIT Press. pp.364-365. Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, pp.231-274. Horner, K. (1993). Methodology as a Productivity Tool, in Software Productivity Handbook, J. Keyes (ed), New York, NY: Windcrest/McGraw-Hill, pp.97-117. Pressman, R. (1987). Software Engineering: A Practitioner's Approach, 2d ed. New York, NY: McGraw-Hill. Teague, L and C. Pidgeon. (1985) Structured Analysis Methods for Computer Information Systems. Chicago, Ill.: Science Research Associates. Yourdon, E. (1989) Modern Structured Systems Analysis. Englewood Cliffs, NJ: Prentice Hall. Yourdon, E. (1993). A Natural Productivity in Object-Orientation, in Software Productivity Handbook, J. Keyes (ed), New York, NY: Windcrest/McGraw-Hill, pp.97-117. Return to Contents Updated on October 12, 1997 by Jagdish S. Gangolly.