Product Specification Document
BACK TO:

Product Specification Document

Contributors:
Dave Bartle
David Emery
Richard Hoffman
Mark Holmes
Nate Jones
Clifton Pee
Document Title:
Product Specification Document
Last Modified on:
Wednesday 11/01/00 11:18:26 AM

Product Specification Document

Table of Contents

  1. Introduction and Feasibility Analysis
  2. Description and Overview of Planned Product
  3. Management Requirements
  4. Hardware and Software Requirements
  5. Program Requirements

Section 1 - Introduction and Feasibility Analysis

1.1 - Document Overview

     The purpose of the Product Specification Document (PSD) is to describe clearly, explicitly, precisely, completely, and without ambiguity the functionality and constraints of the system. In other words, what shall the software product do to meet the customer's requirements?

1.2 - Problem Definition

     The need that we are faced with is a unified access tool to the numerous electronic resources on campus. As of yet, there is no linked access of any kind. There is also a need to facilitate expanded communication between students and faculty, that which can best be addressed and accomplished electronically.

     Therefore, there is a desire for a home front, or "starting point" from where users will be able to have all the resources simultaneously at their finger tips, in a comfortable, unthreatening way, as an interface to otherwise independently organized services.

1.3 - Justification for Product

     The web is quite possibly the most widely recognized interface. It allows for a simple, familiar, and unified look and feel that everyone can use, with minimal instruction. The goal is to create a product that solves the addressed problem with an interface that is as unthreatening as possible, hopefully encouraging users to use it. The hope is that the web interface will provide for that.

     Another beneficial aspect of a web interface is the fact that it is broadly cross platform, which makes it easy to work with for administrators and users alike. It is highly ubiquitous.

