SAaM2011

A Seven Step Methodology

(with Case Study)
for
Systems Analysis

Fundamental
Custodial Data Access D Fundamental External Response I
Stimulus A Activity
Activity
B D

External Entity
Data Store Mixed Data Access Q External Entity
BB Custodial
Response G S Stimulus X BB

Fundamental Stimulus J
Activity Mixed
Stimulus W
V Activity
Custodial Response P External
E Response K
External Response X Custodial Response O
External Entity
CC Custodial
Data Access Y Mixed Data Access N External Entity
Data Store
AA
T

Custodial Custodial Fundamental

Activity Response H
Stimulus U
Activity
C Fundamental External Response L
Data Access M F

A DFD of A Hypothetical Event

Dr. Richard LUCAS University of Canberra
The Seven Step Outline
N this guide I do two things: Firstly I give a seven step procedure for performing systems analysis.
I Secondly I outline a case study, and I use the seven step procedure to create an analysis model for the
case study. The seven step procedure is designed to give the analyst a practical method for using the
ideas and concepts in Lectures on A Methodology for Systems Analysis.

The two parts are:

Part 1. The Seven Steps

1) Establish Purpose
2) Uncover (Events)
3) Construct a Table of Events and Responses
4) Build Activity Tables
5) Create Event-Activity Related DFD’s and an E-R Diagram
6) Transform Event-Activity Related DFD’s into Abstract DFD’s, Normalize the E-R Diagram
7) Create Documentation for all Activities

Part 2. Canberra Disability Services Case Study

Section 1. Outline
1) Profile
2) Example Forms

Section 2. Analysis
1) Establish Canberra Disability Services’ Purpose
2) Discover Canberra Disability Services’ Events
3) Construct a Table of Events and Responses
4) Build Activity Tables
5) Create Event-Activity Related DFD’s and E-R Diagrams
6) Transform Event-Activity Related DFD’s into Abstract DFD’s
7) Create Documentation for all Activities

SAaM Methodology 1
2 Richard Lucas UCAN
The Seven Steps
he procedure here begins with uncovering the purpose of a system and ends with documenting all
T activities. In between are steps that uncover the events, activities, and information, abstracts these.
Remember that it is only those are required to meet the purpose of the system that are so analyzed.

The steps are:

Step 1. Establish Purpose

Step 2. Discover Events
Step 3. Construct a Table of Events and Responses
Step 4. Build Activity Tables
Step 5. Create Event Related DFD’s and an E-R Diagram
Step 6. Transform Event Related DFD’s into Abstract DFD’s
Step 7. Create Documentation for all Activities

SAaM Methodology 3
Step 1 – Establish Purpose
The first and most important task in analysis is to determine what the purpose of the system is. Like the
next three steps, Uncovering Events, Constructing a Table of Events and Responses, and Building Activity
Tables (one for each Event), it is crucial that the Purpose be determined primarily by the User of the System.

How do you do this? Well, it turns out that the ones in the best position to know is the domain expert user.
This methodology does not include the vagaries of Purpose gathering but the analyst should not construe
that Purpose gathering is an easy or trivial process.

Ask the user/owner.

And keep asking until a) the answer does not change, or b) the user gives up.

Step 2 – Uncover Events

Through interviewing the user and examining existing documentation the analyst will unearth the Events
in the systems environment that ought to be responded to by the system. This is done by comparing known
Events with the systems’s purpose.

Where there are apparent differences between the stated Purpose and an Event then either, the Purpose
ought to be modified to include the new Event (and subsequent Activities) or, have the Event excluded for
those to be considered.

Step 3 – Construct a Table of Events and Responses

After having established a list of Events then the next task is to work out what the system should give back
to the environment as a response. In other words what does the user of the system expect the system to
deliver? This response may be made up of many parts.

In accordance with the methodology the table of Events and Responses ought to have columns for Event,
Event Type, Response, and Response Type. See Lectures on A Methodology for Systems Analysis for the
meanings of these terms.

Step 4 – Build Activity Tables

For each Event, the analyst now needs to establish exactly what the system ought to do to be able to produce
the identified Response, As the user is an expert in what the system ought to do they then should outline
which procedures should be followed to be able to produce the desired response.

In accordance with the methodology these Tables of Activities ought to have a heading indicating which
Event is being modelled as well as columns for each Activity, Activity Type, Response, and Response Type.
See Lectures on A Methodology for Systems Analysis for the meanings of these terms.

4 Richard Lucas UCAN

