Supplementary Specification - Vidéotronpages.videotron.com/gerryted/Documents/SRS-document.doc ·...

Supplementary Specification

Task Manager

Use Case Model

Supplementary Specification and Glossary

Version 1.4SOEN 342, Fall 2004.

Assignment 2.

Team: 11

Members:

GERRY TED DOMINIQUE

JOHN NEHME

DAYVANANT MANNORIND

ARASH TORKAMAN-ZEHI

NAIEM ABOU SHAKRA

Revision History

Date

Rev.

Description

Author(s)

2004/10/27

1.1

Chapters 1-2

D. MANNORIND

2004/11/04

1.2

Chapters 3-8

A. TORKAMAN-ZEHI

2004/11/16

1.3

Small correction

G. DOMINIQUE

2004/11/17

1.4

Group revision

4 MEMBERS

Table of Contents

1SOEN 342, Fall 2004.

1Assignment 2.

1Team: 11

51.Introduction

51.1.Purpose

61.2.Overview

62.Functionality

62.1.Security

62.2.Number of tasks

62.3.Fonts and Colors

62.4.Viewing Tasks

72.5.Adding Tasks

72.6.Marking Tasks

72.7.Alerts

72.8.Average training time

82.9.Average access time

82.10.Compatibility

83.Reliability

83.1.Availability

83.2.Mean Time Between Failures

94.Performance

94.1.Response Time for a Reminder

94.2.Network Access Time

94.3.User Capacity

94.4.Disk usage

95.Supportability

95.1.OOD coding standard

95.2.Class naming conventions

95.3.Platforms support

96.Design Constraints

96.1.Programming Language

107.Online User Documentation and Help System Requirements

108.Interfaces

108.1.User Interfaces

128.2.Hardware Interfaces

139.Use Case Model

139.1.Overall Description

13Domain Model

14Use-Case Model

169.2.Use-Cases

2610.Glossary Definition

Supplementary Specification

1. Introduction

The following document is a supplementary requirements specification document for the proposed Task Manager Software. The Task Manager is a handy organizer that allows users to manage and organize their meetings, daily work activities and research tasks. It allows the user to organize all related work activities by a convenient manner. The rest of the document will outline some of the futures that were not presented in the use cases and use case diagrams.

1.1. Purpose

The purpose of this SRS document is to contain all the necessary specifications that were not included in the use cases and vision documents. After reading the SRS document, you will have a better understanding of the Task Manager Software details.

Definitions, Acronyms and Abbreviations

· The Software, Application, System, all relate to the Task Manager.

· The Professor is a member of the faculty at Concordia University and is someone primarily teaching, lecturing, observing, or consulting a post-secondary accredited educational course.

· The tutor in this document is someone employed by Concordia University to provide teaching assistance or instruction to a group of students.

· Availability – is the percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, etc..

· Mean Time Between Failures (MTBF) – this is usually specified in hours but it could also be specified in terms of days, months or years.

· Mean Time To Repair (MTTR) – how long is the system allowed to be out of operation after it has failed?

· Accuracy – the precision (resolution) and accuracy (by some known standard) that is required in the systems output.

· Maximum bugs or defect rate – is expressed in terms of bugs/KLOC (thousands of lines of code), or bugs/function-point.

· Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the requirement(s) define what is meant by a “critical” bug (e.g., complete loss of data or complete inability to use certain parts of the functionality of the system)

· Throughput: transactions per second)

· Capacity: the number of customers or transactions the system can accommodate

· Degradation modes: the acceptable mode of operation when the system has been degraded in some manner

· Resource utilization: are the memory, disk, communications etc.

1.2. Overview

The SRS document contains the following parts: functionality, usability, performance and supportability requirements. It also contains user interface schemas and design constraints. The licensing requirements and user agreement terms are listed at the final part of the document.

2. Functionality

2.1. Security

The Task Manager should have 64 bit-encrypted passwords for the Professor and Tutors for extra security. The passwords should contain 8 ASCII case sensitive characters. The password fill in form should have bold dots to hide the password from being able to read. The username can only contain the following characters: (A-Z, a-z, 0-9, “-“).

2.2. Number of tasks