1.4 - List and Description of Alternative Solutions

  • Authentication and Directory Services
    • These services are at the heart of this project. The final protocols that are selected must be highly extendable and supported well. These are all possible solutions for facilitating user/password authentication:
    • NT - Windows NT method of authentication. Easy System administration but very slow.
    • Lightweight Directory Access Protocol (LDAP) - LDAP is a database model authentication method. Growing support but still in the pioneering stages of use. Two possible products to implement LDAP are OpenLDAP & Netscape LDAP.
    • passwd file - Very old method of UNIX authentication. Very standardized.
    • shadow passwd file - This is an authentication method that hides both the salt and the hash (the users password) in the passwd file. The passwords are contained in another file that can not be read by others.
    • Network Information Service (NIS) - NIS is a network naming and authentication system by Sun Microsystems. It is often used in conjunction with NFS.
    • Password Authentication Module (PAM) - PAM is an interface that can interpret client request for authentication into a variety of different authentication modules.
    • Active Directory - Microsoft's answer to LDAP. Its features almost parallel LDAP's but the interfaces are largely proprietary.
    • Samba - An extremely flexible file service provider for the UNIX platform. Supports authentication in the style of NT.
    • Structured Query Language (SQL) Database - SQL was and has been used as a standard database query language and is widely supported by all platforms.
  • Web service
    • This service will provide all static pages and dynamic pages that the user will see. These are possible web servers out there:
    • Apache - Free, Open Source web server. Currently 54% of all web servers are implemented by Apache.
    • Internet Information Server (IIS) on NT - Comes with NT and has wizards to help create a quick website
    • fHTTPd - fHTTPd is an FTP/HTTP server with modules support. It can also be configured to access files, run scripts and modules under mapped user's ID.
    • Lotus - Application, calendaring, secure server by Lotus
    • Netscape - Application, calendaring and secure server by Netscape
    • Oracle - Application, calendaring and secure server by Oracle
  • File access service
    • These are different ways that we could implement a file service to users:
    • Samba/NT - Samba supports NT-style authentication and the sharing of files and printers with NT and all NT compatible clients. It also can serve as a replacement to Netware, Warp and NFS. It is used on UNIX-based machines.
    • CODA - A distributed file system with synchronization. Still in development phases
    • Network File System (NFS) - NFS that uses TCP/IP. Widely used for remote file access. NFS is a standardized protocol for file access.
    • File Transfer Protocol/Hypertext Transfer Protocol (FTP/HTTP) - FTP and HTTP. These are both Internet standards.
    • AppleTalk/Netatalk - Macintosh file services
    • scp (ssh) - Encrypted (RSA, IDEA, etc.) file copy utility using the secure shell (ssh) protocol from one client to another.
    • Andrew File System (AFS) - The AFS uses a caching mechanism to speed access to its remote file system.
    • Novell - Novell allows Macintosh and Microsoft Windows based machines to access the file system over the network.
  • Chat service
    • The chat service allows students to talk to each other in an online chat environment.
    • Internet Relay Chat (IRC) w/ separate client - Run an IRC service on the server with a separate downloadable chat client. No control of the client is necessary by administration.
    • Internet Relay Chat (IRC) w/ java client - Run an IRC service on the server with a java-based client that runs inside of the web browser. Controllable and updateable by administration
    • ICQ/AIM (AOL Instant Messanger)/other - These are all proprietary chat services that have their own servers and separately available clients.
    • Internally Developed Chat Service - Both the server and client are developed by our team.
  • News service
    • The news service will enable users to access newsgroup-style discussion groups.
    • NNTP (Network News Transfer Protocol) - the predominant protocol used by server and client computers for managing notes posted on newsgroups.
    • Internally Developed Newsgroup Service - The newsgroups server is implemented with a SQL backend.
  • E-mail services
    • E-mail services allow remote access to email held on a server.
    • Post Office Protocol 3 (POP3) - POP3 is the most recent version of a standard protocol for accessing remote e-mail. POP3 is a protocol in which e-mail is downloaded to the client machine.
    • Simple Mail Transfer Protocol (SMTP) - SMTP is a standard protocol for sending and transferring e-mail.
    • Internet Message Access Protocol (IMAP) - IMAP is a standard protocol for accessing e-mail from your local server. IMAP is a protocol in which e-mail is stored on the server.
    • MS Exchange - Exchange is an all-in-one client for accessing an Exchange server.
    • Internally Developed E-mail Service - The E-mail server developed by our team.
  • Database service
    • The database service holds information and provides a standard access method for inserting, updating, and removing data.
    • MySQL (Structured Query Language) - MySQL is a freely available implementation of the SQL language.
    • PostgrSQL (Postgres SQL) - Another freely available implementation of the SQL language.
    • Oracle - Commercially available SQL database service
    • Sybase - Commercially available SQL database service
    • MS Access - Commercially available flat file database service.
    • MS SQL Server - Commercially available SQL database service.
    • Lotus (proprietary) - Commercially available SQL database service.
  • Implementation Language(s)
    • The programming language is the interface between the different services and between us and the user.
    • PHP Hypertext Preprocessor (PHP3) - PHP3 is the third major release of a highly extensible, server-side, cross-platform, HTML-embedded scripting language.
    • Practical Extraction and Report Language (PERL) - PERL is a commercially-supported cross-platform scripting language and a GUI programming environment.
    • C/C++ - C is a structured, procedural programming language that has been widely used both for operating systems and applications. C++ is an extension to the C language including Object Oriented Programming philosophies.
    • Bash (sh) - Bash uses a text file that contains a sequence of commands for a UNIX-based operating system.

1.5 - Feasibility Analysis of Alternatives

     Not all of the aforementioned solutions are practical for the implementation that the client has in mind. We are explicitly using the UNIX platform which eliminates some of the alternatives. To keep the costs low, the costly choices have been discarded as well. Any solution that is either in alpha or beta stages or is not well supported has been discarded.

     Feasibility has been decided by the following factors:

  • Pre-established standards
  • Well supported solution
  • Cost effective solution
  • Dependable products

1.6 - Recommended Solution

Section 2 - Description and Overview of Planned Product

2.1 - Product Description

     2.1.1 - Product Features

