Tools in Structured Analysis

Data Flow Diagram

a modeling tool that use to describe transformation of inputs into outputs

A Data Flow Diagram (DFD) is a process-oriented graphical representation of an application system. In the words of Hoffer, George and Valacich (1999), a DFD "is a picture of the movement of data between external entities and the processes and data stores within a system." The components of a typical dataflow diagram are: the process, the flow, the data store, and the terminator. 1. Flows are shown by curved , directed arrows. They are the connections between the process (system functions) and they are represent the information that the processes require as input and or the information they generate as output 2. Data Stores are shown by 2 parallel lines or by an ellipse They show collections aggregates of data that the system must remember for a period of time. 3. Terminators show the external entities with which the system communicates. Terminators are typically groups of individuals, groups of people (e.g., another dept of division within the org), external computer systems and external org.
ORDER DETAILS ORDER ORDER INQUIRY

1. ENTER ORDERS

ORDERS

2. RESPOND TO INQUIRY
RESPONSE

ACKNOWLEDGMENT

A DFD showing processes, flows, and a data store A flow from a store is normally interpreted as a read or an access to information in a data store. The data store is not changed when a packet of information moves from the store along the flow. A flow to a store is normally described as a write, an update, or possibly a delete. The data store is changed as a result of the flow entering the store.

Prepared by FAJR 2011

ORDERS

CUSTOMERS INVOICES

A typical DFD

The Entity-Relationship Diagram

is a model that identifies the concepts or entities that exist in a system and the relationships between those entities. An ERD is often used as a way to visualize a relational database: each entity represents a database table, and the relationship lines represent the keys in one table that point to specific records in related tables Components of ERD 1. Object Types are show by a rectangular box on the ERD. An object type represents a collection or set or objects(things in the real world whose member play a role in a system being developed, can be identified uniquely, and can be described by one or more facts (attributes) 2. Relationships are shown by the diamond shaped boxes on the diagram. A relationship represents a set of connections or associations, between the object types connected by arrows to the relationship. 3. Associative object type indicators 4. Supertype/subtype indicators

Prepared by FAJR 2011

CUSTOMER

places

receive s

ORDER

ORDER

specifi es

BOOK

An Entity-Relationship Diagram

Prepared by FAJR 2011

State Transition Diagram (STD)

modelling tool that use to describe a systems behavior, emphasizes the time-dependent behavior of the system The major components of the diagram are states and arrows representing state changes. The state-transition diagram is a powerful modeling tool for describing the required behavior of real-time systems, as well as the human interface portion of many on-line systems. Though it is not as widely known or used in the development of business-oriented information systems, it is a tool that you should become familiar with, because, in the future, we can expect that more and more systems, whether business-oriented or scientific/engineering in nature, will take on real-time overtones.

A typical State Transition Diagram (This diagram shows the behavior of a typical telephone answering machine.)

Prepared by FAJR 2011

Structure Chart

A Structure Chart

A Structure Chart (SC) is a chart, which shows the breakdown of the configuration system to the lowest manageable levels. This chart is used in structured programming to arrange the program modules in a tree structure. Each module is represented by a box, which contains the module's name. The tree structure visualizes the relationships between the modules.

Prepared by FAJR 2011

Project Life Cycle

refers to a logical sequence of activities to accomplish the projects goals or objectives. Primary objectives: To define the activities to be carried out in the systems development project To introduce consistency among many systems development projects in the same organization To provide checkpoints for management control for go/no-go decisions 1. The Classical Project Life Cycle every project goes through some kind of systems analysis,design and implementation even if its not done in exactly the same way shown in the diagram. a strong tendency toward bottom up implementation of the system and an insistence on linear, sequential regression from one phase to the next.

Prepared by FAJR 2011

Bottom Up implementation the use of bottom up implementation is one of the major weaknesses in the classical project life cycle. This is also known in computer industry as Waterfall Life Cycle.

Prepared by FAJR 2011

Serious Difficulties in bottom up Implementation: a. Nothing is done until it is done b. The most trivial bugs are found at the beginning of the testing period and the most serious bugs are found last. c. Debugging tends to be extremely difficult during the final stages of system testing Sequential Progression - The second major weakness with the classical project life cycle is its insistence that the phases proceed sequentially from one to the next. There is a natural, human tendency to want this to be so: We want to be able to say that we have finished the systems analysis phase and that well never have to worry about that phase again. Indeed, many organizations formalize this notion with a ritual known as freezing the specification or freezing the design document.

2. The Semistructured Life Cycle

Prepared by FAJR 2011

It shows two obvious features not present in the classical approach: The bottom sequence he bottom-up sequence of coding, module testing, and system testing is replaced by top-down implementation, an approach where highlevel modules are coded and tested first, followed by the lower-level, detailed modules. There is also a strong indication that structured programming is to be used as the method of actually coding the system. Classical design is replaced by structured design

The Structured Project Life Cycle Prepared by FAJR 2011

It has nine activities and three terminators. The terminators consist of: users, managers, and operations personnel

9 ACTIVITIES: ACTIVITY 1: The Survey

This activity is also known as the feasibility study or initial business study. Typically, it begins when a user requests that one or more portions of his or her business be automated.
ACTIVITY 2: Systems Analysis

The primary purpose of the analysis activity is to transform its two major inputs, user policy and project charter, into a structured specification. This involves modeling the users environment with dataflow diagrams, entity-relationship diagrams, state-transition diagrams, and the other tools
ACTIVITY 3: Design

The activity of design is concerned with allocating portions of the specification (otherwise known as the essential model) to appropriate processors (CPUs and/or humans) and to appropriate tasks (or jobs, or partitions, etc.) within each processor.

Prepared by FAJR 2011

ACTIVITY 4: Implementation

This activity includes both coding and the integration of modules into a progressively more complete skeleton of the ultimate system. Thus, Activity 4 includes both structured programming and top-down implementation.
ACTIVITY 5: Acceptance Test Generation

The structured specification should contain all the information necessary to define an acceptable system from the users point of view. Thus, once the specification has been generated, work can commence on the activity of generating a set of acceptance test cases from the structured specification.
ACTIVITY 6: Quality Assurance

Quality assurance is also known as final testing or acceptance testing. This activity requires, as its input, acceptance test data generated in Activity 5 and an integrated system produced by Activity 4.
ACTIVITY 7: Procedure Description

Throughout this book, we concern ourselves with the development of an entire system -not just the automated portion, but also the portion to be carried out by people. Thus, one of the important activities to be performed is the generation of a formal description of those portions of the new system that will be manual, as well as a description of how the users actually will interact with the automated portion of the new system. The output of Activity 7 is a users manual.
ACTIVITY 8: Database Conversion

In some projects, database conversion involved more work (and more strategic planning) than did the development of computer programs for the new system; in other cases, there might not have been any existing database to convert. In the general case, this activity requires, as input, the users current database, as well as the design specification produced by Activity 3.
ACTIVITY 9: Installation

The final activity, of course, is installation; its inputs are the users manual produced by Actvity 7, the converted database produced by Activity 8, and the accepted system produced by Activity 6

Prepared by FAJR 2011