Project Plan And Srs Final

Business Plan & SRS Document 11/9/2007 Ho Chi Minh National University – International University Instructor: Phan Viet Hoang Group 6 November 9th , 2007 Date Version 1.0 Status Baseline Author Team TiHonMum Mim Reviewer Team TiHonMum Mim Documenter Nguyen Duc Quan Team member Signature Nguyen Duc Quan Le Vu Hoang Tran Minh Phung Phan Duy Tan Huynh Da Thuc

Business Plan & SRS Document Table of Contents 1. STATEMENT OF WORK.................................................................................................................5 2. RESOURCE LIST............................................................................................................................8 2.1 Human ................................................................................................................................8 2.2 Software .............................................................................................................................8 2.3 Hardware ............................................................................................................................8 3. ESTIMATION ...............................................................................................................................9 3.1 Huynh Da Thuc estimation ...................................................................................................9 3.2 Phan Duy Tan estimation....................................................................................................12 3.3 Tran Minh Phung estimation ..............................................................................................15 3.4 Nguyen Duc Quan estimation .............................................................................................18 3.5 Le Vu Hoang estimation .....................................................................................................21 4. SCHEDULE.................................................................................................................................24 4.1 Task list .............................................................................................................................24 4.2 Gantt chart (reference) ......................................................................................................26 5. RISK PLAN .................................................................................................................................27 6. DISCUSSION SUMMARY .............................................................................................................29 6.1 Project background............................................................................................................29 6.1.1 Purpose of project ......................................................................................................29 6.1.2 Scope of project .........................................................................................................30 6.2 Perspectives ......................................................................................................................32 6.2.1 Who will use the system?............................................................................................32 6.2.2 Who can provide input about the system? ...................................................................32 6.3 Project objectives ..............................................................................................................33 6.3.1 Know business rules....................................................................................................33 6.3.2 System information and/or diagrams ...........................................................................33 2

Business Plan & SRS Document 6.3.3 Assumptions and dependencies ..................................................................................35 6.3.4 Design and implementation constraint ........................................................................35 6.4 Risks..................................................................................................................................35 6.5 Known future enhancements..............................................................................................36 6.6 References ........................................................................................................................36 6.7 Open, unresolved, or TBD issues.........................................................................................36 7. SOFTWARE REQUIREMENT SPECIFICATION .................................................................................37 7.1 USE CASE SPECIFICATION ...................................................................................................37 7.1.1 Log in and Log out ......................................................................................................37 7.1.2 Manage Department Information ................................................................................39 7.1.3 Manage Lecturer Information......................................................................................41 7.1.4 Manage Student Information ......................................................................................44 7.1.5 Manage Course Offering .............................................................................................47 7.1.6 Manage Financial Activities .........................................................................................50 7.1.7 View Academic History ...............................................................................................52 7.1.8 Register Course ..........................................................................................................53 Appendix ..................................................................................................................................55 7.2 FUNCTIONAL REQUIREMENT ..............................................................................................57 7.3 NON-FUNCTIONAL REQUIREMENT ......................................................................................61 7.3.1 Performance: .............................................................................................................61 7.3.2 Reliability: ..................................................................................................................61 7.3.3 Availability: ................................................................................................................61 7.3.4 Efficiency: ..................................................................................................................61 7.3.5 Supportability:............................................................................................................61 7.3.6 Integrity: ....................................................................................................................61 7.3.7 Portability: .................................................................................................................61 7.3.8 Flexibility:...................................................................................................................62 8. INSPECTION REPORT..................................................................................................................63 9. GLOSSARY.................................................................................................................................63 3

Business Plan & SRS Document 9.1 Introduction ......................................................................................................................63 9.2 Definitions.........................................................................................................................64 9.2.1 OURS .........................................................................................................................64 9.2.2 Academic staff............................................................................................................64 9.2.3 Finance staff...............................................................................................................64 9.2.4 Department ...............................................................................................................64 9.2.5 Faculty.......................................................................................................................64 9.2.6 Curriculum .................................................................................................................64 9.2.7 Subject.......................................................................................................................64 9.2.8 Course Offering ..........................................................................................................64 9.2.9 Prerequisite ...............................................................................................................64 9.2.10 Course Catalog ...........................................................................................................65 9.2.11 Lecturer .....................................................................................................................65 9.2.12 Student......................................................................................................................65 9.2.13 Student priority ..........................................................................................................65 9.2.14 Discount rate..............................................................................................................65 9.2.15 Grade.........................................................................................................................65 9.2.16 Schedule ....................................................................................................................65 9.2.17 Tuition fee..................................................................................................................65 9.2.18 Credit.........................................................................................................................65 9.2.19 Academic duration .....................................................................................................65 9.2.20 Academic year............................................................................................................65 4

Business Plan & SRS Document 1. STATEMENT OF WORK As the head of information systems for International University, our team is tasked with developing a new Online Course Registration System. The system will allow students to access the system during registration time to register for courses, add or drop the registered courses, check tuition fee, and review their academic history. The academic affair staffs will use the system as a mean to manage information of departments, faculties, students and offering courses. The system also supports financial office staffs in monitoring financial activities. The features of the systems can be summarized as the following table: Group of users Features OURS provides All Users Login Manage Department Information Manage Lecturer Information Academic Affair Staffs Manage Department Information Manage Student Information Manage Courses Offering Financial Office Staffs View Tuition Fee View Academic History Students Register for courses Our team is going to develop the system using Rational Unified Process with use-case driven. It includes four phases (inception, elaboration, construction, and transition). And in each phase, we will go through 6 workflows only (Management, Requirement, Analysis, Design, Implementation, and Testing). In fact, all 6 workflows will be done iteratively in each phase. However, attention level of ours team on each workflow in different phases is different. In particular, Inception: It can be referred as Initial phase. In this phase we will review the initial system request from customer, do feasibility study, define the vision and scope of the new system, and the initial project plan. Elaboration: It can be referred as planning & requirement phase. In this phase we will pay attention on detail plan which includes risk plan, estimation, and detail schedule. We also capture & analyze most of requirements to define the system and analyze its behaviors. 5

Business Plan & SRS Document 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. Inception Elaboration Construction Transition 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. [Use-case driven] Design Model Test Use case Analysis Implementation Model Model Model Model Deployment Model 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. 6

Business Plan & SRS Document Analysis model: It contains use-cases and theirs realization which includes domain study, analysis classes and objects, interactions and behaviors of the system. It also defines the design constraints, test plan and test cases for the system. Analysis model is mainly done in Elaboration phase. Design model: It includes system design specifications that define the system architecture and detail design of components, database, graphical user interface, and the constraints for implementation. Design model is done in Construction phase. Deployment model: It defines how we can deploy the system so that it can run on server(s). However, we intent to develop the system running on one server only, not distributed on many server. Therefore, we will not pay much attention on deployment model. This model will be done in Construction phase. Implementation model: It defines the way we transfer from logical system architecture into physical system architecture; test components (unit testing) and integrate them together in order to form a unique system that satisfies users and stakeholders’ needs. Test model: It includes many checklists and test cases that are planned and designed in previous phases. It also requires all defects or errors to be recorded in defects and errors reports. It is done in Construction phase. The detail of each workflows and models will be presented in detail schedule, and the plan for each phase. Development team will use web-base and J2EE technologies to develop the system. 7

Business Plan & SRS Document 2. RESOURCE LIST 2.1 Human Team member Main roles Responsibilities Tran Minh Phung Tester, Integrator Integrate, test components, builds, and system Le Vu Hoang System Designer, Design components, system and implement Coder 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 Monitor, control the project; analyze Analyst, Documenter requirements and system behaviors; and do documentation 2.2 Software Documentation tool Microsoft word 2007 Scheduling tool Microsoft project 2007 IDE Netbean 6.0 Web Server Glassfish server 2.0 Photoshop CS2 Design tool Microsoft Express Web Designer JDK JDK 6.0 DBMS MySQL 5.0 Browser Internet Explorer 6.0, 7.0 Firefox, Opera Operating system Windows XP, Vista, Linux 2.3 Hardware Client 3 laptops 2 desktops Server Reuse one 24/7 available desktop to simulate the server for testing and deployment 8