The system shall provide features as described in this section:
  • Front-end
    • The web application
      • ÜBER module - This is the user's fully customizable "main" page, much like my.yahoo.com and my.netscape.com. It is responsible for displaying a small part of each user-specified module on a section of the page itself, and each module "area" is hyperlinked to the main page for that specific module.
        • Container for all other modules
        • Contains ubiquitous toolbar
        • Gets user's configuration
        • Sets session cookie
        • Displays custom screen
      • File access module - This is a function that will allow users to keep track of their own personal files. Users will be allotted a certain amount of space on the server where they may store files, make directories, etc., all this being accessible on the Web.
        • Permissions
        • Upload (binary/ASCII)
        • Download
        • Create file/dir
        • Delete file/dir
        • Move file/dir
        • List file/dir
        • Change directory
        • Mail to... link
        • Space remaining
        • File size
        • File name
        • Useable GUI
        • Trash can (emptied daily)
        • Archiving tools
        • Virus scanning tools
        • Shared directories
        • Configurable
      • Email module - This is a module that will keep track of a user's e-mail account online. With a look-and-feel resembling hotmail.com, it will allow the user to send, receive and organize his/her many e-mail messages, including the importation and exportation of messages from outside email addresses.
        • New messages
        • Add/delete folders
        • Hyperlinked addressbook
        • Personal and global address lists
        • Addressbook entries as vCard files
        • Addressbook as a .addressbook (ala pine)
        • Import/export tab/space delimited address file
        • Import/export Netscape/IE/Eudora address book
        • Manage addressbook
        • Delete messages
        • Send message
        • Forward/reply to messages
        • Trash folder
        • Add/delete folder
        • Rename/move folder
        • Mailing list tools
        • Downloading email from other places
        • Forward your APU mail another server
        • Mail filtering (ala ProcMail)
        • MIME attachments
    • Look and Feel
      • Ubiquitous toolbar
        • On every page
        • Links
          • Logout
          • Customize
          • Help
          • Quick Access
          • apu.edu
      • Graphic design of all pages (templates)
        • To be worked on in the future
    • System Tools
      • Login (including page)
        This will handle the connection between the user and the server, authentication and the transportation of user-specified customizations from the server back to the user. It will also serve as a way to give the user any urgent messages AS he/she logs in.
        • Username and password
        • Chapel speakers for week
        • Top APU events/news for the week
        • Caf menu for the night
        • Any urgent or posted information
      • User Tools
        This will involve any configuration any normal user (non-administrator) may wish to invoke, including ÜBER module modifications.
        • Help
        • Change Module order/position
        • Change Themes
      • Administrator Tools - Allows administrators to oversee the product from the Web.
        • Update news for certain sections of site
        • Add and Delete users
        • Disable users
        • User preference creator
        • Backup scripts
        • Virus scanner
        • Miscellaneous trash collection
        • Change password/permissions
        • Configure user levels

     2.1.2 - Functions to be Provided

  • Access to "Start Page" of modules not requiring authentication
  • Unified login access
  • Personal desktop page of modules requiring authentication
  • User profiles and configurables
  • Full online help documentation
  • Web administration tools

     2.1.3 - Constraints

  • The product must run in any Netscape or Internet Explorer Browser version 3.02 and later. This will be accomplished by only utilizing those features present in both web browsers.
  • Several operating system platforms must be supported, including UNIX-based, Windows 3.1/95/98/NT and Mac OS
  • All administrative and personal tools must be accessible through a web interface
  • Security measures will be a priority
  • Already-existing standard UNIX tools must be used

     2.1.4 - Design and Other Solution Strategies

    N/A

Section 3 - Management Requirements

3.1 - Standard Practices

  • Weekly Team Meetings
    • Monday - Official meeting, beginning at 10:00 pm. Attendance is mandatory. Group information is disseminated.
    • Tuesday - Un-official work meeting, beginning at 7:00 pm. Attendance is voluntary.
  • Status reports on progress and research are due from each team member.

3.2 - Deliverables

  • Deliverables Created During Project
    • Problem Requirements Document (PRD)
    • Product Specification Document (PSD)
    • Software Project Management Plan (SPMP)
    • Architecture Design Document (ADD)
    • Software Design Document (SDD)
    • Acceptance Test Plan (ATP)
  • Final Deliverables (Deadline 12/15/99)
    • Well documented program with the following modules:
      • Email Client
      • File Management
    • Users Manual
    • Project Legacy Document (PLD)
    • Project Notebook

3.3 - Capstone Guidelines

     3.3.1 - Documentation Standards
  • Source Code File Documentation - Program documentation shall generally follow the guidelines as described in Code Complete by Steve McCrannel
    • Common Documentation Standards
      • General Documentation
        • Source Code File Format
          • Header
          • Variable Declarations
          • Functions
          • Main Function
        • Header Documentation

