1 - Web Pages



TEAM B

Authors

Adnan Syed

Sepideh Dehghani

Jason Eastburn

Ryan Johnson

Kam Walia

Nadrowski Michael

Healthy Homes Network

Community Resources

Requirements Document

Table of Contents

1 Introduction 5

1.1 Goals and Objectives 5

1.2 Scope 5

1.3 Definitions 6

1.4 Assumptions 6

2 General Design Constraints 6

2.1 Product Environment 6

2.2 Administrator Side 6

2.3 User Characteristics 6

2.4 User Characteristics 7

2.5 Mandated Constraints 7

2.6 Potential System Evolution 7

3 Nonfunctional Requirements 7

3.1 Operational Requirements 7

3.2 Performance Requirements 7

3.3 Security Requirements 8

3.4 Safety Requirements 8

3.5 Legal Requirements 8

3.6 Other Quality Attributes 8

3.7 Documentation and Training 8

3.8 External Interface 8

3.8.1 User Interface 9

3.8.2 Software Interface 9

4 System Features 9

4.1 System Features and Maintenance 9

4.1.1 Description and Priority 9

4.1.2 Use Case: Display starting Page 9

4.1.3 Additional Requirements 10

4.2 Feature: Find Results 10

4.2.1 Description and Priority 10

4.2.2 Use Case: Search Database via Category 10

4.3 Feature: HHN System Maintenance 11

4.3.1 Description and Priority 11

4.3.2 Use Case: Maintain Database 11

5 HHN SYSTEM INSTUCTION MANUAL 11

5.1 HHN system Instruction Manual 12

5.1.1 DESCRIPTION 12

5.1.2 User Requirements 12

Introduction

1 Goals and Objectives

The main goals of the Healthy Homes Project are:

1. Expand and improve the existing database to store community resources for HHN.

2. Provide a friendly environment to maintain and update resources within the HHN database via a web browser.

3. The links needs to be set up in such a way that clients can follow their way with out looking for it all over the page.

4. The main page needs to be available on the side in order they decided to go back they don’t have to go through lot of troubles.

5. Simple database with web interface that allows administrator to delete or edit any data on the main page to the correct category.

6. The administrator page should take no longer than 5 minutes for an inexperienced user to input 1 source’s information.

7. Allow HHN users to find information fast to provide clients with correct and up-to-date information.

2 Scope

The system will solicit feedback from readers including written comments. Aggregate feedback from readers may be offered directly to other readers (i.e. articles might be rated), but unedited comments from readers will not automatically be made available to other readers. The reason for this is the quality of unedited comments is hard to control.

When the user click on any category, the category options will go on the side of the same page and the links about that category will appear (the reason for keeping the categories on the side is for the user convenience, the categories will be on the side of the page in order the user wishes to go back easily with out keep clicking the back button.). Inside each link there will be some written comments, telephone numbers of companies that have good experience with their name written on the page or some links that the user can view and be able to gather enough information on the topic that the user was looking for. This information will only be general because HHN wants the clients of their website database to visit or contact the links for detailed information.

After the administrator adds any information or any links, they just have to click on the submit button and all the updated data will accrue in the right category. It will be available for the user to access the contents. The user will see these updates whenever they refresh their browser. This database will be modified on the administrator side of the website. Field and Drop down boxes will be all the administrator can make changes on the database with in order to make is as simple as possible for them. The database will be an ACCESS database because future changes will be easily added in this program.

3 Definitions

All basic

1.4 Assumptions

The users and administrators will have basic knowledge of the computer and the internet.

General Design Constraints

1 Product Environment

The product will be hosted by Alentus, the ISP for HHN, website database will hosted on a web server running windows 2000 server Edition and IIS 5.0. The HHN system is located on a web page using ASP framework 1.1. The HHN database will maintained on the administrative side of the website. The administrator will control a relational database stored on the server in HTML which will contain general information about each source. The client will use web-based interface to access the database maintained by volunteers of the HHN.

