All Documents

Vision and Scope Document 10/12/2007

Ho Chi Minh National University – International University Instructor: Phan Viet Hoang

Date October 10th , 2007

Version 1.0

Status Baseline

Author Team TiHonMumMim(Group 6)

Reviewer Team TiHonMumMim(Group 6)

Documenter Nguyen Duc Quan

Team member Signature

Nguyen Duc Quan

Le Vu Hoang

Tran Minh Phung

Phan Duy Tan

Huynh Da Thuc

Final Document

2

Table of Contents Introduction ..................................................................................................................................................... 13

Development team & OURS project ................................................................................................................ 13

Problem Statement .......................................................................................................................................... 15

Project background ...................................................................................................................................... 15

Key users ...................................................................................................................................................... 15

Stakeholders ................................................................................................................................................ 16

Assumptions & Constraints of Online University Registration System ......................................................... 17

Vision of Solution ............................................................................................................................................. 17

Vision statement .......................................................................................................................................... 17

Scope ........................................................................................................................................................... 18

List of features ............................................................................................................................................. 18

List of features will not be developed .......................................................................................................... 18

Business Plan & SRS Document ....................................................................................................................... 20

STATEMENT OF WORK ..................................................................................................................................... 21

RESOURCE LIST ................................................................................................................................................ 24

Human ......................................................................................................................................................... 24

Software ...................................................................................................................................................... 24

Hardware ..................................................................................................................................................... 24

ESTIMATION .................................................................................................................................................... 25

Huynh Da Thuc estimation ........................................................................................................................... 25

Phan Duy Tan estimation ............................................................................................................................. 28

Tran Minh Phung estimation ....................................................................................................................... 31

Nguyen Duc Quan estimation ...................................................................................................................... 34

Le Vu Hoang estimation ............................................................................................................................... 37

Estimation Summary .................................................................................................................................... 39

SCHEDULE ........................................................................................................................................................ 43

Task list ........................................................................................................................................................ 43

Final Document

3

Gantt chart (reference) ................................................................................................................................ 45

RISK PLAN ........................................................................................................................................................ 46

DISCUSSION SUMMARY ................................................................................................................................... 48

Project background ...................................................................................................................................... 48

Purpose of project ................................................................................................................................... 48

Scope of project ....................................................................................................................................... 49

Perspectives ................................................................................................................................................. 51

Who will use the system? ........................................................................................................................ 51

Who can provide needs about the system? ............................................................................................. 51

Project objectives ........................................................................................................................................ 52

Know business rules ................................................................................................................................. 52

System information and/or diagrams ...................................................................................................... 52

Assumptions and dependencies .............................................................................................................. 54

Design and implementation constraint .................................................................................................... 54

Risks ............................................................................................................................................................. 54

Known future enhancements ...................................................................................................................... 55

References ................................................................................................................................................... 55

Open, unresolved issues ............................................................................................................................. 55

SOFTWARE REQUIREMENT SPECIFICATION ..................................................................................................... 56

USE CASE SPECIFICATION ............................................................................................................................. 56

Log in and Log out .................................................................................................................................... 56

Manage Department Information ............................................................................................................ 58

Manage Lecturer Information .................................................................................................................. 60

Manage Student Information................................................................................................................... 63

Manage Course Offering .......................................................................................................................... 66

Manage Financial Activities ...................................................................................................................... 69

View Academic History ............................................................................................................................ 71

Register Course ........................................................................................................................................ 72

Manage Course Catalogue ....................................................................................................................... 74

Manage User Account .............................................................................................................................. 77

Final Document

4

Appendix .................................................................................................................................................. 80

FUNCTIONAL REQUIREMENT ....................................................................................................................... 82

NON-FUNCTIONAL REQUIREMENT .............................................................................................................. 86

Performance: ........................................................................................................................................... 86

Reliability: ................................................................................................................................................ 86

Availability: .............................................................................................................................................. 86

Efficiency: ................................................................................................................................................. 86

Supportability: ......................................................................................................................................... 86

Integrity: .................................................................................................................................................. 86

Portability: ............................................................................................................................................... 86

Flexibility: ................................................................................................................................................. 87

INSPECTION REPORT ........................................................................................................................................ 88

GLOSSARY ........................................................................................................................................................ 89

Introduction ................................................................................................................................................. 89

Definitions.................................................................................................................................................... 89

OURS ........................................................................................................................................................ 89

Academic staff ......................................................................................................................................... 89

Finance staff ............................................................................................................................................. 89

Department ............................................................................................................................................. 89

Faculty...................................................................................................................................................... 89

Curriculum ............................................................................................................................................... 89

Subject ..................................................................................................................................................... 89

Course Offering ........................................................................................................................................ 90

Prerequisite.............................................................................................................................................. 90

Course Catalog ......................................................................................................................................... 90

Lecturer .................................................................................................................................................... 90

Student .................................................................................................................................................... 90

Student priority ........................................................................................................................................ 90

Discount rate............................................................................................................................................ 90

Grade ....................................................................................................................................................... 90

Final Document

5

Schedule .................................................................................................................................................. 90

Tuition fee ................................................................................................................................................ 90

Credit ....................................................................................................................................................... 90

Academic duration ................................................................................................................................... 90

Academic year.......................................................................................................................................... 91

Testing Plan & Test case Document ................................................................................................................. 93

A- Test Plan .................................................................................................................................................. 94

Introduction ..................................................................................................................................................... 94

Purpose ........................................................................................................................................................ 94

Scope ........................................................................................................................................................... 94

References ................................................................................................................................................... 94

Review requirement and Design ...................................................................................................................... 94

Review system architecture ......................................................................................................................... 95

Features to be tested ....................................................................................................................................... 97

Features not to be tested ................................................................................................................................ 98

Approach ......................................................................................................................................................... 99

Kind of test ................................................................................................................................................... 99

Data and Database Integrity Testing ........................................................................................................ 99

System testing .......................................................................................................................................... 99

Performance Testing .............................................................................................................................. 100

Load Testing ........................................................................................................................................... 100

Stress Testing ......................................................................................................................................... 100

Volume Testing ...................................................................................................................................... 100

Test Strategy .............................................................................................................................................. 100

Checklist of unit test .............................................................................................................................. 100

Unit testing ............................................................................................................................................ 101

Smoke test ............................................................................................................................................. 101

Test Automation .................................................................................................................................... 101

Data and Database Integrity Testing ...................................................................................................... 102

System Testing ....................................................................................................................................... 102

Final Document

6

Performance Testing .............................................................................................................................. 103

Load Testing ........................................................................................................................................... 104

Stress Testing ......................................................................................................................................... 105

Volume Testing ...................................................................................................................................... 106

Suspension criteria and resumption requirements ........................................................................................ 107

Suspension criteria ..................................................................................................................................... 107

Resumption requirements ......................................................................................................................... 107

Environmental Needs .................................................................................................................................... 108

Tools .......................................................................................................................................................... 108

Software .................................................................................................................................................... 108

Hardware ................................................................................................................................................... 109

Schedule ........................................................................................................................................................ 109

Acceptance criteria ........................................................................................................................................ 110

Resources ...................................................................................................................................................... 110

B- Test Case ................................................................................................................................................ 113

Unit testing .................................................................................................................................................... 113

Test Cases of Log in and Log out Use Case ..................................................................................................... 115

User logs in successfully with valid username and password .................................................................... 115

Fail to login the system when providing invalid username ........................................................................ 115

Fail to login the system when providing username or password containing special character(s).............. 115

Fail to login the system when providing valid username and invalid password ......................................... 116

Fail to login the system when providing empty username ........................................................................ 116

Fail to login the system when providing valid username and empty password ......................................... 117

User account is locked after failing to log in 3 times .................................................................................. 117

User logs in the system using an account is being used by another user................................................... 118

User logs in the system using an account is being locked .......................................................................... 118

Change password successfully ................................................................................................................... 118

Fail to change password when old or new or confirmed password is empty ............................................ 119

Fail to change password when old password is incorrect .......................................................................... 119

Recover the password successfully ............................................................................................................ 120

Final Document

7

Fail to reset password when inputting wrong answer for the security question ....................................... 120

Fail to reset password when inputting answer containing special character(s) for the security question . 121

Fail to reset password when inputting empty answer for the security question ....................................... 122

Test Cases of Manage Department Information Use case ............................................................................. 122

Add a department with valid information successfully .............................................................................. 122

Fail to add a department with name that already exists in the system ..................................................... 123

Fail to add a department when one or some or all fields are empty ......................................................... 123

Fail to add a department when inputting special character(s) to one or some or all fields ....................... 124

Update a department with valid information successfully ........................................................................ 125

Fail to update a department with name that already exists in the system ................................................ 125

Fail to update a department when one or some or all fields are empty .................................................... 126

Fail to update a department when inputting special character(s) to one or some or all fields .................. 127

Update cancel ............................................................................................................................................ 127

Delete a department .................................................................................................................................. 128

Delete cancel ............................................................................................................................................. 128

Test Cases of Manage Lecturer Information use case.................................................................................... 129

Add a lecturer with valid information successfully .................................................................................... 129


Fail to add a lecturer when inputting special character(s) to one or some or all fields.............................. 130

Look for a lecturer...................................................................................................................................... 131

Update a lecturer with valid information successfully ............................................................................... 131

Fail to update a lecturer when one or some or all fields are empty .......................................................... 133

Fail to update a lecturer information when inputting special character(s) to one or some or all fields .... 133

Update cancel ............................................................................................................................................ 134

Delete a lecturer ........................................................................................................................................ 135

Delete cancel ............................................................................................................................................. 135

Test Cases of Manage Student Information Use Case ................................................................................... 136

Add a student with valid information successfully ..................................................................................... 136

Fail to add a student when one or some or all fields are empty ................................................................ 136

Fail to add a student when inputting special character(s) to one or some or all fields .............................. 137

Final Document

8

Search student by student ID or/and by student name ............................................................................. 138

Fail to search student by student ID or/and by student name when providing invalid student ID or/and

student name ............................................................................................................................................. 138

Fail to search student by student ID or/and by student name when providing empty student ID or/and

student name ............................................................................................................................................. 139

Search student by faculty and academic duration ..................................................................................... 139

Search student by academic year, semester, and course .......................................................................... 141

Update a student with valid information successfully ............................................................................... 141

Fail to update a student when one or some or all fields are empty ........................................................... 142

Fail to update a student when inputting special character(s) to one or some or all fields ........................ 142

Update is canceled ..................................................................................................................................... 143

Delete a student ........................................................................................................................................ 144

Delete is canceled ...................................................................................................................................... 144

Test Cases of Manage Course Offering Use Case ........................................................................................... 145

Create list of courses offering successfully ................................................................................................ 145

Update the list of course offering .............................................................................................................. 145

Cancel during the Create list of course offering operation ........................................................................ 146

Cancel during the Update list of course offering operation ....................................................................... 147

Fail to create an empty list of course offering ........................................................................................... 147

Update list of course offering while there’s no list of course offering for specific faculty ......................... 148

Test Cases of Manage Financial Activities Use Case ...................................................................................... 150

View tuition fee by student ID or/and by student name............................................................................ 150

Fail to view tuition fee by student ID or/and by student name when providing invalid student ID or/and

student name ............................................................................................................................................. 150

Fail to view tuition fee by student ID or/and by student name when providing empty student ID or/and

student name ............................................................................................................................................. 151

View tuition fee by faculty or/and by academic duration .......................................................................... 151

View tuition fee by academic year, semester, and course ......................................................................... 152

Update tuition fee status of a student ....................................................................................................... 152

Test Cases of View Academic History Use Case ............................................................................................. 153

View academic history successfully ........................................................................................................... 153

Final Document

9

View all course have taken history............................................................................................................. 153

View by specific year and semester. .......................................................................................................... 154

View by passed and failed status. .............................................................................................................. 154

Test Cases of Register Course Use Case ......................................................................................................... 155

Fail to register more than 30 credits .......................................................................................................... 155

Fail to register less than 15 credits ............................................................................................................ 155

Register for courses successfully ................................................................................................................ 156

Update the existing schedule successfully ................................................................................................. 157

Test Cases of Manage Course Catalogue Use Case ........................................................................................ 157

Add new course to course catalogue successfully ..................................................................................... 157

Fail to add a course when one or some or all fields are empty .................................................................. 158

Fail to add a course when inputting special character(s) ........................................................................... 159

Search for course by ID or Name ............................................................................................................... 159

Fail to search for course by ID or Name when inputting invalid ID and/or Name ...................................... 160

Fail to search for course by ID or Name when inputting empty ID and/or empty Name ........................... 160

Update course with valid information successfully .................................................................................... 161

Fail to update a course when one or some or all fields are empty ............................................................ 161

Fail to update a course when inputting special character(s) ...................................................................... 162

Update operation is canceled .................................................................................................................... 163

Delete a course .......................................................................................................................................... 163

Delete operation is canceled ..................................................................................................................... 163

Test Cases of Manage User Account Use Case ............................................................................................... 164

Create a new user account successfully ..................................................................................................... 164

Fail to create a new user account when the username that user has provided existing in the system

already ....................................................................................................................................................... 164

Fail to create a new user account when inputting empty username ......................................................... 165

Fail to create a new user account when the inputs containing special character(s) .................................. 166

Search for account by username ............................................................................................................... 166

Fail to search for account by empty username .......................................................................................... 167

Fail to search for account by username that does not exist in the system ................................................ 167

Final Document

10

Fail to search for account by username containing special characters(s) .................................................. 167

Update an account ..................................................................................................................................... 168

Update operation is canceled .................................................................................................................... 168

Delete an account ...................................................................................................................................... 169

Delete operation is canceled ..................................................................................................................... 169

Test Cases of Non-functional requirement testing ........................................................................................ 170

Switch from Vietnamese to English ........................................................................................................... 170

Switch from English to Vietnamese ........................................................................................................... 170

Load testing with 15 requests at the same time ........................................................................................ 170


C- Appendix ................................................................................................................................................ 171

D- Inspection Checklist ............................................................................................................................... 173

The following checklist items apply to the test plan. ..................................................................................... 173

The following checklist items apply to the test cases: ................................................................................... 173

Testing demo ................................................................................................................................................. 176

Unit testing .................................................................................................................................................... 177

Functional requirement testing ..................................................................................................................... 177

Test Cases of Log in and Log out Use Case ..................................................................................................... 177

User logs in successfully with valid username and password .................................................................... 177

Fail to login the system when providing invalid username ........................................................................ 178

Fail to login the system when providing username or password containing special character(s).............. 178

Fail to login the system when providing valid username and invalid password ......................................... 179

Fail to login the system when providing empty username ........................................................................ 179

Fail to login the system when providing valid username and empty password ......................................... 179

User account is locked after failing to log in 3 times .................................................................................. 180

User logs in the system using an account is being used by another user................................................... 180

User logs in the system using an account is being locked .......................................................................... 181

Change password successfully ................................................................................................................... 181

Fail to change password when old or new or confirmed password is empty ............................................ 182

Fail to change password when old password is incorrect .......................................................................... 182

Final Document

11

Recover the password successfully ............................................................................................................ 183

Fail to reset password when inputting wrong answer for the security question ....................................... 183

Fail to reset password when inputting answer containing special character(s) for security question ....... 184

Fail to reset password when inputting empty answer for the security question ....................................... 184

Test Cases of Manage Course Offering Use Case ........................................................................................... 185

Create list of courses offering successfully ................................................................................................ 185

Update the list of course offering .............................................................................................................. 186

Cancel during the Create list of course offering operation ........................................................................ 186

Cancel during the Update list of course offering operation ....................................................................... 187

Fail to create an empty list of course offering ........................................................................................... 188

Update list of course offering while there’s no list of course offering for specific faculty ......................... 188

Test Cases of Manage Department Information Use case ............................................................................. 189

Add a department with valid information successfully .............................................................................. 189

Fail to add a department with name that already exists in the system ..................................................... 189


Fail to add a department when inputting special character(s) to one or some or all fields ....................... 191

Update a department with valid information successfully ........................................................................ 191

Fail to update a department with name that already exists in the system ................................................ 192

Fail to update a department when one or some or all fields are empty .................................................... 193

Fail to update a department when inputting special character(s) to one or some or all fields .................. 193

Update cancel ............................................................................................................................................ 194

Delete a department .................................................................................................................................. 194

Delete cancel ............................................................................................................................................. 195

Test Cases of Register Course Use Case ......................................................................................................... 195

Fail to register more than 30 credits .......................................................................................................... 195

Fail to register less than 15 credits ............................................................................................................ 196

Register for courses successfully ................................................................................................................ 196

Update the existing schedule successfully ................................................................................................. 198

Non-functional requirement testing .............................................................................................................. 198

Test Cases of Non-functional requirement testing ........................................................................................ 198

Final Document

12

Switch from Vietnamese to English ........................................................................................................... 198

Switch from English to Vietnamese ........................................................................................................... 199



System architecture introduction .................................................................................................................. 200

How to download & install tools .................................................................................................................... 201

How to install OURS ....................................................................................................................................... 205

How to run OURS ........................................................................................................................................... 207

How to setup and run tests of OURS ............................................................................................................. 208

How to use OURS ........................................................................................................................................... 209

Login and Logout ........................................................................................................................................... 209

Register Course .............................................................................................................................................. 209

View Academic History .................................................................................................................................. 209

Manage Department Information ................................................................................................................. 210

Manage Student Information ........................................................................................................................ 210

Manage Course Offering ................................................................................................................................ 211

Manage Lecturer Information ........................................................................................................................ 212

Manage Financial Activities ........................................................................................................................... 213

Manage Course Catalogue ............................................................................................................................. 214

Manage User Account ................................................................................................................................... 214

Final Document

13

Introduction This is the Vision and Scope document of OURS project. Like any other Vision and Scope

document, this document will cover the problem and vision statement including project

background, list of users, stakeholders, candidate risks, assumptions & constraints, and project

scope. In addition, the document will also cover the part of development team introduction.

Development team & OURS project TiHonMumMim is a small software development team set up in 2007 by 5 students of

International University. The structure of the team includes 3 software engineers, 1 system &

networking engineer, and 1 team leader.

Our business goal is to be a leading company in IT. And our slogan is “Computing, consulting,

and programming professionally” (CC&PP).

For more information about our team:

Email: [email protected]

Blog: http://360.yahoo.com/TiHonMumMim

mailto:[email protected]

http://360.yahoo.com/TiHonMumMim

Final Document

14

We are assigned to build Online University Registration System (OURS). The internal

development team structure and roles on OURS project:

TEAM LEADER: Responsible for all project management.

DOCUMENTER: Responsible for documentation from other members’ according to the RUP

document standard.

BUSINESS ANALYST: Capture and analyze user requirements.

SYSTEM ANALYST: Analyze system requirements.

SYSTEM DESIGNER: Design the internal structure and operations of system.

UI DESIGNER: Design user interface for the system.

CODER: Responsible for implementing the system.

INTEGRATOR: Integrate the system components.

TESTER: Responsible for testing activities.

Team member ID Email Main roles

Tran Minh Phung 090401096 [email protected] Tester, Integrator

Le Vu Hoang 090401019 [email protected] System Designer, Coder

Huynh Da Thuc 090401121 [email protected] Tester, UI Designer

Phan Duy Tan 090401044 [email protected] System Analyst, Coder

Nguyen Duc Quan 090401038 [email protected] Team leader, Business Analyst, Documenter

OURS project

Team leader

Documenter

Business

Analyst

System

Analyst

System

Designer

UI

Designer

Coder Integrator Tester






Final Document

15

Problem Statement

Project background

There is a widespread agreement that the policy in course registration is very complicated,

costly, take-time, and inconvenient to both students and university. This is due the fact that at the

beginning of each semester, the university has to pause or delay some activities to spend time for

course registration of students. Some staffs have to prepare for offering courses list (including

selecting courses and inviting lecturers …), print it out, and deliver the registration form to each

student. After around one week, all students’ registration form will be returned. And the staffs

have to input students’ registration information to Excel files. They also have to check manually

whether the registration form of each student is legal or not basing on some conditions such as

prerequisite course, maximum and minimum number of credits allowed to register … If there is

anything wrong or students want to add or drop the courses, everything in the above process has

to be restarted. And sometimes some papers are lost when documents are moved from one place

to another place; both students and university have to spend time for retrieving necessary

information and approve it. However, it is impossible to do that in some cases.

In addition, calculating tuition fee for students, managing students’ academic history… are

also thorny issues. Mistakes can occur anytime when financial office‘s staffs use calculator or

Microsoft excel to calculate tuition fee.

Students’ transcript management is also another issue. When students want to have transcript to

see their academic history, they have to wait at least two weeks to receive it from academic affair.

Those are some typical examples for the inconvenience and complication of the current

course registration policy. They lead the university to the decision of building Online Course

Registration System to improve effectiveness, reduce time and cost in course registration process.

Key users

STUDENT: use the system to register for course or view academic history.

ADMINISTRATOR: Manage the system after it is built and the authentication mechanism of the

system.

Final Document

16

ACADEMIC AFFAIR STAFF: use the system to manage department and faculty, lecturer, student,

course catalogue, list of course offering information.

FINANCIAL OFFICE STAFF: use the system to monitor financial activities related to course

registration.

Stakeholders

STUDENT: use the system to register for course or view academic history.

ADMINISTRATOR: Manage the system after it is built.

ACADEMIC AFFAIR STAFF: use the system to manage school, lecturer-professor, and

ADMINISTRATOR: Manage the system after it is built and the authentication mechanism of the

system.

LECTURER: They could give ideas or comment on the solution for the system’s development

and improvement.

FINANCIAL OFFICE MANAGER: They also manage the investment of university for the system

development.

FINANCIAL OFFICE STAFF: use the system to monitor financial activities related to course

registration.

DEVELOPMENT TEAM: include all software engineers, business analysts, system analysts, system

designers, implementers, testers, QA, and project manager… They are tasked to build the

system.

List of Risks

All team members need preparation time for midterm, final exam, and other

subjects.

Phung, Thuc, and Hoang take pre-thesis course.

Lack of experiences in software project management, especially in testing,

verification, validation, risks management and changes management exists in the

Team.

No substitution if any team member cannot continue to contribute to the project.

Applying the project again from the beginning could take development team more

time.

Development time is limited in 2 months only. Therefore the pressure is really high.

Final Document

17

Development team cannot deliver the components when reviewed. Development

team could deliver components of unacceptably low quality, and time must be

added to improve quality.

Developing extra functionalities that are not required will extends the schedule.

Low motivation and moral reduce productivity.

Team member needs extra time to learn unfamiliar tools or techniques.

Conflicts among team members’ ideas results in poor performances, more meeting,

and extra rework.

People’s assignments do not match their strengths.

Components developed separately cannot be integrated easily, requiring redesign

and rework.

Detail reporting could take more development time.

Assumptions & Constraints of Online University Registration System

The system will be applied for universities using credit system like International

University.

The registration information of students is processed by academic affair. And only

academic affair has right to manage and process the registration information.

Development team will use J2EE architecture to develop system.

Policy for tuition fee payment is using cash and it is managed by financial office.

Development team must have at least one 2-hour meeting per week.

Development time 2 months and 10 days (from 01/10/2007 to 20/12/2008)

Development team must produce the first build before review 3 (05/12/2007).

Each team member must work at least 15 hours per week.

Vision of Solution

Vision statement

As the head of information systems for International University team are tasked with developing a new Online Course Registration System. The new system will allow students to access the system during registration time to register for courses, add or drop the registered courses, check tuition

Final Document

18

fee, and review their academic history. Academic affair can use the system as a mean to manage information of schools, classes, professors, students and offering courses. Financial office will use the system to monitor financial activities. The system provides a better solution and policy for course registration in International University. It reduces much time, cost, and resources required in processing registration information of students.

Scope

To be noticed on the scope of the system that this system is an Online University Registration

System. It is not a university management system which is much larger than the system we try to

build. It is only a part of the university management system. Therefore, we have to pay attention

on building applications supporting students to do registration, academic affairs to manage

information related to students’ courses registration, and financial office to mange financial