Business Plan & SRS Document 3. ESTIMATION 3.1 Huynh Da Thuc estimation Name : Huynh Da Thuc Date: 11/09/2007 Estimation form /// Goal statement: To estimate the time to develop prototype for customer A and B Unit: days Category x goal tasks x quality tasks waiting time project overhead No. Task Est Del1 Del2 Del3 Del4 Total Assumption Initial 1 Write team introduction 3 1 4 The system request is quite complex than initial 2 Review system request 4 2 1 -4 3 review The key user and stakeholder varies and 3 Identify U ser and Stakeholder 4 -4 3 3 changes Gather user and stakeholder 2 3 5 -5 5 Difficult in getting appointment and interview 4 ideas 5 Write Project background 2 0.5 0.5 3 6 Write Vision statement 1 2 3 6 7 Write Scope statement 2 -1 1 2 The scope is quite simple 8 Identify risks and assumption 2 0.5 2.5 The document should be review again and 9 Complete vision and scope 1 0.5 0.5 2 check any existing error 10 Team Review 3 -1 2 Team gather late and far distance 11 Review 1 3 0.5 0.5 4 Planning 1 Complete statements of works 2 1 3 Statement of works is more complex Risk varies and should be coherent between 2 Plan for risk 4 1 -1 4 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 The document is long and complex, need more 6 Discussion summary 2 3 1 7 time to review 7 Analyze initial requirement 2 2 2 6 Understand stakeholder & user 8 needs 1 1 -2 2 2 9 Complete glossary 2 1 1 4 The glossary should be exact and complete 10 Login use case 1 1 -2 3 3 11 Manage faculty use case 1.5 2 12 Manage lecturer use case 1 1 1 3 The use case should be reviewed many times 13 Manage student use case 0.5 2 3 The use case should be reviewed many times 14 Manage courses offering 2 1 1 4 The use case should be reviewed many times 15 View academic history 2 2 1 5 16 Register cour ses use case 3 1 1 1 6 17 Manage financial activities 3 2 -3 1 3 Financial activities are quite complex 9

Business Plan & SRS Document Complete functional 18 requirement 1 1 -4 4 2 Complete non- functional 19 requirements 2 1 3 20 Define the system 1 1 3 1 6 Team should consider carefully this part Manage the scope of the 21 system 2 1 1 1 5 Requirement is complex and should be 22 Complete SRS 1 1 1 3 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 Complete design model & 5 system architecture 1 1 1 3 The architecture grows rapidly 6 Design GUI 2 1 3 7 Design database 1.5 2 8 Design persistence layer 2 1 3 9 Design business logic layer 1.5 2 10 Design presentation layer 1.5 1 3 11 Design test case 2 2 Complete Implementation 12 model 1 1 2 Complete Implementation 13 guidelines & code conventions 2 2 14 Produce Integration build plan 1 1 15 Review OOAD 1 1 16 Create file structure of system 1 1 17 Implement GUI 10 10 18 Implement database 9 2 11 No experience in using MySQL 19 Implement persistence layer 11 11 20 Implement business logic layer 9 9 21 Implement presentation layer 9 9 Review code & update 22 changes 2 1 3 Fixing bugs and updates encounter difficulty 23 Integrated build 2 2 10

Business Plan & SRS Document 24 Do integration test 1 1 2 25 Test build 1 1 2 26 Test system 2 1 3 System should be tested well Inspection meeting should be established between this duration to ensure the repor t is 27 Complete test report 6 2 8 defection- free and coherent 28 Rework 4 2 6 29 Team review & evaluation 1 1 2 30 Review 3 1 2 3 Closing Need coherence and re-check logic 1 Complete sour ce code 6 2 4 12 functionality 2 Complete User Manual 3 2 1 1 7 User manual must be in detail 3 Do acceptance test 3 1 1 5 Acceptance test is brand new to team 4 Team review & evaluation 2 2 5 Complete all documents 2 2 3 7 6 Review 4 2 2 11

Business Plan & SRS Document 3.2 Phan Duy Tan estimation Name : 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 quality tasks waiting time pr oject overhead No. Task Est. Del1 Del2 Del3 Del4 Total Assumption Initial 1 Write team introduction 0.5 0.5 1 discuss 2 Review system request 0.5 0.5 1 additional requirement 3 Identify U ser and stakeholder 1 1 1 3 Interview 2 members do not know requirements provides Login use case 4 -2 2 last year 4 Write Project background 1 1 2 Spend time to understand current problem 5 6 Write Vision statement 0.5 0.5 1 review 7 Write Scope statement 0.5 0.5 1 review Identify risks and assumption 3 -1 2 4 cannot find all risk and assumption 8 All par ts of Vision and Scope document have to Complete vision and scope 0.5 0.5 1 be finished 9 10 Team Review 1 11 Review 1 0.5 0.5 Planning 1 Complete statements of works 0.5 0.5 2 Plan for risk 6 4 -1 9 Need a lot of meeting to identify mitigation plan 3 WBS 0.5 0.5 4 Estimation & assumption 1 1 5 Schedule 0.5 0.5 6 Discussion summary 1 1 7 Analyze initial requirement 2 1 3 Review Understand stake holder & 8 user needs 2 2 9 Complete glossary 0.5 0.5 1 Double-check ter m definitions 10 Login use case 1 1 11 Manage faculty use case 1 1 12 Manage lecturer use case 1 1 13 Manage student use case 2 2 There are many solutions in solving problem of Manage courses offering 4 -1 1 4 course offering management. It is difficult to choose one 14 12

Business Plan & SRS Document 15 View academic history 1 1 16 Register cour ses use case 4 -1 3 Team brainstor ming 17 Manage financial activities 2 -1 1 only simple activities Complete functional 18 requirement 3 3 Complete non- functional 19 requirements 3 3 20 Define the system 2 1 3 Review Manage the scope of the 21 system 2 2 22 Complete SRS 1 1 2 Use cases are written in details 23 SRS inspection 1 1 24 Test Plan 2 1 3 No experience 25 Test case 2 1 3 Review 26 Detail WBS 0.5 0.5 27 Re-estimation & assumption 0.5 0.5 1 Under-estimate tasks 28 Detail Schedule 0.5 0.5 29 Team review 1 1 30 Review 2 1 1 Executing 1 Define candidate architecture 3 2 5 J2EE architecture is complex 2 Refine the architecture 1 1 2 J2EE architecture is complex 3 Analyze behaviors 1 1 4 Complete analysis model 1 1 Complete design model & 5 system architecture 2 1 3 Review 6 Design GUI 1 1 7 Design database 2 2 8 Design persistence layer 1 1 9 Design business logic layer 1 1 10 Design presentation layer 1 1 11 Design test case 2 1 3 test case document Complete Implementation 12 model 2 2 Complete Implementation 13 guidelines & code conventions 0.5 0.5 14 Produce Integration build plan 0.5 1 15 Review OOAD 0.5 0.5 1 Debate 16 Create file structure of system 0.5 0.5 1 Packaging Tan has a lot of experience in implementing 17 Implement GUI 6 -1 -1 1 5 GUI 18 Implement database 4 4 2 1 11 First time using MySQL 19 Implement persistence layer 9 9 20 Implement business logic layer 10 10 21 Implement presentation layer 6 1 7 Environment integration 13

Business Plan & SRS Document Review code & update 22 changes 1 1 23 Integrate build 1 1 24 Do integration test 2 -1 1 No experience 25 Test build 2 2 26 Test system 2 2 27 Complete test report 3 2 5 Fix new defects 28 Rework 3 3 29 Team review & evaluation 1 1 30 Review 3 1 1 Closing 1 Complete sour ce code 10 -1 -1 8 use IDE 2 Complete User Manual 6 -1 5 Thuc has a very good writing skill 3 Do acceptance test 3 3 4 Team review & evaluation 1 1 5 Complete all documents 3 3 6 Review 4 1 1 14

Business Plan & SRS Document 3.3 Tran Minh Phung estimation Name : 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 quality tasks waiting time project overhead No. Task Est Del1 Del2 Del3 Del4 Total Assumption Initial Understanding the problems 1 Write team introduction 2 0.5 0.5 3 2 Review system request 2 1 0.5 0.5 4 3 Identify U ser and Stakeholder 2 0.5 0.5 3 Gather user and stakeholder 3 1 1 5 Use all existed documents ideas 4 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 Have enough all information 9 Complete vision and scope 1 0.5 0.5 2 10 Team Review 1 1 11 Review 1 1 1 Planning Vision and Scope documents is baseline 1 Complete statements of works 1 0.5 0.5 2 Candidate risks must be listed out already 2 Plan for risk 3 2 1 1 5 3 WBS 4 0.5 0.5 1 6 4 Estimation & assumption 1.5 0.5 2 5 Schedule 2 1 3 6 Discussion summary 6 1 7 7 Analyze initial requirement 2 2 Understand stake holder & 8 user needs 1 1 1 3 9 Complete glossary 4 1 0.5 0.5 5 10 Login use case 3 0.5 0.5 4 11 Manage faculty use case 2 0.5 0.5 3 12 Manage lecturer use case 3 0.5 0.5 4 15