Step 5 – Create an Event-Activity Related DFD Set and
an E-R Diagram
While mostly a mechanical conversion process of the Event-Response and Activity Tables, much care needs
to be taken to ensure an accurate translation of Events and activities into DFD’s and an E-R Diagram.
There are three sections in this Step:

Section1 – External Entities

This Step involves:
Identifying External Entities as the source of the stimuli. Most of the time this is a straight
forward process with the name of the External Entity frequently being part of the Event Name.
(Eg. Client Requests Services). Remember that it is because of the stimuli that we are aware
of the occurrence of an Event .

Section2 – DFD Context

Here we create a set of data flow diagrams beginning with a Context Diagram using the External
Entities from the previous section. At this point the analyst creates up to two one-way data
flows between each External Entity and the System. These data flows are labelled as —

for the stimuli,

< ExternalEntityN ame > Stimuli + < ResponseN ame >

and, for the responses

< ResponseN ame > to < ExternalEntityN ame >

Where it is not possible for this to be done because there are too many stimuli and responses
to come from and go to a particular External Entity then these data flows should be left blank.

Section3 – Primitive DFD’s

Using the Activities identified in each Event -Activity Table, make primitive Level DFDs: One
for each Event

The Activities are named thus:

Event nn + Activity mm + < descriptivename >

At this point the analyst can specifically label the responses from individual fundamental activ-
ities as these are known from the Activity Tables. The results from Custodial Activities may be
optionally labelled if they are known and can be identified accurately without losing simplicity
of the diagram.

At this stage the Entity-Relationship Diagram starts to take shape with the data stores in the
DFDs containing groups of data structures which are equivalent to entities in the E-RD. It
is natural to want to normalize the E-RD but this is not absolutely necessary until the next
section. As well, the data dictionary should be starting to be built.

SAaM Methodology 5
Step 6 – Transform Event Related Primitive DFD’s into
Abstract DFDs
Section1 – Remove Event and Technology References
So far the steps have been fairly procedural with the analyst’s principle task being recording,
classifying, and clarifying what the user describes. Now it is the job of the analyst to examine
the DFDs and extract from them the essence of the system. This involves a practical application
of the methodology explained in Lectures on A Methodology for Systems Analysis.

In particular, Event references are eliminated entirely from the DFDs and the Activities have
their labels changed to remove any reference to both External Entities and technology.

Now, the Entity-Relationship Diagram needs to be checked so that it conforms to the level of
normalization required for the model (at least 3rd normal form – 3NF, possibly higher) as well
as being both complete and consistent for the model of the system.

Section2 – High Level DFD’s

Once all references to Events have been removed from the DFD,s use the guidelines for con-
structing a set of High Level DFDs. Each high level process represents an appropriate grouping
based on the coupling/cohesion guidelines described in Lectures on A Methodology for Systems
Analysis.

The data flows for these DFDs are modelled using the descriptions:

for stimuli < Stimuli N ame >

for responses < Response N ame >
and
for data accesses < Data Structure N ame >

Step 7 – Create Documentation for all Activities

The final step in the analysis process is to document all activities by creating some form of narrative that
provides enough detail about each activity so that the succeeding phases can be completed. This can be in
the form of Pseudocode, Structured English, Nassi-Schneiderman Diagrams, or in Object Oriented Analysis
methodologies – Use Case Narratives, Activity Diagrams, and Sequence Diagrams.

6 Richard Lucas UCAN

Canberra Disability Services –
Case Study Outline
N this part I describe Canberra Disability Services and give a set of example forms.
I
The sections of this part are:

Part 1. Profile
Part 2. Example Forms

Canberra Disability Services Example 7

 Part 1. Profile
Canberra Disability Services is a nonprofit enterprise which provides a number of services to disabled indi-
vidual in the greater Canberra region. Services provided to the disabled (about 300 clients) include various
forms of therapy, assistance to family and friends who provide care, and assistance in obtaining aid from
government agencies. These services are provided by a staff of some twenty care-givers, the size of the staff
varies with load and funding. The care-givers are certified professionals who are required to maintain and
update their skills through continuing education.

The Service (as it is usually called by our clients) is managed by Kim Putnam, who is herself a professional
care-giver. She has two full-time staff, one of whom also works as a care-giver, the other is an office
assistant. Kim has asked you to build a system with a prototype for The Service. Her immediate concern is
the management of records on clients and on care-givers. She is currently using a manual system borrowed
from a colleague in Canada (which has some peculiarities not appropriate to Australia). The information
on the forms (examples follow) is mostly that required by government agencies. Both the content and the
layout of existing forms must be used in the proposed system. Except, of course, for the obvious differences
between here and Canada.