2 Administrator Side

For the administrator convenience there will be a simple manual that the administrator will follow and it will help to update or delete any data or any information. This can be done with the administrator side of the website. These steps will be very simple and anybody with internet and typing knowledge will be able to follow them.

2.3 User Characteristics

Administrative User. This user will be responsible for maintaining the information through the web-based interface to the database. The administrative user will be a HHN employee or any user(s) designated by HHN with administrative rights to the HHN system. Basic training that should last around 10 minutes and a user’s manual will be provided for the administrative users. The user manual is discussed in more details in section 5 of this document.

General User. This user could be any user who uses the HHN system through the public website. The general user could be a HHN employee, a volunteer, or any individual designated to retrieve a resource on the HHN system.

2.4 User Characteristics

It’s important for developers to have a complete and accurate image of the end users. Even when the requirements of the user interface are described in detail the developer will still make many tiny design decisions during design and implementation. Knowing the general characteristics of the end users will help the developer make better decisions.

If the specific users of the system are know list them here. More likely there will be user roles or categories of uses. For each group of users list their responsibilities, characterize their knowledge of the domain and describe their characteristics including technical sophistication, background and education.

Prioritize users if necessary. This is especially important when user characteristics conflict. For example, if the system must accommodate experience users as well as novices it is important to know which should be given priority in case it’s not possible to accommodate both groups.

2.5 Mandated Constraints

No constraints are foreseen at this point, the database compatible with the alentus server.

2.6 Potential System Evolution

The resulting software system should be maintainable and extensible. Knowing the types of anticipated changes aids significantly in establishing an architecture that will accommodate the types of expected changes. This section suggests ways the system is likely to be extended or modified in the future. The evolution of the HHN will be the amount of categories and different services that they way offer in the future.

Nonfunctional Requirements

Nonfunctional requirements are properties the system must have. Nonfunctional requirements tend to be orthogonal to functional requirements. For example a system may have the nonfunctional requirement that it be offline no more than 15 minutes at a time and not more than ½ hour each week. This requirement applies to every functional requirement.

1 Operational Requirements

The data must be run on web browser such as Internet or Netscape.

2 Performance Requirements

The website will perform on any basic server with .NET.

3 Security Requirements

Access to data and features may be limited to specific users. There may also be a requirement to keep an audit trail of system use. This section describes the security requirements including the levels and what needs to be protected.

The level of security available to the HHN system is authentication. Administrative users are required to authenticate with the system before any additions, deletions or revisions can be made. General users are able to access the information, which is available on the HHN system which it will include the information that the administrative will add or update. They do not have to authenticate and cannot make any changes or copying from the data.

4 Safety Requirements

The system may affect the safety of the larger environment. For example, there are limits on the intensity of stray electromagnetic radiation from electronic devices used in hospitals. Potential safety concerns should be investigated and documented in this section.

5 Legal Requirements

Some security and safety requirements may also be legal requirements. For example, federal law protects confidentiality of medical records. HHN system is public information but all information will be screened before it reaches the website database.

6 Other Quality Attributes

There are specific sections above for non-functional quality attributes such as security, performance, etc. In this section describe any other non-functional quality attributes such as portability, availability, etc.

7 Documentation and Training

An important part of the total system is the documentation and training that is provided with the system. This section should describe the types and quantity of documentation and training that will be provided with the product.

Documentation will be provided to the client regarding use of the system. The client’s contact information is provided on the website if the user has any questions regarding the system. Training should not be required to the general user. Formal training or a user’s manual will be provided to administrative users.

8 External Interface

External interfaces may be user interfaces or software interfaces.

1 User Interface

The requirements document shouldn’t contain design or implementation details. The logical user interface should be described here. The description here shouldn’t unnecessarily constrain design and implementation options.

The general personality of the interface should be described here. For example, should the interface convey a conservative, professional, authoritative or fun attitude? What is the look and feel? Style? User characteristics were given above in section 2.2 but it may be helpful to characterize the average user here as adult, teenager or child.