activities.

List of features

User login and log out

View Academic History

Register for course

Manage Department Information

Manage Student Information

Manage Courses Offering

Manage Course Catalogue

Manage Lecturer Information

Manage Financial Activities

Manage User Account

List of features will not be developed

Pay tuition fee (billing system)

Access the system as professor or lecturer

Final Document

19

Business Plan & SRS Document 11/9/2007


Group 6


Nguyen Duc Quan

Le Vu Hoang

Tran Minh Phung

Phan Duy Tan

Huynh Da Thuc

Date November 9th , 2007

Version 1.0

Status Baseline

Author Team TiHonMumMim

Reviewer Team TiHonMumMim


Final Document

20

Business Plan & SRS Document

Final Document

21

STATEMENT OF WORK

As the head of information systems for International University, our team is tasked with developing

a new Online Course Registration System.

The system will allow students to access the system during registration time to register for

courses, add or drop the registered courses, check tuition fee, and review their academic

history.

The academic affair staffs will use the system as a mean to manage information of

departments, faculties, students and offering courses.

The system also supports financial office staffs in monitoring financial activities.

The features of the systems can be summarized as the following table:

Group of users Features OURS provides

All Users Login and Log out

Academic Affair Staffs Manage Department Information Manage Lecturer Information Manage Course Catalogue Manage Student Information Manage Courses Offering

Financial Office Staffs Manage Financial Activities Students View Academic History

Register for courses Administrator Manage User Account

Our team is going to develop the system using Rational Unified Process with use-case driven. It

includes four phases (inception, elaboration, construction, and transition). And in each phase, we

will go through 6 workflows only (Management, Requirement, Analysis, Design, Implementation,

and Testing). In fact, all 6 workflows will be done iteratively in each phase. However, attention level

of ours team on each workflow in different phases is different. In particular,

Inception: It can be referred as Initial phase. In this phase we will review the initial system request

from customer, do feasibility study, define the vision and scope of the new system, and the initial

project plan.

Final Document

22

Elaboration: It can be referred as planning & requirement phase. In this phase we will pay

attention on detail plan which includes risk plan, estimation, and detail schedule. We also capture

& analyze most of requirements to define the system and analyze its behaviors.

Construction: It can be referred as executing, monitoring, and controlling phase which includes 3

main parts: system design, system implementation, and testing.

Transition: It can be referred as closing phase. In this phase, we will complete and improve the

system, and performance acceptance test to prepare for delivering the system to the stakeholders.

In order to complete the system development, our team will complete the vision and scope

document, project plan and 6 primary development models which are key products of each phase.

Vision and Scope document: It provides a vision of current problem and solution for the problem.

It also defines what will be developed and what will not be developed. It is done in Inception phase.

Project plan: It is a business plan. It includes statements of works, project estimation, schedule,

and risk plan. It is also done in Inception phase.

Use case model: It is a group of use-case package, which includes one or some related use-cases.

And each use case will contain related users’ needs, goals, tasks, processes…, and resources

Inception Elaboration Construction Transition

[Use-case driven]

Use case

Model

Analysis

Model

Design

Model

Deployment

Model

Implementation

Model

Test

Model

Final Document

23

involved to it together. It is created after users and stakeholders’ requirements are captured by

business analysts. The most important document included in use case model is use-cases

specification document. Use-case model will be done in Inception & Elaboration phases.

Analysis model: It contains use-cases and theirs realization which includes domain study, analysis

classes and objects, interactions and behaviors of the system. It also defines the design constraints,

test plan and test cases for the system. Analysis model is mainly done in Elaboration phase.

Design model: It includes system design specifications that define the system architecture and

detail design of components, database, graphical user interface, and the constraints for

implementation. Design model is done in Construction phase.

Deployment model: It defines how we can deploy the system so that it can run on server(s).

However, we intent to develop the system running on one server only, not distributed on many

server. Therefore, we will not pay much attention on deployment model. This model will be done in

Construction phase.

Implementation model: It defines the way we transfer from logical system architecture into

physical system architecture; test components (unit testing) and integrate them together in order

to form a unique system that satisfies users and stakeholders’ needs.

Test model: It includes many checklists and test cases that are planned and designed in previous

phases. It also requires all defects or errors to be recorded in defects and errors reports. It is done

in Construction phase.

The detail of each workflows and models will be presented in detail schedule, and the plan for each

phase.

Development team will use web-base and J2EE technologies to develop the system.

Final Document

24

RESOURCE LIST

Human

Software

Documentation tool Microsoft word 2007

Scheduling tool Microsoft project 2007

IDE Netbean 6.0

Web Server Glassfish server 2.0

Design tool Photoshop CS2

Microsoft Express Web Designer

JDK JDK 6.0

DBMS MySQL 5.0

Browser Internet Explorer 6.0, 7.0

Firefox, Opera

Operating system Windows XP, Vista, Linux

Hardware

Client

3 laptops 2 desktops

Server Reuse one 24/7 available desktop to simulate the server for testing and deployment

Team member Main roles Responsibilities

Tran Minh Phung Tester, Integrator Integrate, test components, builds, and system

Le Vu Hoang System Designer, Coder Design components, system and implement components

Huynh Da Thuc Tester, UI Designer Design graphical user interface, and test components, builds, and system

Phan Duy Tan System Analyst, Coder Analyze system and implement front end of the system

Nguyen Duc Quan Team leader, Business Analyst, Documenter

Monitor, control the project; analyze requirements and system behaviors; and do documentation

Final Document

25

ESTIMATION

Huynh Da Thuc estimation

Name : Huynh Da Thuc Date: 11/09/2007 Estimation form ///

Goal statement: To estimate the time to develop prototype for customer A and B Unit: days

Category x goal tasks x quality tasks waiting time project overhead

No. Task Est Del1 Del2 Del3 Del4 Total Assumption

Initial

1 Write team introduction 3 1 4

2 Review system request 4 2 1 -4 3 The system request is quite complex than initial review

3 Identify User and Stakeholder 4 -4 3 3 The key user and stakeholder varies and changes

4 Gather user and stakeholder ideas

2 3 5 -5 5 Difficult in getting appointment and interview

5 Write Project background 2 0.5 0.5 3

6 Write Vision statement 1 2 3 6

7 Write Scope statement 2 -1 1 2 The scope is quite simple

8 Identify risks and assumption 2 0.5 2.5

9 Complete vision and scope 1 0.5 0.5 2 The document should be review again and check any existing error

10 Team Review 3 -1 2 Team gather late and far distance

11 Review 1 3 0.5 0.5 4

Planning

1 Complete statements of works 2 1 3 Statement of works is more complex

2 Plan for risk 4 1 -1 4 Risk varies and should be coherent between the team members

3 WBS 2 3 -1 1 5

4 Estimation & assumption 1 0.5 0.5 2 Idea should be coherent

5 Schedule 0.5 0.5 1 2

6 Discussion summary 2 3 1 7 The document is long and complex, need more time to review

7 Analyze initial requirement 2 2 2 6

8 Understand stakeholder & user needs 1 1 -2 2 2

9 Complete glossary 2 1 1 4 The glossary should be exact and complete

10 Login use case 1 1 -2 3 3

11 Manage faculty use case 1.5 2

12 Manage lecturer use case 1 1 1 3 The use case should be reviewed many times

13 Manage student use case 0.5 2 3 The use case should be reviewed many times

14 Manage courses offering 2 1 1 4 The use case should be reviewed many times

15 View academic history 2 2 1 5

Final Document

26

16 Register courses use case 3 1 1 1 6

17 Manage financial activities 3 2 -3 1 3 Financial activities are quite complex

18 Complete functional requirement 1 1 -4 4 2

19 Complete non-functional requirements 2 1 3

20 Define the system 1 1 3 1 6 Team should consider carefully this part

21 Manage the scope of the system 2 1 1 1 5

22 Complete SRS 1 1 1 3 Requirement is complex and should be reviewed more

23 SRS inspection 0.5 1 2

24 Test Plan 1.5 1 3

25 Test case 2 1 3

26 Detail WBS 2 2

27 Re-estimation & assumption 1.4 1 2

28 Detail Schedule 1.5 2

29 Team review 1 2 3

30 Review 2 2 2

Executing

1 Define candidate architecture 1.5 2

2 Refine the architecture 1 1 2 Refinement should last for more session

3 Analyze behaviors 2 2

4 Complete analysis model 2 1 3

5 Complete design model & system architecture 1 1 1 3 The architecture grows rapidly

6 Design GUI 2 1 3

7 Design database 1.5 2

8 Design persistence layer 2 1 3

9 Design business logic layer 1.5 2

10 Design presentation layer 1.5 1 3

11 Design test case 2 2

12 Complete Implementation model 1 1 2

13 Complete Implementation guidelines & code conventions 2 2

14 Produce Integration build plan 1 1

15 Review OOAD 1 1

16 Create file structure of system 1 1

17 Implement GUI 10 10

18 Implement database 9 2 11 No experience in using MySQL

19 Implement persistence layer 11 11

Final Document

27

20 Implement business logic layer 9 9

21 Implement presentation layer 9 9

22 Review code & update changes 2 1 3 Fixing bugs and updates encounter difficulty

23 Integrated build 2 2

24 Do integration test 1 1 2

25 Test build 1 1 2

26 Test system 2 1 3 System should be tested well

27 Complete test report 6 2 8

Inspection meeting should be established between this duration to ensure the report is defection-free and coherent

28 Rework 4 2 6

29 Team review & evaluation 1 1 2

30 Review 3 1 2 3

Closing

1 Complete source code 6 2 4 12 Need coherence and re-check logic functionality

2 Complete User Manual 3 2 1 1 7 User manual must be in detail

3 Do acceptance test 3 1 1 5 Acceptance test is brand new to team

4 Team review & evaluation 2 2

5 Complete all documents 2 2 3 7

6 Review 4 2 2

Final Document

28

Phan Duy Tan estimation

Name : Phan Duy Tan Date: 11/09/2007 Estimation form ///



No.

Task Est. Del1 Del2 Del3 Del4 Total Assumption

Initial

1 Write team introduction 0.5 0.5 1 discuss

2 Review system request 0.5 0.5 1 additional requirement

3 Identify User and stakeholder 1 1 1 3 Interview

4 Login use case 4 -2 2

2 members do not know requirements provides last year

5 Write Project background 1 1 2 Spend time to understand current problem

6 Write Vision statement 0.5 0.5 1 review

7 Write Scope statement 0.5 0.5 1 review

8 Identify risks and assumption 3 -1 2 4 cannot find all risk and assumption

9 Complete vision and scope 0.5 0.5 1

All parts of Vision and Scope document have to be finished

10 Team Review 1

11 Review 1 0.5 0.5

Planning

1 Complete statements of works 0.5 0.5

2 Plan for risk 6 4 -1 9 Need a lot of meeting to identify mitigation plan

3 WBS 0.5 0.5

4 Estimation & assumption 1 1

5 Schedule 0.5 0.5

6 Discussion summary 1 1

7 Analyze initial requirement 2 1 3 Review

8 Understand stake holder & user needs 2 2

9 Complete glossary 0.5 0.5 1 Double-check term definitions

10 Login use case 1 1

11 Manage faculty use case 1 1

12 Manage lecturer use case 1 1

13 Manage student use case 2 2

Final Document

29

14

Manage courses offering 4 -1 1 4 There are many solutions in solving problem of course offering management. It is difficult to choose one

15 View academic history 1 1

16 Register courses use case 4 -1 3 Team brainstorming

17 Manage financial activities 2 -1 1 only simple activities

18 Complete functional requirement 3 3

19 Complete non-functional requirements 3 3

20 Define the system 2 1 3 Review

21 Manage the scope of the system 2 2

22 Complete SRS 1 1 2 Use cases are written in details

23 SRS inspection 1 1

24 Test Plan 2 1 3 No experience

25 Test case 2 1 3 Review

26 Detail WBS 0.5 0.5

27 Re-estimation & assumption 0.5 0.5 1 Under-estimate tasks

28 Detail Schedule 0.5 0.5

29 Team review 1 1

30 Review 2 1 1

Executing

1 Define candidate architecture 3 2 5 J2EE architecture is complex

2 Refine the architecture 1 1 2 J2EE architecture is complex


4 Complete analysis model 1 1

5 Complete design model & system architecture 2 1 3 Review

6 Design GUI 1 1

7 Design database 2 2

8 Design persistence layer 1 1

9 Design business logic layer 1 1

10 Design presentation layer 1 1

11 Design test case 2 1 3 test case document

12 Complete Implementation model 2 2

13 Complete Implementation guidelines & code conventions 0.5 0.5

14 Produce Integration build plan 0.5 1

15 Review OOAD 0.5 0.5 1 Debate

16 Create file structure of system 0.5 0.5 1 Packaging

Final Document

30

17 Implement GUI 6 -1 -1 1 5 Tan has a lot of experience in implementing GUI

18 Implement database 4 4 2 1 11 First time using MySQL



21 Implement presentation layer 6 1 7 Environment integration

22 Review code & update changes 1 1

23 Integrate build 1 1

24 Do integration test 2 -1 1 No experience

25 Test build 2 2

26 Test system 2 2

27 Complete test report 3 2 5 Fix new defects

28 Rework 3 3


30 Review 3 1 1

Closing

1 Complete source code 10 -1 -1 8 use IDE

2 Complete User Manual 6 -1 5 Thuc has a very good writing skill

3 Do acceptance test 3 3


5 Complete all documents 3 3

6 Review 4 1 1

Final Document

31

Tran Minh Phung estimation

Name : Tran Minh Phung Date: 11/09/2007 Estimation form ///




Initial

1 Write team introduction 2 0.5 0.5 3 Understanding the problems

2 Review system request 2 1 0.5 0.5 4

3 Identify User and Stakeholder 2 0.5 0.5 3

4

Gather user and stakeholder ideas

3 1 1 5 Use all existed documents

5 Write Project background 1 1 2 4

6 Write Vision statement 3 1 1 0.5 0.5 6

7 Write Scope statement 4 1 2 7

8 Identify risks and assumption 1 0.5 0.5 1 3

9 Complete vision and scope 1 0.5 0.5 2 Have enough all information

10 Team Review 1 1

11 Review 1 1 1

Planning

1 Complete statements of works 1 0.5 0.5 2 Vision and Scope documents is baseline

2 Plan for risk 3 2 1 1 5 Candidate risks must be listed out already

3 WBS 4 0.5 0.5 1 6

4 Estimation & assumption 1.5 0.5 2

5 Schedule 2 1 3

6 Discussion summary 6 1 7

7 Analyze initial requirement 2 2

8 Understand stake holder & user needs 1 1 1 3

9 Complete glossary 4 1 0.5 0.5 5

10 Login use case 3 0.5 0.5 4

Final Document

32

11 Manage faculty use case 2 0.5 0.5 3

12 Manage lecturer use case 3 0.5 0.5 4

13 Manage student use case 3 1 4

14 Manage courses offering 3 1 4

15 View academic history 4 1 1 6

16 Register courses use case 4 1 1 1 7

17 Manage financial activities 1 0.5 2


19 Complete non-functional requirements 3 1 4

20 Define the system 7 0.5 0.5 8

21 Manage the scope of the system 8 1 2 11

22 Complete SRS 1 1


24 Test Plan 2 1 3

25 Test case 2 1 3

26 Detail WBS 2 2

27 Re-estimation & assumption 1 1

28 Detail Schedule 1 1

29 Team review 1 1

30 Review 2 1 1

Executing

1 Define candidate architecture 1 1 2

2 Refine the architecture 1 1



5 Complete design model & system architecture 2 2

6 Design GUI 1 1 2

7 Design database 1 1 2

8 Design persistence layer 1 1 2

9 Design business logic layer 1.5 0.5 2

10 Design presentation layer 1.5 0.5 2

11 Design test case 1.5 0.5 2




15 Review OOAD 1 1

Final Document

33

16 Create file structure of system 1.5 0.5 2

17 Implement GUI 10 2 12

18 Implement database 8 1.5 0.5 10

19 Implement persistence layer 9 0.5 0.5 10

20 Implement business logic layer 8 0.5 0.5 1 10

21 Implement presentation layer 7 2 1 10

22 Review code & update changes 1 1 2

23 Integrate build 1 1 2

24 Do integration test 1 1 2

25 Test build 1 0.5 0.5 2

26 Test system 3 3

27 Complete test report 6 2 1 9

28 Rework 5 2 7


30 Review 3 1 1

Closing

1 Complete source code 10 1 1 1 13

2 Complete User Manual 6 1 1 8

3 Do acceptance test 4 2 6


5 Complete all documents 4 3 1 8

6 Review 4 1 1

Final Document

34

Nguyen Duc Quan estimation

Name :Nguyen Duc Quan Date: 11/09/2007 Estimation form ///




Initial

1 Write team introduction 1 2 -1 2

2 Review system request 1 1 2

3 Identify User and Stakeholder 2 1 -1 2

4

Gather user and stakeholder ideas

1 1 Use existing requirements provided last year, additional requirements

5 Write Project background 1 1

6 Write Vision statement 1 1

7 Write Scope statement 1 1

8 Identify risks and assumption 4 2 2 -2 6

this task must be done along the summary task

9 Complete vision and scope 0.5 0.5 1 must do informal review

10 Team Review 1 1

11 Review 1 1 1

Planning

1 Complete statements of works 0.5 0.5 1

2 Plan for risk 8 2 1 -2 11 lack of experience in risk mitigation

3 WBS 1 1

4 Estimation & assumption 1 1

5 Schedule 1 1

6 Discussion summary 1 0.5 0.5 2 must be more detail than vision and scope

7 Analyze initial requirement 1 1 2


Final Document

35

9 Complete glossary 2 2

10 Login use case 3 -1 2 Login is a popular function

11 Manage faculty use case 2 1 3

3 members are familiar with old requirements

12 Manage lecturer use case 2 1 3

13 Manage student use case 2 1 3

14 Manage courses offering 2 1 3

15 View academic history 2 1 3

16 Register courses use case 2 1 3

17 Manage financial activities 2 1 3

18 Complete functional requirement 1 1 1 3

19 Complete non-functional requirements 1 1 1 3

20 Define the system 1 1 1 3

21 Manage the scope of the system 6 2 1 1 10

Must perform scope management during the requirement phase

22 Complete SRS 1 1


24 Test Plan 1 1 2

25 Test case 1 1 2

26 Detail WBS 1 1


28 Detail Schedule 1 1

29 Team review 1 1

30 Review 2 1 1

Executing

1 Define candidate architecture 2 1 3

2 Refine the architecture 1 1



5 Complete design model & system architecture 1 1

6 Design GUI 1 1 2


8 Design persistence layer 1 1


10 Design presentation layer 1 1

Final Document

36

11 Design test case 1 0.5 0.5 2

12 Complete Implementation model 1 1 2



15 Review OOAD 1 1

16 Create file structure of system 1 1

17 Implement GUI 5 2 2 9

18 Implement database 6 1 1 1 9

19 Implement persistence layer 7 1 9

20 Implement business logic layer 7 1 9

21 Implement presentation layer 7 1 9

22 Review code & update changes 1 1

23 Integrate build 1 1

24 Do integration test 1 1

25 Test build 1 1

26 Test system 1 1 2

27 Complete test report 5 2 1 8

28 Rework 3 0.5 0.5 1 5


30 Review 3 1 1

Closing

1 Complete source code 10 2 12 J2EE requires more works

2 Complete User Manual 5 1 1 7 Too many guidelines must be written

3 Do acceptance test 5 5


5 Complete all documents 4 1 1 6 documentation follows RUP standard

6 Review 4 1 1

Final Document

37

Le Vu Hoang estimation

Name : Le Vu Hoang Date: 11/09/2007 Estimation form ///




Initial

1 Write team introduction 1 1 2 Review introduction

2 Review system request 3 -1 2 Already have basic requirement

3 Identify User and Stakeholder 2 1 3 Investigate and interview

4 Gather user and stakeholder ideas

1 1

5 Write Project background 2 2

6 Write Vision statement 1 1

7 Write Scope statement 1 1

8 Identify risks and assumption 9 -1 -1 7 Team brainstorming

9 Complete vision and scope 2 2

10 Team Review 2 2

11 Review 1 1 1

Planning

1 Complete statements of works 1 1

2 Plan for risk 12 -1 -1 10 Just find basic risk

3 WBS 1 1

4 Estimation & assumption 3 -1 2 Elicitation

5 Schedule 3 -1 2 Assign schedule for 1 person

6 Discussion summary 1 2 3 Sum everything in detail

7 Analyze initial requirement 2 -1 1 Stifling


9 Complete glossary 2 2

10 Login use case 6 -2 4 Login use case is simple

11 Manage faculty use case 4 4

12 Manage lecturer use case 4 4

13 Manage student use case 6 -1 5 Inspection

14 Manage courses offering 6 -1 -1 4 Just consider about offering, not class

Final Document

38

15 View academic history 3 3

16 Register courses use case 3 3

17 Manage financial activities 2 2


19 Complete non-functional requirements 4 4

20 Define the system 2 1 3 Iteration abuse

21 Manage the scope of the system 10 3 13 Define carefully scope

22 Complete SRS 1 1


24 Test Plan 2 -1 1 2 people

25 Test case 2 -1 1 2 people

26 Detail WBS 1 1 2 Scope Creep


28 Detail Schedule 1 1 2 Misunderstood predecessor

29 Team review 2 2

30 Review 2 1 1

Executing

1 Define candidate architecture 3 -1 2 Fix J2EE model

2 Refine the architecture 0.5 0.5

3 Analyze behaviors 0.5 0.5

4 Complete analysis model 1 0.5 0.5 2 Review model

5 Complete design model & system architecture 3 -1 2 Hoang is professional

6 Design GUI 2 1 3 Use AJAX


8 Design persistent layer 2 2


10 Design presentation layer 1 1 2 Use AJAX

11 Design test case 0.5 0.5 1 Many test cases


13 Complete Implementation guidelines & code conventions 1 0.5 1.5 Replace Magic Number with symbolic Constant

14 Produce Integration build plan 1 1 2 Extract Method

15 Review OOAD 3 -1 2 Defect tracking

16 Create file structure of system 0.5 0.5

17 Implement GUI 7 5 12 Implement AJAX

18 Implement database 10 -1.5 -0.5 8 Use Database tool


Final Document

39


21 Implement presentation layer 10 10

22 Review code & update changes 4 -1 -1 2 Good Programming skill

23 Integrate build 1 1 2 No experience

24 Do integration test 2 2

25 Test build 1 1

26 Test system 1 1

27 Complete test report 5 2 2 9 Report unit test

28 Rework 6 1 -1 6 Broken build


30 Review 3 1 1

Closing

1 Complete source code 16 -1 -1 14 Need system build

2 Complete User Manual 10 -1 9 Good English skill

3 Do acceptance test 4 0.5 0.5 1 6 Need rework


5 Complete all documents 5 2 7 Need time for review

6 Review 4 1 1

Estimation Summary

Date: 11/09/2007 Estimation Summary form ///

Goal statement: To estimate the time to develop prototype for customer Unit: days

Estimators : Quan, Thuc, Tan, Hoang, Phung

No. Task Thuc Tan P Q H Best Worst Avg Assumption

Initial

1 Write team introduction 4 1 3 2 2 1 4 2.4 Review introduction

2 Review system request 3 1 4 2 2 1 4 2.4 The system request is quite complex than initial review

3 Identify User and Stakeholder 3 3 3 2 3 2 3 2.8

The key user and stakeholder varies and changes

4 Gather user and stakeholder ideas 5 2 5 1 1 1 5 2.8

Difficult in getting appointment and interview

5 Write Project background 3 2 4 1 2 1 4 2.4

6 Write Vision statement 6 1 6 1 1 1 6 3

7 Write Scope statement 2 1 7 1 1 1 7 2.4 The scope is quite simple

8 Identify risks and assumption 2.5 4 3 6 7 2.5 7 4.5 Team brainstorming

9 Complete vision and scope 2 1 2 1 2 1 2 1.6 The document should be review again and check any

Final Document

40

existing error

