FB Video Player free download for Android
Description:
Monday, May 18, 2015
Folder Lock Android app download
Folder Lock for Android app
Latest application Folder Lock protect your personal files, photos, videos, documents, contacts, wallet cards, notes and audio recordings in Android Phones. The app has attractive and pleasant interface. it is easy to install.
Whats App Messenger download
Whats App Messenger download
Whats App messenger is a smartphone to smartphone messenger now availability for iPhone and BlackBerry. The application utilizes push notifications to instantly get messages from friends, colleagues and familydownload
Sunday, May 17, 2015
usb show software free download data recovery
usb show software free download
Description:
USB Show is a free software that helps user to recover files
hidden when you connect usb and data size show but data hidden by someone or by
a virus or malware. USB Show can search any files from Flash drive or internal
hard disk. This application is portable and user usually highlights this
feature for the ease of running it as you want. When you download it, you will know
that its size is very small , it’s really useful, it work in any computer
without any kind of problems.
This software
is easy to use, it works really power full . Its efficiency is high to
recognizing a great amount of hidden documents by different viruses in the same
USB. In fact, you can also run it in hard disks.
How recover hidden files:
it is a very simple method to recover the hidden files from the usb.
1.just download the software
2.Install it
3.select the language
4.select the usb
5.click the recovery button
6.wait few mints
7.now your data recover successfully.
Saturday, May 16, 2015
Free Download ACD ChemSketch software- Chemistry
Free Download ACD ChemSketch Freeware - Chemistry
Educational software tool.
size 37 Mb
OS: windows
easy to installation
Description:
ACD ChemSketch software is a drawing package thatpermision you to Make chemical structures including Organics, Organometallics, Polymers, and Markush structures. It also includes features such as calculation of molecular attribute. (e.g., molecular weight, density, molar refractivity etc.), 2 Dimensional and 3 Dimensional structures cleaning and viewing, functionality for naming structures..
How Recover Deleted Files & Folders from Hard Drive
How Recover Deleted Files & Folders from Hard Drive
Description:
If your important data delete and now! you are worry about how recover that data .
Now you cane do it in easily.
Recover formatted partition
Recover raw hard drive
Recover lost partitions
Recover lost photo and images
Recover deleted files
How to recover deleted files from hard drive
How to recover deleted files from hard drive
If you want to recover your important data that deleted from your computers or hard disk. If your Data delete any way. means accidental formate ,delete or other
No matter you shift+delete the files or empty the Recycle Bin, All Deleted files can be Recover by Data Recovery software. When you delete a file from your computer, you just remove the file entry instead of the content. Windows simply marks the hard drive space as free for use.
Size 33 MB
easy to install and use.
High performance with 100%
Friday, May 15, 2015
free download Acer Aspire Bluetooth Driver for Windows 7
free download Acer Aspire Bluetooth Driver for Windows 7
To installing the Latest version of Acer Bluetooth Driver simply and enjoy .I hope you shal be happy to use this driver for windows 7.Clickk here for download
free download HP Scanjet 2400 driver
Free download HP Scanjet 2400 driver
Latest Version
209 Mb size
HP Scanjet 2400: A slim, attractive and affordable scanner that will get you started in no time at all. It is easy to use and fully secured. it is very important driver to print any document from HP devices. I hope you shall be very happy.Click Here For Download
For Leser jet Click Here to download
For Leser jet Click Here to download
Thursday, May 14, 2015
free download HP Bluetooth software
HP Integrated Module with Bluetooth 4.00
The HP Integrated Module with Bluetooth Wireless Technology provides wireless connectivity to other devices from the integrated module of the supported notebooks. to transfer data
Click Here For Download
Click Here For Download
SRS of Web Publishing System
Software Requirements Specification
Version 1.0
<<Annotated Version>>
April 15, 2004
Web Publishing System
Submitted in partial fulfillment
Of the requirements of
CS 310 Software Engineering
<<Any comments inside double brackets such as these are not part of this SRS but are comments upon this SRS example to help the reader understand the point being made.
Refer to the SRS Template for details on the purpose and rules for each section of this document.
This work is based upon the submissions of the Spring 2004 CS 310. The students who submitted these team projects were Thomas Clay, Dustin Denney, Erjon Dervishaj, Tiffanie Dew, Blake Guice, Jonathan Medders, Marla Medders, Tammie Odom, Amro Shorbatli, Joseph Smith, Jay Snellen, Chase Tinney, and Stefanie Watts. >>
Table of Contents
Table of Contents.. i
List of Figures.. ii
1.0. Introduction.. 1
1.1. Purpose. 1
1.2. Scope of Project 1
1.3. Glossary. 2
1.4. References. 2
1.5. Overview of Document 2
2.0. Overall Description.. 4
2.1 System Environment 4
2.2 Functional Requirements Specification. 5
2.2.1 Reader Use Case. 5
Use case: Search Article. 5
2.2.2 Author Use Case. 6
Use case: Submit Article. 6
2.2.3 Reviewer Use Case. 7
Use case: Submit Review.. 7
2.2.4 Editor Use Cases. 8
Use case: Update Author 8
Use case: Update Reviewer 9
Use case: Update Article. 9
Use case: Receive Article. 10
Use case: Assign Reviewer 11
Use case: Receive Review.. 11
Use case: Check Status. 12
Use case: Send Response. 12
Use case: Send Copyright 13
Use case: Remove Article. 14
Use case: Publish Article. 14
2.3 User Characteristics. 15
2.4 Non-Functional Requirements. 15
3.0. Requirements Specification.. 17
3.1 External Interface Requirements. 17
3.2 Functional Requirements. 17
3.2.1 Search Article. 17
3.2.2 Communicate. 18
3.2.3 Add Author 18
3.2.4 Add Reviewer 19
3.2.5 Update Person. 19
3.2.6 Update Article Status. 20
3.2.7 Enter Communication. 20
3.2.8 Assign Reviewer 21
3.2.9 Check Status. 21
3.2.10 Send Communication. 22
3.2.11 Publish Article. 22
3.2.12 Remove Article. 23
3.3 Detailed Non-Functional Requirements. 23
3.3.1 Logical Structure of the Data. 23
3.3.2 Security. 25
Index. 26
List of Figures
Figure 1 - System Environment 4
Figure 2 - Article Submission Process. 6
Figure 3 - Editor Use Cases. 8
Figure 4 - Logical Structure of the Article Manager Data. 23
1.0. Introduction
1.1. Purpose
The purpose of this document is to present a detailed description of the Web Publishing 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 stakeholders and the developers of the system and will be proposed to the Regional Historical Society for its approval.
1.2. Scope of Project
This software system will be a Web Publishing System for a local editor of a regional historical society. This system will be designed to maximize the editor’s productivity by providing tools to assist in automating the article review and publishing process, which would otherwise have to be performed manually. By maximizing the editor’s work efficiency and production the system will meet the editor’s needs while remaining easy to understand and use.
More specifically, this system is designed to allow an editor to manage and communicate with a group of reviewers and authors to publish articles to a public website. The software will facilitate communication between authors, reviewers, and the editor via E-Mail. Preformatted reply forms are used in every stage of the articles’ progress through the system to provide a uniform review process; the location of these forms is configurable via the application’s maintenance options. The system also contains a relational database containing a list of Authors, Reviewers, and Articles.
1.3. Glossary
Term
Definition
Active Article
The document that is tracked by the system; it is a narrative that is planned to be posted to the public website.
Author
Person submitting an article to be reviewed. In case of multiple authors, this term refers to the principal author, with whom all communication is made.
Database
Collection of all the information monitored by this system.
Editor
Person who receives articles, sends articles for review, and makes final judgments for publications.
Field
A cell within a form.
Historical Society Database
The existing membership database (also HS database).
Member
A member of the Historical Society listed in the HS database.
Reader
Anyone visiting the site to read articles.
Review
A written recommendation about the appropriateness of an article for publication; may include suggestions for improvement.
Reviewer
A person that examines an article and has the ability to recommend approval of the article for publication or to request that changes be made in the article.
Software Requirements Specification
A document that completely describes all of the functions of a proposed system and the constraints under which it must operate. For example, this document.
Stakeholder
Any person with an interest in the project who is not a developer.
User
Reviewer or Author.
1.4. References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.
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
The Web Publishing System has four active actors and one cooperating system.
The Author, Reader, or Reviewer accesses the Online Journal through the Internet. Any Author or Reviewer communication with the system is through email. The Editor accesses the entire system directly. There is a link to the (existing) Historical Society.
<< The division of the Web Publishing System into two component parts, the Online Journal and the Article Manager, is an example of using domain classes to make an explanation clearer. >>
2.2 Functional Requirements Specification
This section outlines the use cases for each of the active readers separately. The reader, the author and the reviewer have only one use case apiece while the editor is main actor in this system.
2.2.1 Reader Use Case
Use case: Search Article
Brief Description
The Reader accesses the Online Journal Website, searches for an article and downloads it to his/her machine.
Initial Step-By-Step Description
Before this use case can be initiated, the Reader has already accessed the Online Journal Website.
1. The Reader chooses to search by author name, category, or keyword.
2. The system displays the choices to the Reader.
3. The Reader selects the article desired.
4. The system presents the abstract of the article to the reader.
5. The Reader chooses to download the article.
6. The system provides the requested article.
Xref: Section 3.2.1, Search Article
Figure 2 - Article Submission Process
The Article Submission Process state-transition diagram summarizes the use cases listed below. An Author submits an article for consideration. The Editor enters it into the system and assigns it to and sends it to at least three reviewers. The Reviewers return their comments, which are used by the Editor to make a decision on the article. Either the article is accepted as written, declined, or the Author is asked to make some changes based on the reviews. If it is accepted, possibly after a revision , the Editor sends a copyright form to the Author. When that form is returned, the article is published to the Online Journal. Not shown in the above is the removal of a declined article from the system.
2.2.2 Author Use Case
In case of multiple authors, this term refers to the principal author, with whom all communication is made.
Use case: Submit Article
Diagram:
Brief Description
The author either submits an original article or resubmits an edited article.
Initial Step-By-Step Description
Before this use case can be initiated, the Author has already connected to the Online Journal Website.
1. The Author chooses the Email Editor button.
2. The System uses the sendto HTML tag to bring up the user’s email system.
3. The Author fills in the Subject line and attaches the files as directed and emails them.
4. The System generates and sends an email acknowledgement.
Xref: Section 3.2.2, Communicate
2.2.3 Reviewer Use Case
Use case: Submit Review
Diagram:
Brief Description
The reviewer submits a review of an article.
Initial Step-By-Step Description
Before this use case can be initiated, the Reviewer has already connected to the Online Journal Website.
1. The Reviewer chooses the Email Editor button.
2. The System uses the sendto HTML tag to bring up the user’s email system.
3. The Reviewer fills in the Subject line and attaches the file as directed and emails it.
4. The System generates and sends an email acknowledgement.
Xref: Section 3.2.2, Communicate
2.2.4 Editor Use Cases
The Editor has the following sets of use cases:
Update Information use cases
Use case: Update Author
Diagram:
Brief Description
The Editor enters a new Author or updates information about a current Author.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager.
1. The Editor selects to Add/Update Author.
2. The system presents a choice of adding or updating.
3. The Editor chooses to add or to update.
4. If the Editor is updating an Author, the system presents a list of authors to choose from and presents a grid filling in with the information; else the system presents a blank grid.
5. The Editor fills in the information and submits the form.
6. The system verifies the information and returns the Editor to the Article Manager main page.
Xref: Section 3.2.3, Add Author; Section 3.2.5 Update Person
Use case: Update Reviewer
Diagram:
Brief Description
The Editor enters a new Reviewer or updates information about a current Reviewer.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager.
The Editor selects to Add/Update Reviewer.
The system presents a choice of adding or updating.
The Editor chooses to add or to update.
The system links to the Historical Society Database.
If the Editor is updating a Reviewer, the system and presents a grid with the information about the Reviewer; else the system presents list of members for the editor to select a Reviewer and presents a grid for the person selected.
The Editor fills in the information and submits the form.
The system verifies the information and returns the Editor to the Article Manager main page.
Xref: Section 3.2.4, Add Reviewer; Section 3.2.5, Update Person
Use case: Update Article
Diagram:
Brief Description
The Editor enters information about an existing article.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager.
1. The Editor selects to Update Article.
2. The system presents s list of active articles.
3. The system presents the information about the chosen article.
4. The Editor updates and submits the form.
5. The system verifies the information and returns the Editor to the Article Manager main page.
Xref: Section 3.2.6, Update Article Status
Handle Article use cases
Use case: Receive Article
Diagram:
Brief Description
The Editor enters a new or revised article into the system.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager and has a file containing the article available.
1. The Editor selects to Receive Article.
2. The system presents a choice of entering a new article or updating an existing article.
3. The Editor chooses to add or to update.
4. If the Editor is updating an article, the system presents a list of articles to choose from and presents a grid for filling with the information; else the system presents a blank grid.
5. The Editor fills in the information and submits the form.
6. The system verifies the information and returns the Editor to the Article Manager main page.
Xref: Section 3.2.7, Enter Communication
Use case: Assign Reviewer
This use case extends the Update Article use case.
Diagram:
Brief Description
The Editor assigns one or more reviewers to an article.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case.
1. The Editor selects to Assign Reviewer.
2. The system presents a list of Reviewers with their status (see data description is section 3.3 below).
3. The Editor selects a Reviewer.
4. The system verifies that the person is still an active member using the Historical Society Database.
5. The Editor repeats steps 3 and 4 until sufficient reviewers are assigned.
6. The system emails the Reviewers, attaching the article and requesting that they do the review.
7. The system returns the Editor to the Update Article use case.
Xref: Section 3.2.8, Assign Reviewer
Use case: Receive Review
This use case extends the Update Article use case.
Diagram:
Brief Description
The Editor enters a review into the system.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case.
1. The Editor selects to Receive Review.
2. The system presents a grid for filling with the information.
3. The Editor fills in the information and submits the form.
4. The system verifies the information and returns the Editor to the Article Manager main page.
Xref: Section 3.2.7, Enter Communication
Check Status use case:
Use case: Check Status
Diagram:
Brief Description
The Editor checks the status of all active articles.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager.
1. The Editor selects to Check Status.
2. The system returns a scrollable list of all active articles with their status (see data description in section 3.3 below).
3. The system returns the Editor to the Article Manager main page.
Xref: Section 3.2.9, Check Status
Send Recommendation use cases:
Use case: Send Response
This use case extends the Update Article use case.
Diagram:
Brief Description
The Editor sends a response to an Author.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case.
1. The Editor selects to Send Response.
2. The system calls the email system and puts the Author’s email address in the Recipient line and the name of the article on the subject line.
3. The Editor fills out the email text and sends the message.
4. The system returns the Editor to the Article Manager main page.
Xref: Section 3.210, Send Communication
Use case: Send Copyright
This use case extends the Update Article use case.
Diagram:
Brief Description
The Editor sends a copyright form to an Author.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case.
1. The Editor selects to Send Copyright.
2. The system calls the email system and puts the Author’s email address in the Recipient line, the name of the article on the subject line, and attaches the copyright form.
3. The Editor fills out the email text and sends the message.
4. The system returns the Editor to the Article Manager main page.
Xref: Section 3.2.10, Send Communication
Use case: Remove Article
Diagram:
Brief Description
The Editor removes an article from the active category.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case.
1. The Editor selects to remove an article from the active database.
2. The system provides a list of articles with the status of each.
3. The Editor selects an article for removal.
4. The system removes the article from the active article database and returns the Editor to the Article Manager main page.
Xref: Section 3.2.12, Remove Article
Publish Article use case:
Use case: Publish Article
T
Diagram:
Brief Description
The Editor transfers an accepted article to the Online Journal.
Initial Step-By-Step Description
Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case.
1. The Editor selects to Publish Article.
2. The system transfers the article to the Online Journal and updates the search information there.
3. The system removes the article from the active article database and returns the Editor to the Article Manager home page.
Xref: Section 3.2.11, Publish Article
<< Since three of the actors only have one use case each, the summary diagram only involves the Editor. Adapt the rules to the needs of the document rather than adapt the document to fit the rules. >>
2.3 User Characteristics
The Reader is expected to be Internet literate and be able to use a search engine. The main screen of the Online Journal Website will have the search function and a link to “Author/Reviewer Information.”
The Author and Reviewer are expected to be Internet literate and to be able to use email with attachments.
The Editor is expected to be Windows literate and to be able to use button, pull-down menus, and similar tools.
The detailed look of these pages is discussed in section 3.2 below.
2.4 Non-Functional Requirements
The Online Journal will be on a server with high speed Internet capability. The physical machine to be used will be determined by the Historical Society. The software developed here assumes the use of a tool such as Tomcat for connection between the Web pages and the database. The speed of the Reader’s connection will depend on the hardware used rather than characteristics of this system.
The Article Manager will run on the editor’s PC and will contain an Access database. Access is already installed on this computer and is a Windows operating system.
3.0. Requirements Specification
3.1 External Interface Requirements
The only link to an external system is the link to the Historical Society (HS) Database to verify the membership of a Reviewer. The Editor believes that a society member is much more likely to be an effective reviewer and has imposed a membership requirement for a Reviewer. The HS Database fields of interest to the Web Publishing Systems are member’s name, membership (ID) number, and email address (an optional field for the HS Database).
The Assign Reviewer use case sends the Reviewer ID to the HS Database and a Boolean is returned denoting membership status. The Update Reviewer use case requests a list of member names, membership numbers and (optional) email addresses when adding a new Reviewer. It returns a Boolean for membership status when updating a Reviewer.
3.2 Functional Requirements
The Logical Structure of the Data is contained in Section 3.3.1.
3.2.1 Search Article
Use Case Name
Search Article
XRef
Section 2.2.1, Search Article
SDD, Section 7.1
Trigger
The Reader assesses the Online Journal Website
Precondition
The Web is displayed with grids for searching
Basic Path
1. The Reader chooses how to search the Web site. The choices are by Author, by Category, and by Keyword.
2. If the search is by Author, the system creates and presents an alphabetical list of all authors in the database. In the case of an article with multiple authors, each is contained in the list.
3. The Reader selects an author.
4. The system creates and presents a list of all articles by that author in the database.
5. The Reader selects an article.
6. The system displays the Abstract for the article.
7. The Reader selects to download the article or to return to the article list or to the previous list.
Alternative Paths
In step 2, if the Reader selects to search by category, the system creates and presents a list of all categories in the database.
3. The Reader selects a category.
4. The system creates and presents a list of all articles in that category in the database. Return to step 5.
In step 2, if the Reader selects to search by keyword, the system presents a dialog box to enter the keyword or phrase.
3. The Reader enters a keyword or phrase.
4. The system searches the Abstracts for all articles with that keyword or phrase and creates and presents a list of all such articles in the database. Return to step 5.
Postcondition
The selected article is downloaded to the client machine.
Exception Paths
The Reader may abandon the search at any time.
Other
The categories list is generated from the information provided when article are published and not predefined in the Online Journal database.
3.2.2 Communicate
Use Case Name
Communicate
XRef
Section 2.2.2, Submit Article; Section 2.2.3, Submit Review
SDD, Section 7.2
Trigger
The user selects a mailto link.
Precondition
The user is on the Communicate page linked from the Online Journal Main Page.
Basic Path
This use case uses the mailto HTML tag. This invokes the client email facility.
Alternative Paths
If the user prefers to use his or her own email directly, sufficient information will be contained on the Web page to do so.
Postcondition
The message is sent.
Exception Paths
The attempt may be abandoned at any time.
Other
None
3.2.3 Add Author
Use Case Name
Add Author
XRef
Section 2.2.4, Update Author
SDD, Section 7.3
Trigger
The Editor selects to add a new author to the database.
Precondition
The Editor has accessed the Article Manager main screen.
Basic Path
1. The system presents a blank grid to enter the author information.
2. The Editor enters the information and submits the form.
3. The system checks that the name and email address fields are not blank and updates the database.
Alternative Paths
If in step 2, either field is blank, the Editor is instructed to add an entry. No validation for correctness is made.
Postcondition
The Author has been added to the database.
Exception Paths
The Editor may abandon the operation at any time.
Other
The author information includes the name mailing address and email address.
3.2.4 Add Reviewer
Use Case Name
Add Reviewer
XRef
Section 2.2.4, Update Reviewer
SDD, Section 7.4
Trigger
The Editor selects to add a new reviewer to the database.
Precondition
The Editor has accessed the Article Manager main screen.
Basic Path
1. The system accesses the Historical Society (HS) database and presents an alphabetical list of the society members.
2. The Editor selects a person.
3. The system transfers the member information from the HS database to the Article Manager (AM) database. If there is no email address in the HS database, the editor is prompted for an entry in that field.
4. The information is entered into the AM database.
Alternative Paths
In step 3, if there is no entry for the email address in the HS database or on this grid, the Editor will be reprompted for an entry. No validation for correctness is made.
Postcondition
The Reviewer has been added to the database.
Exception Paths
The Editor may abandon the operation at any time.
Other
The Reviewer information includes name, membership number, mailing address, categories of interest, and email address.
3.2.5 Update Person
Use Case Name
Update Person
XRef
Sec 2.2.4 Update Author; Sec 2.2.4 Update Reviewer
SDD, Section 7.5
Trigger
The Editor selects to update an author or reviewer and the person is already in the database.
Precondition
The Editor has accessed the Article Manager main screen.
Basic Path
1. The Editor selects Author or Reviewer.
2. The system creates and presents an alphabetical list of people in the category.
3. The Editor selects a person to update.
4. The system presents the database information in grid form for modification.
5. The Editor updates the information and submits the form.
6. The system checks that required fields are not blank.
Alternative Paths
In step 5, if any required field is blank, the Editor is instructed to add an entry. No validation for correctness is made.
Postcondition
The database has been updated.
Exception Paths
If the person is not already in the database, the use case is abandoned. In addition, the Editor may abandon the operation at any time.
Other
This use case is not used when one of the other use cases is more appropriate, such as to add an article or a reviewer for an article.
3.2.6 Update Article Status
Use Case Name
Update Article Status
XRef
Section 2.2.4, Update Article
SDD, Section 7.6
Trigger
The Editor selects to update the status of an article in the database.
Precondition
The Editor has accessed the Article Manager main screen and the article is already in the database.
Basic Path
1. The system creates and presents an alphabetical list of all active articles.
2. The Editor selects the article to update.
3. The system presents the information about the article in grid format.
4. The Editor updates the information and resubmits the form.
Alternative Paths
In step 4, the use case Enter Communication may be invoked.
Postcondition
The database has been updated.
Exception Paths
If the article is not already in the database, the use case is abandoned. In addition, the Editor may abandon the operation at any time.
Other
This use case can be used to add categories for an article, to correct typographical errors, or to remove a reviewer who has missed a deadline for returning a review. It may also be used to allow access to the named use case to enter an updated article or a review for an article.
3.2.7 Enter Communication
Use Case Name
Enter Communication
XRef
Section 2.2.4, Receive Article; Section 2.2.4, Receive Review
SDD, Section 7.7
Trigger
The Editor selects to add a document to the system.
Precondition
The Editor has accessed the Article Manager main screen and has the file of the item to be entered available.
Basic Path
1. The Editor selects the article using the 3.2.6, Update Article Status use case.
2. The Editor attaches the file to the grid presented and updates the respective information about the article.
3. When the Editor updates the article status to indicate that a review is returned, the respective entry in the Reviewer table is updated.
Alternative Paths
None
Postcondition
The article entry is updated in the database.
Exception Paths
The Editor may abandon the operation at any time.
Other
This use case extends 3.2.6, Update Article Status
3.2.8 Assign Reviewer
Use Case Name
Assign Reviewer
XRef
Section 2.2.4, Assign Reviewer
SDD, Section 7.8
Trigger
The Editor selects to assign a reviewer to an article.
Precondition
The Editor has accessed the Article Manager main screen and the article is already in the database. .
Basic Path
1. The Editor selects the article using the 3.2.6, Update Article Status use case.
2. The system presents an alphabetical list of reviewers with their information.
3. The Editor selects a reviewer for the article.
4. The system updates the article database entry and emails the reviewer with the standard message and attaches the text of the article without author information.
5. The Editor has the option of repeating this use case from step 2.
Alternative Paths
None.
Postcondition
At least one reviewer has been added to the article information and the appropriate communication has been sent.
Exception Paths
The Editor may abandon the operation at any time.
Other
This use case extends 3.2.6, Update Article Status. The Editor, prior to implementation of this use case, will provide the message text.
3.2.9 Check Status
Use Case Name
Check Status
XRef
Section 2.2.4, Check Status
SDD, Section 7.9
Trigger
The Editor has selected to check status of all active articles.
Precondition
The Editor has accessed the Article Manager main screen.
Basic Path
1. The system creates and presents a list of all active articles organized by their status.
2. The Editor may request to see the full information about an article.
Alternative Paths
None.
Postcondition
The requested information has been displayed.
Exception Paths
The Editor may abandon the operation at any time.
Other
The editor may provide an enhanced list of status later. At present, the following categories must be provided:
1. Received but no further action taken
2. Reviewers have been assigned but not all reviews are returned (include dates that reviewers were assigned and order by this criterion).
3. Reviews returned but no further action taken.
4. Recommendations for revision sent to Author but no response as of yet.
5. Author has revised article but no action has been taken.
6. Article has been accepted and copyright form has been sent.
7. Copyright form has been returned but article is not yet published.
A published article is automatically removed from the active article list.
3.2.10 Send Communication
Use Case Name
Send Communication
XRef
Section 2.2.4, Send Response; Section 2.2.4, Send Copyright
SDD, Section 7.10
Trigger
The editor selects to send a communication to an author.
Precondition
The Editor has accessed the Article Manager main screen.
Basic Path
1. The system presents an alphabetical list of authors.
2. The Editor selects an author.
3. The system invokes the Editor’s email system entering the author’s email address into the To: entry.
4. The Editor uses the email facility.
Alternative Paths
None.
Postcondition
The communication has been sent.
Exception Paths
The Editor may abandon the operation at any time.
Other
The standard copyright form will be available in the Editor’s directory for attaching to the email message, if desired.
3.2.11 Publish Article
Use Case Name
Publish Article
XRef
Section 2.2.4, Publish Article
SDD, Section 7.11
Trigger
The Editor selects to transfer an approved article to the Online Journal.
Precondition
The Editor has accessed the Article Manager main screen.
Basic Path
1. The system creates and presents an alphabetical list of the active articles that are flagged as having their copyright form returned.
2. The Editor selects an article to publish.
3. The system accesses the Online Database and transfers the article and its accompanying information to the Online Journal database.
4. The article is removed from the active article database.
Alternative Paths
None.
Postcondition
The article is properly transferred.
Exception Paths
The Editor may abandon the operation at any time.
Other
Find out from the Editor to see if the article information should be archived somewhere.
3.2.12 Remove Article
Use Case Name
Remove Article
XRef
Section 2.2.4, Remove Article
SDD, Section 7.12
Trigger
The Editor selects to remove an article from the active article database.
Precondition
The Editor has accessed the Article Manager main screen.
Basic Path
1. The system provides an alphabetized list of all active articles.
2. The editor selects an article.
3. The system displays the information about the article and requires that the Editor confirm the deletion.
4. The Editor confirms the deletion.
Alternative Paths
None.
Postcondition
The article is removed from the database.
Exception Paths
The Editor may abandon the operation at any time.
Other
Find out from the Editor to see if the article and its information information should be archived somewhere.
3.3 Detailed Non-Functional Requirements
3.3.1 Logical Structure of the Data
The data descriptions of each of these data entities is as follows:
Author Data Entity
Data Item
Type
Description
Comment
Name
Text
Name of principle author
Email Address
Text
Internet address
Article
Pointer
Article entity
May be several
Reviewer Data Entity
Data Item
Type
Description
Comment
Name
Text
Name of principle author
ID
Integer
ID number of Historical Society member
Used as key in Historical Society Database
Email Address
Text
Internet address
Article
Pointer
Article entity of
May be several
Num Review
Integer
Review entity
Number of not returned reviews
History
Text
Comments on past performance
Specialty
Category
Area of expertise
May be several
Review Data Entity
Data Item
Type
Description
Comment
Article
Pointer
Article entity
Reviewer
Pointer
Reviewer entity
Single reviewer
Date Sent
Date
Date sent to reviewer
Returned
Date
Date returned; null if not returned
Contents
Text
Text of review
Article Data Entity
Data Item
Type
Description
Comment
Name
Text
Name of Article
Author
Pointer
Author entity
Name of principle author
Other Authors
Text
Other authors is any; else null
Not a pointer to an Author entity
Reviewer
Pointer
Reviewer entity
Will be several
Review
Pointer
Review entity
Set up when reviewer is set up
Contents
Text
Body of article
Contains Abstract as first paragraph.
Category
Text
Area of content
May be several
Accepted
Boolean
Article has been accepted for publication
Needs Copyright form returned
Copyright
Boolean
Copyright form has been returned
Not relevant unless Accepted is True.
Published
Boolean
Sent to Online Journal
Not relevant unless Accepted is True. Article is no longer active and does not appear in status checks.
The Logical Structure of the data to be stored in the Online Journal database on the server is as follows:
Published Article Entity
Data Item
Type
Description
Comment
Name
Text
Name of Article
Author
Text
Name of one Author
May be several
Abstract
Text
Abstract of article
Used for keyword search
Content
Text
Body of article
Category
Text
Area of content
May be several
3.3.2 Security
The server on which the Online Journal resides will have its own security to prevent unauthorized write/delete access. There is no restriction on read access. The use of email by an Author or Reviewer is on the client systems and thus is external to the system.
The PC on which the Article Manager resides will have its own security. Only the Editor will have physical access to the machine and the program on it. There is no special protection built into this system other than to provide the editor with write access to the Online Journal to publish an article.
free download folder colorizer software
free download folder colorizer software
Now you can Color of the folder! yuor own desire any folder to give any color – just right-click a folder and choose “Colorize”! Supports your own color, labels and works seamlessly with any version of Windows.Click Here for Download
Wednesday, May 13, 2015
avast anti virus with serial key registered till 2038 free download
Avast Anti Virus with serial key Registered till 2038
Latest version of avast anti virus that help you fully protect your pc
It is very simple and easy to install.
Size 144 MB
Windows Movie Maker free download
Windows Movie Maker free download
What is movie maker?
Now you can make your own video with help of this program. MovieMakerOnline is your online program to create a beautiful home video from photos and music absolutely free! To create a video you just have to add the required photos and favorite music and get unique video. Also our video editor allows you to add subtitle and draw on photos.
Use our video editor to make slideshow presentations for school or for work. Create the photo video report about a good trip and vacation with good music for your family and friends!
Tuesday, May 12, 2015
Monday, May 11, 2015
free download phpMyAdmin 4.4.6 for windowos
phpMyAdmin 4.4.6 free download
It is a web tool for all windows version.
phpMyAdmin is a free software tool written in PHP, intended to handle the administration of MySQL over the Web. phpMyAdmin helps a huge range of operations on MySQL .Frequently used operations (managing databases, tables, columns, relations, indexes, users, permissions, etc) can be performed via the user interface, while you still have the ability to directly execute any SQL statement.
phpMyAdmin Features:
phpMyAdmin Features:
- Sensitive web interface
- helps for most MySQL features:
- Browse and drop databases, tables, views, fields and indexes
- Create, copy, drop, rename and alter databases, tables, fields and indexes
- Maintenance server, databases and tables, with proposals on server configuration
- Execute, edit and bookmark any SQL-statement, even batch-queries
- Manage MySQL users and privileges
- Manage stored procedures and triggers
- Import data from CSV and SQL
- Export data to various formats: CSV, SQL, XML, PDF, ISO/IEC 26300 - Open Document Text and Spreadsheet, Word, Excel, LATEX and others
- Administering multiple servers
- Creating PDF graphics of your database layout
- Creating complex queries using Query-by-example (QBE)
- Searching globally in a database or a subset of it
- Transforming stored data into any format using a set of predefined functions, like displaying BLOB-data as image or download-link
- And much more..
- click Here for download
Wednesday, May 6, 2015
Grand Theft Auto: Vice City Skin Pack free download
Grand Theft Auto: Vice City Skin Pack
This is a pack of more than 30 skins from various authors for Grand Theft Auto: Vice City to give Tommy a new look. Included are thunder cat skins, Adidas skins, a ghost rider with a flaming skull, a priest and much more.
Digital Hospital and Medical Information System final project of software Engineering
Digital Hospital and
Medical Information System
Table of Contents
1. Introduction
1.1
Purpose
1.2 Scope of Document
1.3 Definitions, Acronyms, and
Abbreviations
1.4 References
1.5 Overview of document
2.
Description of Project
2.1 Project Overview
2.2 Project Functions
2.3 User Characteristics
2.4 Constraints to Project Development
and Implementation
2.5 Assumptions and Dependencies
3. Specific
Requirements of Physician Office System
3.1 Functional Requirements of Physician
Digital Record System
3.2 Non- Functional Requirements of
Physician Digital Record System
3.3 Physician Digital Record System
Performance
3.4 Logical Database Requirements
3.5 Design Constraints
4. Specific Requirements of Hospital System
4.1 Functional Requirements of Hospital
Digital Record System
4.2 Non- Functional Requirements of
Hospital Digital Record System
4.3 Hospital Digital Record System
Performance
4.4 Logical Database Requirements
4.5 Design Constraints
5. Specific Requirements of Real-time Patient
Monitoring System
5.1 Functional Requirements of Real-time
Patient Monitoring System
5.2 Non- Functional Requirements of
Real-time Patient Monitoring System
5.3 Real-time Patient Monitoring System
Performance
5.4 Design Constraints
6. Specific Requirements of Ambulatory Medical System
6.1 Functional Requirements of
Ambulatory Medical System
6.2 Non- Functional Requirements of
Ambulatory Medical System
6.3 Real-time Ambulatory Medical System
Performance
6.4 Design Constraints
1. Introduction
1.1 Purpose
The
software requirement specification document is specifically designed to
delineate the boundaries of the Healthcare Information System design and functionality.
Parties interested in this documentation would include but not be limited to
the system owners, the system users, the project manager and the design team.
1.2 Scope of Document
This document will identify the pertinent
software products we will develop including a Host DBMS, JAVA software
supported and web-based Patient, Physician, and Ambulatory Input/Outputs, and
sensor driven inputs for real-time patient monitoring. The SRS will show that
we will be utilizing SQL server and ASP for interfacing with the Input/Outputs
as well as Java applets for the real-time acquisition of health data from
remote sources. Finally, utilizing the security attributes of XML, XSL, and a
secure socket layer in the protocol stack we hope to address the valid security
concerns about the networking and transmission of confidential health care
information.
In addition to the specific design
components of this software, this document will make clear the design team’s
goals of creating value-added software which not only correctly captures
patient health information, but then efficiently stores it, sorts it, retrieves
it, and delivers this critical care information where it is needed by
healthcare professionals. The benefit of having accurate, complete, and timely
health information is that it will inevitably save human lives.
This software is deliberately focused on
medical records and the associated diagnostics. It is important to point out
that this system which is life critical will not have cross functionality regarding
appointment management, billing, or insurance functions, however diagnostic
codes sets will be compliant with present Federal law.
1.3 Definitions, Acronyms, and
Abbreviations
1.3.1 Electro-cardiogram (ECG). A
device that measures the electrical activity in a biological heart and measures
heart rate.
1.3.2 Pulse oximeter. A device that
employs monochromatic light to measures percentages of oxygenated hemoglobin in
blood.
1.3.3 Systolic blood pressure. The peak
pressure in the arterial circulatory system.
1.3.4 Diastolic blood pressure. The
pressure at which the heart’s aortic valve closes.
1.3.5 Emergency medical technician
(EMT). A trained emergency healthcare specialist.
1.3.6 Oscilloscope monitor. A cathode
ray tube capable of representing a beam of light that simulates a heart rhythm
waveform.
1.3.7 (HIPAA) -The Health Insurance
Portability and Accountability Act of 1996
1.3.8 (SDLC)-The Systems Development
Life Cycle.
1.3.9 Non-Digitized Professionals.
Health Care providers who have no access to digital records through lack of
hardware, software, or preference to legacy flat file charting methods.
1.3.10 (AES)-Advanced Encryption Standard
1.3.11 (DSP) -Distributed Services
Provider
1.3.12 (ASP) –Application Service
Provider
1.3.13 (FAT32) - File Allocation Table
32 Bit
1.3.14 (TIFF) – Tag Image File Format
1.3.15 (JPEG) - Joint Photographic
Experts Group
1.3.16 (DOB) – Date of Birth
1.3.17 Vendor. A licensed and
authorized agent of the development team or their vested remaindermen.
1.3.18 ISO 8601. A standard format for
representing date and time recommended by the International Organization for Standardization
1.3.19 Initial patient information.
Information normally gathered during a patient’s first arrival in a healthcare
provider’s office or in an emergency room. This includes but not limited to
name, address, Social Security Number and any health insurance numbers.
1.3.20 (fps) – Frames per second
1.3.21 (CISDC) – Computer Information
Society Design Competition
1.4 References
[1] Mack, Francis E. MD, Personal Interview February 1, 2003
[2]Sundaram, Senthilnathan, Requirements Analysis of Software
Requirements for Telemedicine and the HealthCare Industry, Master Thesis,
UCF,
Orlando,
Florida, July 19, 2002
1.5 Overview of document
The Software
Requirement Specification will define and illustrate the overall project and
its requirements- both functional and non-functional. In addition the SRS will define the users and
their respective characteristics as well as any constraints to development that
the team has identified.
The format of the SRS document will
address the overall project first- including functions and objectives in an
overview. This section will also address how this software interfaces with
other legacy systems and/or diagnostic equipment connected to it. Then the
subsequent sections will specifically addresses the components of the larger
software system. These sections delineate specifications for every facet of the
components design.
2.
Description of Project
2.1 Project Overview
Medical
records are the keystone to the healthcare profession; however these records
are not utilized to their fullest potential. Often records are inaccurate, misplaced,
and /or duplicated unnecessarily. In a world which recognizes the improvement
of data digitization and networking as a constructive force which often
increases efficiency while lowering costs; it is our view that medical records
networking could only benefit the quality of healthcare offered in the United
States.
An information system which is
primarily linked between a physician’s office and his hospital would be able to
capture and store data from either location giving access to diagnostics from
satellite locations. Added functionality could include ability to gather data
in real time from a remote monitor or an inbound Emergency transport vehicle.
[2]
This information system is an
industry-compliant application, based upon an open architecture (Microsoft
NT/SQL relational database), and is designed to function within a standard IEEE
compliant Ethernet (10 or 100) Local or Wide Area Network environment, and will also include
Wireless capabilities. The communications protocol is TCP/IP, and is supported
under any routing protocol within an infrastructure (routed or bridged).
The software is based upon standard
and emerging web technologies, requiring a workstation to only be capable of
running an Internet Browser such as Microsoft’s Internet Explorer and Netscape
Navigator. Within the browser Java applets will parse and display real-time
data in the form of streaming MPEG 4 video, still images in JPEG or Tiff
format, and a java bean real-time graph plotter from diagnostic equipment
anywhere within the network.
As a Distributed Systems Provider
(DSP) the system offers all the advantages of an Application Service Provider
(ASP), but overcomes security and proximity issues by allowing hospitals to
keep the primary system at their facility.
2.2 Project Functions
2.2.1 The
software code should be portable between different operating systems such as
Linux and Windows.
2.2.2
The software should be easy to use and should require minimum manual operation.
2.2.3 The
software should have a user-familiar interface so that the system would not
pose an additional workload to the users.
Note. Interface design would follow
generally accepted model conventions for placement of dropdown menus and
toolbars.
2.2.4 The
software should allow bidirectional synchronous communication between the user
and the data source in real time.
2.2.5 The software should provide security of operation and
confidentiality of information (restricting access to non-privileged users), by
FAT32 compression of data and Rijndael (AES) encryption algorithms.
2.2.6 The
software should allow collection of vital signs and still images of the patient
for visual inspection by experts.
2.2.7
The software should have tools for computer assisted diagnosis like an electronic
stethoscope, a blood oxygen sensor, ECG, and a digital sphygmomanometer.
2.2.8
The software should be able to avoid congestion while transmitting high volumes
of data and images in real-time.
2.2.9
The software should sample video images from diagnostic equipment automatically
at 30fps or rates compatible with the transmission capacity available.
2.2.10 The
software should be able to interface
and link all components of system refer to Figure 2.2.1
Figure 2.2.1 Context Diagram
2.2.11 The system will extend the data capabilities of the Physician’s office,
the hospital, and emergency personnel. Refer to Figure 2.2.2
Figure 2.2.2 Use Cases
2.3 User Characteristics
2.3.1 The primary user will be a
healthcare professional like a physician, a nurse, or an emergency medical
technician.
Note. This is a Medical
Information System therefore to limit access and ensure integrity of the data
only licensed medical personnel have access to input, search, and update
functions.
2.3.2
Nurse Administrators, Physician Office Administrators, System
Administrators and/or Therapists will have limited access and information
capabilities.
Note: For the reasons clearly stated in 2.3.1 the System
Administrator (or Vendor) will only be able to access data with his Admin
access code in combination with the Physician’s code while in the physician’s
presence.
2.4 Constraints to Project Development
and Implementation
2.4.1 The
Health Insurance Portability and Accountability Act of 1996 (HIPAA) has
mandated various standards on security, privacy, transaction and code sets, and
unique healthcare identifiers to which this system must adhere.
2.4.2 Legacy systems in place
must be considered and modified to interface with the new system design.
2.4.3 The timebox which
encapsulates the SDLC may limit some functionality of the system.
2.4.4 Both the hospital and
physician database will need large storage capabilities and a process to
archive outdated data.
(Note. Method and size of Database storage TBD)
2.4.5 Paper flat file medical
records will need to be produced and stored to ensure ability to handle
non-digitized medical professionals.
2.5 Assumptions and Dependencies
2.5.1 The system
relies on a Physician relationship with a hospital system with which he/she is
a staff member.
2.5.2 The SDLC chosen to implement the system will be model driven
and based on subsequent versions to insure data integrity and functionality.
Refer to figure 2.5.1
2.5.3 Due to report length constraints imposed by CISDC, HIPAA
regulations will be strictly followed but kept as a stand alone document.
Model Driven System Development Life Cycle
Figure 2.5.1 Model Driven Hybrid SDLC
3. Specific
Requirements of Physician Office System
3.1 Functional Requirements of Physician
Digital Record System
3.1.1 The software must allow input of
patient data from patient (initial) home, secured access at Physician and Nurse
Workstations, and from the data streaming real-time monitoring equipment.
Note. A web-based
system can allow initial patient information to be gathered by a dumb terminal
in office or from patient’s own computer upon Email appointment verification
hyperlinked to a web-based input screen.
3.1.2 The software must request username and password for
access to data, only after authentication will allow access to the system.
3.1.3 The software must require high levels of error correction and input
validation.
Note.
Message box prompts would require a second entry of key data fields including
name, DOB, Social Security Number, medications and allergies. Doctor’s inputs
will similarly prompt proper code sets for diagnosis.
3.1.4 The software must allow
browsing by the physician of historical medical information of his/her patients
only.
3.1.5 The
software must
identify the patient by a unique numeric identifier derived from a function
performed on the patient’s birth date.
Note.
Algorithm will be simply TODAY-BIRTHDAY = NUM& Doctor key & Increment
(Increment
will be added if duplicate number found in Database.)
3.1.6 The software
must retrieve,
update, and store data from multiple input locations including but not limited
to hospital workstations, physician workstations, inbound emergency vehicles,
and electronic monitoring equipment.
3.1.7 The
software must allow
patient to view their own medical record online allowing changes only to
address, phone number, and insurer after initial input.
3.1.8 The
software must only allow
deletions by the vendor and only after archiving data in flat file format.
Reference 2.4.4
Note.
Deletions will only be performed at the request of the patient or the
decedent’s heirs in compliance with HIPAA guidelines.
3.1.9 The software to be developed
must display the correct patient name.
3.1.10 The software to be developed
shall display the correct time of day in compliance with ISO 8601. Reference 1.3.18
3.1.11 The software to be developed
must operate without interruption twenty-four hours a day.
3.1.12 The software must allow full and complete record search queries by
physicians; also allow access to limited bloodwork, medication, and allergen
information by EMT personnel and display results in order specified by
operator.
3.1.13 The software must allow input of
diagnostic imagery and FAT32 compression for storage and transmission of data.
3.1.14 The software must enable out put of real-time data and imagery from
electronic diagnostic equipment through java applets which run in the web
browser. Refer to 2.1
Note: Nurses at workstation or
doctors at desktop can access this data.
3.1.15 The software must retrieve and sort medical record information and allow
for screen and print output of said information.
Note. Print output will include name,
DOB, and requested diagnostic information only.
3.1.16 The software must encrypt the data using Rijndael (AES) encryption
algorithms from the
database for transmission from point to point.
3.2 Non- Functional Requirements of
Physician Digital Record System
3.2.1 The
software interface must follow design conventions which allow for familiar
location of drop down menus, help etc.
3.2.2 Input errors will be returned in red with
appropriate message box.
3.2.3 More than three
attempts at login and failure will produce a red flag to system administrator.
3.3 Physician Digital Record System
Performance Requirements
3.3.1 The Physician software should be
able to support at least three simultaneous users.
3.3.2The Physician software should
support diagnostics inputs (see section 5.1), three terminals and a SQL server
database.
3.3.3 95% of the transactions shall be
processed in less than one second.
3.3.4 Data should be secured and backed up every quarter hour.
3.3.5 Power supply should have a back
up and a disaster recovery plan.
3.3.6 System should be operable 8 hours
a day and accessible in real-time.
3.3.7 Secure Socket Layer 3.0 with 128
bit encryption will enable network security
3.4 Logical Database Requirements
Figure 3.4.1 Physicians
Office Entity Relationship Diagram
3.5 Design Constraints
3.5.1 Hardware, software, and data
communication elements must be sourced within budgetary constraints.
4. Specific Requirements of Hospital System
4.1 Functional Requirements of Hospital
Digital Record System
4.1.1 The software must allow input of patient data from the patient and the
Physician.
Note. A web-based
system can allow initial patient information to be gathered by a dumb terminal
in office or from patient’s own computer upon Email appointment verification
hyperlinked to input screen.
4.1.2 The software must request username and password for access to data, only
after authentication the system will allow access.
4.1.3 The
software must require
high levels of error correction and input validation.
Note.
Message box prompts would require a second entry of key data fields including
name, DOB, Social Security Number, medications and allergies. Doctor’s inputs
will similarly prompt proper code sets for diagnosis.
4.1.4 The
software must
allow browsing by the physician of historical medical information of his/her
patients only.`1
4.1.5 The
software must identify
the patient by a unique numeric identifier derived from a function performed on
the patient’s birth date.
Note.
Algorithm will be simply TODAY-BIRTHDAY = NUM & Doctor Key & Increment
(Increment
will be added if duplicate number found in Database.)
4.1.6 The
software must retrieve,
update, and store data from multiple input locations including but not limited
to hospital workstations, physician workstations, inbound emergency vehicles,
and the electronic monitoring equipment.
4.1.7 The
software must allow
patient to view their own medical record online allowing changes only to
address, Insurance # and phone number.
4.1.8 The
software must only allow
deletions by the vendor and only after archiving data. Reference 2.4.4
4.1.9 The software to be developed
must display the correct patient name.
4.1.10 The software to be developed
shall display the correct time of day in compliance with ISO 8601. Refer to 1.3.18
4.1.11 The software to be developed
must operate twenty-four hours a day.
4.1.12 The software must allow full and complete record search queries by
physicians; also allow access to limited bloodwork, medication, and allergen
information by EMT personnel and display results in order specified by
operator.
4.1.13 The software must allow input of
diagnostic imagery and FAT32 compression for storage and transmission of data.
4.1.14 The software must enable out put of real-time data and imagery from
electronic diagnostic equipment through java applets which run in the web
browser.
Note: Nurses at workstation or
doctors at desktop can access this data.
4.1.15The software must retrieve
and sort medical record information and allow for screen and print output of
said information.
Note. Print output will
include name, DOB, and requested diagnostic information only.
4.1.16 The software must encrypt the data using Rijndael (AES) encryption
algorithms from the
database for transmission from point to point.
4.2 Non- Functional Requirements of
Hospital Digital Record System
4.2.1 The
software interface must follow design conventions which allow for familiar
location of drop down menus, help etc.
4.2.2 Input errors will be
returned in red with appropriate message box.
4.2.3 More than three
attempts at login and failure will produce a red flag to system administrator.
4.3 Hospital Digital Record System
Performance Requirements
3.3.1 The Hospital software should be able to support up to 300
simultaneous users.
3.3.2The Hospital software should support an internet server,
diagnostics inputs (see section 5.1), thirty two terminals and a SQL server
database.
3.3.3 95% of the transactions shall be processed in less than one
second.
3.3.4 Data should be secured and backed up every quarter hour.
3.3.5 Power supply should have a back up and a disaster recovery
plan.
3.3.6 System should be operable 24 hours a day and accessible in
real-time.
3.3.7 Secure Socket Layer 3.0 with 128 bit encryption will enable
network security
4.4 Logical Database Requirements
TBD
4.5 Design Constraints
4.5.1 Hardware, software, and
data communication elements must be sourced within budgetary constraints.
5. Specific Requirements of Real-time Patient
Monitoring System
5.1 Functional Requirements of Real-time
Patient Monitoring System
5.1.1 The software to be developed shall accept output from existing patient monitoring equipment.
5.1.2 The software to be developed shall display graphical and numeric data
at a remote location in real time.
5.1.3 The software to be developed shall graphically display output from an
ECG oscilloscope monitor.
5.1.4 The software to be developed shall display numeric output from an ECG
monitor.
5.1.5 The software to be developed
shall display numeric percentages from a pulse oximeter.
5.1.6 The software to be developed shall display numeric values for systolic
blood pressure.
5.1.7 The software to be developed shall display numeric values for
diastolic blood pressure.
5.1.8 The software to be developed shall display numeric values for mean
blood pressure.
5.1.9 The software to be developed shall display numeric values for body
temperature.
5.1.10 The software to be developed shall display text values for patient
identification.
5.1.11 The software to be developed shall display text values for time of
day.
5.2 Non- Functional Requirements of
Real-time Patient Monitoring System
5.2.1 The software to be developed must display correct numeric pulse
oximeter values at a remote location within five seconds. (Note. Correct values
within 3% of actual [1])
5.2.2 The software to be developed must display correct numeric ECG values
at a remote location within five seconds.
5.2.3 The software to be developed must display a correct graphical ECG
oscilloscope waveform at a remote location within five seconds.
5.2.4 The software to be developed must display correct numeric blood
pressure values at a remote location within five seconds.
5.2.5 The software to be developed must display correct numeric body
temperature values at a remote location within five seconds.
5.2.6 The software to be developed must display the correct patient name.
5.2.7 The software to be developed shall display the correct time of day.
5.2.8 The software to be developed must operate twenty-four hours a day.
5.3 Real-time Patient Monitoring System
Performance Requirements
5.3.1 Acquisition of ECG
Data will require solid, wet gel, banana socket, snap or tab disposable electrode sensors.
5.3.2 Electrode (ECG) sensors will attach to electronic monitoring
equipment through 36 inch IEEE compliant universal lead wires. Refer to
Requirement 5.3.1
5.3.3 Pulse oximetry data must be collected using Masimo finger
sensor.
5.3.4 Masimo finger sensor must connect
to Masimo interface cable. Refer to Requirement 5.3.3
5.4 Design Constraints
5.4.1 Real-time Sensors and
Diagnostics may need to be simulated due to inability to access authentic
healthcare equipment.
5.4.2 Data Integrity and Security are life critical issues with this
system.
5.4.3 Redundant
power and transmission should be addressed as this system is life critical.
6. Specific Requirements of Ambulatory Medical System
6.1 Functional Requirements of
Ambulatory Medical System
(Note. Asked source about blood
type, allergies, etc. informed that information presently not relevant to EMT.
[1])
6.3.1 The software to be developed shall accept output from existing patient monitoring equipment.
6.3.2 The software to be developed shall display graphical and numeric data
at a remote location in real time.
6.3.3 The software to be developed shall graphically display output from an
EKG oscilloscope monitor.
6.3.4 The software to be developed shall display numeric output from an EKG
monitor.
6.3.5 The software to be developed
shall display numeric percentages from a pulse oximeter.
6.3.6 The software to be developed shall display numeric values for systolic
blood pressure.
6.3.7 The software to be developed shall display numeric values for
diastolic blood pressure.
6.3.8 The software to be developed shall display numeric values for mean
blood pressure.
6.3.9 The software to be developed shall display text values for patient
identification.
6.2 Non- Functional Requirements of
Ambulatory Medical System
6.4.1 The software to be developed must display correct numeric pulse
oximeter values at a remote location within five seconds. (Note. Correct values
within 3% of actual [1])
6.4.2 The software to be developed must display correct numeric EKG values
at a remote location within five seconds.
6.4.3 The software to be developed must display a correct graphical EKG
oscilloscope waveform at a remote location within five seconds.
6.4.4 The software to be developed must display correct numeric blood
pressure values at a remote location within five seconds.
6.4.5 The software to be developed must operate twenty-four hours a day.
6.3 Real-time Ambulatory Medical System
Performance Requirements
TBD
6.4 Design Constraints
TBD
End of
Software Requirements Specification
Subscribe to:
Posts (Atom)