Business Plan & SRS Document 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 cour ses use case 4 1 1 1 7 17 Manage financial activities 1 0.5 2 Complete functional 18 requirement 1 1 Complete non- functional 19 requirements 3 1 4 20 Define the system 7 0.5 0.5 8 Manage the scope of the 21 system 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 Complete design model & 5 system architecture 2 2 6 Design GUI 1 1 2 7 Design database 1 1 2 8 Design persistence layer 1 1 2 9 Design business logic layer 1.5 0.5 2 10 Design presentation layer 1.5 0.5 2 11 Design test case 1.5 0.5 2 Complete Implementation 12 model 2 2 Complete Implementation 13 guidelines & code conventions 1 1 14 Produce Integration build plan 2 2 15 Review OOAD 1 1 16 Create file structure of system 1.5 0.5 2 17 Implement GUI 10 2 12 18 Implement database 8 1.5 0.5 10 19 Implement persistence layer 9 0.5 0.5 10 16

Business Plan & SRS Document 20 Implement business logic layer 8 0.5 0.5 1 10 21 Implement presentation layer 7 2 1 10 Review code & update 22 changes 1 1 2 23 Integrate build 1 1 2 24 Do integration test 1 1 2 25 Test build 1 0.5 0.5 2 26 Test system 3 3 27 Complete test report 6 2 1 9 28 Rework 5 2 7 29 Team review & evaluation 1 1 2 30 Review 3 1 1 Closing 1 Complete sour ce code 10 1 1 1 13 2 Complete User Manual 6 1 1 8 3 Do acceptance test 4 2 6 4 Team review & evaluation 1 2 3 5 Complete all documents 4 3 1 8 6 Review 4 1 1 17

Business Plan & SRS Document 3.4 Nguyen Duc Quan estimation Name :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 quality tasks waiting time project overhead No. Task Est Del1 Del2 Del3 Del4 Total Assumption Initial 1 Write team introduction 1 2 -1 2 2 Review system request 1 1 2 3 Identify U ser and Stakeholder 2 1 -1 2 Gather user and stakeholder Use existing requirements provided last year, 1 1 ideas additional requirements 4 5 Write Project background 1 1 6 Write Vision statement 1 1 7 Write Scope statement 1 1 this task must be done along the summary task 8 Identify risks and assumption 4 2 2 -2 6 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 lack of experience in risk mitigation 2 Plan for risk 8 2 1 -2 11 3 WBS 1 1 4 Estimation & assumption 1 1 5 Schedule 1 1 must be more detail than vision and scope 6 Discussion summary 1 0.5 0.5 2 7 Analyze initial requirement 1 1 2 Understand stake holder & 8 user needs 2 2 9 Complete glossary 2 2 10 Login use case 3 -1 2 Login is a popular function 18

Business Plan & SRS Document 11 Manage faculty use case 2 1 3 12 Manage lecturer use case 2 1 3 13 Manage student use case 2 1 3 3 members are familiar with old requirements 14 Manage courses offering 2 1 3 15 View academic history 2 1 3 16 Register cour ses use case 2 1 3 17 Manage financial activities 2 1 3 Complete functional 18 requirement 1 1 1 3 Complete non- functional 19 requirements 1 1 1 3 20 Define the system 1 1 1 3 Must per form scope management during the requirement phase Manage the scope of the 21 system 6 2 1 1 10 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 Complete design model & 5 system architecture 1 1 6 Design GUI 1 1 2 7 Design database 1 1 8 Design persistence layer 1 1 9 Design business logic layer 1 1 10 Design presentation layer 1 1 11 Design test case 1 0.5 0.5 2 Complete Implementation 12 model 1 1 2 Complete Implementation 13 guidelines & code conventions 1 1 14 Produce Integration build plan 1 1 15 Review OOAD 1 1 19

Business Plan & SRS Document 16 Create file structure of system 1 1 17 Implement GUI 5 2 2 9 18 Implement database 6 1 1 1 9 19 Implement persistence layer 7 1 9 20 Implement business logic layer 7 1 9 21 Implement presentation layer 7 1 9 Review code & update 22 changes 1 1 23 Integrate build 1 1 24 Do integration test 1 1 25 Test build 1 1 26 Test system 1 1 2 27 Complete test report 5 2 1 8 28 Rework 3 0.5 0.5 1 5 29 Team review & evaluation 1 1 30 Review 3 1 1 Closing J2EE requires more works 1 Complete sour ce code 10 2 12 Too many guidelines must be written 2 Complete User Manual 5 1 1 7 3 Do acceptance test 5 5 4 Team review & evaluation 2 2 documentation follows RUP standard 5 Complete all documents 4 1 1 6 6 Review 4 1 1 20

Business Plan & SRS Document 3.5 Le Vu Hoang estimation Name : 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 quality tasks wa iting time project overhead No. Task Est Del1 Del2 Del3 Del4 Total Assumption Initial 1 Write team introduction 1 1 2 Review introduction 2 Review system request 3 -1 2 Already have basic requirement 3 Identify U ser and Stakeholder 2 1 3 Investigate and interview Gather user and stakeholder 1 4 ideas 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 brainstor ming 9 Complete vision and scope 2 2 10 Team Review 2 2 11 Review 1 1 1 Planning 1 Complete statements of works 1 1 2 Plan for risk 12 -1 -1 10 Just find basic risk 3 WBS 1 1 4 Estimation & assumption 3 -1 2 Elicitation 5 Schedule 3 -1 2 Assign schedule for 1 person 6 Discussion summary 1 2 3 Sum everything in detail 7 Analyze initial requirement 2 -1 1 Stifling Understand stake holder & 8 user needs 3 3 9 Complete glossary 2 2 10 Login use case 6 -2 4 Login use case is simple 11 Manage faculty use case 4 4 12 Manage lecturer use case 4 4 13 Manage student use case 6 -1 5 Inspection 14 Manage courses offering 6 -1 -1 4 Just consider about offering, not class 15 View academic history 3 3 16 Register cour ses use case 3 3 17 Manage financial activities 2 2 21

Business Plan & SRS Document Complete functional 18 requirement 4 4 Complete non- functional 19 requirements 4 4 20 Define the system 2 1 3 Iteration abuse Manage the scope of the 21 system 10 3 13 Define carefully scope 22 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 Schedule 1 1 2 Misunderstood predecessor 29 Team review 2 2 30 Review 2 1 1 Executing 1 Define candidate architecture 3 -1 2 Fix J2EE model 2 Refine the architecture 0.5 0.5 3 Analyze behaviors 0.5 0.5 4 Complete analysis model 1 0.5 0.5 2 Review model Complete design model & 5 system architecture 3 -1 2 Hoang is professional 6 Design GUI 2 1 3 Use AJAX 7 Design database 1 1 8 Design persistent layer 2 2 9 Design business logic layer 2 2 10 Design presentation layer 1 1 2 Use AJAX 11 Design test case 0.5 0.5 1 Many test cases Complete Implementation 12 model 1 1 Complete Implementation 13 guidelines & code conventions 1 0.5 1.5 Replace Magic Number with sy mbolic Constant 14 Produce Integration build plan 1 1 2 Extract Method 15 Review OOAD 3 -1 2 Defect tracking 16 Create file structure of system 0.5 0.5 17 Implement GUI 7 5 12 Implement AJAX 18 Implement database 10 -1.5 -0.5 8 Use Database tool 19 Implement persistence layer 9 9 20 Implement business logic layer 9 9 21 Implement presentation layer 10 10 Review code & update 22 changes 4 -1 -1 2 Good Programming skill 23 Integrate build 1 1 2 No experience 24 Do integration test 2 2 22

Business Plan & SRS Document 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 sour ce code 16 -1 -1 14 Need system build 2 Complete User Manual 10 -1 9 Good English skill 3 Do acceptance test 4 0.5 0.5 1 6 Need rework 4 Team review & evaluation 3 3 5 Complete all documents 5 2 7 Need time for review 6 Review 4 1 1 23

Business Plan & SRS Document 4. SCHEDULE 4.1 Task list Start End Pre- No. Task Duration Resource Date Date decessor 1 Initial 11 days 02/10/2007 15/10/2007 Team 2 Write team introduction 2 days 02/10/2007 03/10/2007 Team 3 Review system request 2 days 02/10/2007 03/10/2007 Team 4 Develop vision and scope 6 days 04/10/2007 10/10/2007 3 Team 5 Identify User and Stakeholder 2 days 04/10/2007 05/10/2007 Team 6 Gather user and stakeholder ideas 1 day 06/10/2007 06/10/2007 5 Quan 7 Write Project background 1 day 08/10/2007 08/10/2007 6 Thuc 8 Write Vision statement 1 day 08/10/2007 08/10/2007 6 Phung 9 Write Scope statement 1 day 08/10/2007 08/10/2007 6 Hoang 10 Identify risks and assumption 6 days 04/10/2007 10/10/2007 5SS Team 11 Complete vision and scope 1 day 11/10/2007 11/10/2007 4 Quan 12 Team Review 1 day 12/10/2007 12/10/2007 11 Team 13 Review 1 1 day 15/10/2007 15/10/2007 12 Team 14 Planning 20 days 15/10/2007 09/11/2007 Team 15 Complete statements of works 1 day 15/10/2007 15/10/2007 Team 16 Plan for risk 11 days 15/10/2007 29/10/2007 Tan 17 WBS 1 day 15/10/2007 15/10/2007 Thuc 18 Estimation & assumption 1 day 16/10/2007 16/10/2007 17 Team 19 Schedule 1 day 17/10/2007 17/10/2007 18 Phung 20 Discussion summary 2 days 15/10/2007 16/10/2007 Quan 21 Analyze initial requirement 2 days 18/10/2007 19/10/2007 20 Team 22 Understand stake holder & user needs 2 days 22/10/2007 23/10/2007 21 Quan 23 Complete glossary 2 days 22/10/2007 23/10/2007 22SS Hoang 24 Complete use case model 3 days 24/10/2007 26/10/2007 22 Team 25 Login use case 3 days 24/10/2007 26/10/2007 Thuc 26 Manage faculty use case 3 days 24/10/2007 26/10/2007 Phung 27 Manage lecturer use case 3 days 24/10/2007 26/10/2007 Phung 28 Manage student use case 3 days 24/10/2007 26/10/2007 Phung 29 Manage offering course 3 days 24/10/2007 26/10/2007 Hoang 30 View academic history 3 days 24/10/2007 26/10/2007 Tan 31 Register courses use case 3 days 24/10/2007 26/10/2007 Tan 32 Manage financial activities 3 days 24/10/2007 26/10/2007 Quan 33 Complete functional requirement 3 days 24/10/2007 26/10/2007 Team 34 Complete non-functional requirements 3 days 24/10/2007 26/10/2007 Team 35 Define the system 3 days 24/10/2007 26/10/2007 Hoang 36 Manage the scope of the system 10 days 15/10/2007 26/10/2007 Quan 24

Business Plan & SRS Document 37 Complete SRS 1 day 29/10/2007 29/10/2007 35,33,34,24 Quan 38 SRS inspection 1 day 31/10/2007 31/10/2007 37 Team Phung, 39 Test Plan 1 day 01/11/2007 01/11/2007 37SS Thuc Phung, 40 Test case 1 day 01/11/2007 01/11/2007 37SS,39SS Thuc 41 Detail WBS 1 day 02/11/2007 02/11/2007 37,38 Quan 42 Re-estimation & assumption 1 day 05/11/2007 05/11/2007 41 Team 43 Detail Schedule 1 day 06/11/2007 06/11/2007 42 Quan 44 Team review 1 day 07/11/2007 07/11/2007 43 Team 45 Review 2 1 day 09/11/2007 09/11/2007 44 Team 46 Executing 31 days 01/11/2007 07/12/2007 Team 47 Define candidate architecture 3 days 01/11/2007 05/11/2007 Quan 48 Refine the architecture 1 day 09/11/2007 09/11/2007 47 Team 49 Analyze behaviors 1 day 09/11/2007 09/11/2007 Quan 50 Complete analysis model 1 day 10/11/2007 11/11/2007 49 Quan 51 Complete design model & system architecture 1 day 12/11/2007 12/11/2007 50 Hoang 52 Design component 1 day 13/11/2007 13/11/2007 51 Team 53 Design GUI 1 day 13/11/2007 13/11/2007 Thuc,Tan 54 Design database 1 day 13/11/2007 13/11/2007 Hoang 55 Design persistence layer 1 day 13/11/2007 13/11/2007 Hoang 56 Design business logic layer 1 day 13/11/2007 13/11/2007 Hoang 57 Design presentation layer 1 day 13/11/2007 13/11/2007 Tan Phung, 58 Design test case 1 day 13/11/2007 13/11/2007 52SS Thuc 59 Complete Implementation model 2 days 14/11/2007 15/11/2007 52 Hoang Complete Implementation guidelines 60 & code conventions 1 day 16/11/2007 16/11/2007 59 Tan 61 Produce Integration build plan 1 day 16/11/2007 17/11/2007 60SS Quan 62 Review OOAD 1 day 18/11/2007 18/11/2007 60,61 Team 63 Create file structure of system 1 day 19/11/2007 19/11/2007 62 Tan 64 Implement components & unit test & check list 9 days 19/11/2007 29/11/2007 Team 65 Implement GUI 9 days 19/11/2007 29/11/2007 Thuc 66 Implement database 9 days 19/11/2007 29/11/2007 Hoang 67 Implement persistence layer 9 days 19/11/2007 29/11/2007 Hoang 68 Implement business logic layer 9 days 19/11/2007 29/11/2007 Hoang 69 Implement presentation layer 9 days 19/11/2007 29/11/2007 Tan 70 Review code & update changes 1 day 30/11/2007 30/11/2007 64 Team 71 Integrate build 1 day 01/12/2007 01/12/2007 70 Phung 72 Testing & fix bugs 5 days 01/12/2007 05/12/2007 Team 73 Do integration test 1 day 01/12/2007 01/12/2007 Phung 74 Test build 1 day 02/12/2007 02/12/2007 73 Phung 75 Test system 1 day 03/12/2007 03/12/2007 74 Tan, Thuc 25

Business Plan & SRS Document Phung, 76 Complete test report 4 days 01/12/2007 04/12/2007 Thuc 77 Rework 5 days 01/12/2007 05/12/2007 Team 78 Team review & evaluation 1 day 06/12/2007 06/12/2007 72 Team 79 Review 3 1 day 07/12/2007 07/12/2007 78 Team 80 Closing 18 days 10/12/2007 28/12/2007 Team 81 Complete source code 6 days 10/12/2007 15/12/2007 Hoang,Tan 82 complete User Manual 7 days 10/12/2007 17/12/2007 Thuc 83 Do acceptance test 5 days 15/12/2007 20/12/2007 Phung 84 Team review & evaluation 2 days 21/12/2007 22/12/2007 Team 85 Complete all documents 6 days 18/12/2007 23/12/2007 Quan 86 Review 4 1 day 28/12/2007 28/12/2007 Team 4.2 Gantt chart (reference) 26

Business Plan & SRS Document 5. RISK PLAN Risk plan for project OURS Project Assessment team members Quan, Tan, Thuc, Phung, Hoang Risk Prob. Impact Priority Actions Assign tasks of these people to Quan & Phung, Thuc, and Hoang take 5 4 20 Tan, Work overtime. pre-thesis course Components developed Reserve time to integrated and rework for separately cannot be 4 4 16 integration in schedule. integrated easily, requiring redesign and rework. Make another informal meeting in the Development team cannot complete to deliver the 3 5 15 same week to complete them components when reviewing No substitution if any team Add more tasks for remaining members, member cannot continue to 4 3 12 add more time to work contribute to the project. Before starting; development team lists People’s assignments do not 3 4 12 out and evaluates the skills of each match their strengths member. Each team member will write a draft version of report on what he does before Detail reporting could take 4 3 12 more development time. documenter of team writes it again. Work on weekends, set schedule with All team members need time for exam; define meetings in each preparation time for 3 3 9 midterm, final exam, and week in suitable time for all people. other subjects. Lack of experiences in software project Assign 2 members working on each test. management, especially in Risk and changes management tasks will testing, verification, 3 3 9 have a long duration to finish. Support validation, risks others people about what we already management and changes known. management exists in the Team Create a detailed schedule in a whole Development time is limited project and supervise process of work with in 2 months only. Therefore, 2 3 6 schedule, change schedule with any the pressure is really high. mismatch with schedule. 27

Business Plan & SRS Document Operate some relax actions to recharge Low motivation and moral 2 3 6 team spirit reduce productivity Make clear about techniques we used, if some new techniques are needed, assign a Team member needs extra time to learn unfamiliar 2 2 4 member read them and talk to other Tools or techniques. members about them. PM has to control conflicts in team, assure Conflicts among team everybody thoughts are respected, make members’ ideas results in 2 2 4 assumptions when we have conflicts, poor performances, more record any conflicts to change if we are in meeting, and extra rework. wrong way Analysis carefully requirements, review Developing extra requirements and design, if extra function functionalities that are not 1 2 2 required will extends the appears, change schedule to add more schedule. time for working 28

Business Plan & SRS Document 6. DISCUSSION SUMMARY 6.1 Project background 6.1.1 Purpose of project There is a widespread agreement that the policy in course registration is very complicated, costly, take-time, and inconvenient to both students and university. This is due the fact that at the beginning of each semester, the university has to pause or delay some activities to spend time for course registration of students. Some staffs have to prepare for offering courses list (including selecting courses and inviting lecturers …), print it out, and deliver the registration form to each student. After around one week, all students’ registration form will be returned. In addition, the staffs have to input students’ registration information to Excel files. They also have to check manually whether the registration form of each student is legal or not basing on some conditions such as prerequisite course, maximum and minimum number of credits allowed registering … If there is anything wrong or students want to add or drop the courses, everything in the above process has to be restarted. Moreover, sometimes some papers are lost when documents are moved from one place to another place; both students and university have to spend time for retrieving necessary information and approve it. However, it is impossible to do that in some cases. In addition, calculating tuition fee for students, managing students’ academic history… are also thorny issues. Mistakes can occur anytime when financial office‘s staffs use calculator or Microsoft excel to calculate tuition fee. Students’ transcript management is also another issue. When students want to have transcript to see their academic history, they have to wait at least two weeks to receive it from academic affair. Those are some typical examples for the inconvenience and complication of the current course registration policy. They lead the university to the decision of building Online Course Registration System to improve effectiveness, reduce time and cost in course registration process. 29

Business Plan & SRS Document 6.1.2 Scope of project The list of features which are developed: Feature Description o This feature allows user to log in the system to achieve the access permission to perform other functions, which are granted to that specific user. It also lets the user log out his/her session. o If the username and password are correct, the system redirects the Login and user to his/her specific homepage (student, administrator or officers…). logout o Otherwise, the system warns the user with the error messages. The account is locked out if the user fails to log in three times. User has to wait 30 minutes for the account to be released. o Users also have another option to choose when they forget the password and intend to recover it o This feature allows a Student to view his studying progress. The View Academic Student can see the courses he has taken as well as the scores and History 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. o This feature allows a Student to register course offerings in the current Register course semester. o The system retrieves and displays the Student’s current schedule (e.g.; the schedule for the current semester). The schedule may be empty. o The student can change the schedule by adding or dropping course(s). o The system also checks the prerequisite and the total of credits before allowing that student to register the selected courses. The Student can only select a total of minimum 15 credits and maximum 30 credits. o After the Student add or drop a course, the system recalculate total credits and discount o This feature allows Academic Affair Staff to manage department and Manage faculty information. This includes adding, updating, and deleting Department department and faculty from the system. Information o This feature allows the Academic Affair Staff to manage student Manage information in the registration system. This includes adding, updating, Student deleting, and searching students from the system. Information o This feature allows Academic Affairs to monitor course offerings in one Manage 30

Business Plan & SRS Document Courses semester of specific year o The following tasks are included in this feature: Create list of course, Offering update list of course, add a course offering, delete course offering, change lecturer Manage o This feature allows the Academic Affair Staff to manage lecturer Lecturer information in the registration system. This includes adding, updating, information deleting, and searching lecturers from the system. o This feature allows Financial Office Staff to monitor student’s tuition Manage fee. This includes viewing and updating the tuition fee status of financial students. activities 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 31

Business Plan & SRS Document 6.2 Perspectives 6.2.1 Who will use the system? User Description Student The people who attending the course in the university. Use the system to register the courses and view academic history Academic Affair The Staff working in the Academic Affair Office, responsible for the Staff Academic issue in the University. Use the system to manage school, lecturer, and student information Financial Office Staff The Staff who is responsible for the financial business in the University. Use the system to monitor financial activities related to course registration 6.2.2 Who can provide input about the system? Student The Student needs an online mechanism to register, add and drop course instead of the paper based process The Student needs to view their academic history every time and every where they want instead of waiting the respond from the Academic Office Academic Affair staff 1. The Staff of the Academic Affair Staff needs to manage the course information, department information. 2. Easy to use, easy update, easy to modify Financial Office staff 1. The Staff needs to manage the financial business of the University 2. They would view the Student tuition fee status Lecturer They could give ideas or comment on the solution for the system’s development and improvement 32

Business Plan & SRS Document 6.3 Project objectives 6.3.1 Know business rules 1. In the old paper-based mechanism, the process of registration as follow a. The Students receive the Registration form and register the course for the semester b. The Registration forms are transferred to the Academic Affair Staff c. Academic Affair Staff process the Registration Form d. The Students receive the report from offering course from the Academic Affair Staff e. If any Student wants to add or drop course(s), the process restarts 2. At each beginning of the semester, the Academic Affair Staff make the list of course and provide to each Faculty to distribute to the Students. They also manage the number of Lecturer, the Department. All is the paper – based process. 3. After receiving the report from the Academic Affair Staff, the Students also receive the financial report from the Finance Office. The Finance Officers have to manage the financial information status of each student, decide the financial business of each student and make the report to each student. 6.3.2 System information and/or diagrams System context: OURS is a part of university management system. It can interact with other sub-system of university management system such as scheduling system, grading system, student management system, payment system … University Online university System registration system 33

Business Plan & SRS Document OURS will be used by students, academic affair staffs, and financial office staffs with functionalities showed in following diagram. OURS Manage Department «uses» «uses» Manage Lecturer «uses» «uses» Manage Student «uses» Academic Affair Staff Manage Course Offering Register Courses «uses» «uses» Login&Logout «uses» «uses» «uses» View Academic History Manage Financial Student Activities Financial Office Staff 34

Business Plan & SRS Document 6.3.3 Assumptions and dependencies 1. The system will be applied for universities using credit system like International University. 2. The registration information of students is processed by academic affair. And only academic affair has right to manage and process the registration information. 3. Development team will use J2EE architecture to develop system. 4. Policy for tuition fee payment is using cash and it is managed by financial office. 5. Development team must have at least one 2-hour meeting per week. 6. Development time is 2 months and 10 days 7. Development team must produce the first build before the review 3 8. Each team member must work at least 15 hours per week. 6.3.4 Design and implementation constraint 1. The system will be developed using J2EE technology 2. The system provides the service in two languages Vietnamese and English 6.4 Risks 1. All team members need preparation time for midterm, final exam, and other subjects. 2. Phung, Thuc, and Hoang take pre-thesis course. 3. Lack of experiences in software project management, especially in testing, verification, validation, risks management and changes management exists in the Team. 4. No substitution if any team member cannot continue to contribute to the project. Applying the project again from the beginning could take development team more time. 5. Development time is limited in 2 months only. Therefore, the pressure is really high. 6. Development team cannot deliver the components when reviewed. Development team could deliver components of unacceptably low quality, and time must be added to improve quality. 7. Developing extra functionalities that are not required will extends the schedule. 8. Low motivation and moral reduce productivity. 9. Team member needs extra time to learn unfamiliar tools or techniques. 10. Conflicts among team members’ ideas results in poor performances, more meeting, and extra rework. 11. People’s assignments do not match their strengths. 12. Components developed separately cannot be integrated easily, requiring redesign and rework. 13. Detail reporting could take more development time. 35

Business Plan & SRS Document 6.5 Known future enhancements 1. Pay tuition fee (billing system): The Student can access to a billing system and perform the transaction online such as transferring money to the Bank account of the University, receiving the discount money from the University policies. This function would be involved with the other banking system, authentication and security issue which are out of the scope of the this development 2. Access the system as lecturer: Initially, the users who can access to the system are Students, Academic Affair Staffs, and Financial Officer. The Lecturer plays a role as an observer. However, in the future, the Lecturer can log in to the system to view course, to access to their homepage in order to make the contact with the Students. Grading system is also considered in the future. 6.6 References For further information, the reader should examine the Vision and Scope document, the SRS document. 6.7 Open, unresolved, or TBD issues Schedule and time table construction are not completed at the recent time 36

