03-04-2012, 01:01 PM
Medical Diagnostic System.doc (Size: 74 KB / Downloads: 73)
1.0. Introduction
1.1. Purpose
The purpose of this document is to present a detailed description of the Medical Diagnostic System. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the patient and the doctors.
1.2. Scope of Project
This software system will be a Medical Diagnostic System for common man and doctors . This system will be designed to immediately diagnose by providing tools to assist the patient and doctor , which would otherwise have to be performed manually. By this system, we will be able to quick diagnose a person and give reports about that person that is easy to understand and use.
More specifically, this system is designed to allow a patient to diagnose himself and it will analyze every symptom and give a complete report of his illness .This software will keep a complete record of the patients history and his medical problems . It will also help the doctors to quickly analyze the disease and will help to decide the medicine for that illness. The software will also give the name of the doctor to consult in this illness.
1.5. Overview of Document
The next chapter, the Overall Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter.
The third chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product.
Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language.
2.0. Overall Description
2.1 System Environment
Objective is to provide essential medical services online to everyone hardly matters you live in metro or a remotely located village. Users can connect through their home internet or approach any nearby kiosk to get these services. What motivate to build this system are:
1) Very few or no doctors at remote locations
2) Limited hour services and lack of sophisticated medical equipments
3) No patients history/lab data management
2.2 Functional Requirements Specification
This section outlines the use cases for each of the patient separately. The patient, doctor and the administrator are the main actor in this system.
2.2.1 Patient Use Case
Brief Description
The patient accesses the Online Diagnostic System , registers its full details and downloads it to his/her machine.
Initial Step-By-Step Description
Before this use case can be initiated, the patient has already accessed the Online Diagnostic System
1. The patient enters the area in this body where it has most problems.
2. The patient enters the type of symptoms it is prevailing.
3. The patient can look at its past medical history, doctors prescription and total expense
4. The patient can find the nearest doctor available and fix an appointment.
2.2.2 Doctor Use Case
Brief Description
The doctor can really benefit as from here he can know the patient medical history and also find the illness.
Initial Step-By-Step Description
Before this use case can be initiated, the Doctorr has already connected to the Online Diagnostic System
1. The doctor can enter the symptoms of the patient and get to know what disease it has
2. The doctor can know about the medical history of the patient.
Update Information use cases
Administration uses
Brief Description
The administrator enters a new entry or updates information about a current disease or patient
Initial Step-By-Step Description
Before this use case can be initiated, the administrator has already accessed the main page of the Diagnostic system
1. The administrator selects to Add/Update information
2. The system presents a choice of adding or updating.
3. The administrator chooses to add or to update.
4. If the administrator is updating an patient history, the system asks the patient code and updates it.
5. The administrator fills in the information and submits the form.
6. The system verifies the information and returns the administrator to the Diagnostic System main page.
Use case: Remove Entry
This use case extends the Update use case.
Brief Description
The Editor removes an article from the active category.