10 Team Review 2 1 1 1 2 1 2 1.4 Team gather late and far distance

11 Review 1 4 0.5 1 1 1 0.5 4 1.5

Planning

1 Complete statements of works 3 0.5 2 1 1 0.5 3 1.5

Statement of works is more complex

2 Plan for risk 4 9 5 11 10 4 11 7.8

Risk varies and should be coherent between the team members

3 WBS 5 0.5 6 1 1 0.5 6 2.7

4 Estimation & assumption 2 1 2 1 2 1 2 1.6 Idea should be coherent

5 Schedule 2 0.5 3 1 2 0.5 3 1.7 Assign schedule for 1 person

6 Discussion summary 7 1 7 2 3 1 7 4

The document is long and complex, need more time to review

7 Analyze initial requirement 6 3 2 2 1 1 6 2.8 Stifling

8 Understand stakeholder & user needs 2 2 3 2 3 2 3 2.4

9 Complete glossary 4 1 5 2 2 1 5 2.8 The glossary should be exact and complete

10 Login use case 3 1 4 2 4 1 4 2.8 Login use case is simple

11 Manage faculty use case 2 1 3 3 4 1 4 2.6

12 Manage lecturer use case 3 1 4 3 4 1 4 3 The use case should be reviewed many times

13 Manage student use case 3 2 4 3 5 2 5 3.4 The use case should be reviewed many times

14 Manage courses offering 4 4 4 3 4 3 4 3.8 The use case should be reviewed many times

15 View academic history 5 1 6 3 3 1 6 3.6

16 Register courses use case 6 3 7 3 3 3 7 4.4

17 Manage financial activities 3 1 2 3 2 1 3 2.2 Financial activities are quite complex

18 Complete functional requirement 2 3 1 3 4 1 4 2.6

19 Complete non-functional requirements 3 3 4 3 4 3 4 3.4

20 Define the system 6 3 8 3 3 3 8 4.6 Team should consider carefully this part

21 Manage the scope of the system 5 2 11 10 13 2 13 8.2 Define carefully scope

22 Complete SRS 3 2 1 1 1 1 3 1.6 Requirement is complex and should be reviewed more

23 SRS inspection 2 1 1 1 1 1 2 1.2

24 Test Plan 3 3 3 2 1 1 3 2.4

Final Document

41

25 Test case 3 3 3 2 1 1 3 2.4

26 Detail WBS 2 0.5 2 1 2 0.5 2 1.5 Scope Creep

27 Re-estimation & assumption 2 1 1 1 2 1 2 1.4

28 Detail Schedule 2 0.5 1 1 2 0.5 2 1.3 Misunderstood predecessor

29 Team review 3 1 1 1 2 1 3 1.6

30 Review 2 2 1 1 1 1 1 2 1.2

Execution

1 Define candidate architecture 2 5 2 3 2 2 5 2.8 Fix J2EE model

2 Refine the architecture 2 2 1 1 0.5 0.5 2 1.3 Refinement should last for more session

3 Analyze behaviors 2 1 1 1 0.5 0.5 2 1.1

4 Complete analysis model 3 1 2 1 2 1 3 1.8 Review model

5 Complete design model & system architecture 3 3 2 1 2 1 3 2.2 The architecture grows rapidly

6 Design GUI 3 1 2 2 3 1 3 2.2 Use AJAX

7 Design database 2 2 2 1 1 1 2 1.6

8 Design persistence layer 3 1 2 1 2 1 3 1.8

9 Design business logic layer 2 1 2 1 2 1 2 1.6

10 Design presentation layer 3 1 2 1 2 1 3 1.8 Use AJAX

11 Design test case 2 3 2 2 1 1 3 2 Many test cases

12 Complete Implementation model 2 2 2 2 1 1 2 1.8

13

Complete Implementation guidelines & code conventions 2 0.5 1 1 1.5 0.5 2 1.2

Replace Magic Number with symbolic Constant

14 Produce Integration build plan 1 1 2 1 2 1 2 1.4 Extract Method

15 Review OOAD 1 1 1 1 2 1 2 1.2 Defect tracking

16 Create file structure of system 1 1 2 1 0.5 0.5 2 1.1

17 Implement GUI 10 5 12 9 12 5 12 9.6 Implement AJAX

18 Implement database 11 11 10 9 8 8 11 9.8 No experience in using MySQL

19 Implement persistence layer 11 9 10 9 9 9 11 9.6

20 Implement business logic layer 9 10 10 9 9 9 10 9.4

21 Implement presentation layer 9 7 10 9 10 7 10 9

22 Review code & update changes 3 1 2 1 2 1 3 1.8

Fixing bugs and updates encounter difficulty

23 Integrated build 2 1 2 1 2 1 2 1.6

24 Do integration test 2 1 2 1 2 1 2 1.6

25 Test build 2 2 2 1 1 1 2 1.6

26 Test system 3 2 3 2 1 1 3 2.2 System should be tested well

Final Document

42

27 Complete test report 8 5 9 8 9 5 9 7.8

Inspection meeting should be established between this duration to ensure the report is defection-free and coherent

28 Rework 6 3 7 5 6 3 7 5.4 Broken build

29 Team review & evaluation 2 1 2 1 1 1 2 1.4

30 Review 3 3 1 1 1 1 1 3 1.4

Closing

1 Complete source code 12 8 13 12 14 8 14 11.8 Need coherence and re-check logic functionality

2 Complete User Manual 7 5 8 7 9 5 9 7.2 User manual must be in detail

3 Do acceptance test 5 3 6 5 6 3 6 5 Acceptance test is brand new to team

4 Team review & evaluation 2 1 3 2 3 1 3 2.2

5 Complete all documents 7 3 8 6 7 3 8 6.2 Need time for review

6 Review 4 2 1 1 1 1 1 2 1.2

Total 289 181 295 215 253 144 352 246

Final Document

43

SCHEDULE

Task list

No. Task Duration Start Date

End Date

Pre-decessor

Resource

1 Initial 11 days 02/10/2007 15/10/2007 Team

2 Write team introduction 2 days 02/10/2007 03/10/2007 Team

3 Review system request 2 days 02/10/2007 03/10/2007 Team

4 Develop vision and scope 6 days 04/10/2007 10/10/2007 3 Team

5 Identify User and Stakeholder 2 days 04/10/2007 05/10/2007 Team

6 Gather user and stakeholder ideas 1 day 06/10/2007 06/10/2007 5 Quan

7 Write Project background 1 day 08/10/2007 08/10/2007 6 Thuc

8 Write Vision statement 1 day 08/10/2007 08/10/2007 6 Phung

9 Write Scope statement 1 day 08/10/2007 08/10/2007 6 Hoang

10 Identify risks and assumption 6 days 04/10/2007 10/10/2007 5SS Team

11 Complete vision and scope 1 day 11/10/2007 11/10/2007 4 Quan

12 Team Review 1 day 12/10/2007 12/10/2007 11 Team

13 Review 1 1 day 15/10/2007 15/10/2007 12 Team

14 Planning 20 days 15/10/2007 09/11/2007 Team

15 Complete statements of works 1 day 15/10/2007 15/10/2007 Team

16 Plan for risk 11 days 15/10/2007 29/10/2007 Tan

17 WBS 1 day 15/10/2007 15/10/2007 Thuc

18 Estimation & assumption 1 day 16/10/2007 16/10/2007 17 Team

19 Schedule 1 day 17/10/2007 17/10/2007 18 Phung

20 Discussion summary 2 days 15/10/2007 16/10/2007 Quan

21 Analyze initial requirement 2 days 18/10/2007 19/10/2007 20 Team

22 Understand stake holder & user needs 2 days 22/10/2007 23/10/2007 21 Quan

23 Complete glossary 2 days 22/10/2007 23/10/2007 22SS Hoang

24 Complete use case model 3 days 24/10/2007 26/10/2007 22 Team

25 Login use case 3 days 24/10/2007 26/10/2007 Thuc

26 Manage faculty use case 3 days 24/10/2007 26/10/2007 Phung

27 Manage lecturer use case 3 days 24/10/2007 26/10/2007 Phung

28 Manage student use case 3 days 24/10/2007 26/10/2007 Phung

29 Manage offering course 3 days 24/10/2007 26/10/2007 Hoang

30 View academic history 3 days 24/10/2007 26/10/2007 Tan

31 Register courses use case 3 days 24/10/2007 26/10/2007 Tan

32 Manage financial activities 3 days 24/10/2007 26/10/2007 Quan

33 Complete functional requirement 3 days 24/10/2007 26/10/2007 Team

34 Complete non-functional requirements 3 days 24/10/2007 26/10/2007 Team

Final Document

44

35 Define the system 3 days 24/10/2007 26/10/2007 Hoang

36 Manage the scope of the system 10 days 15/10/2007 26/10/2007 Quan

37 Complete SRS 1 day 29/10/2007 29/10/2007 35,33,34,24 Quan

38 SRS inspection 1 day 31/10/2007 31/10/2007 37 Team

39 Test Plan 1 day 01/11/2007 01/11/2007 37SS Phung, Thuc

40 Test case 1 day 01/11/2007 01/11/2007 37SS,39SS Phung, Thuc

41 Detail WBS 1 day 02/11/2007 02/11/2007 37,38 Quan

42 Re-estimation & assumption 1 day 05/11/2007 05/11/2007 41 Team

43 Detail Schedule 1 day 06/11/2007 06/11/2007 42 Quan

44 Team review 1 day 07/11/2007 07/11/2007 43 Team

45 Review 2 1 day 09/11/2007 09/11/2007 44 Team

46 Executing 31 days 01/11/2007 07/12/2007 Team

47 Define candidate architecture 3 days 01/11/2007 05/11/2007 Quan

48 Refine the architecture 1 day 09/11/2007 09/11/2007 47 Team

49 Analyze behaviors 1 day 09/11/2007 09/11/2007 Quan

50 Complete analysis model 1 day 10/11/2007 11/11/2007 49 Quan

51 Complete design model & system architecture 1 day 12/11/2007 12/11/2007 50 Hoang

52 Design component 1 day 13/11/2007 13/11/2007 51 Team

53 Design GUI 1 day 13/11/2007 13/11/2007 Thuc,Tan

54 Design database 1 day 13/11/2007 13/11/2007 Hoang

55 Design persistence layer 1 day 13/11/2007 13/11/2007 Hoang

56 Design business logic layer 1 day 13/11/2007 13/11/2007 Hoang

57 Design presentation layer 1 day 13/11/2007 13/11/2007 Tan

58 Design test case 1 day 13/11/2007 13/11/2007 52SS Phung, Thuc

59 Complete Implementation model 2 days 14/11/2007 15/11/2007 52 Hoang

60 Complete Implementation guidelines & code conventions 1 day 16/11/2007 16/11/2007 59 Tan

61 Produce Integration build plan 1 day 16/11/2007 17/11/2007 60SS Quan

62 Review OOAD 1 day 18/11/2007 18/11/2007 60,61 Team

63 Create file structure of system 1 day 19/11/2007 19/11/2007 62 Tan

64 Implement components & unit test & check list 9 days 19/11/2007 29/11/2007 Team

65 Implement GUI 9 days 19/11/2007 29/11/2007 Thuc

66 Implement database 9 days 19/11/2007 29/11/2007 Hoang

67 Implement persistence layer 9 days 19/11/2007 29/11/2007 Hoang

68 Implement business logic layer 9 days 19/11/2007 29/11/2007 Hoang

69 Implement presentation layer 9 days 19/11/2007 29/11/2007 Tan

70 Review code & update changes 1 day 30/11/2007 30/11/2007 64 Team

Final Document

45

71 Integrate build 1 day 01/12/2007 01/12/2007 70 Phung

72 Testing & fix bugs 5 days 01/12/2007 05/12/2007 Team

73 Do integration test 1 day 01/12/2007 01/12/2007 Phung

74 Test build 1 day 02/12/2007 02/12/2007 73 Phung

75 Test system 1 day 03/12/2007 03/12/2007 74 Tan, Thuc

76 Complete test report 4 days 01/12/2007 04/12/2007 Phung, Thuc

77 Rework 5 days 01/12/2007 05/12/2007 Team

78 Team review & evaluation 1 day 06/12/2007 06/12/2007 72 Team

79 Review 3 1 day 07/12/2007 07/12/2007 78 Team

80 Closing 18 days 10/12/2007 28/12/2007 Team

81 Complete source code 6 days 10/12/2007 15/12/2007 Hoang,Tan

82 complete User Manual 7 days 10/12/2007 17/12/2007 Thuc

83 Do acceptance test 5 days 15/12/2007 20/12/2007 Phung

84 Team review & evaluation 2 days 21/12/2007 22/12/2007 Team

85 Complete all documents 6 days 18/12/2007 23/12/2007 Quan

86 Review 4 1 day 28/12/2007 28/12/2007 Team

Gantt chart (reference)

Final Document

46

RISK PLAN

Risk plan for project OURS Project

Assessment team members Quan, Tan, Thuc, Phung, Hoang

Risk Prob. Impact Priority Actions

Phung, Thuc, and Hoang take pre-thesis course

5 4 20

Assign tasks of these people to Quan &

Tan, Work overtime.

Components developed separately cannot be integrated easily, requiring redesign and rework.

4 4 16

Reserve time to integrated and rework for

integration in schedule.

Development team cannot complete to deliver the components when reviewing

3 5 15

Make another informal meeting in the

same week to complete them

No substitution if any team member cannot continue to contribute to the project.

4 3 12 Add more tasks for remaining members, add more time to work

People’s assignments do not match their strengths

3 4 12 Before starting; development team lists out and evaluates the skills of each member.

Detail reporting could take more development time.

4 3 12

Each team member will write a draft

version of report on what he does before

documenter of team writes it again.

All team members need preparation time for midterm, final exam, and other subjects.

3 3 9

Work on weekends, set schedule with

time for exam; define meetings in each

week in suitable time for all people.

Lack of experiences in software project management, especially in testing, verification, validation, risks management and changes management exists in the Team

3 3 9

Assign 2 members working on each test. Risk and changes management tasks will have a long duration to finish. Support others people about what we already known.

Development time is limited in 2 months only. Therefore,

2 3 6 Create a detailed schedule in a whole

project and supervise process of work with

Final Document

47

the pressure is really high. schedule, change schedule with any

mismatch with schedule.

Low motivation and moral reduce productivity

2 3 6

Operate some relax actions to recharge

team spirit

Team member needs extra time to learn unfamiliar Tools or techniques.

2 2 4

Make clear about techniques we used, if

some new techniques are needed, assign a

member read them and talk to other

members about them.

Conflicts among team members’ ideas results in poor performances, more meeting, and extra rework.

2 2 4

PM has to control conflicts in team, assure everybody thoughts are respected, make assumptions when we have conflicts, record any conflicts to change if we are in wrong way

Developing extra functionalities that are not required will extends the schedule.

1 2 2

Analysis carefully requirements, review

requirements and design, if extra function

appears, change schedule to add more

time for working

Final Document

48

DISCUSSION SUMMARY

Project background

Purpose of project

There is a widespread agreement that the policy in course registration is very complicated,

costly, take-time, and inconvenient to both students and university. This is due the fact that at the

beginning of each semester, the university has to pause or delay some activities to spend time for

course registration of students. Some staffs have to prepare for offering courses list (including

selecting courses and inviting lecturers …), print it out, and deliver the registration form to each

student. After around one week, all students’ registration form will be returned. In addition, the

staffs have to input students’ registration information to Excel files. They also have to check

manually whether the registration form of each student is legal or not basing on some conditions

such as prerequisite course, maximum and minimum number of credits allowed registering … If

there is anything wrong or students want to add or drop the courses, everything in the above

process has to be restarted. Moreover, sometimes some papers are lost when documents are

moved from one place to another place; both students and university have to spend time for

retrieving necessary information and approve it. However, it is impossible to do that in some cases.

In addition, calculating tuition fee for students, managing students’ academic history… are

also thorny issues. Mistakes can occur anytime when financial office‘s staffs use calculator or

Microsoft excel to calculate tuition fee.

Students’ transcript management is also another issue. When students want to have

transcript to see their academic history, they have to wait at least two weeks to receive it from

academic affair.

Those are some typical examples for the inconvenience and complication of the current

course registration policy. They lead the university to the decision of building Online Course

Registration System to improve effectiveness, reduce time and cost in course registration process.

Final Document

49

Scope of project

The list of features which are developed

Feature Description

Login and logout

o This feature allows user to log in the system to achieve the access permission to perform other functions, which are granted to that specific user. It also lets the user log out his/her session.

o If the username and password are correct, the system redirects the user to his/her specific homepage (student, administrator or officers…).

o Otherwise, the system warns the user with the error messages. The account is locked out if the user fails to log in three times. User has to wait 30 minutes for the account to be released or contact to the administrator

o Users also have another option to choose when they forget the password and intend to reset back to the default password.

o User can change their own password and change the security question


o This feature allows a Student to view his studying progress. The Student can see the courses he has taken as well as the scores and status (passed or failed)as follow:

View all courses he took. View courses in a specific semester in a specific year. View all courses he passed. View all courses he failed.

Register course o This feature allows a Student to register course offerings in the current

semester. o The system retrieves and displays the Student’s current schedule (e.g.;

the schedule for the current semester). The schedule may be empty. o The student can change the schedule by adding or dropping course(s). o The system also checks the prerequisite and the total of credits before

allowing that student to register the selected courses. The Student can only select a total of minimum 15 credits and maximum 30 credits.

o After the Student add or drop a course, the system recalculate total credits and discount


o This feature allows Academic Affair Staff to manage department and faculty information. This includes adding, updating, and deleting department and faculty from the system.

Manage Student

o This feature allows the Academic Affair Staff to manage student information in the registration system. This includes adding, updating,

Final Document

50

Information deleting, and searching students from the system.

Manage Courses Offering

o This feature allows Academic Affairs to monitor course offerings in one semester of specific year

o The following tasks are included in this feature: Create list of course, update list of course, add a course offering, delete course offering, change lecturer

Manage Lecturer information

o This feature allows the Academic Affair Staff to manage lecturer information in the registration system. This includes adding, updating, deleting, and searching lecturers from the system.

Manage financial activities

o This feature allows Financial Office Staff to monitor student’s tuition fee. This includes viewing and updating the tuition fee status of students.

o Following tasks are included in this feature: View tuition fee

View by ID and name

View by faculty and academic duration

View by course, semester, and academic year

o Update tuition fee of students


o This feature allows the Academic Affair Staff to manage Course Catalogue Information in the registration system. This includes adding, updating, deleting, and searching Course Catalogue Information from the system.

Manage User Accounts

o This feature allows the Administrator to Create User Account, Reset User Password, Delete or Edit User Account, Unlock User Account

Final Document

51

Perspectives

Who will use the system?

User Description

Student The people who attending the course in the university. Use the system to register the courses and view academic history

Academic Affair Staff

The Staff who is working in the Academic Affair Office, responsible for the Academic issue in the University. They use the system to manage school, lecturer, and student information

Financial Office Staff The Staff who is responsible for the financial business in the University. Use the system to monitor financial activities related to course registration

Who can provide needs about the system?

Student The Student needs an online mechanism to register, add and drop

course instead of the paper based process

The Student needs to view their academic history every time and

every where they want instead of waiting the respond from the

Academic Office

Academic Affair staff 1. The Staff of the Academic Affair Staff needs to manage the course information, department information.

2. Easy to use, easy update, easy to modify

Financial Office staff 1. The Staff needs to manage the financial business of the University 2. They would view the Student tuition fee status

Lecturer They could give ideas or comment on the solution for the system’s

development and improvement

Final Document

52

Project objectives

Know business rules

1. In the old paper-based mechanism, the process of registration as follow a. The Students receive the Registration form and register the course for the semester

b. The Registration forms are transferred to the Academic Affair Staff

c. Academic Affair Staff process the Registration Form

d. The Students receive the report from offering course from the Academic Affair Staff

e. If any Student wants to add or drop course(s), the process restarts

2. At each beginning of the semester, the Academic Affair Staffs make the list of course and

provide to each Faculty to distribute to the Students. They also manage the number of

Lecturer, the Department. All is the paper – based process.

3. After receiving the reports from the Academic Affair Staffs, the Students also receive the

financial report from the Finance Office. The Finance Officers have to manage the financial

information status of each student, decide the financial business of each student and make

the report to each student.

System information and/or diagrams

System context: OURS is a part of university management system. It can interact with other

sub-system of university management system such as scheduling system, grading system,

student management system, payment system …

Online university

registration system

University

System

Final Document

53

OURS will be used by students, academic affair staffs, financial office staffs, administrator

with functionalities showed in following diagram.

Final Document

54

Assumptions and dependencies

1. The system will be applied for universities using credit system like International University.

2. The registration information of students is processed by academic affair. And only academic

affair has right to manage and process the registration information.

3. Development team will use J2EE architecture to develop system.

4. Policy for tuition fee payment is using cash and it is managed by financial office.

5. Development team must have at least one 2-hour meeting per week.

6. Development time is 2 months and 10 days

7. Development team must produce the first build before the review 3

8. Each team member must work at least 15 hours per week.

Design and implementation constraint

1. The system will be developed using J2EE technology

2. The system provides the service in two languages Vietnamese and English

Risks

1. All team members need preparation time for midterm, final exam, and other subjects.

2. Phung, Thuc, and Hoang take pre-thesis course.

3. Lack of experiences in software project management, especially in testing, verification,

validation, risks management and changes management exists in the Team.

4. No substitution if any team member cannot continue to contribute to the project. Applying

the project again from the beginning could take development team more time.

5. Development time is limited in 2 months only. Therefore, the pressure is really high.

6. Development team cannot deliver the components when reviewed. Development team

could deliver components of unacceptably low quality, and time must be added to improve

quality.

7. Developing extra functionalities that are not required will extends the schedule.

8. Low motivation and moral reduce productivity.

9. Team member needs extra time to learn unfamiliar tools or techniques.

10. Conflicts among team members’ ideas results in poor performances, more meeting, and

extra rework.

Final Document

55

11. People’s assignments do not match their strengths.

12. Components developed separately cannot be integrated easily, requiring redesign and

rework.

13. Detail reporting could take more development time.

Known future enhancements

1. Pay tuition fee (billing system): The Student can access to a billing system and perform the

transaction online such as transferring money to the Bank account of the University,

receiving the discount money from the University policies. This function would be involved

with the other banking system, authentication and security issue which are out of the scope

of the this development

2. Lecturer Assessment: Initially, the users who can access to the system are Students,

Academic Affair Staffs, and Financial Officer. The Lecturer plays a role as an observer.

However, in the future, the Lecturer can log in to the system to view course, to access to

their homepage in order to make the contact with the Students. Grading system is also

considered in the future.

References

For further information, the reader should examine the Vision and Scope document, the SRS

document.

Open, unresolved issues

Schedule and time table construction are not completed at the recent time

Final Document

56

SOFTWARE REQUIREMENT SPECIFICATION

USE CASE SPECIFICATION

Log in and Log out

Name Use Case: Log in and Log out

Summary This use case allows user to log in to the system to achieve the access permission to perform other functions that are granted to that specific user. It also lets user log out to end his/her session

Rationale The system provides functions such as course registration, financial management just for the specific users (Students, ACADEMIC AFFAIR STAFF…). Therefore, logging in/out helps to distinguish type of user.

Users All users Precondition None.

Basic course of event

This use case begins when a user wants to log in the system to perform desired tasks.

1. The system requests the user to provide his username and password for the authentication.

2. Right after the user submits his username and password, the system checks username and password.

3. If the username and password matches, the system redirects the user to his specific homepage (student, administrator, financial officer).

4. After logging in, the user can log out to end his/her session

Alternatives paths

Authentication Fail In step 4, if the username and password do not match, the system will return the log in homepage with the error message MS001 (see Appendix). The system will allow the user to log in 3 times before it locks the user account and displays an error message MS002.

Not remember password In step 1, the system provides the user another option, call “Not remember password”. The users will use this option to recover their forgotten password by giving the username, answer a security question. Then the system will set the password to a default value. The user can use the password to log in or change the new password.