The Application software should be capable of entering as many as a hundred tasks per calendar day.

2.3. Fonts and Colors

The software should be capable of using the following fonts: Arial, Times New Roman, Verdana, and Courier New. Each font can be chosen as a specific theme in the Software and will be used throughout the entire graphical interface. Also various color themes can be used.

2.4. Viewing Tasks

The software should be capable of viewing tasks by task Timeline and Date. (Diagram 8.4). This info should be displayed on the right side of the To Do list Window. Also, the software should be able to briefly view all tasks on one page by just viewing the first lines of each task (Diagram 8.4). When adding a task with the standard procedure, if a specific date and time is chosen and a task is within that timeline, the Software will bring up the task description and the user could modify the task or delete it (Diagram 8.3).

2.5. Adding Tasks

There are two ways of adding tasks in the Software. Either by creating a task with the quick add task method, where after the quick add option is chosen, the user could type in the necessary task, assign it to him/her self or assign to someone else. Also she/he could postpone the task if not important.

The other method is to assign the task with the standard procedure. In this method the user can either choose a standard task or a recurrent task. A standard task has a time and date that can be chosen via a drop down menu. A brief calendar is displayed when the date menu is used to facilitate the user on choosing the date required. A recurrent task can be hourly, daily or weekly. After choosing the type of task, the user can type in the desired task in the task description window. As much as 1000 characters are allowed for the task description window.

2.6. Marking Tasks

The software should be capable of marking a task as complete or incomplete with a checkbox at the left side of each task.(Diagram 8.2). Once a task is marked as complete, the task should be outlined with a line and the user could have the option of removing the task from the Task Manager.

2.7. Alerts

The software can alert the user with a sound chosen by the user. The user can modify the alert mechanism and choose either a specific sound or no sound at all. This is a good option if the user has a specific task that is more important than the others.

2.8. Average training time

Because there are no help files within the Task Manager software, there will be a short tutorial on how to use the software. The average tutorial time should be no more than 40 minutes. The tutorial will be given at a conference room with one trainer demonstrating the different functionalities of the Software. The users will be given a computer each and can follow through the training session. For more support, there will be an online webpage available with a reference to all the different functionalities of the Task Manager.

2.9. Average access time

The average access time should be around 60 seconds. This is based on the times spent for the user to input his/her username and password properly. The Software should allow the user 5 consecutive tries. If there was no success, the Software should terminate.

2.10. Compatibility

The software should be compatible with 32-bit Intel or AMD based chipsets and should also be compatible with Microsoft’s Windows XP Series, NT, 2003, 2000, 98, 95, Linux and ME. The software is not compatible with other operating systems such as MAC OS’s.

3. Reliability

3.1. Availability

The application should be available 95% percent of the time for user access. The hours of use should relate to Concordia Universities Business Hours. The Software can be used for maintenance purposes on Sundays when the University is closed.

3.2. Mean Time Between Failures

The average Software maintenance time should be no more than 1 day. The Software maintenance procedures would be as follows: After a call to the maintenance team, if the problem is due to a software failure, an engineer would test the software and find the error and report to the maintenance and design section. The maintenance and design section would find a solution and resolve the issue in the quickest time possible. Once the solutions are resolved, the maintenance team will reintegrate the software to the network. During this phase the users should accommodate themselves with the earlier releases of the software.

4. Performance

4.1. Response Time for a Reminder

The response time for a reminder is the time required for the reminder to be displayed once it has been summoned. Maximum time delay is 1 seconds. Average response is 0.1 second. Minimum is 0 second.

4.2. Network Access Time

The network access time is the time required for the user to logon to the System. Maximum time delay is 20 second. Average response is 5 seconds. Minimum response is 1 second.

4.3. User Capacity

The maximum number of users allowed using the software should 25 users. The professor’s user login should be labeled administrator and the tutors would have their own unique user names and passwords.

4.4. Disk usage

The Task Manager’s database capacity can be increased through the maintenance team and the amount of storage can be as much as 1000 Giga Bytes. Various Network Drives can be configured for this usage.

5. Supportability

5.1. OOD coding standard

Object-Oriented design is to be implemented as a coding standard in order to simplify program maintenance, complexity and readability.

