Technical Assistance Request

2.2 Database Schemas

We are building our database using Microsoft Access. The database is made up of a hierarchal, or tree, structure composed of segment types.

The following are detailed views of the data tables we have built so far.

2.2.2 Table Name: SWTTar

Definition: This is the table showing the TAR’s accompanied various field categories.

Fields	Description/Definitions	Type
Number	The TAR’s identified number. Once the user opens the TAR, the system will automatically give the TAR number after the TAR is submitted.	integer
Project_Name	The name of the project that the TAR belongs to.	String,length (str)<=20
Open_Date	The specific date when the TAR opened	Mon/day/yr
Open_by	The person who creates the TAR	String,length (str)<=20
Owner	A person who is in charge of fixing the TAR.	String,length (str)<=20
Type	Type of the TAR. Ie. todo/enhancement/bug etc	String,length (str)<=20
Priority	Priority of the TAR. Ie. high/medium/low etc	String,length (str)<=20
Status	Status of the TAR. Ie. open/new/close etc.	String,length (str)<=20
Description	Description of the TAR and the reasons to open.	String,length (str)<=1000
Resolution /Fix	It describes the methods of fixing the TAR, what it is, how to deal with it.	String,length (str)<=1000
Phase	Phase of the TAR. Ie. planning /design /development /implementation etc	String,length (str)<=50
Link	It shows the related web page about the TAR.	String,length (str)<=100

The default value of Table SWTTar is Open_by, the same as user_name.

The value ranges: All of them are strings except the Number, which is an integer value. Also, the Description, Resolution/Fix are the strings that can contain 1000 characters.

NOTE: THERE WILL BE A TAR TABLE FOR EVERY PROJECT. The naming convention is “Project Name”Tar so for the SWT project the TAR table is named SWTTar

2.2.3 Table Name: User

Definition: This is the table showing the profile of the users.

