Structured Analysis

Infsy 570

Dr. R. Ocker

What is structured analysis?

It focuses on specifying what the system or application is required to do.

Elements of structured analysis . Graphical description . Data Flow Diagrams . Data Dictionary: definitions of

elements in the system

What is structured Design?

Focus on the development of software specifications

Three primary modules in SDLC

(1) Analysis

(2) Design

(3) Implementation

various phases within each module

Systems Analysis

A. Objectives of System Analysis

determine if current system is in trouble

determine appropriate alternatives

make recommendation

To establish in detail what the system is to do objectives costs benefits implementation process organizational changes required defines who the USERS are Their input and output

Phase 1 Identify problems, opportunities, and objectives analyst looks at what is occurring in the

business look for problems and opportunities People involved: users, analysts, systems managers

Phase 1 Activities include: interviewing user management summarizing knowledge obtained estimating scope of project documenting results Output of this phase: feasibility study (report) containing a

problem definition and summarizing the objectives

Feasibility Study: The Basic Tasks Problem Orientation . Define the problem . Establish system objectives . Identify the users . Establish functional scope

Feasibility Study

Alternative Specification– Propose options– Cost-Benefit analysis– Assess project risk– Recommend

Feasibility Study

Technical Do we have the capability to develop the

system? Does the necessary technology exist? Does the proposed system have the

right:– response time, interface,

Can the system be expanded?

Feasibility Study

Economic Is there an economic payoff? cost of hardware/software/ other benefits in terms of reduced costs opportunity costs

Phase 2 Determining RequirementsPhase 3 Analyzing System Needs

goal - determine the requirements of the new system -- must obtain a consensus from the user community on the ideal information system

Requirements

Analyst must understand:

a. the CURRENT SYSTEM

b. what information users need to perform their jobs

c. why and how current system is no longer effective

analyst derives new system requirements from an analysis and synthesis of a,b,& c

Requirements

People involved in this phase:

analysts, users - operations managers and workers

Major steps in determining requirements for new system

1. Requirements capture and analysis The process of deriving system

requirements accomplished through observation of

existing systems, discussions with potential users and task analysis.

very time consuming step

Analyst needs to know details of current system functions who - the people who are involved what - the business activity where - the environment in which the

work occurs when - the timing of the activity how - how the current procedures are

performed

2. Requirements definition

document containing an abstract description of:

- user functions the new system is expected to provide

- constraints under which the system must operate.

only specifies the external behavior of the system - does not cover any implementation considerations.

2. Requirements definition

written without using any specialized notations so that it is understandable by non-systems professionals (e.g., potential users, system procurers).

becomes the focus for much of the work involved in developing system requirements.

3. Requirements specification

document that details the functions that the system is to include - sometimes called a functional specification

written using a formal systems specification language

more precise than the requirements definition - for use by the technical staff

3. Requirements specification

creation of this document might be carried out in parallel with some high-level design (this may be essential) as the design and requirements activities influence each other as they develop.

Tools used to determine requirements sampling and investigating hard data,

interviewing, questionnaires, observation, and prototyping

CASE tools

DFD - data flow diagram - used to chart the input, processes, and output of the business's functions in a structured graphical form

data dictionary - developed from the DFDs; lists all of the data items used in the system along with their specifications

Analysts use CASE tools to

1. Increase productivity - draw and modify diagrams easily

2. Improve analyst-user communication - same - draw and modify diagrams easily

CASE tools integrate activities within the SDLC

types of CASE

1. Upper CASE - used by analysts to create and modify system design

2. Lower CASE - used to generate computer source code

Using Data Flow Diagrams

structured approach - take a top-down approach to system development

system is defined first at a general level - overview successive refinement occurs until the bottom

(primitive) levels are defined. primitive level - point where specifications can be

translated into lines of code So...system is decomposed into small modules that

perform simple tasks

Structured Development

the systematic and integrated use of tools and techniques to aid the analysis and design of information systems

structured methodologies use one or more tools to define information flow and processes.

Structured Development

definition is from top to bottom in increasing levels of detail.

1.major flows and processes identified

2.these are exploded into subprocesses

3.subprocesses are exploded into more detail. this process can continue to the primitive

level, where programming begins directly from the exploded diagram

Structured terms

data elements - lowest level of information on which a process can act

i.e. DB attributes/record fields - e.g. unit price data stores - places where data are stored; e.g.

files; microfiche, filing cabinets data flows - represent movement of data in a

system; consist of data input and data output e.g. forms, reports, invoices, letters show movement of data about a physical “thing”

Structured terms

process specifications - definitions of how processes work

data dictionary - document containing definitions of all system data; includes data elements, data structures, data stores, data flows, and process specifications

Tools

I. Hierarchy Chart

graphic tool to represent all the tasks or processes in a system

groups them into hierarchical levels one-to-many relationship between upper

and lower levels of the chart node has single parent and >=0 children

nodes all sibling nodes have same level of detail

I. Hierarchy Chart

functional primitives - bottommost nodes; get translated into programming code

control modules - any node above the functional primitives

topmost node - always single node, ties whole system together

II. Data Flow Diagrams

DFDs - graphic representation of the flow of data through a system;

can be physical DFDs or logical DFDs

Logical DFDs shows sources and sinks (destinations) of data identifies and names the logical functions (processes)

of the system identifies and names the groups of data elements that

connect one process to another identifies the data stores each function broken down into more detailed DFD

(levels) descriptions of processes, flows, stores, elements

recorded in data dictionary

Logical DFDs

All of the above documentation comprises a logical functional specification for an existing or new system. a detailed statement of what the system

does/is to do free from physical considerations of how it

will be implemented

DFD components (Gane & Sarson Methodology) contains combinations of only four

symbols

1. External entities

also called sources or sinks people or groups of people who interact with the

current system but are not internal to the system; outside of boundary of our system square is symbol for an external entity to identity an external entity - place a unique,

lower-case alphabetic character in upper-left-hand corner of square. Then give entity a single, descriptive noun as a name.

2. Processes processes=functions actions performed on data flowing through the

system rounded rectangle - symbol for process each process is identified by a number

corresponding to the level of the process on the hierarchy chart.

each process is named with a simple verb-object pair, i.e. enter transaction

3. Data Stores

repository for data can be as simple as an in/out box or as

complex as a database open-ended rectangle - symbol of a

data store; open end on right side

3. Data Stores identified by upper-case alphabetic character

and a digit:– each data store within the same system has the

same alphabetic characters with different digits. when a process stores data data flow arrow goes into data store when process accesses data data flow arrow goes into process avoid crossed data flow lines by repeating the

data stores on the DFD as needed

4. Data flows

represents the movement of data through the system

data often moves through the system as a form or a report

solid line with arrowhead - symbol for a data flow

each data flow must be identified with a descriptive name

5. Exploding DFDs into levels

diagrams move from general to specific similar to levels in a menu-driven

system; top-level node is analogous to the main menu

Context-level

highest level in a DFD lays out sources and sinks and a single

process representing the entire system

Diagram 0. first-level explosion

contains all the options on the main menu

a leveled set of DFDs has a 1-to-1 correspondence with the levels on the hierarchy chart

Developing DFDs

Diagram 0 - explosion of context diagram may include from 3 to 9 processes ignore exception handling processes for

the first 2-3 levels of a DFD each process numbered with an integer includes major data stores and all

external entities

Creating child diagrams each process on diagram 0 can be exploded

to create a more detailed child diagram parent - process on diagram 0 that is

exploded child - resulting diagram vertical balancing - a child diagram cannot

produce output or receive input that the parent process does not also produce or receive

Creating child diagrams all data flow in or out of the parent process must

be shown flowing in or out of the child diagram child diagram given the same number as its

parent process in Diagram 0 (e.g., process 3 would explode to diagram 3)

processes on the child diagram are numbered using the parent process number, a decimal point, and a unique number for each child process

Creating child diagrams external entities - not shown on child

diagrams below Diagram 0 child diagram may include data stores not

shown on the parent process processes may or may not be exploded,

depending on level of complexity primitive process - when a process is shown

at its lowest level of detail, cannot be exploded any further

Some general rules

1.a DFD level should contain from 3-9 processes

2.data flows should not split into two or more different flows

3.all data flows must EITHER originate or terminate at a process

4.processes need to have at least one input data flow and one output data flow

Some general rules

5. each child diagram should have the same input and output data flow as the parent process

6. avoid crossing data flow lines by repeating data stores and external entities

7. do not show exception handling processes until the lower levels of the DFD

Physical DFDs vs. Logical DFDs

physical DFDs - contain both what processes are in the system and how the processes operate; show movement of things

allow us to understand how the current system works

can be restrictive in the design process

logical DFDs

contains only the minimal data that flow through the system, independent of any devices, persons, forms, or specific physical implementations;

implementation-free