System Analysis and Design for Desklib

This article discusses the system requirements, use cases, domain modelling, and use case modelling for Desklib, an online library for study material with solved assignments, essays, dissertation, etc.

System Analysis and Design
Institution Affiliation

1. SYSTEM REQUIREMENTS...........................................................................................................................2
a. Stakeholders....................................................................................................................................................2
b. Techniques......................................................................................................................................................4
c. Primary Functional Requirements...............................................................................................................6
d. Non-Functional Requirements......................................................................................................................7
2. USE CASES........................................................................................................................................................9
a. Actors..............................................................................................................................................................9
b. Use Cases and Description............................................................................................................................9
c. Use Case Diagram........................................................................................................................................11
3. DOMAIN MODELLING................................................................................................................................12
a. Domain Classes and Attributes...................................................................................................................12
b. Domain Model Class Diagram....................................................................................................................14
c. Associations...................................................................................................................................................14
4. USE CASE MODELLING..............................................................................................................................16
a. Fully Developed Use Case Description.......................................................................................................16
b. Activity Diagram..........................................................................................................................................18
c. System Sequence Diagram...........................................................................................................................19
d. CRUD Analysis.............................................................................................................................................20
References.............................................................................................................................................................21

1. SYSTEM REQUIREMENTS
a. Stakeholders
These are the individuals in an organization considered to interact or benefit with the system
either direct or indirect (Mohammad 2013, p. 215). They can be either the people enjoying
the system at present or in the future. The primary stakeholders to the medical management
practice system include:
Doctors- They will have daily interaction with the system as it is developed to work within
the medical centre. A high number of their activities will be performed through the system.
These activities will involve attending to the patients and inputting the patient's vital
information into the system that will be easily accessed by the business managers and the
receptionist to perform their duties.
Patients- The patients will also play a role in the system as it is design purposely to handle
various activities associated with the patient. The patient information will be stored in the
system, and they will also be able to make an appointment at the receptionist desk or via
phone.
Business managers- The managers will use the system by inputting all the necessary data at
the high level and retrieving it for the analysis. Moreover, activities related to financial will
be conducted by the managers through the system.
Nurses- The nurses are also part of the stakeholders as the system is designed such that the
nurses can record their related information such as the working hours and availability.
Receptionist staff- These are the operational and the internal stakeholders tasked with the
responsibility of recording patient's details into the system and document printing such as the
invoices.

IT Administrator- These are the people who will play a key role in maintaining the system
to ensure it functions properly. They will perform all the IT related duties for the maintenance
purpose.
Police- The police will take place into the system in the event of an emergency. The doctors
will make a call to the police to report any emergency that occurs while the patient is in a
consultant.
AA medical practice investor- These are the people with the financial interest to the
information produced such as the financial report details.
Below are the stakeholder’s dimensions (Nudurupati et al. 2015, p. 253).
b. Techniques
In the collection of data for analysis concerning certain research, various techniques are
employed. However, the application of these techniques varies according to the type of the
data being collected and the objective (Auberlet et al. 2014, p. 5). Example of these
techniques include:
 Joint Application Design (JAD)
 Observation
 Interviews
Operational Executive
Internal Business Manager
Doctor
Receptionist Staff
Nurses
AA medical practice investors
IT Administrator
External Patients Police

 Questionnaires
 Work and Product Sampling
 Prototyping
For these requirements, the best and appropriate techniques to be used in the data collection
are the questionnaires and the interviews. This is because the two techniques are the most
popular and effective especially in the system that is built from scratch as in our case (Gill et
al. 2008, p. 259). Although they are the best among the list, they, however, face some flaws
as they tend to take longer time compared to the other data collection techniques. This issue
will be mitigated by the use of the group interviewing technique. The objective of this data
collection will be to define the systems functional requirements to be built. This means that
the information collected must be able to define the scope, the task to be performed and the
boundaries of the system (Anyan 2013, p. 42). To achieve the objective, the interviewing
team must determine what kind of questions they are going to ask and who will answer them.
The interview will be conducted among the people with the knowledge on the similar system
also known as the domain experts and the users of the future system. Below are examples of
the questions regarding the system to be developed.
Sample Interview Question:
 Should the system be designed to provide duty roster?
 Should the doctor be issued with the authority to access the patient medical record and