Account locked In step 3, if the user account is locked, the system notifies the user that the account is locked with the error message MS002.

Final Document

57

Account logging in simultaneously In step 2, if the account is logged by another user, the second user can not log in by that username and password. An error message MS003 will be provided.

Create the security question and answer In step 3, if the user logs in successfully for the first time, the system will check for the security question and answer. If the security question and answer is blank, the system prompts the user to specify the security question and answer.

Update password In step 3, if the user logs in successfully for the first time, the system will ask user to change the default password.

Post Conditions

If the logging in is successful, the system will redirect the user to his specific homepage.

Final Document

58


Name Use Case: Manage Department Information

Summary This use case allows Academic Affair Staff to manage department and faculty information. This includes adding, updating, and deleting department and faculty from the system.

Rationale The Academic Affair Staff needs to manage the department and faculty information online. With the paper – based system, the Staff have to deal with a bunch of paper if he/she wants to add, update or delete one department. Along with this feature, it makes the Staff easier and more convenient to manage the information.

Users Academic Affair Staff

Precondition User logged in the system as the role of Academic Affair Staff.


This use case starts when the Academic Affair Staff wishes to add, update, and/ or delete department information in the system

1. The system requests that the Academic Affair Staff to specify the function he/she would like to perform (add department information, Update department information, or Delete department information).

2. Once the Academic Affair Staff provides the requested information, one of the sub flows is executed. If the Academic Affair Staff selects “Add a Department”, the Add a Department sub flow is executed.

If the Academic Affair Staff selects “Update a Department”, the Update a Department sub flow is executed.

If the Academic Affair Staff selects “Delete a Department”, the Delete a Department sub flow is executed.

Add a Department

1. The system requests that the Academic Affair Staff enter the Department information. This includes:

- Name

- Location

- Description

- Dean

- Faculty

2. Once the Academic Affair Staff provides the requested information and

Final Document

59

confirms, the department is added to the system.

3. The system provides the Academic Affair Staff with a summary of department information newly added.

Update a Department

1. The system requests the Academic Affair Staff to choose a department to modify information.

2. The Academic Affair Staff chooses a department.

3. The system retrieves and displays the department information has been chosen by user.

4. The Academic Affair Staff makes the desired changes to the department information. This includes any of the information specified in the Add a department sub-flow

5. Once the Academic Affair Staff updates the necessary information, the system updates the department record.

Delete a Department

1. The system requests the Academic Affair Staff to choose a department to delete.


3. The system retrieves and displays the department information

4. The system prompts message MS004 to the Academic Affair Staff to confirm the deletion of the Department.

5. The Academic Affair Staff confirms to delete the selected department.

6. The system deletes the selected department from the system.

Alternatives paths

Delete Cancelled If, in the Delete s Department sub-flow, the Academic Affair Staff decides not to delete the Department , the delete operation is cancelled, and the Basic Flow is re-started

Post Conditions

If the use case is successful, the department information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.

Final Document

60


Name Use Case: Manage Lecturer Information

Summary This use case allows the Academic Affair Staff to manage lecturer information in the registration system. This includes adding, updating, deleting, and searching lecturers from the system.

Rationale With the paper – based system, the Academic Affair Staff have to manage a lot of papers. And it is easy to be lost, damaged and difficult to maintain. With the OURS, ACADEMIC AFFAIR STAFFStaff can manage the information easily every time and every where




This use case starts when the Academic Affair Staff wishes to add, update, delete, and/or search lecturer information in the system

1. The system requests the Academic Affair Staff to specify the function he/she would like to perform (either Add a Lecturer, Update a Lecturer, Delete a Lecturer, or Search a Lecturer)

2. Once the Academic Affair Staff provides the requested information, one of the sub-flows is executed If the Academic Affair Staff selected “Add a Lecturer”, the “Add a Lecturer” sub-flow is executed

If the Academic Affair Staff selected “Update a Lecturer”, the “Update a Lecturer” sub-flow is executed

If the Academic Affair Staff selected “Delete a Lecturer”, the “Delete a Lecturer” sub-flow is executed.

Add a Lecturer 1. The system requests that the Academic Affair Staff enter the lecturer

information. This includes:

- Name

- Date of birth

- Cell-phone

- Email

- Faculty

- Degree

2. Once the Academic Affair Staff provides the requested information and

Final Document

61

confirms, the lecturer is added to the system.

3. The system provides the Academic Affair Staff with a summary of lecturer information newly added.

Update a Lecturer 1. The system requests the Academic Affair Staff to choose a department.


3. The system returns a list of lecturers of that department.

4. The Academic Affair Staff chooses a lecturer.

5. The system provides the Academic Affair Staff with a summary of information of selected lecturer.

6. The Academic Affair Staff makes the desired changes to the lecturer information and confirms. This includes any of the information specified in the Add a Lecturer sub-flow.

7. The system prompts message MS005 to the Academic Affair Staff to confirm the deletion of the lecturer.

8. The system updates the lecturer record. Delete a Lecturer

1. The system requests that the Academic Affair Staff choose the department.


3. The system returns a list of lecturers of that department.

4. The Academic Affair Staff chooses a lecturer.

5. The system provides the Academic Affair Staff with a summary of information of selected lecturer.

6. The Academic Affair Staff decides to delete the lecturer whose information currently displayed.

7. The system prompts message MS006 to the Academic Affair Staff to confirm the deletion of the lecturer.

8. The system deletes the lecturer from the system

Alternatives paths

Delete Cancelled If, in the Delete a Lecturer sub-flow, the Academic Affair Staff decides not to delete the lecturer, the delete is cancelled, and the Basic Flow is re-started at the beginning

Update Cancelled

Final Document

62

If, in the Update a Lecturer sub-flow, the Academic Affair Staff decides not to update the lecturer, the update is cancelled, and the Basic Flow is re-started at the beginning

Post Conditions

If the use case was successful, the lecturer information is added, updated, or deleted from the system.

Final Document

63


Name Use Case: Manage Student Information

Summary This use case allows the Academic Affair Staff to manage student information in the registration system. This includes adding, updating, deleting, and searching Students from the system

Rationale The information of a student is various and too difficult to handle with the old paper – based system. With OURS manage student information feature, the ACADEMIC AFFAIR STAFF feels easier and more convenient




This use case starts when the Academic Affair Staff wishes to add, update, delete, and/or search student information in the system

1. The system requests the Academic Affair Staff to specify the function he/she would like to perform (either Add a Student, Update a Student, or Delete a Student)

2. Once the Academic Affair Staff provides the requested information, one of the sub-flows is executed If the Academic Affair Staff selects “Add a Student”, the “Add a Student” sub-flow is executed

If the Academic Affair Staff selects “Update a Student”, the “Update a Student” sub-flow is executed

If the Academic Affair Staff selects “Delete a Student”, the “Delete a Student” sub-flow is executed

If the Academic Affair Staff selects “Search a Student”, the “Search a Student” sub-flow is executed

Add a Student 1. The system requests that the Academic Affair Staff enter the student

information. This includes:

- Student ID

- Name

- Gender

- Date of birth

- Address

- Faculty

Final Document

64

- Priority(a child of dead or wounded soldiers, belong to highland area, or other priority)

- Academic Year

2. Once the Academic Affair Staff provides the requested information and confirmations, the student is added to the system.

3. The system provides the Academic Affair Staff with a summary of information of student newly added.

Update a Student

1. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty & academic duration, academic year & semester & course).

2. The Academic Affair Staff chooses a filter group, then inputs necessary information for the filters, and confirms to search.

3. The system returns a list of student whose information matches the filter’s inputs

4. The Academic Affair Staff chooses the student that he/she wants to update.

5. The system displays the student information

6. The Academic Affair Staff makes the desired changes to the student information. This includes any of the information specified in the Add a Student sub-flow

7. The system prompts message MS007 to the Academic Affair Staff to confirm the updating of the student.

8. The system updates the student information Delete Student(s)



3. The system returns a list of student(s) whose information matches the filter’s inputs

4. The Academic Affair Staff chooses the student(s) that he/she wants to delete.

Final Document

65

5. The system prompts message MS008 to the Academic Affair Staff to confirm the deletion of the student(s).

6. The Academic Affair Staff confirms the deletion.

7. The system deletes the selected student(s). Search Student(s)



3. The system returns a list of student(s) whose information matches the filter’s inputs.

Alternatives paths

Student Not Found In Search a Student sub-flows, if there’s no student whose information matches the filter’s inputs, the system displays the error message MS009. The Academic Affair Staff can then enter different values of the filters or cancel the operation, at which point the use case ends.

Delete Cancelled If, in the Delete a Student sub-flow, the Academic Affair Staff decides not to delete the student, the delete operation is cancelled, and the Basic Flow is re-started.

Update Cancelled If, in the Update a Student sub-flow, the Academic Affair Staff decides not to update the student, the update operation is cancelled, and the Basic Flow is re-started.

Post Conditions

If the use case is successful, the student information is added, updated, or deleted from the system.

Final Document

66

Manage Course Offering

Name Use Case: Manage Course Offering

Summary This use case allows Academic Affairs to monitor course offerings in one semester of specific year.

Rationale Each student receives a list course to register at the beginning of each semester. Using the feature “Manage Course Offering”, an ACADEMIC AFFAIR STAFF can easy to create, update or delete the course list and sooner distribute to the Students within the short time




Use Case is triggered when Academic Affair Staff chooses “Manage offering course” task. The system requires Academic Affair Staff to choose a faculty.

1. Academic Affair Staff chooses a faculty.

2. The system displays current list of course offerings of chosen faculty, each course offering has these information:

- Name of course

- Credits

- Lecturer

- Faculties

3. System requests Academic Affair Staff to specify the function he/she would like to perform : - Create List of course offerings

- Update List of course offerings

4. Once Academic affair staff chooses a function, one of the following sub-flows is executed - If Academic Affair Staff selects “Create list of course offerings”, “Create List of course offerings” sub-flow is executed

- If Academic Affair Staff selects “Update list of course offerings”, “Update List of course offerings” sub-flow is executed

Create list of course offerings 1. The system displays curriculum of the selected faculty.

2. Repeat sub flow “Add an offering course” until Academic Affair Staff completes the list for this faculty

3. Academic Affair Staff confirms his/her selections

Final Document

67

4. The system creates and stores the offering courses list of the selected faculty.

Update list of course offerings 1. The system displays curriculum and offering courses list currently

existing of selected faculty

2. Academic Affair Staff updates a course in this list

If Academic Affair Staff wants to add one or more course, sub flow “Add a course offering” is executed.

If Academic Affair Staff wants to add one or more course, sub flow “Delete a course offering” is executed.

If Academic Affair Staff wants to change lecturer of a specific course, sub flow “Change lecturer” is executed.

3. Academic Affair Staff confirms his/her modification

4. The system updates all changes.

Add a course offering

1. Academic Affair Staff chooses a subject from the curriculum.

2. The system holds the selected subject

3. The system displays list of available lecturers in the department to which the subject belongs.

4. Academic choose a lecturer for selected subject

5. The system adds the selected subject with specific lecturer attached to it into the offering courses list.

Delete a course offering

1. Academic Affair Staff chooses a course offering from the list of course offerings to delete.

2. The system asks user for confirmation.

3. User confirms to delete.

4. The system removes the selected course offering. Change Lecturer

1. Academic Affair Staff chooses a course offering from the list of course offerings to change the lecturer.

2. The system displays list of available lecturers in the department to

Final Document

68

which the subject belongs.

3. Academic choose a lecturer for the selected course offering.

4. The system updates the selected course offering with the new lecturer.

Alternatives paths

No list of course offering In the step 3 of main flow, if this faculty does not have a list of course offering yet, system displays message MS010 and function “Update list of course offering” is not available.

Update canceled If, in the Update list of course offerings sub-flow, the Academic Affair Staff decides not to update anything, the update is cancelled, and the Basic Flow is re-started at the beginning

Post Conditions

If the use case is successful, the offering courses list of a specific faculty will be created or updated.

Final Document

69


Name Use Case: Manage Financial Activities

Summary This use case allows Financial Office Staff to monitor student’s tuition fee. This includes viewing and updating the tuition fee status of students.

Rationale Dealing with number is the task of the Finance Office Staff. The Staffs also have to distribute the financial report to the Students and manage the financial status of each Student. The OURS makes everything easier and more convenient.

Users Financial Office Staff

Precondition User logged in the system as the role of Financial Office Staff.


This use case starts when the Financial Office Staff wishes to view and/or update students’ tuition fee status of one specific student or list of students.

1. The system requests the Financial Office Staff to specify the function he/she would like to perform (either View tuition fee or updating tuition fee status)

2. Once the Financial Office Staff provides the requested information, one of the sub-flows is executed

If the Financial Office Staff selects “View tuition fee”, the “View tuition fee” sub-flow is executed

If the Financial Office Staff selects “Update tuition fee status”, the “Update tuition fee status” sub-flow is executed

View tuition fee 1. The system requests the Academic Affair Staff to choose a filter group

(ID & name, faculty & academic duration, academic year & semester & course).


3. The system returns a list of student(s) whose information matches the filter’s inputs with tuition fee and tuition fee status.

Update tuition fee status


Final Document

70


3. The system returns a list of student whose information matches the filter’s inputs with tuition fee and tuition fee status.

4. The Academic Affair Staff changes tuition fee status of specific student.

5. The system prompts message MS011 to the Academic Affair Staff to confirm the updating of the student.

6. The system updates the student tuition fee status.

Alternatives paths

Student Not Found: In Search a Student sub-flows, if there’s no student whose information matches the filter’s inputs, the system displays the error message MS012. The Academic Affair Staff can then enter different values of the filters or cancel the operation, at which point the use case ends.

Update Cancelled: If, in the Update a Student sub-flow, the Academic Affair Staff decides not to update the student, the update operation is cancelled, and the Basic Flow is re-started.

Post Conditions

If the use case was successful, the student tuition fee is display or student tuition fee status is updated.

Final Document

71


Name Use Case: View Academic History

Summary This use case allows a Student to view his studying progress. The Student can see the courses he has taken as well as the scores and status (passed or failed).

Rationale Every Student wants to view and review his/her grades, GPA and list of course. With the paper - based system, he/she has to request the ACADEMIC AFFAIR STAFF to deliver the transcript contains all above information. In contrast, the Student can easily access to his account and view his/her Academic history online whenever he/she wants.

Users Students

Precondition Users logged in the system as the role of a student.


This use case starts when a student wishes to view his/her academic history.

1. The system requests the student to choose one of these filters:

View All.

View by specific year and semester.

View by passed and failed status.

2. The student chooses a filter.

3. The system displays a list of courses that match the filter.

Alternatives paths

None.

Post Conditions None.

Final Document

72

Register Course

Name Use Case: Register Course

Summary This use case allows a Student to register course offerings in the current semester.

Rationale With old system, the Students have to fill in the Registration forms and hand them to the ACADEMIC AFFAIR STAFF and wait for approvals. The process takes a long time. Therefore, it is significant to reduce the time and make the process shorter. The Students can find it happily with the feature “Register Course” which performs everything online.

Users Students

Precondition Users logged in the system as the role of a student.


This use case starts when a student wishes to register for course offerings or to update his/her existing course schedule.

1. The system retrieves and displays the Student’s current schedule (e.g.; the schedule for the current semester). The schedule may be empty.

2. The student choose “change schedule” in order to begin add/drop course.

3. The system retrieves a list of available course offerings from the Course Catalog System, filters courses that the student does not meet the prerequisite and displays the list to the Student.

4. The Student may update the course selections on the current selection by dropping and adding course offerings. The Student selects the course offerings to add from the list of available course offerings. The Student also deselects any course offerings to drop from the existing schedule. The Student can only select a total of minimum 15 credits and maximum 30 credits.

5. After the Student adds or drop a course, the system recalculate and update total credits, fee and discount.

6. Once the Student indicates that he/her has finished making his/her selections, the system prompt message MS016 to the Student to confirm the submission of the schedule.

7. The Student confirms to continue submitting or cancel to continue add/drop courses.

8. After submitted, the schedule is saved in the system.

Alternatives Course Registration Closed

Final Document

73

paths If, when the use case starts, it is determined that registration for the current semester has been closed, message MS013 is displayed to the Student, and the use case terminates. Students cannot register for course offerings after registration for the current semester has been closed.

Reset changes to a schedule If, while choosing to add/ drop courses, the Student decides to undo all the changes he/her made, the Student then indicates the system that he/her wants to reset changes to the schedule. The system then prompts message MS017 for the student confirmation, the student can agree and either the Basic Flow is re-started at the beginning or cancels reset.

Register more than 30 credits The student has to select less than a total of 30 credits per. If the Student add a course that increase the total credits more than 30, the system will prompt the message MS013 and do not allow the student to add the course to his/her schedule.

Register less than 15 credits The student has to select more than a total of 30 credits per. If the Student drop a course that decrease the total credits to less than 30, the system will prompt the message MS014 and do not allow the student to add the course to his/her schedule.

Post Conditions

If the use case was successful, the student schedule is updated. Otherwise, the system state is unchanged.

Final Document

74


Name Use case: Manage Course Catalogue

Summary This use case allows the Academic Affair Staff to manage Course Catalog information in the registration system. This includes adding, updating, deleting, and searching a course from the course catalog of the university

Rationale The number of courses in the course catalogue of the university is really large. And courses management is a challenging work for Academic Affair Staff if he/she works with paper-based system. Therefore, with the system, he/she will take the advantages of computer-base system to reduce the effort when doing course catalogue management.

User Academic Affair Staff


Basic Flow of Event

This use case starts when the Academic Affair Staff wishes to add, update, delete, and/or search the information of a course in course catalogue.

1. The system requests the Academic Affair Staff to specify the function he/she would like to perform (either Add a course, Search course(s), Update a course, or Delete a course)

2. Once the Academic Affair Staff provides the requested information, one of the sub-flows is executed If the Academic Affair Staff selects “Add a course”, the “Add a course” sub-flow is executed

If the Academic Affair Staff selects “Update a course”, the “Update a course” sub-flow is executed

If the Academic Affair Staff selects “Delete a course”, the “Delete a course” sub-flow is executed

If the Academic Affair Staff selects “Search course(s)”, the “Search course(s)” sub-flow is executed

Add a Course 1. The system requests that the Academic Affair Staff enter the

information of course. This includes:

- Course ID

- Name

- Number of credits

- Faculty

Final Document

75

- Description

2. Once the Academic Affair Staff provides the requested information and confirmations, the course is added to the system.

3. The system provides the Academic Affair Staff with a summary of information of course newly added.

Update a course

1. The system requests the Academic Affair Staff to specify course ID or Course Name that he wants to update.

2. The system displays the information of the selected course.

3. The Academic Affair Staff makes the desired changes to the course information. This includes any of the information specified in the Add a course sub-flow

4. The system prompts the Academic Affair Staff to confirm the updating of the course.

5. The system updates the course information Delete a course

1. The system requests the Academic Affair Staff specify course ID or Course Name

2. The system displays the information of the selected course and asks user to confirm the deletion.

2. The Academic Affair Staff confirms the deletion.

3. The system deletes the selected course. Search course(s)

4. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty, Number of credits).


The system returns a list of course(s) whose information matches the filter’s inputs.

Alternative Paths

Course Not Found In Search course(s) sub-flows, if there’s no course whose information matches the filter’s inputs, the system displays the error message “Course does not exist in the course catalogue”. The Academic Affair Staff can then enter different values of the filters or cancel the operation, at which point the use case ends.

Final Document

76

Delete Cancelled If, in the Delete a course sub-flow, the Academic Affair Staff decides not to delete the course, the delete operation is cancelled, and the Basic Flow is re-started.

Update Cancelled If, in the Update a course sub-flow, the Academic Affair Staff decides not to update the course, the update operation is cancelled, and the Basic Flow is re-started.

Post Condition If the use case is successful, the course information is added, updated, or deleted from course catalogue.

Final Document

77

Manage User Account

Name Use case: Manage User Account

Summary This use case allows the Administrator to manage user account information in the system. This includes creating, updating, deleting, and searching user account(s) in the system

Rationale The university provides each student, academic affair staff, and financial office staff with one account login the system with different rights when using the system.

User Administrator

Precondition User logged in the system as administrator of the system

Basic Flow of Event

This use case starts when the Administrator wishes to create, update, delete, and/or search the information of user account(s).

1. The system requests the Administrator to specify the function he/she would like to perform (either Create an account, Search account(s), Update an account, or Delete an account)

2. Once the Administrator provides the requested information, one of the sub-flows is executed If the Administrator selects “Create an account”, the “Create an account” sub-flow is executed

If the Administrator selects “Update an account”, the “Update an account” sub-flow is executed

If the Administrator selects “Delete an account”, the “Delete an account” sub-flow is executed

If the Administrator selects “Search course(s)”, the “Search course(s)” sub-flow is executed

Create an account 1. The system requests that the Administrator specify the information of

the account. This includes:

- Username

- Role(which can be student, academic affair staff, financial office staff, or admin)

- Description

- Other information will use the default values

o Password: Abcd1234

Final Document

78

o Status: available

2. Once the Administrator provides the requested information and confirmations, the account is added to the system.

3. The system provides the Administrator with a summary of information of the account newly added.

Update an account

1. The system requests the Administrator to specify username he wants to update.

2. The system displays the information of the selected account.

3. The Administrator makes the desired changes to the account information. This includes any of the information specified in the Create an account sub-flow

4. The system prompts the Administrator to confirm the updating of the account.

5. The system updates the account information Delete an account

1. The system requests the Administrator specify username

2. The system displays the information of the selected account and asks user to confirm the deletion.

3. The Administrator confirms the deletion.

4. The system deletes the selected account. Search account(s)

1. The system requests the Administrator to specify username.

2. The system returns the account whose information matches the input username.

Alternative Paths

Account Not Found In Search account(s) sub-flows, if there’s no account whose information matches the input, the system displays the error message “Account does not exist in the system”. The Administrator can then enter different values or cancel the operation, at which point the use case ends.

Delete Cancelled If, in the Delete an account sub-flow, the Administrator decides not to delete the account, the delete operation is cancelled, and the Basic Flow is re-started.

Final Document

79

Update Cancelled If, in the Update an account sub-flow, the Administrator decides not to update the account, the update operation is cancelled, and the Basic Flow is re-started.

Post Condition If the use case is successful, the user account information is added, updated, or deleted from the system.

Final Document

80

Appendix

Message ID Type Context Error Messages Actions

MS001 Info Authentication

Failed Wrong password or username

cannot be found. OK

MS002 Info Account locked Account locked. Please wait for 30

minutes or contact the administrator.

OK

MS003 Info Account being used This account is being used by

another user. OK

MS004 Question Delete a department Are you sure you want to delete

the selected department? OK – Cancel

MS005 Question Update a lecturer Are you sure you want to update the current displayed lecturer?

OK – Cancel

MS006 Question Delete a lecturer Are you sure you want to delete

the selected lecturer? OK – Cancel

MS007 Question Update a student Are you sure you want to update

the modified student? OK – Cancel

MS008 Question Delete a student Are you sure you want to delete

the selected student? OK – Cancel

MS009 Info Student not found The selected student does not

exist OK

MS010 Info No list of course

offering This faculty has no list of course

offering yet Ok

MS011 Question Update tuition fee

status

Are you sure you want to update tuition fee status of current

student? OK – Cancel

MS012 Info Student not found Cannot find the result. OK

Final Document

81

MS013 Info Course Registration

Closed The course registration has been

closed OK

MS014 Info Register more than

30 credits You cannot register more than 30

credits OK

MS015 Info Register less than 30

credits You cannot register less than 30

credits OK

MS016 Question Submit a schedule Are you sure you want to submit

this schedule? OK – Cancel

MS017 Question Reset changes to a

schedule Are you sure you undo all the

changes you have made? OK – Cancel

Final Document

82

FUNCTIONAL REQUIREMENT

Name FR-1: Department & Faculty relationship

Summary There exists department that no student studies in it.

Rationale The concepts of department and faculty are not the same. Please check the glossary part for those concepts.

