Project Plan And Srs Final

Business Plan & SRS Document 11/9/2007

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

Group 6

Team member Signature

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

Documenter Nguyen Duc Quan

Business Plan & SRS Document

2

Table of Contents 1. STATEMENT OF WORK .................................................................................................................5

2. RESOURCE LIST............................................................................................................................8

2.1 Human ................................................................................................................................8

2.2 Software .............................................................................................................................8

2.3 Hardware ............................................................................................................................8

3. ESTIMATION ...............................................................................................................................9

3.1 Huynh Da Thuc estimation ...................................................................................................9

3.2 Phan Duy Tan estimation....................................................................................................12

3.3 Tran Minh Phung estimation ..............................................................................................15

3.4 Nguyen Duc Quan estimation .............................................................................................18

3.5 Le Vu Hoang estimation .....................................................................................................21

4. SCHEDULE.................................................................................................................................24

4.1 Task list .............................................................................................................................24

4.2 Gantt chart (reference) ......................................................................................................26

5. RISK PLAN .................................................................................................................................27

6. DISCUSSION SUMMARY .............................................................................................................29

6.1 Project background ............................................................................................................29

6.1.1 Purpose of project ......................................................................................................29

6.1.2 Scope of project .........................................................................................................30

6.2 Perspectives ......................................................................................................................32

6.2.1 Who will use the system?............................................................................................32

6.2.2 Who can provide input about the system? ...................................................................32

6.3 Project objectives ..............................................................................................................33

6.3.1 Know business rules....................................................................................................33

6.3.2 System information and/or diagrams ...........................................................................33


3

6.3.3 Assumptions and dependencies ..................................................................................35

6.3.4 Design and implementation constraint ........................................................................35

6.4 Risks..................................................................................................................................35

6.5 Known future enhancements..............................................................................................36

6.6 References ........................................................................................................................36

6.7 Open, unresolved, or TBD issues .........................................................................................36

7. SOFTWARE REQUIREMENT SPECIFICATION .................................................................................37

7.1 USE CASE SPECIFICATION ...................................................................................................37

7.1.1 Log in and Log out ......................................................................................................37

7.1.2 Manage Department Information ................................................................................39

7.1.3 Manage Lecturer Information......................................................................................41

7.1.4 Manage Student Information ......................................................................................44

7.1.5 Manage Course Offering .............................................................................................47

7.1.6 Manage Financial Activities .........................................................................................50

7.1.7 View Academic History ...............................................................................................52

7.1.8 Register Course ..........................................................................................................53

Appendix ..................................................................................................................................55

7.2 FUNCTIONAL REQUIREMENT ..............................................................................................57

7.3 NON-FUNCTIONAL REQUIREMENT ......................................................................................61

7.3.1 Performance: .............................................................................................................61

7.3.2 Reliability: ..................................................................................................................61

7.3.3 Availability: ................................................................................................................61

7.3.4 Efficiency: ..................................................................................................................61

7.3.5 Supportability:............................................................................................................61

7.3.6 Integrity: ....................................................................................................................61

7.3.7 Portability: .................................................................................................................61

7.3.8 Flexibility:...................................................................................................................62

8. INSPECTION REPORT..................................................................................................................63

9. GLOSSARY .................................................................................................................................63


4

9.1 Introduction ......................................................................................................................63

9.2 Definitions.........................................................................................................................64

9.2.1 OURS .........................................................................................................................64

9.2.2 Academic staff............................................................................................................64

9.2.3 Finance staff...............................................................................................................64

9.2.4 Department ...............................................................................................................64

9.2.5 Faculty .......................................................................................................................64

9.2.6 Curriculum .................................................................................................................64

9.2.7 Subject.......................................................................................................................64

9.2.8 Course Offering ..........................................................................................................64

9.2.9 Prerequisite ...............................................................................................................64

9.2.10 Course Catalog ...........................................................................................................65

9.2.11 Lecturer .....................................................................................................................65

9.2.12 Student ......................................................................................................................65

9.2.13 Student priority ..........................................................................................................65

9.2.14 Discount rate..............................................................................................................65

