Time Manager Glossary
Version 2.0
Revision History
Date |
Issue |
Description |
Author |
10/April/2015 |
V1.0 |
Initial Creation |
Jieru Zhang |
22/May/2015 |
V2.0 |
Generation for release |
Jieru Zhang |
Table of Contents
1. Introduction 1
2. Definitions 2
2.1 Time Manager 2
2.2 Insert 2
2.3 Delete 2
2.4 Grade 3
2.5 Unlock 3
2.6 Puzzle Game 3
1.Introduction
This document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information.
2.Definitions
The glossary contains the working definitions for the key concepts in the Time Manager.
2.1 Time Manager
It means that when customers use my program, he can see it as a personal time manager to manage his daily time resonably, by which he can put some task or things with the ending time into the list. Then my program will help him to hold these data.
2.2 Insert
Customer can insert a new task with the DeadLine by click the ‘Insert‘ button.
2.3 Delete
Customer can delete the old task in the list by click the ‘Delete‘ button.
2.4 Grade
Customer can make the grade increasing by finishing the task advanced by clicking the ‘Finish advanced‘. How many days advanced, then how many grade he will get. The grade is used when it comes to the little puzzle game.
2.5 Unlock
When the customer get the enough grades, he will have a chance to open a new puzzle game somehow. It means to unlock the puzzle.
2.6 Puzzle Game
The game is a pretty easy one, just with the different background pictures when in different levels of the game that the users unlocked.Each time customer play a new term, the total grade will decrease.
Time Manager Problem Statement
Version 2.0
Revision History
Date |
Issue |
Description |
Author |
10/April/2015 |
v1.0 |
Initial creation. Extracted the Problem Statement from the Vision document for purposes of scoping. |
Jieru Zhang |
22/May/2015 |
V2.0 |
Generation for release |
Jieru Zhang |
Time Manager Problem Statement
Version 2.0
Problem Statement
The Time Manager application is designed for the common people range from young people to old one, from students to workers.Ii is a light application , while at the same time , there remains some unsolved problems about the algorithm and the functions.
Customer can sort the task list by the remaining days by clicking the header of the whole list. But when the windows closed and open again, the list becomes unsorted again, so customer should click the header once more time to sort it. It is inconvenient.
And the puzzle game is hard to pass somehow because it is created by the random numbers. So it maybe make the users confused and lead to a decreasing in popularity.
When customer input two tasks with the same name but the different ending time, both of them will be showed in the list, but when people want to delete one of it, another one will also be deleted.(Maybe the reason is that When I programming, I make the Name of the task the key word, which means that not allowed two tasks have the same name ).
The Window of each page is a little small , so that customer may feel uncomfortable abput it, when they drag the edge of the windows, their layout will become a little strange(the background becomes dark or some other situations ).I will fix these problems in the future gradually.
Time Manager Supplementary Specification
Version 2.0
Revision History
Date |
Issue |
Description |
Author |
10/April/2015 |
V1.0 |
Initial Creation |
Jieru Zhang |
22/May/2015 |
V2.0 |
Generation for release |
Jieru Zhang |
Table of Contents
1. Objectives 4
2. Scope 4
3. References 4
4. Functionality 4
5. Usability 4
6. Reliability 4
7. Performance 4
8. Supportability 4
9. Security 4
10. Design Constraints 5
1. Objectives
The purpose of this document is to define requirements of the Time Manager. This Supplementary Specification lists the requirements that are not readily captured in the use cases of the use-case model. The Supplementary Specifications and the use-case model together capture a complete set of requirements on the Application.
2. Scope
This Supplementary Specification applies to the Time Manager, which will be developed by the students.
This specification defines the non-functional requirements of the system; such as reliability, usability, performance, and supportability as well as functional requirements that are common across a number of use cases. (The functional requirements are defined in the Use Case Specifications.).
3. References
none
4. Functionality
It is for the common people to manage thier personal time reasonably. It can calculate the remaining time of each task and show the exactly number of days last in the main list of the main window.
5. Usability
The desktop user-interface shall be Windows 7/8/8.1 compliant.
6.Reliability
There is no request about the down time. Customer can shut down the computer and the data in the application will stored in the memory of the computer.
7.Performance
The application is a light one , so it doesn‘t have as much requirements as others. The calculation too easy to finish, so the costing time is very short.
8.Supportability
none
9.Security
1.Only the user of the application can log in it and can delete or insert some tasks.
2.Only the user can unlock the puzzle game by using the grade he earned.
10. Design Constraint
The one on the WindowsPhone8.1 is not finished as the WPF one, so some functions are not availible in the phone.
Requirement
1. Insert
1.1 Brief Description
This use case describes how a user insert a new task into the list.
1.2 Flow of Events
1.2.1 Basic Flow
This use case starts when the actor wishes to insert a new task.
- The system requests that the actor click the ‘Insert‘ button.
- The actor click the ‘Insert‘ button.
- The system requests that the actor enter the task name, ending time and importance.
- The actor enter the task name, ending time and importance.
- The system requests that the actor click the ‘OK‘ button.
- The actor clicks the ‘OK‘ button.
- The system add the new task into the list window.
1.2.2 Alternative Flows
1.2.2.1 Invalid Task name and ending time
If in the Basic Flow, the actor enters an invalid task name or ending time, the system displays an error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the inserting.
1.3 Special Requirements
None.
1.4 Pre-Conditions
None.
1.5 Post-Conditions
If the use case was successful, the task is now added into the list. If not, the list view is unchanged.
1.6 Extension Points
None.
2. Delete
2.1 Brief Description
This use case describes how a user delete a new task into the list.
2.2 Flow of Events
2.2.1 Basic Flow
This use case starts when the actor wishes to delete an old task.
- The system requests that the actor click the ‘Delete‘ button.
- The actor click the ‘Insert‘ button.
- The system ask the actor weather delete or not.
- The actor enter choose the ‘Yes‘ or ‘No‘.
- The system delete the old task item and remove it from the list view or not.
2.2.2 Alternative Flows
none
2.3 Special Requirements
None.
2.4 Pre-Conditions
The customer should choose the one that he wants to delete.
2.5 Post-Conditions
If the use case ‘Yes‘ was successful, the chosen task is now removed from the list.
If the use case ‘NO‘ was successful, the chosen task is still in the list.
2.6 Extension Points
None.
3. Finish Advanced and Add Score
3.1 Brief Description
This use case describes how a user finish a task advanced and add some more scores into the old one.
3.2 Flow of Events
3.2.1 Basic Flow
This use case starts when the actor wishes to delete an old task.
- The system requests that the actor click the ‘Finish advanced‘ button.
- The actor click the ‘finish advanced‘ button.
- The system remove the chosen one.
- The system add some score into the old one.
3.2.2 Alternative Flows
none
3.3 Special Requirements
None.
3.4 Pre-Conditions
1.The customer should choose the one that he already finished.
2.The ending time of the chosen task should bigger than the current time.
3.5 Post-Conditions
If the use case was successful, the score will become larger.
3.6 Extension Points
None.
4. Unlock
4.1 Brief Description
This use case describes how a user can unlock a new puzzle game level.
4.2 Flow of Events
4.2.1 Basic Flow
This use case starts when the actor wishes to unlock a new level.
- The system requests that the actor click the ‘unlock‘ button.
- The actor click the ‘unlock‘ button.
- The system ask the actor weather play or not.
- The actor enter choose the ‘Yes‘ or ‘No‘.
- The system show the game window or not.
4.2.2 Alternative Flows
none
4.3 Special Requirements
None.
4.4 Pre-Conditions
The whole score should be enough for the unlocking.
4.5 Post-Conditions
If the use case ‘Yes‘ was successful, the game window will show.
If the use case ‘NO‘ was successful, the game window will not show.
4.6 Extension Points
None.