Requirements Specifications

Rose Hulman Archive Project

Stephen Gregory

JP Gonzalez

Jonathan Knez

Table of Contents

1. Introduction

2. Special Terms/Abbreviations

3. Current Client System Diagram

4. User Characteristics

5. Requirements

6. Use Case Model

7. Problem Domain Model

8. Scope of the Project

9. Client Materials

10. Reference Material

11. To Do List

12. Revision History

 

1. Introduction

The client needs a new system to access the RHAP. The current system is inefficient and does not support the system in its entirety. This document describes the requirements for the software as desired by the client.

 

2. Special Terms/Abbreviations

3. Current Client System Diagram

4. User Characteristics

4.1 Users

The target user for this software is anybody in the general public.  This software is aimed at Students, Faculty, and Alumni.  They will know how to use a web browser, and they should not need special training or experience.

4.2 User's Environment

This software will be accessed through a web browser.  The user shouldn’t have to set up any special settings for this software to work appropriately in their native environment.  Many of the users may be using the system from inside the Logan Library, where most of the computers are thin-client terminals.  Because of this, the software will need to take up the smallest amount of resources possible.  The cgi script will be run on a server hosted by IAIT.  Backup and maintenance will continue as IAIT is currently doing it.  Any cosmetic changes will be performed by Richard Bernier.

5. Requirements

For this section we are using “IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1998, New York, NY:  IEEE, 1998.”

5. 1. External Interfaces

5.1.1 User Interfaces

The only interaction the user has with the software is through a web interface. Our web interface consists of a single webpage. Through this webpage the user performs searches and explores the returned results. They can input these searches by specifying keywords and categories or using a timeline which is broken up into subjects. This is the page layout as dictated by the client.

On the top of the webpage the links “Home”, “About”, “Contact” and “Help”, will take the user to some client written webpage.

In the middle left area the webpage contains checkboxes for “Newspaper”, “Modulus”, “Audio”, “Images” and “All”. These are the different categories the user can search in. The user must specify at least one category, but can also specify any combination of the above.

Immediately below is the text entry field, where the user enters the search keywords.

To the right of the text entry field we find the “search” button. By clicking on the button a searched is performed and its results are displayed on the middle right area of the webpage, which we will refer to as the “Result Area”.

The Result Area will list the results and highlight with a brown background the “Description field”. Below the description field, the source field will display the “Source” of the result i.e. “Rose-Hulman Modulus Yearbook, 1985”

On the bottom left part we find the Browse Tree. The top level nodes are the different topics. By expanding the topics you can go down to a specific year, at which point the results will be displayed on the Results Area. The images category will subcategorize by athletics, faculty and staff, students and miscellaneous. Each subcategory will expand to a timeline similar to that found in the other categories.

When looking at designing the page we strove to make it clean, simple, powerful and yet user friendly. It had to be simple enough for users with minimal computer skills, but powerful enough for users with advanced computer knowledge.

5.1.2 Hardware Interfaces - N/A

5.1.3 Software Interfaces - Look at Communication Interfaces.

5.1.4 Communication Interfaces

5.1.4.1 The client will communicate with the web server using the HTTP protocol.  The server will be running an Apache web server.

5.1.4.2 The web server will communicate with the database using oracle extensions for perl.  The server will be running Oracle.  The web server will use a cgi Interface to run the script.

5.2. Functional Requirements

The first requirement of the project is to accept search criteria from the user (i.e. keywords). In order to do this we must make sure there is a valid input. We will only accept one or more keywords, and will ignore any Boolean operator that is not followed by a keyword. Additionally, if no search category is specified then by default every category will be search.

The second requirement is searching the database. Using the gathered keywords and selected topics, a search will be performed on the database.

The third requirement is displaying the results returned by the database. If no results are found then an error message will be displayed on the Result Area.

The fourth requirement is expanding on a “clicked” result, by displaying pictures and/or text.

Here is diagram displaying the interaction between the different functional components.

5.3. Performance Requirements

Ask the client (not less than 30 not thin client users.)

At least support all the thin clients.

If it not fast enough on the server side ask IAIT to support Mod_Perl. This basically enhances server side Perl performance, by keeping the script cache.

Database Server should not be an issue on the speed and simultaneous requests.

5.4. Logical Database Requirements – N/A

5.5. Design Constraints

Use existing Database.

Run on Thin clients.

Run on Perl and Apache, requested by IAIT.

