online course mgmt sys- case

8/8/2019 Online Course Mgmt Sys- Case

1/65

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


2/65

Business Plan & SRS Document

2

Table of Contents1. 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/65


4/65


4

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

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

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

9.2.2 Academic staff............................................................................ ................................649.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/65


5

1. STATEMENT OF WORKAs 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 DepartmentInformation

Manage Lecturer Information

Manage Department

Information

Manage Student Information

Manage Courses Offering

Financial Office Staffs View Tuition Fee

StudentsView 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 systemrequest 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/65


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


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 intophysical 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/65


8

2. RESOURCE LIST2.1 Human

2.2 SoftwareDocumentation tool Microsoft word 2007

Scheduling tool Microsoft project 2007

IDE Netbean 6.0

Web Server Glassfish server 2.0

Design toolPhotoshop 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 HardwareClient 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/65


9

3. ESTIMATION3.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 quali ty tasks waiting time project overhead

No. Task Est Del1 Del2 Del3 Del4 Total Assumption

Initial

1 Wri te 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 3The key user and stakeholder varies andchanges

4Gather user and stakeholderideas

2 3 5 -5 5 Difficult in getting appointmen t and interv iew

5 Write Project background 2 0.5 0.5 36 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 2The document should be review again andcheck any existing error

10 Team Review 3 -1 2 Team gather la te and far dis tance

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 7The document is long and complex, need moretime to review

7 Analyze ini tial require ment 2 2 2 6

8Understand stakeholder & userneeds 1 1 -2 2 2

9 Complete glossary 2 1 1 4 The glossary should be exac t and comple te

10 Login use case 1 1 -2 3 3

11 Manage facul ty use case 1.5 2

12 Manage lec turer use case 1 1 1 3 The use case should be rev iewed many times

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

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

15 View acade mic his tory 2 2 1 5

16 Register courses use case 3 1 1 1 6

17 Manage financial activi ties 3 2 -3 1 3 Financial activi ties are quite complex


10/65


10

18Complete functionalrequirement 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 architec ture 1 1 1 3 The architecture grows rap idly

6 Design GUI 2 1 3

7 Design database 1.5 2

8 Design persis tence layer 2 1 3

9 Design business logic layer 1.5 2

10 Design presen tation layer 1.5 1 3

11 Design tes t case 2 2

12Complete Implementationmodel 1 1 2

13Complete Implementationguidelines & code conventions 2 2

14 Produce Integra tion build plan 1 1

15 Review OOAD 1 1

16 Create file struc ture of system 1 1

17 Implement GUI 10 10

18 Implement database 9 2 11 No exper ience in using MyS QL

19 Implement persis tence layer 11 11

20 Implement business logic layer 9 9

21 Implement presen tation layer 9 9

22Review code & updatechanges 2 1 3 Fixing bugs and updates encounter difficul ty

23 Integra ted build 2 2


11/65


11

24 Do integration tes t 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 establishedbetween this duration to ensure the report is

defection-free and coherent28 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 Manua l 3 2 1 1 7 User manual must be in detail

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

4 Team review & evaluation 2 2

5 Complete all docu ments 2 2 3 7

6 Review 4 2 2


12/65


12

3.2 Phan Duy Tan estimationName : Phan Duy Tan Date: 11/09/2007 Estimation form ///


Category x goal tasks x quali ty tasks waiting time projec t overhead

No.Task Est. Del1 Del2 Del3 Del4 Total Assumption

Initial

1 Wri te 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

4Login 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 rev iew

7 Write Scope statement 0.5 0.5 1 rev iew

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

9Complete vision and scope 0.5 0.5 1

All parts of Vision and Scope document have tobe 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 ini tial require ment 2 1 3 Review

8

Understand stake holder &

user needs 2 2

9 Complete glossary 0.5 0.5 1 Double-check term defini tions10 Login use case 1 1

11 Manage facul ty 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. It is difficult tochoose one


13/65


13

15 View acade mic his tory 1 1

16 Register courses use case 4 -1 3 Team brainstorming

17 Manage financial activi ties 2 -1 1 only simple activi ties

18Complete functionalrequirement 3 3

19 Complete non-functionalrequirements 3 3

20 Define the system 2 1 3 Review

21Manage the scope of thesystem 2 2

22 Complete SRS 1 1 2 Use cases are wri tten 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-estima te tasks

28 Detail Schedu le 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 archi tecture is complex


4 Complete analysis model 1 1

5Complete design model &system architecture 2 1 3 Review

6 Design GUI 1 17 Design database 2 2

8 Design pers istence layer 1 1

9 Design business logic layer 1 1

10 Design presentation layer 1 1

