Task Manager
Use Case Model
Supplementary Specification and Glossary
Version 1.4
SOEN 342, Fall 2004.
Assignment 2.
Team: 11
Members:
GERRY TED DOMINIQUE
JOHN NEHME
DAYVANANT MANNORIND
ARASH TORKAMAN-ZEHI
NAIEM ABOU SHAKRA
Concordia UniversitySupplementary Specifications and Use CaseSOEN 342
CS & SE DepartmentFall 2004SR&S Assignment 2
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
SOEN 342, Fall 2004.
Assignment 2.
Team: 11
1.Introduction
1.1.Purpose
1.2.Overview
2.Functionality
2.1.Security
2.2.Number of tasks
2.3.Fonts and Colors
2.4.Viewing Tasks
2.5.Adding Tasks
2.6.Marking Tasks
2.7.Alerts
2.8.Average training time
2.9.Average access time
2.10.Compatibility
3.Reliability
3.1.Availability
3.2.Mean Time Between Failures
4.Performance
4.1.Response Time for a Reminder
4.2.Network Access Time
4.3.User Capacity
4.4.Disk usage
5.Supportability
5.1.OOD coding standard
5.2.Class naming conventions
5.3.Platforms support
6.Design Constraints
6.1.Programming Language
7.Online User Documentation and Help System Requirements
8.Interfaces
8.1.User Interfaces
8.2.Hardware Interfaces
9.Use Case Model
9.1.Overall Description
Domain Model
Use-Case Model
9.2.Use-Cases
10.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.
9.Use Case Model
9.1.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
TheTask Manageris 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
9.2.Use-Cases
9.2.1 General Use Cases
9.2.1.1 Professor/Tutor logs in to the system
Level / Professor/Tutor levelPrimary 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
- Unsuccessful end of use case.
- The system exits the program.
- Unsuccessful end of use case.
9.2.1.2 Professor/Tutor Deals with popup Tasks
Level / Professor/Tutor levelPrimary 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.
Main Success Scenario /
- 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.
- 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
- The use case resumes at [Choice]
- Unsuccessful end of use case.
9.2.1.3 Professor/Tutor Adds a Task
Level / Professor/Tutor levelPrimary 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.
Main Success Scenario /
- 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].
- The system indicates that another reminder is using the same date/time.
- The system asks the professor/tutor to provide another date/time.
- The professor/tutor provides another date/time.
- The use case resumes at [Message].
- Unsuccessful end of use case.
9.2.1.4 Professor/Tutor Quick Adds a Task
Level / Professor/Tutor levelPrimary 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.
Main Success Scenario /
- 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.
- 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.
- [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].
- The system indicates that another reminder is using the same date/time.
- The system asks the professor/tutor to provide another date/time.
- The professor/tutor provides another date/time.
- The use case resumes at [Message].
- Unsuccessful end of use case.
9.2.1.5 Professor/Tutor Modifies a Task