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

2. Lower levels of the system are considered in detail, later on
SSADM
(Structured System Analysis & Design Methodology - SSADM) basic principles
top down functional decomposition
analyze level
Break down functional complex system into chunks
Ignore the small details until it engages the key features of the system
Lower levels of the system are considered in detail, later on
The first principle is the one just mentioned, about breaking down
complex systems into chunks. This is called top down functional
decomposition. It means that the analyst starts off just thinking about
the system as a whole. Small details are ignored to begin with until the
analyst has a grasp of the key features of the system. Later on, the analyst
will think about the more detailed lower levels of the system.

3. 2. Requirement of explanation
SSADM
2. Requirement of explanation
physical aspects of the current system
physical perspectives of the current system
how things are currently done and who does them?
Logical point of view
what is currently done or?
This completes the analysis phase, and then it’s on to design
What the new system should do? Who and how will do?
The scope of SSADM is clearly defined. The analyst starts off by looking
at the physical aspects of the current system. This means looking at
how things are currently done and who does them. The analyst then
moves on to look at what is currently done from a logical point of view.
This completes the analysis phase, and then it’s on to design. The analyst
will consider what the new system should do and finally how it
should do it. This is as far as SSADMgoes. This approachmight be represented
as in Figure 1.2.

4. 2. Requirement of explanation
SSADM
2. Requirement of explanation
This is as far as SSADM goes. This approach might be represented
as in Figure 1.2.

5. 3. SSADM requires users to get involved from the start
The analyst must meet the users regularly to sort out problems and check understanding.
SSADM, would involve users from the beginning
Stay happy in the new system
SSADM requires users to get involved from the start. This makes them
more committed to the process and more likely to be happy with the
new system. The analyst must meet the users regularly to sort out problems
and check understanding. Incidentally, this means that the analyst
should possess highly developed communication skills. These are
possibly the most important skills of all in systems analysis.

6. 4. effective use of diagrams
SSADM
4. effective use of diagrams
Forming detailed logical data structure
Establishing multipart data structure multipart
Creating data dictionary
like a map of the system
SSADM makes effective use of diagrams to help both the analyst and
the user understand the system. These diagrams should be simple and
easy to follow, like a map of the system.

7. 5. SSADM allows the analyst to see the system from different views
check to see if the different views match up
Cross-checking
SSADM allows the analyst to see the system from different views. You
can then check to see if the different views match up. This is called
cross-checking.

8. SSADM is an industry standard
1980’lerin başında kullanılmaya başlanmıştır.
SSADM SSADM, genellikle devlet bilgisayar projeleri için bir gereklilik olarak belirtilen İngiltere'de yaygın olarak kullanılan bir bilgisayar uygulama geliştirme yöntemidir. Giderek Avrupa'da kamu sektörü tarafından kabul edilmiştir.
SSADM kamu malıdır ve İngiliz Standardı BS7738 ile belirtilir.
SSADM is an industry standard
It has been used science early 1980’s.
SSADM, is a widely-used computer application development method in the UK, where its use is often specified as a requirement for government computing projects.
It is increasingly being adopted by the public sector in Europe.
SSADM is in the public domain, and is formally specified in British Standard BS7738.
SSADM has been around for a good many years. It’s an industry standard,
so most analysts have used it. If your life depended on a system being successful,
you might well use SSADM as the best bet to save your skin.
is a widely-used computer application development method in the UK, where its use is often specified as a requirement for government computing projects. It is increasingly being adopted by the public sector in Europe. SSADM is in the public domain, and is formally specified in British Standard BS7738.

9. SSADM's objectives are to:
Improve project management & control
Make more effective use of experienced and inexperienced developmentstaff
Develop better quality systems
Make projects resilient to the loss of staff
Enable projects to be supported by computer-based tools such as computer-aided software engineering systems
Establish a framework for good communications between participants in a project
SSADM divides an application development project into modules, stages, steps, and tasks, and provides a framework for describing projects in a fashion suited to managing the project. SSADM's objectives are to:

10. The structure of SSADM
SSADM is made up of a number of Stages. These Stages are then divided up
into Steps. Figure 1.3 shows an overview of the Stages.
Stage 0: Feasibility
This is where the analyst and users decide if the entire project is worth pursuing.
It involves the analyst considering the problems faced by the organization
and producing a set of options to resolve them. The users must then
decide whether the costs involved in resolving the problem are worth it. It
may be that the problems are so severe that the organization simply has to
resolve them. In this case, the feasibility study might be left out.
Stage 1: Investigation of the current environment
This needs to be done so that the analyst and the users fully understand
what the current system does. They need to be clear what problems they
have and what they want from the new system.
Stage 2: Business system options
This Stage allows the analyst and users to come up with some ideas about
what the new system might do. Usually, a range of options, with different
costs and benefits, are considered. Users will need to be clear about the
objectives of the business before they can choose the option to proceed
with.
Stage 3: Definition of requirements
This involves specifying the required system. During this Stage, the analyst
will want to move away from the constraints of the current system and
towards a more logical, data-driven design. An overview of the underlying
data structures for the required system is created.
Stage 4: Selection of technical system options
By now, the analyst and users will have a reasonable idea of what the new
system will be expected to do. This allows them to consider the technical
options. For example, the key hardware components will need to be identified
and costed. The users will, eventually, choose from a range of options.
Stage 5: Logical design
This involves specifying the new system. What will the new system do?
What might it look like from a user perspective?
Stage 6: Physical design
This Stage concentrates on the environment within which the new system
will be running. It involves looking at storage requirements and performance
issues.
At the end of each of these Stages, the analyst and users must decide
whether to press on to the next Stage, abandon the project, or redo one or
more Stages. All of these cost money.

11. SSADM
Stage 0. Feasibility
Technical – is the project technically possible? Financial – can the business afford to carry out the project? Organizational – will the new system be compatible with existing practices? Ethical – is the impact of the new system socially acceptable?
In order to determine whether or not a given project is feasible, there must be some form of investigation into the goals and implications of the project. For very small scale projects this may not be necessary at all as the scope of the project is easily understood. In larger projects, the feasibility may be done but in an informal sense, either because there is not time for a formal study or because the project is a “must-have” and will have to be done one way or the other.
When a feasibility study is carried out, there are four main areas of consideration:
Technical – is the project technically possible? Financial – can the business afford to carry out the project? Organizational – will the new system be compatible with existing practices? Ethical – is the impact of the new system socially acceptable?
To answer these questions, the feasibility study is effectively a condensed version of a fully blown systems analysis and design. The requirements and users are analyzed to some extent, some business options are drawn up and even some details of the technical implementation. The product of this stage is a formal feasibility study document. SSADM specifies the sections that the study should contain including any preliminary models that have been constructed and also details of rejected options and the reasons for their rejection.

12. Stage 1 – Investigation of the current environment
Through a combination of interviewing employees, circulating questionnaires, observations and existing documentation, the analyst comes to full understanding of the system as it is at the start of the project.
Stage 1 – Investigation of the current environment[edit]
The developers of SSADM understood that in almost all cases there is some form of current system even if it is entirely composed of people and paper. Through a combination of interviewing employees, circulating questionnaires, observations and existing documentation, the analyst comes to full understanding of the system as it is at the start of the project. This serves many purposes:

13. Stage 2 – Business system options
the degree of automation
the boundary between the system and the users
the distribution of the system, for example, is it centralized to one office or spread out across several?
cost/benefit
impact of the new system
Stage 2 – Business system options
Having investigated the current system, the analyst must decide on the overall design of the new system. To do this, he or she, using the outputs of the previous stage, develops a set of business system options. These are different ways in which the new system could be produced varying from doing nothing to throwing out the old system entirely and building an entirely new one. The analyst may hold a brainstorming session so that as many and various ideas as possible are generated.
The ideas are then collected to options which are presented to the user. The options consider the following:
the degree of automation
the boundary between the system and the users
the distribution of the system, for example, is it centralized to one office or spread out across several?
cost/benefit
impact of the new system
Where necessary, the option will be documented with a logical data structure and a level 1 data-flow diagram.
The users and analyst together choose a single business option. This may be one of the ones already defined or may be a synthesis of different aspects of the existing options. The output of this stage is the single selected business option together with all the outputs of the feasibility stage.