make changes?
 Should the system store any doctor's sheet record including time?
 Should the system store the information regarding the availability of the doctor to the
work?
 What should be the maximum number of hours an employee should work?

 Is there any need for issuing doctors with electronic devices with an internal installed
application for making calls to the police in case of an emergency?
 Should the system allow storage of financial, and medical details of the patient for the
managers and receptions to perform their duties?
 Should the system allow the receptionist to access the appointment for the existing
and the new patients?
 Should the system allow the call-up for billing details for the business managers,
receptionists and the doctors to accomplish their task?
 Should the system allow invoice and script printing for the managers and doctors
respectively?
c. Primary Functional Requirements
These are the requirements performed by the system to ensure the system meets the user's
needs. They should ensure that they meet all the necessary needs for it to be effective. In
other words, the functional requirements are the business rules and the functions performed
by an organization in the real world (Li et al. 2014, p. 297). The main primary function
requirements for the systems are:
 The system should allow the doctors to make any necessary changes on the patients'
medical record. Moreover, the systems should store all the details entered by the
doctor either related to the doctor or the patient.
 The system should keep all the information related to the doctor's availability time in
the work for an effective rostering.
 The system should only roster the locum doctors for not more than 40 hours.
However, if rostered as a locum, a gap of 14 hours should be allowed before the
continuity of the next shift.

 It should have an installed application and a button for making a call to the police in
case of an emergency. The system should be able to transmit the patients recorded
information for consulting. Moreover, the system should be able to access the
information of the patient contained in the database (Lewis and Pflum 2015, p. 251).
 The system should be able to store the patient's financial details, personal information,
all the other patient's information separately.
 It should be able to store the patient's appointments to help the receptionist prepare
the new and existing patient's appointment sheet.
 The system should be able to call up the billing information through a special function
so that the business managers, receptionists and the doctors can accomplish their task.
 It should be able to report information, print invoices and scripts for the receptionist,
business managers, and the doctors.
d. Non-Functional Requirements
These are the activities not performed directly by the system (Slankas and Williams 2013, p.
12). In other words, they are the indirect functions of the systems apart from the objectives
set by the users to be performed by the system. They are the system's basic characteristics.
However, to differentiate between the functional and non-functional requirement for the
system, a special framework called the FURPS is used where F is for the functional
requirements and the other part URPS is for the non-functional requirements (Khan, Khanam
and Khan 2016, p.1034). The major non-functional requirements for the system include:
 The management system should be able to accommodate a large number of patients to
ensure the performance is not compromised.
 Due to many subsystems in the system that handle different information related to the
patients and the doctors, the system should, therefore, have the potential to provide

security to the patient's data. It should ensure that only authorized person can access
the data (Luo 2015, p. 125)
 The systems should ensure the performance requirements are not compromised by
responding to any request within a short period and also the system should be
available during the working hours with 98% certainty (Lawton and Parker 2002, p.
17).
 The system should provide backup services to the business data in the database to
ensure all the updates that have been made within the business hours are protected and
available (Prieto 2016, p. 450).
 The system should be able to log out the user within 20 minutes of inactivity
automatically.
 The system should be user-friendly in its operations to ensure easy execution of the
functions (Lee et al. 2014, p. 329).