/*--------------------------------------------------------------------------------------------------
 * Filename    : PHONEBOOK.HTM
 * Module Name : Address Book
 * Developers  : Clifton Pee	
 * Created     : 10 Jul 97
 * Version     : X.X.X  MAJOR.MAJOR(but not requiring a version change).MINOR
 * File No.    : 1 of 499 done by section or module
 *
 * Parameters:
 * 	Any information which is passed into this file or program and from 
 *	where it may be passed
 *
 * Description:
 * 	Brief description of what this file does
 *
 * Logic:
 *	Pseudo-Code showing what the file does
 *
 * Database link:
 *
 * 	How you are getting to your database source (This includes 
 *	directory services and other databases)
 *
 * Tables Used: {HERE YOU INFORM WHAT YOU ARE DOING TO THE DATABASES}
 *
 * 	{DATABASE NAME} TABLE NAMES         SELECT UPDATE DELETE INSERT
 *	----------------------------------- ------ ------ ------ ------
 * 	DATABASE TABLE                        X      X
 *		
 * Standard Definitions: {NOT IN THIS FILE}
 *		
 * 	Definition Name        	Source
 * 	---------------------	-----------------------------------------------	
 *
 * Standard Routines: {NOT IN THIS FILE}
 *
 * 	Function Name		Source
 * 	---------------------	-----------------------------------------------
 *
 * Callable Functions: {IN THIS FILE} 
 *
 * 	Function Name		Description
 * 	---------------------	-----------------------------------------------
 *
 * Modification History: {DOCUMENT ALL CHANGES HERE}
 *
 * Date		Developer	Ver	Comment
 * ---------	-----------	---	--------------------------------------------
 * 25-Jul-97	Clifton Pee	2.1	Added comments and changed code to meet
 *					programming standards.
 *--------------------------------------------------------------------------------------------------
 */
        • Variable Documentation
var declaration		/* Global Variables are described here */
        • Function Documentation