Business Plan & SRS Document 7. SOFTWARE REQUIREMENT SPECIFICATION 7.1 USE CASE SPECIFICATION 7.1.1 Log in and Log out Name Use Case: Log in and Log out Summary This use case allows user to log in to the system to achieve the access permission to perform other functions which are granted to that specific user. It also lets user log out to end his/her session Rationale The system provides functions such as course registration, financial management just for the specific users (Students, AAO Staff…). Therefore, logging in/out helps to distinguish type of user. Users All users Precondition None. Basic course of This use case begins when a user wants to log in the system to perform event desired tasks. 1. The system requests the user to provide his username and password for the authentication. 2. Right after the user submits his username and password, the system checks username and password. 3. If the username and password matches, the system redirects the user to his specific homepage (student, administrator, financial officer). 4. After logging in, the user can log out to end his/her session Authentication Fail Alternatives paths 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. 37

Business Plan & SRS Document 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 If the logging in is successful, the system will redirect the user to his specific Conditions homepage. 38

Business Plan & SRS Document 7.1.2 Manage Department Information Name Use Case: Manage Department Information Summary This use case allows Academic Affair Staff to manage department and faculty information. This includes adding, updating, and deleting department and faculty from the system. Rationale The Academic Affair Staff needs to manage the department and faculty information online. With the paper – based system, the Staff have to deal with a bunch of paper if he/she wants to add, update or delete one department. Along with this feature, it makes the Staff easier and more convenient to manage the information. Users Academic Affair Staff Precondition User logged in the system as the role of Academic Affair Staff. Basic course of This use case starts when the Academic Affair Staff wishes to add, update, event and/ or delete department information in the system 1. The system requests that the Academic Affair Staff to specify the function he/she would like to perform (add department information, Update department information, or Delete department information). 2. Once the Academic Affair Staff provides the requested information, one of the sub flows is executed. If the Academic Affair Staff selects “Add a Department”, the Add a Department sub flow is executed. If the Academic Affair Staff selects “Update a Department”, the Update a Department sub flow is executed. If the Academic Affair Staff selects “Delete a Department”, the Delete a Department sub flow is executed. Add a Department 1. The system requests that the Academic Affair Staff enter the Department information. This includes: Name - Location - Description - Dean - Faculty - 39

Business Plan & SRS Document 2. Once the Academic Affair Staff provides the requested information and confirms, the department is added to the system. 3. The system provides the Academic Affair Staff with a summary of department information newly added. Update a Department 1. The system requests the Academic Affair Staff to choose a department to modify information. 2. The Academic Affair Staff chooses a department. 3. The system retrieves and displays the department information has been chosen by user. 4. The Academic Affair Staff makes the desired changes to the department information. This includes any of the information specified in the Add a department sub-flow 5. Once the Academic Affair Staff updates the necessary information, the system updates the department record. Delete a Department 1. The system requests the Academic Affair Staff to choose a department to delete. 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. Delete Cancelled Alternatives paths 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 If the use case is successful, the department information is added, updated, Conditions or deleted from the system. Otherwise, the system state is unchanged. 40

Business Plan & SRS Document 7.1.3 Manage Lecturer Information Name Use Case: Manage Lecturer Information Summary This use case allows the Academic Affair Staff to manage lecturer information in the registration system. This includes adding, updating, deleting, and searching lecturers from the system. Rationale With the paper – based system, the Academic Affair Staff have to manage a lot of papers. And it is easy to be lost, damaged and difficult to maintain. With the OURS, AAO Staff can manage the information easily every time and every where Users Academic Affair Staff Precondition User logged in the system as the role of Academic Affair Staff. Basic course of This use case starts when the Academic Affair Staff wishes to add, update, event delete, and/or search lecturer information in the system 1. The system requests the Academic Affair Staff to specify the function he/she would like to perform (either Add a Lecturer, Update a Lecturer, Delete a Lecturer, or Search a Lecturer) 2. Once the Academic Affair Staff provides the requested information, one of the sub-flows is executed If the Academic Affair Staff selected “Add a Lecturer”, the “Add a Lecturer” sub-flow is executed If the Academic Affair Staff selected “Update a Lecturer”, the “Update a Lecturer” sub-flow is executed If the Academic Affair Staff selected “Delete a Lecturer”, the “Delete a Lecturer” sub-flow is executed. Add a Lecturer 1. The system requests that the Academic Affair Staff enter the lecturer information. This includes: Name - Date of birth - Cell-phone - Email - Faculty - 41

Business Plan & SRS Document 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 to confirm the deletion of the lecturer. 8. The system deletes the lecturer from the system Delete Cancelled Alternatives 42

Business Plan & SRS Document 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 If the use case was successful, the lecturer information is added, updated, or Conditions deleted from the system. 43

Business Plan & SRS Document 7.1.4 Manage Student Information Name Use Case: Manage Student Information Summary This use case allows the Academic Affair Staff to manage student information in the registration system. This includes adding, updating, deleting, and searching Students from the system Rationale The information of a student is various and too difficult to handle with the old paper – based system. With OURS manage student information feature, the AAO Staff feels easier and more convenient Users Academic Affair Staff Precondition User logged in the system as the role of Academic Affair Staff. Basic course of This use case starts when the Academic Affair Staff wishes to add, update, event delete, and/or search student information in the system 1. The system requests the Academic Affair Staff to specify the function he/she would like to perform (either Add a Student, Update a Student, or Delete a Student) 2. Once the Academic Affair Staff provides the requested information, one of the sub-flows is executed If the Academic Affair Staff selects “Add a Student”, the “Add a Student” sub-flow is executed If the Academic Affair Staff selects “Update a Student”, the “Update a Student” sub-flow is executed If the Academic Affair Staff selects “Delete a Student”, the “Delete a Student” sub-flow is executed If the Academic Affair Staff selects “Search a Student”, the “Search a Student” sub-flow is executed Add a Student 1. The system requests that the Academic Affair Staff enter the student information. This includes: Student ID - Name - Gender - Date of birth - 44

Business Plan & SRS Document Address - Faculty - Priority(a child of dead or wounded soldiers, belong to highland - area, or other priority) Academic Year - 2. Once the Academic Affair Staff provides the requested information and confirmations, the student is added to the system. 3. The system provides the Academic Affair Staff with a summary of information of student newly added. Update a Student 1. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty & academic duration, academic year & semester & course). 2. The Academic Affair Staff chooses a filter group, then inputs necessary information for the filters, and confirms to search. 3. The system returns a list of student whose information matches the filter’s inputs 4. The Academic Affair Staff chooses the student that he/she wan ts to update. 5. The system displays the student information 6. The Academic Affair Staff makes the desired changes to the student information. This includes any of the information specified in the Add a Student sub-flow 7. The system prompts message MS007 to the Academic Affair Staff to confirm the updating of the student. 8. The system updates the student information Delete Student(s) 1. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty & academic duration, academic year & semester & course). 2. The Academic Affair Staff chooses a filter group, then inputs necessary information for the filters, and confirms to search. 3. The system returns a list of student(s) whose information matches the filter’s inputs 4. The Academic Affair Staff chooses the student(s) that he/she wants to 45

Business Plan & SRS Document 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 necessary information for the filters, and confirms to search. 3. The system returns a list of student(s) whose information matches the filter’s inputs. Student Not Found Alternatives paths In Search a Student sub-flows, if there’s no student whose information matches the filter’s inputs, the system displays the error message MS009. The Academic Affair Staff can then enter different values of the filters or cancel the operation, at which point the use case ends. Delete Cancelled If, in the Delete a Student sub-flow, the Academic Affair Staff decides not to delete the student, the delete operation is cancelled, and the Basic Flow is re-started. Update Cancelled If, in the Update a Student sub-flow, the Academic Affair Staff decides not to update the student, the update operation is cancelled, and the Basic Flow is re-started. Post If the use case is successful, the student information is added, updated, or Conditions deleted from the system. 46

Business Plan & SRS Document 7.1.5 Manage Course Offering Name Use Case: Manage Course Offering Summary This use case allows Academic Affairs to monitor course offerings in one semester of specific year. Rationale Each student receives a list course to register at the beginning of each semester. Using the feature “Manage Course Offering”, an AAO Staff can easy to create, update or delete the course list and sooner distribute to the Students within the short time Users Academic Affair Staff Precondition User logged in the system as the role of Academic Affair Staff. Basic course of Use Case is triggered when Academic Affair Staff chooses “Manage offering event course” task. The system requires Academic Affair Staff to choose a faculty. 1. Academic Affair Staff chooses a faculty. 2. The system displays current list of course offerings of chosen faculty, each course offering has these information: Name of course - Credits - Lecturer - Faculties - 3. System requests Academic Affair Staff to specify the function he/she would like to perform : - Create List of course offerings - Update List of course offerings 4. Once Academic affair staff chooses a function, one of the following sub-flows is executed - If Academic Affair Staff selects “Create list of course offerings”, “Create List of course offerings” sub-flow is executed - If Academic Affair Staff selects “Update list of course offerings”, “Update List of course offerings” sub-flow is executed Create list of course offerings 1. The system displays curriculum of the selected faculty. 47