14. Stage 3 – Requirements specification
To produce the logical specification, the analyst builds the required logical models for both the data-flow diagrams (DFDs) and the Logical Data Model(LDM), consisting of the Logical Data Structure (referred to in other methods as entity relationship diagrams) and full descriptions of the data and its relationships.
Stage 3 – Requirements specification[edit]
This is probably the most complex stage in SSADM. Using the requirements developed in stage 1 and working within the framework of the selected business option, the analyst must develop a full logical specification of what the new system must do. The specification must be free from error, ambiguity and inconsistency. By logical, we mean that the specification does not say how the system will be implemented but rather describes what the system will do.
To produce the logical specification, the analyst builds the required logical models for both the data-flow diagrams (DFDs) and the Logical Data Model(LDM), consisting of the Logical Data Structure (referred to in other methods as entity relationship diagrams) and full descriptions of the data and its relationships. These are used to produce function definitions of every function which the users will require of the system, Entity Life-Histories (ELHs) which describe all events through the life of an entity, and Effect Correspondence Diagrams (ECDs) which describe how each event interacts with all relevant entities. These are continually matched against the requirements and where necessary, the requirements are added to and completed.
The product of this stage is a complete requirements specification document which is made up of:
the updated data catalogue
the updated requirements catalogue
the processing specification which in turn is made up of
user role/function matrix
function definitions
required logical data model
entity life-histories
effect correspondence diagrams
Though some of these items may be unfamiliar to you, it is beyond the scope of this unit to go into them in great detail.

15. Stage 4 – Technical system options
the hardware architectures
the software to use
the cost of the implementation
the staffing required
the physical limitations such as a space occupied by the system
the distribution including any networks which that may require
the overall format of the human computer interface
Stage 4 – Technical system options[edit]
This stage is the first towards a physical implementation of the new system. Like the Business System Options, in this stage a large number of options for the implementation of the new system are generated. This is honed down to two or three to present to the user from which the final option is chosen or synthesized.
However, the considerations are quite different being:
the hardware architectures
the software to use
the cost of the implementation
the staffing required
the physical limitations such as a space occupied by the system
the distribution including any networks which that may require
the overall format of the human computer interface
All of these aspects must also conform to any constraints imposed by the business such as available money and standardization of hardware and software.
The output of this stage is a chosen technical system option.

16. Stage 5 – Logical design
the outputs of this stage are implementation-independent and concentrate on the requirements for the human computer interface.
Stage 5 – Logical design[edit]
Though the previous level specifies details of the implementation, the outputs of this stage are implementation-independent and concentrate on the requirements for the human computer interface. The logical design specifies the main methods of interaction in terms of menu structures and command structures.
One area of activity is the definition of the user dialogues. These are the main interfaces with which the users will interact with the system. Other activities are concerned with analyzing both the effects of events in updating the system and the need to make inquiries about the data on the system. Both of these use the events, function descriptions and effect correspondence diagrams produced in stage 3 to determine precisely how to update and read data in a consistent and secure way.
The product of this stage is the logical design which is made up of:
Data catalogue
Required logical data structure
Logical process model – includes dialogues and model for the update and inquiry processes
Stress & Bending moment.

17. Stage 6 – Physical design
This is the final stage where all the logical specifications of the system are converted to descriptions of the system in terms of real hardware and software.
Stage 6 – Physical design[edit]
This is the final stage where all the logical specifications of the system are converted to descriptions of the system in terms of real hardware and software. This is a very technical stage and a simple overview is presented here.
The logical data structure is converted into a physical architecture in terms of database structures. The exact structure of the functions and how they are implemented is specified. The physical data structure is optimized where necessary to meet size and performance requirements.
The product is a complete Physical Design which could tell software engineers how to build the system in specific details of hardware and software and to the appropriate standards

18. Swillbuckets Country Club
The Case Studies
Swillbuckets Country Club

