To Do List Problem Statement
Version 1.0
Revision History
|
Date |
Issue |
Description |
Author |
|
17/May/2015 |
1.0 |
Initial creation. Extracted the Problem Statement from the Vision document for purposes of scoping. |
Li Yinglan |
|
24/May/2015 |
V1.0 |
Generation for release |
Li Yinglan |
|
|
|
|
|
|
|
|
|
|
To Do List Problem Statement
Version 1.0
Problem Statement
You are tasked with developing a task manager. The task manager will allow people to add a new task, modify or delete an existing task.
Each task must have a title, a due date and a description.
The user interface should be simple, and the app should be easy to operate.
The task manager should be available to three platforms including Windows App Store 8.1, Windows Phone App 8.1 and WPF.
To Do List Glossary
Version 1.0
Revision History
|
Date |
Issue |
Description |
Author |
|
17/May/2015 |
V1.0 |
Initial Creation |
Li Yinglan |
|
24/May/2015 |
V1.0 |
Generation for release |
Li Yinglan |
|
|
|
|
|
|
|
|
|
|
Table of Contents
1. Introduction
2. Definitions
2.1 Task
2.2 Title
2.3 Due Date
2.4 Description
2.5 Is Done
2.6 Task List
Course Registration System Glossary
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 To Do List.
2.1 Task
A thing needed to be done in some day.
2.2 Title
The key word of a task.
2.3 Due Date
The date when the task should be done before.
2.4 Description
The details of a task.
2.5 Is Done
The state that shows whether the task is finished.
2.6 Task List
A list of tasks saved by the user.
To Do List Supplementary Specification
Version 1.0
Revision History
|
Date |
Issue |
Description |
Author |
|
17/May/2015 |
V1.0 |
Initial creation |
Li Yinglan |
|
24/May/2015 |
V1.0 |
Generation for release |
Li Yinglan |
|
|
|
|
|
|
|
|
|
|
Table of Contents
1. Objectives
2. Scope
3. References
4. Functionality
5. Usability
6. Reliability
7. Performance
8. Supportability
9. Security
10. Design Constraints
To Do List
Supplementary Specification
1. Objectives
The purpose of this document is to define requirements of the To Do List. 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 system.
2. Scope
This Supplementary Specification applies to the To Do List.
This specification defines the non-functional requirements of the todolist; 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
- If the chosen due date is not a future date, the user must be notified, and choose the due date again until it’s valid.
- Before the user deletes a task, he/she should be asked if he/she is sure to delete it in case he/she clicks the button unintentionally.
- If the task is done, and it isn’t deleted, then the task should be marked to show that it is done.
5. Usability
The user-interface shall be Windows 8.1 or Windows Phone 8.1 compliant.
6. Reliability
Saved tasks should be available every time the user opens the app.
7. Performance
- The app can be used at any time the user wants.
8. Supportability
None.
9. Security
None
10. Design Constraints
The app shall provide a Windows-based desktop interface, a Windows-based phone interface, and a WPF interface.
Requirements
1. Add A Task
1.1 Brief Description
This use case allows a user to add a new task. A task must include a title, a due date and a description.
1.2 Flow of Events
1.2.1 Basic Flow
This use case starts when the user click the ADD button in the “add a task” page.
- The system checks to see if the due date is a future date. If it is, then the task will be successfully added to the task list. If not, the system will notify the user, and the task with invalid due date won’t be added to the task list.
1.2.2 Alternative Flows
1.3 Special Requirements
None.
1.4 Pre-Conditions
None.
1.5 Post-Conditions
If the task is added successfully, it will return to the main page with an updated task list. If not, it will stay in the current page.
1.6 Extension Points
None.
2. Modify & Delete A Task
2.1 Brief Description
This use case describes how a user modifies the title, due date, is done state, or the description of the task.
2.2 Flow of Events
2.2.1 Basic Flow
This use case starts when the user clicks one of the tasks shown in the task list.
- The user modifies the information of the task.
- The system checks if the due date is a future date.
- The system checks if the “is done” checkbox is checked.
2.2.2 Alternative Flows
2.2.2.1 Invalid Due Date
If in the Basic Flow, the user enters an invalid date, the system displays an error message. The user can choose to either enter a valid due date or cancel the modifying action, at which point the use case ends.
2.2.2.2 “Is Done”Is Checked
If in the Basic Flow, the user check the “Is Done” checkbox, when the system returns to the task list, the task that is checked, will be marked with the word “Done” to show its state.
2.2.2.3 Delete A Task
If in the Basic Flow, the user clicks the Delete button, the system will ask if the user is sure to delete the task, if the user clicks delete, the task is deleted, else the system will return to the current page.
2.3 Special Requirements
None.
2.4 Pre-Conditions
None.
2.5 Post-Conditions
If the use case was successful, the user will return to the task list with the updated tasks.
2.6 Extension Points
None.