Business Plan & SRS Document 2. Repeat sub flow “Add an offering course” until Academic Affair Staff completes the list for this faculty 3. Academic Affair Staff confirms his/her selections 4. The system creates and stores the offering courses list of the selected faculty. Update list of course offerings 1. The system displays curriculum and offering courses list currently existing of selected faculty 2. Academic Affair Staff updates a course in this list If Academic Affair Staff wants to add one or more course, sub flow “Add a course offering” is executed. If Academic Affair Staff wants to add one or more course, sub flow “Delete a course offering” is executed. If Academic Affair Staff wants to change lecturer of a specific course, sub flow “Change lecturer” is executed. 3. Academic Affair Staff confirms his/her modification 4. The system updates all changes. Add a course offering 1. Academic Affair Staff chooses a subject from the curriculum. 2. The system holds the selected subject 3. The system displays list of available lecturers in the department to which the subject belongs. 4. Academic choose a lecturer for selected subject 5. The system adds the selected subject with specific lecturer attached to it into the offering courses list. Delete a course offering 1. Academic Affair Staff chooses a course offering from the list of course offerings to delete. 2. The system asks user for confirmation. 3. User confirms to delete. 4. The system removes the selected course offering. Change Lecturer 1. Academic Affair Staff chooses a course offering from the list of course 48

Business Plan & SRS Document 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. No list of course offering Alternatives paths In the step 3 of main flow, if this faculty does not have a list of course offering yet, system displays message MS010 and function “Update list of course offering” is not available. Update canceled If, in the Update list of course offerings sub-flow, the Academic Affair Staff decides not to update anything, the update is cancelled, and the Basic Flow is re-started at the beginning Post If the use case is successful, the offering courses list of a specific faculty will Conditions be created or updated. 49

Business Plan & SRS Document 7.1.6 Manage Financial Activities Name Use Case: Manage Financial Activities Summary This use case allows Financial Office Staff to monitor student’s tuition fee. This includes viewing and updating the tuition fee status of students. Rationale Dealing with number is the task of the Finance Office Staff. The Staffs also have to distribute the financial report to the Students and manage the financial status of each Student. The OURS makes everything easier and more convenient. Users Financial Office Staff Precondition User logged in the system as the role of Financial Office Staff. Basic course of This use case starts when the Financial Office Staff wishes to view and/or event update students’ tuition fee status of one specific student or list of students. 1. The system requests the Financial Office Staff to specify the function he/she would like to perform (either View tuition fee or updating tuition fee status) 2. Once the Financial Office Staff provides the requested information, one of the sub-flows is executed If the Financial Office Staff selects “View tuition fee”, the “View tuition fee” sub-flow is executed If the Financial Office Staff selects “Update tuition fee status”, the “Update tuition fee status” sub-flow is executed View tuition fee 1. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty & academic duration, academic year & semester & course). 2. The Academic Affair Staff chooses a filter group, then inputs necessary information for the filters, and confirms to search. 3. The system returns a list of student(s) whose information matches the filter’s inputs with tuition fee and tuition fee status. Update tuition fee status 50

Business Plan & SRS Document 1. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty & academic duration, academic year & semester & course). 2. The Academic Affair Staff chooses a filter group, then inputs necessary information for the filters, and confirms to search. 3. The system returns a list of student whose information matches the filter’s inputs 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. Student Not Found: Alternatives paths In Search a Student sub-flows, if there’s no student whose information matches the filter’s inputs, the system displays the error message MS012. The Academic Affair Staff can then enter different values of the filters or cancel the operation, at which point the use case ends. Update Cancelled: If, in the Update a Student sub-flow, the Academic Affair Staff decides not to update the student, the update operation is cancelled, and the Basic Flow is re-started. Post If the use case was successful, the student tuition fee is display or student Conditions tuition fee status is updated. 51

Business Plan & SRS Document 7.1.7 View Academic History Name Use Case: View Academic History Summary This use case allows a Student to view his studying progress. The Student can see the courses he has taken as well as the scores and status (passed or failed). Rationale Every Student wants to view and review his/her grades, GPA and list of course. With the paper - based system, he/she has to request the AAO to deliver the transcript contains all above information. In contrast, the Student can easily access to his account and view his/her Academic history online whenever he/she wants. Users Students Precondition Users logged in the system as the role of a student. Basic course of This use case starts when a student wishes to view his/her academic event 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 None. paths Post Conditions None. 52

Business Plan & SRS Document 7.1.8 Register Course Name Use Case: Register Course Summary This use case allows a Student to register course offerings in the current semester. Rationale With old system, the Students have to fill in the Registration forms and hand them to the AAO and wait for approvals. The process takes a long long time. Therefore, it is significant to reduce the time and make the process shorter. The Students can find it happily with the feature “Register Course” which performs everything online. Users Students Precondition Users logged in the system as the role of a student. Basic course of This use case starts when a student wishes to register for course offerings or event to update his/her existing course schedule. 1. The system retrieves and displays the Student’s current schedule (e.g.; the schedule for the current semester). The schedule may be empty. 2. The student choose “change schedule” in order to begin add/drop course. 3. The system retrieves a list of available course offerings from the Course Catalog System, filters courses that the student does not meet the prerequisite and displays the list to the Student. 4. The Student may update the course selections on the current selection by dropping and adding course offerings. The Student selects the course offerings to add from the list of available course offerings. The Student also deselects any course offerings to drop from the existing schedule. The Student can only select a total of minimum 15 credits and maximum 30 credits. 5. After the Student adds or drop a course, the system recalculate and update total credits, fee and discount. 6. Once the Student indicates that he/her has finished making his/her selections, the system prompt message MS016 to the Student to confirm the submission of the schedule. 7. The Student confirms to continue submitting or cancel to continue add/drop courses. 8. After submitted, the schedule is saved in the system. 53

Business Plan & SRS Document Course Registration Closed Alternatives paths If, when the use case starts, it is determined that registration for the current semester has been closed, message MS013 is displayed to the Student, and the use case terminates. Students cannot register for course offerings after registration for the current semester has been closed. Reset changes to a schedule If, while choosing to add/ drop courses, the Student decides to undo all the changes he/her made, the Student then indicates the system that he/her wants to reset changes to the schedule. The system then prompts message MS017 for the student confirmation, the student can agree and either the Basic Flow is re-started at the beginning or cancels reset. Register more than 30 credits The student has to select less than a total of 30 credits per. If the Student add a course that increase the total credits more than 30, the system will prompt the message MS013 and do not allow the student to add the course to his/her schedule. Register less than 15 credits The student has to select more than a total of 30 credits per. If the Student drop a course that decrease the total credits to less than 30, the system will prompt the message MS014 and do not allow the student to add the course to his/her schedule. Post If the use case was successful, the student schedule is updated. Otherwise, Conditions the system state is unchanged. 54

Business Plan & SRS Document Appendix Message ID Type Context Error Messages Actions Authentication Wrong password or username MS001 Info OK Failed cannot be found. Account locked. Please wait for 30 MS002 Info Account locked minutes or contact the OK administrator. This account is being used by MS003 Info Account being used OK another user. Are you sure you want to delete MS004 Question Delete a department OK – Cancel the selected department? Are you sure you want to update MS005 Question Update a lecturer OK – Cancel the current displayed lecturer? Are you sure you want to delete MS006 Question Delete a lecturer OK – Cancel the selected lecturer? Are you sure you want to update MS007 Question Update a student OK – Cancel the modified student? Are you sure you want to delete MS008 Question Delete a student OK – Cancel the selected student? The selected student does not MS009 Info Student not found OK exist No list of course This faculty has no list of course MS010 Info Ok offering offering yet Update tuition fee Are you sure you want to update MS011 Question OK – Cancel status tuition fee status of current 55

Business Plan & SRS Document student? MS012 Info Student not found Cannot find the result. OK Course Registration The course registration has been MS013 Info OK Closed closed Register more than You cannot register more than 30 MS014 Info OK 30 credits credits Register less than 30 You cannot register less than 30 MS015 Info OK credits credits Are you sure you want to submit MS016 Question Submit a schedule OK – Cancel this schedule? Reset changes to a Are you sure you undo all the MS017 Question OK – Cancel schedule changes you have made? 56