9.2.15 Grade.........................................................................................................................65

9.2.16 Schedule ....................................................................................................................65

9.2.17 Tuition fee..................................................................................................................65

9.2.18 Credit.........................................................................................................................65

9.2.19 Academic duration .....................................................................................................65

9.2.20 Academic year ............................................................................................................65


5

1. 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

Academic Affair Staffs

Manage Department Information

Manage Lecturer Information

Manage Department Information

Manage Student Information

Manage Courses Offering

Financial Office Staffs View Tuition Fee

Students View Academic History

Register for courses

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.

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.


6

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 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.

Inception Elaboration Construction Transition

[Use-case driven]

Use case

Model

Analysis

Model

Design

Model

Deployment

Model

Implementation

Model

Test

Model


7

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.


8

2. RESOURCE LIST

2.1 Human

2.2 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

2.3 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


9

3. ESTIMATION

3.1 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 in itia l

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 in itia l 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

16 Register courses use case 3 1 1 1 6

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


10

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

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


11

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 repor t 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


12

3.2 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 par ts 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 in itia l 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

14

Manage courses offering 4 -1 1 4

There are many solutions in solving problem of

course offering management. I t is d ifficult to choose one


13

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


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

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


14

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


15

3.3 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 a lready

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 in itia l 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

11 Manage faculty use case 2 0.5 0.5 3

12 Manage lecturer use case 3 0.5 0.5 4


16

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

18

Complete functional

requirement 1 1

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

12


model 2 2

13 Complete Implementation guidelines & code conventions 1 1


15 Review OOAD 1 1

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


17

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


18

3.4 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

th is 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 in itia l requirement 1 1 2

8 Understand stake holder & user needs 2 2

9 Complete glossary 2 2

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


19

11 Manage faculty use case 2 1 3

3 members are familiar with o ld 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 per form 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

11 Design test case 1 0.5 0.5 2

12 Complete Implementation model 1 1 2

13


guidelines & code conventions 1 1


15 Review OOAD 1 1


20

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


21

3.5 Le Vu Hoang estimation

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


Category x goal tasks x quality tasks wa iting time project overhead


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 in itia l requirement 2 -1 1 Stifling

8

Understand stake holder &

user needs 3 3

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

15 View academic history 3 3

16 Register courses use case 3 3

17 Manage financial activities 2 2


22

18 Complete functional requirement 4 4

19


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

12 Complete Implementation model 1 1

13


guidelines & code conventions 1 0.5 1.5 Replace Magic Number with sy mbolic 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



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


23

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


24

4. SCHEDULE

4.1 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

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


25

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

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


26

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

4.2 Gantt chart (reference)


27

5. 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, the pressure is really high.

2 3 6

Create a detailed schedule in a whole

project and supervise process of work with

schedule, change schedule with any

mismatch with schedule.


28

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


29

6. DISCUSSION SUMMARY

6.1 Project background

6.1.1 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.


30

6.1.2 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. o Users also have another option to choose when they forget the

password and intend to recover it

View Academic

History

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 Manage

Department

Information

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

Information

o 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.

Manage o This feature allows Academic Affairs to monitor course offerings in one


31

Courses

Offering

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


32

6.2 Perspectives

6.2.1 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 working in the Academic Affair Office, responsible for the

Academic issue in the University. 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

6.2.2 Who can provide input 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


33

6.3 Project objectives

6.3.1 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 Staff 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 report from the Academic Affair Staff, 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.

6.3.2 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


34

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

functionalities showed in following diagram.

OURS

Manage Department

Manage Lecturer

Manage Course

Offering

Manage Student

Manage Financial

Activities

View Academic

History

Register Courses

Student

Academic Affair Staff

Financial Office Staff

Login&Logout

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»

«uses»«uses»

«uses»


35

6.3.3 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.

6.3.4 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

6.4 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.

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.


36

6.5 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. Access the system as lecturer: 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.

6.6 References

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

SRS document.

6.7 Open, unresolved, or TBD issues

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


37

7. SOFTWARE REQUIREMENT SPECIFICATION