/*-----------------------------------------------------------------------------------------------
*
* exactFunctionName( var sItUses)
* 
*   Brief description of what the function does
*
* Inputs: {ANY INPUTS IN THE FUNCTION CALL IE VAR sItUses}
*   sItUses:       Brief description of the point of this variable
*   
* Outputs: {ANY VALUSE RETURNED BY THE FUNCTION}
*   NONE
*
* Logic: 
*   Pseudo-Code telling what the function does
*
* Globals:
*   Any global variables used or changed by this function
*
* Locals:
*   Any local variables used in this function with brief description
*
*-------------------------------------------------------------------------------------------------
*/
        • Main Function Documentation
          • Every line does not require documentation
          • Format groups of commands like a switch statement or an if then else statement
          • Use a prose format not pseudo-code in documenting
      • Language Specific Standards
        • HTML files
        • C files
        • C++ files
        • Perl files
        • PHP files
  • Online Help Documentation - Document standards for the online help system.
    • Help Browser - All online, with hyperlinks between the sections.
      • Sections - One for each module
      • Glossary - Dictionary of terms that are not obvious to the everyday user.
    • Context Help - Accessible through a icon next to items which might require assistance
      • Explanation - Concise explanation of the function of the feature
      • Examples - Example entries
  • Special Documentation - Will be determined on a situational basis
  • Client Communication Documentation - All communication from the client, including emails, meeting notes, etc. will be filed in hard copy with a date stamp.
  • Project Documents Standard - Documenting procedures on documents produced by the project (i.e. PRD, PSD, etc.)
    • Location - All official project documents will reside in separate directories, the path being "/public_html/docs/<doc acronym>/". Also, the index.html file in "/public_html/docs/" will contain a link to each document's directory.
    • Document Conventions
      • Bulleted Lists - All bulleted lists will be formatted according to the following template (notice the indenting as well):

        • Topics with description and subtopics should be bolded to distinguish them from their respective descriptions and sub areas, but simple lists and simple sublists don't need to be bolded. Examples:

        Topics with descriptions and subtopics with descriptions.
        <ul>
        <li><b>Topic</b> - Description</li>
        <li><b>Topic</b></li>
        <ul>
        <li><b>Subtitle 1</b> - Description 1</li>
        <li><b>Subtitle 2</b> - Description 2</li>
        </ul>
        </ul>
        Simple lists.
        <ul>
        <li><b>Topic</b></li>
        <ul>
        <li>Item 1</li>
        <li>Item 2</li>
        </ul>
        </ul>
        Simple sublists.
        <ul>
        <li>Item 1</li><br>
        <li>Item 2</li><br>
        </ul>
        Topics with descriptions and subtopics with descriptions.
        • Topic - Description
        • Topic
          • Subtitle 1 - Description 1
          • Subtitle 2 - Description 2
        Simple lists.
        • Topic
          • Item 1
          • Item 2
        Simple sublists.
        • Item 1

        • Item 2


      • Paragraphs - All paragraphs will be single spaced with five spaces of indentation, and paragraphs will separated by a double space. Example:
        • <p>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence.
        </p>
        <p>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This is a sample sentence. This is a sample sentence. Hi Mom. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence.
        </p>

        Which yields:

             This is a sample sentence. This is a sample sentence. This is a sample sentence. Hi Dad. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence.

             This is a sample sentence. This is a sample sentence. This is a sample sentence. This is for all the people that helped me to this point. Thank you. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence. This is a sample sentence.

    • Document Management Files
      • template.php3 - This file is a template that can be copied to index.php3 in the document directory. It has two variables at the top, and then it includes header.inc and footer.inc. The first variable is $title. It should be set to the title of the document (of all things). The other is $filename. This is because the header contains the timestamp of whatever file is in this variable, so it should usually be index.php3.
      • header.inc - This file provides 2 functions. First, by being included at the top of each official document, it sets up the header for the document, with a credits area and the title centered. It also defines four functions for use in the document body. These are described as follows:
        • section(string $name) - This function increments the section counter, and then displays the Section Number, a dash, and then the $name variable in a HTML heading 1 tag (<h1>).
        • subsection(string $name) - This function increments the internal subsection counter, and then displays the section number, the subsection number, a dash, and then the $name variable in a HTML heading 4 tag (<h4>).
        • subsubsection(string $name) - This function increments the internal subsubsection counter, and then displays the Section Number, the subsection number, the subsubsection number, a dash, and then the contents of $name in an indented HTML heading 4 tag (<h4>)
        • minclude(string $filename) - This function is a wrapper to the basic php include() function. It tests for the existence of the file and then includes the file if it does or prints "Section Not Defined Yet" if it does not exist.
      • footer.inc - This file provides the horizontal bar at the bottom of the page, as well as links to the Project Documents Page and the SE Team Home-page.
  • Howto Document Standard - Document standards for any instructional documents created for the project.
    • Location - All Howto documents should be placed in the "~/public_html/docs/howtos/" directory and a link should be added to the howto section for the documents page.
    • Structure
      • Header
        • Name - All contributing members.
        • Date - Last modified date.
      • Title - Centered with a <h1>
      • Purpose - Stated clearly: What exactly will the reader be able to do after reading this document?
      • Body - Clearly defined steps, tutorial style with example output and listings of input and config files.
      • Other topics - List of topics that naturally descend from the tutorial and/or that pertain directly to our project.
      • Resources - List the hyperlinks/references of the resources that you consulted in creating this tutorial
  • Research Document Standard - Document standards for any documents created as a result of research for the project.
    • Location - All research based documents should be placed in the ~/public_html/docs/research/ directory and a link should be added in the lower section of the documents page.
    • Structure
      • Header
        • Name - All contributing members.
        • Date - Last modified date.
      • Title - Centered with a <h1>
      • Key Points - List the main points discovered in your research, as they pertain to the project.
      • Summary of Findings - In 2 to 4 paragraphs, Summarize your findings.
      • Questions - Optional. List any questions that come to mind that pertain to the topic, or that must be researched in order for the team to use this information.
      • Resources - List the hyperlinks/references of the resources that you consulted in researching this topic.

     3.3.2 - Special Procedures

  • Research
    • Weekly discussion meetings to update the team on new information
    • Open discussion to debate decisions relating to the project
    • Assigning new tasks (action items) to complete for the following meeting
  • Document Creation
    • Periodic group meetings for analysis and delegation of documentation work load
    • Individual HTML document creation
    • Compilation of separate HTML documents into one large document
    • Clarification and proofreading of the large document as a group until document is deliverable

     3.3.3 - Design and Implementation Priorities

  • Platform Independent - There will be a large emphasis in a unified look between differing web browsers.
    • Unix, Mac, or PC compatible
  • Useability
    • Ease of use
    • Consistency in layout
    • Design
    • High portability between browsers
  • Expandable/Upgradeable
    • Hardware upgradeable
    • Software upgradeable (add-on features)
  • Speedy access to database
  • Customizable user interface

     3.3.4 - Proposed Future Enhancements

     This product will be designed with high modularity, allowing for expansion and development. After initial implementation, cooperation from other departments will be required for resource and content upkeep. For example, the News and Events module might require a weekly submission from Chapel Programs for the Chapel bulletin, etc.

