The purpose of the analysis stage is to thoroughly understand the current system, including its strengths, weaknesses, processes, and data requirements. From this information, possible solutions can be generated, and a recommendation can be given to the users to continue to the design stage, or to abandon the project. Before beginning the analysis stage, it is important to review the preliminary investigation report for valuable insight into the analysis.
Every system is based on business need (goals) through business functions. Through the process of business function decomposition, these business functions are progressively reduced from high level functions to low level functions, and finally to business processes. The business processes are critical to the functioning of the system. They describe how and what is done at each step of the system, and who and what performs the process.
Work is accomplished in the system by flowing from one process to the next. A system can then be compared to a series of water pipes that flow into and out of connectors. These connectors are the processes in the system complete with who, or what performs the processes, and the water is the work flow. Constructing a diagram showing the connections of processes will help explain how the system functions. This diagram is a process flow diagram, and is one of several important tools used to understand a system. Often, instead of using a diagram, the process flow is shown using a functional decomposition format. This helps distinguish the process flow from a data flow.
For more information on functional decomposition, please refer to the preliminary investigation training module. For more information on business processes, and process flows, please attend the business process presentation.
Data flows are another critical tool used to understand a system. These diagrams are related to process flows through the use of processes, however, data diagrams also show the flow of data through the system. Understanding the flow of data in a system will permit a more thorough analysis of the data, and subsequent data modeling in the design stage. A data flow diagram is similar to the water pipe example used in the process flow diagram. However, the connectors represent processes without who, or what performs them, and the pipes represent the data that flows from one process to the next. This model also includes sinks for storing the data flow (databases), when the data flow diagram is expanded to more detail. The top, or zero level, data flow diagram is the context diagram. Using a top down methodology, the data flow diagram is progressively expanded until the processes are low level processes. From this detailed data flow diagram, a new logical design can be created by adding and removing processes. Accompanying the data flow diagram is a data dictionary which gives each of the data flow names, and describes them with the data flow elements that make up the more general data flow. At the lowest level of the data dictionary are the field descriptors which describe the data type, size, and default values of these data elements.
Top down methodology is a process of examining an item of interest globally to start, then progressively work in more detail until all of the components of the item have been inventoried. For example, using top down methodology to understand the construction of a Lego® house, begin by describing the outside look of the house. Next, take the house apart as whole rooms, and describe the look of the room without describing exactly what is in each room. The next step is to take the room apart by its walls, and describe the walls. Then, take the walls apart and describe the pieces that make up the walls. By the time this process is finished, the construction of the Lego house will be fully understood, and a new house can be built using this knowledge, and the pieces. If a different house is desired, simply add new pieces, remove others, and use the knowledge gained to put this new house together. The process of putting a new item together from the pieces is called Bottom Up Design.
An important part of the analysis stage is generate possible solutions. During the preliminary investigation, alternative solutions were generated. These were very general concepts that could be used, however, during the analysis stage, more complete solutions are looked at. These solutions do not have much detail, but have more detail than the alternatives considered in the preliminary investigation. As a result of analyzing the system, the solutions that will be considered must be plausible. The thorough understanding of the system gained in the analysis permits the alternatives to be assessed for plausibility. This process is called a Feasibility Study, and weights the benefits against the costs, both tangible (measurable) and intangible (feeling). Detailed solutions are not generated until the design stage, however the possible solutions require sufficient detail to permit them to undergo feasibility testing.
A first level data flow diagram (1-DFD) is the extent to which data flow diagrams are taken in introductory systems analysis and design. The 1-DFD uses high level business processes to describe the system, and is derived directly from the context diagram (0-DFD).
For more information on data flow diagrams, please attend the data flow diagram presentation.
While analyzing a system, its strengths and weaknesses are noted. The purpose of recording these are to make them available to the design team, who will attempt to keep the strengths, and eliminate the weaknesses. The strengths and weaknesses are often included with the process flow in functional decomposition format, as a separate column.
Recalling the purpose of the analysis stage, the recommendation will be to continue to the design stage, or stop. If, after the analysis, it is felt that the project cannot meet its objectives given the constraints placed on the project, the project should be abandoned, and reasons given. Otherwise, the recommendation should be to continue, giving the reasons why a possible solution is considered feasible.
The analysis report represents the second milestone of the project, and is presented to the user for acceptance. If accepted, the project will proceed in accordance with the recommendations. The purpose of the analysis is to thoroughly understand the system, and the report includes: