Structured Analysis

What is structured analysis?

s

s s s s

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?

s s

Focus on the development of software specifications

Three primary modules in SDLC

(1) Analysis (2) Design (3) Implementation
s

various phases within each module

Systems Analysis

A. Objectives of System Analysis

s

determine if current system is in trouble determine appropriate alternatives make recommendation

To establish in detail what the system is to do

s s s s s s s

objectives costs benefits implementation process organizational changes required defines who the USERS are Their input and output

Phase 1 Identify problems, opportunities, and objectives

s

s s s

analyst looks at what is occurring in the business look for problems and opportunities People involved: users, analysts, systems managers

Phase 1
s s s s s s s

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

s s s s s

Problem Orientation . Define the problem . Establish system objectives . Identify the users . Establish functional scope

Feasibility Study
s

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

Feasibility Study
s s

s s

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
s s s s s

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

Phase 2 Determining Requirements Phase 3 Analyzing System Needs

s

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 s analyst derives new system requirements from an analysis and synthesis of a,b,& c
s

Requirements
s

People involved in this phase: analysts, users - operations managers and workers

Major steps in determining requirements for new system

1. Requirements capture and analysis

s

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

s s s

s s

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
s

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
s

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
s

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
s

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

Tools used to determine requirements

s

sampling and investigating hard data, interviewing, questionnaires, observation, and prototyping

CASE tools
s

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

s

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
s

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

s

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
s

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. s this process can continue to the primitive level, where programming begins directly from the exploded
s

Structured terms
s

s s

s s

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
s

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.
s

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

s s

I.
s

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

s

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
s

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)

s

contains combinations of only four symbols

1. External entities
s s

s s s

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-lefthand corner of square. Then give entity a single, descriptive noun as a name.

2. Processes
s s

s s

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
s s

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
s

identified by upper-case alphabetic character and a digit:

each data store within the same system has the same alphabetic characters with different digits.

s s s s s

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

4. Data flows
s

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

s s

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

s

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
s

s s

s s

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

s

s s

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

s

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

s

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

s

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
s

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