Project Analysis
Care Solutions Aged Care
7002ICT Systems Development
Assignment 1 – Project Management
Trimester 2 2022
According to Roth, Wixom, and Dennis (2021), functional requirements are the functionalities of the system and they are more described as what the system needs to do. Giving a bicycle as an example, the bicycle needs to move forward through pedaling. On the other hand, the non-functional requirements of a system are the characteristics of the system (Roth, Wixom, & Dennis, 2021). Still giving the same example of a bicycle, the characteristic may be it has a nice blue seat. We will use FURPS+ framework to deduce the functional and non-functional requirements of the Care solution hospital system. FURPS+ in full is Functionality, Usability, Reliability, Performance, and Security and it is a framework widely used in software engineering to come up with functional and non-functional requirements. The F deals with the functional requirements of the system and the URPS+ deals with the non-functional requirements. The addition sign in the FURPS+ includes other things such as supportability, design constraints, physical, interface requirements, and implementation (Roth, Wixom, & Dennis, 2021).
1.1 Functional Requirements
The functional requirements of the Care solution hospital has been tabulated using the table below using sub-systems. According to Ibm (2021), a subsystem is a single unit of a system that works independently and on its own environment. A sub-system can also have other sub-systems and when they are all combined together they form a system (Ibm, 2021).
Functional Requirements
Sub-system
Function
Description
Patient Appointment Booking Subsystem
Create/ Update/ Delete patient record
The system should allow a patient to create, update, delete his/her record when making an appointment
Search functionality
The system should allow a patient to search for area of need such as orthopedic.
Add/ delete doctors
The system should allow doctors who are available to see patients on a particular date to be added by patients when making an appointment.
Send appointment reminders
The system should be able to send appointment reminders to both the patient and the doctor via Short Message Service (SMS) and email.
Cancel/ Rescheduling appointments
The system should allow cancelling and rescheduling of appointments from the patient. The system should only allow rescheduling but not cancelling of the appointment from the doctor.
Retrieval of patient history
The system should permit retrieval of patient history to the doctor when a patient makes an appointment
Addition of appointment notes
The system should allow addition of appointment notes to be added to the booking.
Price display
The system should display the consultation fee of any doctor from general doctor to specialists such as optician
Email/ print appointment
The system should allow the patient to email or print his/her appointment for
Pharmacy subsystem
Show drugs in store
The system should be able to show drugs in store
Price of drugs
The system should be able to show the price of drugs purchased by a patient
Print drugs
The system should be able to print the name and price of drugs purchased by a patient
Medical Diagnosis Subsystem
Diagnose diseases
The system should be able to diagnose diseases from the record given by the patient. For example, if you have prolonged headaches, chest pains, nose bleeding, sweating, then the system should be able to inform you that you are suffering from hypertension.
1.2 Non-Functional Requirements
The non-functional requirements of the system relate to usability, reliability, performance, security, and other things such as physical, implementation requirements and design constraints. The usability deals with how user-friendly of the system or lack of it. Reliability deals with how you can depend on the system. Will the system be up and running every other time or sometimes it will be down due to various reasons such as network connection or maintenance. Performance deals with how fast the system responds to tasks or commands. Performance consists of how fast the system loads when started and does it give response in less than one second when a patient requests for his/her data. Security deals with the security of the system and this consists of the ease of the system being hacked and whether the data being transmitted is encrypted among other things. The physical requirement looks at whether the system is dependable on certain hardware architecture such as the system should only run on an 8 GB Random Access Memory (RAM). The implementation requirement looks at the programming language that will used to implement the system such as Python, Java, JavaScript, etc. the following table shows the non-functional requirements of the system.
Non-Functional Requirements
FURPS+ category
Requirements
Usability
The website should have a modern look and feel
The website needs to be informative
The navigation menus to be easily accessible
The graphics used need to be of high quality
The website needs to be responsive and adapt well on mobile devices.
The website needs to support several languages but only those that are common, for example, English, French, German, etc.
The website should have instant message service where patients can get instant message from support team regarding their queries.
Performance
The website needs to load under 0.2 seconds
The website should be able to handle at least 20,000 transactions per day
The website should be able to handle more than 1000 users at the same time.
Reliability
The website should be available at all times
In case of down time the system needs to be up and running in less than one hour
The system should have a daily incremental backup and a rollback plan in case of failure.
Security
The website needs to use https protocol for connection
The website needs to use SSL/ TLS encryption protocol
The website should use multi-factor authentication for users where a confirmation code is sent in form of a Short Message Service (SMS).
The system should be able to allow only doctors to access patient’s sensitive information and no other users.
Implementation
The website will be implemented using a Content Management System called WordPress that depends on PHP programming language and MySQL database
Program version will be done using Git
Documentation of the website will be done using Microsoft Word
Graphics will be designed using Adobe CC Suite.
Physical
The only physical requirement is that the website needs to be hosted on a server that has 32GB of RAM and CPU of 8+ cores.
The Care Solution system has various stakeholders and they can be categorized as internal and external stakeholders. The internal and external stakeholders can further be categorized as operational and executive. The following table shows the stakeholders.
Stakeholders
Operational
Executives
Internal
Doctors
Head Nurses
Chief Executive Officer
Accountants
Department Managers
Reception Staff
Book keepers
Surgeons
Anesthesiologists
Pharmacists
External
Patients
Australian taxation office
Suppliers
Insurance company
Web development consultancy firm
Auditing firm
IT personnel
Database administrator consultants
Internal-Operational Stakeholders
These are people who interact with the system on a day to day basis and they include doctors, head nurses, accountants, reception staff, book keepers, surgeons, and anesthesiologists. The doctor will look at the system to see the medical history of a patient and booked patients. The accountant will look at the financial section of the system. The head nurse will look at the system to assign nurses on a particular patient. Surgeons and anesthesiologists will look at the system to know operation that will be underway at a given time and whether it will need anesthetic or not. The pharmacist will be able to see drugs prescribed to a patient.
Internal-Executive Stakeholders
The internal-executive stakeholders are personnel who work in the hospital and may interact with the system for various reasons such as the Chief Financial Officer may interact with the system to see financial records of the organization.
External-Operational Stakeholders
These are people who do not work in the hospital but they interact with the system. Patients will interact with the system to book appointments, check prices and how much they need to pay after being treated among others. Suppliers will look at what the hospital needs and restock before they run out of stock and this may include things like surgical blades, gloves, etc. The web consultancy firm will look at updates and update the system from time to time, upgrade when needed and security matters. The IT personnel will ensure that the system is working as required and helping internal personnel when needed. The database administrator will be looking at the database to check whether it is working as needed and it is secure from SQL injection.
External-Executive Stakeholders
The external-executive stakeholders do not work in the hospital but they have an interest with the system because of various reasons such as taxation, hospital auditing, etc.
The questionnaire has open-ended and close-ended questions and its main purpose is to give an insight on the proposed system and areas that need improvement. The questionnaire targets the employees of the hospital and they include the people who will interact with the system n daily basis such as doctors, surgeons, head nurses, accountants, etc.
Care Solution Hospital Questionnaire
Care Solution Hospital is building an online management system that will manage the hospital operations. The purpose of this questionnaire is to look at the current processes that will help in the development of the proposed system. If you have further comments or questions you can contact your immediate supervisor.
Section One
Will patient appointment improve your work as a doctor? YES/NO
Will a medical diagnosing system assist you as a doctor? YES/NO
Do you like the manual system in place? YES/NO
Do you think the proposed system will bring changes? YES/NO
Questions
Strongly Disagree Strongly Agree
How can you rate your IT skills
0 1 2 3 4 5 6 7 8 9 10
How can you rate your database skills
0 1 2 3 4 5 6 7 8 9 10
Section Two
Do you have any other IT certification such as Word, Excel, etc. Explain
————————————————————————————————————————————————————————————————————————————————————-
As a pharmacist, will the proposed system help you do your work better? Explain
……………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………….
From the proposed system, what improvements can be made?
………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………
The table below shows the use case description of the pharmacy subsystem. The use case shows the activity in the pharmacy subsystem whereas the actor indicates the person or people involved and finally the description describes what transpires in that use case.
Brief Use Case Description
Use Case
Actors
Description
Receive prescription of patient from the doctor
Doctor
The pharmacy subsystem reflects by showing prescribed prescription of a patient from the doctor.
Keying in the index of a patient
Pharmacist
The pharmacist logs in to the system and keys in the index of a patient using the browser to generate his/her records.
Checking of drugs in the system
Pharmacist
The browser returns the drugs prescribed to a patient and per every drug the system shows the prescribed quantity and the number in stock
Payment of drugs
Patient
The patient pays for the drugs using cash or using a card.
Printing of receipt
Pharmacist
When payment is complete the pharmacist clicks on the print icon and a receipt is printed for the patient as he/she receives the drugs.
The diagram below shows the use case diagram of pharmacy subsystem and shows users and how they interact with the system.
From the diagram we can see that a doctor prescribes drugs after meeting the patient and the data is reflected in the pharmacy system. The pharmacist logs in and keys in the patient unique number (index number) and the pharmacist can see the prescribed drugs and amount to be paid by the patient. The pharmacist can only see the drugs in stock or out of stock. The patient can make cash payment or using a bank card. When the patient decides to use a card, he gives the card to the pharmacist and it is swiped and verification is done to check whether the card has not expired, money is in the bank, and the authentication of the card by entering the pin number of the card.
The domain model class diagram shows the relationship and association of classes of the system. The diagram below shows the model class diagram
From the diagram we can see that prescribe several drugs to the patient and a stock can store several drugs. We can also see that a pharmacist can deal with many patients and a he/she can deal with a lot of drugs at a given time. The diagram also shows that a patient can make several payments and there is a relationship of card with payment.
A fully developed use case description shows how the user of the system will interact with it in detail. Some preconditions need to be satisfied in order for the use case to execute and also some post conditions need to be achieved when the use case is done executing. The table below shows our use case.
Fully Developed Use Case Description
Use Case Name
Collecting drugs
Scenario
A patient wants to collect drugs from the pharmacy
Triggering event
A doctor saves a patient’s prescription and the data can be seen by the pharmacist
Brief description
The doctor writes a patient’s prescription using the system after diagnosing the patient and the data can be seen by the pharmacist. The patient is sent to the pharmacy to pick his/her drugs.
Actors
Doctor, Pharmacist, Patient
Related use cases
Open patient file, search patient, choose payment method, verify payment
Preconditions
The system is available
The doctor has seen the patient
The doctor has written the prescription
The hospital pharmacy is open
Postconditions
The patient’s file is in the system
Drugs are given to the patient
Payment is done
Receipt is given to the patient
Flow of activities
Doctor
Pharmacist
Patient
System
Bank
Sees the patient and diagnose him/her and writes prescription of drugs
The prescription reflects in the system
Logs in to the system
Gives id number
Keys in the id number
1. Finds the patient
Search for drugs
Find drugs
Shows drugs in stock
Shows payment options
Swipes card
Enter card details
Verifies card details
Completes transaction.
6.1. issues card
6.2. Issues drugs
6.3. Issues receipt
Collects drugs
Collects receipt
6.1.1.1. System is updated
Exception conditions
Patient file not found
Patient file is not updated
Patient payment card lacks money
Patient payment card has expired
From the table we can see that our use case is collecting drugs from the pharmacy where the patient is sent by the doctor. Our triggering event is when the doctor writes a prescription and saves it in the system for it to be accessed by the pharmacist. The actors in our use case are doctor, pharmacist, and patient.
According to Tegarden, Wixom, and Dennis (2020), an activity diagram is a diagram that shows the “behaviour in a business process”.
The first column represents the doctor, the second the pharmacist, the third system, the fourth the patient, and lastly the bank. We can see that the activity starts when the doctor updates the system with the prescription drugs prescribed to the patient. From the diagram we can see that the system is reflected with the updated drugs and the pharmacist goes ahead and logs in when the patient appears in site or the system always remains logged in. The pharmacist requests for an identity card from the patient and he/she searches for the patient records using an id number. The pharmacist can view the drugs and request for payment. The payment can be done using cash or a card. If the payment is cash, the system is updated and the patient is issued a receipt. If the payment is deducted from the bank or insurance company then the patient issues the bank or insurance company card. The card is swiped and the bank verifies the card after the patient inputs a pin number. Payment is done and the system is updated. After the system reflects the patient is issued a receipt.
According to Tegarden, Wixom, and Dennis (2020), a system sequence diagram is a diagram that shows messages that are passed from one object to another over time in a use case. The following diagram shows our sequence diagram for collecting drugs use case.
Ibm (2021). Subsystems. Ibm. https://www.ibm.com/docs/en/i/7.2?topic=concepts-subsystems
Roth, R., Wixom, B., & Dennis, A. (2021). System Analysis and Design. (8th ed.). John Wiley & Sons, Inc.
Tegardden, D., Wixom, B., & Dennis, A. (2020). Systems analysis & design: an object oriented approach
With UML. (6th ed.). John Wiley & Sons.