Business Plan & SRS Document 7.2 FUNCTIONAL REQUIREMENT Name FR-1: Department & Faculty relationship Summary There exists department that no student studies in it. Rationale The concepts of department and faculty are not the same. Please check the glossary part for those concepts. Requirement A department has at most one faculty. When a department is being added, if it does not have a faculty, it means it has no student, then the value of Faculty is default value “None”. Mathematics Department is an example for department which does not has faculty (all students study mathematics courses but no one study in Mathematics department) Reference Use-case: Manage Department Information Name FR-2: Lecturer and department relationship Summary Lecturers are belonged and managed by department, not faculty Rationale As mentioned in the glossary part that when we talk about lecturers, we mention to department scope. And when we talk about students, we mention to faculty scope. Requirement A lecturer must belong to one specific department. If a lecturer does not belong to any department of the university, his department is denoted “General”. Departments do not have faculty: Mathematics , English Reference Use-case: Manage lecturer 57

Business Plan & SRS Document Name FR-3: Student and faculty relationship Summary Students are belonged to faculties. It means that students are directly managed by faculties Rationale As mentioned in the glossary part that when we talk about students, we mention to faculty scope. Requirement A student must belong to one specific faculty Students can not belong to department because there are departments that have no student such as Mathematics Department, English Department… Reference Use-Case: Manage Student Name FR-4: course offering management Summary Manage offering course including “general” course (belongs to general departments that have no students) and specific course (belongs to departments that have student) Rationale There are courses that are common courses to many faculties of different departments Requirement In each semester, university has maximum of opening course is 50 courses. Each course offering can only be taught by one lecturer and belong to one department. A course could be opened for many faculties with the same lecturer such as Courses belonging to “General” departments. For example, Marxist-related courses, Physical training, English… Reference Use-case: Manage course offering 58

Business Plan & SRS Document Name FR-5: Registration constraints Summary Student can only register for courses that he can satisfy the requirement of that course Rationale There are constraints on maximum and minimum number of credits and the prerequisites. Requirement A student just register any course opened by his/her faculty. In addition, this course has all prerequisites are studied in this student's academic history. Each subject may require the student to finish one or more subjects Student can register maximum 30 credits and minimum 15 credits Reference Use-case: Register Course Name FR-6: Discount rate management Summary Students are in priority will have their tuition fees be reduced with specific rate. Rationale There are some students are in priority. Therefore their tuition fees are reduced. Requirement Discount rates are not cumulative. Only the highest discount rate is applied. _ Highland area and Child of Wounded Soldier(3/4 or 4/4): 25% _ Child of Wounded Solider (1/4 or 2/4) or Child of Revolutionary Martyr: 50% Reference Use-case: Manage financial activities Name FR-7: Type of credits management Summary Each kind of credits will have a specific fee Rationale Not all kind of credits have the same fee. For example English credits and Software Engineering credits have different fees. Requirement Type A – 42 USD per credit: Academic subjects. Type B – 4.5 USD per credit: Physical education, Marxist-related subjects. Type C – 16 USD per credit: English. Reference Use-case: Manage financial activities 59

Business Plan & SRS Document Name FR-8: Grade management policy Summary The system stores the final grade and status of that subject of student only. Rationale This is not a grading system. Therefore, we do not care all kind of grades such as midterm, homework grades. Requirement The system only stores the final grade of each course for students. Maximum grade is 100. Grade over 50: passed Grade under 50: failed Reference Use-Case: View Academic History Name FR-9: Password constraints Summary For security, password should have constraints Rationale For easy to recovery password and secure the user account Requirement The minimum length is 8 The default password is Abcd1234 Reference Use-Case: Login & Logout 60

Business Plan & SRS Document 7.3 NON-FUNCTIONAL REQUIREMENT Introduction: The Non-functional Requirements are requirements that are not readily captured in the use case model. These requirements will apply on OURS and cover all following aspects: 7.3.1 Performance: Support 100 simultaneously users 1. 90% request has response within 10 seconds. 2. 7.3.2 Reliability: For time-consuming task such as Create Schedule, Register and any other task has response time is greater than 5 seconds, the system should be provide indicated symbol to let user knows that process is going on. 7.3.3 Availability: System should be supported 24/7 for on line application. 7.3.4 Efficiency: 1. System should be provided at least 1 Mbps bandwidth connection. 2. Database is able to retain volume of data desired by University, not less than 20.000 students in 10 years; with maximum of course list is 500 courses. 7.3.5 Supportability: Localization: i. Support for the following language must be provided: a. English b. Vietnamese ii. Language could be selectable. 7.3.6 Integrity: User could enter password to login only 3 times, if they fails, this user account will be 1. locked in 30ph: user could not log in the system in a account when this account is locked. At any moment, an account is used only by 1 user. 2. 7.3.7 Portability: 1. System is web application which runs in Internet Explorer 6.0, Firefox 2.0 or above with JavaScript is enabled. System is not guaranteed to operate on any lower vers.ion or other browser. 2. OURS intended to work with a number of customer MySQL 5.0 databases and J2EE servers (Glassfish). 61

Business Plan & SRS Document 7.3.8 Flexibility: After system is deployed, system could be developed these other functions: 1. Lecturer chooses course to teach 2. Academic affair creates schedule for class 3. Financial staff get document from system for billing 62

Business Plan & SRS Document 8. INSPECTION REPORT # of issue 11 Review date 11/05/2007 Attendees Read document Time spent preparing Nguyen Duc Quan Y 3hours Tran Minh Phung Y 2 hours Le Vu Hoang Y 1.5 hours Phan Duy Tan Y 2 hours Huynh Da Thuc Y 2 hours No Section/ page Identified by Issue Manage Course Tan Department used to manage lecturer, Faculty used to 1 Offering manage student Manage Course Phung University has a catalog of all the courses in this 2 Offering university Manage Course Quan Write detail steps of change lecturer, remove course 3 Offering Register Course Tan Our system just considers about course offering, not 4 physical class Register Course Quan Building schedule is too difficult so we don't try to 5 create schedule Manage Hoang To make SRS simply, we merge use case manage 6 Department department and manage faculty 7 Login & Logout Thuc Default password is “Abcd1234” Manage Hoang To help people find student effectively, we support 8 Student filters to users Manage Phung Student has attribute Academic duration to manage 9 Student Manage Thuc Number of lecturers is small so we do not need support 10 Lecturer search function Manage Thuc Number of department is small so we do not need 11 Department support search function 9. GLOSSARY 9.1 Introduction This document is used to define terminology specific to the domain problem, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so 63

Business Plan & SRS Document that use-case descriptions and other project documents can focus on what the system must do with the information. 9.2 Definitions The glossary contains the working definitions for the key concepts in the Course Registration System. 9.2.1 OURS Online University Registration System 9.2.2 Academic staff A person working in academic affair and managing academic information (student, lecturer, course offering, department and faculty) 9.2.3 Finance staff A person working in finance office and managing finance activities (tuition fee, etc) 9.2.4 Department All professors belong to a department which plays the same role as the faculty in the aspect of lecturer. A department has at most 1 faculty. 9.2.5 Faculty All students belong to a faculty which is responsible for the academic affair of a field of study in the University 9.2.6 Curriculum All the courses in a faculty a student studies in university. 9.2.7 Subject Name of a course opened by university 9.2.8 Course Offering A specific course with a lecturer opened in a specific semester offered by Academic affair staff for some faculties 9.2.9 Prerequisite A prerequisite of a course is courses a student must finish in order to take this course 64

Business Plan & SRS Document 9.2.10 Course Catalog The catalog of all courses offered by the university 9.2.11 Lecturer A person teaching courses at the university 9.2.12 Student A person enrolled in courses at the university. A student belongs to one faculty. 9.2.13 Student priority The background of the student to get discount in tuition fee 9.2.14 Discount rate The percentage of reduction of tuition fee a student can get for his priority 9.2.15 Grade The academic result of a particular student for a particular course offering 9.2.16 Schedule The list of course offering a student has selected to study the current semester. 9.2.17 Tuition fee A fee student needs to pay for university in a semester. 9.2.18 Credit A unit to represent the weight of a subject 9.2.19 Academic duration Planned time for student for study in university 9.2.20 Academic year Each academic year in the university consists two semesters, starts from September and ends in May the following year (Ex: 2007-2008) 65

Project Plan And Srs Final

1 comments

Notes on slide 1

1 Favorite