joeism

UNC Software Engineering Laboratory

Comp 145 - Team 9

 

 

 

 

 

 

 

Contract I

 

February 6, 2001

 

 

Submitted to

Joe Colopy and

Prof. Greg Welch

 

 

 

PREFACE

The purpose of this contract is to verify the requirements with Joe Colopy, the Client.  This document is Version I of the contract, which we, Team 9, will deliver to the Client on February 6, 2001.  After receiving this document, the Team and Mr. Colopy will have one week (until February 13, 2001) to review the Contract and resolve any discrepancies in the requirements for the system being developed.  On February 13, 2001, the Team will deliver Version II of the contract, which will be validated by all members of the Team and the Client.  Version II will be the binding document for the production of the software for the Help System of Joeism.com.

 

GLOSSARY

DBI is a database Application Programming Interface (API) written in the form of a Perl5 module.

MySQL is a database management system.

Perl is an interpreted high-level programming language developed by Larry Wall.

 

1. INTRODUCTION

Joe Colopy, the Client, is the founder of Joesim.com, a web site designed to ease the process of building databases.  Joe Colopy is currently busy finishing version 0.2 of Joeism.com.  Team 9 has been contracted to build a help system for Joe Colopy’s web site due to his time constraints.  The Client needs the help system to stay in tune with the easy-to-use interface that Joeism.com uses.  Joe Colopy also expressed the need for three ways to access the help information; links from pages, navigable folders, and a search engine.  Joeism.com was created as a way for companies without the assets to hire Database Administrators to create databases for their company on the web.  According to Joe Colopy, this is the focus of the company: "Joeism allows organizations to power their website with a database solution that is easily created, configured, and maintained by non-technical personnel."


2. USER-LEVEL REQUIREMENTS SPECIFICATION

 

 

 

 

2-A.  User Interface

The user interface for the Help System will include three possible ways to access the help system.  The first will be from a link on a page in the Joeism.com site.  The second is a help button that opens a window containing folders to navigate through.  The third is a box where the user can input a word that they want to search for in the help database.

 

 

2-B.  Database

The database in the help system will contain all (graphics and text) help information for Joeism.com.      

 

 

2-C.  Processing

The processing for the database will be used to generate search results, construct indexed folders, and provide links with relevant information.

 

 

2-D.  Administrative Security

The security will allow for an administrator to have a password that allows them to update the database within the help system.

 

 

 

 

 

 

 

 

 


3. SYSTEM-LEVEL REQUIREMENTS SPECIFICATION

 

3.1. Functional Requirements

3.1.1    Behavior Model

 

a.       Data-Flow Diagram

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


b.      State Machine Model

 

 

 

 

 

 

 

 

 


3.1.2.   Data-Model

 

a.       From user to Joeism web page or help system: Keyword and item selection

b.      From Joeism web page or help system to Database API: A function call and keyword as a parameter of the function

c.       From Database API to Database: Query language

d.      From Database to Database API: Contents of table in the database

e.       From Database API to Web site: Content of table in the database

f.        From web page to user: Formatted contents corresponding to keyword

 

3.1.3.   Interface Requirement

a.       User Interface

 

-         User interface is based on web site.  Through web site, a user inputs a keyword, selects topic or navigates the help web site. 

-         Interface should be simple

-         A user can customize his/her help site.  Help web site should be popup window which can be generated from main web page (Joeism web site)

 

b.      Interfaces to other program

-         The help system should provide Perl script modules, so any web site or program, which can be extended in the future, can use Perl script modules.

 

 

 

 

3.1.4.   System-level Description

 

a.       Database for Help Topics - Topics will be indexed by ID#. Additional fields include topic, text for help entry and possibly a graphic (if applicable) for help entry.

b.      Website to Access Database - Access includes hierarchical directory navigation, keyword search function, and discussion forum.

c.       Password-protected Administration - Website that gives management functions over database, e.g. edit, delete, etc. Should also include importing graphics where necessary.

 

 

3.2.  Non-functional Requirements

3.2.1.   The help system should be developed with Perl script and MySql on the Linux machine.

3.2.2.   The help system should work other Unix systems such as SunOS and HP.

3.2.3.   The help system should not expose other user information

 

3.3.  Domain Requirements

3.3.1.   The coding style and comment should follow the standard, which is already used in Joeism.com.

3.3.2.   The design of help system should reciprocate the design of Joeism web site.  It should show some level of unification.

 

3.4.  Goals

A.     The help system focus on the user who is not familiar to data base system. 

B.     It needs to be simple and contains example, which can guide users to build their own database. 


4. HARDWARE AND SOFTWARE RESOURCE REQUIREMENTS

 

4.1 Plans to procure hardware and software:

Joe Colopy agreed and has allowed Team 9 access to his version of Linux and mySQL.

The team has a user name and password allowing them to telnet into or FTP to the Joeism.com resources.

 

4.2 Estimated schedule:

Not applicable, already have needed resources.

 

4.3 Alternatives:

Alternatives in case of mishap with Joeism.com resources is to use the Linux machines available in the computer science department, and a version of mySQL that we can download.

 

5. PRELIMINARY SCHEDULE

 

5.1 Development Items

5.1.1    Major Phases

a.       Design Phase – includes Contract I, Contract II and the design specification.  Contract II and the Design Specification may be done in parallel but both are dependent upon Contract I.

b.      Implementation Phase – includes the User Manual, Prototype, and the Midterm Presentation.  User Manual and Prototype may be done in parallel but the Midterm Presentation is dependent upon both.  All are dependent upon the Design Phase.

c.       Validation and Verification Phase – includes Implementation Manual and Testing.  Both are done in parallel and both are dependent upon completion of the Implementation Phase.

d.      Project Completion – includes Final Presentation, WWW Site Completion, Project Package, Team Report and Individual Report.  All dependent upon Validation and Verification Phase.

 

5.1.2    Major Milestones

a.       Contract I signed.

b.      Contract II signed.

c.       Design Specification complete.

d.      Prototype complete.

e.       Implementation Manual complete.

f.        Final Presentation.

 

5.1.3    Deliverables

a.       Contract I/II

b.      Design Specification

c.       User Manual

d.      Prototype

e.       Implementation Manual

f.        Project Package

g.       Team/Individual Reports

 


5.2 Schedule Diagrams

5.2.1 Gantt Chart

 

 

5.2.2. PERT Chart

 


 

 

 

 

5.3 Risks Analysis and Management

5.3.1.   Non-administrative users gaining access to help databases.

Plan

Use the user_id to allow access to edit pages.

User will view a different page than the administrators.

 

5.3.2.   Administrators accessing database of which they are not members.

Plan

Require each access to the database to have an admin key.

This will limit administrators from writing to other group’s databases and sheets in case they try to supply queries that include changing directories. 

 

5.3.3.   Links connected to right pages.

Plan

Test to see that links are pointing to proper location.

This will ease the frustration of users trying to navigate the pages.

 

5.3.4.   Users fill up their allotted spaces on database.

Plan

            Warn users of space limit so that they can manage it better.

            If the users want more space they can request it from help@joeism.com.

 

5.3.5.   Users entering in data that could be potentially harmful to the system.

            Ex. “rm *.*” removes all files from system.

Plan

Test for users input and restrict these types of actions through regular expressions.

Warn the administrator that this type of usage is illegal and could result in lose of privileges.