| Version 4 (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
Системот е наменет за образовните институции. Конкретно, се изработува како подсистем на on-line системот на факултетот Финки, за овозможување на on-line консултации помеѓу предавачите и студентите. Големината на корисници на системот зависи од бројот на запишани на факултетот, заедно со наставниот кадар.
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.
The entire project mainly consists of 7 modules, which are
- Admin module
- User module (patient)
- Doctor module
- Nurse module
- Pharmacist module
- Laboratorist module
- Accountant module
4.2 Summary of Capabilities
Customer Support System
| Customer Benefit | Supporting Features |
| Лесен за користење. | Ќе биде достапен на македонски јазик, едноставен за да може да користат и обични корисници без големо мознавање на технологијата. |
| Достапен на македонски. | / |
| Достапен online 24 часа. | |
| Системот треба да врши архивирање на сите пратени пораки. | Зачувување на сите пораки, датум на праќање и исприќач и примач во базата на системот. |
| Системот треба да биде заштитен за пристап на надворешни лица. | Дозвола за пристап само на студентите и предавачите на Финки |
4.3 Assumptions and Dependencies
Корисниците на системот ќе се менуваат, бидејќи системот ќе може да го користат само тековните студенти на ФИНКИ и професори.
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
Да не постои ограничување на истовремениот број на корисници.
Да не постои ограничување на бројот на испратени пораки од еден корисник.
Корисникот да биде дел само од курсевите кои што ги запишал.
9.3 Performance Requirements
Бројот на студенти кај одреден професор во некој закажан термин ќе биде ограничен ,т.е ако повеќе студенти го слушаат курсот професорот ќе закаже повеќе термини и ќе ги подели студентите и во соодветните термини.
9.4 Environmental Requirements
При потреба од некаква помош студентите можат да го искористат веќе постоечкиот систем Help.
10. Documentation Requirements
10.1 User Manual
Сите тековни студенти на ФИНКИ ќе добијат корисничко име и лозинка со кои што ќе се најавуваат на системот. Секако лозинката подоцна студентите ќе можат да ја променат.
10.2 On-line Help
Системот се предвидува да има и on-line помош. Тоа би значело дека ќе има страна на која ќе се наведени упатствата за користење на системот, ќе има дел за FAQ (најчесто поставувани прашања), а за проблеми кои се посложени и треба да се интервенира од страна на администраторите ќе биде достапна техничката служба на ФИНКИ.
10.3 Installation Guides, Configuration, Read Me File
Системот за корисникот ќе претставува веб страна на која се најавува со својот индекс (за студенти) или со своето корисничко име (за наставниот кадар) и лозинката која што ја користи на системот за е-курсеви и исто како и за него, ќе може да го користи од сите пребарувачи (Firefox , Opera, Chrome итн).
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
Тимот ќе има мал број на членови кои најпрво ќе ја напишат спецификацијата со цел да се утврдат сите барања и можности. Во развојот на системот секако ќе биде потребно да се вклучат и надлежните кои го надгледуваат проектот како и лица кои се запознаени со веќе постоечкиот систем на факултетот, со цел овој под-систем полесно и подобро да се вклопи.
11.4 Risk
Ризикот за неостварување на проектот постои и е голем од временска гледна точка. Доколку не се развие целосно до одреден период, постои можност да заостане и да се тргне на страна како неприоритетен. Исто така, постои можност да не се развие доколку се смени тимот и не може да се најде друг тим во соодветно време. Уште една можност е системот да се развие, но да не биде прифатен од повисоките редови од факултетот кои носат одлуки.
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.