11 Design tes t case 2 1 3 tes t case docu ment

12Complete Implementationmodel 2 2

13

Complete Implementation

guidelines & code conventions 0.5 0.5

14 Produce Integra tion build plan 0.5 1

15 Review OOAD 0.5 0.5 1 Debate16 Create file struc ture of system 0.5 0.5 1 Packaging

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

18 Implement database 4 4 2 1 11 First time using MyS QL

19 Implement persis tence layer 9 9


21 Implement presentation layer 6 1 7 Environment integration


14/65


14

22Review code & updatechanges 1 1

23 Integra te build 1 1

24 Do integration test 2 -1 1 No exper ience

25 Test build 2 2

26 Test system 2 227 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 Comple te User Manual 6 -1 5 Thuc has a very good writing skill

3 Do acceptance test 3 3


5 Complete all docu ments 3 3

6 Review 4 1 1


15/65


15

3.3 Tran Minh Phung estimationName : Tran Minh Phung Date: 11/09/2007 Estimation form ///


Category x goal tasks x quali ty tasks wa iting time project overhead


Initial

1 Wri te 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

ideas3 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 2Vision and Scope documents is baseline

2 Plan for risk 3 2 1 1 5Candidate 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 ini tial require ment 2 2

8Understand 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 facul ty use case 2 0.5 0.5 3

12 Manage lec turer use case 3 0.5 0.5 4


16/65


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 activi ties 1 0.5 2


19Complete non-functionalrequirements 3 1 4

20 Define the system 7 0.5 0.5 8

21Manage the scope of thesystem 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



5Complete design model &system architecture 2 2

6 Design GUI 1 1 2

7 Design database 1 1 2

8 Design persis tence layer 1 1 2

9 Design business logic layer 1.5 0.5 2

10 Design presen tation layer 1.5 0.5 2

11 Design tes t case 1.5 0.5 2

12


model 2 2

13


guidelines & code conventions 1 114 Produce Integra tion build plan 2 2

15 Review OOAD 1 1

16 Create file struc ture of system 1.5 0.5 2

17 Implement GUI 10 2 12

18 Implement database 8 1.5 0.5 10

19 Implement persis tence layer 9 0.5 0.5 10


17/65


17

20 Implement business logic layer 8 0.5 0.5 1 10

21 Implement presen tation layer 7 2 1 10

22

Review code & update

changes 1 1 2

23 Integra te build 1 1 2

24 Do integration tes t 1 1 225 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 Comple te User Manual 6 1 1 8

3 Do acceptance test 4 2 6


5 Comple te all documents 4 3 1 8

6 Review 4 1 1


18/65


18

3.4 Nguyen Duc Quan estimationName :Nguyen Duc Quan Date: 11/09/2007 Estimation form ///




Initial

1 Wri te 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

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

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 11lack 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 2must be more detail than vision and scope

7 Analyze ini tial require ment 1 1 2

8Understand stake holder &user needs 2 2

9 Comple te glossary 2 2

10 Login use case 3 -1 2 Login is a popu lar function


19/65


19

11 Manage facul ty 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 acade mic his tory 2 1 3

16 Register courses use case 2 1 3

17 Manage financial activi ties 2 1 3

18Complete functionalrequirement 1 1 1 3

19Complete non-functionalrequirements 1 1 1 3

20 Define the system 1 1 1 3

21


system 6 2 1 1 10

Must perform scope management during therequirement 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



5Complete design model &system architecture 1 1

6 Design GUI 1 1 2

7 Design database 1 1

8 Design persis tence layer 1 1

9 Design business logic layer 1 1

10 Design presen tation layer 1 1

11 Design tes t case 1 0.5 0.5 2

12Complete Implementationmodel 1 1 2

13


guidelines & code conventions 1 1

14 Produce Integra tion build plan 1 1

15 Review OOAD 1 1


20/65


20

16 Create file struc ture of system 1 1

17 Implement GUI 5 2 2 9

18 Implement database 6 1 1 1 9

19 Implement persis tence layer 7 1 9

20 Implement business logic layer 7 1 9

21 Implement presen tation layer 7 1 9

22Review code & updatechanges 1 1

23 Integra te build 1 1

24 Do integration tes t 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 12J2EE requires more works

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

3 Do acceptance test 5 5


5 Comple te all documents 4 1 1 6documentation follows RUP standard

6 Review 4 1 1


21/65


21

3.5 Le Vu Hoang estimationName : Le Vu Hoang Date: 11/09/2007 Estimation form ///




Initial

1 Wri te team introduction 1 1 2 Review introduction

2 Review system request 3 -1 2 Already have basic requ irement

3 Identify User and Stakeholder 2 1 3 Investigate and interview

4 Gather user and stakeholderideas 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 12 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 schedu le for 1 person

6 Discussion summary 1 2 3 Sum every thing in detail

7 Analyze ini tial require ment 2 -1 1 Stifling

8

Understand stake holder &

user needs 3 3

9 Comple te glossary 2 2

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

11 Manage facul ty 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 acade mic his tory 3 3

16 Register courses use case 3 3

17 Manage financial activi ties 2 2


22/65


22


19

Complete non-functional

requirements 4 4

20 Define the system 2 1 3 Itera tion abuse

21


system 10 3 13 Define carefully scope22 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 Schedu le 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

5Complete design model &system architec ture 3 -1 2 Hoang is pro fessional

6 Design GUI 2 1 3 Use AJAX

7 Design database 1 1

8 Design pers istent layer 2 2

9 Design business logic layer 2 210 Design presentation layer 1 1 2 Use AJAX

11 Design tes t case 0.5 0.5 1 Many test cases

12Complete Implementationmodel 1 1

13


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

14 Produce Integra tion build plan 1 1 2 Extract Method

15 Review OOAD 3 -1 2 Defect tracking

16 Create file struc ture 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 tool19 Implement persis tence layer 9 9


21 Implement presentation layer 10 10

22Review code & updatechanges 4 -1 -1 2 Good Progra mming skill

23 Integra te build 1 1 2 No experience

24 Do integration tes t 2 2


23/65


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 Comple te User Manual 10 -1 9 Good English skill

3 Do acceptance test 4 0.5 0.5 1 6 Need rework


5 Complete all docu ments 5 2 7 Need time for rev iew

6 Review 4 1 1


24/65


24

4. SCHEDULE4.1 Task list

No. Task DurationStart

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 Team11 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 Quan21 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/65


26/65


26

76 Complete test report 4 days 01/12/2007 04/12/2007Phung,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 Team81 Complete source code 6 days 10/12/2007 15/12/2007 Hoang,Ta

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


27

5. RISK PLANRisk 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 course5 4 20

Assign tasks of these people to Quan &

Tan, Work overtime.

Components developed

separately cannot be

integrated eas ily, 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 12Add more tasks for remaining members,

add more time to work

Peoples assignments do not

match their strengths3 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 changesmanagement 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/65


28

Low motivation and moral

reduce productivity2 3 6

Operate some relax actions to recharge

team spirit

Team member needs extratime 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 notrequired will extends the

schedule.

1 2 2

Analysis carefully requirements, review

requirements and design, if extra functionappears, change schedule to add more

time for working


29/65


29

6. DISCUSSION SUMMARY6.1 Project background6.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 offices 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/65


30

6.1.2 Scope of projectThe list of features which are developed:

Feature Description

Login and

logout

o This feature allows user to log in the system to achieve the accesspermission 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 theuser to his/her specific homepage (student, administrator or officers).

o Otherwise, the system warns the user with the error messages. Theaccount 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 AcademicHistory

o This feature allows a Student to view his studying progress. TheStudent 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 Students 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 beforeallowing 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 studentinformation 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/65


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 students 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/65


32

6.2 Perspectives6.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 courseinformation, 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 systems

development and improvement


33/65


33

6.3 Project objectives6.3.1 Know business rules

1. In the old paper-based mechanism, the process of registration as followa. 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 diagramsSystem 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/65


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 CourseOffering

Manage Student

Manage FinancialActivities

View AcademicHistory

Register Courses

Student

Academic Affair Staff

Financial Office Staff

Login&Logout

uses

uses

uses

uses

uses

uses

uses

usesuses

uses


35/65


35

6.3.3 Assumptions and dependencies1. 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 constraint1. The system will be developed using J2EE technology

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

6.4 Risks1. 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 l imited 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, andextra rework.

11.Peoples 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/65


36

6.5 Known future enhancements1. 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 outof 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 ReferencesFor further information, the reader should examine the Vision and Scope document, the

SRS document.

6.7 Open, unresolved, or TBD issuesSchedule and time table construction are not completed at the recent time


37/65


37

7. SOFTWARE REQUIREMENT SPECIFICATION7.1 USE CASE SPECIFICATION7.1.1 Log in and Log outName Use Case: Log in and Log out

SummaryThis 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

eventThis 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 passwordfor 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/65


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


39

7.1.2 Manage Department InformationName Use Case: Manage Department Information

SummaryThis 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

eventThis 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, oneof 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/65


40

2. Once the Academic Affair Staff provides the requested information andconfirms, the department is added to the system.

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

Update a Department

1. The system requests the Academic Affair Staff to choose a departmentto 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, thesystem updates the department record.

