System Analysis
What do you understand by System Analysis? And discuss the techniques of System Analysis?
OR
What are the different tools for the System Analysis?
Ans.: Following tools are used for system analysis :
(1) Entity – Relationship Diagrams : The object-relationship pair can be represented graphically using an ER diagram. An entity represents an object. Examples: a computer, an employee, a song, a mathematical theorem. Entities are represented as rectangles.
A relationship captures how two or more entities are related to one another. Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song. Relationships are represented as diamonds, connected by lines to each of the entities in the relationship.
Entities and relationships can both have attributes. Examples: an employee entity might have an employee ID number attribute; the proved relationship may have a date attribute. Attributes are represented as ellipses connected to their entity by a line.
2) Structured English : Structured English, as the name implies, is ―English with structure.‖ That is, it is a subset of the full English language with some major restrictions on the kind of sentences that can be used and the manner in which sentences can be put together. It is also known by such names as PDL (Program Design Language) and PSL (Problem Statement Language or Problem Specification Language). Its purpose is to strike a reasonable balance between the precision of a formal programming
language and the casual informality and readability of the English language.
In Structured English you can use simple verbs from a small set of action-oriented verbs such as:
GET (or ACCEPT or READ)
PUT (or DISPLAY or WRITE)
FIND (or SEARCH or LOCATE)
ADD
SUBTRACT
MULTIPLY
DIVIDE
Most organizations find that 40 to 50 verbs are sufficient to describe any policy in any process specification.
(3) Decision Tables : There are situations where structured English is not appropriate for writing process specifications. This is particularly true if the process must produce some output or take some actions based on complex decisions. If the decisions are based on several different variables (e.g., input data elements), and if those variables can take on many different values, then the logic expressed by structured English or pre/post conditions is likely to be so complex that the user won‘t understand it. A decision table is likely to be the preferred approach.
As shown in Figure, a decision table is created by listing all the relevant variables (sometimes known as conditions or inputs) and all the relevant actions on the left side of the table; note that the variables and actions have been conveniently separated by a heavy horizontal line. In this example, each variable is a logical variable, meaning that it can take on the value of true or false.
In many applications, it is easy (and preferable) to express the variables as binary (true-false) variables, but decision tables can also be built from multivalued variables; for example, one could build a decision table with a variable called ―customer-age‖ whose relevant values are ―less than 10,‖ ―between 10 and 30,‖ and ―greater than 30.‖
Next, every possible combination of values of the variables is listed in a separate column; each column is typically called a rule. A rule describes the action (or actions) that should be carried out for a specific combination of values of the variables. At least one action needs to be specified for each rule (i.e., for each vertical column in the decision table).
(4) Data Dictionary : A data dictionary is a structured repository of data, about data. In other words it is set of precise and accurate definitions of all DFDs, data elements and data structures.
There are three main items present in a data dictionary :
i) Data Item : It is the smallest unit of data and cannot be decomposed further.
ii) Data Structures : It is a group of elements handled as a unit. A data structure contains a number of data elements as its fields,
iii) Data Flows and Data Stored : Data flows are nothing but data structure in motion where the data stores are data structures at rest.
Data Dictionary Notation : There are many common notational schemes used by systems analyst. The one shown below is the more common, and it uses a number of simple symbols:
= is composed of
+ and
( ) optional (may be present or absent)
{ } iteration
[ ] select one of several alternative choices
** comment
@ identifier (key field) for a store
| separates alternative choices in the [ ] construct
As an example, we might define name as follows :
name = courtesy-title + first-name + (middle-name) + last-name
courtesy-title = [Mr. | Miss | Mrs. | Ms. | Dr. | Professor]
first-name = {legal-character}
middle-name = {legal-character}
last-name = {legal-character}
legal-character = [A-Z|a-z|0-9|'|-| | ]
(5) Decision Tree : Decision trees are graphical representation methods of representing sequences of logical decisions. When initial decision guided the next, when and then next one. This can be done with Decision Tree.
In decision analysis, a decision tree (or tree diagram) is a decision support tool that uses a graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. A decision tree is used to identify the strategy most likely to reach a goal. Another use of trees is as descriptive means for calculating conditional probabilities.
(6) Flow Charts : The flowchart is a means of graphical representation of the flow of data through an information processing system, the operations performed within the system and the sequence in which they are performed. A programmer prefers to draw a flowchart prior to writing a computer program. As in the case of the drawing of a blueprint, the flowchart is drawn according to defined rules and using standard flowchart symbols.
“A flowchart is a diagrammatic representation that illustrates the sequence of operations to be performed to get the solution of a problem. “
Guidelines for Drawing a Flow Chart : Flowcharts are usually drawn using some standard symbols; however, some special symbols can also be developed when required. Some standard symbols, which are frequently, required for flowchart for many computer programs are as follows :
Advantages of Using Flowcharts :
i) Communication : Flowcharts are better ways of communicating the logic of a system to all concerned.
ii) Effective Analysis : With the help of flowchart, problems can be analyzed in more effective way.
iii) Proper Documentation : Program flowcharts serve as a good program documentation, which is needed for various purposes.
iv) Efficient Coding : The flowcharts act as a guide or blueprint during the systems analysis and program development phase.
v) Proper Debugging : The flowchart helps in debugging process.
vi) Efficient Program Maintenance : The maintenance of operating program becomes easy with the help of flowchart. It helps the programmer to put efforts more efficiently on that part.
Limitations of Using Flowcharts :
i) Complex Logic : Sometimes, the program logic is quite complicated. In that case, flowchart becomes complex and clumsy.
ii) Alterations and Modifications : If alterations are required the flowchart may require re-drawing completely.
iii) Reproduction : As the flowchart symbols cannot be typed, reproduction of flowchart becomes a problem.
iv) The essentials of what is done can easily be lost in the technical details of how it is done.
(7) Data Flow Diagram : DFD is graphical modeling tool for structured analysis. The dataflow diagram is a modeling tool that allows us to picture a system as a network of functional processes, connected to one another by ―pipelines‖ and ―holding tanks‖ of data. Following terms are used as synonyms for dataflow diagram : Bubble Chart DFD (the abbreviation we will use throughout this book) Bubble Diagram Process Model (or Business Process Model) Business Flow Model Work Flow Diagram Function Model A picture of what‘s going on around here
The dataflow diagram is one of the most commonly used systems-modeling tool, particularly for operational systems in which the functions of the system are of paramount importance and more complex than the data that the system manipulates.
The Components of a DFD : Following diagram shows a typical DFD for a small system. Before we examine its components in detail, notice several things: -
A Typical DFD has following features : It hardly needs to be explained at all; The diagram fits easily onto one page. The diagram has been drawn by a computer.
The Process : The first component of the DFD is known as a process. Common synonyms are a bubble, a function, or a transformation. The process shows a part of the system that transforms inputs into outputs; that is, it shows how one or more inputs are changed into outputs. The process is represented graphically as a circle, oval or a rectangle with rounded edges, or rectangle,
The Flow : A flow is represented graphically by an arrow into or out of a process; The flow is used to describe the movement of chunks, or packets of information from one part of the system to another part. Thus, the flows represent data in motion, whereas the stores represent data at rest.
The name represents the meaning of the packet that moves along the flow. A corollary of this is that the flow carries only one type of packet, as indicated by the flow name. It is sometimes useful to consolidate several elementary dataflows into a consolidated flow.
The Store : The store is used to model a collection of data packets at rest. The notation for a store is two parallel lines or a rectangle open with one side.; Typically, the name chosen to identify the store is the plural of the name of the packets that are carried by flows into and out of the store.
We can to exclude the issues and model only the essential requirements of the system.
As we have seen in the examples thus far, stores are connected by flows to processes. Thus, the context in which a store is shown in a DFD is one (or both) of the following : A flow from a store A flow to a store
In most cases, the flows will be labeled. While some of the procedural questions can thus be answered by looking carefully at the labels attached to a flow, not all the details will be evident.
A flow from store is often described as a read.
A flow to a store is often described as a write, an update, or possibly a delete.
In all these cases, it is evident that the store is changed as a result of the flow entering the store. It is the process (or processes) connected to the other end of the flow that is responsible for making the change to the store.
The Terminator : The next component of the DFD is a terminator; it is graphically represented as a rectangle, Terminators represent external entities with which the system communicates. Typically, a terminator is a person or a group of people, for example, an outside organization or government agency, or a group or department that is within the same company or organization, but outside the control of the system being modeled. In some cases, a terminator may be another system, for example, some other computer system with which your system will communicate.
Guidelines for constructing DFDs : The guidelines include the following :
i) Choosing Meaningful Names for Processes, Flows, Stores and Terminators : As we have already seen, a process in a DFD may represent a function that is being carried out, or it may indicate how the function is being carried out, by identifying the person, group, or mechanism involved. A good discipline to use for process names is a verb and an object.
ii) Number the Processes : As a convenient way of referencing the processes in a DFD, most systems analysts number each bubble. It doesn‘t matter how much you go about doing this — left to right, top to bottom, or any other convenient pattern will do -- as long as you are consistent in how you apply the numbers.
iv) Avoid Overly Complex DFDs : The purpose of a DFD is to accurately model the functions that a system has to carry out and the interactions between those functions. But another purpose of the DFD is to be read and understood, not only by the systems analyst who constructed the model, but by the users who are the experts in the subject matter. This means that the DFD should be readily understood, easily absorbed, and pleasing to the eye. Redraw the DFD As Many Times As Necessary : In a real-world systems analysis project, DFD will have to be drawn, redrawn, and redrawn again, often as many as ten times or more, before it is (1) technically correct, (2) acceptable to the user, and (3) neatly enough drawn that you wouldn‘t be embarrassed to show it to the board of directors in your organization.