5.6. Software System Attributes

5.6.1 Reliability

 

We will build rock solid software. The software should never fail unless a server goes down. If a server did go down, IAIT would be in charge of getting it up and running again.


5.6.2 Availability

 

If either web server or database server where to go down, the searching webpage will still be available online, but it’s searching capabilities will not be present.

 

5.6.3 Security

 

The database we are accessing is of public domain, therefore there is no unauthorized reading access situation. Our software will only search the database; it will never need or try to populate it. We don’t use any user names or passwords that could potentially be used to modify the content of the database. Security will not be a problem in this system.

 

5.6.4 Maintainability

 

Once the system is set up, it will not need maintenance. New features would be handled by IAIT. They requested that it should be written in Perl because they are familiar with the language.


5.6.5 Portability

 

The client part of the system can be accessed in computers with different OS. The server side is very specific to the current system, so it is not portable.

5.7. Other Requirements

Other requirements be the client were to be able to search or browse by modulus, newspaper, audio and images. When browsing, the modulus, newspaper, and audio categories will expand to a timeline selector. From there a specific year will be chosen and all the results from that year will be displayed. The images category will expand to subcategories such as faculty and athletics. When the subcategory is chosen a timeline selector will appear.

We also must make the system robust enough to allow future expandability. For example, if the client wants to add a “performing arts” category as a search option, then he should be able to do so with minimal effort. The client has also expressed in interest in having the years displayed in the timeline to be automatically generated from the database. This way, when new data is added, there will be minimal, if any, changes required of the web page.

6. Use Case Model

6.1 Use Cases

1 - Use Case - UserSearchWebPage Search

Overview:

In this scenario the user submits a search request

Preconditions:

The user must be at the search page.

Scenario:

User Action

System Reaction

user fills in the keyword field by typing on the keyboard

The keywords are displayed on the screen

User clicks the “search” button

The webpage checks the validity of the search request then sends the request to the database.

Scenario Notes:

Post Condition:

The database will return the first ten results and the number of results total. The web page will then display those results in a user friendly fashion.

Exceptions:

The search request is only submitted if it is valid. If it is not valid, any valid portion is submitted otherwise an error message is displayed in the search results area.

 2 - Use Case - UserBrowseWebPage Browse

Overview:

In this scenario the user is “browsing” the database using the topic tree.

Preconditions:

The user must be at the search page.

Scenario:

User Action

System Reaction

User clicks on a subject of the topic tree

That subject is expanded to the appropriate category. Usually this will be a timeline.

User browses further into the sub-tree or chooses another subject to browse.

The webpage will expand further into the tree. At the lowest level this will be a timeline. If the user chooses another subject to browse the tree will expand accordingly.

User has browsed the tree down to a specific year

The webpage submits the search request to the server

Scenario Notes: N/A.

Post Condition:

The database will return the first ten results and the number of results total. The web page will then display those results in a user friendly fashion.

Exceptions:

If there is no data in the database for that year, a message will be displayed in the search results area that states that there is currently no data for that time frame.

3 - Use Case - UserDisplayWebPage DisplayResults>

Overview:

The user clicks on the link to view the result from a search request.

Preconditions:

The user must be at the search page and have successfully submitted a search request that resulted in 1 or more entries being returned.

Scenario:

User Action

System Reaction

User clicks on the link of the entry he wishes to view

That search entry is opened in a new window. For example, if it is a picture link, that picture will be opened in a new window.

Scenario Notes: N/A

Post Condition:

A new window is opened on top of any currently visible window. The search page remains unchanged after the new windows opens.

Exceptions:

If the browser does not support the file-type of the search result, than the built in browser error message will be displayed.

7. Problem Domain Model

8. Scope of the Project

The overall requirements should be met by the Rose-Hulman students during the span of the winter and spring quarters of 2003.

9. Client Materials

10. Reference Materials

11. To Do List 

Items

 Review with Mark Ardis and/or Don Bagger

Review Use Case Diagrams

12. Revision History

Date

Name

Revision

01/27/2003 

JP & Steve

Complete main ideas on everything except for Use Cases and User Interface.

01/28/2003 

JP & Jonathan 

Complete All Relevant to Use Cases and User Interface.

01/30/2003 

 JP

 Inserted diagrams, completed point 6 of Requirements, expanded on all points in the document, except for Use Cases and User Interface.

02/19/2003

JP

Inserted Table of Contents