| Version 6 (modified by , 7 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
CFD – Context Flow Diagram
DFD – Data Flow Diagram
IDE – Integrated Development Environment
SQL – Structured Query Language
SRS – Software Requirement Specification
GUI - Graphical User Interface
Name: System administrator
Brief description: 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, what type of doctors specialists are missing in the hospital staff etc.
Name: Doctos
Brief description: 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. A doctor in the system can become any person that gets employed on the position doctor in the hospital using this system.
Name: Nurses
Brief description: The nurses help the doctors. They can list all the patients and update information for the patients visit.
Name: Patients
Brief description: Patients are all the people that need health care. They can view their appointments already made and the ones that are scheduled in the future, as well as invoices for the appointments.
Name: Responsible institutions
Brief description: 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 hospital itself.
Name: Medicine person
Brief description: A medicine person is a person that is not going to be involved into using or developing the system, but is going to help us reach our goals by informing us what are the needed requirements that a hospital would need and want in order to be easier to fit into the already existing system for health care.
Name: System developers
Brief description: System developers are those who are responsible for having the system completed successfully within the stipulated deadline (designers, coders, testers).
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 company. 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 are 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.
- A system where all the records for the patients doesn't exist, these should be kept up to date and kept in a system for historical purposes.
2.3 Product Position Statement
| For | The current employees and the management of the institution using the system |
| 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 diagnosis |
| 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 patient's 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 |
| Систем администратор | Систем администратор ќе биде одговорен за надгледување и одржување на системот. | Тој ќе ги контролира пораките кои ќе се испраќаат и коирсниците на системот. |
| Одговорни институции | Одговорните институции (факултетот) се оние кои ќе го финансираат системот и потоа ќе го користат за нивните потреби. | |
| Систем инжинери Финки | Систем инжињерите на Финки треба да се вклучат во изборот на платформа во која ќе се развива системот, со цел тој полесно да се вклопи во досегашниот систем на Финки. | |
| Развивачи на системот | Развивачи на системот се сите оние кои ќе бидат вклучени на системот(дизајнери, кодери, тестери). | Тие ќе бидат одговорни за успешно завршување на системот во предвидениот рок. |
| Професори | Професори, асистенсти и демонстратори кои ќе ги држат консултациите. | Ќе ги закажуваат консултациите, ќе ги одржуваат и ќе одговараат на прашања. |
| Студенти | Студентите на ФИНКИ воедно и најзасегнатата страна од сите. | Ќе го користат системот како замена на редовните консултации. |
3.3 User Summary
| Name | Description | Stakeholder |
| Неприлагодени на технологијата | Иако претставуваат мал дел од корисниците сепак не значи дека се помалку важни од останатите..Имаат потешкотии да се прилагодат кон новите функционалности. Многу мал дел од корисниците. Обично постари лица. Имаат потешкотии да се прилагодат на покомлексни системи. | Студенти, Професори |
| Премногу зафатени личности | Дел од корисниците кои имаат премногу обврски и не се во можност да бидат достапни за системот во било кое време.Може да бидат на било која возраст. Вообичаено имаат емаил акаунти. | Студенти, Професори |
| Стандардни корисници | Најголем процент од корисниците на системот обично помлади личности. Немаат никакви потешкотии кон прилагодувањето кон покомплексните системи и најверојатно активно ќе го користат системот. | Студенти, Професори |
| Студенти | Студентите на ФИНКИ. Ќе го користат системот како замена на редовните консултации | Студенти |
| Професори | Професори, асистенсти и демонстратори кои ќе ги држат консултациите. Ќе ги закажуваат консултациите, ќе ги одржуваат и ќе одговараат на прашања | Професори |
3.4 User Environment
Бројот на луѓе инволвирани во комплетирање на задача се менува. Најчесто ќе бидат вклучени еден до двајца професори и ограничен број на студенти кој помал или еднаков на бројот на студенти што го следат дадениот курс за кој се одржуваат консултациите.
Траењето на консултациите ќе биде најчесто еден до два саати.
Корисниците, како професорите така и студентите ќе можат да го користат системот од било каков уред со Интернет конекција.
Овој систем ќе биде интегриран како дел од веќе постоечкиот систем за онлајн следење на курсевите на истата платформа.
3.5 Stakeholder Profiles
3.5.1 <Корисници>
| Representative | Студенти, професори, демонстратори и асистенти |
| Description | Корисниците ќе бидат во можност да праќаат пораки преку системот во било кое време. Исто така ќе можат да читаат оние пораки кои ќе се упатени до нив. Корисник на системот се постанува со запишување во образовната институција или вработување како професор, асистент или демонстратор. |
| Type | Студенти, професори, асистенти, демонстратори |
| Responsibilities | Предавачите да враќаат на поставните прашања и да се достапни во терминот за консултации |
| Success Criteria | Навремено одговарање на поставните прашања и достапност во терминот за консултации |
| Involvement | |
| Deliverables | |
| Comments / Issues | Недостапност на системот |
3.5.2 <Систем администратор>
| Representative | |
| Description | Систем администратор ќе биде одговорен за надгледување и одржување на системот. Тој ќе ги контролира пораките кои ќе се испраќаат и коирсниците на системот. |
| Type | |
| Responsibilities | Грижа за системот 24/7, одржување и решавање на проблеми |
| Success Criteria | Достапност на системот 24/7 |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.5.3 <Одговорни институции>
| Representative | |
| Description | Одговорните институции(факултетот) се оние кои ќе го финансираат системот и потоа ќе го користат за нивните потреби. |
| Type | Факултети и универзитети |
| Responsibilities | Финансирање на системот |
| Success Criteria | Успешно имплементирање на системот во наставата |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.5.4 <Систем инженери>
| Representative | |
| Description | Систем инженерите на Финки треба да се вклучат во изборот на платформа во која ќе се развива системот, со цел тој полесно да се вклопи во досегашниот систем на Финки. |
| Type | |
| Responsibilities | Избор на платформа на која ќе се развива системот |
| Success Criteria | Успешно вклопување на новиот систем со тековниот |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.5.5 <Развивачи на системот>
| Representative | |
| Description | Развивачи на системот се сите оние кои ќе бидат вклучени на системот(дизајнери, кодери, тестери). Тие ќе бидат одговорни за успешно завршување на системот во предвидениот рок. |
| Type | Студенти, предавачи, систем инженери и администратори |
| Responsibilities | Дизајнирање, кодирање и тестирање на системот. |
| Success Criteria | Успешно завршување на системот во предвидениот рок. |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.6 User Profiles
3.6.1 < Неприлагодени на технологијата >
| Representative | Иако претставуваат мал дел од корисниците сепак не значи дека се помалку важни од останатите. |
| Description | Имаат потешкотии да се прилагодат кон новите функционалности. Многу мал дел од корисниците. Обично постари лица. Имаат потешкотии да се прилагодат на покомлексни системи. |
| Type | професори, студенти, асистенти, демонстратори. |
| Responsibilities | Не сакаат да се оптоваруваат со користење и учење како да се користат покомплексните системи. |
| Success Criteria | Едноставен за користење на македонски и анлиски јазик |
| Involvement | |
| Deliverables | |
| Comments / Issues |
3.6.2 < Премногу зафатени личности >
| 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 Редовни консултации
Редовните консултации сега за сега се единствениот тип на консултации. Секако дека имаат предност во одност на online консултациите во поглед на поголема интеракција меѓу професорот и студентите и комуникација во реално време. Секако недостатоците се поголеми: недостапност на професорите, термини кои не им одговараваат на студентите и зафатеност на двете страни.
3.8.2 Јавните форуми
Форумите кои се составен дел од секој курс, како и форумите кои можат да постојат независно од курсевите се еден вид на консултации, во смисла дека студентите јавно може да комуницираат како меѓусебе така и со професорите. Системот е достапен 24/7 и може да се користи за поставување на прашања на професорите, добивање одговори и поставување најразлични соопштенија.
3.8.3 Приватните пораки на ecourses
Приватните пораки на ecourses се начин студентите да праќаат приватни пораки на професорите и да добијат одговори на истите. Секако најголем проблем е нередовното одговарање на пораките.
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 available in English, 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. | |
| Системот треба да врши архивирање на сите пратени пораки. | Зачувување на сите пораки, датум на праќање и исприќач и примач во базата на системот. |
| Системот треба да биде заштитен за пристап на надворешни лица. | Дозвола за пристап само на студентите и предавачите на Финки |
4.3 Assumptions and Dependencies
The patients of the system once registered will remain constant, unless the 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.
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 | Системот треба да овозможи некакво класифицирање на пораките по некакви критериуми Системот треба да овозможи архивирање на сите пораки и нивна достапност до соодветните корисници |
| Approved | Системот треба да им дозволи на студентите да им праќаат пораки на предавачите Системот треба да им дозволи на предавачите да им одговараат на студентите Системот треба да овозможи приватност во комуникацијата студент- предавач Системот треба да овозможи поставување на пораки од предавачите кои ќе бидат достапни за сите студенти Системот треба да биде online достапен 24 часа седум дена во неделата |
| Incorporated | Системот треба да овозможи креирање на јавни дискусии на некои теми |
11.2 Benefit
| Critical | Системот треба да биде достапен online во било кое време. Системот треба да им дозволи на студентите да им праќаат пораки на предавачите Системот треба да им дозволи на предавачите да им одговараат на студентите Системот треба да овозможи приватност во комуникацијата студент- предавач Системот треба да овозможи поставување на пораки од предавачите кои ќе бидат достапни за сите студенти Системот со секоја поставена порака треба да асоцира дата на поставување и личност која ја поставила Системот треба да биде заштитен за пристап на надворешни лица. |
| Important | Системот треба да овозможи креирање на јавни дискусии на некои теми Системот треба да овозможи архивирање на сите пораки и нивна достапност до соодветните корисници Системот треба да биде лесен за користење и за оние кои лесно се прилагодуваат на технологиите и за оние кои не се прилагодуваат лесно. Системот треба да биде достапен на македонски јазик за да оние кои немаат добри познавања на англиски. |
| Useful | Системот треба да овозможи некакво класифицирање на пораките по некои критериуми |
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 authorities, 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.