19. Swillbuckets Country Club
Tasks:
Reservation of artists
New memberships
Preparing receipts to artists
Promotion of future events
chasing memberships
Nice meat dishes! reward the Chief !!

20. Swillbuckets Country Club
Card-based data storage system
Users and artists
2-3 shoeboxes
Not an Adequate storage system !!
There isn’t an option to open a new box and / or information system
Subscription fees of the members - assistant: Amanda

21. Definition of the problem
Amanda is not patient !!
• She wants from Jack the list of members who have
delayed payments I want the list (2 weeks ago)
• Is it possible for Jack to remove the list from the
box??

22. Definition of problem -2
changing customer records
Creation of Monthly "future events" list
announce these events to the local press

23. Definition of problem- Food Service
They have a well-planned food range
Meat, especially organ meats, expert
Several suppliers
Reliable?
Payments are made in cash
Unknown instant stock records unknown
It remains a difficult situation while cooking for chef
Last-minute changes in menus

27. Problem background
Appointments: chaotic, with double bookings, no room for urgent cases, and changes not made. A foolproof system of appointments is the top priority for the Centre.
Patient processing: the filing of records is haphazard. They can go missing, or be misfiled. With such a high turnover of patients, the records are not always maintained accurately. Much information is duplicated and often disparities appear. The doctors require a way of viewing patient records without having to keep going backwards and forwards to see Betty and George. Prescriptions are normally illegible, which results in Heather in the chemists having to pop in regularly to have them decrypted.

28. Problem background
management information: the GPC requires regular information about the hours doctors have worked, new patients, supplies used etc. Currently, Nurse Payne attempts to produce these, but mathematics is not her strong point. The staff time sheets are a mess and staff often get paid for hours they haven’t worked. The accountant is not happy about this. Neither is the GPC. The GPC also needs regular updates on currently enrolled patients. It is the responsibility of the receptionists to record when patients leave and keep a list of patients for each doctor. However, the University does not tell them when a student withdraws, and patients rarely think to inform them when they move away.

29. Problem background
The only information it gets is from the GPC when it issues a new Medical Card for another practice, or from the Registrar of Deaths. Betty gets quite queasy when she has to tear up someone’s medical records and throw them in the bin. The Prescription Monitoring Agency also requires information about what prescriptions have been issued so that it can compare different practices and see who is out of line. It sends a report every six months to the Centre. This is shredded and used as a home for the hamster. The accountant requires regular financial information about outgoings. This is the bane of Nurse Payne’s life. A proper accounting system is required.

30. Ordering supplies: on a more mundane note, Nurse Payne has no information about potential suppliers, other than the catalogues she keeps under her desk. She may be paying too much for bandages etc. She is keen to find out more about some recycled Crimean War bandages that her friend, Nurse Blunt mentioned to her.

31. Registration: it has been known for the receptionists to take down details wrongly (e.g. ‘blood group’), or to omit key words such as ‘haemophiliac’. These typing errors have had unnerving results. Also, George and Betty have had problems trying to determine who is eligible to join the practice. A street map with felt tip lines on it has proven to be a less than adequate tool. Ideally, they want to be able to say instantantly if a postcode is within their catchment area.

32. 4 doctors - every doctor has his/her own patient list
Staff
4 doctors - every doctor has his/her own patient list
Patients can go another physician
1 nurse: prescription writing & ordering injection & syringe - plastic and so on.
2 receptionist & 1 trainee receptionist:
patient tails and appointments

33. Summary of the problems
Appointments
Complex, dual enrollment, no emergency rooms
Patient process
Random records, not updated records
Doctors do not know the patient case history
Prescriptions are illegible: influence of pharmacist

34. Summary of the problems
• Management information
Regular information requested by the GPC
• working hours of doctors
• New patient
• Suppliers ...
• Charts inadequate. accounting & GPC :(
GPC new records
An appropriate accounting system

35. Do Nurses know potential suppliers ?? • Register
• There may be more money to bandage !!
• Register
Receptionist missing records (major diseases) or take the wrong record
• Haşimato / 0rh positive