Requirement A department has at most one faculty. When a department is being added, if it does not have a faculty, it means it has no student, then the value of Faculty is default value “None”. Mathematics Department is an example for department which does not has faculty (all students study mathematics courses but no one study in Mathematics department)

Reference Use-case: Manage Department Information

Name FR-2: Lecturer and department relationship Summary Lecturers are belonged and managed by

department, not faculty Rationale As mentioned in the glossary part that when

we talk about lecturers, we mention to department scope. And when we talk about students, we mention to faculty scope.

Requirement A lecturer must belong to one specific department. If a lecturer does not belong to any department of the university, his department is denoted “General”. Departments do not have faculty: Mathematics , English

Reference Use-case: Manage lecturer

Final Document

83

Name FR-3: Student and faculty relationship

Summary Students are belonged to faculties. It means that students are directly managed by faculties

Rationale As mentioned in the glossary part that when we talk about students, we mention to faculty scope.

Requirement A student must belong to one specific faculty Students can not belong to department because there are departments that have no student such as Mathematics Department, English Department…

Reference Use-Case: Manage Student

Name FR-4: course offering management

Summary Manage offering course including “general” course (belongs to general departments that have no students) and specific course (belongs to departments that have student)

Rationale There are courses that are common courses to many faculties of different departments

Requirement In each semester, university has maximum of opening course is 50 courses. Each course offering can only be taught by one lecturer and belong to one department. A course could be opened for many faculties with the same lecturer such as Courses belonging to “General” departments. For example, Marxist-related courses, Physical training, English…

Reference Use-case: Manage course offering

Final Document

84

Name FR-5: Registration constraints

Summary Student can only register for courses that he can satisfy the requirement of that course

Rationale There are constraints on maximum and minimum number of credits and the prerequisites.

Requirement A student just register any course opened by his/her faculty. In addition, this course has all prerequisites are studied in this student's academic history. Each subject may require the student to finish one or more subjects Student can register maximum 30 credits and minimum 15 credits

Reference Use-case: Register Course

Name FR-6: Discount rate management

Summary Students are in priority will have their tuition fees be reduced with specific rate.

Rationale There are some students are in priority. Therefore their tuition fees are reduced.

Requirement Discount rates are not cumulative. Only the highest discount rate is applied. _ Highland area and Child of Wounded Soldier(3/4 or 4/4): 25% _ Child of Wounded Solider (1/4 or 2/4) or Child of Revolutionary Martyr: 50%

Reference Use-case: Manage financial activities

Name FR-7: Type of credits management

Summary Each kind of credits will have a specific fee Rationale Not all kind of credits have the same fee. For

example English credits and Software Engineering credits have different fees.

Requirement Type A – 42 USD per credit: Academic subjects. Type B – 4.5 USD per credit: Physical education, Marxist-related subjects. Type C – 16 USD per credit: English.

Final Document

85

Reference Use-case: Manage financial activities

Name FR-8: Grade management policy

Summary The system stores the final grade and status of that subject of student only.

Rationale This is not a grading system. Therefore, we do not care all kind of grades such as midterm, homework grades.

Requirement The system only stores the final grade of each course for students. Maximum grade is 100. Grade over 50: passed Grade under 50: failed

Reference Use-Case: View Academic History

Name FR-9: Password constraints

Summary For security, password should have constraints Rationale For easy to recovery password and secure the

user account Requirement The minimum length is 8

The default password is Abcd1234 Reference Use-Case: Login & Logout

Final Document

86

NON-FUNCTIONAL REQUIREMENT

Introduction: The Non-functional Requirements are requirements that are not readily captured in

the use case model. These requirements will apply on OURS and cover all following aspects:

Performance:

1. Support 100 simultaneously users 2. 90% request has response within 10 seconds.

Reliability:

For time-consuming task such as Create Schedule, Register and any other task has response time is greater than 5 seconds, the system should be provide indicated symbol to let user knows that process is going on.

Availability:

System should be supported 24/7 for on line application.

Efficiency:

1. System should be provided at least 1 Mbps bandwidth connection. 2. Database is able to retain volume of data desired by University, not less than 20.000

students in 10 years; with maximum of course list is 500 courses.

Supportability:

Localization: i. Support for the following language must be provided:

a. English

b. Vietnamese

ii. Language could be selectable.

Integrity:

1. User could enter password to login only 3 times, if they fails, this user account will be locked in 30ph: user could not log in the system in an account when this account is locked.

2. At any moment, an account is used only by 1 user.

Portability:

1. System is web application which runs in Internet Explorer 6.0, Firefox 2.0 or above with JavaScript is enabled. System is not guaranteed to operate on any lower vers.ion or other browser.

2. OURS intended to work with a number of customer MySQL 5.0 databases and J2EE servers

Final Document

87

(Glassfish).

Flexibility:

After system is deployed, system could be developed these other functions: 1. Lecturer chooses course to teach

2. Academic affair creates schedule for class

3. Financial staff get document from system for billing

Final Document

88

INSPECTION REPORT

# of issue 11

Review date 11/05/2007

Attendees Read document Time spent preparing Nguyen Duc Quan Y 3hours

Tran Minh Phung Y 2 hours

Le Vu Hoang Y 1.5 hours

Phan Duy Tan Y 2 hours Huynh Da Thuc Y 2 hours

No Section/ page Identified by Issue

1 Manage Course Offering

Tan Department used to manage lecturer, Faculty used to manage student


Phung University has a catalog of all the courses in this university


Quan Write detail steps of change lecturer, remove course

4 Register Course Tan Our system just considers about course offering, not

physical class

5 Register Course Quan Building schedule is too difficult so we don't try to

create schedule

6 Manage Department

Hoang To make SRS simply, we merge use case manage department and manage faculty

7 Login & Logout Thuc Default password is “Abcd1234”

8 Manage Student

Hoang To help people find student effectively, we support filters to users

9 Manage Student

Phung Student has attribute Academic duration to manage

10 Manage Lecturer

Thuc Number of lecturers is small so we do not need support search function

11 Manage Department

Thuc Number of department is small so we do not need support search function

Final Document

89

GLOSSARY

Introduction

This document is used to define terminology specific to the domain problem, 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.

Definitions

The glossary contains the working definitions for the key concepts in the Course Registration

System.

OURS

Online University Registration System

Academic staff

A person working in academic affair and managing academic information (student, lecturer, course

offering, department and faculty)

Finance staff

A person working in finance office and managing finance activities (tuition fee, etc)

Department

All professors belong to a department which plays the same role as the faculty in the aspect of

lecturer. A department has at most 1 faculty.

Faculty

All students belong to a faculty which is responsible for the academic affair of a field of study in the

University

Curriculum

All the courses in a faculty a student studies in university.

Subject

Name of a course opened by university

Final Document

90

Course Offering

A specific course with a lecturer opened in a specific semester offered by Academic affair staff for

some faculties

Prerequisite

A prerequisite of a course is courses a student must finish in order to take this course

Course Catalog

The catalog of all courses offered by the university

Lecturer

A person teaching courses at the university

Student

A person enrolled in courses at the university. A student belongs to one faculty.

Student priority

The background of the student to get discount in tuition fee

Discount rate

The percentage of reduction of tuition fee a student can get for his priority

Grade

The academic result of a particular student for a particular course offering

Schedule

The list of course offering a student has selected to study the current semester.

Tuition fee

A fee student needs to pay for university in a semester.

Credit

A unit to represent the weight of a subject

Academic duration

Planned time for student for study in university

Final Document

91

Academic year

Each academic year in the university consists two semesters, starts from September and ends in

May the following year (Ex: 2007-2008)

Final Document

92

Testing Plan & Test case Document

12/7/2007

Ho Chi Minh National University – International University

Instructor: Phan Viet Hoang

Group 6


Nguyen Duc Quan

Le Vu Hoang

Tran Minh Phung

Phan Duy Tan

Huynh Da Thuc

Date December 7th , 2007

Version 1.0

Status Baseline

Author Team TiHonMumMim

Reviewer Team TiHonMumMim


Final Document

93

Testing Plan & Test case Document

Final Document

94

A- Test Plan

Introduction

Purpose

This document describes the plan for testing the Online University Registration System [OURS]. This Test

Plan document supports the following objectives:

Identify ours project information and its components that should be tested.

List the recommended test requirements (high level).

Recommend and describe the testing strategies.

Identify the required resources, provide an estimate of the test efforts, and detail testing schedule.

List the deliverable elements of the test activities.

Scope

This Test Plan applies to unit test, integration test and system test that will be conducted on the Online

University Registration System [OURS]. It is assumed that unit testing already provided thorough black box

testing through extensive coverage of source code and testing of all module interfaces.

This Test Plan applies to test all requirements of the [OURS] as defined in the Vision and Scope Document,

Use-case specification, and software requirement specification document.

References

Vision and Scope document

Business Plan and SRS document

Review requirement and Design

The following is the updated use case model.

Final Document

95

Review system architecture

From the updated requirement, our team sees that the number of functions the system provides is

too large in comparison with the scope of the system. This brings us to the decision to divide the original

system into many subsystems as follow.

Final Document

96

System architecture with sub-system model

System architecture with layer model

Final Document

97

Features to be tested

We will perform testing on use case specification, functional requirement, and non-functional requirement

of all use cases and functions. They include

o User login and logout

Login

Logout

Reset password

o View Academic History (depend on filter selected by user)

o Register for course

o Manage Department Information

Add a department

Update a department

Delete a department

Viewing information

o Manage Student Information

Add a student

Update a student

Delete a student

Search for student(s) (for viewing or updating or deleting)

o Manage Lecturer Information

Add a lecturer

Update a lecturer

Delete a lecturer

Viewing information

Final Document

98

o Manage Course Catalog

Add a course

Update a course

Delete a course

Search for course(s)

o Manage Offering Courses

Create list of course offering

Update list of course offering

Add a course offering

Delete a course offering

Change lecturer of a course offering

o Manage Financial Activities

View tuition fee information of student(s)

Update tuition fee status of student(s)

o Manage User Account

o Create an account

o Update an account

o Delete an account

o Search for account(s)

The test cases will be separated in later part. Therefore, we do not put the list of test cases here.

Features not to be tested

Because we will test all features of the system we have defined, there is no feature that will not be

tested.

Final Document

99

Approach

Kind of test

The tests below base on the use case specifications, functional requirements, and non-functional

requirements which have been identified as the targets for testing

Besides, we also show the kinds of test which our team intend to perform.

Data and Database Integrity Testing

Data integrity and database integrity test techniques verify that data is being stored by the system in

a manner where the data is not compromised by updating, restoration, or retrieval processing. This type of

testing is intended to uncover design flaws that may result in data corruption, unauthorized data access, lack

of data integrity across multiple tables, and lack of adequate transaction performance. The database, data

files, and the database or data file processes should be tested as a subsystem within the application.

System testing

System testing of software is testing conducted on a complete, integrated system to evaluate the

system's compliance with its specified requirements. They includes the following functions

User login and logout


Register for course




Manage Course Catalog

Manage Offering Courses


Manage User Account

Final Document

100

Performance Testing

Performance Testing covers a broad range of engineering or functional evaluations where a

material, product, or system is not specified by detailed material or component specifications: Rather,

emphasis is on the final measurable performance characteristics.

Load Testing

Load testing is the process of creating demand on a system or device and measuring its response.

Stress Testing

Stress testing is a form of testing that is used to determine the stability of a given system or entity. It

involves testing beyond normal operational capacity, often to a breaking point, in order to observe the

results. Stress testing may have a more specific meaning in certain industries.

Verify system response during maximum student logins.

Volume Testing

Volume Testing belongs to the group of non-functional tests, which are often misunderstood and/or

used interchangeably. Volume testing refers to testing a software application for a certain data volume.

Verify system response when Course Catalog Database at 90% capacity.

Test Strategy

The Test Strategy presents the recommended approach to the testing of the software applications.

The previous section on Test Requirements described what kinds of test will be tested. This part

describes how they will be performed.

The main considerations for the test strategy are the techniques to be used and the criterion for

testing to be completed.

However, before starting the system test (both functional and non-functional requirements testing),

we must perform unit test for each unit of the system (fields, methods, classes, and components) and

make sure that all unit must pass the checklist of unit test.

Checklist of unit test

Verify the input data length specified in the database or in EJB

Verify the input data format specified in each form, classes, and interaction with database

String format

Integer number format

Final Document

101

Email address format

Date format

Special character

Empty field

Null

Test write

Test write null field

Test write read

Test getter setter

Doing this kind of checking help us to decrease the number of simple test cases

Unit testing

According to the system architecture, we have to test all entities, ejb3 session bean, struts actions…

In order to complete this kind of test, we will use JUnit and EJB3Unit as tools for implement and execute the

unit test.

Smoke test

Because the number of use cases and the number of test cases are really large, we cannot demo all of them.

Therefore we will define a smoke test for demonstration.

Our smoke test includes test cases of 3 main use cases of the system:

Login and Logout use case

Manage courses offering user case

Register for courses use case

For the detail of each test case, please reference to the part of test case in later part.

Test Automation

Test automation is the use of software to control the execution of tests, the comparison of actual outcomes

to predicted outcomes, the setting up of test preconditions, and other test control and test reporting

functions.

Final Document

102

All the tools that are used for test automation please reference to the part of tools in later part.

Data and Database Integrity Testing

The database data and database processing should be tested as separate systems. These systems should be

tested without the applications (as the interface to the data). Additional research into the DBMS needs to be

performed to identify the tools / techniques that may exist to support the testing identified below.

Test Objective Ensure Database access methods and processes function properly and

without data corruption.

Technique Invoke each database access method and process, seeding each with valid

and invalid data (or requests for data).

Inspect the database to ensure the data has been populated as intended, all

database events occurred properly, or review the returned data to ensure

that the correct data was retrieved (for the correct reasons)

Completion Criteria All database access methods and processes function as designed and without

any data corruption.

Special Considerations Testing may require a DBMS development environment or drivers to enter or

modify data directly in the databases.

Processes should be invoked manually.

Small or minimally sized databases (limited number of records) should be

used to increase the visibility of any non-acceptable events.

System Testing

Testing of the application should focus on any target requirements that can be traced directly to use cases

(or business functions), and business rules. The goals of these tests are to verify proper data acceptance,

processing, and retrieval, and the appropriate implementation of the business rules. This type of testing is

based upon black box technique, which is, verifying the application (and its internal processes) by interacting

with the application via the GUI and analyzing the output (results). Following is an outline of the testing

recommended for each application.

Test Objective Ensure proper application navigation, data entry, processing, and

retrieval.

Final Document

103

Technique Execute each use case, use-case flow, or function, using valid and

invalid data, to verify the following:

The expected results occur when valid data is used.

The appropriate error / warning messages are displayed when invalid

data is used.

Each business rule is properly applied.

Completion Criteria All planned tests have been executed.

All identified defects have been addressed.

Special Considerations Access to the OURS Server and the existing Course Catalog System is

required.

Performance Testing

Performance testing measures response times, transaction rates, and other time sensitive

requirements. The goal of Performance testing is to verify and validate the performance requirements have

been achieved. Performance testing is usually executed several times, each using a different "background

load" on the system. The initial test should be performed with a "nominal" load, similar to the normal load

experienced (or anticipated) on the target system. A second performance test is running using a peak load.

Additionally, Performance tests can be used to profile and tune a system's performance as a

function of conditions such as workload or hardware configurations.

NOTE: Transactions below refer to "logical business transactions". These transactions are defined as specific

functions that an end user of the system is expected to perform using the application, such as add or modify

a given contract.

Test Objective Validate System Response time for designated transactions or business

functions under a the following two conditions:

- Normal anticipated volume

- Anticipated worse case volume

Technique Use Test Scripts developed for Business Model Testing (System Testing).

Modify data files (to increase the number of transactions) or modify scripts

Final Document

104

Load Testing

Load testing measures subjects the system-under-test to varying workloads to evaluate the system's

ability to continue to function properly under these different workloads. The goal of load testing is to

determine and ensure that the system functions properly beyond the expected maximum workload.

Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and

other time sensitive issues).

to increase the number of iterations each transaction occurs.

Scripts should be run on one machine (best case to benchmark single user,

single transaction) and be repeated with multiple clients (virtual or actual,

see special considerations below).

Completion Criteria Single Transaction / single user: Successful completion of the test scripts

without any failures and within the expected / required time allocation (per

transaction)

Multiple transactions / multiple users: Successful completion of the test

scripts without any failures and within acceptable time allocation.

Special Considerations: Comprehensive performance testing includes having a "background" load

on the server. There are several methods that can be used to perform this,

including:

"Drive transactions" directly to the server, usually in the form of MySQL

calls.

Create "virtual" user load to simulate many (usually several hundred)

clients. Remote Terminal Emulation tools are used to accomplish this load.

This technique can also be used to load the network with "traffic."

Use multiple physical clients, each running test scripts to place a load on

the system.

Performance testing should be performed on a dedicated machine or at a

dedicated time. This permits full control and accurate measurement.

The databases used for Performance testing should be either actual size, or

scaled equally.

Final Document

105

NOTE: Transactions below refer to "logical business transactions". These transactions are defined as specific

functions that an end user of the system is expected to perform using the application, such as add or modify

a given contract.

Test Objective Verify System Response time for designated transactions or

business cases under varying workload conditions.

Technique Use tests developed for Business Cycle Testing.

Modify data files (to increase the number of transactions) or

the tests to increase the number of times each transaction

occurs.

Completion Criteria Multiple transactions / multiple users: Successful completion of

the tests without any failures and within acceptable time

allocation.

Special Considerations Load testing should be performed on a dedicated machine or

at a dedicated time. This permits full control and accurate

measurement.

The databases used for load testing should be either actual

size, or scaled equally.

Stress Testing

Stress testing is intended to find errors due to low resources or competition for resources. Low

memory or disk space may reveal defects in the software that aren't apparent under normal conditions.

Other defects might results from competition for shared resource like database locks or network bandwidth.

Stress testing identifies the peak load the system can handle.

NOTE: References to transactions below refer to logical business transactions.

Test Objective Verify that the system and software function properly and

without error under the following stress conditions:

little or no memory available on the server (RAM)

Maximum (actual or physically capable) number of clients

connected (or simulated)

Multiple users performing the same transactions against the

Final Document

106

same data / accounts

Worst-case transaction volume / mix (see performance testing

above).

NOTES: Stress testing's goal might also be stated as identify

and document the conditions under which the system FAILS to

continue functioning properly.

Technique Use tests developed for Performance Testing.

To test limited resources, tests should be run on single

machine, RAM and DASD on server should be reduced (or

limited).

For remaining stress tests, multiple clients should be used,

running either the same tests or complementary tests to

produce the worst-case transaction volume / mix.

Completion Criteria All planned tests are executed and specified system limits are

reached / exceeded without the software or software failing

(or conditions under which system failure occurs is outside of

the specified conditions).

Special Considerations Stressing the network may require network tools to load the

network with messages / packets.

The DASD used for the system should temporarily be reduced

to restrict the available space for the database to grow.

Synchronization of the simultaneous clients accessing of the

same records / data accounts.

Volume Testing

Volume Testing subjects the software to large amounts of data to determine if limits are reached

that cause the software to fail. Volume testing also identifies the continuous maximum load or volume the

system can handle for a given period. For example, if the software is processing a set of database records to

generate a report, a Volume Test would use a large test database and check that the software behaved

normally and produced the correct report.

Test Objective Verify that the application / system successfully functions

Final Document

107

under the following high volume scenarios:

Maximum (actual or physically capable) number of clients

connected (or simulated) all performing the same, worst case

(performance) business function for an extended period.

Maximum database size has been reached (actual or scaled)

and multiple queries / report transactions are executed

simultaneously.

Technique Use tests developed for Performance Testing.

Multiple clients should be used, either running the same tests

or complementary tests to produce the worst case transaction

volume / mix (see stress test above) for an extended period.

Maximum database size is created (actual, scaled, or filled with

representative data) and multiple clients used to run queries /

report transactions simultaneously for extended periods.

Completion Criteria All planned tests have been executed and specified system

limits are reached / exceeded without the software or software

failing.

Special Considerations What period of time would be considered an acceptable time

for high volume conditions (as noted above)?

Suspension criteria and resumption requirements

Suspension criteria

Three use cases have more than 2 major errors or fours minor errors, then the build is not acceptable and

the testing is suspended.

Resumption requirements

All major errors & and at least 70% of minor errors that have been found in previous iteration are fixed

Final Document

108

Environmental Needs

Tools

Testing tools Tool Version

Unit Testing Junit and EJB3Unit Latest version

Functional requirement testing QuickTest Professional 9.2

Non-functional requirement

testing

AdventNetQEngine 6.0

Software

Documentation tool Microsoft word 2007

Scheduling tool Microsoft project 2007

IDE Netbean 6.0

Web Server Glassfish server 2.0

DBMS MySQL GUI tool 5.0

MySQL 5.0

Design tool Photoshop CS2

Microsoft Express Web Designer

JDK JDK 6.0

Browser Internet Explorer 6.0, 7.0

Firefox, Opera

Operating system Windows XP, Vista, Linux

Vision and Scope Document

109

Hardware

Client

3 laptops

2 desktops

Server Reuse one 24/7 available desktop to simulate the server for testing and

deployment

Schedule

The testing activities and milestones are dependent on the development iterations. The

Construction Phase (in RUP-Rational Unified Process) will be split into 3 iterations. Each iteration

contains a full test cycle of test planning, designing, development, execution, and evaluation.

Refer to the Software Development Plan and the Iteration Plans for the master schedule and

Construction Phase plan that shows the development iterations.

The following table shows the Test Milestones, start date, and end date as planned.

Milestone Task Start Date End Date

Iteration C1: Review 3

Test Planning

Test Design

Test Development

Test Execution

Test Evaluation

9th November 7th December

Iteration C2: Review 4

Test Planning

Test Design

Test Development

Test Execution

Test Evaluation

7th December 28th December


110

Acceptance criteria

Satisfy all features will be tested as above lists. OURS Website can run smoothly. Provide

a product with functions as requirements, help customer how to use the product easily. And

satisfy the following conditions:

Successful completion of all tasks as documented in the test schedule.

Quantity of medium- and low-level defects must be at an acceptable level as determined by the

software testing project team lead.

User interfaces for all features are functionally complete.

Installation documentation and scripts are complete and tested.

Development code reviews are complete and all issues addressed. All high-priority issues have

been resolved.

All outstanding issues pertinent to this release are resolved and closed.

All current code must be under source control, must build cleanly, the build process must be

automated, and the software components must be labeled with correct version numbers in the

version control system.

All high-priority defects are corrected and fully tested prior to release.

All defects that have not been fixed before release have been reviewed by project stakeholders

to confirm that they are acceptable.

The end user experience is at an agreed acceptable level.

Operational procedures have been written for installation, set up, error recovery, and

escalation.

There must be no adverse effects on already deployed systems.

Resources

This section presents the recommended resources for testing the Online University

Registration System, their main responsibilities, and their knowledge or skill set.

Roles and responsibilities

This table shows the staffing assumptions for the test activities.

Worker Specific Responsibilities/Comments


111

Test Manager Provides management oversight

Responsibilities:

Provide technical direction

Acquire appropriate resources

Management reporting

Test Designer Identifies, prioritizes, and implements test cases

Responsibilities:

Generate test plan

Generate Test Suite

Evaluate effectiveness of test effort

System Tester Executes the tests, Responsibilities:

Execute tests

Log results

Recover from errors

Document defects

Test System

Administrator

Ensures test environment and assets are managed

and maintained.

Responsibilities:

Administer test management system

Install / manage worker access to test systems

Database

Administration

Database Manager

Ensures test data (database) environment and

assets are managed and maintained.

Responsibilities:


112

Administer test data (database)

Designer Identifies and defines the operations, attributes,

and associations of the test classes

Responsibilities:

Identifies and defines the test class(es)

Identifies and defines the test packages

Implementer Implements and unit tests the test classes and test

packages

Responsibilities:

Creates the test classes and packages implemented

in the Test Suite.