Beyond this, the system should support the preparation of the fortnightly payroll. This involves the produc-
tion of a report. The care-givers are paid on a fee-for-service basis. Each care-giver turns in a slip of paper
(hand-written) for each contact with a client; the slip details the nature of the contact, the client, and the
care-giver. This determines the care-giver’s fee. These slips are totalled and cross-checked at every second
thursday. Currently this takes three employee-days. At the moment the slips are stored in the client’s file.

Data may be entered into the system by Kim or her two assistants. Owing to confidentiality requirements
certain client data may be entered by only Kim. or her care-giving qualified assistant. The office assistant
is responsible for entering all data on the care-givers although Kim can if there is a pressing need to do so.
Each care-giver can access data on their clients but only their clients.. Kim and her assistance may access
any information about any client. No other person may access any information whatsoever. The system
must provide for security and appropriate restrictions of access. Reports are prepared periodically, some
weekly, others monthly, quarterly, annually, or as needed.

None of the staff are particularly computer-literate but the ACT government has agreed to supply the
technology required to build the system. This is subject to the normal limits of the kinds of equipment the
government supplies to its own staff.

8 Richard Lucas UCAN

 Part 2. Example Forms

List of forms:

Form Number Name

1 Daily Comment Log
2 Client Identification Sheet
3 In-Home Training/Family Interview
4 Care-Giver Training Record
5 Progress Review
6 IPP Objectives
7 File Access Record

Canberra Disability Services Example 9

 Daily Comment Log

On Call Care-Giver’s Name Contact

10 Richard Lucas UCAN

 Client Identification Sheet

Name: Primary Diagnosis:

—————————————- —————————-
Address: Age of Onset:
—————— —————————-
City: ——————— Allergies:
—————————-
State: ——- PostCode: —– Date:
—————————-
Phone (1): ——————— Prepared By:
—————————-
Phone (2): ——————— Title:
—————————-
BirthPlace: ——————— Admission and Financial Info:
BirthDate: ——————— Date:
—————————-
Gender: ——————— Referred From:
—————————-
Sex: ——————— Reason for Admission:
—————————-
Culture: ———————
Race: Date of Admission:
——————— —————————-
Religion: Residential:
——————— —————————-
Hair Colour: Day Services:
——————— —————————-
Eye Colour: ——————— Other:
—————————-
Marital Status: ——————— Other:
—————————-
Language (1): ——————— Country:
—————————-
Language (2): ——————— Social Security Number:
————————
Residency Status: ——————— Legal Status:
—————————-
Communication Skills: ——————— Benefits:
Characteristics: Type: Number
————— ————
Height: ——– Weight: —– Type: Number
————— ————
Assisting Devices: —————————- Type: Number
————— ————
Physical Disabilities: —————————- Medicare:
—————————-
Gait: —————————- Veterans:
—————————-
Posture: Legal Status:
—————————- —————————-
(continued over)

Canberra Disability Services Example 11

 Page 2 of 2

Medical Alert: State: PostCode:

—————————– ——- —–
Last Tetanus: Phone (1): ———————
——————
Emergency Contacts: Phone (2):
1. Name: ——————— ———————
Police:
Relationship: ——————— ———————
Fire:
Address: ——————— ———————
Hospital: ———————
State: ——- PostCode: —– Medical Practitioner: ———————
Phone (1): ——————— Phone (1): ———————
Phone (2): Phone (2): ———————
———————
2. Name: ——————— Legal:
Relationship: ——————— Dependent Child : —————————-
Address: ——————— Full Guardianship: —————————-
State: ——- PostCode: —– Custodial: —————————-
Phone (1): ——————— Limited Guardianship: Yes/No
——- ——–
Phone (2): Emancipated Adult: ——- Yes/No ——–
———————
3. Name: Voting Rights: Yes/No
——————— ——- ——–
Relationship: ——————— Payee:
Address: ——————— —————————-
Guardian:
State: ——- PostCode: —– —————————-
Relationship:
Phone (1): —————————-
——————— Address: ———————
Phone (2): ——————— State: ——- PostCode: —–
Parent Information: Phone (1): ———————
Mother’s Maiden Name: Phone (2): ———————
———————
BirthDate: ——————— Additional Guardian
Address: ——————— Information —————————-
State: ——- PostCode: —– Name of Advocate
Phone (1): ——————— – —————————-
Phone (2): Relationship: —————————-
———————
Father’s Name: School: —————————-
———————
BirthDate: Social Worker: —————————-
———————
Address: ——————— Phone:
—————————-