5.2. Class naming conventions

Class names should be meaningful and follow as much as possible the use cases.

5.3. Platforms support

The program should be running properly on a Linux and on a Windows system.

6. Design Constraints

6.1. Programming Language

The programming languages to be used are JAVA and C++. These languages enable the program to be supported by most operating system platforms used by users throughout the world.

7. Online User Documentation and Help System Requirements

There will be an online web page containing a complete reference to the different tasks that the Software is capable of doing.

8. Interfaces

8.1. User Interfaces

The user interface would be based on the .NET GUI architecture libraries. The following diagrams describe the Task Managers User Interface Design.

Diagram 8.1 Login window.

Diagram 8.2 The main window appearing once a user has logged on with quick add option.

Diagram 8.3 The Task window pop up.

Diagram 8.4 Adding a Task with the standard method.

8.2. Hardware Interfaces

The existing computer facilities in the University should be completely compatible with the Software.

Use Case Model

8.3. Overall Description

Domain Model

The following figure is a domain model that represents the Task Manager. The domain model is a visual representation of the conceptual classes.

Figure 1: Domain Model Task Manager

Use-Case Model

The following figures provide use case diagrams to illustrate the names of use cases and actors of the Task Manager.

Figure 2: Use Cases for the Professor/Tutor actor

Figure 3: Use Cases for the Professor actor

The Task Manager is a solution to supply the professors and their tutors with a simple and effective way to manage their tasks and todo-lists. It provides the professors with a simple interface to assign tasks to a particular tutor or more. Tutors can also use this system to add their own tasks or to add collective tasks that will be addressed to the professor and the rest of the tutors. The Task Manager offers the professor as well as the tutors with a convenient way to be reminded about their common and individual tasks, for instance, meetings and tutorials.

The following table lists all the actors in the system and their use cases:

Actor

Goal (Use Case)

Tutor

Login

Dealing with popup Tasks

Add Task

Modify Task

Delete Task

Professor

Login

Dealing with popup Tasks

Add Task

Modify Task

Delete Task

Add Tutor

Modify Tutor

Delete Tutor

Table 1: Actor-Goal List

Use-Cases

9.2.1 General Use Cases

9.2.1.1 Professor/Tutor logs in to the system

Level

Professor/Tutor level

Primary actor

Professor/Tutor

Success guarantee

Professor/Tutor logs in to the system

Minimal guarantee

Nothing happens

Pre-condition

The todo-list should exist in the system.

Main Success Scenario

· [logon]The system displays the logon window.

· The system asks the professor/tutor to provide a username and a password.

· The professor/tutor provides a username and a password.

· [Check] The system ensures that the logon information is correct.

· The system accepts the professor/tutor and shows the “manage todo-list” window including a quick add textbox, a “manage task” button, a “quit” button and a “manage tutor” (admin only).

· End of use case

Extensions

[Check] The system denies access to the professor/tutor

· The system displays to the professor/tutor that the logon information is incorrect.

· The use case resumes at [logon].

· End of use case

a*. Professor/tutor indicates that s/he wishes to quit

· Unsuccessful end of use case.

b*. Professor/tutor selects the “quit button”

· The system exits the program.


9.2.1.2 Professor/Tutor Deals with popup Tasks

Level


Primary actor

Professor/Tutor

Success guarantee

Professor/Tutor deals with popup tasks

Minimal guarantee

Nothing happens

Pre-condition

The todo-list should exist in the system. Professor/Tutor is logged into the Task Manager.


· The system displays the task window to the professor/tutor with a description of the task, and an option to “mark as complete”, “postpone”, or “assign to someone else”.

· [Choice] The professor/tutor chooses the “mark as complete” option.

· The system sets the task as done in the todo-list.

· End of use case

Extensions

[Choice]

1- The professor/tutor chooses the “postpone” option.

· The system asks the professor/tutor to provide another date/time.

· The professor/tutor provides another date/time.

· [Check] The system ensures that there is no conflict with another task.

· The system displays that the task is added successfully.

· End of use case.

2- The professor/tutor chooses the “assign to someone else” option.

· The system displays the list of users.

