| Version 10 (modified by , 6 years ago) ( diff ) |
|---|
Vision
Version <1.0>
Table of Contents
3. Stakeholder and User Descriptions
10. Documentation Requirements
11. Appendix 1 - Feature Attributes
Vision
1. Introduction
1.1 Purpose
The purpose of this document is to specify and perceive the goals and capabilities of this system. It also states the various constraints which the system will be abide to. This document further leads to clear vision of the software requirements, specification and capabilities which are to be exposed to the development, testing team and end users of the software.
1.2 Scope
The system being described generally provides management of all activities among the hospital staff and the patients. The system will be used in any hospital, clinic, dispensary or Pathology laboratories in order to get information from the patients and then store that data for future usage. The current system in use is a paper-based system. It is too slow and cannot provide updated lists of patients within a reasonable time frame. The intention of the system is to reduce over-time pay and increase the number of patients that can be treated accurately. Requirements statements in this document are both functional and non-functional.
1.3 Definitions, Acronyms and Abbreviations
Appointment is an arrangement to meet someone at a particular time and place. In this context we are going to use it for meeting a doctor when a patient has health issues.
Patient - institution's patient can be any citizen of any age who is regulated as a patient in the institution using the system according to the laws and its policy.
Institution which is using the system can be any health care institution (like Hospital or Ministry of Health) that has bought a licence to use the system.
Appointment request is a request for scheduling an appointment (visit to the doctor), after which the system should return possible time slots.
GP - General Practitioner is a doctor that implies prevention, education, care of the diseases and traumas that do not require a specialist, and orientate the patients towards a specialist when necessary. Each patient must have one GP.
Available time slot is the slot when a patient can get a scheduled appointment for their GP. It has to be free time when no other patients have scheduled appointments at the same GP. The average time would be 15 minutes, but it is going to be regulated by the system administrator.
PIN - personal identification number, it is a unique identifier for each citizen.
Specialization - something that a doctor-specialist has studied for. He is expert for this and works only in this field.
1.4 References
1.5 Overview
In the further part of the document, the objectives of the system are specified, what are the benefits of using it, the description of the environment on which this system is built, its users, alternative solutions are considered, the cost of building this system, etc.
2. Positioning
2.1 Business Opportunity
The feasibility of the project is analysed in this phase and business proposal is put forth with a very general plan for the project and some cost estimates. During system analysis the feasibility study of the proposed system is to be carried out. This is to ensure that the proposed system is not a burden to the institution using the system. For feasibility analysis, some understanding of the major requirements for the system are essential.
2.2 Problem Statement
- Not having computerized all details regarding the patients and the hospital.
- Not having good overview what time is convenient for both the patient and the doctor.
- Not having scheduled all the services of specialized doctors and emergencies provided by hospital to be fully utilized in effective and efficient manner.
- If the medical store issues medicines to patients, the stock status of the medical store and vice-versa should be reduced.
- It should be able to handle the test reports of patients conducted in the pathology lab of the hospital.
- There is not updated inventory, it needs to be updated automatically whenever a transaction is made.
- There is no a system where all the records for the patients exist, these should be kept up to date and kept in a system for historical purposes.
2.3 Product Position Statement
| For | The management of the institution using the system, its current employees and patients |
| Employees | Need an easy access to the free time available for further appointments and review of patient's record |
| Patients | Can view their own appointments and reports |
| Different than | Paper-based system |
| This product | Is available online and does not require additional expenses |
3. Stakeholder and User Descriptions
3.1 Market Demographics
The system is intended for health institutions. It should be a part of the process for organizing patients' appointments and having overview of their diagnosis, therapy and health progress in one place. The number of users is limited to the number of employees in the institution using the system, as well as the patients that are under its auspices.
3.2 Stakeholder Summary
| Name | Represents | Role |
| System administrator | As an administrator the user is responsible for supervising and maintaining the system, as well as taking care the system to have all the data updated. | As system admin the user is able to review the reports regarding the hospital activities, update the type of rooms and departments that are needed, keep track of what type of doctors specialists are missing in the hospital staff etc. |
| Doctors | A doctor in the system can become any person that gets employed on the position doctor in the institution using this system. | Doctors will be able to add new patients and to update the appointments, as well as review the appointments. They can write recipes, add diagnoses and place/dismiss a patient. |
| Nurses | The nurses help the doctors. | They can list all the patients and update information for the patients' appointments. |
| Patients | Patients are the people that need health care. Who can become a patient in the institution is regulated with its policy which is outside the concern of the system. | They can view their appointments already made and the ones that are scheduled in the future, as well as reports for the appointments. |
| Responsible institutions | The responsible institutions are the sponsors for this system's development and the ones that are going to use it later on for their purposes. It could be the Ministry of Health or the institution itself. | / |
| System developers | System developers are those who are responsible for having the system completed successfully within the stipulated deadline (designers, coders, testers). | Maintain the system. |
3.3 User Summary
| Name | Description | Stakeholder |
| Not technically skilled | These are small amount of users and are usually older people with very little technical knowledge or not at all. They will gain help from other people. | Patients |
| Standard users | The largest percentage of system users are going to be technically skilled people. They have no difficulty in adapting to more complex systems and are likely to actively use the system. | Doctors, Nurses, Patients, System administrator |
| Employees | All the institution's staff. They will use the system for help in human resources management. | Doctors, Nurses |
| Patients | Patients that are going to visit the doctor according to the time slot that has been thrown out by the system. | Patients |
3.4 User Environment
The number of people included in one task will be mostly two - one patient and one doctor, but it can happen the nurses to help (like in emergency cases and similar).
The users can use the system from any device that has internet connection.
3.5 Stakeholder Profiles
3.5.1 <Users>
| Representative | Doctors, Nurses, Patients |
| Description | The users will be able to make appointments and review them according to their type as explained under 3.2 |
| Type | Doctors, Nurses, Patients |
| Responsibilities | The employees and patients to be on time at their working places and to do their job. |
| Success Criteria | Coming to the doctor on time and give the patient appropriate medicament. |
| Involvement | |
| Deliverables | |
| Comments / Issues | Unavailability of the system |
3.5.2 <System administrator>
| Representative | |
| Description | The system administrator will supervise and maintain the system. He will keep a track if the rooms that are offered by the system are indeed free and will take care of staff's absences and replacements within the system. |
| Type | |
| Responsibilities | Taking care of the system, maintain it and solve problems and inconsistencies. |
| Success Criteria | The system is available when it should be and its state is consistent with the institution's state (same number of rooms available etc.) |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.5.3 <Institution using the system>
| Representative | |
| Description | They are going to be sponsors of the development of the system and then are going to use it for their own needs. |
| Type | Health institutions |
| Responsibilities | Finance the development of the system |
| Success Criteria | Successful integration of the system in institution's working |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.5.4 <System developers>
| Representative | |
| Description | System developers are those who are responsible for developing the system (designers, coders, testers). |
| Type | Developers |
| Responsibilities | Designing, coding and testing the system. |
| Success Criteria | Successful completion within the stipulated deadline. |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.6 User Profiles
3.6.1 < Неприлагодени на технологијата >
| Representative | Иако претставуваат мал дел од корисниците сепак не значи дека се помалку важни од останатите. |
| Description | Имаат потешкотии да се прилагодат кон новите функционалности. Многу мал дел од корисниците. Обично постари лица. Имаат потешкотии да се прилагодат на покомлексни системи. |
| Type | професори, студенти, асистенти, демонстратори. |
| Responsibilities | Не сакаат да се оптоваруваат со користење и учење како да се користат покомплексните системи. |
| Success Criteria | Едноставен за користење на македонски и анлиски јазик |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.6.3 <Стандардни корисници>
| Representative | Најголем процент од корисниците на системот обично помлади личности. |
| Description | Немаат никакви потешкотии кон прилагодувањето кон покомплексните системи и најверојатно активно ќе го користат системот. |
| Type | студенти, професори, асистенти, демонстратори |
| Responsibilities | |
| Success Criteria | Едноставен за користење и да дозволи пристап 24/7. |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.7 Key Stakeholder / User Needs
| Need | Priority | Concerns | Current Solution | Proposed Solutions |
| Системот треба да има дозвола на студентот да им одговори да праќаат пораки до предавачите | Must | Може да им праќаат пораки на меил или приватни пораки на courses. | ||
| Системот треба да им дозволи на предавачите да им одговараат на студентите | Must | Може да им одговараат на меил, преку приватни пораки на courses или лично за време на консултации. | ||
| Системот треба да овозможи приватност во комуникацијата студент- предавач | Must | Пораките на меил и приватните пораки на courses се невидливи за другите. | ||
| Системот треба да овозможи поставување на пораки од предавачите кои ќе бидат достапни за сите студенти | Must | Ова е овозможено со форумите кои постојат за секој курс и преку соопштенија што може предавачите да ги поставуваат на курсот. | ||
| Системот треба да овозможи креирање на јавни дискусии на некои теми | Should | Ова е овозможено со форумите кои постојат за секој курс. | ||
| Системот треба да овозможи некакво класифицирање на пораките по некаои критериуми | Could | Не е овозможено. | ||
| Системот со секоја поставена порака треба да асоцира дата на поставување и личност која ја поставила | Must | Овозможено како на форумите така и на приватните пораки. | ||
| Системот треба да овозможи архивирање на сите пораки и нивна достапност до соодветните корисници | Should | Овозможено е и за пораките пратени на форумите и приватните пораки. |
3.8 Alternatives and Competition
3.8.1 Current system for making appointments
This system which is in current use is available only for the institutions using it. Disadvantage is not having all the patients' records in one place, as well as the patients not being able to review their reports by them selves anytime.
4. Product Overview
4.1 Product Perspective
The application will be windows-based, self contained and independent software product. It is necessary all employees and the management of the institution which uses it to have access to it and credentials provided. Only the current employees have access to system as the type of user they are. For instance if a doctor stops working in a hospital, they lose the credentials for the system and can no longer access it.
4.2 Summary of Capabilities
Customer Support System
| Customer Benefit | Supporting Features |
| Easy to use. | Will be made simple so it can be used by ordinary citizens who have only basic technology knowledge. |
| Available in English with possibility to be upgraded with translations in another languages. | / |
| Available during the working hours of the institution, plus 99% of the remaining time. | Patients will be able to make an appointment request anytime. |
| The system must archive all the appointments made and the reports along with them. | For each appointment save its date, the patient, diagnosis and medication. |
| The system should be protected from unauthorized and unauthenticated access. | Each patient has access only to their respective data, and each doctor has access only to their patients' data. |
4.3 Assumptions and Dependencies
The patients of the system once registered will remain constant, unless they change the institution and the employees accounts will be changed along with the employees current status because the system can be used only by the institution's current employees and patients.
4.4 Cost and Pricing
4.5 Licensing and Installation
5. Product Features
Системот треба да овозможи креирање на јавни дискусии на некои теми.
Системот со секоја поставена порака треба да асоцира дата на поставување и личност која ја поставила.
Системот треба да овозможи некакво класифицирање на пораките по некаои критериуми.
Системот треба да овозможи поставување на пораки од предавачите кои ќе бидат достапни за сите студенти.
Системот треба да овозможи архивирање на сите пораки и нивна достапност до соодветните корисници.
Системот треба да овозможи приватност во комуникацијата студент- предавач.
Системот треба да им дозволи на студентите да праќаат пораки до предавачите.
6. Constraints
The system should be protected for access by unauthorized people. Only logged in users can see the details that they are supposed to.
7. Quality Ranges
The system needs to be easy to use. The system should be available in English with a possibility to be upgraded with new languages in future.
The system should be available online all the time within the hospital working hours.
The system should archive all appointments made, along with the reports for each of them.
8. Precedence and Priority
The most important feature is that the system should provide the list of appointments all the time during the hospital's working hours.
9. Other Product Requirements
9.1 Applicable Standards
Regarding the fact that the system will be used within the hospital environment, it needs to be easily maintainable and portable if needed.
9.2 System Requirements
There mustn't be limitation of the number of users who are online at the same time.
There mustn't be limitation of the number of appointment requests send by a patient.
The user must make an appointment only to the doctor who is user's GP.
9.3 Performance Requirements
The number of patients in a certain period of time intended for appointment must be limited to maximum one. If it is noted that there is big demand for appointments (for example in winter during some flu period) then the system will provide the institution to be able to notice the frequency, so they will know that they should hire new employees (for example doctors).
9.4 Environmental Requirements
If users need some help (they have technical problems or they don't know how to do what they want) they can use the On-line Help.
10. Documentation Requirements
10.1 User Manual
All current employees of the institution using the system will get username and password. Of course the password can be changed later on. The patients will be able to create new account - to register.
10.2 On-line Help
It is predicted the system to offer online help. It means that there will be a page where will be written some general guidelines for using the system, there will be a part FAQ (frequently asked questions), and for more complex problems like not being able to login and similar technical problems will be intervened by system administrators.
10.3 Installation Guides, Configuration, Read Me File
The system for the user will represent a webpage where with its username and password can login and use it from any browser (Firefox, Opera, Chrome etc.).
10.4 Labeling and Packaging
11. Appendix 1 - Feature Attributes
11.1 Status
| Proposed | The system must be available online. The system has to response to the patient with an available slot. The system must allow the doctors to have a review of their appointments. The system has to sort the patients' records by date. |
| Approved | The system has to be protected from unauthorized and unauthenticated access. Each slot must be unique for each patient at 1 doctor. The system has to allow the patients to send appointment request. The system has to keep a track of the date when an appointment has been made. The system must be easy to use for people of all ages. The system must provide option for upgrading it in another language for those who are not familiar with English language. |
| Incorporated | / |
11.2 Benefit
| Critical | The system must be available online. The system has to response to the patient with an available slot. Each slot must be unique for each patient at 1 doctor. The system must allow the doctors to have a review of their appointments. The system has to be protected from unauthorized and unauthenticated access. |
| Important | The system has to allow the patients to send appointment request. The system has to keep a track of the date when an appointment has been made. The system must be easy to use for people of all ages. The system must provide option for upgrading it in another language for those who are not familiar with English language. |
| Useful | The system has to sort the patients' records by date. |
11.3 Effort
The team consists of two students who are developing this project as a part of course curriculum supervised by one professor.
11.4 Risk
The risk is the system to be developed but never be used by some institutions.
11.5 Stability
The development of the system should not contain major concessions because we have our goals specified in the first phase and we us team will give our best to accomplish all the initial ideas and agreements given in the documents which are made during the first phase of software development.
11.6 Target Release
It is expected this system to have its first initial release, with basic requirements done in January 2018.
11.7 Assigned To
We will divide the tasks, clearly specifying what is expected of us to do, what are the allowed concessions, and to what extent and for how long it is planned the task to be finished. In consultation with each other, as well as with the supervising authority, each problem will be overcome.
11.8 Reason
The reason for the development of this system, as mentioned before, is the simplification of the whole process of making appointments, perspicuous schedule of any doctor at a certain time period. That will help in avoiding unnecessary waiting for appointments, help staff have a better review of a patient's illness, given therapy and health progress.