2. USE CASES
a. Actors
The main actors include: business managers, doctors, receptionists and the nurses.
b. Use Cases and Description
Use Case Case Description
Roster creation The managers will add the name of the doctors and their
departments for easy identification.
They will moreover add the duration of time the doctors are
going to work together with the shift gap. The working
hours should not exceed 40 hours and a break of 14 hours
before the next shift should be allowed (Barrett and Holme
2018, p. 263).
Transmitting address In case of emergency, the doctors will click on the call
button and the information of the patient the doctor is
consulting will be able to be sent to the police.
Patient’s data record
addition/maintenance.
The receptionist will enter the patient’s data record into the
system and in turn the system will create and save patient’s
sheet.
Patient medical record
addition/maintenance
The doctor or the nurse will enter the patient’s medical
details into the system and the systems will create the
patients’ sheet and save the data.
Booking an appointment The receptionist will enter the existing and the new patient’s
details and the system will handle the appointment activity.
Information billing The receptionist will enter the information into the system
related to the payment and the system will, therefore,

identify the option either electronic or cash, process the
transaction and prints the invoice.
Financial record
maintenance
The business managers will feed the financial details related
to the patient into the system.
Information report
printing
The managers will enter all the financial related information
and the system generates the report.
Script report printing The doctors will feed the details related to the time to the
system and the system generate a script report.
Invoice printing The receptionist handles the invoice printing when needed
by the patient.

c. Use Case Diagram

3. DOMAIN MODELLING
a. Domain Classes and Attributes
Class Attributes
Patient.Personal Gender, Photograph, EyeColour, HairColour, PatientID
Weight, Height.
Staff DateOfBirth, FisrtName, MiddleName, Phone, Address,
StaffID, Surname
Patient.MedicalHistory VisitResults, PatientID, AppointmentID, VisitReason,
Patient.Medication MeciationName, DoctorID, PatientID, PerscriptionID
PurposeDirections.
Receptionist ReceptionistID
Appointments ReceptionistID, Duration, Type, PatientID, Time/Date,
AppointmentID, DoctorID.
Rostering StaffID, FinishTime/date, StartTime/date, RosterID,
WorkType
Patient.FinancialRecord MedicareNO, PatientID, InsuraceneNo, InsuranceName,
Outstanding,
Patient EmergencyContactPhone, Surname, FirstName,
MiddleName, DateOfBirth, EmergencyContactName,

Phone, Address, PatientID.
Nurse Type, Experience, Certificate, NurseID.
Doctor DegreeType, Specialization, Experience, DoctorID,
Certificate.
BillingSystem TrnsactionID, PatientID, TotalRebate, ReceptionistID,
BillAmmount.

b. Domain Model Class Diagram
c. Associations
1. A patient can only be offered one medication.
One medication can be offered to more than one patient.
2. One patient can receive one patient medication service
One medication service can be offered to many patients
3. One doctor can offer one medication service

One medication service can be offered by many doctors
4. One patient can have one patient medication history
Many medication histories can be offered to one patient.
5. A receptionist cannot make more than one appointment
One appointment can only be made by one receptionist.
6. A receptionist can only have zero or one billing system
One billing system can only be offered to one receptionist

4. USE CASE MODELLING
a. Fully Developed Use Case Description
Use Case Description.
Scenario: New patient appointment booking by the receptionist
Events triggering New patient boking an appointment with the doctor
Brief
description:
The system handles the appointment of all the new and existing
patient’s information fed by the receptionist.
Actors: Receptionists.
Related use
cases:
Create customer record use case can be used to invoke the related use
cases (Hoekstra 2015, p. 111).
Stakeholders: Patient, Doctor, Business Manager, Receptionist and Nurse.
Preconditions: The system should be available for patient booking. Additionally, the
timing between the patients and the doctor should be suitable
(Srivastava et al. 2016, p. 5).
Postconditions: Backup should be performed for any new patient record.
Activity flow Actor System
1.Patient request for
appointment and the
receptionist enter the details
into the system.
2.Receptionist identifies the
appropriate time for the patient.
1.The system creates the patient
details sheet.
2.The system generates the
PatientID.
3.The system returns the available
time for the doctor.
4.Both Appointment record and
AppointmentID are created.

3.The appointment to the
patient is confirmed
5.The system returns the final
report.
Exception
conditions:
1. Incorrect basic patient details.
2. Unavailability of the doctor.
3. Wrong keying of the patient details into the system.

b. Activity Diagram