12 Richard Lucas UCAN

 In-Home Training/Family Interview

Primary Care-Giver: ———————————————————-

Training/Interview Address: —————————————————-

City: ———————————– PostCode: —–

Individual’s Name:
—————————————————-
DSMIII Diagnosis: —————————————————-

Medical Diagnosis (if appropriate): —————————————————-

Siblings in Respite Care: —————————————————-

Training and/or Interview Complete: ———————————– Date: —–

Signature of Primary Care-Giver:

—————————————————-
Signature of Direct Staff/Secondary Care-Giver: ———————————————

RETURN TO REGIONAL OFFICE WHEN COMPLETE,

COPIES TO BE KEPT IN FAMILY FILE, REGIONAL
FILE, AND CAREGIVERS FILE.
1) Review general information form. Where is it kept? . The individual file
is to be available to direct care staff when in the residence of the person seeking care.
2) Check emergency medical release. See that it is appropriate for the situation.
3) Instructions for emergencies (Fire, Accident, Flood, etc.)

4) Which first aid supplies are kept and where?

5) Where is fuse box or circuit breaker?

Canberra Disability Services Example 13

 6) Where are the utilities shut off ?
a) Water?
b) Electricity?
c) Gas?
7) Where is the nearest phone for an emergency? If the phone does not have
a phone, where is the nearest location of a pay phone or neighbour’s phone that can
be used?
8) Emergency Phone Numbers:
a) Fire?
b) Utility Company?
c) Ambulance?
d) Plumber?
e) Police?
f) Electrician?
9) Special Instructions:

10) Persons Restricted from Premise:

Name:

Name:

11) Pets:

Name: Care:

Name: Care:

12) Client Diagnosis

13) Client Strengths

14) Hobbies or Leisure activities

15) Client Needs:

16) Behaviour Management Techniques:

17) Administration of Medication:

14 Richard Lucas UCAN

 Care-Giver Training Record

Name of Staff: ———————————————- Medicare Number: ——————

Start Date: ————————–

City: ———————————– PostCode: —–

Module Score Date Practicum Comments

Canberra Disability Services Example 15

 Progress Review
Note: Date and signature must be included in each entry
Date: Progress:
—/—/— ————————————————————————————

Signature: —————————————-

Date: —/—/— Progress: ————————————————————————————

Signature:
—————————————-
Date: Progress:
—/—/— ————————————————————————————

Signature: —————————————-

16 Richard Lucas UCAN

 IPP Objectives

( ) High
( ) Medium
( ) Low
Individual: Staff:
———————————————- ——————
Start Date: —/—/— Target Date: —/—/— Terminated Date: —/—/—

Objecctive and Description:

———————————————————————-

Where training is to occur: ———————————- Frequency of contact: ————–

Method of Data Coll.: ———————————- Frequency of Monitor: ————–
Reinforcement: Frequency of Reinf.:
———————————- ————–
Special Materials: —————————————————————————————-

Anticipated Barriers: —————————————————————————————-

Method/Procedure: —————————————————————————————-

Canberra Disability Services Example 17

 File Access Record
No File Viewed By: Date/Time
1 ——————————————————————————— ——————-
2 ——————————————————————————— ——————-
3
——————————————————————————— ——————-
4 ——————————————————————————— ——————-
5
——————————————————————————— ——————-
6 ——————————————————————————— ——————-
7 ——————————————————————————— ——————-
8 ——————————————————————————— ——————-
9 ——————————————————————————— ——————-
10
——————————————————————————— ——————-
11 ——————————————————————————— ——————-
12
——————————————————————————— ——————-
13 ——————————————————————————— ——————-
14 ——————————————————————————— ——————-
15 ——————————————————————————— ——————-
16 ——————————————————————————— ——————-
17
——————————————————————————— ——————-
18 ——————————————————————————— ——————-
19
——————————————————————————— ——————-
20 ——————————————————————————— ——————-
21 ——————————————————————————— ——————-
22
——————————————————————————— ——————-
23 ——————————————————————————— ——————-
24
——————————————————————————— ——————-
25 ——————————————————————————— ——————-
26
——————————————————————————— ——————-
27 ——————————————————————————— ——————-
28 ——————————————————————————— ——————-
29
——————————————————————————— ——————-
30 ——————————————————————————— ——————-

