1. SSADM – Structured Systems Analysis and Design Method
Yard.Doç.Dr. Zehra KAMIŞLI ÖZTÜRK

3. Investigation of the current environment Investigate and define requirements

5. Analysts are looking for the answer of these questions
• Is the current system reliable? • Is there an integrity of the current system? Does it provide valid information? • can the system easily be divided? • The system has no backup process • Does the system Works regularly in the most intense moments? • Does it meet current and future needs?

6. Fact finding techniques
• Interviews / surveys Analyst should be well prepared • a time on a given day • Start from the top levels of management! • receive audio recording instead of writing! Do not miss important points • current form and files in the current system can provide information!

7. Investigate current processing
This Step also involves fact-finding, but focuses on producing models or diagrams of the processing in the current system. The key technique here is Data Flow Modelling.
Data flow modelling of SSADM

8. At this stage of SSADM, the diagrams include: context diagrams
Data Flow Diagrams
At this stage of SSADM, the diagrams include:
context diagrams
Document flow diagrams
Data Flow Diagrams (DFDs)

9. what data is involved, and where the data goes to.
Data Flow Diagrams
what data is involved, and where the data goes to.
the processes involved in the current (and required) system
How the data is created, updated, stored?
Processes –activities
The things you did at weekend?
Going to cinema, at which oclock?...

10. Processes (or activities) Data flows External entities Data stores
four elements to a DFD
Processes (or activities)
Data flows
External entities
Data stores

11. Processes at DFD
The processes show an activity carried out by someone in the organization which involves data in some way.
They take the form of a box with the
activity inside. The activity always starts with a verb, such as ‘Pay artistes’
at Swillbuckets. The processes are numbered in the top left-hand corner.
This is just to identify the process: it does not mean that process number 1
must be done first. The person, or department, who does the activity,
appears in the top right section of the box.

12. Data flows show the movement of data around the system.
They take the form of an arrow which shows the direction of the data

13. They will send data into the system or receive data from it.
External Entities
These are people or organizations outside of the system being investigated.
They will send data into the system or receive data from it.
At Swillbuckets,
‘artiste’ would be an external entity, as would ‘brewery’. They are shown in
the form of ovals with a label inside. If the same entity appears more than
once on a diagram, it has a line through it. Figure 2.7 shows the entity
‘member’.

14. Jack Trout’s members’ shoebox at Swillbuckets is a data store
Data Stores
These are places where data is stored. For example, an Orders file would be a data store.
Jack Trout’s members’ shoebox at Swillbuckets is a data store
M: manuel

15. Example: Partial DFD

16. Data flow diagram rules
Processes Have to have the input and output
Data flows should be exit in the process box
There can not be a flow into the data store from an external entity
label of external entitites must be a name
Flow to data store: Update
flow from the data store: receiving data from the data store

17. Context diagram This is the first diagram we draw.
In order to prevent it looking too complicated, we might summarize the key data flows.
All the processes in the system are contained in one process box.
The aim is to get an overview of which external entities send or receive data from our system at present.
A context diagram is a tool to establish the scope of the system under investigation.
It is similar to a DFD, but does not obey the rules outlined above.

18. Document flow diagram
This follows on from the context diagram.
It looks inside the one process box in the context diagram and breaks it up into departments or areas of work.
It also allows us to show exactly which parts of the overall system we are going to investigate.
Some parts might not need looking at.

19. Simple steps in data flow modelling
The main tasks to be completed, in order, are:
1 Draw a context diagram.
2 Draw a document flow diagram.
3 Draw a top-level data flow diagram.
4 Draw lower level data flow diagrams.

20. Data Flows and Entities
1. Determination of the external entitites
Make a list of all the things (entities) external to our organization which send
data to us or receive data from us. The Medical Centre list might consist of:
Patient: the Centre will receive all kinds of data from patients, such as
appointment requests.
University: the Centre receives a list of new students.
General Practitioners Council: the Centre sends to the GPC
timesheets for the work done by the receptionists and the Nurse. Doctors
are paid according to the number of patients on their list. The Centre
receives pay slips from the GPC.
Supplier: Nurse Payne will send orders for supplies and receive invoices.
Hospital: the Centre sends referrals to the hospital and receives reports
on treatment at the hospital.
Prescription Monitoring Agency: the Centre sends the PMA data on
prescriptions and receives reports on the practice for prescribing drugs
nationally.
Accountant: the Centre sends regular financial information and
receives reports.