Fields	Description /Definitions	Type
Login	Identification, shows the unique username by while the user login the webtracker system	String,(length(str)<=20
Password	The password created by the user when user accesses the system first time. Then user should type the same password every time while accessing the system. Setting the password is to increase the security of system.	String,(length(str)<=20
FirstName	Users’s first name	String,(length(str)<=20
LastName	User’s lastName	String,(length(str)<=20
Phone	User’s contact phone number	integer
FaxNumber	User’s fax number	integer
CellPhone	User’s cellular phone number	integer
Email	User’s email address which is unique	String,(length(str)<=20
Address1	User’s first address / street address	String,(length(str)<=50
Address2	User’s second address / city state and zip	String,(length(str)<=50
Company	The company name the user is working at.	String,(length(str)<=50

The default value of Table User is Login: user_name. Once the user accesses this table, all the information is directly connected to the user.

The value ranges: Described in above table.

2.2.4 Table Name: ChangelogSWT1

Definition: This is the table showing the each entry along with each comment/change made in tracker should be logged so that each user can view all changes made to each to do’s, issue, bugs, and enhancements.

Fields	Description /Definitions	Type
ID	Once a changelog entry is made, the system will give it an unique number.	integer
Tar_Number	The number of the TAR, user wants to change information of the TAR	integer
User_Name	The name the user, the same as the User table of login	String,length(str)<=20
Tar_field	The fields of the TAR, including the type, priority, status, description, resolution/fix, phase and link	string
Change_Date	The date when the user makes a change of the TAR	Mon/day/yr
Previous_Value	Old value the user changed	String
New_Value	New value the user created	String

The default value of Table ChangelogSWT1 is Open_by, which is the same as user_name.

The value ranges: Described in above the table

2.2.5 Table Name: Access_level

This table that showing the relationship /connections between the table of User and Project.

Fields	Description /Definations	Type
Level_Index	The identified number the system automatically gives when the user is added to project.	interger
User_Name	The name of the user, the same as login	String
Project_Name	The name of the project the superuser creates.	String
Access-Level	It defines the level of user (user/admin/superuser)	String

The default value of Table Access_Level is Project_name.

The value ranges: Integer is an unsigned long, the string contains 20 characters or less.

2.2.6 Table Name: Project

Definition: This is the table in which showing the project’s name and open/close date.

Fields	Description /Definitions	Type
Project_Name	The name of project when the superuser creates the project.	String
Opened	True and false, indicates the project’s status, whether it is opened or not.	boolean
Date_Opened	The date when the superuser creates the project	Mon/day/yr
Date_Closed	The date when the supersuer closes the project	Mon/day/yr

The default value of Table Project is Project_name.

The value ranges: The project_name is a string that contains 20 characters or less. The type of opened is a boolean value, indicates the project is opened or not. The date should be the standard form.

2.2.7 Table Name: Status

Definition: This is the table showing the project’s current status.

Fields	Description /Definitions	Type
ID	The unique number the system automatically gives when a field type is inserted into a project.	Integer
Project_Name	The name of the project when the superuser creates	String
Field	Show the status of the project such as open/new/close	String

The default value of Table Status is Project_Name.

The value ranges: The integer is an unsigned long, the strings contain 20 characters or less.

2.2.8 Table Name: Type

Definition: This is the table showing the project’s current type.

Fields	Description /Definitions	Type
ID	The unique number the system automatically gives when a field type is inserted into a project.	Integer
Project_Name	The name of the project when the superuser creates.	String
Field	Shows the type of the project such as todo /enhancement /bug etc.	String

The default value of Table Type is Project_Name.

The value ranges: The integer is an unsigned long integer, the strings contain 20 characters or less.

2.2.9 Table Name: Priority

Definition: This is the table showing the project’s current priority.

Fields	Description /Definitions	Type
ID	The unique number the system automatically gives when a field type is inserted into a project.	Integer
Project_Name	The name of the project when the superuser creates	String
Field	Shows the priority of the project such as high /medium /low etc	String

The default value of Table Priority is Project_Name.

The value ranges: The integer is an unsigned long integer, the strings contain 20 characters or less.

2.2.10 Table Name: Phase

Definition: This is the table showing the project’s current phase.

Fields	Description /Definitions	Type
ID	The unique number the system automatically gives when a field type is inserted into a project.	Integer
Project_Name	The name of the project when the superuser creates.	String
Field	It indicates the phase of the project such as planning/design/development/implementation etc	String

The default value of Table Phase is Project_Name.

The value ranges: The integer is an unsigned long integer, the strings contain 20 characters or less.

4. Interface Design (Use Cases)

**************EXTENDED USE CASES***********************

4.1 View TAR

Use case:	View TAR
Actors:	User, Administrator
Purpose:	Look up a Technical Assistance Request and view TAR details
Overview:	The actor searches for a TAR, and views the details of particular TAR. This page also displays the Change Log for the TAR at the bottom of the page. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.8

Actor Action		System Response
1. This use case starts when the user clicks the Search link on the Navigation bar		2. The system returns the search menu page.
1.1 This use case can also begin when the actor clicks on the TAR number link.		2.1 The system returns a page with all the TAR’s info –name, owner, date, description, status, priority, phase, resolution/fix. The Change Log is also displayed.
3. Actor supplies the search criteria; either the date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link, followed by the description specified by the search criteria.		4. The system verifies if the TAR exists with the specified criteria and returns a list of TARs with the date, type, description, priority, status and owner. All this information is first checked in the TAR-project relation table.
3.1 No TARs are found in the current project—Actor is given a error page with a link back to the Search TAR page.		4.1 The System returns an error page specifying it could not find the specified TAR. It also provides a link back to the Search TAR page
5. Actor clicks on a TAR number link		6. System returns the detail page showing more information on the TAR. All this data is returned from the database’s TAR table. This includes the fields, date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link. The TAR’s change log is also returned from the database’s change log TAR table. The information returned by the change log table is the user’s name, previous value, current value and date of change, and field changed.

4.2 Edit TAR

Use case:	Edit TAR
Actors:	User, Administrator
Purpose:	To edit the contents found in a TAR
Overview:	The actor searches for a TAR, and views the details of particular TAR. This page also displays the Change Log for that TAR at the bottom of the page. From this page, the actor presses the Edit TAR button and is returned a modifiable TAR. The Actor modifies the information and submits the new TAR. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real.
Cross References:	Screen Shot Figure: 3.1.8, 3.1.9

Actor Action		System Response
1. This use case starts when the user presses the Search Link on the Navigation bar		2. The system returns the search menu page.
1.1 This use case can also begin when the actor clicks on the TAR number link. Jump to step 7.		2.1 The system returns a page with all the TAR’s info –name, owner, date, description, status, priority, phase, resolution/fix. The Change Log is also displayed.
3. Actor supplies the search criteria; either the date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link, followed by the description specified by the search criteria fields.		4. The system verifies if the TAR exists with that criteria and returns a list of TARs with the date, type, description, priority, status and owner. All this information is first checked in the TAR-project relation table.
3.1 The TAR is not found in current project—Actor is prompted again by the Search screen to put another		4.1 The System returns an error page specifying it could not find the specified TAR.
5. Actor clicks on a TAR link		6. System returns the detail page showing more information on the TAR. All this data is returned from the database’s TAR table--date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link. The TAR’s change log is also returned from the database’s change log TAR table. In order to associate the TAR with the change log, the database also checks the TAR-Change Log relation table. The information returned by the change log table is the user’s name, previous value, current value and date of change, and field changed.
7. The Actor presses the Edit TAR button		8. The system returns a detailed page with modifiable text. The database returns the information specified in the TAR table, but displays it so the user can modify the information.
9. The Actor modifies the TAR field and presses the Submit Changes button		10. The system updates the database with the new information and replaces the previous TAR entry in the database’s TAR table. It also updates the Change log with the previous value, name, current value, field changed and the date changed.
		11. The system returns a TAR with the new changes to it..

4.3 View Change Log

Use case:	View Change Log
Actors:	User, Administrator
Purpose:	Actor logs into the system, searches for a TAR, and views the details of that TAR. The Actor then scrolls down to look at the change log. Note: Actor must be logged into system. Refer to 4.11 to learn how to log in.
Overview:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.8

Actor Action		System Response
1. This use case starts when the user presses the Search Link on the Navigation bar		2. The system returns the search menu page.
1.1 This use case can also begin when the actor clicks on the TAR number link. Jump to step 7.		2.1 The system returns a page with all the TAR’s info –name, owner, date, description, status, priority, phase, resolution/fix. The Change Log is also displayed.
3. Actor supplies the search criteria; either the date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link, followed by the description specified by the search criteria.,		4. The system verifies if the TAR exists with that criteria and returns a list of TARs with the date, type, description, priority, status and owner. All this information is first checked in the TAR-project relation table.
3.1 The TAR is not found in current project—Actor is prompted again by the Search screen to put another TAR search criteria.		4.1 The System returns an error page specifying it could not find the specified TAR.
5. Actor clicks on a TAR link		6. System returns the detail page showing more information on the TAR. All this data is returned from the database’s TAR table—date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link. The TAR’s change log is also returned from the database’s change log TAR table. In order to associate the TAR with the change log, the database also checks the TAR-Change Log relation table. The information returned by the change log table is the user’s name, previous value, current value and date of change, and field changed.
6. The Actor scrolls down the page to view the Change Log.

4.4 Submit New TAR

Use case:	Submit new TAR
Actors:	User, Administrator
Purpose:	Creates a new Technical Assistance Request and enters it into database.
Overview:	The Actor submits a new TAR. Note: the Actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.13

Actor Action		System Response
1. This use case begins when the Actor clicks Submit TAR link.		2. The system returns a page with an empty TAR with modifiable fields -- date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase and link. This template for a TAR is called from the database’s TAR table.
3. Actor supplies TAR information which includes the date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase and link fields.		4. System waits for Submission button
5. Actor presses the Submit Button.		6. System verifies all necessary fields have been entered which includes the date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link and inserts the new TAR in the database. This new entry is put within a unique project table and a change log is created for that TAR.
5.1 If not all information has been filled out, an error message is given to the Actor with the current information that has been filled out by Actor.		6.1 The system returns an error page prompting the actor to resubmit the page with all the necessary information filled out.
		7. The system returns a page with a list of TARs in the current project. This information is relayed by querying the TAR table and TAR-project table to get a list of the current TARs in a project along with the new TAR added into the necessary relation and entry tables.

4.5 Edit User (Admin only)

Use case:	Edit User
Actors:	Administrator
Purpose:	Change the contact information.
Overview:	The Actor selects the List Users(Edit/Delete) link, is given a list of users and click on the user’s name. The Actor can then update the User’s contact info. Note: the Actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.15, 3.1.16

Actor Action		System Response
1. This use case starts when the Actor clicks on the List users(Edit/Delete) link on the Navigation bar		2. The system returns a page with the list of current Users in a Project. This information is recalled from the Project – Users relation table. The information returned is the user’s first name, last name, log in, email and phone number.
3. The Actor presses the Edit button listed next to the user.		4. The system looks up the User in the User table and returns their first name, last name, address1, 2, email, phone number, user name, password, status, cell phone, fax number and the company (all specified in the User table).
5. The Actor modifies the information on the form. It can be either the first name, last name, address1, 2, email, phone number, password, status, cell phone, fax number and the company fields. The actor presses the Submit Changes button.		6. The system validates all information on form and replaces the previous User profile entry in the User table with the new information
5.1 The Actor leaves part of the form blank or has some erroneous unacceptable information on (IE phone number is not 10 digits or has letters) the form. Actor sees an error message with the form with the information entered prompting him to finish filling the form.		6.1 The system sees information on the form is not valid and returns a page prompted the user to resubmit the form with valid information. The form still has current information.

4.6 View Report

Use case:	View Report
Actors:	Administrator
Purpose:	View the number of specified events per period of time.
Overview:	The Actor views the reporting tools which will report on how many special events took place on a variable interval of time. Note: the Actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.19, 3.1.20

Actor Action		System Response
1. This use case begins when the actor clicks on the Reporting tools link.		2 The system returns a page with the date range, the time to report (per day, week, monthly basis) and the way to track based on issues reported, bugs, enhancements requested, to do’s submitted and TAR’s closed.
3. The actor selects the time period and specifies the type of bugs they want to see. They enter the time period in the time period field, select the option for the type of bugs and select the timing (per day, etc)		4. System generates report from specified information database and displays results to user. The system must search through the TARs in a project (TAR- project relation table) and then look through all the information and look for matches. This is tabulated and returned to Actor.

4.7 Add User

Use case:	Add User
Actors:	Administrator
Purpose:	Add a new user to the project
Overview:	The actor adds a new user to an active project and creates the entry in the database for the system to use. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.21, 3.1.22

Actor Action		System Response
1. This use case starts when the Actor presses the Add User Link.		2. The system returns a page prompting the Actor to input the User’s name.
3. The Actor inputs the user’s name and presses the Add User button.		4. The system checks if the user doesn’t exist in the database and returns an empty profile page with field specified by the User table. This includes the first name, last name, address1, 2, email, phone number, password, status, cell phone, fax number and the company field and presses the Add User button listed at the bottom of the page.
5. The user is added into the project		6. The user is added into project and given a relation in the project-user relation table
5.1. If the user doesn’t have an existing user profile (not found in database), the Actor is given a form. The Actor enters the first name, last name, address1, 2, email, phone number, password, status, cell phone, fax number and the company field and presses the Add User button listed at the bottom of the page.		6.1 The system validates all information on form and updates the User table, the User-Project relation table. System gave a form for user to fill out and takes info to update database.
5.1.1 The Actor leaves part of the form blank or has some erroneous unacceptable information on (IE phone number is not 10 digits or has letters) the form. Actor sees an error message with the form with the information entered prompting him to finish filling the form.		6.1.1The system sees information on the form is not valid and returns a page prompted the user to resubmit the form with valid information. The form still has current information.
		7. The system returned the page with the new current user information from the project-user relation table.

4.8 Remove User

Use case:	Remove User
Actors:	Administrator
Purpose:	To remove the User from current project
Overview:	The actor must first search for the User in the project and delete a user from that project. This is not erasing the user’s entry in the User table from the database, it is merely removing the relation to the current project. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.15, 3.1.16, 3.1.17

Actor Action		System Response
1. This use case starts when the user presses the List users(Edit/Delete) Link on the Navigation bar		2. The system returns a page with the list of current users in a project. This information is recalled from the Project – Users relation table. The information returned is the user’s first name, last name, log in, email and phone number.
3. The Actor presses the Remove button		4. The system removes the user from the Project-User Relation Table so that the user is not associated with the current project.

4.9 Customize TAR configuration

Use case:	Customize TAR configuration
Actors:	Administrator
Purpose:	Change the drop down fields available for Technical Assistance Requests within a specific project.
Overview:	The Actor selects which drop down fields to modify, and modifies them. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Primary and Real
Cross References:	Screen Shot Figure: 3.1.23

Actor Action		System Response
1. The Actor presses the Customize Project link		2. The system returns a customizable TAR page.
3. The Customize TAR page comes up with modifiable fields. The Actor selects which fields he would like to add/remove from the current TAR template. In order to add a field, the Actor types in a field name and presses the Add Field button. To delete a field, the Actor selects an existing field and clicks the Delete Field button. Once satisfied, the Actor presses the Customize Project button.		4. The system checks if all information is valid and updates the new TAR in the TAR table. All TARs from now on (in that project) will follow the newly updated TAR template.
3.1 Error page is displayed and prompts user to enter valid entries and or, have fields in the TAR. Page is returned with current values.		4.1 Error page is returned and system waits for valid information.

4.10 Delete TAR

Use case:	Delete TAR
Actors:	Actor
Purpose:	Delete Technical Assistance Requests.
Overview:	The Actor searches for and selects a TAR to delete it. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Primary and Real
Cross References:	Screen Shot Figure: 3.1.18

Actor Action		System Response
1. This use case starts when the user presses the Search Link on the Navigation bar		2. The system returns the search menu page.
1.1 This use case can also begin when the actor clicks on the TAR number link. Jump to step 7.		2.1 The system returns a page with all the TAR’s info –name, owner, date, description, status, priority, phase, resolution/fix. The Change Log is also displayed.
3. Actor supplies the search criteria; either the date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link, followed by the description specified by the search criteria fields.		4. The system verifies if the TAR exists with the given criteria and returns a list of TARs with the date, type, description, priority, status and owner. All this information is first checked in the TARs unique to a Project table.
3.1 The TAR is not found in current project—Actor is prompted again by the Search screen to put another		4.1 The System returns an error page specifying it could not find the specified TAR.
5. Actor clicks on a TAR link		6. System returns the detail page showing more information on the TAR. All this data is returned from the database’s TAR table—date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link. The change log is also displayed. The information returned by the change log table is the user’s name, previous value, current value and date of change, and field changed.
7. Actor selects the Delete TAR button		8. System removes TAR from the TAR table and the TAR unique to a project table. The Change log associated with the TAR is also deleted.

4.11 Log In

Use case:	Log in
Actors:	Super User/User/Administrator
Purpose:	To log user into the system—marks the beginning of a session
Overview:	The actor must type in their login and password to obtain access into the system. From that, the actor can go do other actions specified by the use cases
Type:	Primary and Real
Cross References:	Screen Shot Figure: 3.1.1, 3.1.2, 3.1.3, 3.1.14, 3.1.24

Actor Action		System Response
1. This use case starts when Actor asks for Log In page		2. System returns the login page and requests user name (user name field), password (password field) and project (project field)
3. Actor Supplies name, password and project and clicks on the Log In button		4. The system verifies the name and password are found in the database. The system returns Actor Welcome page.
		4.1 If the password and name is invalid, then the system returns an error message with a link back to the log in page.

4.12 Log Out

Use case:	Log Out
Actors:	Super User/Administrator/User
Purpose:	To log user out of the system – marks the end of a session.
Overview:	The Actor goes to the log out page, and presses the log out button to specify the end of a session
Type:	Primary and Real
Cross References:	Screen Shot Figure : 3.1.33

Actor Action		System Response
1. This use case starts when the user presses the log out link.		2. System logs Actor out of system and closes the current session.

4.13 Create Project

Use case:	Create Project
Actors:	Super User
Purpose:	Create a new project and assign at least one administrator
Overview:	The Actor creates a new project and has to name at least one administrator. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Primary and Real
Cross References:	Screen Shot Figure: 3.1.27, 3.1.28

Actor Action		System Response
1. This use case starts when the actor selects the Create Project link		2. System returns a page with a series of fields for Super User to fill out about the new project. This is a series of steps. First, a page with empty text fields are shown prompting user to enter the Project name, at least one Administrator and any users
3. Actor enters the project name, administrator and users, and presses the Next button.		4. The system checks all necessary data is filled (the project name and administrator) and returns a page with a customizable TAR. The TAR fields include an editable type field, priority field, status and phases with empty editable text fields under each.
		4.1 The system returns an error page specifying not all information is valid. The System also provides a link to the Create Project(i) page.
5. Create Project(ii) :A customizable TAR page appears with modifiable fields. The Actor can add/delete fields to the TAR template. To add, the Actor enters a field into a text box and presses the Add Field button. To remove, the Actor selects an existing field and clicks the Delete Field button. Once the Actor is satisfied, he presses the Create Project button.		6. The system checks if all information is valid and creates the new TAR template in the TAR table for the new project.
		6.1 If invalid entries are found, an error page is returned. It also prompts the Actor to enter valid entries and/or, have fields in the TAR. Page is returned with current values.
7. Actor is given a confirmation page with the User info, project name and TAR form.		8. The system creates a new project in the database and finalizes it.

4.14 Delete Project

Use case:	Delete Project
Actors:	Super User
Purpose:	Erase Project from the database.
Overview:	The actor deletes a project. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Primary and Real
Cross References:	Screen Shot Figure: 3.1.29, 3.1.30

Actor Action		System Response
1. Actor selects the Delete Project link		2. System returns the Delete Project page consisting of a prompt to enter the Project name.
3. Actor supplies the project name in the Project Name field and presses the Delete Project button.		4. System searches if the Project name exists in the Project table. It returns a confirmation page to ensure the Actor wants to delete the project.
		4.1 If the project is not found, the System returns an error page specifying it could not find the specified project. The system also provides a link back to the Delete Project page.
5. Actor presses Delete button.		6. The system deletes the project from its system. It removes the TAR table for the project and any relations between the User and project (User-Project table).
5.1 If the Actor does not want to delete the project, he presses the Cancel button		6.1 The system returns the Actor to Delete Project Page.

4.15 Close Project

Use case:	Close Project
Actors:	Super User
Purpose:	Change project to a closed status.
Overview:	The actor searches for and then changes a project to the closed status. Note: the actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary Real
Cross References:	Screen Shot Figure: 3.1.31, 3.1.32

Actor Action		System Response
1. Actor selects the Close Project link		2. The system returns the Close Project link with a prompt for the Project’s Name.
3. Actor supplies the project name in the Project Name field and presses the Close Project button.		4. System searches if the Project name exists in the Project table. Returns a confirmation page to ensure the Actor wants to close the project.
		4.1 If project is not found, the System returns an error page specifying it could not find the project.
5. Actor presses the Close button.		6. The system updates the project from its system. The project’s status is updated on the Project table
5.1 If the actor doesn’t want to close the project, he selects the cancel button.		6.1 The system returns the Actor to the Close Project Page.

4.16 Search TAR

Use case:	Search TAR
Actors:	User/Administrator
Purpose:	To look for a specific TAR
Overview:	The actor searches for TAR. Note: the actor must be logged into the system. Refer to section 4.11 for more details.
Type:	Secondary Real
Cross References:	Screen Shot Figure: 3.1.10,3.1.11,3.1.12

Actor Action		System Response
1. This use case starts when the user presses the Search Link on the Navigation bar		2. The system returns the search menu page.
3. The Actor supplies the date and or TAR number.		4. The system verifies if the TAR exists with the given criteria and returns a list of TARs with the date, type, description, priority, status and owner.
3.1. The Actor clicks on the Advanced Search link. He can supply these search criteria; either the date, TAR number, opened by, assigned owner, type, status, description, resolution/fix, phase, link, followed by the description specified by the search criteria.		4.1 The system verifies if TARs exist with that criteria,then returns a list of TARs with the date, type, description, priority, status and owner.
5. The TAR is not found in current project—Actor is prompted again by the Search screen to put another		6. The System returns an error page specifying it could not find the specified TAR.

4.17 Sort TAR

Use case:	Sort TAR
Actors:	Administrator/User
Purpose:	After searching for the TARs, the Actor can sort their results.
Overview:	After searching for TARs, the Actor is given a list of results. They can sort by the name, date, type, owner, status, and priority. Note: the Actor must be logged in. Refer to section 4.11 for more details.
Type:	Secondary Real
Cross References:	Screen Shot Figure: 3.1.12

Actor Action		System Response
1. After a search, a list of TARs are displayed (Refer to 4.16 for Search TAR). The subject heading for the TARs will be colored blue. This color informs the Actor that a search can be sorted by type, owner, date, status and priority. This use case begins when the user presses any of the links to sort the TARs		2. The system returns a list of TARs, queried by the previous Search (for TARs). It returns a list of TARs with its name, date, description, status, priority and TAR number.
3.The Actor presses on the name or date or status or priority link.		4. The system takes the TAR in the current list and sorts it alphabetically if by name, status or priority, and sequentially if for date. The system returns a page with the sorted TARs.

4.18 Delete User ( from Database)

Use case:	Delete User (from Database)
Actors:	Super User
Purpose:	The Super User deletes the user from the database. (Note: the difference between removing user versus delete is that delete destroys the user’s profile in the database whereas removing gets rid of a user’s association with a project. Removing does not delete a user.)
Overview:	The Super User can delete the user from the database, removing his/her records from all projects and the user profile. Only the Super User will have the power delete the User. Note: the user needs to be logged in. Refer to section 4.11 for more details)
Type:	Secondary Real
Cross References:	Screen Shot Figure: 3.1.25, 3.1.26

Actor Action		System Response
1. Actor selects the Delete User link		2. The Delete User page is shown-prompting the Actor for User’s name
3. Actor supplies the User’s name and presses the Delete User button		4. System checks if user exists in database. Should it be able to find the User, the system returns a Delete User Confirmation page with the User’s Profile
		4.1 If the User is not found --The System returns an error page specifying it could not find the specified User, it provides a link to the Delete User page.
5. Actor presses the Delete User button.		6. The system removes the User’s profile and any associations with the User.
5.1 If the actor doesn’t want to close the project, he selects the cancel button.		6.1 The system returns the Actor to the Delete User Page.

4.19 View User Details

Use case:	View User Details
Actors:	User, Administrator
Purpose:	The actor views the user details.
Overview:	The Actor selects the List User option, and views the user’s contact info. Note: the Actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.4, 3.1.5

Actor Action		System Response
1. This use case starts when the user presses the List users(Edit/Delete) Link (Admin only) and for user it’s called List Users on the Navigation bar		2. The system returns a page with the list of current users in a project. This information is recalled from the Project – Users relation table. The information returned is the user’s first name, last name, user name, email and phone number.
3. The Actor presses the user’s name (link)		4. The system looks up the User in the User table and returns their first name, last name, address1, 2, email, phone number, user name, password, status, cell phone, fax number and the company (all specified in the User table).
5. The Actor views the information in the user, he sees the first name, last name, address1, 2, email, phone number, password, status, cell phone, fax number and the company fields. The actor presses the back button to go back to the user’s list		6. The system returns the original list of users

4.20 Edit Own Profile

Use case:	Edit Own Profile
Actors:	User/Administrator
Purpose:	The actor changes his/her own contact information.
Overview:	The Actor chooses the Edit My Info link, and updates his/her contact info. Note: the Actor must be logged into system. Refer to section 4.11 for more details.
Type:	Secondary and Real
Cross References:	Screen Shot Figure: 3.1.6, 3.1.7

Actor Action		System Response
1. This use case starts when the user presses the Edit My Info link		2. The system looks up the User in the User table and returns their first name, last name, address1, 2, email, phone number, user name, password, status, cell phone, fax number and the company (all specified in the User table) in editable textfields
3. The Actor modifies the information on the form. It can be either the first name, last name, address1, 2, email, phone number, password, status, cell phone, fax number and the company fields. The actor presses the Submit Changes button.		4. The system validates all information on form and replaces the previous User profile entry in the User table with the new information
3.1 The actor presses the change password button.		4.1 The system returns a page prompting user to change the password and verifying it.
3.1.1 The actor enters old password and types the new password twice . The user presses the Change Password button		4.1.1 The system verifies the old password and checks if the new password has been typed in twice correctly. The system generates a javascript button showing the change was successful.
		4.1.2 If the old password was correct or the retyped passwords don’t match up, the system returns an error page with a link to change password.
		4.2. If the information on the form is not valid - and returns a page prompted the actor to resubmit the form with valid information.

7. Project Planning										123

7.1 Work Breakdown Structure
7.1.1 Requirements						(hours)	(hours)		Man Hours
Work Task Description	Planned Start	Actual Start	Planned Complete	Actual Complete	Assigned	Time Allocated	Actual Time	Multiplier	Allocated	Actual
Meeting with Sapient	1/17/2001	1/17/2001	1/17/2001	1/17/2001	All	1.5	1.5	5	7.5	7.5
Technical Setup (IIS + Web Server)	1/26/2001	1/26/2001	2/2/2001	2/2/2001	Michael	7	5	1	7	5
Initial group meeting	1/28/2001	1/28/2001	1/28/2001	1/28/2001	All	4	3	5	20	15
Email Contact / Response	1/28/2001	1/28/2001	1/29/2001	1/30/2001	Mandeep	1	1	1	1	1
Write Introduction	1/28/2001	1/30/2001	2/1/2001	2/5/2001	Michael	4	4	1	4	4
Write Project planning Document	1/28/2001	1/30/2001	2/1/2001	2/8/2001	Michael	10	8	1	10	8
Group meeting 2	1/30/2001	1/31/2001	1/30/2001	1/31/2001	All	3	2	5	15	10
Screen Shots	1/31/2001	2/1/2001	2/8/2001	2/8/2001	Mandeep	20	11	1	20	11
Flow Diagram	1/31/2001	1/31/2001	1/31/2001	1/31/2001	Alen	2	1	1	2	1
Define System Functions	1/31/2001	2/1/2001	2/3/2001	2/5/2001	Priscilla	5	4	1	5	4
Define System Attributes	1/31/2001	2/2/2001	2/3/2001	2/7/2001	Jessi	3	2.5	1	3	2.5
Email Contact / Response	2/1/2001	2/1/2001	2/1/2001	2/1/2001	Mandeep	1	0.5	1	1	0.5
Group meeting 3 (Discussion)	2/2/2001	2/2/2001	2/2/2001	2/2/2001	All	2	2	5	10	10
Develop use cases	2/4/2001	2/8/2001	2/7/2001	2/8/2001	Priscilla	5	2.5	1	5	2.5
Email Contact / Response	2/4/2001	2/5/2001	2/4/2001	2/5/2001	Mandeep	1	1	1	1	1
Group meeting 4	2/4/2001	2/4/2001	2/4/2001	2/4/2001	All	2	1.5	5	10	7.5
Technical Setup (User Login for TA's)	2/5/2001	2/7/2001	2/9/2001	2/7/2001	Michael	5	3	1	5	3
Develop use cases	2/5/2001	2/8/2001	2/7/2001	2/8/2001	Michael	5	4	1	5	4
Organize Email Correspondence	2/6/2001	2/9/2001	2/8/2001	2/9/2001	Mandeep	2	1	1	2	1
Gather and Edit Requirement Document	2/7/2001	2/8/2001	2/9/2001	2/9/2001	Alen	10	15	1	10	15
Gather and Edit Requirement Document	2/8/2001	2/8/2001	2/9/2001	2/9/2001	Mandeep	2	4	1	2	4
Data Dictionary	2/8/2001	2/8/2001	2/8/2001	2/8/2001	Priscilla	3	1.5	1	3	1.5
Milestone Requirement Document Due	2/9/2001	2/9/2001	2/9/2001	2/9/2001	*	*	*	*	*	*
							Total:		148.5	119
							Per day:		9.9	7.93333

7.1.2 Design						(hours)	(hours)		Man Hours
Work Task Description	Planned Start	Actual Start	Planned Complete	Actual Complete	Assigned	Time Allocated	Actual Time	Multiplier	Allocated	Actual
Project Plan 2	2/8/2001	2/9/2001	2/16/2001	3/1/2001	Michael	5	4	1	5	4
Group Meeting 5	2/11/2001	2/19/2001	2/11/2001	2/19/2001	Alen	4	3	1	4	3
Group Meeting 5	2/11/2001	2/19/2001	2/11/2001	2/19/2001	Priscilla	4	3	1	4	3
Group Meeting 5	2/11/2001	2/19/2001	2/11/2001	2/19/2001	Michael	4	3	1	4	3
Introduction (Revise)	2/11/2001	2/26/2001	2/18/2001	2/26/2001	Michael	2	1	1	2	1
Update group members through email	2/11/2001	2/19/2001	2/11/2001	2/19/2001	Priscilla	2	2	1	2	2
Data Design(ER Diagrams)	2/11/2001	2/19/2001	2/15/2001	2/26/2001	Priscilla	7	8.5	1	7	8.5
Data Design (Database Schemas)	2/11/2001	2/18/2001	2/18/2001	2/26/2001	Michael	5	3	1	5	3
Architectural Design (Screen Shots)	2/11/2001	2/16/2001	2/16/2001	2/23/2001	Mandeep	15	15	1	15	15
Architectural Design (Screen Shots)	2/11/2001	2/24/2001	2/28/2001	3/1/2001	Alen	7	7	1	7	7
Architectural Design (Screen Navigation)	2/12/2001	2/24/2001	2/18/2001	3/1/2001	Alen	5	12	1	5	12
Technical Setup (Functionality: adduser)	2/12/2001	2/14/2001	2/16/2001	2/16/2001	Michael	5	4	1	5	4
Group meeting 6 (Discussion)	2/13/2001	2/24/2001	2/13/2001	2/24/2001	All	3	2.25	5	15	11.25
Interface Design(Use Cases)	2/13/2001	2/19/2001	2/17/2001	3/1/2001	Priscilla	5	14	1	5	14
Interface Design(Use Cases)	2/13/2001	2/20/2001	2/20/2001	2/20/2001	Jessi	3	2	1	3	2
Component Level Design(2 Procedure)	2/15/2001	2/7/2001	2/18/2001	2/27/2001	Michael	5	6.75	1	5	6.75
Data Design (Database Report)	2/15/2001	2/26/2001	2/18/2001	3/1/3001	Jessi	5	7	1	5	7
Design Constraints	2/15/2001	2/28/2001	2/18/2001	3/1/2001	Alen	5		1	5	0
Data Dictionary	2/17/2001	2/27/2001	2/20/2001	3/1/2001	Michael	2	3	1	2	3
Data Dictionary	2/17/2001	2/28/2001	2/18/2001	2/28/2001	Jessi	2	0.5	1	2	0.5
Group meeting 7	2/18/2001	2/25/2001	2/18/2001	2/25/2001	All	3	3.5	5	15	17.5
Gather Edit Design Specification	2/18/2001	2/28/2001	2/21/2001	3/2/2001	Mandeep	5	4	1	5	4
Milestone Design Specification Due	3/2/2001	3/2/2001	3/2/2001	3/2/2001	*	*	*	*	*	*
							Total:		127	131.5
							Per day:		6.047619048	6.2619

7.1.3 Implementation						(hours)	(hours)		Man Hours
Work Task Description	Planned Start	Actual Start	Planned Complete	Actual Complete	Assigned	Time Allocated	Actual Time	Multiplier	Allocated	Actual
Resynchronize Web Site	2/20/2001	2/20/2001	2/27/2001	2/25/2001	Michael	7	7	1	7	7
Group meeting 10	2/20/2001		2/20/2001		All	4		5	20	0
Web pages/Interface	2/20/2001	2/16/2001	2/27/2001	2/24/2001	Mandeep	5	4	1	5	4
User database coding	2/20/2001	2/7/2001	2/25/2001	2/15/2001	Michael	5	5	1	5	5
Search coding	2/20/2001	2/28/2001	2/23/2001	3/1/2001	Mandeep	7	6	1	7	6
Group meeting 11	2/23/2001		2/23/2001		All	4		5	20	0
Sort coding	2/20/2001	2/28/2001	2/23/2001	3/1/2001	Mandeep	7	4	1	7	4
TAR list	2/21/2001	2/25/2001	2/25/2001	3/1/2001	Mandeep	5	2	1	5	2
TAR submission	2/21/2001	2/25/2001	2/25/2001	3/1/2001	Mandeep	5	2.5	1	5	2.5
TAR Detail	2/21/2001	2/25/2001	2/25/2001	3/1/2001	Mandeep	5	2	1	5	2
TAR Edit	2/21/2001	2/25/2001	2/25/2001	3/1/2001	Mandeep	5	3	1	5	3
SSI page top	2/21/2001	2/25/2001	2/25/2001	2/27/2001	Mandeep	5	0.5	1	5	0.5
User Add	2/21/2001	2/17/2001	2/25/2001	2/18/2001	Michael	5	3	1	5	3
User Edit Self	2/21/2001	2/14/2001	2/25/2001	2/15/2001	Michael	5	4	1	5	4
User Remove	2/21/2001	2/17/2001	2/25/2001	2/18/2001	Michael	5	3	1	5	3
User Modify	2/21/2001	2/19/2001	2/25/2001	2/23/2001	Michael	5	4	1	5	4
Drop field modification capability	2/22/2001		2/27/2001		Alen	10		1	10	0
Report capability	2/22/2001		2/27/2001		Priscilla	10		1	10	0
Project Add	2/22/2001		2/27/2001		Michael	3		1	3	0
Project Remove	2/22/2001		2/27/2001		Jessi	4		1	4	0
Project Close	2/22/2001		2/27/2001		Priscilla	4		1	4	0

Group meeting 12	2/25/2001		2/25/2001		All	4		5	20	0
							Total:		167	50
							Per day:		16.7	8.33333

7.1.4 Testing						(hours)	(hours)		Man Hours
Work Task Description	Planned Start	Actual Start	Planned Complete	Actual Complete	Assigned	Time Allocated	Actual Time	Multiplier	Allocated	Actual
Trace to requirements	2/26/2001		2/28/2001		Priscilla	5		1	5	0
Group meeting 13	2/27/2001		2/27/2001		All	4		5	20	0
Test case development	2/28/2001		3/2/2001		Alen	5		1	5	0
Test case development	2/28/2001		3/2/2001		Mandeep	5		1	5	0
Test case development	2/28/2001		3/2/2001		Jessi	5		1	5	0
Group meeting 14	3/2/2001		3/2/2001		All	4		5	20	0
Test the software	3/3/2001		3/10/2001		Michael	5		1	5	0
Group meeting 15	3/4/2001		3/4/2001		All	4		5	20	0

Milestone Test Case Design Due	2/28/2001		3/12/2001		*	*	*	*	*	*
							Total:		85	0
							Per day:		12.14285714	0

7.1.5 Demo						(hours)	(hours)		Man Hours
Work Task Description	Planned Start	Actual Start	Planned Complete	Actual Complete	Assigned	Time Allocated	Actual Time	Multiplier	Allocated	Actual
Group meeting 16	3/6/2001		3/6/2001		All	4		5	20	0
Prepare software	3/6/2001		3/8/2001		Mandeep	5		1	5	0
Prepare Powerpoint	3/7/2001		3/10/2001		Michael	3		1	3	0
Prepare Powerpoint	3/7/2001		3/10/2001		Priscilla	5		1	5	0
Group meeting 17	3/9/2001		3/9/2001		All	4		5	20	0
Coordinate Speaking	3/9/2001		3/11/2001		Alen	5		1	5	0
Coordinate Visuals	3/9/2001		3/11/2001		Jessi	5		1	5	0
Group meeting 18	3/11/2001		3/11/2001		All	4		5	20	0

Milestone Demo Due	3/12/2001		3/12/2001		*	*	*	*	*	*
							Total:		83	0
							Per day:		11.85714286	0

7.2 Work Input Summary

7.2.1 Break Down			Allocated		Actual
Per person	Allocated	Actual	Per Week	Per Day	Per Week	Per Day
Alen	102.5	53.75	15.76923077	2.277777778	13.4375	1.919642857
Jessi	81.5	27.75	12.53846154	1.811111111	6.9375	0.991071429
Mandeep	160.5	75.25	24.69230769	3.566666667	18.8125	2.6875
Michael	156.5	90.5	24.07692308	3.477777778	22.625	3.232142857
Priscilla	109.5	51.25	16.84615385	2.433333333	12.8125	1.830357143
Total:	610.5	298.5	93.92307692	13.56666667	74.625	10.66071429
* The per person hour totals are implemented a module of this excel sheet which I developed.

7.2.2 Overall	Allocated	Actual
Requirements Phase	148.5	119
Design Phase	127	131.5
Implementation Phase	167	50
Testing Phase	85	0
Demo	83	0
Total:	610.5	300.5

7.2.3 Reasonable
Based on the per week and per day projections, I would say that this is a pretty reasonable project plan. Of course certain members are allocated uneven amounts, but this is
due to the inaccuracy of estimation. These numbers represent a preliminary projection of project hours and are subject to change at a future date. Even though hour hourly estimate
were somewhat close to the actual results, we had a week of stall which threw our time tables off by one week. Simply put, we had a whole week where productivity was near
zero due to the fact that the design document was not explained to us and we could not move forward in our design.

7.2.4 Allocated for What has been done
For the requirements phase that is complete and the design phase that will be complete by the time this is printed, a total of 252.5 hours have been allocated to the tasks.

7.2.5 Actual hours Needed
The actual number of hours needed to complete the two phases is			250.5

7.2.6 Estimation Ratio
The estimation ratio currently is	275.5	=	1.099800399
	250.5

7.2.7 Conclusion
This information tells us that we have a slight tendency to over estimate the hours needed. But our estimates were closer to the actual results than we expected.
And as we do more, our estimates becomes more accurate as our experience improves our understanding of how long a certain process might take.
We actually under estimated for the design part, but over all our estimate is still over.

8. Appendix

8.1 Data Dictionary

	Access Level
	The rights a user has within a certain project. These rights come in three categories: user, administrator, and Super User. Based on these levels, the user will be allowed to access certain functions that they cannot access if they were not the right level.

	Administrator
	This person is responsible for upkeep of a project on a day-to-day process. He/She can either add new users to project, edit anyone’s profile, or do whatever functions the User can do.

	Array
	A bounded list of data items used to hold information with an index number to access specific elements.

	ASP – Active Server Pages
	The computer language that executes on the server side of the internet connection. Implemented mostly in Visual Basic and SQL.

	Confirmation
	A prompt to ascertain the correctness of an individual's response in order to determine whether to proceed or repeat the user query.

	Cookie
	A file that is generated on the client side storing specific information that the site specifies. Helps maintain user login identity.

	Database
	A Database is a storage and retrieval system that allows information to be grouped, indexed, related, sorted, and modified. Often found as a collection or occurrences of a number of record types, where the record types and their occurrences are interrelated by means of specific relationships.

	Default value
	Value specified for a formal parameter in the database table. It is also considered bad practice. Only one default value can be specified.

	ER Diagrams – Entity Relation Diagrams
	Diagrams containing multiple entities, their relationships, their cardinality, and modality.

	Execute
	To execute a command would result in the software flow of the command to begin and often reach a desirable result.

	Form
	A method in which users can submit information through html pages either by the post method, you don't see the parameters, or the get method, the parameters are shown in the URL.

	IIS – Internet Information Server
	Internet Server that executes server-side ASP code and sends output to the user.

	Incremental
	The process involving a linear process but in increments where we first get core functionality and then increasing functionality.

	Link
	A universal resource location which allows one to simply click and be redirected to a page specified the link

	Login
	A login is a name or alias used by the user to access the system.

	Object Oriented
	Simplifying models and structures into encapsulated objects in order to use them as objects.

	Password
	A password is a secret key which allows users identities to be verified.

	Phase
	Phase refers to the project cycle that the current tar is in.

	Prototyping
	A process where we listen to the customer, develop a prototype and have the customer evaluate the prototype, and repeating the cycle.

	RAD – Rapid Application Development
	A process where a highly modularized and well-defined project can be completed in 60-90 days by having many groups work simultaneously on different modules.

	Relational User Database
	A database keeping track of users through relationships.

	Schema
	Overall plan and diagram of implementation of the database.

	SEQueL - Standard English Query Language
	Database Query Language in plain English, designed to be comprehensive and easy to use. All actions through databases are done through SQL queries.

	Structured Analysis
	Breaking up the problem into seven distinct parts, Data Dictionary, Entity Relation Diagrams, Data Flow Diagrams, State Transition Diagrams, Process Specifications, Control Specifications, and Data Object Definitions.

	Super User
	This person is responsible for creating and deleting projects. They are solely responsible of creating but not updating projects.

	TAR (Technical Assistance Request)
	This report is used to report any bugs in an application. It consists of online submittal form, which consists of details about a bug.

	User
	This person has can submit, search, edit and view Technical Assistance reports. This is the base user of the application

	Value range
	The valid data values that a database field can assume.

	What
	A variable in the reporting function, holding the tar type to which the performance report will be generated for.

8.2 Continuing Correspondence with Sapient

8.2.1 First E-mail sent to Peter Shanley

Included with Peter’s responses.

Sent: 1/29/01

Response Received: 1/30/01

----- Original Message -----

From: Peter Shanley

To: 'Mandeep Arora'

Sent: Tuesday, January 30, 2001 12:18 AM

Subject: RE: CS 130 - Sapient WebTracker System

Mandeep,

Sorry for the delay - I am over in London for a bit. Alright, I will do my best for you.

-----Original Message-----
From: Mandeep Arora [mailto:marora@ucla.edu]
Sent: Monday, January 29, 2001 2:37 AM
To: pshanley@sapient.com
Subject: CS 130 - Sapient WebTracker System

Hi Pete,

My name is Mandeep Arora, and I'm the group leader for Group K. I'll be the one e-mailing you for the next six weeks. We have a lot of questions already so I won't waste any time...

The biggest question we have, has to do with the entire setup of the WebTracker. During the meeting we had with you guys we talked about the administrator being able to modify field values for their own "projects." The thing we are having a problem with is the idea of a PROJECT.

The document handed out about the system mention nothing about the idea of a project. We are confused as to how projects influence the behavior of the system. We envisioned a lot of different scenarios:

· When logging in to the WebTracker the user logs in to a specific project and all tools the user accesses work with that project and its associated TARs

· When submitting a TAR there is a project field and the user has to specify which project the TAR is associated with. [Peter Shanley] - no, a user needs to be in a 'project' to work in WebTracker

· When searching for TAR's does it search a specific project, only projects a user is associated with, ALL projects in the system, or current projects[Peter Shanley] - same as above

Also:

· Can you supply some preliminary types for each fields Priority, Phases, Type, Status. And what does each field mean, with a one line description.
[Peter Shanley] Priorities: Show Stopper, Critical, Moderate, Nice to have; Type: TAR, bug, enhancement, issue; Status: Open, Closed, Duplicate, New, etc

We're really unclear on how projects affect the system. The concept seems to be central to the WebTracker but its not mentioned in the document at all. We're very confused about this. Here's what we understand about each section if we are interpreting things incorrectly please let us know:

Login & Identification
We have a simple prompt asking for a user name and password (Possibly specifying a project[Peter Shanley] - definitely get the user to choose a project first ). The user is then taken to a page where they can wither go to a page where they can link to:

· Submit a TAR

· Search TAR's

· Reporting tools

· Administration for Administrators only

TAR Submission
Is the "Opened By" field of a TAR forced to be the user logged in.[Peter Shanley] - defaulted to, not forced

Search Query
User gets a pulldown menu of the different fields associated with a TAR (type, status, resolution/fix etc..) and a text box in which they can type a keyword(s). User can also specify a date range.[Peter Shanley] - not sure what you mean about a date range.

When results are returned the user the user can click at the top of the column and sort by different items (Status, Date, TAR #, Owner, Opened By).[Peter Shanley] good

Reporting Tool
Can report the number of BUGS reported over a time period. Returns a figure in units of bugs per week. Same for Fixes.

· Are reporting tools project specific or over a certain date range.[Peter Shanley] yes - it should be able to be sliced by day, week and month

Is reporting restricted to Administrators?[Peter Shanley] yes

Change Log
When viewing details on a TAR a link will be available to see the Change Log. It will list Changes to the TAR with a

· Date

· The Field that was changed

· The user that made the change[Peter Shanley] good

Administration
The administrator can:

· Add users, edit their contact information, delete users [Peter Shanley] change them to administrators

· Change the TAR structure for a specific project.

· Delete TARs.
[Peter Shanley] I suppose there needs to be a super user who can set up projects

I know there's a lot here. The most important thing is how the project setup works. Please let us know ASAP, because as soon as we know we'll have a slew of more questions.[Peter Shanley] Keep the questions coming - I will give you the best turnaround I can (1-2 days) I look forward to going forward with you guys - maybe we should schedule dinner or something in the next few weeks. -pete

Thanks,

Mandeep Arora
mdeeps@bigfoot.com

8.2.2 Second E-mail sent to Peter Shanley.

Peter’s responses follow immediately.
Sent: 1/30/01
Response Received: 1/31/01

-----Original Message-----
From: Mandeep Arora [mailto:marora@ucla.edu]
Sent: Tuesday, January 30, 2001 10:20 PM
To: Peter Shanley
Subject: Re: CS 130 - Sapient WebTracker System

Pete,

Thanks for the last set of answers it helps out a lot.

One more question about the projects.

Should all the TARs for all projects be in one database, seperated by projects of course, but still all in one central database? Or should each project spawn its own database?

-Mandeep

----- Original Message -----

From: Peter Shanley

To: 'Mandeep Arora'

Sent: Wednesday, January 31, 2001 12:04 AM

Subject: RE: CS 130 - Sapient WebTracker System

you tell me what you think is best - then we'll make a decision together.

8.2.3 Third E-mail sent to Peter Shanley

Included with Peter’s responses.
Sent: 2/01/01
Response Received: 2/02/01

----- Original Message -----

From: Peter Shanley

To: 'Mandeep Arora'

Sent: Friday, February 02, 2001 3:10 AM

Subject: RE: Flowchart & More Questions

Great work Mandeep! Let me know if the team wants to meet for dinner or coffee or whatever.

-----Original Message-----
From: Mandeep Arora [mailto:marora@ucla.edu]
Sent: Thursday, February 01, 2001 7:35 PM
To: Peter Shanley
Subject: Flowchart & More Questions

Included is a screen navagation diagram. Please let us know what you think of this initial layout.[Peter Shanley] Couple of points on the diagram

1. the super user should have all the rights of users and admins plus their own special rights

2. update it for the edit self information (passwords, phone, email) for users.

We also have another list of questions:

1. In the last e-mail you mentioned a superuser. Should they have the power to also DELETE projects?[Peter Shanley] - yes

2. From the Diagram you can see that the abilities of the SuperUser are limited to opening and closing projects. We envisioned that there would be one and only one SuperUser and that this account would not be used for normal access but just for Project creation( and possibly deletion). Is this ok?[Peter Shanley] sounds good to me

3. Upon logging in should user see a list of most recent TAR's?[Peter Shanley] not necessary (don't increase scope for yourselves too much :-))

4. Should the TAR information be confirmed before it is submitted? We had an arguement about this. Some of us though that after submitting a TAR a confirmation screen with all the information should appear. Others thought this would be an inconvinience since it would require an extra step every time a user submits a TAR especially since after the TAR is submitted the user could edit the TAR in just 2 clicks. Let us know...[Peter Shanley] I don't feel that a confirmation screen is necessary, but error checking for important fields would be nice - such as owner, opened by, description, status.

5. For what Optimal Screen Size should the webtracker be designed?[Peter Shanley] It should be flexible enough to work on most screens, but we should probably work with a lower limit of 800X600 - optimally 1024X768.

6. Will Projects be reffered to by name? Or will they be automatically assigned numbers?[Peter Shanley] we should be able call projects a name.

7. Is the Administrator as involved in a project as a normal user? We made the diagram assuming that they are as involved.[Peter Shanley] yes - administrators should be able to act as normal users.

8. Can a user changes his own contact information / password? Or can only an administrator change this data?[Peter Shanley] user can change just themselves.

Our requirements document is due next friday so we'll be hammering out the details.[Peter Shanley] I will be out of touch until Monday - I will be traveling about Europe this weekend and back in LA on Monday night. Good Luck.

Thanks,

Mandeep Arora

8.2.4 Fourth E-mail sent to Peter Shanley

Included with Peter’s responses.
Sent: 2/06/01
Response Received: 2/06/01

----- Original Message -----

From: Peter Shanley

To: 'Mandeep Arora'

Sent: Tuesday, February 06, 2001 11:34 AM

Subject: RE: More Questions

I pushed some of these back into your court, to tell me what you think is best.

Early next week would be good for me to walk through the requirements doc - how is Tuesday?

-----Original Message-----
From: Mandeep Arora [mailto:marora@ucla.edu]
Sent: Tuesday, February 06, 2001 2:45 AM
To: Peter Shanley
Subject: More Questions

Hey Pete,

Hope your trip back was a good one. We've had some questions ready and waiting for your return. Here they are:

1. The SuperUser should be able to Open, Close and Delete a project. What is entailed in Closing a Project? What should be the effect of closing a project?[Peter Shanley] Give me your thoughts on this.

2. The document handed to us from Sapient on the day you came to our lecture says the following when giving an overview of the project:

"... As for the company, other project groups encountering similar bugs will be able to view archived

bugs and hopefully apply the same fix or resolution to their own problem."

Everything we have discussed so far is operating on the assumption that a user logs into a specific Project and that all searches they conduct are restricted to the TAR's in the project they logged into. This seems to contradict the handout we received. We just want to confirm that we are continuing in the right direction.[Peter Shanley] Good point - Think through what is a good way to handle this - if it is right/wrong, too much work, etc.

3. We're confused about the SuperUser. The last e-mail had a contradiction in it:

> .[Peter Shanley] 1. the super user should have all the rights of

> users and admins plus their own special rights

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From the Diagram you can see that the abilities of the

> SuperUser are limited to opening and closing projects.

> We envisioned that there would be one and only one

> SuperUser and that this account would not be used

> for normal access but just for Project creation( and

> possibly deletion). Is this ok?[Peter Shanley] sounds good to me

These two statements seem to contradict themselves. I'll try to clarify how we think of the superuser and why we set up the superuser the way we did.

We imagined there would be ONE superuser account. I.E. UserName: Superman; Password: ClarkKent. People can not be given SuperUser status; instead the SuperUser name/password would be only revealed to those people who need the ability to Create, Delete and Close Projects. When the SuperUser logs in they would not log into a project. They would be taken to a screen where they could choose to either Create, Delete or Close a project. While creating a project the SuperUser would specify at least one Administrator for the project and will be given the options to customize the drop down menus as neccesary. After the Project is created any Administrator for the project will have the power to modify the project pull down menus add and maintain users to the project etc.

This would keep the SuperUser account from being used freely and on a normal basis preventing HUGE mistakes and/or more security. The ability to change the SuperUser password would also be provided.

There are many other approaches that we can see but this is what we had imagined. Please let us know what you want out of the SuperUser account. (If you want me to list other possible options let me know.)[Peter Shanley] I like your approach - see if you can think through the archiving/retrieval with the super user...

4. We're still very unclear on the Reporting tools. Could you possibly give us a description of a scenario where you logged into a Project and wanted to use these tools. Let us know what options you'd expect to have, what kind of report you'd be running and what kind of results you want back ( please be specific on the format of these results ).
[Peter Shanley] Just a couple examples of many, I would like to get a report on discovery rates (how many bugs are being found over time). Also, we should have standard reports for tars, lists of tar status, priority, etc.

5. Can users/administrators be involved in multiple projects? If so, if a user is an Administrator are they an administrator for all projects they are involved in?[Peter Shanley] not sure, this links to the archive/retrieve bit.

6. From the last e-mail we have:

>> Upon logging in should user see a list of

>> most recent TAR's?[Peter Shanley] not

>> necessary (don't increase scope for yourselves

>> too much :-))

As a group we talked about this and we don't think it will be a technical challenge, we also envisioned this as being important to how the user navigates through the project. I'm working on screen shots and as soon as they're ready I'll send you a link. We'll make the screen shots working with the list. If after seeing them you think the list is inappropriate we'll get rid of it.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(whew... that was a little long)

Ok hopefully after this set we'll have the requirements document ready. Also the rest of the group is really bogged down this week, but I'm pretty free after wednesday. We were thinking it wouldn't be a bad idea if you and I met up wednesday night or Thursday sometime. I could bring the requirements document we develop and I could run through it with you in person. Let me know if you're available. Otherwise I can just e-mail you all the documents if you have time to look them over. I think the whole group will be busy this week but after that it would be nice to all meet.

Thanks again,

Mandeep Arora

mdeeps@bigfoot.com

8.2.5 Fifth E-mail sent to Peter Shanley

Included with Peter’s responses.
Sent: 2/12/01
Response Received: 2/15/01

----- Original Message -----

From: Peter Shanley

To: 'Mandeep Arora'

Sent: Thursday, February 15, 2001 9:19 AM

Subject: RE: Meeting and Requirements

Mandeep - I apologize for my delayed response. I am knee deep in client work - I will be able to reply to this message tomorrow. Please move forward and we will make course corrections if necessary. Thanks – pete

-----Original Message-----
From: Mandeep Arora [mailto:marora@ucla.edu]
Sent: Monday, February 12, 2001 10:36 PM
To: Peter Shanley
Subject: Meeting and Requirements

Hey Pete,

Included is a self extracting version of our Requirements Document. Its pretty large but a lot of it is screen shots.

I'm sorry we didn't get back to you earlier we were busy putting that Document together in time for our friday deadline. We'd still like to meet up before we move on to the Design step of the project. Tuesday night is ok for the rest of the team members. I won't be able to make it, but seeing as the other 4 group members can thats just fine. Finding a time where all 5 of us are available and you are also available is going to be quite difficult.

If you're still free for tomorrow evening please e-mail ASAP so I can alert the rest of the group. If you would rather meet on another night let me know. Any day of the week should be ok, midterm time has cooled off and i'm sure a good portion of the group would be able to make it any night of the week.

Thank you,

Mandeep Arora
mdeeps@bigfoot.com

8.2.5 Sixth E-mail sent to Peter Shanley

Included with Peter’s responses.
Sent: 2/01/01
Response Received: 2/02/01

----- Original Message -----

From: Peter Shanley

To: 'Mandeep Arora'

Sent: Tuesday, February 27, 2001 8:39 AM

Subject: RE: Haven't heard from you

Mandeep I am still really busy - I looked at your design doc briefly and it looks good - like I said last time please proceed. Don't let me slow you down right now.

Sorry for the delays,

-pete

-----Original Message-----
From: Mandeep Arora [mailto:marora@ucla.edu]
Sent: Tuesday, February 27, 2001 12:10 AM
To: Peter Shanley
Subject: Haven't heard from you

Hey Pete,

We haven't heard from you at all in quite some time. Its getting to be urgent since we're turning in our Design Documents this friday and are already moving onto implementing the project.

I'm going to unclude a screen navigation diagram and a zip file.

Unzip the file to a folder then Browse one of three files:

UserFrameSet.html
AdminFrameSet.html
SUFrameSet.html

each of those will give you a view of the system from the perspective of each of the three user types. Let us know whats happening on your end.

thanks,

Mandeep Arora
mdeeps@bigfoot.com

Kamakazi Knights Present

DESIGN DOCUMENT

For this quarter, the project is to build a Web Tracker for Sapient Corporation. Our team is called the Kamikaze Knights (Team K). We choose this name because not many words start with the letter K. So what better than suicidal noble warriors?

Fields

Description/Definitions

Type

Fields

Description /Definitions

Type

Fields

Description /Definitions

Type

Fields

Description /Definations

Type

Fields

Description /Definitions

Type

Fields

Description /Definitions

Type

Fields

Description /Definitions

Type

Fields

Description /Definitions

Type

Fields

Description /Definitions

Type

View TAR

Actor Action

System Response

1. This use case starts when the user clicks the Search link on the Navigation bar

2. The system returns the search menu page.

1.1 This use case can also begin when the actor clicks on the TAR number link.

2.1 The system returns a page with all the TAR’s info –name, owner, date, description, status, priority, phase, resolution/fix. The Change Log is also displayed.

Edit TAR

Actor Action

System Response

1. This use case starts when the user presses the Search Link on the Navigation bar

2. The system returns the search menu page.

2.1 The system returns a page with all the TAR’s info –name, owner, date, description, status, priority, phase, resolution/fix. The Change Log is also displayed.

View Change Log

Actor Action

System Response

1. This use case starts when the user presses the Search Link on the Navigation bar

2. The system returns the search menu page.

2.1 The system returns a page with all the TAR’s info –name, owner, date, description, status, priority, phase, resolution/fix. The Change Log is also displayed.

Actor Action

System Response

Edit User

Actor Action

System Response

1. This use case starts when the Actor clicks on the List users(Edit/Delete) link on the Navigation bar

2. The system returns a page with the list of current Users in a Project. This information is recalled from the Project – Users relation table. The information returned is the user’s first name, last name, log in, email and phone number.

View Report

Actor Action

System Response

Add User

Actor Action

System Response

1. This use case starts when the Actor presses the Add User Link.

2. The system returns a page prompting the Actor to input the User’s name.

3. The Actor inputs the user’s name and presses the Add User button.

5. The user is added into the project

6. The user is added into project and given a relation in the project-user relation table

Remove User

Actor Action

System Response

1. This use case starts when the user presses the List users(Edit/Delete) Link on the Navigation bar

2. The system returns a page with the list of current users in a project. This information is recalled from the Project – Users relation table. The information returned is the user’s first name, last name, log in, email and phone number.

Actor Action

System Response

Actor Action

System Response

1. This use case starts when the user presses the Search Link on the Navigation bar

2. The system returns the search menu page.

2.1 The system returns a page with all the TAR’s info –name, owner, date, description, status, priority, phase, resolution/fix. The Change Log is also displayed.

Actor Action