18 Richard Lucas UCAN

Canberra Disability Services –
Analysis

ERE I show how the seven step process is used in practice.

H
The parts of this process are:

Step 1: Establish Canberra Disability Services’ Purpose

Step 2: Discover Canberra Disability Services’ Events
Step 3: Construct a Table of Events and Responses
Step 4: Build Event-Activity Tables
Step 5: Create Primitive (Event -Activity Related) DFD’s and E-R Diagrams
Step 6: Transform Primitive (Event -Activity Related) DFD’s into Abstract DFD’s
Step 7: Create Documentation for all Activities

Canberra Disability Services Example 19

Step 1 – Establish Canberra Disability Services System
Purpose
Purpose
— To assist Canberra Disability Services with the management of their clients,
caregivers, the annual telethon, and in preparing the payroll.

Step 2 – Uncover Events

Event Number Description Type
1 A Person Requests Assistance External
2 A Client Changes Their Personnel Details External
3 A Client Changes Other Details External
4 A Client Arrives for their Detailed (2nd ) Interview External
5 A Care Giver Changes Their Personal Details External
6 Kim Requests a Comment Log Report External
7 A Care Giver Completes a Client Session External
8 A Care Giver Submits a Care Completion Slip External
9 A Care Giver Completes a Training Module External
10 An Authorised Person Requests Access to a Client’s Information External
11 Time to Complete the Shift Comment Log Temporal
12 A Care Giver Completes a Family Interview External
13 Kim Requests an Ad Hoc Report External
14 Kim Requests an Individual Client’s External
Service Objectives Log Report External
15 Time to Prepare the Monthly Payroll Summary Report Temporal
16 A Care Giver Completes a Progress Review External
17 A Care Giver Reassesses a Client External
18 Kim Requests a Client’s File Access Summary Report External
19 Kim Hires a New Care Giver External

20 Richard Lucas UCAN

Step 3 – Construct a Table of Events and Responses

After having established a list of Events then the next task is to work out what the system
should give back to the environment as a response. In other words what does the user of the
system expect the system to deliver? This response may be made up of many parts.

– Table of Events and Responses

.
Event (Type) Responses (Type)

1. A person Requests Assistance 1.1 Client Acceptability Notice

(External) (Fundamental)
1.2 Preliminary Client Assessment
(Custodial)
1.3 Preliminary Service Objectives
(IPP) (Custodial)
1.4 2nd Interview Notice (Fundamental)
1.5 Client Care Details (Custodial)

2. A Client Changes Their Personnel Details 2.1 Client Personal Details

Acknowledgement

3. A Client Changes Other Details 3.1 Client Other Details

Acknowledgement

4. A Client Arrives for their 4.1 Client Details Acknowledgement

Detailed (2nd ) Interview 4.2 Detailed (2nd ) Interview
Summary Report

5. A Care-Giver Changes Their 5.1 Care-Giver Personal Details

Personnel Details Acknowledgement

6. Kim Requests a 6.1 Shift Comment Log Report

Comment Log Report Acknowledgement

7. A Care Giver Completes a Client Session 7.1 In-Home Training Report

8. A Care Giver Submits a 8.1 Slip Completion Receipt

Care Completion Slip

Canberra Disability Services Example 21

9. A Care Giver Completes a Training Module 9.1 Care Giver Training
Acknowledgement

10. An Authorised Person Requests Access to 10.1 Initial Security Response

a Client’s Information 10.2 Second Security Response
10.3 Final Security Response
10.4 Client Details Report

11. Time to Complete the Shift Comment Log 11.1 Shift Comment Log
Acknowledgement

12. A Care Giver Completes a Family Interview 11.1 Family Interview Report

13. Kim Requests an Ad Hoc Report 11.1 Ad Hoc Report

14. Kim Requests an Individual Client 14.1 Individual Client

Service Objectives Log Report Service Objectives Log Report

15. Time to Prepare the 15.1 Monthly Payroll Summary

Monthly Payroll Summary Report Report

16. A Care Giver Completes a Progress Review 16.1 Client Progress Review Report
16.2 Progress Review Summary
Report

17. A Care Giver Reassesses a Client 17.1 Client Reassessment Summary

Report

18. Kim Requests a Client’s File Access 18.1 Kim Requests a Client’s File
Summary Report Access Summary Report

19. Kim Hires a New Care Giver 11.1 New Care Giver Employment
Acknowledgement

22 Richard Lucas UCAN