· The professor/tutor chooses a user or more from the list.

· The system displays that the task has been assigned successfully.

· End of use case

[Check] The system displays that there is a conflict, and asks the user to provide another date/time.

· The use case resumes at [Choice]



9.2.1.3 Professor/Tutor Adds a Task

Level


Primary actor

Professor/Tutor

Success guarantee

Professor/Tutor adds a task to the todo-list

Minimal guarantee

Nothing happens

Pre-condition

Professor/Tutor is logged into the task Manager. The “manage todo-list” is displayed to the professor/tutor. The professor/tutor chooses the “manage task” button from the “manage todo-list” window while no task is highlighted.


· The system displays an empty “manage task” window to the user.

· [Choice] the professor/tutor chooses the standard task.

· The professor/tutor enters the date, the time, and the small description.

· The system ensures that there is no date/time conflict with another reminder.

· [Message] The system displays a message indicating that the reminder has been added successfully.

· The system returns to “manage todo-list” state.

· End of use case

Extensions

[Choice] the professor/tutor chooses the recurrent task.

· The professor/tutor chooses any of the hourly/daily/weekly options.

· The professor/tutor selects the interval.

· The use case resumes at [Message].

[Message] The system displays an error indicating that there has been a date/time conflict.

· The system indicates that another reminder is using the same date/time.






9.2.1.4 Professor/Tutor Quick Adds a Task

Level


Primary actor

Professor/Tutor

Success guarantee

Professor/Tutor adds a task to the todo-list from within the todo-list itself.

Minimal guarantee

Nothing happens

Pre-condition

Professor/Tutor is logged into the task Manager. The “manage todo-list” is displayed to the professor/tutor.


· The system displays the todo-list window to the user.

· The professor/tutor selects the quick add task textbox below the list of task.

· The professor/tutor enters the date, the time, and the small description.


· [Message] The system displays a message indicating that the reminder has been added successfully.

· [Assign] The professor/tutor does not click on the “assign task” “quick link”.

· [Good] The system redisplays to “manage todo-list” state.

· End of use case

Extensions

[Assign] the professor/tutor chooses to assign the created task.

· The system displays a check box list of available tutors.

· The professor/tutor chooses any one or more tutors to assign the task to.

· The system displays a message indicating that the task has been forwarded successfully.

· The use case resumes at [Good].








9.2.1.5 Professor/Tutor Modifies a Task

Level


Primary actor

Professor/Tutor

Success guarantee

Professor/Tutor modifies a task in the todo-list

Minimal guarantee

Nothing happens

Pre-condition

Professor/Tutor is logged into the task Manager. The “manage todo-list” is displayed to the professor/tutor. The professor/tutor chooses the “manage task” button from the “manage todo-list” window while a task is highlighted.


· The system displays a “manage task” window with the info of the current task to the user.

· The professor/tutor modifies the information.


· [Message] The system displays a message indicating that the reminder has been changed successfully.


· End of use case

Extensions








9.2.1.6 Professor/Tutor Deletes a Task

Level


Primary actor

Professor/Tutor

Success guarantee

Professor/Tutor deletes a task from the todo-list

Minimal guarantee

Nothing happens

Pre-condition

Professor/Tutor is logged into the task Manager. The “manage todo-list” is displayed to the professor/tutor. The professor/tutor chooses the “Manage Task” button from the “manage todo-list” window while a task is highlighted.


· The system displays a “manage task” window with the info of the current task to the user.

· The professor/tutor selects the “Delete Task” button.

· The system asks the professor/tutor if s/he really wants to delete the reminder.

· The professor/tutor affirms the request.

· [Message] The system displays a message indicating that the reminder has been deleted successfully deleted.


· End of use case

Extensions

[Message] The system displays a message indicating that the reminder is marked incomplete/postponed.

· The system asks the professor/tutor if s/he really wants to delete the reminder.

· The professor/tutor affirms the request.



Unsuccessful end of use case.

9.2.1.7 Professor/Tutor Sets a Task as Done or Undone

Level


Primary actor

Professor/Tutor

Success guarantee

Professor/Tutor sets a task as done in the todo-list

Minimal guarantee

Professor/Tutor sets a task as not done in the todo-list

