CIS2000 Systems Analysis and Design Proof Reading Services

CIS2000 Systems Analysis and Design OZ Assignments

CIS2000 Systems Analysis and Design Proof Reading Services

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 may enjoy the benefits in the future. The primary stakeholders to the medical health management practice system include:

1. Doctors- The doctors will 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 that will be easily accessed by the business managers and the receptionist to perform their duties.

2. Patients- The patients will also play a role in the system as the system 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.

3. Business managers- The managers will use the system by inputting all the necessary data at the high level and retrieving for the analysis. Moreover, activities related to the financial to the system will be conducted by the managers through the system.

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

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

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

7. Police- The police 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.

8.AAmedical 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, Bhattacharya, Lascelles and Caton 2015, p. 253).

Operational

Executive

Internal

Business Manager

Doctor

Receptionist Staff

Nurses

AA medical practice investors

IT Administrator

External

Patients

Police

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:

1. Joint Application Design (JAD)
2. Observation
3. Interviews
4. Questionnaires
5. Work and Product Sampling
6. Prototyping

For this 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, Stewart, Treasure, and Chadwick 2008, p. 259). Although they are the best among the list, they, however, face some flaws as they tend to take a long time. 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 example of the questions regarding the system to be developed.

Sample Interview Question:

1. Should the system be designed to provide duty roster?
2. Should the doctor be issued with the authority to access the patient medical record and make changes?
3. Should the system store any doctor's sheet record including time?
4. Should the system store the information regarding the availability of the doctor to the work?
5. What should be the maximum number of hours an employee should work?
6. Is there any need for the issuing doctors with electronic devices with an internal installed application for making calls to the police in case of an emergency?
7. Should the system allow storage of financial, patient and medical details of the patient for the managers and receptions to perform their duties?
8. Should the system allow the receptionist to access the appointment for the existing and the new patients?
9. Should the system allow the call-up for billing details for the business managers, receptionists and the doctors to accomplish their task?
10. 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 that it 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:

1. 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.
2. The system should keep all the information related to the doctor's availability time in the work for an effective rostering.
3. 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 shift.
4. The systems 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).
5. The system should be able to store the patient's financial details, personal information, all the other patient's information separately.
6. The system should be able to store the patient's appointments to help the receptionist prepare the new and existing patient's appointment sheet.
7. 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.
8. The systems 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:

1. The management system should be able to accommodate a large number of patients to ensure the performance is not compromised.
2. Due to many subsystems in the system that handle different information related to the patient and the doctors, the system should, therefore, have the potential to provide security to the patient's data. It should ensure the only authorized person can access the data (Luo 2015, p. 125)
3. 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).
4. 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 strategies hours are protected and available (Prieto 2016, p. 450).
5. The system should be able to log out the user within 20 minutes of inactivity automatically.
6. The system should be user-friendly in its operations to ensure easy execution of the functions (Lee et al. 2014, p. 329).

Use cases

a. Actors

The main actorsinclude:business managers, doctors, receptionist and the nurse.

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 patients record into the system and in turn the system will create patient’s sheet and save it.
Patient medical record addition/maintenance	The doctor or the nurse will enter the details of the patients 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.
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, processes the transaction and prints the invoice.
Financial record maintenance	The business managers will feed the financial details related to the patient and the systems records the information.
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.

Use Case Diagram

Domain modelling

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, Specializationm, Experience DoctorID, Certificate.
BillingSystem	TrnsactionID, PatientID, TotalRebate, ReceptionistID, BillAmmount.

Domain Model Class Diagram

Associations

1. A patient can only be offered one medication.
2. One medication can be offered to more than one patient.
3. A patient can only access one patient medication history
4. Many patient’s medical history can be offered to exactly one patient.
5. One patient can receive one patient medication service
6. One medication service can be offered to many patients
7. One doctor can offer one medication service
8. One medication service can be offered by many doctors
9. One patient can have one patient medication history
10. Many medication histories can be offered to one patient.
11. A receptionist cannot make more than one appointment
12. One appointment can only be made by one receptionist.
13. A receptionist can only have zero or one billing system
14. One billing system can only be offered to one receptionist

Use case modelling

Fully Developed Use Case Description

Use Case	Description.
Scenario:	New patient appointment booking by the receptionist
Events triggering	New patient boking ab 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.
Stakeholders:	Patient, Doctors, Business Manager, Receptionists and Nurse.
Preconditions:	The system should be available for patient booking and also the timing between the patients and the doctor should be suitable (Srivastava, Khurana, Rai, Cheema and Srivastava 2016, p. 5).
Postconditions:	Backup should be performed for any new patient record.
Activity flow	Actor	System
	1.Patient request for appointment and te receptionist enter the details into the system. 2.Receptionist identifies the appropriate time for the patient. 3.The appointment to the patient is confirmed	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.Appointment record is created and AppointmentID created. 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 int the system.

Activity Diagram

System Sequence Diagram

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. Lawton, R. and Parker, D., 2012. Barriers to incident reporting in a healthcare system. BMJ Quality & Safety, 11(1), pp.15-18.
8. 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.
9. 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.
10. 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.
11. Luo, H., CIM TECHNOLOGY INC., 2015. Wearable mini-size intelligent healthcare system. U.S. Patent, pp. 120-136.
12. Mohammad, A., 2013. Healthcare service quality: Towards a broad definition. International journal of health care quality assurance, 26(3), pp.203-219.
13. 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.
14. Prieto, L., Tamm, G. and Stantchev, V., 2016. Towards aSoftware EngineeringApproach for Cloud and IoT Services in Healthcare. In International Conference on Computational Science and Its Applications (pp. 439-452). Springer, Cham.
15. 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.
16. 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