标签：
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
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.
The glossary contains the working definitions for the key concepts in the To Do List.
A thing needed to be done in some day.
The key word of a task.
The date when the task should be done before.
The details of a task.
The state that shows whether the task is finished.
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
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.
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.).
None.
- 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.
The user-interface shall be Windows 8.1 or Windows Phone 8.1 compliant.
Saved tasks should be available every time the user opens the app.
None.
None
The app shall provide a Windows-based desktop interface, a Windows-based phone interface, and a WPF interface.
Requirements
This use case allows a user to add a new task. A task must include a title, a due date and a description.
This use case starts when the user click the ADD button in the “add a task” page.
None.
None.
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.
None.
This use case describes how a user modifies the title, due date, is done state, or the description of the task.
This use case starts when the user clicks one of the tasks shown in the task list.
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.
None.
None.
If the use case was successful, the user will return to the task list with the updated tasks.
None.
10.0 Problem Statement & Glossary & Supplementary Specifications & Requirements
标签：
原文地址：http://www.cnblogs.com/lyli/p/4525750.html