The following table sets forth the system resources for the testing the Online University

Registration System.

System Resources

Resource Description

OURS Server Server for simulating the

environment of real OURS system

Course Catalog Database Simulated database

2 Remote PCs (with internet

access)

PCs for connecting to OURS via

internet


113

2 Local PCs (connected via LAN) Local network computers

Test Development PC's - 2

Load Simulator Simulator for load and

performance test

B- Test Case

In this part, we only provide test cases for all use cases defined in original requirement. We will

complete all test cases and use case specification of 2 new use cases have been added later in

the final review.

Unit testing

Again, we use JUnit and EJB3Unit for unit testing. To be noticed that EJB3Unit is really different

from JUnit or NUnit. In JUnit and NUnit, we have to give the input and the output so that these

tools can know how to check the result and notify us whether the unit is passed or not.

However, with EJB3Unit, if we test the entities, we are not required to provide the input and the

output because the EJB3Unit (an extension of JUnit) automatic provide a random data to check

the result our entities. And all the cases we need to check are as below checklist:

Verify the input data length specified in the database or in EJB. The EJB3Unit will can collect

information about the database basing on the entities and check the length. For example, the

student name’s length is specified is 50, then the EJB3Unit will generate data with length is 50,

greater than 50, and less than 50 to check all cases that can happen. And the case that is passed

is the case with length 50. Other cases are failed.

That is the reason while we do not need to write too much test case in this part. However, if the

team is required, we will do it in the review 4.

Other kinds of checks will be showed below:

Verify the input data format specified in each form, classes, and interaction with database

String format: only accept string, not number format, or mixed (string and number)

format…

Integer number format: only accept integer number format, not string format, or mixed

format…


114

Email address format: only valid email address is accepted, other string patterns are not

accepted

Date format: only date format is accepted, others are not accepted

Special character: not use special character. Special character

Empty field: empty field is not accepted.

Null: not allowed using null

Test write: test writing operation to database check whether we can write data to

database or not

Test write null field: not allow write null data to our system database

Test write read: test reading and writing data with relationships and constraints

Test getter setter: test whether get and set methods of each entity

For further information about EJB3Unit and how it work, please contact with our team. This is

due to the fact that it is a brand new tool introduced after EJB3.0 is defined. And it change the

way J2EE developers do the unit test.


115

Test Cases of Log in and Log out Use Case

User logs in successfully with valid username and password

Name Test case: User logs in successfully with valid username and password

Requirement The user is logged in correctly after providing correct username and

password

Preconditions The user is at the homepage or the log in page

Steps 1. Provide valid username in the username textbox

2. Provide valid password in the password textbox

3. Click on log in button

Expected results The user is redirected to the specific homepage of that user

Fail to login the system when providing invalid username

Name Test case: Fail to login the system when providing invalid username

Requirement The user is not logged in when providing invalid username


Steps 1. Provide invalid username in the username textbox

2. Provide password in the password textbox or let password field be empty


Expected results The user is redirected to the error page with a warning “You have provided invalid

username or invalid password”

Fail to login the system when providing username or password

containing special character(s)

Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and

numeric (0-9) space characters.

Name Test case: Fail to login the system when providing username or password containing


116

special character(s)

Requirement The user is not logged in when providing username or password containing special

character(s).


Steps 1. Provide username containing special character(s) in the username textbox

or/and

2. Provide password containing special character(s) in the password textbox or

let password field be empty


Expected results The user is redirected to the error page with a warning “Username and Password

cannot contain special character(s)”

Fail to login the system when providing valid username and invalid

password

Name Test case: Fail to login the system when providing valid username and invalid

password

Requirement The user is not logged in when providing valid username and invalid password



2. Provide invalid password in the password textbox




Fail to login the system when providing empty username

Name Test case: Fail to login the system when providing empty username

Requirement The user is not logged in when providing empty username



117

Steps 1. Provide empty username in the username textbox



Expected results The user is redirected to the error page with a warning “You must provide both

username and password”

Fail to login the system when providing valid username and empty

password

Name Test case: Fail to login the system when providing valid username and empty

password

Requirement The user is not logged in when providing valid username and empty password



2. Provide empty password in the password textbox




User account is locked after failing to log in 3 times

Name Test case: User account is locked after failing to log in 3 times

Requirement User account is locked after failing to log in 3 times with a specific username


Steps 1. Provide valid username in the username textbox or/and

2. Provide invalid or empty password in the password textbox


4. Repeat above process for 3 times




118

After the 3rd time, the user account with given user name is locked out and a

warning is issued “Account locked. Please wait for 30 minutes or contact the

administrator”

User logs in the system using an account is being used by another

user

Name Test case: User logs in the system using an account is being used by another user

Requirement User CAN NOT log in the system using account is being used by another user

Preconditions A given account is being used by user 1

Steps 1. User 2 provides username of user 1 exactly

2. User 2 provides password of user 1 exactly


Expected results User 2 is redirected to the error page with a warning “This account is being used by

another user”

User logs in the system using an account is being locked

Name Test case: User logs in the system using an account is being locked

Requirement User CAN NOT log in the system using account is being locked

Preconditions A given account is being locked by logging in fail 3 times

Steps 1. Provides username of given account being locked

2. Provide password of given account being locked


Expected results User is redirected to the error page with a warning “This account is being locked.

Please wait for 30 minutes or contact the administrator”

Change password successfully

Name Test case: Change password successfully

Requirement The user wants to update password


119

Fail to change password when old or new or confirmed password is

empty

Fail to change password when old password is incorrect

All old and new passwords must be provided

Preconditions The user clicks on the “change password”

The webpage that allows user to change password is displayed

Steps 1. Enter old password

2. Enter new password

3. Enter confirmed password

4. Click on the Recovery password button

Expected results The old password is changed into new password

Name Test case: Fail to change password

Requirement Try to change password when old or new or confirmed password is not input



Steps 1. Let old password empty or/and

2. Let new password empty or/and

3. Let confirmed password empty or/and


Expected results Notify user about empty fields


Requirement Try to change password when providing incorrect old password



120

Recover the password successfully

Fail to reset password when inputting wrong answer for the security

question


Steps 1. Enter wrong password

2. Enter new password empty

3. Enter confirmed password empty


Expected results Notify user that the current password is wrong

Name Test case: Recover the password successfully

Requirement The user lost or forget the password and wants to reset the password

Input right answer

Preconditions The user clicks on the “Forget password”

The system warns the user about recovering the password

Steps 1. Specify the answer for the security question in the text box


Expected results The system issues the message indicates the password has been reset to the default

password “Abcd1234” and warns the user to change their password for the next log

in

The password is reset to the default password “Abcd1234”

The system redirects the user to the log in page

Name Test case: Fail to reset password when inputting wrong answer for the security

question

Requirement The user lost or forget the password and wants to reset password


121

Fail to reset password when inputting answer containing special

character(s) for the security question



Input wrong answer



Steps 1. Specify the wrong answer of the security question in the text box


Expected results The system issues the message “The answer is not correct”

The system redirects the user to the recover password page to choose another

question or answer the selected again

Name Test case: Fail to reset password when inputting answer containing special

characters for the security question


The answer contains special characters



Steps 1. Specify the answer containing special character(s) for the security question

in the text box


Expected results The system issues the message “The answer cannot contain special character(s)”




122

Fail to reset password when inputting empty answer for the security

question

Test Cases of Manage Department Information Use case

Add a department with valid information successfully

Name Test case: Add a department with valid information successfully

Requirement All fields are filled with valid data

Preconditions The webpage that allows user to input information of a department is displayed

Steps 1. Provide department’s name in the name textbox

2. Provide department’s location in the location textbox

3. Provide department’s dean in the dean textbox

4. Provide faculty information that the department has

5. Provide department description in the description text area

6. Click on add button

Name Test case: Fail to reset password when inputting empty answer for the security

question


Let answer be empty



Steps 1. Leave the answer text box blank


Expected results The system issues the message “The answer cannot be empty”




123

Expected results 1. The department is added to the system

2. The summary of department has been added to the system is displayed

Fail to add a department with name that already exists in the system

Fail to add a department when one or some or all fields are empty

Name Test case: Fail to add a department with name that already exists in the system

Requirement All fields are filled with data


Steps 1. Provide department’s name (which already exist in the system) in the name

textbox






Expected results 1. The department is NOT added to the system

2. The user is redirected to the error page with a warning “ Fail to add the

department to the system. The name of the department that you have provided

already exists in the system”

Name Test case: Fail to add a department when one or some or all fields are empty

Requirement NOT all fields are filled with data


Steps 1. Provide empty department’s name in the name textbox or/and

2. Provide empty department’s location in the location textbox or/and

3. Provide empty department’s dean in the dean textbox or/and


124

Fail to add a department when inputting special character(s) to one

or some or all fields

Special Characters: special characters are characters which are not the alphabet (A – Z, a-z)and


4. Provide empty faculty information that the department has or/and

5. Provide department description in the description text area or/and



2. The user is redirected to the error page with a warning “Fail to add the

department to the system. You must provide all information”

Name Test case: Fail to add a department when inputting special character(s) to one or

some or all fields



Steps 1. Provide department’s name containing special character(s) in the name

textbox or/and

2. Provide department’s location containing special character(s) in the location

textbox or/and

3. Provide department’s dean containing special character(s) in the dean

textbox or/and

4. Provide faculty information containing special character(s) or/and

5. Provide department description containing special character(s) in the

description text area or/and




department to the system. Some fields contains special character(s)”


125

Update a department with valid information successfully

Name Test case: Update a department with valid information successfully


Preconditions The webpage that allows user to update information of a department is displayed

Steps 1. Provide department’s name in the name textbox or/and

2. Provide department’s location in the location textbox or/and

3. Provide department’s dean in the dean textbox or/and

4. Provide faculty information that the department has or/and



Expected results 1. The department is updated in the system

2. The summary of department has been updated is displayed

Fail to update a department with name that already exists in the

system

Name Test case: Fail to update a department with name that already exists in the system




textbox or/and







126

Fail to update a department when one or some or all fields are

empty

Expected results 1. The department is NOT updated in the system

2. The user is redirected to the error page with a warning “ Fail to update the

department in the system. The name of the department that you have provided


Name Test case: Fail to update a department when one or some or all fields are empty










2. The user is redirected to the error page with a warning “Fail to update the

department in the system. You must provide all information”


127

Fail to update a department when inputting special character(s) to

one or some or all fields


numeric (0-9) and space characters.

Update cancel

Name Test case: Fail to update a department when inputting special character(s) to one or

some or all fields




textbox or/and


textbox or/and


textbox or/and







department in the system. Some fields contains special character(s)”

Name Test case: Update cancel

Requirement When user decides to cancel updating, the system must allow him/her to stop the

operation



128

Delete a department

Delete cancel

Steps Click on add button

Expected results The department is NOT updated in the system

User is redirected to his/her main page

Name Test case: Delete a department

Requirement When user decides to delete the selected department, the system removes that

department from the system

Preconditions The webpage that allows user to delete information of a department is displayed

Steps 1. User chooses a department to delete from a drop down list.

2. Verify that the system retrieves and displays the department information for

user and prompts message MS004 to the Academic Affair Staff to confirm

the deletion of the Department.

3. User confirms to delete the selected department by clicking on delete

button.

Expected results The system deletes the selected department from the system

Name Test case: Delete cancel

Requirement When user decides to cancel deletion, the system allows user to cancel the operation






3. User click on cancel button.


129

Test Cases of Manage Lecturer Information use case

Add a lecturer with valid information successfully

Name Test case: Add a lecturer with valid information successfully


Preconditions The webpage that allows user to input information of a lecturer is displayed

Steps 1. Provide lecturer’s name in the name textbox

2. Choose lecturer’s date of birth in the calendar

3. Provide lecturer’s cell-phone number in the cell-phone textbox

4. Provide lecturer’s email address in the email textbox

5. Provide lecturer’s department where that lecturer belongs in the

department textbox

6. Provide lecturer’s degree in the degree textbox


Expected results 1. The lecturer is added to the system

2. The summary of lecturer’s information has been added to the system is displayed


Expected results The selected department is NOT deleted from the system





Steps 1. Provide empty lecturer’s name in the name textbox or/and


130

Fail to add a lecturer when inputting special character(s) to one or

some or all fields



2. Choose empty lecturer’s date of birth in the calendar or/and

3. Provide empty lecturer’s cell-phone number in the cell-phone textbox or/and

4. Provide empty lecturer’s email address in the email textbox or/and

5. Provide empty lecturer’s department where that lecturer belongs in the

department textbox or/and

6. Provide empty lecturer’s degree in the degree textbox or/and


Expected results 1. The lecturer is NOT added to the system

2. The user is redirected to the error page with a warning “Fail to add the lecturer to

the system. You must provide all information”

Name Test case: Fail to add a lecturer when inputting special character(s) to one or some or

all fields



Steps 1. Provide lecturer’s name containing special character(s) the name textbox

or/and

2. Choose lecturer’s date of birth in the calendar or/and

3. Provide lecturer’s cell-phone number containing special character(s) in the

cell-phone textbox or/and

4. Provide lecturer’s email address containing special character(s) in the email

textbox or/and

5. Provide lecturer’s department where that lecturer belongs, containing

special character(s), in the department textbox or/and


131

Look for a lecturer

Name Test case: Look for a lecturer

Requirement When user wants to update or delete a lecturer, he/she has to look for information

of the lecturer he/she wants to delete or modify information.

Preconditions The webpage that allows user to look for information of a lecturer is displayed. It can

be update or delete page.

Steps 1. User chooses the department where the lecturer belongs

2. Verify that the system retrieves and displays the list of lecturers of that

department

3. User choose a lecturer from the list

4. Verify that the summary of information of selected lecturer is displayed

Expected results 1. Information of the select lecturer is displayed

Update a lecturer with valid information successfully

Name Test case: Update a lecturer with valid information successfully


Preconditions The webpage that allows user to update information of a lecturer is displayed. (To be

noted that we have test case for looking for lecturer above already. There’s no need

to repeat it here.)

Steps 1. Provide lecturer’s name in the name textbox or/and


3. Provide lecturer’s cell-phone number in the cell-phone textbox or/and

6. Provide lecturer’s degree containing special character(s) in the degree

textbox or/and


Expected results 1. The lecturer is NOT added to the system

2. The user is redirected to the error page with a warning “Fail to add the lecturer to

the system. Some fields contains special character(s)”


132

4. Provide lecturer’s email address in the email textbox or/and

5. Provide lecturer’s department where that lecturer belongs in the


6. Provide lecturer’s degree in the degree textbox or/and


Expected results 1. The lecturer is updated in the system

2. The summary of the lecturer has been updated is displayed


133

Fail to update a lecturer when one or some or all fields are empty

Fail to update a lecturer information when inputting special

character(s) to one or some or all fields



Name Test case: : Fail to update a lecturer when one or some or all fields are empty


Preconditions The webpage that allows user to update information of a lecturer is displayed.(To be


to repeat it here.)

Steps 1. Provide empty lecturer’s name in the name textbox or/and


3. Provide empty lecturer’s cell-phone number in the cell-phone textbox or/and

4. Provide empty lecturer’s email address in the email textbox or/and

5. Provide empty lecturer’s department where that lecturer belongs in the


6. Provide empty lecturer’s degree in the degree textbox or/and


Expected results 1. The lecturer is NOT updated in the system


lecturer in the system. You must provide all information”

Name Test case: Fail to update a lecturer information when inputting special character(s) to






134

Update cancel

to repeat it here.)

Steps 1. Provide empty lecturer’s name containing special character(s) in the name

textbox or/and


3. Provide empty lecturer’s cell-phone number containing special character(s)

in the cell-phone textbox or/and

4. Provide empty lecturer’s email address containing special character(s) in the

email textbox or/and

5. Provide empty lecturer’s department where that lecturer belongs, containing

special character(s) in the department textbox or/and

6. Provide empty lecturer’s degree containing special character(s) in the degree

textbox


Expected results 1. The lecturer is NOT updated in the system


lecturer in the system. Some fields contains special character(s)”



operation



to repeat it here.)

Steps Click on cancel button

Expected results The lecturer is NOT updated in the system



135

Delete a lecturer

Delete cancel

Name Test case: Delete a lecturer

Requirement When user decides to delete the selected lecturer, the system removes that lecturer

from the system

Preconditions The webpage that allows user to delete information of a lecturer is displayed. (To be


to repeat it here.)

Steps Click on delete button

Expected results The system deletes the selected lecturer from the system




Preconditions The webpage that allows user to delete information of a lecturer is displayed. (To be


to repeat it here.)


Expected results The selected lecturer is NOT deleted from the system



136

Test Cases of Manage Student Information Use Case

Add a student with valid information successfully

Name Test case: Add a student with valid information successfully


Preconditions The webpage that allows user to input information of a student is displayed

Steps 1. Provide student’s name in the name textbox

2. Provide student’s ID in the ID textbox

3. Choose student’s faculty in the list of faculty

4. Choose student’s academic duration in the range list

5. Choose student’s academic year in the list

6. Choose semester of this academic year.

7. Choose course of this semester.


Expected results 1. The student is added to the system

2. The summary of student’s information has been added to the system is displayed

Fail to add a student when one or some or all fields are empty

Name Test case: Fail to add a student when one or some or all fields are empty


Preconditions The webpage that allows user to input information of a student is displayed

Steps 1. Provide empty student’s name in the name textbox or/and

2. Provide empty student’s ID in the ID textbox or/and

3. Choose empty student’s faculty in the list of faculty or/and


137

Fail to add a student when inputting special character(s) to one or

some or all fields



4. Choose empty student’s academic duration in the range list or/and

5. Choose empty student’s academic year in the list or/and

6. Choose empty semester of this academic year or/and

7. Choose empty course of this semester or/and


Expected results 1. The student is NOT added to the system

2. The user is redirected to the error page with a warning “Fail to add the student to

the system. You must provide all information”

Name Test case: Fail to add a student when inputting special character(s) to one or some or

all fields



Steps 1. Provide student’s name containing special character(s) the name textbox

or/and

2. Provide student’s ID containing special character(s) in the ID textbox or/and

3. Choose student’s faculty in the list of faculty or/and

4. Choose student’s academic duration in the range list or/and

5. Choose student’s academic year in the list or/and

6. Choose semester of this academic year or/and

7. Choose course of this semester or/and



138

Search student by student ID or/and by student name

Fail to search student by student ID or/and by student name when

providing invalid student ID or/and student name

Expected results 1. The student is NOT added to the system

2. The user is redirected to the error page with a warning “Fail to add the student to

the system. Some fields contains special character(s)”

Name Test case: Search student by student ID or/and by student name

Requirement User wants to find information of a specific student with student’s ID or list of

students with given name.

Preconditions The webpage allows user to find students is displayed

Steps 1. Chooses ID and Name filter from the filter drop down list

2. Provide an ID in the ID textbox or/and

3. Provide a name in the name textbox

4. Click on search button

Expected results The information of student with given ID or a list of student(s) with given name is

displayed

Name Test case: Fail to search student by student ID or/and by student name when


Requirement User wants to find information of student whose ID or/and name does not exist in

the system, then the system must notify the user about this



2. Provide an invalid ID in the ID textbox or/and

3. Provide a invalid name in the name textbox



139

Fail to search student by student ID or/and by student name when

providing empty student ID or/and student name

Search student by faculty and academic duration

Expected results The user is redirected to the error page with a warning “The desired student is not

found”

Name Test case: Fail to search student by student ID or/and by student name when


Requirement User wants to find information of a specific student’s ID or list of students with given

name.



2. Provide an empty ID in the ID textbox or/and

3. Provide an empty name in the name textbox


Expected results The user is redirected to the error page with a warning “You must provide an ID

or/and student name”

Name Test case: Search student by faculty and academic duration

Requirement User wants to view tuition fee information of students of a specific faculty with a

specific academic duration

Preconditions The webpage allows user to view tuition fee of students is displayed

Steps 1. Chooses faculty and academic duration filter from the filter drop down list

2. Choose a faculty from the drop down list


140

3. Choose an academic duration from drop down list


Expected results The information of students of selected faculty with specific academic duration


141

Search student by academic year, semester, and course

Update a student with valid information successfully

Name Test case: Update a student with valid information successfully


Preconditions The webpage that allows user to update information of a student is displayed. (To be

noted that we have test cases searching for student above already. There’s no need

to repeat it here)

Steps 1. Provide student’s name in the name textbox or/and

2. Provide student’s ID in the ID textbox or/and






Name Test case: Search student by academic year, semester, and course

Requirement User wants to find information of students in a specific academic year and/or

semester and/or course


Steps 1. Chooses academic year, semester, and course filter from the filter drop

down list

2. Choose a academic year from the academic year drop down list or/and

3. Choose a semester from the semester drop down list or/and

4. Choose a course from the course drop down list


Expected results The information of students of selected academic year and/or semester and/or

course is displayed


142

8. Click on update button

Expected results 1. The student is updated in the system

2. The summary of the student has been updated is displayed

Fail to update a student when one or some or all fields are empty

Fail to update a student when inputting special character(s) to one




Name Test case: Fail to update a student when one or some or all fields are empty


Preconditions The webpage that allows user to update information of a student is displayed (To be


to repeat it here)









Expected results 1. The student is NOT updated in the system

2. The user is redirected to the error page with a warning “Fail to update the student

in the system. You must provide all information”


143

Update is canceled

Name Test case: Fail to update a student information when inputting special character(s) to





to repeat it here)









Expected results 1. The student is NOT updated in the system

2. The user is redirected to the error page with a warning “Fail to update the student

in the system. Some fields contains special character(s)”

Name Test case: Update is canceled


operation



to repeat it here.)


Expected results The student is NOT updated in the system


144

Delete a student

Delete is canceled

User is redirected to his/her main pages

Name Test case: Delete a student

Requirement When user decides to delete the selected student, the system removes that student

from the system

Preconditions The webpage that allows user to delete information of a student is displayed. (To be


to repeat it here.)


Expected results The system deletes the selected student from the system


Name Test case: Delete is canceled


Preconditions The webpage that allows user to delete information of a student is displayed. (To be


to repeat it here)


Expected results The selected student is NOT deleted from the system



145

Test Cases of Manage Course Offering Use Case

Create list of courses offering successfully

Update the list of course offering

Name Test case: Create list of courses offering successfully

Requirement List of courses offering does not exist yet

Academic affair staff wants to create new list course offering

Preconditions The user must log in as the Academic Affair Staff

The webpage that allows user to create list of courses offering is displayed

Steps 1. Click on the button Manage Course Offering

2. Click on the button Create a list of course offering

3. Click on the drop down list to choose the desired faculty

4. Click on the check box to choose the subject which is selected to offer

5. Click on the drop down list to choose the lecturers for the selected courses

6. Click on the Submit button to create the list of course offering for the

selected faculty

7. Click on the OK button to confirm the operation

Expected results The new list of courses offering is created

The system displayed the list of course offering that has been created

The system redirects to the Manage Course Offering page

Name Test case: Update the list of course offering

Requirement The list of courses offering exists in the system

Academic affair staff wants to update list of courses offering



146

Cancel during the Create list of course offering operation



2. Click on the button Update list of course offering


4. Check or uncheck the check box of each course to change the list of course

offering

5. Change the lecturer for each course (if desired)

6. Click on the Update button


Expected results The confirmation displayed

The list of course offering is updated with the changes of the user

The updated list of course offering is displayed after the operation completed

Name Test case: Cancel during the Create list of course offering operation

Requirement Academic affair staff is being in the creating list of courses offering process.


User is being in the creating list of courses offering process







selected faculty


147

Cancel during the Update list of course offering operation

Fail to create an empty list of course offering

7. Click on the Cancel button

Expected results No list of course offering is created


Name Test case: Cancel during the Update list of course offering operation

Requirement Academic affair wants to cancel the updating list of courses offering process







offering



7. Click on the Cancel button to confirm the operation

Expected results List of courses offering is not updated


Name Test case: Fail to create an empty list of course offering


148

Update list of course offering while there’s no list of course offering

for specific faculty