User interfaces may contain a mixture of media types. It may be helpful to describe the desired/permissible user interface in terms of media elements.

Should the interface be intuitive or will training be provided. If training is required what types of training will be provided (online help, separate user manual, formal classroom training).

Ease-of-use requirements should be stated in a way that can be verified. For example, “the product should be easy to use” isn’t verifiable because it’s impossible to define “easy” in a measurable way. Must better is “75% of users will be able to use 80% of the features within 20 seconds without prior training”.

The user interface doesn’t need to be trained to use the web browser. For the administrative interface there will be a brief manual of how to update the data and this manual will be also a web-based.

2 Software Interface

The software interfaces may be locally addressable API’s or remote interfaces using technologies such as web services.

System Features

4.1 System Features and Maintenance

The cost, risk and value estimates given below are numerical values between 1 and 10 with 1 being the lowest value and 10 the highest.

1 Description and Priority

This feature explains the starting HHN web page.

Cost: 0

Risk: 1

Value: 9

2 Use Case: Display starting Page

Title: Display Starting Page

Actor: General User

Description: This use case begins when the general user visits the HHN website. The starting webpage outlines menu options to the general user. The general user can select any option by clicking on it, and the system will display the desired information in the main window. The user has the ability to change menu option at every step, without having to use the “GoBack” browser function.

3 Additional Requirements

User knows how to use a web browser and Administrator knows how to type data into field boxes on a website.

H.H.N. Diagram

[pic]

2 Feature: Find Results

1 Description and Priority

This feature explains the steps and procedures for searching for results from the HHN system.

Cost: 0

Risk: 3

Value: 10

2 Use Case: Search Database via Category

Title: Search Database via Category

Actor: HHN Employee

Description: This use case begins when a person with a need contacts the HHN employee. The employee selects to search via category. The employee selects the category. If there are sub-categories, the related sub-category will be selected. The system returns list of potential information sources, which include the information source, summary, and link for full information. The search selects one of the information sources. The system responds with the full information. There are no other searches other than category.

Search Database

[pic]

3 Feature: HHN System Maintenance

1 Description and Priority

Some features that support system maintenance are the ability to update/edit different items in the database along with the ability to delete them if they become out-dated or cease to exist.

2 Use Case: Maintain Database

Title: Maintain Database

Actor: HHN Administrative Employee

Description: This use case begins when a HHN administrative employee authenticates with the HHN system administrative interface.

HHN SYSTEM INSTUCTION MANUAL

HHN System Instruction Manual provides simple instruction for the HHN staff members. For convenience The Instruction Manual will be in two forms: a hard form (a typed instruction set) as well as online version.

Both forms of the instruction manual will be identical.

HHN system Instruction Manual

The main goals of the Instruction Manual are to provide the HHN staff with enough information to maintain the HHN database.

1 DESCRIPTION

This section outlines the main subsections of the Instruction Manual

5.1.1.1 Introduction

This section of the manual will outline what software application will be needed to operate the database as well as inform the HHN Staff members how to open and get these programs up and running. It will also explain how to log in to the Staff Only section.

5.1.1.2 Adding New Data

This section of the manual will show the HHN Staff Members how to populate the database using Microsoft Access Database.

5.1.1.3 Updating Existing Data

This section of the manual will explain the HHN Staff Members how to update existing database information. Note that these instructions will be very similar to the “Adding New Data” instructions.

5.1.14 Removing Data

This section of the manual will explain the HHN Staff Members how to delete information from the database.

5.1.2 User Requirements

HHN Staff Members will be familiar with basic computer concepts such as turning on the computer system and knowing how to use computer mouse and keyboard.

-----------------------

[pic]

Just phone number of some businesses who can help

Information for the requested category with a phone numbers of Businesses that can help

Some categories contain sub-categories

Pick a Category

From the list on the side of HHN site

Delete category

Edit category

Add category

Login require

Administer site

HHN web site

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download