Delete a Department

1. The system requests the Academic Affair Staff to choose a departmentto 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/65


41

7.1.3 Manage Lecturer InformationName Use Case: Manage Lecturer Information

SummaryThis 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

eventThis 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 functionhe/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 Adda 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 lecturerinformation. This includes:

- Name

- Date of birth

- Cell-phone

- Email

- Faculty


42/65


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.


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.


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 toconfirm the deletion of the lecturer.

8. The system deletes the lecturer from the system

Alternatives Delete Cancelled


43/65


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


44

7.1.4 Manage Student InformationName Use Case: Manage Student Information

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

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, oneof 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/65


45

- Address

- Faculty

- Priority(a child of dead or wounded soldiers, belong to highlandarea, or other priority)

- Academic Year

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

confirmations, the student is added to the system.


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 necessaryinformation for the filters, and confirms to search.

3. The system returns a list of student whose information matches thefilters inputs

4. The Academic Affair Staff chooses the student that he/she wants toupdate.

5. The system displays the student information

6. The Academic Affair Staff makes the desired changes to the studentinformation. This includes any of the information specified in the Add a

Student sub-flow


confirm the updating of the student.

8. The system updates the student informationDelete 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

filters inputs

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


46/65


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)



course).

2. The Academic Affair Staff chooses a filter group, then inputs necessaryinformation for the filters, and confirms to search.

3. The system returns a list of student(s) whose information matches thefilters inputs.

Alternatives

paths

Student Not Found

In Search a Student sub-flows, if theres no student whose information

matches the filters 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 BasicFlow 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/65


47

7.1.5 Manage Course OfferingName Use Case: Manage Course Offering

SummaryThis 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/shewould like to perform :

- Create List of course offerings

- Update List of course offerings

4. Once Academic affair staff chooses a function, one of the followingsub-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 Updatelist of course offerings,

UpdateList of course offerings sub-flow is executed

Create list of course offerings

1. The system displays curriculum of the selected faculty.


48/65


48

2. Repeat sub flow Add an offering course until Academic Affair Staffcompletes 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 subject3. 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/65


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 theBasic 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/65


50

7.1.6 Manage Financial ActivitiesName Use Case: Manage Financial Activities

SummaryThis use case allows Financial Office Staff to monitor students 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

eventThis 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, oneof 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 thefilters inputs with tuition fee and tuition fee status.

Update tuition fee status


51/65


51



course).



3. The system returns a list of student whose information matches the

filters inputs with tuition fee and tuition fee status.

4. The Academic Affair Staff changes tuition fee status of specific student.


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 theres no student whose information

matches the filters 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/65


52

7.1.7 View Academic HistoryName Use Case: View Academic History

SummaryThis 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

eventThis 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/65


53

7.1.8 Register CourseName Use Case: Register Course

SummaryThis 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

eventThis 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 Students 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/dropcourse.

3. The system retrieves a list of available course offerings from the CourseCatalog 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/65


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 theStudent, 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/65


55

Appendix

Message ID Type Context Error Messages Actions

MS001 InfoAuthentication

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 usedThis account is being used by

another user.OK

MS004 Question Delete a departmentAre you sure you want to delete

the selected department?OK Cancel

MS005 Question Update a lecturerAre you sure you want to update

the current displayed lecturer?OK Cancel

MS006 Question Delete a lecturerAre you sure you want to delete

the selected lecturer?OK Cancel

MS007 Question Update a studentAre you sure you want to update

the modified student?OK Cancel

MS008 Question Delete a studentAre you sure you want to delete

the selected student?OK Cancel

MS009 Info Student not foundThe selected student does not

existOK

MS010 InfoNo list of course

offering

This faculty has no list of course

offering yetOk

MS011 QuestionUpdate tuition fee

status

Are you sure you want to update

tuition fee status of currentOK Cancel


56/65


56

student?

MS012 Info Student not found Cannot find the result. OK

MS013 Info Course RegistrationClosed

The course registration has beenclosed

OK

MS014 InfoRegister more than

30 credits

You cannot register more than 30

creditsOK

MS015 InfoRegister less than 30

credits

You cannot register less than 30

creditsOK

MS016 Question Submit a scheduleAre you sure you want to submit

this schedule?OK Cancel

MS017 QuestionReset changes to a

schedule

Are you sure you undo all the

changes you have made?OK Cancel


57/65


57

7.2 FUNCTIONAL REQUIREMENTName FR-1: Department & Faculty relationship

Summary There exists department that no student

studies in it.

Rationale The concepts of department and faculty arenot 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/65


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 ar

online course mgmt sys- case

Documents