Upload
muawiyah
View
226
Download
0
Embed Size (px)
Citation preview
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
8/8/2019 Online Course Mgmt Sys- Case
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
8/8/2019 Online Course Mgmt Sys- Case
3/65
8/8/2019 Online Course Mgmt Sys- Case
4/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
5/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
6/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
7/65
Business Plan & SRS Document
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/8/2019 Online Course Mgmt Sys- Case
8/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
9/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
10/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
11/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
12/65
Business Plan & SRS Document
12
3.2 Phan Duy Tan estimationName : Phan Duy Tan 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 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
8/8/2019 Online Course Mgmt Sys- Case
13/65
Business Plan & SRS Document
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
3 Analyze behaviors 1 1
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
20 Implement business logic layer 10 10
21 Implement presentation layer 6 1 7 Environment integration
8/8/2019 Online Course Mgmt Sys- Case
14/65
Business Plan & SRS Document
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
29 Team review & evaluation 1 1
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
4 Team review & evaluation 1 1
5 Complete all docu ments 3 3
6 Review 4 1 1
8/8/2019 Online Course Mgmt Sys- Case
15/65
Business Plan & SRS Document
15
3.3 Tran Minh Phung estimationName : Tran Minh Phung 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 wa iting time project overhead
No. Task Est Del1 Del2 Del3 Del4 Total Assumption
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
8/8/2019 Online Course Mgmt Sys- Case
16/65
Business Plan & SRS Document
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
18Complete functionalrequirement 1 1
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
23 SRS inspection 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
3 Analyze behaviors 1 1
4 Complete analysis model 2 2
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
Complete Implementation
model 2 2
13
Complete Implementation
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
8/8/2019 Online Course Mgmt Sys- Case
17/65
Business Plan & SRS Document
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
29 Team review & evaluation 1 1 2
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
4 Team review & evaluation 1 2 3
5 Comple te all documents 4 3 1 8
6 Review 4 1 1
8/8/2019 Online Course Mgmt Sys- Case
18/65
Business Plan & SRS Document
18
3.4 Nguyen Duc Quan estimationName :Nguyen Duc Quan 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 wa iting time project overhead
No. Task Est Del1 Del2 Del3 Del4 Total Assumption
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
8/8/2019 Online Course Mgmt Sys- Case
19/65
Business Plan & SRS Document
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
Manage the scope of the
system 6 2 1 1 10
Must perform scope management during therequirement phase
22 Complete SRS 1 1
23 SRS inspection 1 1
24 Test Plan 1 1 2
25 Test case 1 1 2
26 Detail WBS 1 1
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 2 1 3
2 Refine the architecture 1 1
3 Analyze behaviors 1 1
4 Complete analysis model 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
Complete Implementation
guidelines & code conventions 1 1
14 Produce Integra tion build plan 1 1
15 Review OOAD 1 1
8/8/2019 Online Course Mgmt Sys- Case
20/65
Business Plan & SRS Document
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
29 Team review & evaluation 1 1
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
4 Team review & evaluation 2 2
5 Comple te all documents 4 1 1 6documentation follows RUP standard
6 Review 4 1 1
8/8/2019 Online Course Mgmt Sys- Case
21/65
Business Plan & SRS Document
21
3.5 Le Vu Hoang estimationName : Le Vu Hoang 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 wa iting time project overhead
No. Task Est Del1 Del2 Del3 Del4 Total Assumption
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
8/8/2019 Online Course Mgmt Sys- Case
22/65
Business Plan & SRS Document
22
18Complete functionalrequirement 4 4
19
Complete non-functional
requirements 4 4
20 Define the system 2 1 3 Itera tion abuse
21
Manage the scope of the
system 10 3 13 Define carefully scope22 Complete SRS 1 1
23 SRS inspection 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
27 Re-estimation & assumption 2 2
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
Complete Implementation
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
20 Implement business logic 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
8/8/2019 Online Course Mgmt Sys- Case
23/65
Business Plan & SRS Document
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
29 Team review & evaluation 1 1
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
4 Team review & evaluation 3 3
5 Complete all docu ments 5 2 7 Need time for rev iew
6 Review 4 1 1
8/8/2019 Online Course Mgmt Sys- Case
24/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
25/65
8/8/2019 Online Course Mgmt Sys- Case
26/65
Business Plan & SRS Document
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)
8/8/2019 Online Course Mgmt Sys- Case
27/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
28/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
29/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
30/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
31/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
32/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
33/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
34/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
35/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
36/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
37/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
38/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
39/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
40/65
Business Plan & SRS Document
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.
2. The Academic Affair Staff chooses a department.
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.
8/8/2019 Online Course Mgmt Sys- Case
41/65
Business Plan & SRS Document
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
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,
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
- Faculty
8/8/2019 Online Course Mgmt Sys- Case
42/65
Business Plan & SRS Document
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.
2. The Academic Affair Staff chooses a department.
3. The system returns a list of lecturers of that department.
4. The Academic Affair Staff chooses a lecturer.
5. The system provides the Academic Affair Staff with a summary of
information of selected lecturer.
6. The Academic Affair Staff makes the desired changes to the lecturer
information and confirms. This includes any of the information
specified in the Add a Lecturer sub-flow.
7. The system prompts message MS005 to the Academic Affair Staff to
confirm the deletion of the lecturer.
8. The system updates the lecturer record.Delete a Lecturer
1. The system requests that the Academic Affair Staff choose the
department.
2. The Academic Affair Staff chooses 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 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
8/8/2019 Online Course Mgmt Sys- Case
43/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
44/65
Business Plan & SRS Document
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
Users Academic Affair Staff
Precondition User logged in the system as the role of Academic Affair Staff.
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
8/8/2019 Online Course Mgmt Sys- Case
45/65
Business Plan & SRS Document
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.
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 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
7. The system prompts message MS007 to the Academic Affair Staff to
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
8/8/2019 Online Course Mgmt Sys- Case
46/65
Business Plan & SRS Document
46
delete.
5. The system prompts message MS008 to the Academic Affair Staff to
confirm the deletion of the student(s).
6. The Academic Affair Staff confirms the deletion.
7. The system deletes the selected student(s).Search Student(s)
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(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.
8/8/2019 Online Course Mgmt Sys- Case
47/65
Business Plan & SRS Document
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
Users Academic Affair Staff
Precondition User logged in the system as the role of Academic Affair Staff.
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.
8/8/2019 Online Course Mgmt Sys- Case
48/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
49/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
50/65
Business Plan & SRS Document
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).
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 thefilters inputs with tuition fee and tuition fee status.
Update tuition fee status
8/8/2019 Online Course Mgmt Sys- Case
51/65
Business Plan & SRS Document
51
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
filters 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 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.
8/8/2019 Online Course Mgmt Sys- Case
52/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
53/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
54/65
Business Plan & SRS Document
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.
8/8/2019 Online Course Mgmt Sys- Case
55/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
56/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
57/65
Business Plan & SRS Document
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
8/8/2019 Online Course Mgmt Sys- Case
58/65
Business Plan & SRS Document
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