7.1 USE CASE SPECIFICATION

7.1.1 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 which 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, AAO 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.


38

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.

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.

Post

Conditions

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

homepage.


39

7.1.2 Manage Department Information

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.

Basic course of

event 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


40

2. Once the Academic Affair Staff provides the requested information and 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.


41

7.1.3 Manage Lecturer Information

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, AAO Staff can manage the information easily every time and every

where



Basic course of

event 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


42

- Degree

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

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.


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.


confirm the deletion of the lecturer.

8. The system deletes the lecturer from the system

Alternatives Delete Cancelled


43

paths 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

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.


44

7.1.4 Manage Student Information

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

AAO Staff feels easier and more convenient



Basic course of

event 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


45

- Address

- Faculty

- 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)

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(s) whose information matches the filter’s inputs

4. The Academic Affair Staff chooses the student(s) that he/she wants to


46

delete.


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.


47

7.1.5 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 AAO Staff can easy

to create, update or delete the course list and sooner distribute to the

Students within the short time



Basic course of

event

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.


48

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

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


49

offerings to change the lecturer.

2. The system displays list of available lecturers in the department to

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.


50

7.1.6 Manage Financial Activities

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.

Basic course of

event 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



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


51


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 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.


52

7.1.7 View Academic History

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 AAO 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.

Basic course of

event 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.


53

7.1.8 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 AAO and wait for approvals. The process takes a long 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.

Basic course of

event 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.


54

Alternatives

paths

Course Registration Closed

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.


55

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 OK – Cancel


56

student?

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 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


57

7.2 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


58

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


59

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.

Reference Use-case: Manage financial activities


60

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


61

7.3 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:

7.3.1 Performance:

1. Support 100 simultaneously users 2. 90% request has response within 10 seconds.

7.3.2 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.

7.3.3 Availability:

System should be supported 24/7 for on line application.

7.3.4 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.

7.3.5 Supportability:

Localization:

i. Support for the following language must be provided:

a. English

b. Vietnamese

ii. Language could be selectable.

7.3.6 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 a account when this account is locked.

2. At any moment, an account is used only by 1 user.

7.3.7 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 (Glassfish).


62

7.3.8 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


63

8. 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

2 Manage Course

Offering

Phung University has a catalog of all the courses in this

university

3 Manage Course

Offering

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

9. GLOSSARY

9.1 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


64

that use-case descriptions and other project documents can focus on what the system must do

with the information.

9.2 Definitions

The glossary contains the working definitions for the key concepts in the Course Registration

System.

9.2.1 OURS

Online University Registration System

9.2.2 Academic staff

A person working in academic affair and managing academic information (student, lecturer,

course offering, department and faculty)

9.2.3 Finance staff

A person working in finance office and managing finance activities (tuition fee, etc)

9.2.4 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.

9.2.5 Faculty

All students belong to a faculty which is responsible for the academic affair of a field of study in

the University

9.2.6 Curriculum

All the courses in a faculty a student studies in university.

9.2.7 Subject

Name of a course opened by university

9.2.8 Course Offering

A specific course with a lecturer opened in a specific semester offered by Academic affair staff

for some faculties

9.2.9 Prerequisite

A prerequisite of a course is courses a student must finish in order to take this course


65

9.2.10 Course Catalog

The catalog of all courses offered by the university

9.2.11 Lecturer

A person teaching courses at the university

9.2.12 Student

A person enrolled in courses at the university. A student belongs to one faculty.

9.2.13 Student priority

The background of the student to get discount in tuition fee

9.2.14 Discount rate

The percentage of reduction of tuition fee a student can get for his priority

9.2.15 Grade

The academic result of a particular student for a particular course offering

9.2.16 Schedule

The list of course offering a student has selected to study the current semester.

9.2.17 Tuition fee

A fee student needs to pay for university in a semester.

9.2.18 Credit

A unit to represent the weight of a subject

9.2.19 Academic duration

Planned time for student for study in university

9.2.20 Academic year

Each academic year in the university consists two semesters, starts from September and ends in

May the following year (Ex: 2007-2008)