Requirement Academic affair tries to create an empty list of courses offering or creates an empty

list of courses offering by accident






4. Don’t click any check box in order not to select any course



selected faculty


Expected results No empty list is created

The system issued warning about the empty list of course offering

The system redirects to the Create list of course offering and let the user to create

the non – empty list

Name Test case: Update list of course offering while there’s no list of course offering for

specific faculty

Requirement Academic affair staff tries to update list of courses offering while has not been

created. Then the system must notify him/her about the unavailable status of list of

courses offering.

Preconditions 1. The user must log in as the Academic Affair Staff

2. The selected faculty has no list of course offering



149



Expected results A warning is displayed “There’s no list of course offering in this faculty. Cannot

update”


150

Test Cases of Manage Financial Activities Use Case

View tuition fee by student ID or/and by student name

Fail to view tuition fee by student ID or/and by student name when


Name Test case: View tuition fee by student ID or/and by student name

Requirement User wants to view tuition fee information of a specific student or list of students

with given name.






Expected results The tuition fee information of student with given ID or student(s) with given name is

displayed

Name Test case: Fail to view tuition fee by student ID or/and by student name when


Requirement User wants to view tuition fee information of student whose ID or/and name does

not exist in the system, then the system must notify the user about this



2. Provide an invalid ID in the ID textbox or/and

3. Provide a invalid name in the name textbox


Expected results The user is redirected to the error page with a warning “The desired student is not


151

Fail to view tuition fee by student ID or/and by student name when


View tuition fee by faculty or/and by academic duration

found”

Name Test case: Fail to view tuition fee by student ID or/and by student name when


Requirement User wants to view tuition fee information of a specific student or list of students

with given name.



2. Provide an empty ID in the ID textbox or/and

3. Provide a empty name in the name textbox



or/and student name”

Name Test case: View tuition fee by faculty or/and by academic duration

Requirement User wants to view tuition fee information of students of a specific faculty with a

specific academic duration


Steps 1. Chooses faculty and academic duration filter from the filter drop down list


3. Choose a academic duration from drop down list


Expected results The tuition fee information of students of selected faculty with specific academic


152

View tuition fee by academic year, semester, and course

Update tuition fee status of a student

duration

Name Test case: View tuition fee by academic year, semester, and course

Requirement User wants to view tuition fee information of students in a specific academic year

and/or semester and/or course


Steps 1. Chooses academic year, semester, and course filter from the filter drop

down list





Expected results The tuition fee information of students of selected academic year and/or semester

and/or course is displayed

Name Test case: Update tuition fee status of a student

Requirement User wants to update the tuition fee status of students after he/she pays the tuition

fee. User wants to update tuition fee status of student that user has update wrongly.

Preconditions The webpage allows user to update the tuition fee status of student is

displayed.(Because we have the test cases for filtering student to find the student(s)

above, we do not need to repeat steps of filtering here). And list of students with

tuition fee status is displayed.

Steps 1. Choose a student from the list

2. Change status of tuition fee of that student by choose tuition fee status from


153

Test Cases of View Academic History Use Case

View academic history successfully

Name Test case: Verify View Academic History

Requirement FR- 8 Grade management policy, UC - View Academic History

Preconditions The testing plan document is loaded.

Steps 1. Assume that we are in View Academic History function of the

system.

2. Choose a filter group: View All, View by specific year and semester,


3. One filter is chosen.

4. Click View button.

Expected results The system displays a list of courses that match the filter.

Academic history of a student is display.

Verify that all these information match with FR-8 information.

View all course have taken history.

the stats drop down list

3. Click on submit button

Expected results Tuition fee status of selected student is changed and the system notify the user.

Name Test case: View all courses have taken history


154

View by specific year and semester.


Requirement Student wants to view all courses information.

Preconditions The webpage allows student to view academic history

Steps 1. Choose “All” filter from drop down list.

2. Click on “View” button

Expected results The information of all courses he/she has taken is displayed.

Name Test case: View by specific year and semester

Requirement Student wants to view all courses information of specific year or/and semester.

Preconditions The webpage allows student to view academic history.

Steps 1. Choose “Specific year and Semester” filter from drop down list.



Name Test case: View by specific year and semester

Requirement Student wants to view all courses information of passed and failed status.

Preconditions The webpage allows student to view academic history

Steps 1. Choose “passed and failed status” filter from drop down list.




155

Test Cases of Register Course Use Case

We will filter the prerequisites courses before showing the list of courses that a specific student

can register. Therefore, that student can register any course in the list of courses offering that

student can see.

Fail to register more than 30 credits

Fail to register less than 15 credits

Name Test case: Fail to register more than 30 credits

Requirement All the courses he/she wants to register has been checked

Total number of credits is greater than 30

Preconditions The webpage allows user to register for courses is displayed

Steps 1. Click register course offering button

2. Select courses from list of courses offering by checking the checkbox of the

courses offering

3. Repeat step 2 until the total number of credits is greater than 30

4. Click on the Register button

Expected results The system prompts the user with a warning message “You are not allowed to

register more than 30 credits”

Name Test case: Fail to register less than 15 credits


Total number of credits is less than 15





156

Register for courses successfully

Name Test case: Register for courses successfully

Requirement Student registers for courses to create his/her schedule (please see the

definition of SCHEDULE in the glossary part)

That student does not have schedule yet

The total number of credits is less than or equal to 30 and greater than or

equal to 15

Preconditions The webpage allows student to register for courses is displayed

Steps 1. Click register course offering button.

2. Select courses offering from a list of available course offerings of this

student that the system displays.

3. Repeat step 2 and make sure that the total of credits is less than or

equal to 30 and greater than or equal to 15.

4. Click the submit button

Expected results The schedule of that student is created in the system.

List of course offering will be shown on the schedule of this student.

courses offering

3. Repeat step 2 until but make sure that the total number of credits is less

than 15



register less than 15 credits”


157

Update the existing schedule successfully

Name Test case: update the existing schedule successfully

Requirement Student has his/her schedule already (please see the definition of SCHEDULE

in the glossary part)

That student wants to modify his/her schedule


equal to 15


Steps 1. Click the update schedule button.

2. Check some more courses that he/she wants to register and/or

3. Uncheck some courses that he/she does not want to register

4. Repeat step 2 or/and 3 if needed and make sure that The total

number of credits is less than or equal to 30 and greater than or equal

to 15

5. Click the update button

Expected

results

The schedule is updated in the system.

Updated list of course offering will be shown on the schedule of this student.

Test Cases of Manage Course Catalogue Use Case

Add new course to course catalogue successfully

Name Test case: Add new course to course catalogue successfully

Requirement All fields of course information are filled with valid information

Preconditions The webpage that allows user to input information of a course is displayed


158

Steps 1. Provide course’s ID in the ID textbox

2. Provide course’s Name in the name textbox

3. Provide number of credits of the course in the credit textbox

4. Choose the faculty of the department where the course belongs from

dropdown list

5. Provide the description of the course in the description text area.


Expected

results

1. The course is added to the system

2. The summary of course’s information has been added to the system is

displayed

Fail to add a course when one or some or all fields are empty

Name Test case: Fail to add a course when one or some or all fields are empty



Steps 1. Provide empty course’s ID in the ID textbox or/and

2. Provide empty course’s Name in the name textbox or/and

3. Provide empty number of credits of the course in the credit textbox

or/and


dropdown list

5. Provide the empty description of the course in the description text

area


Expected

results

1. The course is NOT added to the system

2. The user is redirected to the error page with a warning “Fail to add

the course to course catalogue. You must provide all information”


159

Fail to add a course when inputting special character(s)



Name Test case: Fail to add a course when inputting special character(s) to one or

some or all fields

Requirement All fields are filled with data but ID or name containing special character(s)


Steps 1. Provide course’s ID containing special character(s)in the ID textbox

or/and

2. Provide course’s Name containing special character(s) in the name

textbox or/and

3. Provide number of credits of the course in the credit textbox or/and


dropdown list

5. Provide the description of the course in the description text area


Expected

results

3. The course is NOT added to the system

4. The user is redirected to the error page with a warning “Fail to add

the course to course catalogue. ID and Name cannot contain special

character(s)”

Search for course by ID or Name

Name Test case: Search course by course ID or/and by course name

Requirement User wants to find information of a specific course with course’s ID or name.

Preconditions The webpage allows user to find courses is displayed

Steps 1. Provide an ID in the ID textbox or/and



160

Fail to search for course by ID or Name when inputting invalid ID

and/or Name

Fail to search for course by ID or Name when inputting empty ID

and/or empty Name


Expected results The information of course with given ID or/and name is displayed

Name Test case: Fail to search course by course ID or/and by course name when providing

invalid course ID or/and course name

Requirement User wants to find information of course whose ID or/and name does not exist in the

system, then the system must notify the user about this


Steps 1. Provide an invalid ID in the ID textbox or/and

2. Provide an invalid name in the name textbox


Expected results The user is redirected to the error page with a warning “The desired course is not

found”

Name Test case: Fail to search course by course ID or/and by course name when providing

empty course ID or/and course name

Requirement User wants to find information of a specific course’s ID or list of courses with given

name.


Steps 1. Provide an empty ID in the ID textbox or/and

2. Provide an empty name in the name textbox



161

Update course with valid information successfully

Name Test case: Update a course with valid information successfully

Requirement All fields of course information are filled with valid information

Preconditions The webpage that allows user to update information of a course is displayed

Steps 1. Provide course’s ID in the ID textbox or/and

2. Provide course’s Name in the name textbox or/and



dropdown list or/and



Expected

results

1. The course is updated

2. The summary of course information has been updated is displayed

Fail to update a course when one or some or all fields are empty

Name Test case: Fail to add a course when one or some or all fields are empty



Steps 1. Provide empty course’s ID in the ID textbox or/and

2. Provide empty course’s Name in the name textbox or/and

3. Provide empty number of credits of the course in the credit textbox

or/and


dropdown list


or/and course name”


162

5. Provide the empty description of the course in the description text

area


Expected

results

1. The course is NOT updated

2. The user is redirected to the error page with a warning “Fail to update

the course to course catalogue. You must provide all information”

Fail to update a course when inputting special character(s)



Name Test case: Fail to update a course when inputting special character(s) to one


Requirement All fields are filled with data but ID or name containing special character(s)


Steps 1. Provide course’s ID containing special character(s)in the ID textbox

or/and

2. Provide course’s Name containing special character(s) in the name

textbox or/and



dropdown list

5. Provide the description of the course in the description text area


Expected

results

1. The course is NOT updated


the course to course catalogue. ID and Name cannot contain special

character(s)”


163

Update operation is canceled

Delete a course

Delete operation is canceled

Name Test case: Update operation is canceled


operation

Preconditions The webpage that allows user to update information of a course is displayed. (To be

noted that we have test cases searching for course above already. There’s no need to

repeat it here.)


Expected results The course is NOT updated in the system


Name Test case: Delete a course

Requirement When user decides to delete the selected course, the system removes that course

from the system

Preconditions The webpage that allows user to delete information of a course is displayed. (To be


repeat it here.)


Expected results The system deletes the selected course from the system


Name Test case: Delete operation is canceled



164

Test Cases of Manage User Account Use Case

Create a new user account successfully

Name Test case: Create new user account successfully

Requirement All fields of account information are filled with valid information

Preconditions The webpage that allows user to input information of an account is displayed

Steps 1. Provide username in the username textbox

2. Choose a role from the drop down list

3. Provide the description of the account in the description text area.

4. Other information will be used with default values specified in the

use-case specification of Manage user account use case

5. Click on create button

Expected

results

1. The account is added to the system

2. The summary of account’s information has been added to the system

is displayed

Fail to create a new user account when the username that user has

provided existing in the system already

Name Test case: Create a new user account with the username existing in the

system already

Requirement All fields of account information are filled with information

Preconditions The webpage that allows user to delete information of a course is displayed. (To be


repeat it here)


Expected results The selected course is NOT deleted from the system



165


Steps 1. Provide username in the username textbox. But this username has

been being used by another account.






Expected

results

1. The account is NOT added to the system

2. The user is redirected to the error page with the warning “This

username has been being used by another user”

Fail to create a new user account when inputting empty username

Name Test case: Create a new user account when inputting empty username

Requirement Not fields of account information are filled with information








Expected

results


2. The user is redirected to the error page with the warning “You must

provide all information”


166

Fail to create a new user account when the inputs containing special

character(s)



Name Test case: Create a new user account when inputting empty username

Requirement All fields of account information are filled with information


Steps 6. Provide username containing special character(s) in the username

textbox


8. Provide the description of the account containing special character(s)

in the description text area.




Expected

results



the course to course catalogue. The input(s) cannot contain special

character(s)”

Search for account by username

Name Test case: Search for account by username

Requirement User wants to find information of a specific account by username.

Preconditions The webpage allows user to find accounts is displayed

Steps 1. Provide username in the username textbox


Expected results The information of account with given username is displayed


167

Fail to search for account by empty username

Fail to search for account by username that does not exist in the

system

Fail to search for account by username containing special

characters(s)

Name Test case: Search for account by empty username





Expected results The user is redirected to the error page with a warning “Username cannot be

empty.”

Name Test case: Search for account by username that does not exist in the sysem



Steps 1. Provide username in the username textbox. That username does not exist in

the system.


Expected results The user is redirected to the error page with a warning “The account with the given

username does not exist in the system.”

Name Test case: Search for account by username containing special character(s)


168

Update an account

Name Test case: Update an account

Requirement All fields of account information are filled with valid information

Preconditions The webpage that allows user to update information of an account is

displayed

Steps 1. Provide new username in the username textbox and/or

2. Choose a role from the drop down list and/or

3. Provide the description of the account in the description text area

and/or

4. Choose the status of the account from the drop down list and/or


Expected

results

1. The account is updated to the system

2. The summary of account’s information has been updated to the

system is displayed

Update operation is canceled





Expected results The user is redirected to the error page with a warning “Username cannot contain

special character(s).”

Name Test case: Update operation is canceled



169

Delete an account

Delete operation is canceled

operation

Preconditions The webpage that allows user to update information of a account is displayed. (To be

noted that we have test cases searching for account above already. There’s no need

to repeat it here.)


Expected results The account is NOT updated in the system


Name Test case: Delete an account

Requirement When user decides to delete the selected account, the system removes that account

from the system

Preconditions The webpage that allows user to delete information of a account is displayed. (To be


to repeat it here.)


Expected results The system deletes the selected account from the system


Name Test case: Delete operation is canceled


Preconditions The webpage that allows user to delete information of a account is displayed. (To be


to repeat it here)



170

Test Cases of Non-functional requirement testing

Switch from Vietnamese to English

Name Test case: Switch from Vietnamese to English

Requirement The system must have ability to allow user to view the system in English while

he/she is viewing the system in Vietnamese

Preconditions The system is displaying text in Vietnamese

Steps 1. Click on Vietnamese button

Expected

results

1. The system displayed text in English

Switch from English to Vietnamese

Name Test case: Switch from English to Vietnamese

Requirement The system must have ability to allow user to view the system in Vietnamese

while he/she is viewing the system in English

Preconditions The system is displaying text in English


Expected

results

1. The system displayed text Vietnamese

Load testing with 15 requests at the same time

Name Test case: Load testing with 15 requests at the same time

Requirement The system must have ability to response many requests at the same time

Test with 15 requests at the same time

Expected results The selected account is NOT deleted from the system



171

Preconditions The resource to be requested is available

Steps 1. 15 requests are submitted at the same time

Expected

results

1. The time for system to response all the requests is less than 10

seconds







Expected

results


seconds

C- Appendix

Message

ID Type Context Error Messages Actions

MS001 Info Authentication Failed Wrong password or username cannot

be found. OK

MS002 Info Account locked Account locked. Please wait for 30

minutes or contact the administrator. OK

MS003 Info Account being used This account is being used by another

user. OK

MS004 Question Delete a department Are you sure you want to delete the OK – Cancel


172

selected department?

MS005 Question Update a lecturer Are you sure you want to update the

current displayed lecturer? OK – Cancel

MS006 Question Delete a lecturer Are you sure you want to delete the

selected lecturer? OK – Cancel

MS007 Question Update a student Are you sure you want to update the

modified student? OK – Cancel

MS008 Question Delete a student Are you sure you want to delete the

selected student? OK – Cancel

MS009 Info Student not found The selected student does not exist OK

MS010 Info No list of course

offering

This faculty has no list of course

offering yet Ok

MS011 Question Update tuition fee

status

Are you sure you want to update

tuition fee status of current student? OK – Cancel

MS012 Info Student not found Cannot find the result. OK

MS013 Info Course Registration

Closed

The course registration has been

closed OK

MS014 Info Register more than 30

credits

You cannot register more than 30

credits OK

MS015 Info Register less than 15

credits

You cannot register less than 15

credits OK

MS016 Question Submit a schedule Are you sure you want to submit this

schedule? OK – Cancel


173

MS017 Question Reset changes to a

schedule

Are you sure you undo all the

changes you have made? OK – Cancel

D- Inspection Checklist

The following checklist items apply to the test plan.

Completeness

Does the document meet all established templates and standards?

Is the document complete?

Are there any requirements that are not tested?

Are there any features that are planned for testing but should be excluded?

Feasibility

Can the testing as planned be accomplished within the known cost and schedule

constraints?

Can every test described in the test plan be reasonably conducted?

Environment

Is the description of the environment complete?

Is the test plan traceable to any nonfunctional requirements that define the operating

environment?

Performance

Does the test plan account for the expected load for concurrent users, large databases,

or other performance requirements?

Can the performance tests be traced back to requirements in the specification?

Acceptance Criteria

Do the acceptance criteria match the standards of the organization?

The following checklist items apply to the test cases:

Clarity

Does each test case have a clear flow of events?


174

Does each test case test only one specific interaction?

Does each test case describe the interaction using specific user interface and data

elements?

Is each test case repeatable by someone uninitiated on the project?

Completeness

Is every requirement in the SRS verified fully with individual test cases?

Are all of the steps in each test case necessary?

Are there any steps that are missing?

Are all alternative paths and exceptions accounted for?

Accuracy

For every action, is there an expected result?

For every behavior in the requirement, is there a verification of the actual behavior?

Is the test case data specific if data must be entered or modified, is that data provided?

Traceability

Is each test case uniquely identified with a name and a number?

Can each test case be traced back to a specific requirement?


175

Review 4 & Testing Demo Document

28/12/2007


Date December 28th , 2007

Version 1.0

Status Baseline

Author Team TiHonMumMim(Group 6)

Reviewer Team TiHonMumMim(Group 6)



Nguyen Duc Quan

Le Vu Hoang

Tran Minh Phung

Phan Duy Tan

Huynh Da Thuc


176

Testing demo

In this part, we will introduce what we will perform in the testing demo for review 4. We will

perform 3 kinds of tests. They are Unit testing, Functional requirement testing, and Non-

Functional requirements testing.

Due to the large number of classes, test cases for functional requirements, and non-functional

requirements, and the recommendations for quality assurance from Prof. Phan Hoang and Ms.

Sang, we will use check list and test some classes (not all classes) for Unit testing, and smoke

tests (a collection of some test cases, not all tests cases) for functional and non-functional

requirements testing.

All 3 kinds of tests will be performed automatically.


177

Unit testing

As we wrote in the Test Plan and Test Case document (document for review 3), we will use

EJB3Unit to do Unit Testing. Our team will choose persistence classes (entities) to run demo for

Unit Testing. Please check the system architecture with layer model to see where entities are

used.

Because we use EJB3Unit instead of JUnit to test persistence classes, we can use check list to

make sure that entities are implemented correctly. The following check list contains standard

checks that a persistence class must pass to be accepted.

Test write: test writing operation to database check whether writing data to database is

successful or not

Test write null field: not allow write null data to our system database

Test write read: test reading and writing data with relationships and constraints

Test getter setter: test whether get and set methods of each entity work correctly or

not

The testing result of Unit Testing will be showed in the testing report later.

Functional requirement testing In this part we will introduce the smoke test for functional requirements testing. As Prof.Phan

Hoang and Ms. Sang recommended that we should choose which test cases that we feel most

confident to run the testing demo. Therefore, we try to perform smoke test with all test cases of

Login and Logout use case, Manage Course Offering use case, Register courses use case, and

Manage Department Information.

Test Cases of Log in and Log out Use Case

User logs in successfully with valid username and password

Name Test case: User logs in successfully with valid username and password

Requirement The user is logged in correctly after providing correct username and

password



5. Provide valid password in the password textbox



178

Expected results The user is redirected to the specific homepage of that user

Fail to login the system when providing invalid username

Name Test case: Fail to login the system when providing invalid username

Requirement The user is not logged in when providing invalid username


Steps 4. Provide invalid username in the username textbox





Fail to login the system when providing username or password

containing special character(s)



Name Test case: Fail to login the system when providing username or password containing

special character(s)

Requirement The user is not logged in when providing username or password containing special

character(s).



or/and

5. Provide password containing special character(s) in the password textbox or

let password field be empty


Expected results The user is redirected to the error page with a warning “Username and Password

cannot contain special character(s)”


179

Fail to login the system when providing valid username and invalid

password

Name Test case: Fail to login the system when providing valid username and invalid

password

Requirement The user is not logged in when providing valid username and invalid password



5. Provide invalid password in the password textbox




Fail to login the system when providing empty username

Name Test case: Fail to login the system when providing empty username

Requirement The user is not logged in when providing empty username







Fail to login the system when providing valid username and empty

password

Name Test case: Fail to login the system when providing valid username and empty


180

password

Requirement The user is not logged in when providing valid username and empty password



5. Provide empty password in the password textbox




User account is locked after failing to log in 3 times

Name Test case: User account is locked after failing to log in 3 times

Requirement User account is locked after failing to log in 3 times with a specific username


Steps 5. Provide valid username in the username textbox or/and

6. Provide invalid or empty password in the password textbox


8. Repeat above process for 3 times



After the 3rd time, the user account with given user name is locked out and a

warning is issued “Account locked. Please wait for 30 minutes or contact the

administrator”

User logs in the system using an account is being used by another

user

Name Test case: User logs in the system using an account is being used by another user

Requirement User CAN NOT log in the system using account is being used by another user


181

Preconditions A given account is being used by user 1

Steps 4. User 2 provides username of user 1 exactly

5. User 2 provides password of user 1 exactly


Expected results User 2 is redirected to the error page with a warning “This account is being used by

another user”

User logs in the system using an account is being locked

Name Test case: User logs in the system using an account is being locked

Requirement User CAN NOT log in the system using account is being locked

Preconditions A given account is being locked by logging in fail 3 times

Steps 4. Provides username of given account being locked

5. Provide password of given account being locked


Expected results User is redirected to the error page with a warning “This account is being locked.

Please wait for 30 minutes or contact the administrator”

Change password successfully

Name Test case: Change password successfully

Requirement The user wants to update password

All old and new passwords must be provided



Steps 5. Enter old password

6. Enter new password

7. Enter confirmed password


182

Fail to change password when old or new or confirmed password is

empty

Fail to change password when old password is incorrect


Expected results The old password is changed into new password


Requirement Try to change password when old or new or confirmed password is not input



Steps 5. Let old password empty or/and

6. Let new password empty or/and

7. Let confirmed password empty or/and


Expected results Notify user about empty fields


Requirement Try to change password when providing incorrect old password



Steps 5. Enter wrong password

6. Enter new password empty

7. Enter confirmed password empty


Expected results Notify user that the current password is wrong


183

Recover the password successfully

Fail to reset password when inputting wrong answer for the security

question

Name Test case: Recover the password successfully

Requirement The user lost or forget the password and wants to reset the password

Input right answer



Steps 1. Specify the answer for the security question in the text box


Expected results The system issues the message indicates the password has been reset to the default

password “Abcd1234” and warns the user to change their password for the next log

in

The password is reset to the default password “Abcd1234”

The system redirects the user to the log in page

Name Test case: Fail to reset password when inputting wrong answer for the security

question


Input wrong answer



Steps 3. Specify the wrong answer of the security question in the text box


Expected results The system issues the message “The answer is not correct”