Step 4 – Build Event-Activity Tables
.
Event 1 – A Person Requests Assistance
When we consider the task of a person asking for help we get the following Activity-Response
Table.
Activity (Type)
1.1 Identify Person (Type - Mixed)
1.2 Perform Preliminary Assessment
(Custodial)
1.3 Determine Client Acceptability
(Mixed)
1.4 Determine Preliminary
Service Objectives (IPP)
(Fundamental)
1.5 Select Client’s Primary Care Giver
(Custodial)
1.6 Notify Client of Primary Care Giver
(Fundamental)
1.7 Notify Care Giver of New Client
(Fundamental)
Responses (Type)
1.1.1 Person Details (Type - Custodial)
1.1.2 Request Acknowledgement
(External)
1.2.1 Preliminary Assessment Result
(Custodial)
1.3.1 Client Acceptability (Custodial)
1.3.2 Client Acceptability Notice
(External)
1.4.1 Preliminary Service Objectives
(IPP)(External)
1.5.1 Client Care Details (Custodial)
1.6.1 2nd Interview Notice
(External)
1.7.1 2nd Interview Notice (External)
1.7.2 Client Care Details (External)
1.7.3 Preliminary Service Objectives
(External)
1.7.4 Client Acceptability Notice
(External)
Canberra Disability Services Example 23
Step 5 – Create Event-Activity Related DFD’s and E-R
Diagrams
While mostly a mechanical conversion process of the Event-Response and Event-Activity Ta-
bles, much care needs to be taken to ensure an accurate translation into DFD’s and an E-R
Diagram. There are three sections in this Step:

Section1 – External Entities

This Step involves:

Identifying External Entities as the source of the stimuli. Where does the Event
come from? Remember that it is because of the stimuli that we are aware of the
occurrence of an Event .

Section2 – DFD Context

Create a Context Diagram using the External Entities from the previous section.
At this point the analyst creates two one-way data flows between each External
Entity and the System. These data flows are labelled as —

< ExternalEntityN ame > Stimuli + < ExternalEntityN ame >

Responses. These represent the stimuli coming from the External Entity and the
responses the system creates that go back to the External Entity.

Recall that it may not be possible to render the complexity of the stimuli and responses into
a single descriptive names.

Section3 – Primitive (Event-Activity Related) DFD’s

Using the guidelines for constructing DFD’s build primitive DFDs, one for each
Event. Each primitive DFD represents an Event and its Activities. Putting all
the Events on one DFD violates the modeling principles described in Lectures on A
Methodology for Systems Analysis.

The data flows for these DFDs are modelled using the descriptions,

for stimuli -

< ExternalEntityN ame > Stimuli f or Event nn

for responses -

< ExternalEntityN ame > Response f rom Event nn

where nn is the number of the Event in the Table of Events. If the descriptive
names of an Event is short then the descriptive name can be added to give the
more complete, and hopefully helpful, label:

for stimuli -

24 Richard Lucas UCAN

 < ExternalEntityN ame > Stimuli f or Event nn + < descriptivename >

for responses -

< ExternalEntityN ame > Response f rom Event nn + < descriptivename >

Section4 – E-R Diagram

At this point the basics of the E-R Diagram ought to be substantially complete.

Data Dictionary

Name Type Description

Daily Comment Log Data Structure Comments made by the on-call Care-Giver
Client Identification Sheet Data Structure The form used to collect initial data about a Client
In-Home Training Data Structure
/Family Interview Data Structure
Care-Giver Training Record Data Structure
Progress Review Data Structure
IPP Objectives Data Structure
File Access Record Data Structure

Step 6 – Transform Event-Activity Related DFD’s into

Abstract DFDs
So far the steps have been fairly procedural with the analyst’s principle task being recording,
classifying, and clarifying what the user descries Now it is the job of the analyst to examine
the DGDs and extract from the the essence of the system. This involves a practical application
of the explained in Lectures on A Methodology for Systems Analysis.

In particular, the Event processors are eliminated entirely and the Activity processors have
their labels changed to remove any reference to both External Entities and technology.

Now the Entity-Relationship Diagram needs to be checked so that it conforms to the level of
normalization required for the model (at least 3rd normal form – 3NF, possibly higher) and is
both complete and consistent for the model of the system.

Canberra Disability Services Example 25

Step 7 – Create Documentation for all Activities
In this worked example I will use simplified Use Case Narratives, Activity Diagrams, and
Sequence Diagrams.

26 Richard Lucas UCAN