21. 2. Draw the context diagram
A dashed line can be used to show
data flows between external entities
Notice that a dashed line has been drawn between GPC and the Patient,
to show the Medical Card. A dashed line can be used in this way to show
data flows between external entities which are felt to be important enough
to show.

22. 3. Identify internal areas/departments
In a college
Department, Student, Tutor,
Admin, Support
In the Medical Centre
Reception, Doctor and Nurse
Having considered the external data flows, we move on to the internal ones
which will appear in the document flow dia
We need to separate Doctor and Nurse
because they perform different tasks for the Centre. We also need to identify
the data flows between these areas, as we did with the Context Diagram.
You could draw a table as in the previous section, but in this case it’s
fairly simple, so we’ll draw the diagram.gram. We need to identify the internal areas which might send data between themselves.
We also need to identify the data flows between these areas
We need to identify the internal areas which might send data between themselves

23. 4. Draw the document flow diagram
Electronic
Word of mouth
Written
System boundary
The document flow diagram need not just consist of documents. Confusingly,
it can include any type of data flow
The system boundary has been added to show exactly what areas we are
concerned with in the Medical Centre. All entities outside of the dashed
line are external entities.
It should be obvious from the Context Diagram
which areas are outside our system. With the user’s agreement, it is the
analyst’s role to investigate the internal entities. In this case, they are
RECEPTIONIST, DOCTOR and NURSE.

24. 5. Convert the document flow diagram into a top-level data flow diagram
Start with the document flow diagram.
Focus on the sources/recipients (ellipses) inside the boundary (ex: Doctor, Nurse and Reception).
Look at the data flows coming into and going out of these ellipses.
What processes generate these data flows? What are the main processes carried out by Doctor, Nurse and Reception?

25. Another data flow is ‘registration form’.
5. Convert the document flow diagram into a top-level data flow diagram
Let’s take Reception – we might start with the data flow ‘appointment’.
What process generates this ‘appointment’? Remember that we’re trying
to be general at the moment, so we could identify a process called ‘Process
Appointment’. This would cover a number of our data flows.
Another data flow is ‘registration form’.
What process generates ‘registration form’? Being general again, we might call it ‘Register Patient’.
Other data flows are ‘prescription’ and ‘referral’. What processes generate
these? They could be brought together under the process ‘Process
Patient Requirements’.

26. Level 1 DFD
5. Convert the document flow diagram into a top-level data flow diagram
Put these general processes together in one diagram and we have our DFD.
For the sake of simplicity, data stores can be left out of this top-level diagram. They will appear in the lower level diagrams.
Who?
When?
What?
How?
We now have an overview DFD. This is normally called a Level 1 DFD.

27. 6 Develop the lower level DFDs using functional decomposition
Level 1 DFD gives us a very general overview of what goes on in the Medical Centre, but provides no details about what really happens.
Thus each Level 1 process might be broken down into a number of Level 2 processes.
When drawing the lower level DFDs, we must now incorporate the data
stores.
Level 1 DFD gives us a very general
overview of what goes on in the Medical Centre, but provides no details
about what really happens. We need to know these details. So we need to
talk to the users again to gain a deeper understanding of what happens at a
lower level.
When drawing the lower level DFDs, we must now incorporate the data
stores. These were omitted from the Level 1 DFD, simply to avoid overloading
the diagram.

28. Level 2 DFD ‘Register Patient’
Level 2 DFDs for the Medical Centre
Level 2 DFD ‘Register Patient’

29. Level 2 DFD - ‘Process Appointment’.

30. Level 2 DFD – ‘Process Patient Requirements’.

31. limitations with DFDs
They don’t show us how the data is structured.
They don’t show the effect of time or sequence.
They may not help communicate with the user – they may be too complex.
They take a long time to draw and redraw.
They may never be complete.