Section 4 - Hardware and Software Requirements

4.1 - Hardware/Software Environment

  • Hardware
    • One (1) Pentium II compatible or better machine running at 400MHz or better with no less than 256 megabytes of RAM. This is the PDC and serves as the synchronizer of the password/user information.
    • Two (2) Pentium compatible or better machines running at 266MHz or better with no less than 512 megabytes of RAM. These are the file and web servers.
    • Each computer will have at least one (1) NIC (Network Interface Card).
    • Each computer must have at least 1 gigabyte of storage space for the UNIX OS + Software needed for the Personal workspace.
    • Each computer acting as a file server must have no less than 50 megabytes of storage space for each users file space. This is estimated from (~5000 users) x (50 megabytes personal space) = (250 gigabyte).
    • The hard drives must be in a RAID2 configuration or better for data integrity. (Preferably RAID5).
    • All ports to the machines should be shut off except for those that are absolutely necessary (SMTP, NNTP, WWW, SMB, etc)
  • Software
    • The Operating System will be UNIX based.
    • The Apache web server v1.3+ with SSL, CGI, mod_perl, and mod_php enabled will be used.
    • Perl 5 and PHP3 (possibly some C for authentication) will be used as the CGI (Common Gateway Interface) parser.
    • A fully qualified SQL server will be used with speed in mind.
    • An LDAP implementation (OpenLDAP or UMICH) will be used to store user password, address, class standing, and phone information. It will serve as the password database.
    • Samba (SMB protocol) will be used to allow NT/Novell/Warp style authentication.
    • A synchronization tool (possibly custom written) will be needed to synchronize password changes via the two protocols SMB and PAM. Somehow, the LDAP database will contain all passwords and the smbpassword file will contain all passwords, unless Samba allows direct to LDAP authentication.

    4.2 - Documentation Environment

         4.2.1 - Development Environment

         4.2.2 - Implementation Environment

    • All user-targeted documentation will be in HTML format and will be stored both electronically and printed out for reference.
    • General setup instructions for the customer will be available. This includes the general interaction of the modules, the languages used to implement the modules, how to configure the modules, and the inputs and outputs that the modules produce (for interaction between modules).
    • General software and hardware requirements for the Personal Workspace will be listed.
    • All modules will be documented for the administrator.
    • All modules will be documented for the programmer (with function lists, usage, i/o, etc..).

    Section 5 - Program Requirements

    5.1 - Functional Specifications

    • Modular in design for easy addition/deletion of features
    • Template to be used for consistency in layout

    5.2 - Functions to be Provided by the System

    System functions to be provided are as follows:

    • General Application Programming Interface (API) for module insertion
    • Database support for:
      • user settings
      • authentication
      • user information
    • Server side user file storage
    • Web interface to server resources
    • Functional email service

    5.3 - Inputs, Processing, Output Requirements

         5.3.1 - External Interface Requirements

    • User Interface
      •
    • Graphical User Interface (GUI)
      • The web frontend will follow the web paradigm
      • Each web page will have a menu that allows access to the points of interest like email and file access
      • Menus can be customized from within a user profile
      • Each module will have a customization link
    • Help Screens
      • Floating windows
      • Howto for use of the interface
      • Context Sensitive for each module
      • All help accessible from a main index
    • Context Diagram - see attached
    • High Level Data Flow - see attached
    • Structure Diagram - see attached
    • HIPO Diagram - see attached
    • Operating Modes
      • Web client
        • User groups
        • Access rights based on group
        • Administration via the web
      • User selected client - operating modes are client dependent
    • Performance Requirements
      • Web application will be multi-threaded
      • Able to withstand high volume of traffic
      • Backup all user files
      • All servers must be on Uninterrupted Power Supply (UPS)
    • Memory Requirements and Constraints
      • Server memory requirements(see section 4.1)
      • Memory Requirements for the user's system must support at least a suitable browser. It may have to meet requirements for user's preferred client as well.
    • Response Time Requirements
      • All requests must be served within 10 seconds
      • If a request is known to take longer than this, the user should know about it
    • Exception Handling
      • All errors are logged
      • All fatal errors are reported to user and administrator
    • Testing Requirements
      • A testing document will be written at a later time



    Back to Documents
    Back to SE Home
    		 Product Specification Document
    © 1999 udeupa Software Engineering Team


    Direct problems or questions to support@apu.edu