c. System Sequence Diagram

d. CRUD Analysis
USE CASE Doctor Patient Manager Reception
Staff
Patient details
addition/maintenance
Read
Update
Read
Update
Read
Roster creation Read Create
Update
Delete
Information Billing Read Read Read
Update
Delete
Read
Update
Patient’s medical record
addition/maintenance
Read Read
Update
Read
Update
Invoice printing Read Read Create
Script report printing Read
Financial record maintenance Create
Update
Delete
Read
Update
Appointment booking Read Read
Update
Delete
Create
Update
Delete
Information report printing Read
Update
Delete

References
Anyan, F., 2013. The Influence of Power Shifts in Data Collection and Analysis Stages: A
Focus on Qualitative Research Interview. Qualitative Report, 18, p.36-56.
Auberlet, J.M., Bhaskar, A., Ciuffo, B., Farah, H., Hoogendoorn, R. and Leonhardt, A., 2014.
Data collection techniques. Traffic simulation and data: Validation methods and
applications, p.3-8.

Barrett, R. and Holme, A., 2018. Self-rostering can improve work–life balance and staff
retention in the NHS. British Journal of Nursing, 27(5), pp.261-265.
Gill, P., Stewart, K., Treasure, E. and Chadwick, B., 2016. Methods of data collection in
qualitative research: interviews and focus groups. British dental journal, 204(6), pp. 240-299.
Hoekstra, H.A., 2015. Value creation by software companies in the business-to-business
market (Bachelor's thesis, University of Twente), 22, pp. 103-121.
Khan, M.Z., Khanam, M.A. and Khan, M.H., 2016. Software Testability in Requirement
Phase: A Review. International Journal of Advanced Research in Computer and
Communication Engineering, 5(4), pp.1031-1035.
Lawton, R. and Parker, D., 2012. Barriers to incident reporting in a healthcare system. BMJ
Quality & Safety, 11(1), pp.15-18.
Lee, J., Wu, F., Zhao, W., Ghaffari, M., Liao, L. and Siegel, D., 2014. Prognostics and health
management design for rotary machinery systems—Reviews, methodology and
applications. Mechanical systems and signal processing, 42(1-2), pp.314-334.
Lewis, M.S. and Pflum, K.E., 2015. Diagnosing hospital system bargaining power in
managed care networks. American Economic Journal: Economic Policy, 7(1), pp.243-274.
Li, F.L., Horkoff, J., Mylopoulos, J., Guizzardi, R.S., Guizzardi, G., Borgida, A. and Liu, L.,
2014, August. Non-functional requirements as qualities, with a spice of ontology.
In Requirements Engineering Conference (RE), 2014 IEEE 22nd International (pp. 293-302).
IEEE.
Luo, H., CIM TECHNOLOGY INC., 2015. Wearable mini-size intelligent healthcare system.
U.S. Patent, pp. 120-136.

Mohammad, A., 2013. Healthcare service quality: Towards a broad definition. International
journal of health care quality assurance, 26(3), pp.203-219.
Nudurupati, S.S., Bhattacharya, A., Lascelles, D. and Caton, N., 2015. Strategic sourcing
with multi-stakeholders through value co-creation: An evidence from global health care
company. International Journal of Production Economics, 166, pp.248-257.
Prieto, L., Tamm, G. and Stantchev, V., 2016. Towards a Software Engineering Approach for
Cloud and IoT Services in Healthcare. In International Conference on Computational
Science and Its Applications (pp. 439-452). Springer, Cham.
Slankas, J. and Williams, L., 2013. Automated extraction of non-functional requirements in
available documentation. In Natural Language Analysis in Software Engineering
(NaturaLiSE), 2013 1st International Workshop on (pp. 9-16). IEEE.
Srivastava, S., Khurana, P.S., Rai, A., Cheema, A.S. and Srivastava, P.K., 2016. High
performance and adaptive lab report generation in hospital management information systems.
In India Conference (INDICON), 2016 IEEE Annual (pp. 1-6). IEEE.