标签：

Revision History

The Curriculum Software Problem Statement

Version 1.0

Problem Statement

As the head of information systems for Tianjin College you are tasked with developing a new student curriculum software. The existed curriculum software is almost inconvenient and complicated. So I want to create a succinct curriculum software to solve this problem.

Students need a curriculum that just has the main page and edit page. For the main page, it will display the course information in the grids including course name, teacher name, place, which is enough for students to use. For the edit page, students could edit the course name, teacher name, place and the time for the course. If the course in that rime has existed. It will recognize it as the wrong course and replace the old course. If the course does not exist, it will create the course into the curriculum. At last, students can delete all the courses in the curriculum with the delete button.

The new curriculum software can achieve the functions which is said above. It has the simple main page to display the courses. It has the edit page which is said above. So it is a nice project for students to try using it.

I will try my best to test and maintain the software. 

The Curriculum Software Glossary

Version 1.0

Revision History

The Curriculum Software 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 Curriculum Software.

2.1 Courses

Classes offered by the university.

2.2 Course Name

The class name that can easily describe the main content about the class.

2.3 Teacher Name

The name of the teacher who teaches the class.

2.4 Place

The place where the teacher teaches the class.

2.5 Time

The collection of time row and time col.

2.6 Time Row

A specific time interval in the day which can be described like 8:00 - 9:55.

2.7 Time Col

A week time just like Sunday.

2.8 Student

A person enrolled in classes at the university.

The Curriculum Software Supplementary Specification

Version 1.0

Revision History

The Curriculum Software

 Supplementary Specification 

1. Objectives

The purpose of this document is to define requirements of the The Curriculum Software.  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 Software.

2. Scope

This Supplementary Specification applies to the Curriculum Software, which will be developed by the Tianjin University students.

This specification defines the non-functional requirements of the Software; such as reliability, usability, performance, and support 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

- Multiple users can use the software to display their courses sepecifically.

- If a course exist and user edit in a course to the same time interval, the old course will be replaced.

5. Usability 

Win7, Win8, Win8.1,  Windows Phone.

6. Reliability 

The software can correctly display and update the information about the courses.

7. Performance

1. The software has the main page to display the courses and the edit page to update or create course.
2. If a course exist and user edit in a course to the same time interval, the old course will be replaced.

8. Security

Every one who use the software can achieve the all function.

1. Register for Courses

1.1 Brief Description

Students need a curriculum that just has the main page and edit page. For the main page, it will display the  course information in the grids including course name, teacher name, place, which is enough for students to  use. For the edit page, students could edit the course name, teacher name, place and the time for the course. 

1.2 Flow of Events

1.2.1 Basic Flow 

This use case starts when a Student wishes to create courses if he/she want to look for it easily or to change his/her course

1.2.1.1 Create Course

1. The software has an edit page to let user create course.
2. The student type some information about course name, teacher name, class place and choose the time in the software about the course.
3. Once the student has made his/her choice, the software will display the course information in the main page immediately.
4. The software has an edit page to let user update course.
5. The student type the information about course name, teacher name, class place and choose the time the old course has.
6. Once the student has made his/her choice, the software will replace the old course with your typing.
7. The edit page has a button named delete all.
8. The student click this button and the courses are all dropped.
9. Once the courses are all dropped, the curriculum will not display the courses.

1.2.1.2 Update Course

1.2.1.3 Delete Course

1.2.2 Alternative Flows

1.2.2.1 Save Curriculum

I will let the .xml file to store the course information. The student do some edit about course. The change is also stored in the .xml file. And the main page will display the courses with .xml file every time we start the page.

1.2.2.2 No Course in Curriculum

If student choose the delete all button or don’t create one course, the curriculum will display nothing except the time we make.

1.3 Special Requirements

None.

1.4 Extension Points

None. 

The introduction about my project.

标签：

原文地址：http://www.cnblogs.com/Elson8080/p/4530149.html