184

Fail to reset password when inputting answer containing special

character(s) for security question



Fail to reset password when inputting empty answer for the security

question


Name Test case: Fail to reset password when inputting answer containing special

characters for the security question


The answer contains special characters



Steps 3. Specify the answer containing special character(s) for the security question

in the text box


Expected results The system issues the message “The answer cannot contain special character(s)”



Name Test case: Fail to reset password when inputting empty answer for the security

question


Let answer be empty



185

Test Cases of Manage Course Offering Use Case

Create list of courses offering successfully


Steps 3. Leave the answer text box blank


Expected results The system issues the message “The answer cannot be empty”



Name Test case: Create list of courses offering successfully

Requirement List of courses offering does not exist yet

Academic affair staff wants to create new list course offering









selected faculty


Expected results The new list of courses offering is created

The system displayed the list of course offering that has been created



186

Update the list of course offering

Cancel during the Create list of course offering operation

Name Test case: Update the list of course offering

Requirement The list of courses offering exists in the system

Academic affair staff wants to update list of courses offering







offering




Expected results The confirmation displayed

The list of course offering is updated with the changes of the user

The updated list of course offering is displayed after the operation completed

Name Test case: Cancel during the Create list of course offering operation

Requirement Academic affair staff is being in the creating list of courses offering process.





187

Cancel during the Update list of course offering operation






selected faculty

14. Click on the Cancel button

Expected results No list of course offering is created


Name Test case: Cancel during the Update list of course offering operation

Requirement Academic affair wants to cancel the updating list of courses offering process







offering



14. Click on the Cancel button to confirm the operation

Expected results List of courses offering is not updated



188

Fail to create an empty list of course offering

Update list of course offering while there’s no list of course offering

for specific faculty

Name Test case: Fail to create an empty list of course offering

Requirement Academic affair tries to create an empty list of courses offering or creates an empty

list of courses offering by accident






11. Don’t click any check box in order not to select any course



selected faculty


Expected results No empty list is created

The system issued warning about the empty list of course offering

The system redirects to the Create list of course offering and let the user to create

the non – empty list

Name Test case: Update list of course offering while there’s no list of course offering for

specific faculty

Requirement Academic affair staff tries to update list of courses offering while has not been

created. Then the system must notify him/her about the unavailable status of list of

courses offering.


189

Test Cases of Manage Department Information Use case

Add a department with valid information successfully

Name Test case: Add a department with valid information successfully



Steps 7. Provide department’s name in the name textbox






Expected results 1. The department is added to the system

2. The summary of department has been added to the system is displayed

Fail to add a department with name that already exists in the system

Preconditions 3. The user must log in as the Academic Affair Staff

4. The selected faculty has no list of course offering




Expected results A warning is displayed “There’s no list of course offering in this faculty. Cannot

update”

Name Test case: Fail to add a department with name that already exists in the system



190




textbox








department to the system. The name of the department that you have provided













department to the system. You must provide all information”


191

Fail to add a department when inputting special character(s) to one




Update a department with valid information successfully

Name Test case: Update a department with valid information successfully



Steps 7. Provide department’s name in the name textbox or/and

Name Test case: Fail to add a department when inputting special character(s) to one or

some or all fields




textbox or/and


textbox or/and


textbox or/and







department to the system. Some fields contains special character(s)”


192






Expected results 1. The department is updated in the system

2. The summary of department has been updated is displayed

Fail to update a department with name that already exists in the

system

Name Test case: Fail to update a department with name that already exists in the system




textbox or/and








department in the system. The name of the department that you have provided



193

Fail to update a department when one or some or all fields are

empty

Fail to update a department when inputting special character(s) to




Name Test case: Fail to update a department when one or some or all fields are empty











department in the system. You must provide all information”

Name Test case: Fail to update a department when inputting special character(s) to one or

some or all fields




textbox or/and



194

Update cancel

Delete a department

textbox or/and


textbox or/and







department in the system. Some fields contains special character(s)”



operation


Steps Click on add button

Expected results The department is NOT updated in the system


Name Test case: Delete a department

Requirement When user decides to delete the selected department, the system removes that

department from the system




195

Delete cancel

Test Cases of Register Course Use Case

We will filter the prerequisites courses before showing the list of courses that a specific student

can register. Therefore, that student can register any course in the list of courses offering that

student can see.

Fail to register more than 30 credits




6. User confirms to delete the selected department by clicking on delete

button.

Expected results The system deletes the selected department from the system








6. User click on cancel button.

Expected results The selected department is NOT deleted from the system


Name Test case: Fail to register more than 30 credits


Total number of credits is greater than 30


196

Fail to register less than 15 credits

Register for courses successfully

Name Test case: Register for courses successfully

Requirement Student registers for courses to create his/her schedule (please see the

definition of SCHEDULE in the glossary part)




courses offering

7. Repeat step 2 until the total number of credits is greater than 30



register more than 30 credits”

Name Test case: Fail to register less than 15 credits


Total number of credits is less than 15




courses offering

7. Repeat step 2 until but make sure that the total number of credits is less

than 15



register less than 15 credits”


197

That student does not have schedule yet


equal to 15


Steps 5. Click register course offering button.

6. Select courses offering from a list of available course offerings of this

student that the system displays.

7. Repeat step 2 and make sure that the total of credits is less than or

equal to 30 and greater than or equal to 15.

8. Click the submit button

Expected results The schedule of that student is created in the system.

List of course offering will be shown on the schedule of this student.


198

Update the existing schedule successfully

Name Test case: update the existing schedule successfully

Requirement Student has his/her schedule already (please see the definition of SCHEDULE

in the glossary part)

That student wants to modify his/her schedule


equal to 15


Steps 6. Click the update schedule button.

7. Check some more courses that he/she wants to register and/or

8. Uncheck some courses that he/she does not want to register

9. Repeat step 2 or/and 3 if needed and make sure that The total

number of credits is less than or equal to 30 and greater than or equal

to 15

10. Click the update button

Expected

results

The schedule is updated in the system.

Updated list of course offering will be shown on the schedule of this student.

Non-functional requirement testing

Test Cases of Non-functional requirement testing

Switch from Vietnamese to English

Name Test case: Switch from Vietnamese to English

Requirement The system must have ability to allow user to view the system in English while

he/she is viewing the system in Vietnamese

Preconditions The system is displaying text in Vietnamese



199

Expected

results

2. The system displayed text in English

Switch from English to Vietnamese

Name Test case: Switch from English to Vietnamese

Requirement The system must have ability to allow user to view the system in Vietnamese

while he/she is viewing the system in English

Preconditions The system is displaying text in English


Expected

results

2. The system displayed text Vietnamese







Expected

results


seconds







Expected

results


seconds


200

System architecture introduction In this part, we will provide a brief description of OURS architecture so that you can see the

system in a systematic way and test it easily.

From the updated requirement, our team sees that the number of functions the system

provides is too large in comparison with the scope of the system. This brings us to the decision

to divide the original system into many subsystems as follow.

System architecture with sub-system model

System architecture with layer model

We use J2EE technologies to impalement OURS. The following is the layer model view of OURS.


201

We will introduce all technologies that we use to develop OURS.

- Client layer: This layer is used directly by end user of OURS. The web browser will help

end user to interact with OURS by rendering the user interface of OURS. We

recommend to use Internet Explorer 7.0 as web browser for developing, testing, and

running OURS

- Presentation layer: This layer manages and represents the user interface of OURS. We

use AJAX (with Open Rico), Validation Framework, and Struts Framework (this

framework is the key of presentation layer) to implement the presentation layer of

OURS.

- Business Logic layer: This layer is the place we define and manage all business rules that

the system must satisfy and support the university business process, in particular course

registration process. We use EJB3.0 (The latest technology of J2EE for business login

layer) to implement business logic layer.

- Persistence layer: This layer allows the system to access the database in an object-

oriented manner by using EJB entities.

- Database system layer: This layer is the place for OURS stores all data in a database. We

use MySql 5.0 for the database of OURS.

How to download & install tools In this part, we will introduce all the tools, where to download them or their libraries, and how

to install them (if any of them requires installation before we can use it).

o JDK 1.6.x

1. Download JDK for Windows (You need to accept license agreement before

downloading ) at

https://sdlc1a.sun.com/ECom/EComActionServlet;jsessionid=8D963E27810

5AC56A9ADEAA4FBD103B8#


202

2. Double-click on the package you have downloaded to install the JDK

3. Follow the instruction of installation. You should use default values specified

by the instruction and click all “Next” buttons so that you will feel easier to

monitoring it later.

o Environment variables after finishing the JDK installation:

1. Right click on My computer, then choose Properties.

2. Click the Advanced tab.

3. Click Environment variables.

4. For either a user or a system variable, do the following steps:

Click New to add new variable name and value.

o Variable name: PATH

o Variable value: Depend on how you install JDK. It will be

similar to this : C:\Program Files\Java\jdk1.6.0_02\bin

Click New to add new variable name and value:

o Variable name: JAVA_HOME

o Variable value: Depend on how you install JDK. It will be

similar to this: C:\Program Files\Java\jdk1.6.0_02

o Glassfish 2.0

1. Download application server Glassfish V2.0 at

http://java.net/download/javaee5/v2_branch/promoted/WINNT/glassfish-

installer-v2-b58g.jar

2. Make sure that you have set the environment variables (PATH and

JAVA_HOME) correctly

3. Click Start

4. Choose Run

5. Type: CMD, then press Enter , and the console application will be displayed,

6. Type: java -Xmx256m -jar filename.jar

With filename is the name of file you have downloaded. It is the package of

Glassfish V2.0. This command will unbundle Glassfish and create a new

directory structure rooted under a directory named 'glassfish'.

7. Environment variables for ANT (ANT is a common tool used J2EE application

development for building the application):

Right click on My computer, then choose Properties.

Click the Advanced tab.

Click Environment variables.

For either a user or a system variable, do the following steps:

o Click New to add new variable name and value:

Variable name: ANT_HOME

Variable value: Depend on how and where you

extract the Glassfish V2.0. It will be similar to this:


203

8. Go to Glassfish folder where the program has been extracted by using CD

command of MS-DOS. This command depends on where your Glassfish

folder is. It should be similar to: CD glassfish then press Enter.

9. The real installation of glassfish will be done when you execute the ANT

command. We use Windows operating system. Therefore, we type:

lib\ant\bin\ant -f setup.xml

o MySQL 5.0.x (To download at http://dev.mysql.com , you have to register an

account to be member of the website. Therefore, there’s no direct link to

download)

1. Download MySql Essential 5.0 at

http://dev.mysql.com/downloads/mysql/5.0.html#win32

2. Double-Click on the package has been downloaded, and then follow the

instruction of the installation. To be easy to use later, you should use all

default values specified by the instruction and click on all “Next” buttons.

However, both the username and password used for administrator of MySql

should be “root”.

o MySql Gui Tools 5.0.x

1. Download MySql Gui Tools at http://dev.mysql.com/downloads/gui-

tools/5.0.html



default values specified by the instruction and click on all “Next” buttons.

o MySql Connector 5.0.x

1. Download MySql-connector-Java at

http://dev.mysql.com/downloads/connector/j/5.0.html

o NetBean 6.0

1. Download the Netbean IDE verion 6.0 at

http://download.netbeans.org/netbeans/6.0/final/bundles/netbeans-6.0-

windows.exe

2. Double-Click on the package has been downloaded to start setup

3. Follow the instruction of the installation. To be easy to use later, you should

use all default values specified by the instruction and click on all “Next”

buttons

o Junit

1. Download Junit 4.x at

http://sourceforge.net/project/downloading.php?group_id=15278&use_mi

rror=jaist&filename=junit4.4.zip&85130481

2. Unzip the junit.zip distribution file to a directory referred to as

%JUNIT_HOME%. 3. Add JUnit to the classpath:


204

set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%\junit.jar

Note: To run your JUnit tests, you'll need the following elements in

your CLASSPATH:

o JUnit class files

o Your class files, including your JUnit test classes

o Libraries your class files depend on

If attempting to run your tests results in a NoClassDefFoundError, then something is missing from your CLASSPATH.

Windows Example:

set

CLASSPATH=%JUNIT_HOME%\junit.jar;c:\myproject\classes;c:

\myproject\lib\something.jar

o EJB3Unit

1. Download all packages needed for EJB3Unit at

https://sourceforge.net/project/showfiles.php?group_id=150949&package

_id=166989&release_id=528475

o AdventNetQEngine_WebPerformance

1. Download QEngine_WebPerformance at

http://www.adventnet.com/products/qengine/download.html



default values specified by the instruction and click on all “Next”

buttons.

o QuickTest Professional 9.2

1. Download QuickTest Professional at

https://h10078.www1.hp.com/cda/hpdc/display/main/index.jsp?zn=bto&cp=54_

4012_100__

2. You have to register an account at the HP corporation websie before

you are allowed to download the tool.

Click New user please register

On search fill, you type quicktest to find QuickTest Professional

tool

Click on HP QuickTest Professional 9.2 Evaluation in result

Click Agree button to go next page

Click on hyperlink in URL line at Important Software Download

Links


205

3. After downloading, double-Click on the package has been downloaded,

and then follow the instruction of the installation. To be easy to use

later, you should use all default values specified by the instruction and

click on all “Accept” or “I agree” and “Next” buttons.

4. To be noticed that this software requires Dot Net Framework to install

it.

How to install OURS This part of the document is a guide on how to deploy the system to the Java application server.

We provide 3 separate packages for the 3 layers of our system: presentation layer (.war

package), business layer (.jar package) and database storage.

o Database: Restore database from back up file:

1. Login to the database as Administrator:

Run the MySQL Administrator and fill in the required fields:

Server Host: if you have gone through a normal installation

procedure for MySQL, the default value here should be

“localhost”.

Port: the port for the Application server to connect to the

database server. The default value is “3306”.

Username and Password: username and password is used to

authorize user to access to the database. Type the username

and password you used when installing MySQL. Default value is

“root” “root”.

Press “OK” button.

2. Restore back up file:

On the left side of the application, you will see some tasks such

as: Server Information, Service Control, Startup Variables… click

on the “Restore” session.

Click on the “Open Backup File”.

Browse to the location of the database back up file then open.

Check the 2 check box in the Options area.

Click on “Start Restore”.

Now the all the database records have been loaded into the database

server. You can click on “Catalogs” and check if the schema “ours-

silverbullet” presents.

o Web part: Deploy Web part

1. Login the application server

First startup the application server. Open the command line,

type “cmd” then enter. Type the following command:


206

<GlassfishPath>\bin\asadmin start-domain domain1, enter then

wait for the server to start.

Open command line or any browser and type in

http://localhost:4848

You will be redirect to the login page.

Provide the username and password, the default value for

username is “admin” and password is “adminadmin”.

2. Deploy the .war file:

On the left menu, click on “Web Applications”, on the main

content, click on “Deploy”.

Click on “Browse”, locate the oursWeb.war file then open.

Click on “OK” button to start deploy the web layer.

o EJB part:

1. Login the application server: repeat the step above if you haven’t logged

in yet.

2. Connection pool:

On the left menu Click on ResourcesJDBCConnections Pool.

Click “New…” button.

Fill the general settings then click ok

o Name: mysqlPool

o Resource Type: javax.sql.DataSource

o Database Version: MySQL

On Step 2 of 2, go to additional properties table, check all the

properties then click “Delete Properties”

Add 6 new properties, these are the configuration of the

database server, adjust if necessary.

o serverName: localhost

o port: 3306

o networkProtocol: jdbc:mysql

o username: root

o password: root

o databaseName: ours-silverbullet

Finich. You can click on “Ping” to make sure the information use

type is correct.

3. Configure data source

On the left menu, go to ResourcesJDBCJDBC Resources

Add New.

Fill in the new jdbc resource information:

o JDNI name: ours-1.1

o Pool Name: mysqlPool

Click OK

http://localhost:4848/


207

4. Deploy EJB part:

On the left menu, click on EJB Modules.

Click deploy

Browser to the system business layer package OURS1.1.1 then

open

Click on “OK” to start deploying.

How to run OURS o Application server and database server have started already

1. Launch OURS by typing the following URL in Internet Explorer or in

Firefox or any other browsers http://localhost:8080/oursWeb/

o Application server or/and database server not been started

1. Start application server: Looking for “bin” folder of the Glassfish server,

and then double click on the file named “asadmin.exe”. The path of bin

folder will be similar to “C:\Program Files\glassfish-v2\bin”. When the

console application is displayed, type the command “start-domain”, the

server will be started.

2. Launch OURS by typing the following URL in Internet Explorer or in

Firefox or any other browsers http://localhost:8080/oursWeb/


208

How to setup and run tests of OURS o Unit testing

1. Open Netbean 6.0 by double clicking on its shortcut(it is on your

desktop by default)

2. Open the Unit test project. We put all the persistence classes and their

test classes in the Unit test project.

3. Run the test by clicking on run, choose run test.

4. Note that if you Netbean IDE does not have library of EJB3Unit, you

have to download it and add it to the library by right clicking on the

project; choose add library menu item, and then choose the library you

have downloaded.

o Functional requirement testing

1. Start server where OURS is deployed(see the part of How to run OURS)

2. Start the QuickTest Professional by double clicking on the shortcut of

the QuickTest Professional program

3. Create a new test by selecting new button

4. You have to provide the URL you want to test. In this case it is any URL

of OURS. It should be http://localhost:8080/oursWeb/

5. Now, the program will allow you to record the action you perform on

the URL you have specified.

6. Stop the recording by clicking on the stop button.

7. After you finish you action, you can input many different inputs in the

data table. This will help you to test the function automatically, instead

of input data again each time the action is repeated.

o Non-functional requirement testing

1. Multi-language checks

Run OURS and switch between English and Vietnamese by click

on the Vietnamese or English button which is on top of the

website.

2. Load test

Start QEngine server by double click on the shortcut of QEngine

(which is put on your desktop by default)

Choose new transaction specify the name of the transaction

Wait for the program to process. It will ask you to specify the

URL to test. You have to provide the URL of OURS

Wait for the program to records the information, then stop the

recording

The program will show you how it processes the load test


209

How to use OURS This document is about guiding user to use OURS. It includes “How to Use” guidelines of main

functions of the system. Although this part is optional, our group still wants to provide a brief

description of the real user manual, so that user will feel easier to have the basic ideas about

OURS.

Login and Logout This feature allows user to log in to the system to achieve the access permission

to perform other functions that are granted to that specific user. It also lets user log out

to end his/her session View Academic History

Log in

1. Enter the username in the username textbox

2. Enter the password in the password textbox

3. Click on the sign in button

4. Redirected to the desired page with the status logged on

Log out

1. Click on the log out button

2. Redirected to the main page with the status logged out

Recover Password

1. Click on the “Forget password” link

2. Specify the answer of the security question in the text box


Register Course

This feature allows a Student to register course offerings in the current semester.

1. Click on register courses button

2. Check the checkbox(es) to select the course(s) you want to register. If you do not want to register for the course(s) you have checked, just simply uncheck the checkbox(es) of the course(s).



This feature allows a Student to view his studying progress. The Student can see the courses he has taken as well as the scores and status (passed or failed).

1. Choose a filter group: View All, View by specific year and semester, View by

passed and failed status.


210

2. One filter is chosen.

3. Click View button.

Manage Department Information This feature allows Academic Affair Staff to manage department and faculty

information. This includes adding, updating, and deleting department and faculty from

the system.

Add a department

1. Provide department’s name in the name textbox





6. Click on Add button

Update a department

1. Provide department’s name in the Name textbox or/and

2. Provide department’s location in the Location textbox or/and

3. Provide department’s dean in the Dean textbox or/and

4. Provide faculty information that the Department has or/and

5. Provide department description in the Description text area or/and

6. Click on Add button

Delete a department

1. Chooses a department to delete from a drop down list.

2. System displays a message warns the user about the deletion

3. Confirms to delete the selected department by clicking on delete button

Manage Student Information This feature allows the Academic Affair Staff to manage student information in the

registration system. This includes adding, updating, deleting, and searching Students

from the system

Add a student

8. Provide student’s name in the name textbox

9. Provide student’s ID in the ID textbox

10. Choose student’s faculty in the list of faculty

11. Choose student’s academic duration in the range list

12. Choose student’s academic year in the list

13. Choose semester of this academic year.

14. Choose course of this semester.


211


Search a student by Student ID/Student name

1. Chooses ID and Name filter from the filter drop down list




Search a student by Faculty/Academic duration

1. Chooses faculty and academic duration filter from the filter drop down list


3. Choose an academic duration from drop down list

4. Click on the Search button

Search a student by Academic year/Semester/Course

1. Chooses academic year, semester, and course filter from the filter drop down

list





Update a student

1. Provide student’s name in the name textbox or/and

2. Provide student’s ID in the ID textbox or/and







Delete a student

1. Choose a student to be deleted

2. System warns the user about the deletion

3. Click on the Delete button to confirm

Manage Course Offering This feature allows Academic Affairs to monitor course offerings in one semester of

specific year.

Create list of courses offering

1. Click on the button Manage Course Offering




212



6. Click on the Submit button to create the list of course offering for the selected

faculty


Update a list of course offering

1. Click on the button Manage Course Offering




offering




Manage Lecturer Information This feature allows the Academic Affair Staff to manage lecturer information in the

registration system. This includes adding, updating, deleting, and searching lecturers

from the system.

Add a lecturer

1. Provide lecturer’s name in the Name textbox

2. Choose lecturer’s date of birth in the Calendar

3. Provide lecturer’s cell-phone number in the cell-phone textbox

4. Provide lecturer’s email address in the Email textbox

5. Provide lecturer’s department where that lecturer belongs in the department

textbox

6. Provide lecturer’s degree in the degree textbox


Look for a lecturer

1. User chooses the department where the lecturer belongs

2. Verify that the system retrieves and displays the list of lecturers of that

department

3. User choose a lecturer from the list

4. Verify that the summary of information of selected lecturer is displayed

Update a lecturer

1. Provide lecturer’s name in the name textbox or/and


3. Provide lecturer’s cell-phone number in the cell-phone textbox or/and

4. Provide lecturer’s email address in the email textbox or/and


213

5. Provide lecturer’s department where that lecturer belongs in the department

textbox or/and

6. Provide lecturer’s degree in the degree textbox or/and


Delete a lecturer

1. Select the lecturer to be deleted

2. Click on the deleted button

3. System warns the user about the deletion

4. Click on the Delete button to confirm


This feature allows Financial Office Staff to monitor student’s tuition fee. This includes viewing and updating the tuition fee status of students.

View tuition fee by student ID or/and by student name

1. Chooses ID and Name filter from the filter drop down list




View tuition fee by faculty or/and by academic duration

1. Chooses faculty and academic duration filter from the filter drop down list


3. Choose a academic duration from drop down list


View tuition fee by academic year, semester, and course

1. Chooses academic year, semester, and course filter from the filter drop down

list





Update tuition fee status of a student

1. Choose a student from the list

2. Change status of tuition fee of that student by choose tuition fee status from

the stats drop down list



214


This feature allows the Academic Affair Staff to manage Course Catalog information in the registration system. This includes adding, updating, deleting, and searching a course from the course catalog of the university

Add new course to course catalogue successfully

1. Provide course’s ID in the ID textbox

2. Provide course’s Name in the name textbox

3. Provide number of credits of the course in the credit textbox

4. Choose the faculty of the department where the course belongs from dropdown

list



Update course with valid information successfully

1. Provide course’s ID in the ID textbox or/and

2. Provide course’s Name in the name textbox or/and


4. Choose the faculty of the department where the course belongs from dropdown

list or/and



Manage User Account

This feature allows the Administrator to manage user account information in the system. This includes creating, updating, deleting, and searching user account(s) in the system

Create a new user account

1. Provide username in the ID textbox




Update an account

1. Provide new username in the ID textbox and/or

2. Choose a role from the drop down list and/or

3. Provide the description of the account in the description text area and/or

4. Choose the status of the account from the drop down list and/or


215

5. Choose the secret question from the drop down list and/or

6. Provide the answer to the answer textbox