Pre-condition

Professor/Tutor is logged into the task Manager. The “manage todo-list” is displayed to the professor/tutor.


· The system shows the “manage todo-list” window.

· [State] The professor/tutor selects one or more tasks from the list using the check boxes.

· The system automatically set the selected task’s font in gray and put a bar across the task description.

· End of use case

Extensions

[State] The professor/tutor sets a done job as undone.

· The professor/tutor unselects one or more tasks from the list using the check boxes.

· The system automatically set the selected task’s font in gray and put a bar across the task description.

· End of use case


Unsuccessful end of use case.

9.2.2 Admin Use Cases

9.3.2.1 Administrator Adds a Tutor

Level

Administrator level

Primary actor

Administrator

Success guarantee

Administrator adds a tutor

Minimal guarantee

Nothing happens

Pre-condition

Administrator is logged into the task Manager and in the todo-list window. The Administrator selects the “manage tutor” and then “add tutor” from the system.


· The system asks the administrator to provide a username/password/description for the new tutor.

· The administrator enters the username/password/description for the new tutor.

· The system ensures that there is no tutor with the same username.

· [Message] The system displays a message indicating that the tutor has been added successfully.

· The system returns to “manage tutor” state.

· End of use case

Extensions

[Message] The system displays an error indicating that there is an existing tutor with the same username.




9.3.2.2 Administrator Modifies a Tutor

Level

Administrator level

Primary actor

Administrator

Success guarantee

Administrator modifies a tutor

Minimal guarantee

Nothing happens

Pre-condition

Administrator is logged into the task Manager and in the todo-list window. The Administrator selects the “manage tutor” and then “modify tutor” from the system.


· The system displays a list of tutors.

· The administrator selects the tutor from the list.

· The system displays the username/password/description of the tutor

· [Edit] The administrator changes the tutor’s username/password/description.

· The system ensures that there is no tutor with the same username.

· [Message] The system displays a message indicating that the tutor has been modified successfully.


· End of use case

Extensions

[Message] The system displays an error indicating that there is an existing tutor with the same username.

· The use case resumes at [Edit].

a*. Administrator indicates that s/he wishes to quit


9.3.2.3 Administrator Deletes a Tutor

Level

Administrator level

Primary actor

Administrator

Success guarantee

Administrator deletes a tutor

Minimal guarantee

Nothing happens

Pre-condition

Administrator is logged into the task Manager and in the todo-list window. The Administrator selects the “manage tutor” and then “delete tutor” from the system.


· The system displays a list of tutors.

· The administrator selects the tutor from the list.

· The system displays a message indicating that the tutor has been deleted successfully.


· End of use case

Extensions

a*. Administrator indicates that s/he wishes to quit


9. Glossary Definition

SoftwareSets of instructions or data that tells a computer what to do. Software is often divided into two categories: system software, which includes the operating system (e.g., Windows 95, MacOS) and all utilities that enable the computer to function; and applications software, which includes programs that perform specific tasks (e.g., word processors, spreadsheets, and databases).

Use CasesA use-case model consists of actors, use cases, and relations among them. Actors represent everything that must exchange information with the system, including what are typically called users. When an actor uses the system, the system performs a use case. A good use case is a sequence of transactions that yields a measurable result of value for an actor. The collection of use cases is the system's complete functionality..

SpecificationsThe documents that prescribe the requirements with which the product or service has to conform. Note: A specification would refer to or include drawings, patterns or other relevant documents and should also indicate the means and the criteria whereby conformity can be checked.

RequirementsExpectations that a program must meet. Often identified by a designer using a technique such as use cases and embodied in a program's promises or guarantees.

JAVAProgramming Language Developed by Sun Microsystems

C++An industry standard object-oriented compiled language, formally standardized in 1998, but tracing its history to the early 1980s, with an heritage in C and Simula. C++ is a general-purpose programming language with a bias towards systems programming. C++ runs on most computers from the most powerful supercomputers to the ubiquitous personal computers. Symbian OS is written in C++. API, Symbian OS, Java, OPL

UIUser Interface.

GUIGraphical User Interface.

OSOperating System.

Date post:	15-Apr-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times