Your SlideShare is downloading. ×
All Documents
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

All Documents

2,066
views

Published on

Published in: Business, Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,066
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
88
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Vision and Scope Document 10/12/2007 Ho Chi Minh National University – International University Instructor: Phan Viet Hoang October 10th , 2007 Date Version 1.0 Status Baseline Author Team TiHonMumMim(Group 6) Reviewer Team TiHonMumMim(Group 6) Documenter Nguyen Duc Quan Team member Signature Nguyen Duc Quan Le Vu Hoang Tran Minh Phung Phan Duy Tan Huynh Da Thuc
  • 2. Final Document Table of Contents Introduction ..................................................................................................................................................... 13 Development team & OURS project ................................................................................................................ 13 Problem Statement .......................................................................................................................................... 15 Project background ...................................................................................................................................... 15 Key users ...................................................................................................................................................... 15 Stakeholders ................................................................................................................................................ 16 Assumptions & Constraints of Online University Registration System ......................................................... 17 Vision of Solution ............................................................................................................................................. 17 Vision statement .......................................................................................................................................... 17 Scope ........................................................................................................................................................... 18 List of features ............................................................................................................................................. 18 List of features will not be developed .......................................................................................................... 18 Business Plan & SRS Document ....................................................................................................................... 20 STATEMENT OF WORK ..................................................................................................................................... 21 RESOURCE LIST ................................................................................................................................................ 24 Human ......................................................................................................................................................... 24 Software ...................................................................................................................................................... 24 Hardware ..................................................................................................................................................... 24 ESTIMATION .................................................................................................................................................... 25 Huynh Da Thuc estimation ........................................................................................................................... 25 Phan Duy Tan estimation ............................................................................................................................. 28 Tran Minh Phung estimation ....................................................................................................................... 31 Nguyen Duc Quan estimation ...................................................................................................................... 34 Le Vu Hoang estimation ............................................................................................................................... 37 Estimation Summary .................................................................................................................................... 39 SCHEDULE ........................................................................................................................................................ 43 Task list ........................................................................................................................................................ 43 2
  • 3. Final Document Gantt chart (reference) ................................................................................................................................ 45 RISK PLAN ........................................................................................................................................................ 46 DISCUSSION SUMMARY ................................................................................................................................... 48 Project background ...................................................................................................................................... 48 Purpose of project ................................................................................................................................... 48 Scope of project ....................................................................................................................................... 49 Perspectives ................................................................................................................................................. 51 Who will use the system? ........................................................................................................................ 51 Who can provide needs about the system? ............................................................................................. 51 Project objectives ........................................................................................................................................ 52 Know business rules ................................................................................................................................. 52 System information and/or diagrams ...................................................................................................... 52 Assumptions and dependencies .............................................................................................................. 54 Design and implementation constraint .................................................................................................... 54 Risks ............................................................................................................................................................. 54 Known future enhancements ...................................................................................................................... 55 References ................................................................................................................................................... 55 Open, unresolved issues ............................................................................................................................. 55 SOFTWARE REQUIREMENT SPECIFICATION ..................................................................................................... 56 USE CASE SPECIFICATION ............................................................................................................................. 56 Log in and Log out .................................................................................................................................... 56 Manage Department Information ............................................................................................................ 58 Manage Lecturer Information .................................................................................................................. 60 Manage Student Information................................................................................................................... 63 Manage Course Offering .......................................................................................................................... 66 Manage Financial Activities ...................................................................................................................... 69 View Academic History ............................................................................................................................ 71 Register Course ........................................................................................................................................ 72 Manage Course Catalogue ....................................................................................................................... 74 Manage User Account .............................................................................................................................. 77 3
  • 4. Final Document Appendix .................................................................................................................................................. 80 FUNCTIONAL REQUIREMENT ....................................................................................................................... 82 NON-FUNCTIONAL REQUIREMENT .............................................................................................................. 86 Performance: ........................................................................................................................................... 86 Reliability: ................................................................................................................................................ 86 Availability: .............................................................................................................................................. 86 Efficiency:................................................................................................................................................. 86 Supportability: ......................................................................................................................................... 86 Integrity: .................................................................................................................................................. 86 Portability: ............................................................................................................................................... 86 Flexibility: ................................................................................................................................................. 87 INSPECTION REPORT ........................................................................................................................................ 88 GLOSSARY ........................................................................................................................................................ 89 Introduction ................................................................................................................................................. 89 Definitions.................................................................................................................................................... 89 OURS ........................................................................................................................................................ 89 Academic staff ......................................................................................................................................... 89 Finance staff ............................................................................................................................................. 89 Department ............................................................................................................................................. 89 Faculty...................................................................................................................................................... 89 Curriculum ............................................................................................................................................... 89 Subject ..................................................................................................................................................... 89 Course Offering ........................................................................................................................................ 90 Prerequisite.............................................................................................................................................. 90 Course Catalog ......................................................................................................................................... 90 Lecturer .................................................................................................................................................... 90 Student .................................................................................................................................................... 90 Student priority ........................................................................................................................................ 90 Discount rate............................................................................................................................................ 90 Grade ....................................................................................................................................................... 90 4
  • 5. Final Document Schedule .................................................................................................................................................. 90 Tuition fee ................................................................................................................................................ 90 Credit ....................................................................................................................................................... 90 Academic duration ................................................................................................................................... 90 Academic year.......................................................................................................................................... 91 Testing Plan & Test case Document ................................................................................................................. 93 A- Test Plan .................................................................................................................................................. 94 Introduction ..................................................................................................................................................... 94 Purpose ........................................................................................................................................................ 94 Scope ........................................................................................................................................................... 94 References ................................................................................................................................................... 94 Review requirement and Design ...................................................................................................................... 94 Review system architecture ......................................................................................................................... 95 Features to be tested ....................................................................................................................................... 97 Features not to be tested ................................................................................................................................ 98 Approach ......................................................................................................................................................... 99 Kind of test ................................................................................................................................................... 99 Data and Database Integrity Testing ........................................................................................................ 99 System testing.......................................................................................................................................... 99 Performance Testing .............................................................................................................................. 100 Load Testing ........................................................................................................................................... 100 Stress Testing ......................................................................................................................................... 100 Volume Testing ...................................................................................................................................... 100 Test Strategy .............................................................................................................................................. 100 Checklist of unit test .............................................................................................................................. 100 Unit testing ............................................................................................................................................ 101 Smoke test ............................................................................................................................................. 101 Test Automation .................................................................................................................................... 101 Data and Database Integrity Testing ...................................................................................................... 102 System Testing ....................................................................................................................................... 102 5
  • 6. Final Document Performance Testing .............................................................................................................................. 103 Load Testing ........................................................................................................................................... 104 Stress Testing ......................................................................................................................................... 105 Volume Testing ...................................................................................................................................... 106 Suspension criteria and resumption requirements ........................................................................................ 107 Suspension criteria..................................................................................................................................... 107 Resumption requirements ......................................................................................................................... 107 Environmental Needs .................................................................................................................................... 108 Tools .......................................................................................................................................................... 108 Software .................................................................................................................................................... 108 Hardware ................................................................................................................................................... 109 Schedule ........................................................................................................................................................ 109 Acceptance criteria ........................................................................................................................................ 110 Resources ...................................................................................................................................................... 110 B- Test Case ................................................................................................................................................ 113 Unit testing .................................................................................................................................................... 113 Test Cases of Log in and Log out Use Case ..................................................................................................... 115 User logs in successfully with valid username and password .................................................................... 115 Fail to login the system when providing invalid username ........................................................................ 115 Fail to login the system when providing username or password containing special character(s).............. 115 Fail to login the system when providing valid username and invalid password ......................................... 116 Fail to login the system when providing empty username ........................................................................ 116 Fail to login the system when providing valid username and empty password ......................................... 117 User account is locked after failing to log in 3 times .................................................................................. 117 User logs in the system using an account is being used by another user................................................... 118 User logs in the system using an account is being locked .......................................................................... 118 Change password successfully ................................................................................................................... 118 Fail to change password when old or new or confirmed password is empty ............................................ 119 Fail to change password when old password is incorrect .......................................................................... 119 Recover the password successfully ............................................................................................................ 120 6
  • 7. Final Document Fail to reset password when inputting wrong answer for the security question ....................................... 120 Fail to reset password when inputting answer containing special character(s) for the security question . 121 Fail to reset password when inputting empty answer for the security question ....................................... 122 Test Cases of Manage Department Information Use case ............................................................................. 122 Add a department with valid information successfully .............................................................................. 122 Fail to add a department with name that already exists in the system ..................................................... 123 Fail to add a department when one or some or all fields are empty ......................................................... 123 Fail to add a department when inputting special character(s) to one or some or all fields ....................... 124 Update a department with valid information successfully ........................................................................ 125 Fail to update a department with name that already exists in the system ................................................ 125 Fail to update a department when one or some or all fields are empty .................................................... 126 Fail to update a department when inputting special character(s) to one or some or all fields .................. 127 Update cancel ............................................................................................................................................ 127 Delete a department .................................................................................................................................. 128 Delete cancel ............................................................................................................................................. 128 Test Cases of Manage Lecturer Information use case.................................................................................... 129 Add a lecturer with valid information successfully .................................................................................... 129 Fail to add a department when one or some or all fields are empty ......................................................... 129 Fail to add a lecturer when inputting special character(s) to one or some or all fields.............................. 130 Look for a lecturer...................................................................................................................................... 131 Update a lecturer with valid information successfully ............................................................................... 131 Fail to update a lecturer when one or some or all fields are empty .......................................................... 133 Fail to update a lecturer information when inputting special character(s) to one or some or all fields .... 133 Update cancel ............................................................................................................................................ 134 Delete a lecturer ........................................................................................................................................ 135 Delete cancel ............................................................................................................................................. 135 Test Cases of Manage Student Information Use Case ................................................................................... 136 Add a student with valid information successfully..................................................................................... 136 Fail to add a student when one or some or all fields are empty ................................................................ 136 Fail to add a student when inputting special character(s) to one or some or all fields .............................. 137 7
  • 8. Final Document Search student by student ID or/and by student name ............................................................................. 138 Fail to search student by student ID or/and by student name when providing invalid student ID or/and student name ............................................................................................................................................. 138 Fail to search student by student ID or/and by student name when providing empty student ID or/and student name ............................................................................................................................................. 139 Search student by faculty and academic duration ..................................................................................... 139 Search student by academic year, semester, and course .......................................................................... 141 Update a student with valid information successfully ............................................................................... 141 Fail to update a student when one or some or all fields are empty ........................................................... 142 Fail to update a student when inputting special character(s) to one or some or all fields ........................ 142 Update is canceled ..................................................................................................................................... 143 Delete a student ........................................................................................................................................ 144 Delete is canceled ...................................................................................................................................... 144 Test Cases of Manage Course Offering Use Case ........................................................................................... 145 Create list of courses offering successfully ................................................................................................ 145 Update the list of course offering .............................................................................................................. 145 Cancel during the Create list of course offering operation ........................................................................ 146 Cancel during the Update list of course offering operation ....................................................................... 147 Fail to create an empty list of course offering ........................................................................................... 147 Update list of course offering while there’s no list of course offering for specific faculty ......................... 148 Test Cases of Manage Financial Activities Use Case ...................................................................................... 150 View tuition fee by student ID or/and by student name............................................................................ 150 Fail to view tuition fee by student ID or/and by student name when providing invalid student ID or/and student name ............................................................................................................................................. 150 Fail to view tuition fee by student ID or/and by student name when providing empty student ID or/and student name ............................................................................................................................................. 151 View tuition fee by faculty or/and by academic duration .......................................................................... 151 View tuition fee by academic year, semester, and course ......................................................................... 152 Update tuition fee status of a student ....................................................................................................... 152 Test Cases of View Academic History Use Case ............................................................................................. 153 View academic history successfully ........................................................................................................... 153 8
  • 9. Final Document View all course have taken history............................................................................................................. 153 View by specific year and semester. .......................................................................................................... 154 View by passed and failed status. .............................................................................................................. 154 Test Cases of Register Course Use Case ......................................................................................................... 155 Fail to register more than 30 credits .......................................................................................................... 155 Fail to register less than 15 credits ............................................................................................................ 155 Register for courses successfully................................................................................................................ 156 Update the existing schedule successfully ................................................................................................. 157 Test Cases of Manage Course Catalogue Use Case ........................................................................................ 157 Add new course to course catalogue successfully ..................................................................................... 157 Fail to add a course when one or some or all fields are empty .................................................................. 158 Fail to add a course when inputting special character(s) ........................................................................... 159 Search for course by ID or Name ............................................................................................................... 159 Fail to search for course by ID or Name when inputting invalid ID and/or Name ...................................... 160 Fail to search for course by ID or Name when inputting empty ID and/or empty Name ........................... 160 Update course with valid information successfully.................................................................................... 161 Fail to update a course when one or some or all fields are empty ............................................................ 161 Fail to update a course when inputting special character(s) ...................................................................... 162 Update operation is canceled .................................................................................................................... 163 Delete a course .......................................................................................................................................... 163 Delete operation is canceled ..................................................................................................................... 163 Test Cases of Manage User Account Use Case ............................................................................................... 164 Create a new user account successfully ..................................................................................................... 164 Fail to create a new user account when the username that user has provided existing in the system already ....................................................................................................................................................... 164 Fail to create a new user account when inputting empty username ......................................................... 165 Fail to create a new user account when the inputs containing special character(s) .................................. 166 Search for account by username ............................................................................................................... 166 Fail to search for account by empty username .......................................................................................... 167 Fail to search for account by username that does not exist in the system ................................................ 167 9
  • 10. Final Document Fail to search for account by username containing special characters(s) .................................................. 167 Update an account ..................................................................................................................................... 168 Update operation is canceled .................................................................................................................... 168 Delete an account ...................................................................................................................................... 169 Delete operation is canceled ..................................................................................................................... 169 Test Cases of Non-functional requirement testing ........................................................................................ 170 Switch from Vietnamese to English ........................................................................................................... 170 Switch from English to Vietnamese ........................................................................................................... 170 Load testing with 15 requests at the same time ........................................................................................ 170 Load testing with 25 requests at the same time ........................................................................................ 171 C- Appendix ................................................................................................................................................ 171 D- Inspection Checklist ............................................................................................................................... 173 The following checklist items apply to the test plan. ..................................................................................... 173 The following checklist items apply to the test cases: ................................................................................... 173 Testing demo ................................................................................................................................................. 176 Unit testing .................................................................................................................................................... 177 Functional requirement testing ..................................................................................................................... 177 Test Cases of Log in and Log out Use Case ..................................................................................................... 177 User logs in successfully with valid username and password .................................................................... 177 Fail to login the system when providing invalid username ........................................................................ 178 Fail to login the system when providing username or password containing special character(s).............. 178 Fail to login the system when providing valid username and invalid password ......................................... 179 Fail to login the system when providing empty username ........................................................................ 179 Fail to login the system when providing valid username and empty password ......................................... 179 User account is locked after failing to log in 3 times .................................................................................. 180 User logs in the system using an account is being used by another user................................................... 180 User logs in the system using an account is being locked .......................................................................... 181 Change password successfully ................................................................................................................... 181 Fail to change password when old or new or confirmed password is empty ............................................ 182 Fail to change password when old password is incorrect .......................................................................... 182 10
  • 11. Final Document Recover the password successfully ............................................................................................................ 183 Fail to reset password when inputting wrong answer for the security question ....................................... 183 Fail to reset password when inputting answer containing special character(s) for security question ....... 184 Fail to reset password when inputting empty answer for the security question ....................................... 184 Test Cases of Manage Course Offering Use Case ........................................................................................... 185 Create list of courses offering successfully ................................................................................................ 185 Update the list of course offering .............................................................................................................. 186 Cancel during the Create list of course offering operation ........................................................................ 186 Cancel during the Update list of course offering operation ....................................................................... 187 Fail to create an empty list of course offering ........................................................................................... 188 Update list of course offering while there’s no list of course offering for specific faculty ......................... 188 Test Cases of Manage Department Information Use case ............................................................................. 189 Add a department with valid information successfully .............................................................................. 189 Fail to add a department with name that already exists in the system ..................................................... 189 Fail to add a department when one or some or all fields are empty ......................................................... 190 Fail to add a department when inputting special character(s) to one or some or all fields ....................... 191 Update a department with valid information successfully ........................................................................ 191 Fail to update a department with name that already exists in the system ................................................ 192 Fail to update a department when one or some or all fields are empty .................................................... 193 Fail to update a department when inputting special character(s) to one or some or all fields .................. 193 Update cancel ............................................................................................................................................ 194 Delete a department .................................................................................................................................. 194 Delete cancel ............................................................................................................................................. 195 Test Cases of Register Course Use Case ......................................................................................................... 195 Fail to register more than 30 credits .......................................................................................................... 195 Fail to register less than 15 credits ............................................................................................................ 196 Register for courses successfully................................................................................................................ 196 Update the existing schedule successfully ................................................................................................. 198 Non-functional requirement testing .............................................................................................................. 198 Test Cases of Non-functional requirement testing ........................................................................................ 198 11
  • 12. Final Document Switch from Vietnamese to English ........................................................................................................... 198 Switch from English to Vietnamese ........................................................................................................... 199 Load testing with 15 requests at the same time ........................................................................................ 199 Load testing with 25 requests at the same time ........................................................................................ 199 System architecture introduction .................................................................................................................. 200 How to download & install tools .................................................................................................................... 201 How to install OURS ....................................................................................................................................... 205 How to run OURS ........................................................................................................................................... 207 How to setup and run tests of OURS ............................................................................................................. 208 How to use OURS ........................................................................................................................................... 209 Login and Logout ........................................................................................................................................... 209 Register Course .............................................................................................................................................. 209 View Academic History .................................................................................................................................. 209 Manage Department Information ................................................................................................................. 210 Manage Student Information ........................................................................................................................ 210 Manage Course Offering ................................................................................................................................ 211 Manage Lecturer Information ........................................................................................................................ 212 Manage Financial Activities ........................................................................................................................... 213 Manage Course Catalogue ............................................................................................................................. 214 Manage User Account ................................................................................................................................... 214 12
  • 13. Final Document Introduction This is the Vision and Scope document of OURS project. Like any other Vision and Scope document, this document will cover the problem and vision statement including project background, list of users, stakeholders, candidate risks, assumptions & constraints, and project scope. In addition, the document will also cover the part of development team introduction. Development team & OURS project TiHonMumMim is a small software development team set up in 2007 by 5 students of International University. The structure of the team includes 3 software engineers, 1 system & networking engineer, and 1 team leader. Our business goal is to be a leading company in IT. And our slogan is “Computing, consulting, and programming professionally” (CC&PP). For more information about our team: Email: TiHonMumMim@yahoo.com Blog: http://360.yahoo.com/TiHonMumMim 13
  • 14. Final Document We are assigned to build Online University Registration System (OURS). The internal development team structure and roles on OURS project: OURS project Team leader Coder Integrator Documenter Tester Business System System UI Analyst Analyst Designer Designer TEAM LEADER: Responsible for all project management. DOCUMENTER: Responsible for documentation from other members’ according to the RUP document standard. BUSINESS ANALYST: Capture and analyze user requirements. SYSTEM ANALYST: Analyze system requirements. SYSTEM DESIGNER: Design the internal structure and operations of system. UI DESIGNER: Design user interface for the system. CODER: Responsible for implementing the system. INTEGRATOR: Integrate the system components. TESTER: Responsible for testing activities. Team member ID Email Main roles toyohiko1507@yahoo.com Tran Minh Phung 090401096 Tester, Integrator smallwildcat_86@yahoo.com Le Vu Hoang 090401019 System Designer, Coder runnfire@yahoo.com Huynh Da Thuc 090401121 Tester, UI Designer kingduytan@yahoo.com Phan Duy Tan 090401044 System Analyst, Coder duc.quan@yahoo.com Nguyen Duc Quan 090401038 Team leader, Business Analyst, Documenter 14
  • 15. Final Document Problem Statement Project background There is a widespread agreement that the policy in course registration is very complicated, costly, take-time, and inconvenient to both students and university. This is due the fact that at the beginning of each semester, the university has to pause or delay some activities to spend time for course registration of students. Some staffs have to prepare for offering courses list (including selecting courses and inviting lecturers …), print it out, and deliver the registration form to each student. After around one week, all students’ registration form will be returned. And the staffs have to input students’ registration information to Excel files. They also have to check manually whether the registration form of each student is legal or not basing on some conditions such as prerequisite course, maximum and minimum number of credits allowed to register … If there is anything wrong or students want to add or drop the courses, everything in the above process has to be restarted. And sometimes some papers are lost when documents are moved from one place to another place; both students and university have to spend time for retrieving necessary information and approve it. However, it is impossible to do that in some cases. In addition, calculating tuition fee for students, managing students’ academic history… are also thorny issues. Mistakes can occur anytime when financial office‘s staffs use calculator or Microsoft excel to calculate tuition fee. Students’ transcript management is also another issue. When students want to have transcript to see their academic history, they have to wait at least two weeks to receive it from academic affair. Those are some typical examples for the inconvenience and complication of the current course registration policy. They lead the university to the decision of building Online Course Registration System to improve effectiveness, reduce time and cost in course registration process. Key users STUDENT: use the system to register for course or view academic history. ADMINISTRATOR: Manage the system after it is built and the authentication mechanism of the system. 15
  • 16. Final Document ACADEMIC AFFAIR STAFF: use the system to manage department and faculty, lecturer, student, course catalogue, list of course offering information. FINANCIAL OFFICE STAFF: use the system to monitor financial activities related to course registration. Stakeholders STUDENT: use the system to register for course or view academic history. ADMINISTRATOR: Manage the system after it is built. ACADEMIC AFFAIR STAFF: use the system to manage school, lecturer-professor, and ADMINISTRATOR: Manage the system after it is built and the authentication mechanism of the system. LECTURER: They could give ideas or comment on the solution for the system’s development and improvement. FINANCIAL OFFICE MANAGER: They also manage the investment of university for the system development. FINANCIAL OFFICE STAFF: use the system to monitor financial activities related to course registration. DEVELOPMENT TEAM: include all software engineers, business analysts, system analysts, system designers, implementers, testers, QA, and project manager… They are tasked to build the system. List of Risks All team members need preparation time for midterm, final exam, and other subjects. Phung, Thuc, and Hoang take pre-thesis course. Lack of experiences in software project management, especially in testing, verification, validation, risks management and changes management exists in the Team. No substitution if any team member cannot continue to contribute to the project. Applying the project again from the beginning could take development team more time. Development time is limited in 2 months only. Therefore the pressure is really high. 16
  • 17. Final Document Development team cannot deliver the components when reviewed. Development team could deliver components of unacceptably low quality, and time must be added to improve quality. Developing extra functionalities that are not required will extends the schedule. Low motivation and moral reduce productivity. Team member needs extra time to learn unfamiliar tools or techniques. Conflicts among team members’ ideas results in poor performances, more meeting, and extra rework. People’s assignments do not match their strengths. Components developed separately cannot be integrated easily, requiring redesign and rework. Detail reporting could take more development time. Assumptions & Constraints of Online University Registration System The system will be applied for universities using credit system like International University. The registration information of students is processed by academic affair. And only academic affair has right to manage and process the registration information. Development team will use J2EE architecture to develop system. Policy for tuition fee payment is using cash and it is managed by financial office. Development team must have at least one 2-hour meeting per week. Development time 2 months and 10 days (from 01/10/2007 to 20/12/2008) Development team must produce the first build before review 3 (05/12/2007). Each team member must work at least 15 hours per week. Vision of Solution Vision statement As the head of information systems for International University team are tasked with developing a new Online Course Registration System. The new system will allow students to access the system during registration time to register for courses, add or drop the registered courses, check tuition 17
  • 18. Final Document fee, and review their academic history. Academic affair can use the system as a mean to manage information of schools, classes, professors, students and offering courses. Financial office will use the system to monitor financial activities. The system provides a better solution and policy for course registration in International University. It reduces much time, cost, and resources required in processing registration information of students. Scope To be noticed on the scope of the system that this system is an Online University Registration System. It is not a university management system which is much larger than the system we try to build. It is only a part of the university management system. Therefore, we have to pay attention on building applications supporting students to do registration, academic affairs to manage information related to students’ courses registration, and financial office to mange financial activities. List of features User login and log out View Academic History Register for course Manage Department Information Manage Student Information Manage Courses Offering Manage Course Catalogue Manage Lecturer Information Manage Financial Activities Manage User Account List of features will not be developed Pay tuition fee (billing system) Access the system as professor or lecturer 18
  • 19. Final Document 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 TiHonMumMim Reviewer Team TiHonMumMim Documenter Nguyen Duc Quan Team member Signature Nguyen Duc Quan Le Vu Hoang Tran Minh Phung Phan Duy Tan Huynh Da Thuc 19
  • 20. Final Document Business Plan & SRS Document 20
  • 21. Final Document STATEMENT OF WORK As the head of information systems for International University, our team is tasked with developing a new Online Course Registration System. The system will allow students to access the system during registration time to register for courses, add or drop the registered courses, check tuition fee, and review their academic history. The academic affair staffs will use the system as a mean to manage information of departments, faculties, students and offering courses. The system also supports financial office staffs in monitoring financial activities. The features of the systems can be summarized as the following table: Group of users Features OURS provides All Users Login and Log out Academic Affair Staffs Manage Department Information Manage Lecturer Information Manage Course Catalogue Manage Student Information Manage Courses Offering Financial Office Staffs Manage Financial Activities Students View Academic History Register for courses Administrator Manage User Account Our team is going to develop the system using Rational Unified Process with use-case driven. It includes four phases (inception, elaboration, construction, and transition). And in each phase, we will go through 6 workflows only (Management, Requirement, Analysis, Design, Implementation, and Testing). In fact, all 6 workflows will be done iteratively in each phase. However, attention level of ours team on each workflow in different phases is different. In particular, Inception: It can be referred as Initial phase. In this phase we will review the initial system request from customer, do feasibility study, define the vision and scope of the new system, and the initial project plan. 21
  • 22. Final Document Elaboration: It can be referred as planning & requirement phase. In this phase we will pay attention on detail plan which includes risk plan, estimation, and detail schedule. We also capture & analyze most of requirements to define the system and analyze its behaviors. Construction: It can be referred as executing, monitoring, and controlling phase which includes 3 main parts: system design, system implementation, and testing. Transition: It can be referred as closing phase. In this phase, we will complete and improve the system, and performance acceptance test to prepare for delivering the system to the stakeholders. 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 22
  • 23. Final Document involved to it together. It is created after users and stakeholders’ requirements are captured by business analysts. The most important document included in use case model is use-cases specification document. Use-case model will be done in Inception & Elaboration phases. Analysis model: It contains use-cases and theirs realization which includes domain study, analysis classes and objects, interactions and behaviors of the system. It also defines the design constraints, test plan and test cases for the system. Analysis model is mainly done in Elaboration phase. Design model: It includes system design specifications that define the system architecture and detail design of components, database, graphical user interface, and the constraints for implementation. Design model is done in Construction phase. Deployment model: It defines how we can deploy the system so that it can run on server(s). However, we intent to develop the system running on one server only, not distributed on many server. Therefore, we will not pay much attention on deployment model. This model will be done in Construction phase. Implementation model: It defines the way we transfer from logical system architecture into physical system architecture; test components (unit testing) and integrate them together in order to form a unique system that satisfies users and stakeholders’ needs. Test model: It includes many checklists and test cases that are planned and designed in previous phases. It also requires all defects or errors to be recorded in defects and errors reports. It is done in Construction phase. The detail of each workflows and models will be presented in detail schedule, and the plan for each phase. Development team will use web-base and J2EE technologies to develop the system. 23
  • 24. Final Document RESOURCE LIST Human 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 Monitor, control the project; analyze requirements Analyst, Documenter and system behaviors; and do documentation 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 Hardware Client 3 laptops 2 desktops Server Reuse one 24/7 available desktop to simulate the server for testing and deployment 24
  • 25. Final Document ESTIMATION Huynh Da Thuc estimation Name : Huynh Da Thuc Date: 11/09/2007 Estimation form /// Goal statement: To estimate the time to develop prototype for customer A and B Unit: days Category x goal tasks x quality tasks waiting time project overhead No. Task Est Del1 Del2 Del3 Del4 Total Assumption Initial 1 Write team introduction 3 1 4 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 User 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 25
  • 26. Final Document 16 Register courses use case 3 1 1 1 6 17 Manage financial activities 3 2 -3 1 3 Financial activities are quite complex 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 26
  • 27. Final Document 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 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 report 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 source 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 27
  • 28. Final Document 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 project 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 User 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 parts 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 term definitions 10 Login use case 1 1 11 Manage faculty use case 1 1 12 Manage lecturer use case 1 1 13 Manage student use case 2 2 28
  • 29. Final Document 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 15 View academic history 1 1 16 Register courses use case 4 -1 3 Team brainstorming 17 Manage financial activities 2 -1 1 only simple activities 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 29
  • 30. Final Document 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 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 source code 10 -1 -1 8 use IDE 2 Complete User Manual 6 -1 5 Thuc has a very good writing skill 3 Do acceptance test 3 3 4 Team review & evaluation 1 1 5 Complete all documents 3 3 6 Review 4 1 1 30
  • 31. Final Document 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 User 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 31
  • 32. Final Document 11 Manage faculty use case 2 0.5 0.5 3 12 Manage lecturer use case 3 0.5 0.5 4 13 Manage student use case 3 1 4 14 Manage courses offering 3 1 4 15 View academic history 4 1 1 6 16 Register courses use case 4 1 1 1 7 17 Manage financial activities 1 0.5 2 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 32
  • 33. Final Document 16 Create file structure of system 1.5 0.5 2 17 Implement GUI 10 2 12 18 Implement database 8 1.5 0.5 10 19 Implement persistence layer 9 0.5 0.5 10 20 Implement business logic layer 8 0.5 0.5 1 10 21 Implement presentation layer 7 2 1 10 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 source 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 33
  • 34. Final Document 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 User 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 34
  • 35. Final Document 9 Complete glossary 2 2 10 Login use case 3 -1 2 Login is a popular function 11 Manage faculty use case 2 1 3 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 courses 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 perform 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 35
  • 36. Final Document 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 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 source 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 36
  • 37. Final Document 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 waiting 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 User 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 brainstorming 9 Complete vision and scope 2 2 10 Team Review 2 2 11 Review 1 1 1 Planning 1 Complete statements of works 1 1 2 Plan for risk 12 -1 -1 10 Just find basic risk 3 WBS 1 1 4 Estimation & assumption 3 -1 2 Elicitation 5 Schedule 3 -1 2 Assign schedule for 1 person 6 Discussion summary 1 2 3 Sum everything in detail 7 Analyze initial requirement 2 -1 1 Stifling 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 37
  • 38. Final Document 15 View academic history 3 3 16 Register courses use case 3 3 17 Manage financial activities 2 2 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 symbolic Constant 14 Produce Integration build plan 1 1 2 Extract Method 15 Review OOAD 3 -1 2 Defect tracking 16 Create file structure of system 0.5 0.5 17 Implement GUI 7 5 12 Implement AJAX 18 Implement database 10 -1.5 -0.5 8 Use Database tool 19 Implement persistence layer 9 9 38
  • 39. Final Document 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 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 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 Estimation Summary Date: 11/09/2007 Estimation Summary form /// Goal statement: To estimate the time to develop prototype for customer Unit: days Estimators : Quan, Thuc, Tan, Hoang, Phung No. Task Thuc Tan P Q H Best Worst Avg Assumption Initial 1 Write team introduction 4 1 3 2 2 1 4 2.4 Review introduction The system request is quite 2 Review system request 3 1 4 2 2 1 4 2.4 complex than initial review Identify User and The key user and stakeholder 3 Stakeholder 3 3 3 2 3 2 3 2.8 varies and changes Gather user and stakeholder Difficult in getting appointment 4 ideas 5 2 5 1 1 1 5 2.8 and interview 5 Write Project background 3 2 4 1 2 1 4 2.4 6 Write Vision statement 6 1 6 1 1 1 6 3 7 Write Scope statement 2 1 7 1 1 1 7 2.4 The scope is quite simple Identify risks and 8 assumption 2.5 4 3 6 7 2.5 7 4.5 Team brainstorming The document should be 9 Complete vision and scope 2 1 2 1 2 1 2 1.6 review again and check any 39
  • 40. Final Document existing error Team gather late and far 10 Team Review 2 1 1 1 2 1 2 1.4 distance 11 Review 1 4 0.5 1 1 1 0.5 4 1.5 Planning Complete statements of Statement of works is more 1 works 3 0.5 2 1 1 0.5 3 1.5 complex Risk varies and should be coherent between the team 2 Plan for risk 4 9 5 11 10 4 11 7.8 members 3 WBS 5 0.5 6 1 1 0.5 6 2.7 4 Estimation & assumption 2 1 2 1 2 1 2 1.6 Idea should be coherent 5 Schedule 2 0.5 3 1 2 0.5 3 1.7 Assign schedule for 1 person The document is long and complex, need more time to 6 Discussion summary 7 1 7 2 3 1 7 4 review 7 Analyze initial requirement 6 3 2 2 1 1 6 2.8 Stifling Understand stakeholder & 8 user needs 2 2 3 2 3 2 3 2.4 The glossary should be exact 9 Complete glossary 4 1 5 2 2 1 5 2.8 and complete 10 Login use case 3 1 4 2 4 1 4 2.8 Login use case is simple 11 Manage faculty use case 2 1 3 3 4 1 4 2.6 The use case should be 12 Manage lecturer use case 3 1 4 3 4 1 4 3 reviewed many times The use case should be 13 Manage student use case 3 2 4 3 5 2 5 3.4 reviewed many times The use case should be 14 Manage courses offering 4 4 4 3 4 3 4 3.8 reviewed many times 15 View academic history 5 1 6 3 3 1 6 3.6 16 Register courses use case 6 3 7 3 3 3 7 4.4 Financial activities are quite 17 Manage financial activities 3 1 2 3 2 1 3 2.2 complex Complete functional 18 requirement 2 3 1 3 4 1 4 2.6 Complete non-functional 19 requirements 3 3 4 3 4 3 4 3.4 Team should consider carefully 20 Define the system 6 3 8 3 3 3 8 4.6 this part Manage the scope of the 21 system 5 2 11 10 13 2 13 8.2 Define carefully scope Requirement is complex and 22 Complete SRS 3 2 1 1 1 1 3 1.6 should be reviewed more 23 SRS inspection 2 1 1 1 1 1 2 1.2 24 Test Plan 3 3 3 2 1 1 3 2.4 40
  • 41. Final Document 25 Test case 3 3 3 2 1 1 3 2.4 26 Detail WBS 2 0.5 2 1 2 0.5 2 1.5 Scope Creep 27 Re-estimation & assumption 2 1 1 1 2 1 2 1.4 28 Detail Schedule 2 0.5 1 1 2 0.5 2 1.3 Misunderstood predecessor 29 Team review 3 1 1 1 2 1 3 1.6 30 Review 2 2 1 1 1 1 1 2 1.2 Execution Define candidate 1 architecture 2 5 2 3 2 2 5 2.8 Fix J2EE model Refinement should last for 2 Refine the architecture 2 2 1 1 0.5 0.5 2 1.3 more session 3 Analyze behaviors 2 1 1 1 0.5 0.5 2 1.1 4 Complete analysis model 3 1 2 1 2 1 3 1.8 Review model Complete design model & 5 system architecture 3 3 2 1 2 1 3 2.2 The architecture grows rapidly 6 Design GUI 3 1 2 2 3 1 3 2.2 Use AJAX 7 Design database 2 2 2 1 1 1 2 1.6 8 Design persistence layer 3 1 2 1 2 1 3 1.8 9 Design business logic layer 2 1 2 1 2 1 2 1.6 10 Design presentation layer 3 1 2 1 2 1 3 1.8 Use AJAX 11 Design test case 2 3 2 2 1 1 3 2 Many test cases Complete Implementation 12 model 2 2 2 2 1 1 2 1.8 Complete Implementation guidelines & code Replace Magic Number with 13 conventions 2 0.5 1 1 1.5 0.5 2 1.2 symbolic Constant Produce Integration build 14 plan 1 1 2 1 2 1 2 1.4 Extract Method 15 Review OOAD 1 1 1 1 2 1 2 1.2 Defect tracking Create file structure of 16 system 1 1 2 1 0.5 0.5 2 1.1 17 Implement GUI 10 5 12 9 12 5 12 9.6 Implement AJAX 18 Implement database 11 11 10 9 8 8 11 9.8 No experience in using MySQL 19 Implement persistence layer 11 9 10 9 9 9 11 9.6 Implement business logic 20 layer 9 10 10 9 9 9 10 9.4 Implement presentation 21 layer 9 7 10 9 10 7 10 9 Review code & update Fixing bugs and updates 22 changes 3 1 2 1 2 1 3 1.8 encounter difficulty 23 Integrated build 2 1 2 1 2 1 2 1.6 24 Do integration test 2 1 2 1 2 1 2 1.6 25 Test build 2 2 2 1 1 1 2 1.6 26 Test system 3 2 3 2 1 1 3 2.2 System should be tested well 41
  • 42. Final Document Inspection meeting should be established between this duration to ensure the report is 27 Complete test report 8 5 9 8 9 5 9 7.8 defection-free and coherent 28 Rework 6 3 7 5 6 3 7 5.4 Broken build 29 Team review & evaluation 2 1 2 1 1 1 2 1.4 30 Review 3 3 1 1 1 1 1 3 1.4 Closing Need coherence and re-check 1 Complete source code 12 8 13 12 14 8 14 11.8 logic functionality 2 Complete User Manual 7 5 8 7 9 5 9 7.2 User manual must be in detail Acceptance test is brand new 3 Do acceptance test 5 3 6 5 6 3 6 5 to team 4 Team review & evaluation 2 1 3 2 3 1 3 2.2 5 Complete all documents 7 3 8 6 7 3 8 6.2 Need time for review 6 Review 4 2 1 1 1 1 1 2 1.2 Total 289 181 295 215 253 144 352 246 42
  • 43. Final Document SCHEDULE 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 43
  • 44. Final Document 35 Define the system 3 days 24/10/2007 26/10/2007 Hoang 36 Manage the scope of the system 10 days 15/10/2007 26/10/2007 Quan 37 Complete SRS 1 day 29/10/2007 29/10/2007 35,33,34,24 Quan 38 SRS inspection 1 day 31/10/2007 31/10/2007 37 Team 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 44
  • 45. Final Document 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 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 Gantt chart (reference) 45
  • 46. Final Document 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 2 3 6 in 2 months only. Therefore, project and supervise process of work with 46
  • 47. Final Document the pressure is really high. schedule, change schedule with any mismatch with schedule. 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 47
  • 48. Final Document DISCUSSION SUMMARY Project background Purpose of project There is a widespread agreement that the policy in course registration is very complicated, costly, take-time, and inconvenient to both students and university. This is due the fact that at the beginning of each semester, the university has to pause or delay some activities to spend time for course registration of students. Some staffs have to prepare for offering courses list (including selecting courses and inviting lecturers …), print it out, and deliver the registration form to each student. After around one week, all students’ registration form will be returned. In addition, the staffs have to input students’ registration information to Excel files. They also have to check manually whether the registration form of each student is legal or not basing on some conditions such as prerequisite course, maximum and minimum number of credits allowed registering … If there is anything wrong or students want to add or drop the courses, everything in the above process has to be restarted. Moreover, sometimes some papers are lost when documents are moved from one place to another place; both students and university have to spend time for retrieving necessary information and approve it. However, it is impossible to do that in some cases. In addition, calculating tuition fee for students, managing students’ academic history… are also thorny issues. Mistakes can occur anytime when financial office‘s staffs use calculator or Microsoft excel to calculate tuition fee. Students’ transcript management is also another issue. When students want to have transcript to see their academic history, they have to wait at least two weeks to receive it from academic affair. Those are some typical examples for the inconvenience and complication of the current course registration policy. They lead the university to the decision of building Online Course Registration System to improve effectiveness, reduce time and cost in course registration process. 48
  • 49. Final Document 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 Login and specific user. It also lets the user log out his/her session. o If the username and password are correct, the system redirects the logout user to his/her specific homepage (student, administrator or officers…). o Otherwise, the system warns the user with the error messages. The account is locked out if the user fails to log in three times. User has to wait 30 minutes for the account to be released or contact to the administrator o Users also have another option to choose when they forget the password and intend to reset back to the default password. o User can change their own password and change the security question o This feature allows a Student to view his studying progress. The View Academic History Student can see the courses he has taken as well as the scores and status (passed or failed)as follow:  View all courses he took.  View courses in a specific semester in a specific year.  View all courses he passed.  View all courses he failed. 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 Department faculty information. This includes adding, updating, and deleting Information department and faculty from the system. o This feature allows the Academic Affair Staff to manage student Manage Student information in the registration system. This includes adding, updating, 49
  • 50. Final Document Information deleting, and searching students from the system. o This feature allows Academic Affairs to monitor course offerings in one Manage 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 financial fee. This includes viewing and updating the tuition fee status of activities students. o Following tasks are included in this feature:  View tuition fee View by ID and name View by faculty and academic duration View by course, semester, and academic year o Update tuition fee of students o This feature allows the Academic Affair Staff to manage Course Manage Course Catalogue Catalogue Information in the registration system. This includes adding, updating, deleting, and searching Course Catalogue Information from the system. o This feature allows the Administrator to Create User Account, Reset Manage User Accounts User Password, Delete or Edit User Account, Unlock User Account 50
  • 51. Final Document Perspectives Who will use the system? User Description Student The people who attending the course in the university. Use the system to register the courses and view academic history Academic Affair The Staff who is working in the Academic Affair Office, responsible for Staff the Academic issue in the University. They use the system to manage school, lecturer, and student information Financial Office Staff The Staff who is responsible for the financial business in the University. Use the system to monitor financial activities related to course registration Who can provide needs about the system? Student The Student needs an online mechanism to register, add and drop course instead of the paper based process The Student needs to view their academic history every time and every where they want instead of waiting the respond from the Academic Office Academic Affair staff 1. The Staff of the Academic Affair Staff needs to manage the course information, department information. 2. Easy to use, easy update, easy to modify Financial Office staff 1. The Staff needs to manage the financial business of the University 2. They would view the Student tuition fee status Lecturer They could give ideas or comment on the solution for the system’s development and improvement 51
  • 52. Final Document Project objectives Know business rules 1. In the old paper-based mechanism, the process of registration as follow a. The Students receive the Registration form and register the course for the semester b. The Registration forms are transferred to the Academic Affair Staff c. Academic Affair Staff process the Registration Form d. The Students receive the report from offering course from the Academic Affair Staff e. If any Student wants to add or drop course(s), the process restarts 2. At each beginning of the semester, the Academic Affair Staffs make the list of course and provide to each Faculty to distribute to the Students. They also manage the number of Lecturer, the Department. All is the paper – based process. 3. After receiving the reports from the Academic Affair Staffs, the Students also receive the financial report from the Finance Office. The Finance Officers have to manage the financial information status of each student, decide the financial business of each student and make the report to each student. System information and/or diagrams System context: OURS is a part of university management system. It can interact with other sub-system of university management system such as scheduling system, grading system, student management system, payment system … University Online university System registration system 52
  • 53. Final Document OURS will be used by students, academic affair staffs, financial office staffs, administrator with functionalities showed in following diagram. 53
  • 54. Final Document Assumptions and dependencies 1. The system will be applied for universities using credit system like International University. 2. The registration information of students is processed by academic affair. And only academic affair has right to manage and process the registration information. 3. Development team will use J2EE architecture to develop system. 4. Policy for tuition fee payment is using cash and it is managed by financial office. 5. Development team must have at least one 2-hour meeting per week. 6. Development time is 2 months and 10 days 7. Development team must produce the first build before the review 3 8. Each team member must work at least 15 hours per week. Design and implementation constraint 1. The system will be developed using J2EE technology 2. The system provides the service in two languages Vietnamese and English Risks 1. All team members need preparation time for midterm, final exam, and other subjects. 2. Phung, Thuc, and Hoang take pre-thesis course. 3. Lack of experiences in software project management, especially in testing, verification, validation, risks management and changes management exists in the Team. 4. No substitution if any team member cannot continue to contribute to the project. Applying the project again from the beginning could take development team more time. 5. Development time is limited in 2 months only. Therefore, the pressure is really high. 6. Development team cannot deliver the components when reviewed. Development team could deliver components of unacceptably low quality, and time must be added to improve quality. 7. Developing extra functionalities that are not required will extends the schedule. 8. Low motivation and moral reduce productivity. 9. Team member needs extra time to learn unfamiliar tools or techniques. 10. Conflicts among team members’ ideas results in poor performances, more meeting, and extra rework. 54
  • 55. Final Document 11. People’s assignments do not match their strengths. 12. Components developed separately cannot be integrated easily, requiring redesign and rework. 13. Detail reporting could take more development time. Known future enhancements 1. Pay tuition fee (billing system): The Student can access to a billing system and perform the transaction online such as transferring money to the Bank account of the University, receiving the discount money from the University policies. This function would be involved with the other banking system, authentication and security issue which are out of the scope of the this development 2. Lecturer Assessment: Initially, the users who can access to the system are Students, Academic Affair Staffs, and Financial Officer. The Lecturer plays a role as an observer. However, in the future, the Lecturer can log in to the system to view course, to access to their homepage in order to make the contact with the Students. Grading system is also considered in the future. References For further information, the reader should examine the Vision and Scope document, the SRS document. Open, unresolved issues Schedule and time table construction are not completed at the recent time 55
  • 56. Final Document SOFTWARE REQUIREMENT SPECIFICATION USE CASE SPECIFICATION Log in and Log out Name Use Case: Log in and Log out Summary This use case allows user to log in to the system to achieve the access permission to perform other functions that are granted to that specific user. It also lets user log out to end his/her session Rationale The system provides functions such as course registration, financial management just for the specific users (Students, ACADEMIC AFFAIR STAFF…). Therefore, logging in/out helps to distinguish type of user. Users All users Precondition None. Basic course of 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 In step 4, if the username and password do not match, the system will paths return the log in homepage with the error message MS001 (see Appendix). The system will allow the user to log in 3 times before it locks the user account and displays an error message MS002. Not remember password In step 1, the system provides the user another option, call “Not remember password”. The users will use this option to recover their forgotten password by giving the username, answer a security question. Then the system will set the password to a default value. The user can use the password to log in or change the new password. Account locked In step 3, if the user account is locked, the system notifies the user that the account is locked with the error message MS002. 56
  • 57. Final Document Account logging in simultaneously In step 2, if the account is logged by another user, the second user can not log in by that username and password. An error message MS003 will be provided. Create the security question and answer In step 3, if the user logs in successfully for the first time, the system will check for the security question and answer. If the security question and answer is blank, the system prompts the user to specify the security question and answer. Update password In step 3, if the user logs in successfully for the first time, the system will ask user to change the default password. Post If the logging in is successful, the system will redirect the user to his specific Conditions homepage. 57
  • 58. Final Document 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 - 2. Once the Academic Affair Staff provides the requested information and 58
  • 59. Final Document 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 If, in the Delete s Department sub-flow, the Academic Affair Staff decides paths 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. 59
  • 60. Final Document 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, ACADEMIC AFFAIR STAFFStaff 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 - Degree - 2. Once the Academic Affair Staff provides the requested information and 60
  • 61. Final Document 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 If, in the Delete a Lecturer sub-flow, the Academic Affair Staff decides not paths to delete the lecturer, the delete is cancelled, and the Basic Flow is re- started at the beginning Update Cancelled 61
  • 62. Final Document 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. 62
  • 63. Final Document 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 ACADEMIC AFFAIR 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 - Address - Faculty - 63
  • 64. Final Document Priority(a child of dead or wounded soldiers, belong to highland - area, or other priority) Academic Year - 2. Once the Academic Affair Staff provides the requested information and confirmations, the student is added to the system. 3. The system provides the Academic Affair Staff with a summary of information of student newly added. Update a Student 1. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty & academic duration, academic year & semester & course). 2. The Academic Affair Staff chooses a filter group, then inputs necessary information for the filters, and confirms to search. 3. The system returns a list of student whose information matches the filter’s inputs 4. The Academic Affair Staff chooses the student that he/she wants to update. 5. The system displays the student information 6. The Academic Affair Staff makes the desired changes to the student information. This includes any of the information specified in the Add a Student sub-flow 7. The system prompts message MS007 to the Academic Affair Staff to confirm the updating of the student. 8. The system updates the student information Delete Student(s) 1. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty & academic duration, academic year & semester & course). 2. The Academic Affair Staff chooses a filter group, then inputs necessary information for the filters, and confirms to search. 3. The system returns a list of student(s) whose information matches the filter’s inputs 4. The Academic Affair Staff chooses the student(s) that he/she wants to delete. 64
  • 65. Final Document 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 In Search a Student sub-flows, if there’s no student whose information paths 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. 65
  • 66. Final Document Manage Course Offering Name Use Case: Manage Course Offering Summary This use case allows Academic Affairs to monitor course offerings in one semester of specific year. Rationale Each student receives a list course to register at the beginning of each semester. Using the feature “Manage Course Offering”, an ACADEMIC AFFAIR STAFF can easy to create, update or delete the course list and sooner distribute to the Students within the short time 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. 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 66
  • 67. Final Document 4. The system creates and stores the offering courses list of the selected faculty. Update list of course offerings 1. The system displays curriculum and offering courses list currently existing of selected faculty 2. Academic Affair Staff updates a course in this list If Academic Affair Staff wants to add one or more course, sub flow “Add a course offering” is executed. If Academic Affair Staff wants to add one or more course, sub flow “Delete a course offering” is executed. If Academic Affair Staff wants to change lecturer of a specific course, sub flow “Change lecturer” is executed. 3. Academic Affair Staff confirms his/her modification 4. The system updates all changes. Add a course offering 1. Academic Affair Staff chooses a subject from the curriculum. 2. The system holds the selected subject 3. The system displays list of available lecturers in the department to which the subject belongs. 4. Academic choose a lecturer for selected subject 5. The system adds the selected subject with specific lecturer attached to it into the offering courses list. Delete a course offering 1. Academic Affair Staff chooses a course offering from the list of course offerings to delete. 2. The system asks user for confirmation. 3. User confirms to delete. 4. The system removes the selected course offering. Change Lecturer 1. Academic Affair Staff chooses a course offering from the list of course offerings to change the lecturer. 2. The system displays list of available lecturers in the department to 67
  • 68. Final Document 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 In the step 3 of main flow, if this faculty does not have a list of course paths 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. 68
  • 69. Final Document 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 1. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty & academic duration, academic year & semester & course). 69
  • 70. Final Document 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 In Search a Student sub-flows, if there’s no student whose information paths 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. 70
  • 71. Final Document 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 ACADEMIC AFFAIR STAFF to deliver the transcript contains all above information. In contrast, the Student can easily access to his account and view his/her Academic history online whenever he/she wants. Users Students Precondition Users logged in the system as the role of a student. 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. 71
  • 72. Final Document Register Course Name Use Case: Register Course Summary This use case allows a Student to register course offerings in the current semester. Rationale With old system, the Students have to fill in the Registration forms and hand them to the ACADEMIC AFFAIR STAFF and wait for approvals. The process takes a long time. Therefore, it is significant to reduce the time and make the process shorter. The Students can find it happily with the feature “Register Course” which performs everything online. Users Students Precondition Users logged in the system as the role of a student. 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. Course Registration Closed Alternatives 72
  • 73. Final Document 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. 73
  • 74. Final Document Manage Course Catalogue Name Use case: Manage Course Catalogue Summary This use case allows the Academic Affair Staff to manage Course Catalog information in the registration system. This includes adding, updating, deleting, and searching a course from the course catalog of the university Rationale The number of courses in the course catalogue of the university is really large. And courses management is a challenging work for Academic Affair Staff if he/she works with paper-based system. Therefore, with the system, he/she will take the advantages of computer-base system to reduce the effort when doing course catalogue management. User Academic Affair Staff Precondition User logged in the system as the role of Academic Affair Staff. Basic Flow of This use case starts when the Academic Affair Staff wishes to add, update, Event delete, and/or search the information of a course in course catalogue. 1. The system requests the Academic Affair Staff to specify the function he/she would like to perform (either Add a course, Search course(s), Update a course, or Delete a course) 2. Once the Academic Affair Staff provides the requested information, one of the sub-flows is executed If the Academic Affair Staff selects “Add a course”, the “Add a course” sub-flow is executed If the Academic Affair Staff selects “Update a course”, the “Update a course” sub-flow is executed If the Academic Affair Staff selects “Delete a course”, the “Delete a course” sub-flow is executed If the Academic Affair Staff selects “Search course(s)”, the “Search course(s)” sub-flow is executed Add a Course 1. The system requests that the Academic Affair Staff enter the information of course. This includes: Course ID - Name - Number of credits - Faculty - 74
  • 75. Final Document Description - 2. Once the Academic Affair Staff provides the requested information and confirmations, the course is added to the system. 3. The system provides the Academic Affair Staff with a summary of information of course newly added. Update a course 1. The system requests the Academic Affair Staff to specify course ID or Course Name that he wants to update. 2. The system displays the information of the selected course. 3. The Academic Affair Staff makes the desired changes to the course information. This includes any of the information specified in the Add a course sub-flow 4. The system prompts the Academic Affair Staff to confirm the updating of the course. 5. The system updates the course information Delete a course 1. The system requests the Academic Affair Staff specify course ID or Course Name 2. The system displays the information of the selected course and asks user to confirm the deletion. 2. The Academic Affair Staff confirms the deletion. 3. The system deletes the selected course. Search course(s) 4. The system requests the Academic Affair Staff to choose a filter group (ID & name, faculty, Number of credits). 5. The Academic Affair Staff chooses a filter group, then inputs necessary information for the filters, and confirms to search. The system returns a list of course(s) whose information matches the filter’s inputs. Course Not Found Alternative In Search course(s) sub-flows, if there’s no course whose information Paths matches the filter’s inputs, the system displays the error message “Course does not exist in the course catalogue”. The Academic Affair Staff can then enter different values of the filters or cancel the operation, at which point the use case ends. 75
  • 76. Final Document Delete Cancelled If, in the Delete a course sub-flow, the Academic Affair Staff decides not to delete the course, the delete operation is cancelled, and the Basic Flow is re-started. Update Cancelled If, in the Update a course sub-flow, the Academic Affair Staff decides not to update the course, the update operation is cancelled, and the Basic Flow is re-started. Post Condition If the use case is successful, the course information is added, updated, or deleted from course catalogue. 76
  • 77. Final Document Manage User Account Name Use case: Manage User Account Summary This use case allows the Administrator to manage user account information in the system. This includes creating, updating, deleting, and searching user account(s) in the system Rationale The university provides each student, academic affair staff, and financial office staff with one account login the system with different rights when using the system. User Administrator Precondition User logged in the system as administrator of the system Basic Flow of This use case starts when the Administrator wishes to create, update, delete, Event and/or search the information of user account(s). 1. The system requests the Administrator to specify the function he/she would like to perform (either Create an account, Search account(s), Update an account, or Delete an account) 2. Once the Administrator provides the requested information, one of the sub-flows is executed If the Administrator selects “Create an account”, the “Create an account” sub-flow is executed If the Administrator selects “Update an account”, the “Update an account” sub-flow is executed If the Administrator selects “Delete an account”, the “Delete an account” sub-flow is executed If the Administrator selects “Search course(s)”, the “Search course(s)” sub-flow is executed Create an account 1. The system requests that the Administrator specify the information of the account. This includes: Username - Role(which can be student, academic affair staff, financial office - staff, or admin) Description - Other information will use the default values - o Password: Abcd1234 77
  • 78. Final Document o Status: available 2. Once the Administrator provides the requested information and confirmations, the account is added to the system. 3. The system provides the Administrator with a summary of information of the account newly added. Update an account 1. The system requests the Administrator to specify username he wants to update. 2. The system displays the information of the selected account. 3. The Administrator makes the desired changes to the account information. This includes any of the information specified in the Create an account sub-flow 4. The system prompts the Administrator to confirm the updating of the account. 5. The system updates the account information Delete an account 1. The system requests the Administrator specify username 2. The system displays the information of the selected account and asks user to confirm the deletion. 3. The Administrator confirms the deletion. 4. The system deletes the selected account. Search account(s) 1. The system requests the Administrator to specify username. 2. The system returns the account whose information matches the input username. Account Not Found Alternative In Search account(s) sub-flows, if there’s no account whose information Paths matches the input, the system displays the error message “Account does not exist in the system”. The Administrator can then enter different values or cancel the operation, at which point the use case ends. Delete Cancelled If, in the Delete an account sub-flow, the Administrator decides not to delete the account, the delete operation is cancelled, and the Basic Flow is re-started. 78
  • 79. Final Document Update Cancelled If, in the Update an account sub-flow, the Administrator decides not to update the account, the update operation is cancelled, and the Basic Flow is re-started. Post Condition If the use case is successful, the user account information is added, updated, or deleted from the system. 79
  • 80. Final 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 Are you sure you want to update Update tuition fee MS011 Question tuition fee status of current OK – Cancel status student? MS012 Info Student not found Cannot find the result. OK 80
  • 81. Final Document 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? 81
  • 82. Final Document 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 82
  • 83. Final 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 83
  • 84. Final 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. 84
  • 85. Final Document Reference Use-case: Manage financial activities Name FR-8: Grade management policy Summary The system stores the final grade and status of that subject of student only. Rationale This is not a grading system. Therefore, we do not care all kind of grades such as midterm, homework grades. Requirement The system only stores the final grade of each course for students. Maximum grade is 100. Grade over 50: passed Grade under 50: failed Reference Use-Case: View Academic History Name FR-9: Password constraints Summary For security, password should have constraints Rationale For easy to recovery password and secure the user account Requirement The minimum length is 8 The default password is Abcd1234 Reference Use-Case: Login & Logout 85
  • 86. Final Document NON-FUNCTIONAL REQUIREMENT Introduction: The Non-functional Requirements are requirements that are not readily captured in the use case model. These requirements will apply on OURS and cover all following aspects: Performance: Support 100 simultaneously users 1. 90% request has response within 10 seconds. 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. Availability: System should be supported 24/7 for on line application. Efficiency: 1. System should be provided at least 1 Mbps bandwidth connection. 2. Database is able to retain volume of data desired by University, not less than 20.000 students in 10 years; with maximum of course list is 500 courses. Supportability: Localization: i. Support for the following language must be provided: a. English b. Vietnamese ii. Language could be selectable. Integrity: User could enter password to login only 3 times, if they fails, this user account will be locked 1. in 30ph: user could not log in the system in an account when this account is locked. At any moment, an account is used only by 1 user. 2. 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 86
  • 87. Final Document (Glassfish). Flexibility: After system is deployed, system could be developed these other functions: 1. Lecturer chooses course to teach 2. Academic affair creates schedule for class 3. Financial staff get document from system for billing 87
  • 88. Final Document 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 88
  • 89. Final Document GLOSSARY Introduction This document is used to define terminology specific to the domain problem, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. Definitions The glossary contains the working definitions for the key concepts in the Course Registration System. OURS Online University Registration System Academic staff A person working in academic affair and managing academic information (student, lecturer, course offering, department and faculty) Finance staff A person working in finance office and managing finance activities (tuition fee, etc) Department All professors belong to a department which plays the same role as the faculty in the aspect of lecturer. A department has at most 1 faculty. Faculty All students belong to a faculty which is responsible for the academic affair of a field of study in the University Curriculum All the courses in a faculty a student studies in university. Subject Name of a course opened by university 89
  • 90. Final Document Course Offering A specific course with a lecturer opened in a specific semester offered by Academic affair staff for some faculties Prerequisite A prerequisite of a course is courses a student must finish in order to take this course Course Catalog The catalog of all courses offered by the university Lecturer A person teaching courses at the university Student A person enrolled in courses at the university. A student belongs to one faculty. Student priority The background of the student to get discount in tuition fee Discount rate The percentage of reduction of tuition fee a student can get for his priority Grade The academic result of a particular student for a particular course offering Schedule The list of course offering a student has selected to study the current semester. Tuition fee A fee student needs to pay for university in a semester. Credit A unit to represent the weight of a subject Academic duration Planned time for student for study in university 90
  • 91. Final Document Academic year Each academic year in the university consists two semesters, starts from September and ends in May the following year (Ex: 2007-2008) 91
  • 92. Final Document Testing Plan & Test case Document 12/7/2007 Ho Chi Minh National University – International University Instructor: Phan Viet Hoang Group 6 Date December 7th , 2007 Version 1.0 Status Baseline Author Team TiHonMumMim Reviewer Team TiHonMumMim Documenter Nguyen Duc Quan Team member Signature Nguyen Duc Quan Le Vu Hoang Tran Minh Phung Phan Duy Tan Huynh Da Thuc 92
  • 93. Final Document Testing Plan & Test case Document 93
  • 94. Final Document A- Test Plan Introduction Purpose This document describes the plan for testing the Online University Registration System [OURS]. This Test Plan document supports the following objectives: Identify ours project information and its components that should be tested. List the recommended test requirements (high level). Recommend and describe the testing strategies. Identify the required resources, provide an estimate of the test efforts, and detail testing schedule. List the deliverable elements of the test activities. Scope This Test Plan applies to unit test, integration test and system test that will be conducted on the Online University Registration System [OURS]. It is assumed that unit testing already provided thorough black box testing through extensive coverage of source code and testing of all module interfaces. This Test Plan applies to test all requirements of the [OURS] as defined in the Vision and Scope Document, Use-case specification, and software requirement specification document. References Vision and Scope document Business Plan and SRS document Review requirement and Design The following is the updated use case model. 94
  • 95. Final Document Review system architecture From the updated requirement, our team sees that the number of functions the system provides is too large in comparison with the scope of the system. This brings us to the decision to divide the original system into many subsystems as follow. 95
  • 96. Final Document System architecture with sub-system model System architecture with layer model 96
  • 97. Final Document Features to be tested We will perform testing on use case specification, functional requirement, and non-functional requirement of all use cases and functions. They include o User login and logout  Login  Logout  Reset password o View Academic History (depend on filter selected by user) o Register for course o Manage Department Information  Add a department  Update a department  Delete a department  Viewing information o Manage Student Information  Add a student  Update a student  Delete a student  Search for student(s) (for viewing or updating or deleting) o Manage Lecturer Information  Add a lecturer  Update a lecturer  Delete a lecturer  Viewing information 97
  • 98. Final Document o Manage Course Catalog  Add a course  Update a course  Delete a course  Search for course(s) o Manage Offering Courses  Create list of course offering  Update list of course offering  Add a course offering  Delete a course offering  Change lecturer of a course offering o Manage Financial Activities  View tuition fee information of student(s)  Update tuition fee status of student(s) o Manage User Account o Create an account o Update an account o Delete an account o Search for account(s) The test cases will be separated in later part. Therefore, we do not put the list of test cases here. Features not to be tested Because we will test all features of the system we have defined, there is no feature that will not be tested. 98
  • 99. Final Document Approach Kind of test The tests below base on the use case specifications, functional requirements, and non-functional requirements which have been identified as the targets for testing Besides, we also show the kinds of test which our team intend to perform. Data and Database Integrity Testing Data integrity and database integrity test techniques verify that data is being stored by the system in a manner where the data is not compromised by updating, restoration, or retrieval processing. This type of testing is intended to uncover design flaws that may result in data corruption, unauthorized data access, lack of data integrity across multiple tables, and lack of adequate transaction performance. The database, data files, and the database or data file processes should be tested as a subsystem within the application. System testing System testing of software is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. They includes the following functions  User login and logout  View Academic History  Register for course  Manage Department Information  Manage Student Information  Manage Lecturer Information  Manage Course Catalog  Manage Offering Courses  Manage Financial Activities  Manage User Account 99
  • 100. Final Document Performance Testing Performance Testing covers a broad range of engineering or functional evaluations where a material, product, or system is not specified by detailed material or component specifications: Rather, emphasis is on the final measurable performance characteristics. Load Testing Load testing is the process of creating demand on a system or device and measuring its response. Stress Testing Stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. Stress testing may have a more specific meaning in certain industries. Verify system response during maximum student logins. Volume Testing Volume Testing belongs to the group of non-functional tests, which are often misunderstood and/or used interchangeably. Volume testing refers to testing a software application for a certain data volume. Verify system response when Course Catalog Database at 90% capacity. Test Strategy The Test Strategy presents the recommended approach to the testing of the software applications. The previous section on Test Requirements described what kinds of test will be tested. This part describes how they will be performed. The main considerations for the test strategy are the techniques to be used and the criterion for testing to be completed. However, before starting the system test (both functional and non-functional requirements testing), we must perform unit test for each unit of the system (fields, methods, classes, and components) and make sure that all unit must pass the checklist of unit test. Checklist of unit test Verify the input data length specified in the database or in EJB Verify the input data format specified in each form, classes, and interaction with database String format Integer number format 100
  • 101. Final Document Email address format Date format Special character Empty field Null Test write Test write null field Test write read Test getter setter Doing this kind of checking help us to decrease the number of simple test cases Unit testing According to the system architecture, we have to test all entities, ejb3 session bean, struts actions… In order to complete this kind of test, we will use JUnit and EJB3Unit as tools for implement and execute the unit test. Smoke test Because the number of use cases and the number of test cases are really large, we cannot demo all of them. Therefore we will define a smoke test for demonstration. Our smoke test includes test cases of 3 main use cases of the system: Login and Logout use case Manage courses offering user case Register for courses use case For the detail of each test case, please reference to the part of test case in later part. Test Automation Test automation is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions. 101
  • 102. Final Document All the tools that are used for test automation please reference to the part of tools in later part. Data and Database Integrity Testing The database data and database processing should be tested as separate systems. These systems should be tested without the applications (as the interface to the data). Additional research into the DBMS needs to be performed to identify the tools / techniques that may exist to support the testing identified below. Test Objective Ensure Database access methods and processes function properly and without data corruption. Technique Invoke each database access method and process, seeding each with valid and invalid data (or requests for data). Inspect the database to ensure the data has been populated as intended, all database events occurred properly, or review the returned data to ensure that the correct data was retrieved (for the correct reasons) Completion Criteria All database access methods and processes function as designed and without any data corruption. Special Considerations Testing may require a DBMS development environment or drivers to enter or modify data directly in the databases. Processes should be invoked manually. Small or minimally sized databases (limited number of records) should be used to increase the visibility of any non-acceptable events. System Testing Testing of the application should focus on any target requirements that can be traced directly to use cases (or business functions), and business rules. The goals of these tests are to verify proper data acceptance, processing, and retrieval, and the appropriate implementation of the business rules. This type of testing is based upon black box technique, which is, verifying the application (and its internal processes) by interacting with the application via the GUI and analyzing the output (results). Following is an outline of the testing recommended for each application. Test Objective Ensure proper application navigation, data entry, processing, and retrieval. 102
  • 103. Final Document Technique Execute each use case, use-case flow, or function, using valid and invalid data, to verify the following: The expected results occur when valid data is used. The appropriate error / warning messages are displayed when invalid data is used. Each business rule is properly applied. Completion Criteria All planned tests have been executed. All identified defects have been addressed. Special Considerations Access to the OURS Server and the existing Course Catalog System is required. Performance Testing Performance testing measures response times, transaction rates, and other time sensitive requirements. The goal of Performance testing is to verify and validate the performance requirements have been achieved. Performance testing is usually executed several times, each using a different quot;background loadquot; on the system. The initial test should be performed with a quot;nominalquot; load, similar to the normal load experienced (or anticipated) on the target system. A second performance test is running using a peak load. Additionally, Performance tests can be used to profile and tune a system's performance as a function of conditions such as workload or hardware configurations. NOTE: Transactions below refer to quot;logical business transactionsquot;. These transactions are defined as specific functions that an end user of the system is expected to perform using the application, such as add or modify a given contract. Test Objective Validate System Response time for designated transactions or business functions under a the following two conditions: - Normal anticipated volume - Anticipated worse case volume Technique Use Test Scripts developed for Business Model Testing (System Testing). Modify data files (to increase the number of transactions) or modify scripts 103
  • 104. Final Document to increase the number of iterations each transaction occurs. Scripts should be run on one machine (best case to benchmark single user, single transaction) and be repeated with multiple clients (virtual or actual, see special considerations below). Completion Criteria Single Transaction / single user: Successful completion of the test scripts without any failures and within the expected / required time allocation (per transaction) Multiple transactions / multiple users: Successful completion of the test scripts without any failures and within acceptable time allocation. Special Considerations: Comprehensive performance testing includes having a quot;backgroundquot; load on the server. There are several methods that can be used to perform this, including: quot;Drive transactionsquot; directly to the server, usually in the form of MySQL calls. Create quot;virtualquot; user load to simulate many (usually several hundred) clients. Remote Terminal Emulation tools are used to accomplish this load. This technique can also be used to load the network with quot;traffic.quot; Use multiple physical clients, each running test scripts to place a load on the system. Performance testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement. The databases used for Performance testing should be either actual size, or scaled equally. Load Testing Load testing measures subjects the system-under-test to varying workloads to evaluate the system's ability to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues). 104
  • 105. Final Document NOTE: Transactions below refer to quot;logical business transactionsquot;. These transactions are defined as specific functions that an end user of the system is expected to perform using the application, such as add or modify a given contract. Test Objective Verify System Response time for designated transactions or business cases under varying workload conditions. Technique Use tests developed for Business Cycle Testing. Modify data files (to increase the number of transactions) or the tests to increase the number of times each transaction occurs. Completion Criteria Multiple transactions / multiple users: Successful completion of the tests without any failures and within acceptable time allocation. Special Considerations Load testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement. The databases used for load testing should be either actual size, or scaled equally. Stress Testing Stress testing is intended to find errors due to low resources or competition for resources. Low memory or disk space may reveal defects in the software that aren't apparent under normal conditions. Other defects might results from competition for shared resource like database locks or network bandwidth. Stress testing identifies the peak load the system can handle. NOTE: References to transactions below refer to logical business transactions. Test Objective Verify that the system and software function properly and without error under the following stress conditions: little or no memory available on the server (RAM) Maximum (actual or physically capable) number of clients connected (or simulated) Multiple users performing the same transactions against the 105
  • 106. Final Document same data / accounts Worst-case transaction volume / mix (see performance testing above). NOTES: Stress testing's goal might also be stated as identify and document the conditions under which the system FAILS to continue functioning properly. Technique Use tests developed for Performance Testing. To test limited resources, tests should be run on single machine, RAM and DASD on server should be reduced (or limited). For remaining stress tests, multiple clients should be used, running either the same tests or complementary tests to produce the worst-case transaction volume / mix. Completion Criteria All planned tests are executed and specified system limits are reached / exceeded without the software or software failing (or conditions under which system failure occurs is outside of the specified conditions). Special Considerations Stressing the network may require network tools to load the network with messages / packets. The DASD used for the system should temporarily be reduced to restrict the available space for the database to grow. Synchronization of the simultaneous clients accessing of the same records / data accounts. Volume Testing Volume Testing subjects the software to large amounts of data to determine if limits are reached that cause the software to fail. Volume testing also identifies the continuous maximum load or volume the system can handle for a given period. For example, if the software is processing a set of database records to generate a report, a Volume Test would use a large test database and check that the software behaved normally and produced the correct report. Test Objective Verify that the application / system successfully functions 106
  • 107. Final Document under the following high volume scenarios: Maximum (actual or physically capable) number of clients connected (or simulated) all performing the same, worst case (performance) business function for an extended period. Maximum database size has been reached (actual or scaled) and multiple queries / report transactions are executed simultaneously. Technique Use tests developed for Performance Testing. Multiple clients should be used, either running the same tests or complementary tests to produce the worst case transaction volume / mix (see stress test above) for an extended period. Maximum database size is created (actual, scaled, or filled with representative data) and multiple clients used to run queries / report transactions simultaneously for extended periods. Completion Criteria All planned tests have been executed and specified system limits are reached / exceeded without the software or software failing. Special Considerations What period of time would be considered an acceptable time for high volume conditions (as noted above)? Suspension criteria and resumption requirements Suspension criteria Three use cases have more than 2 major errors or fours minor errors, then the build is not acceptable and the testing is suspended. Resumption requirements All major errors & and at least 70% of minor errors that have been found in previous iteration are fixed 107
  • 108. Final Document Environmental Needs Tools Testing tools Tool Version Unit Testing Junit and EJB3Unit Latest version Functional requirement testing QuickTest Professional 9.2 Non-functional requirement AdventNetQEngine 6.0 testing Software Documentation tool Microsoft word 2007 Scheduling tool Microsoft project 2007 IDE Netbean 6.0 Web Server Glassfish server 2.0 MySQL GUI tool 5.0 DBMS MySQL 5.0 Photoshop CS2 Design tool Microsoft Express Web Designer JDK JDK 6.0 Browser Internet Explorer 6.0, 7.0 Firefox, Opera Operating system Windows XP, Vista, Linux 108
  • 109. Vision and Scope Document Hardware Client 3 laptops 2 desktops Server Reuse one 24/7 available desktop to simulate the server for testing and deployment Schedule The testing activities and milestones are dependent on the development iterations. The Construction Phase (in RUP-Rational Unified Process) will be split into 3 iterations. Each iteration contains a full test cycle of test planning, designing, development, execution, and evaluation. Refer to the Software Development Plan and the Iteration Plans for the master schedule and Construction Phase plan that shows the development iterations. The following table shows the Test Milestones, start date, and end date as planned. Milestone Task Start Date End Date Iteration C1: Review 3 9th November 7th December Test Planning Test Design Test Development Test Execution Test Evaluation Iteration C2: Review 4 7th December 28th December Test Planning Test Design Test Development Test Execution Test Evaluation 109
  • 110. Vision and Scope Document Acceptance criteria Satisfy all features will be tested as above lists. OURS Website can run smoothly. Provide a product with functions as requirements, help customer how to use the product easily. And satisfy the following conditions: Successful completion of all tasks as documented in the test schedule. Quantity of medium- and low-level defects must be at an acceptable level as determined by the software testing project team lead. User interfaces for all features are functionally complete. Installation documentation and scripts are complete and tested. Development code reviews are complete and all issues addressed. All high-priority issues have been resolved. All outstanding issues pertinent to this release are resolved and closed. All current code must be under source control, must build cleanly, the build process must be automated, and the software components must be labeled with correct version numbers in the version control system. All high-priority defects are corrected and fully tested prior to release. All defects that have not been fixed before release have been reviewed by project stakeholders to confirm that they are acceptable. The end user experience is at an agreed acceptable level. Operational procedures have been written for installation, set up, error recovery, and escalation. There must be no adverse effects on already deployed systems. Resources This section presents the recommended resources for testing the Online University Registration System, their main responsibilities, and their knowledge or skill set. Roles and responsibilities This table shows the staffing assumptions for the test activities. Worker Specific Responsibilities/Comments 110
  • 111. Vision and Scope Document Test Manager Provides management oversight Responsibilities: Provide technical direction Acquire appropriate resources Management reporting Test Designer Identifies, prioritizes, and implements test cases Responsibilities: Generate test plan Generate Test Suite Evaluate effectiveness of test effort System Tester Executes the tests, Responsibilities: Execute tests Log results Recover from errors Document defects Test System Ensures test environment and assets are managed Administrator and maintained. Responsibilities: Administer test management system Install / manage worker access to test systems Database Ensures test data (database) environment and Administration assets are managed and maintained. Database Manager Responsibilities: 111
  • 112. Vision and Scope Document Administer test data (database) Designer Identifies and defines the operations, attributes, and associations of the test classes Responsibilities: Identifies and defines the test class(es) Identifies and defines the test packages Implementer Implements and unit tests the test classes and test packages Responsibilities: Creates the test classes and packages implemented in the Test Suite. The following table sets forth the system resources for the testing the Online University Registration System. System Resources Resource Description OURS Server Server for simulating the environment of real OURS system Course Catalog Database Simulated database 2 Remote PCs (with internet PCs for connecting to OURS via access) internet 112
  • 113. Vision and Scope Document 2 Local PCs (connected via LAN) Local network computers Test Development PC's - 2 Load Simulator Simulator for load and performance test B- Test Case In this part, we only provide test cases for all use cases defined in original requirement. We will complete all test cases and use case specification of 2 new use cases have been added later in the final review. Unit testing Again, we use JUnit and EJB3Unit for unit testing. To be noticed that EJB3Unit is really different from JUnit or NUnit. In JUnit and NUnit, we have to give the input and the output so that these tools can know how to check the result and notify us whether the unit is passed or not. However, with EJB3Unit, if we test the entities, we are not required to provide the input and the output because the EJB3Unit (an extension of JUnit) automatic provide a random data to check the result our entities. And all the cases we need to check are as below checklist: Verify the input data length specified in the database or in EJB. The EJB3Unit will can collect information about the database basing on the entities and check the length. For example, the student name’s length is specified is 50, then the EJB3Unit will generate data with length is 50, greater than 50, and less than 50 to check all cases that can happen. And the case that is passed is the case with length 50. Other cases are failed. That is the reason while we do not need to write too much test case in this part. However, if the team is required, we will do it in the review 4. Other kinds of checks will be showed below: Verify the input data format specified in each form, classes, and interaction with database String format: only accept string, not number format, or mixed (string and number) format… Integer number format: only accept integer number format, not string format, or mixed format… 113
  • 114. Vision and Scope Document Email address format: only valid email address is accepted, other string patterns are not accepted Date format: only date format is accepted, others are not accepted Special character: not use special character. Special character Empty field: empty field is not accepted. Null: not allowed using null Test write: test writing operation to database check whether we can write data to database or not Test write null field: not allow write null data to our system database Test write read: test reading and writing data with relationships and constraints Test getter setter: test whether get and set methods of each entity For further information about EJB3Unit and how it work, please contact with our team. This is due to the fact that it is a brand new tool introduced after EJB3.0 is defined. And it change the way J2EE developers do the unit test. 114
  • 115. Vision and Scope Document Test Cases of Log in and Log out Use Case User logs in successfully with valid username and password Name Test case: User logs in successfully with valid username and password Requirement The user is logged in correctly after providing correct username and password Preconditions The user is at the homepage or the log in page Steps 1. Provide valid username in the username textbox 2. Provide valid password in the password textbox 3. Click on log in button Expected results The user is redirected to the specific homepage of that user Fail to login the system when providing invalid username Name Test case: Fail to login the system when providing invalid username Requirement The user is not logged in when providing invalid username Preconditions The user is at the homepage or the log in page Steps 1. Provide invalid username in the username textbox 2. Provide password in the password textbox or let password field be empty 3. Click on log in button Expected results The user is redirected to the error page with a warning “You have provided invalid username or invalid password” Fail to login the system when providing username or password containing special character(s) Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. Name Test case: Fail to login the system when providing username or password containing 115
  • 116. Vision and Scope Document special character(s) Requirement The user is not logged in when providing username or password containing special character(s). Preconditions The user is at the homepage or the log in page Steps 1. Provide username containing special character(s) in the username textbox or/and 2. Provide password containing special character(s) in the password textbox or let password field be empty 3. Click on log in button Expected results The user is redirected to the error page with a warning “Username and Password cannot contain special character(s)” Fail to login the system when providing valid username and invalid password Name Test case: Fail to login the system when providing valid username and invalid password Requirement The user is not logged in when providing valid username and invalid password Preconditions The user is at the homepage or the log in page Steps 1. Provide valid username in the username textbox 2. Provide invalid password in the password textbox 3. Click on log in button Expected results The user is redirected to the error page with a warning “You have provided invalid username or invalid password” Fail to login the system when providing empty username Name Test case: Fail to login the system when providing empty username Requirement The user is not logged in when providing empty username Preconditions The user is at the homepage or the log in page 116
  • 117. Vision and Scope Document Steps 1. Provide empty username in the username textbox 2. Provide password in the password textbox or let password field be empty 3. Click on log in button Expected results The user is redirected to the error page with a warning “You must provide both username and password” Fail to login the system when providing valid username and empty password Name Test case: Fail to login the system when providing valid username and empty password Requirement The user is not logged in when providing valid username and empty password Preconditions The user is at the homepage or the log in page Steps 1. Provide valid username in the username textbox 2. Provide empty password in the password textbox 3. Click on log in button Expected results The user is redirected to the error page with a warning “You must provide both username and password” User account is locked after failing to log in 3 times Name Test case: User account is locked after failing to log in 3 times Requirement User account is locked after failing to log in 3 times with a specific username Preconditions The user is at the homepage or the log in page Steps 1. Provide valid username in the username textbox or/and 2. Provide invalid or empty password in the password textbox 3. Click on log in button 4. Repeat above process for 3 times Expected results The user is redirected to the error page with a warning “You have provided invalid username or invalid password” 117
  • 118. Vision and Scope Document After the 3rd time, the user account with given user name is locked out and a warning is issued “Account locked. Please wait for 30 minutes or contact the administrator” User logs in the system using an account is being used by another user Name Test case: User logs in the system using an account is being used by another user Requirement User CAN NOT log in the system using account is being used by another user Preconditions A given account is being used by user 1 Steps 1. User 2 provides username of user 1 exactly 2. User 2 provides password of user 1 exactly 3. Click on log in button Expected results User 2 is redirected to the error page with a warning “This account is being used by another user” User logs in the system using an account is being locked Name Test case: User logs in the system using an account is being locked Requirement User CAN NOT log in the system using account is being locked Preconditions A given account is being locked by logging in fail 3 times Steps 1. Provides username of given account being locked 2. Provide password of given account being locked 3. Click on log in button Expected results User is redirected to the error page with a warning “This account is being locked. Please wait for 30 minutes or contact the administrator” Change password successfully Name Test case: Change password successfully Requirement The user wants to update password 118
  • 119. Vision and Scope Document All old and new passwords must be provided Preconditions The user clicks on the “change password” The webpage that allows user to change password is displayed Steps 1. Enter old password 2. Enter new password 3. Enter confirmed password 4. Click on the Recovery password button Expected results The old password is changed into new password Fail to change password when old or new or confirmed password is empty Name Test case: Fail to change password Requirement Try to change password when old or new or confirmed password is not input Preconditions The user clicks on the “change password” The webpage that allows user to change password is displayed Steps 1. Let old password empty or/and 2. Let new password empty or/and 3. Let confirmed password empty or/and 4. Click on the Recovery password button Expected results Notify user about empty fields Fail to change password when old password is incorrect Name Test case: Fail to change password Requirement Try to change password when providing incorrect old password Preconditions The user clicks on the “change password” 119
  • 120. Vision and Scope Document The webpage that allows user to change password is displayed Steps 1. Enter wrong password 2. Enter new password empty 3. Enter confirmed password empty 4. Click on the Recovery password button Expected results Notify user that the current password is wrong Recover the password successfully Name Test case: Recover the password successfully Requirement The user lost or forget the password and wants to reset the password Input right answer Preconditions The user clicks on the “Forget password” The system warns the user about recovering the password Steps 1. Specify the answer for the security question in the text box 2. Click on the Recovery password button Expected results The system issues the message indicates the password has been reset to the default password “Abcd1234” and warns the user to change their password for the next log in The password is reset to the default password “Abcd1234” The system redirects the user to the log in page Fail to reset password when inputting wrong answer for the security question Name Test case: Fail to reset password when inputting wrong answer for the security question Requirement The user lost or forget the password and wants to reset password 120
  • 121. Vision and Scope Document Input wrong answer Preconditions The user clicks on the “Forget password” The system warns the user about recovering the password Steps 1. Specify the wrong answer of the security question in the text box 2. Click on the Recovery password button Expected results The system issues the message “The answer is not correct” The system redirects the user to the recover password page to choose another question or answer the selected again Fail to reset password when inputting answer containing special character(s) for the security question Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. Name Test case: Fail to reset password when inputting answer containing special characters for the security question Requirement The user lost or forget the password and wants to reset password The answer contains special characters Preconditions The user clicks on the “Forget password” The system warns the user about recovering the password Steps 1. Specify the answer containing special character(s) for the security question in the text box 2. Click on the Recovery password button Expected results The system issues the message “The answer cannot contain special character(s)” The system redirects the user to the recover password page to choose another question or answer the selected again 121
  • 122. Vision and Scope Document Fail to reset password when inputting empty answer for the security question Name Test case: Fail to reset password when inputting empty answer for the security question Requirement The user lost or forget the password and wants to reset password Let answer be empty Preconditions The user clicks on the “Forget password” The system warns the user about recovering the password Steps 1. Leave the answer text box blank 2. Click on the Recovery password button Expected results The system issues the message “The answer cannot be empty” The system redirects the user to the recover password page to choose another question or answer the selected again Test Cases of Manage Department Information Use case Add a department with valid information successfully Name Test case: Add a department with valid information successfully Requirement All fields are filled with valid data Preconditions The webpage that allows user to input information of a department is displayed Steps 1. Provide department’s name in the name textbox 2. Provide department’s location in the location textbox 3. Provide department’s dean in the dean textbox 4. Provide faculty information that the department has 5. Provide department description in the description text area 6. Click on add button 122
  • 123. Vision and Scope Document Expected results 1. The department is added to the system 2. The summary of department has been added to the system is displayed Fail to add a department with name that already exists in the system Name Test case: Fail to add a department with name that already exists in the system Requirement All fields are filled with data Preconditions The webpage that allows user to input information of a department is displayed Steps 1. Provide department’s name (which already exist in the system) in the name textbox 2. Provide department’s location in the location textbox 3. Provide department’s dean in the dean textbox 4. Provide faculty information that the department has 5. Provide department description in the description text area 6. Click on add button Expected results 1. The department is NOT added to the system 2. The user is redirected to the error page with a warning “ Fail to add the department to the system. The name of the department that you have provided already exists in the system” Fail to add a department when one or some or all fields are empty Name Test case: Fail to add a department when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to input information of a department is displayed Steps 1. Provide empty department’s name in the name textbox or/and 2. Provide empty department’s location in the location textbox or/and 3. Provide empty department’s dean in the dean textbox or/and 123
  • 124. Vision and Scope Document 4. Provide empty faculty information that the department has or/and 5. Provide department description in the description text area or/and 6. Click on add button Expected results 1. The department is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the department to the system. You must provide all information” Fail to add a department when inputting special character(s) to one or some or all fields Special Characters: special characters are characters which are not the alphabet (A – Z, a-z)and numeric (0-9) space characters. Name Test case: Fail to add a department when inputting special character(s) to one or some or all fields Requirement All fields are filled with data Preconditions The webpage that allows user to input information of a department is displayed Steps 1. Provide department’s name containing special character(s) in the name textbox or/and 2. Provide department’s location containing special character(s) in the location textbox or/and 3. Provide department’s dean containing special character(s) in the dean textbox or/and 4. Provide faculty information containing special character(s) or/and 5. Provide department description containing special character(s) in the description text area or/and 6. Click on add button Expected results 1. The department is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the department to the system. Some fields contains special character(s)” 124
  • 125. Vision and Scope Document Update a department with valid information successfully Name Test case: Update a department with valid information successfully Requirement All fields are filled with valid data Preconditions The webpage that allows user to update information of a department is displayed Steps 1. Provide department’s name in the name textbox or/and 2. Provide department’s location in the location textbox or/and 3. Provide department’s dean in the dean textbox or/and 4. Provide faculty information that the department has or/and 5. Provide department description in the description text area or/and 6. Click on add button Expected results 1. The department is updated in the system 2. The summary of department has been updated is displayed Fail to update a department with name that already exists in the system Name Test case: Fail to update a department with name that already exists in the system Requirement All fields are filled with data Preconditions The webpage that allows user to update information of a department is displayed Steps 1. Provide department’s name (which already exist in the system) in the name textbox or/and 2. Provide department’s location in the location textbox or/and 3. Provide department’s dean in the dean textbox or/and 4. Provide faculty information that the department has or/and 5. Provide department description in the description text area or/and 6. Click on add button 125
  • 126. Vision and Scope Document Expected results 1. The department is NOT updated in the system 2. The user is redirected to the error page with a warning “ Fail to update the department in the system. The name of the department that you have provided already exists in the system” Fail to update a department when one or some or all fields are empty Name Test case: Fail to update a department when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to update information of a department is displayed Steps 1. Provide empty department’s name in the name textbox or/and 2. Provide empty department’s location in the location textbox or/and 3. Provide empty department’s dean in the dean textbox or/and 4. Provide empty faculty information that the department has or/and 5. Provide department description in the description text area or/and 6. Click on add button Expected results 1. The department is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the department in the system. You must provide all information” 126
  • 127. Vision and Scope Document Fail to update a department when inputting special character(s) to one or some or all fields Special Characters: special characters are characters which are not the alphabet (A – Z, a-z)and numeric (0-9) and space characters. Name Test case: Fail to update a department when inputting special character(s) to one or some or all fields Requirement All fields are filled with data Preconditions The webpage that allows user to update information of a department is displayed Steps 1. Provide department’s name containing special character(s) in the name textbox or/and 2. Provide department’s location containing special character(s) in the location textbox or/and 3. Provide department’s dean containing special character(s) in the dean textbox or/and 4. Provide faculty information containing special character(s) or/and 5. Provide department description containing special character(s) in the description text area or/and 6. Click on add button Expected results 1. The department is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the department in the system. Some fields contains special character(s)” Update cancel Name Test case: Update cancel Requirement When user decides to cancel updating, the system must allow him/her to stop the operation Preconditions The webpage that allows user to update information of a department is displayed 127
  • 128. Vision and Scope Document Steps Click on add button Expected results The department is NOT updated in the system User is redirected to his/her main page Delete a department Name Test case: Delete a department Requirement When user decides to delete the selected department, the system removes that department from the system Preconditions The webpage that allows user to delete information of a department is displayed Steps 1. User chooses a department to delete from a drop down list. 2. Verify that the system retrieves and displays the department information for user and prompts message MS004 to the Academic Affair Staff to confirm the deletion of the Department. 3. User confirms to delete the selected department by clicking on delete button. Expected results The system deletes the selected department from the system Delete cancel Name Test case: Delete cancel Requirement When user decides to cancel deletion, the system allows user to cancel the operation Preconditions The webpage that allows user to delete information of a department is displayed Steps 1. User chooses a department to delete from a drop down list. 2. Verify that the system retrieves and displays the department information for user and prompts message MS004 to the Academic Affair Staff to confirm the deletion of the Department. 3. User click on cancel button. 128
  • 129. Vision and Scope Document Expected results The selected department is NOT deleted from the system User is redirected to his/her main page Test Cases of Manage Lecturer Information use case Add a lecturer with valid information successfully Name Test case: Add a lecturer with valid information successfully Requirement All fields are filled with valid data Preconditions The webpage that allows user to input information of a lecturer is displayed Steps 1. Provide lecturer’s name in the name textbox 2. Choose lecturer’s date of birth in the calendar 3. Provide lecturer’s cell-phone number in the cell-phone textbox 4. Provide lecturer’s email address in the email textbox 5. Provide lecturer’s department where that lecturer belongs in the department textbox 6. Provide lecturer’s degree in the degree textbox 7. Click on add button Expected results 1. The lecturer is added to the system 2. The summary of lecturer’s information has been added to the system is displayed Fail to add a department when one or some or all fields are empty Name Test case: Fail to add a department when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to input information of a department is displayed Steps 1. Provide empty lecturer’s name in the name textbox or/and 129
  • 130. Vision and Scope Document 2. Choose empty lecturer’s date of birth in the calendar or/and 3. Provide empty lecturer’s cell-phone number in the cell-phone textbox or/and 4. Provide empty lecturer’s email address in the email textbox or/and 5. Provide empty lecturer’s department where that lecturer belongs in the department textbox or/and 6. Provide empty lecturer’s degree in the degree textbox or/and 7. Click on add button Expected results 1. The lecturer is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the lecturer to the system. You must provide all information” Fail to add a lecturer when inputting special character(s) to one or some or all fields Special Characters: special characters are characters which are not the alphabet (A – Z, a-z)and numeric (0-9) and space characters. Name Test case: Fail to add a lecturer when inputting special character(s) to one or some or all fields Requirement All fields are filled with data Preconditions The webpage that allows user to input information of a lecturer is displayed Steps 1. Provide lecturer’s name containing special character(s) the name textbox or/and 2. Choose lecturer’s date of birth in the calendar or/and 3. Provide lecturer’s cell-phone number containing special character(s) in the cell-phone textbox or/and 4. Provide lecturer’s email address containing special character(s) in the email textbox or/and 5. Provide lecturer’s department where that lecturer belongs, containing special character(s), in the department textbox or/and 130
  • 131. Vision and Scope Document 6. Provide lecturer’s degree containing special character(s) in the degree textbox or/and 7. Click on add button Expected results 1. The lecturer is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the lecturer to the system. Some fields contains special character(s)” Look for a lecturer Name Test case: Look for a lecturer Requirement When user wants to update or delete a lecturer, he/she has to look for information of the lecturer he/she wants to delete or modify information. Preconditions The webpage that allows user to look for information of a lecturer is displayed. It can be update or delete page. Steps 1. User chooses the department where the lecturer belongs 2. Verify that the system retrieves and displays the list of lecturers of that department 3. User choose a lecturer from the list 4. Verify that the summary of information of selected lecturer is displayed Expected results 1. Information of the select lecturer is displayed Update a lecturer with valid information successfully Name Test case: Update a lecturer with valid information successfully Requirement All fields are filled with valid data Preconditions The webpage that allows user to update information of a lecturer is displayed. (To be noted that we have test case for looking for lecturer above already. There’s no need to repeat it here.) Steps 1. Provide lecturer’s name in the name textbox or/and 2. Choose lecturer’s date of birth in the calendar or/and 3. Provide lecturer’s cell-phone number in the cell-phone textbox or/and 131
  • 132. Vision and Scope Document 4. Provide lecturer’s email address in the email textbox or/and 5. Provide lecturer’s department where that lecturer belongs in the department textbox or/and 6. Provide lecturer’s degree in the degree textbox or/and 7. Click on add button Expected results 1. The lecturer is updated in the system 2. The summary of the lecturer has been updated is displayed 132
  • 133. Vision and Scope Document Fail to update a lecturer when one or some or all fields are empty Name Test case: : Fail to update a lecturer when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to update information of a lecturer is displayed.(To be noted that we have test case for looking for lecturer above already. There’s no need to repeat it here.) Steps 1. Provide empty lecturer’s name in the name textbox or/and 2. Choose empty lecturer’s date of birth in the calendar or/and 3. Provide empty lecturer’s cell-phone number in the cell-phone textbox or/and 4. Provide empty lecturer’s email address in the email textbox or/and 5. Provide empty lecturer’s department where that lecturer belongs in the department textbox or/and 6. Provide empty lecturer’s degree in the degree textbox or/and 7. Click on add button Expected results 1. The lecturer is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the lecturer in the system. You must provide all information” Fail to update a lecturer information when inputting special character(s) to one or some or all fields Special Characters: special characters are characters which are not the alphabet (A – Z, a-z)and numeric (0-9) space characters. Name Test case: Fail to update a lecturer information when inputting special character(s) to one or some or all fields Requirement All fields are filled with data Preconditions The webpage that allows user to update information of a lecturer is displayed. (To be noted that we have test case for looking for lecturer above already. There’s no need 133
  • 134. Vision and Scope Document to repeat it here.) Steps 1. Provide empty lecturer’s name containing special character(s) in the name textbox or/and 2. Choose empty lecturer’s date of birth in the calendar or/and 3. Provide empty lecturer’s cell-phone number containing special character(s) in the cell-phone textbox or/and 4. Provide empty lecturer’s email address containing special character(s) in the email textbox or/and 5. Provide empty lecturer’s department where that lecturer belongs, containing special character(s) in the department textbox or/and 6. Provide empty lecturer’s degree containing special character(s) in the degree textbox 7. Click on add button Expected results 1. The lecturer is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the lecturer in the system. Some fields contains special character(s)” Update cancel Name Test case: Update cancel Requirement When user decides to cancel updating, the system must allow him/her to stop the operation Preconditions The webpage that allows user to update information of a lecturer is displayed. (To be noted that we have test case for looking for lecturer above already. There’s no need to repeat it here.) Steps Click on cancel button Expected results The lecturer is NOT updated in the system User is redirected to his/her main page 134
  • 135. Vision and Scope Document Delete a lecturer Name Test case: Delete a lecturer Requirement When user decides to delete the selected lecturer, the system removes that lecturer from the system Preconditions The webpage that allows user to delete information of a lecturer is displayed. (To be noted that we have test case for looking for lecturer above already. There’s no need to repeat it here.) Steps Click on delete button Expected results The system deletes the selected lecturer from the system User is redirected to his/her main page Delete cancel Name Test case: Delete cancel Requirement When user decides to cancel deletion, the system allows user to cancel the operation Preconditions The webpage that allows user to delete information of a lecturer is displayed. (To be noted that we have test case for looking for lecturer above already. There’s no need to repeat it here.) Steps Click on cancel button Expected results The selected lecturer is NOT deleted from the system User is redirected to his/her main page 135
  • 136. Vision and Scope Document Test Cases of Manage Student Information Use Case Add a student with valid information successfully Name Test case: Add a student with valid information successfully Requirement All fields are filled with valid data Preconditions The webpage that allows user to input information of a student is displayed Steps 1. Provide student’s name in the name textbox 2. Provide student’s ID in the ID textbox 3. Choose student’s faculty in the list of faculty 4. Choose student’s academic duration in the range list 5. Choose student’s academic year in the list 6. Choose semester of this academic year. 7. Choose course of this semester. 8. Click on add button Expected results 1. The student is added to the system 2. The summary of student’s information has been added to the system is displayed Fail to add a student when one or some or all fields are empty Name Test case: Fail to add a student when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to input information of a student is displayed Steps 1. Provide empty student’s name in the name textbox or/and 2. Provide empty student’s ID in the ID textbox or/and 3. Choose empty student’s faculty in the list of faculty or/and 136
  • 137. Vision and Scope Document 4. Choose empty student’s academic duration in the range list or/and 5. Choose empty student’s academic year in the list or/and 6. Choose empty semester of this academic year or/and 7. Choose empty course of this semester or/and 8. Click on add button Expected results 1. The student is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the student to the system. You must provide all information” Fail to add a student when inputting special character(s) to one or some or all fields Special Characters: special characters are characters which are not the alphabet (A – Z, a-z)and numeric (0-9) space characters. Name Test case: Fail to add a student when inputting special character(s) to one or some or all fields Requirement All fields are filled with data Preconditions The webpage that allows user to input information of a lecturer is displayed Steps 1. Provide student’s name containing special character(s) the name textbox or/and 2. Provide student’s ID containing special character(s) in the ID textbox or/and 3. Choose student’s faculty in the list of faculty or/and 4. Choose student’s academic duration in the range list or/and 5. Choose student’s academic year in the list or/and 6. Choose semester of this academic year or/and 7. Choose course of this semester or/and 8. Click on add button 137
  • 138. Vision and Scope Document Expected results 1. The student is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the student to the system. Some fields contains special character(s)” Search student by student ID or/and by student name Name Test case: Search student by student ID or/and by student name Requirement User wants to find information of a specific student with student’s ID or list of students with given name. Preconditions The webpage allows user to find students is displayed Steps 1. Chooses ID and Name filter from the filter drop down list 2. Provide an ID in the ID textbox or/and 3. Provide a name in the name textbox 4. Click on search button Expected results The information of student with given ID or a list of student(s) with given name is displayed Fail to search student by student ID or/and by student name when providing invalid student ID or/and student name Name Test case: Fail to search student by student ID or/and by student name when providing invalid student ID or/and student name Requirement User wants to find information of student whose ID or/and name does not exist in the system, then the system must notify the user about this Preconditions The webpage allows user to find students is displayed Steps 1. Chooses ID and Name filter from the filter drop down list 2. Provide an invalid ID in the ID textbox or/and 3. Provide a invalid name in the name textbox 4. Click on search button 138
  • 139. Vision and Scope Document Expected results The user is redirected to the error page with a warning “The desired student is not found” Fail to search student by student ID or/and by student name when providing empty student ID or/and student name Name Test case: Fail to search student by student ID or/and by student name when providing empty student ID or/and student name Requirement User wants to find information of a specific student’s ID or list of students with given name. Preconditions The webpage allows user to find students is displayed Steps 1. Chooses ID and Name filter from the filter drop down list 2. Provide an empty ID in the ID textbox or/and 3. Provide an empty name in the name textbox 4. Click on search button Expected results The user is redirected to the error page with a warning “You must provide an ID or/and student name” Search student by faculty and academic duration Name Test case: Search student by faculty and academic duration Requirement User wants to view tuition fee information of students of a specific faculty with a specific academic duration Preconditions The webpage allows user to view tuition fee of students is displayed Steps 1. Chooses faculty and academic duration filter from the filter drop down list 2. Choose a faculty from the drop down list 139
  • 140. Vision and Scope Document 3. Choose an academic duration from drop down list 4. Click on search button Expected results The information of students of selected faculty with specific academic duration 140
  • 141. Vision and Scope Document Search student by academic year, semester, and course Name Test case: Search student by academic year, semester, and course Requirement User wants to find information of students in a specific academic year and/or semester and/or course Preconditions The webpage allows user to find students is displayed Steps 1. Chooses academic year, semester, and course filter from the filter drop down list 2. Choose a academic year from the academic year drop down list or/and 3. Choose a semester from the semester drop down list or/and 4. Choose a course from the course drop down list 5. Click on search button Expected results The information of students of selected academic year and/or semester and/or course is displayed Update a student with valid information successfully Name Test case: Update a student with valid information successfully Requirement All fields are filled with valid data Preconditions The webpage that allows user to update information of a student is displayed. (To be noted that we have test cases searching for student above already. There’s no need to repeat it here) Steps 1. Provide student’s name in the name textbox or/and 2. Provide student’s ID in the ID textbox or/and 3. Choose student’s faculty in the list of faculty or/and 4. Choose student’s academic duration in the range list or/and 5. Choose student’s academic year in the list or/and 6. Choose semester of this academic year or/and 7. Choose course of this semester or/and 141
  • 142. Vision and Scope Document 8. Click on update button Expected results 1. The student is updated in the system 2. The summary of the student has been updated is displayed Fail to update a student when one or some or all fields are empty Name Test case: Fail to update a student when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to update information of a student is displayed (To be noted that we have test cases searching for student above already. There’s no need to repeat it here) Steps 1. Provide empty student’s name in the name textbox or/and 2. Provide empty student’s ID in the ID textbox or/and 3. Choose student’s faculty in the list of faculty or/and 4. Choose student’s academic duration in the range list or/and 5. Choose student’s academic year in the list or/and 6. Choose semester of this academic year or/and 7. Choose course of this semester or/and 8. Click on update button Expected results 1. The student is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the student in the system. You must provide all information” Fail to update a student when inputting special character(s) to one or some or all fields Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. 142
  • 143. Vision and Scope Document Name Test case: Fail to update a student information when inputting special character(s) to one or some or all fields Requirement All fields are filled with data Preconditions The webpage that allows user to update information of a student is displayed. (To be noted that we have test cases searching for student above already. There’s no need to repeat it here) Steps 1. Provide empty student’s name in the name textbox or/and 2. Provide empty student’s ID in the ID textbox or/and 3. Choose student’s faculty in the list of faculty or/and 4. Choose student’s academic duration in the range list or/and 5. Choose student’s academic year in the list or/and 6. Choose semester of this academic year or/and 7. Choose course of this semester or/and 8. Click on update button Expected results 1. The student is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the student in the system. Some fields contains special character(s)” Update is canceled Name Test case: Update is canceled Requirement When user decides to cancel updating, the system must allow him/her to stop the operation Preconditions The webpage that allows user to update information of a student is displayed. (To be noted that we have test cases searching for student above already. There’s no need to repeat it here.) Steps Click on cancel button Expected results The student is NOT updated in the system 143
  • 144. Vision and Scope Document User is redirected to his/her main pages Delete a student Name Test case: Delete a student Requirement When user decides to delete the selected student, the system removes that student from the system Preconditions The webpage that allows user to delete information of a student is displayed. (To be noted that we have test cases searching for student above already. There’s no need to repeat it here.) Steps Click on delete button Expected results The system deletes the selected student from the system User is redirected to his/her main page Delete is canceled Name Test case: Delete is canceled Requirement When user decides to cancel deletion, the system allows user to cancel the operation Preconditions The webpage that allows user to delete information of a student is displayed. (To be noted that we have test cases searching for student above already. There’s no need to repeat it here) Steps Click on cancel button Expected results The selected student is NOT deleted from the system User is redirected to his/her main page 144
  • 145. Vision and Scope Document Test Cases of Manage Course Offering Use Case Create list of courses offering successfully Name Test case: Create list of courses offering successfully Requirement List of courses offering does not exist yet Academic affair staff wants to create new list course offering Preconditions The user must log in as the Academic Affair Staff The webpage that allows user to create list of courses offering is displayed Steps 1. Click on the button Manage Course Offering 2. Click on the button Create a list of course offering 3. Click on the drop down list to choose the desired faculty 4. Click on the check box to choose the subject which is selected to offer 5. Click on the drop down list to choose the lecturers for the selected courses 6. Click on the Submit button to create the list of course offering for the selected faculty 7. Click on the OK button to confirm the operation Expected results The new list of courses offering is created The system displayed the list of course offering that has been created The system redirects to the Manage Course Offering page Update the list of course offering Name Test case: Update the list of course offering Requirement The list of courses offering exists in the system Academic affair staff wants to update list of courses offering Preconditions The user must log in as the Academic Affair Staff 145
  • 146. Vision and Scope Document The webpage that allows user to create list of courses offering is displayed Steps 1. Click on the button Manage Course Offering 2. Click on the button Update list of course offering 3. Click on the drop down list to choose the desired faculty 4. Check or uncheck the check box of each course to change the list of course offering 5. Change the lecturer for each course (if desired) 6. Click on the Update button 7. Click on the OK button to confirm the operation Expected results The confirmation displayed The list of course offering is updated with the changes of the user The updated list of course offering is displayed after the operation completed Cancel during the Create list of course offering operation Name Test case: Cancel during the Create list of course offering operation Requirement Academic affair staff is being in the creating list of courses offering process. Preconditions The user must log in as the Academic Affair Staff User is being in the creating list of courses offering process Steps 1. Click on the button Manage Course Offering 2. Click on the button Create a list of course offering 3. Click on the drop down list to choose the desired faculty 4. Click on the check box to choose the subject which is selected to offer 5. Click on the drop down list to choose the lecturers for the selected courses 6. Click on the Submit button to create the list of course offering for the selected faculty 146
  • 147. Vision and Scope Document 7. Click on the Cancel button Expected results No list of course offering is created The system redirects to the Manage Course Offering page Cancel during the Update list of course offering operation Name Test case: Cancel during the Update list of course offering operation Requirement Academic affair wants to cancel the updating list of courses offering process Preconditions The user must log in as the Academic Affair Staff User is being in the creating list of courses offering process Steps 1. Click on the button Manage Course Offering 2. Click on the button Update list of course offering 3. Click on the drop down list to choose the desired faculty 4. Check or uncheck the check box of each course to change the list of course offering 5. Change the lecturer for each course (if desired) 6. Click on the Update button 7. Click on the Cancel button to confirm the operation Expected results List of courses offering is not updated The system redirects to the Manage Course Offering page Fail to create an empty list of course offering Name Test case: Fail to create an empty list of course offering 147
  • 148. Vision and Scope Document Requirement Academic affair tries to create an empty list of courses offering or creates an empty list of courses offering by accident Preconditions The user must log in as the Academic Affair Staff The webpage that allows user to create list of courses offering is displayed Steps 1. Click on the button Manage Course Offering 2. Click on the button Create a list of course offering 3. Click on the drop down list to choose the desired faculty 4. Don’t click any check box in order not to select any course 5. Click on the drop down list to choose the lecturers for the selected courses 6. Click on the Submit button to create the list of course offering for the selected faculty 7. Click on the OK button to confirm the operation Expected results No empty list is created The system issued warning about the empty list of course offering The system redirects to the Create list of course offering and let the user to create the non – empty list Update list of course offering while there’s no list of course offering for specific faculty Name Test case: Update list of course offering while there’s no list of course offering for specific faculty Requirement Academic affair staff tries to update list of courses offering while has not been created. Then the system must notify him/her about the unavailable status of list of courses offering. Preconditions 1. The user must log in as the Academic Affair Staff 2. The selected faculty has no list of course offering Steps 1. Click on the button Manage Course Offering 148
  • 149. Vision and Scope Document 2. Click on the button Update list of course offering 3. Click on the drop down list to choose the desired faculty Expected results A warning is displayed “There’s no list of course offering in this faculty. Cannot update” 149
  • 150. Vision and Scope Document Test Cases of Manage Financial Activities Use Case View tuition fee by student ID or/and by student name Name Test case: View tuition fee by student ID or/and by student name Requirement User wants to view tuition fee information of a specific student or list of students with given name. Preconditions The webpage allows user to view tuition fee of students is displayed Steps 1. Chooses ID and Name filter from the filter drop down list 2. Provide an ID in the ID textbox or/and 3. Provide a name in the name textbox 4. Click on search button Expected results The tuition fee information of student with given ID or student(s) with given name is displayed Fail to view tuition fee by student ID or/and by student name when providing invalid student ID or/and student name Name Test case: Fail to view tuition fee by student ID or/and by student name when providing invalid student ID or/and student name Requirement User wants to view tuition fee information of student whose ID or/and name does not exist in the system, then the system must notify the user about this Preconditions The webpage allows user to view tuition fee of students is displayed Steps 1. Chooses ID and Name filter from the filter drop down list 2. Provide an invalid ID in the ID textbox or/and 3. Provide a invalid name in the name textbox 4. Click on search button Expected results The user is redirected to the error page with a warning “The desired student is not 150
  • 151. Vision and Scope Document found” Fail to view tuition fee by student ID or/and by student name when providing empty student ID or/and student name Name Test case: Fail to view tuition fee by student ID or/and by student name when providing empty student ID or/and student name Requirement User wants to view tuition fee information of a specific student or list of students with given name. Preconditions The webpage allows user to view tuition fee of students is displayed Steps 1. Chooses ID and Name filter from the filter drop down list 2. Provide an empty ID in the ID textbox or/and 3. Provide a empty name in the name textbox 4. Click on search button Expected results The user is redirected to the error page with a warning “You must provide an ID or/and student name” View tuition fee by faculty or/and by academic duration Name Test case: View tuition fee by faculty or/and by academic duration Requirement User wants to view tuition fee information of students of a specific faculty with a specific academic duration Preconditions The webpage allows user to view tuition fee of students is displayed Steps 1. Chooses faculty and academic duration filter from the filter drop down list 2. Choose a faculty from the drop down list 3. Choose a academic duration from drop down list 4. Click on search button Expected results The tuition fee information of students of selected faculty with specific academic 151
  • 152. Vision and Scope Document duration View tuition fee by academic year, semester, and course Name Test case: View tuition fee by academic year, semester, and course Requirement User wants to view tuition fee information of students in a specific academic year and/or semester and/or course Preconditions The webpage allows user to view tuition fee of students is displayed Steps 1. Chooses academic year, semester, and course filter from the filter drop down list 2. Choose a academic year from the academic year drop down list or/and 3. Choose a semester from the semester drop down list or/and 4. Choose a course from the course drop down list 5. Click on search button Expected results The tuition fee information of students of selected academic year and/or semester and/or course is displayed Update tuition fee status of a student Name Test case: Update tuition fee status of a student Requirement User wants to update the tuition fee status of students after he/she pays the tuition fee. User wants to update tuition fee status of student that user has update wrongly. Preconditions The webpage allows user to update the tuition fee status of student is displayed.(Because we have the test cases for filtering student to find the student(s) above, we do not need to repeat steps of filtering here). And list of students with tuition fee status is displayed. Steps 1. Choose a student from the list 2. Change status of tuition fee of that student by choose tuition fee status from 152
  • 153. Vision and Scope Document the stats drop down list 3. Click on submit button Expected results Tuition fee status of selected student is changed and the system notify the user. Test Cases of View Academic History Use Case View academic history successfully Name Test case: Verify View Academic History Requirement FR- 8 Grade management policy, UC - View Academic History Preconditions The testing plan document is loaded. Steps 1. Assume that we are in View Academic History function of the system. 2. Choose a filter group: View All, View by specific year and semester, View by passed and failed status. 3. One filter is chosen. 4. Click View button. Expected results The system displays a list of courses that match the filter.  Academic history of a student is display. Verify that all these information match with FR-8 information. View all course have taken history. Name Test case: View all courses have taken history 153
  • 154. Vision and Scope Document Requirement Student wants to view all courses information. Preconditions The webpage allows student to view academic history Steps 1. Choose “All” filter from drop down list. 2. Click on “View” button Expected results The information of all courses he/she has taken is displayed. View by specific year and semester. Name Test case: View by specific year and semester Requirement Student wants to view all courses information of specific year or/and semester. Preconditions The webpage allows student to view academic history. Steps 1. Choose “Specific year and Semester” filter from drop down list. 2. Click on “View” button Expected results The information of all courses he/she has taken is displayed. View by passed and failed status. Name Test case: View by specific year and semester Requirement Student wants to view all courses information of passed and failed status. Preconditions The webpage allows student to view academic history Steps 1. Choose “passed and failed status” filter from drop down list. 2. Click on “View” button Expected results The information of all courses he/she has taken is displayed. 154
  • 155. Vision and Scope Document Test Cases of Register Course Use Case We will filter the prerequisites courses before showing the list of courses that a specific student can register. Therefore, that student can register any course in the list of courses offering that student can see. Fail to register more than 30 credits Name Test case: Fail to register more than 30 credits Requirement All the courses he/she wants to register has been checked Total number of credits is greater than 30 Preconditions The webpage allows user to register for courses is displayed Steps 1. Click register course offering button 2. Select courses from list of courses offering by checking the checkbox of the courses offering 3. Repeat step 2 until the total number of credits is greater than 30 4. Click on the Register button Expected results The system prompts the user with a warning message “You are not allowed to register more than 30 credits” Fail to register less than 15 credits Name Test case: Fail to register less than 15 credits Requirement All the courses he/she wants to register has been checked Total number of credits is less than 15 Preconditions The webpage allows user to register for courses is displayed Steps 1. Click register course offering button 2. Select courses from list of courses offering by checking the checkbox of the 155
  • 156. Vision and Scope Document courses offering 3. Repeat step 2 until but make sure that the total number of credits is less than 15 4. Click on the Register button Expected results The system prompts the user with a warning message “You are not allowed to register less than 15 credits” Register for courses successfully Name Test case: Register for courses successfully Requirement Student registers for courses to create his/her schedule (please see the definition of SCHEDULE in the glossary part) That student does not have schedule yet The total number of credits is less than or equal to 30 and greater than or equal to 15 Preconditions The webpage allows student to register for courses is displayed Steps 1. Click register course offering button. 2. Select courses offering from a list of available course offerings of this student that the system displays. 3. Repeat step 2 and make sure that the total of credits is less than or equal to 30 and greater than or equal to 15. 4. Click the submit button Expected results The schedule of that student is created in the system. List of course offering will be shown on the schedule of this student. 156
  • 157. Vision and Scope Document Update the existing schedule successfully Name Test case: update the existing schedule successfully Requirement Student has his/her schedule already (please see the definition of SCHEDULE in the glossary part) That student wants to modify his/her schedule The total number of credits is less than or equal to 30 and greater than or equal to 15 Preconditions The webpage allows student to register for courses is displayed Steps 1. Click the update schedule button. 2. Check some more courses that he/she wants to register and/or 3. Uncheck some courses that he/she does not want to register 4. Repeat step 2 or/and 3 if needed and make sure that The total number of credits is less than or equal to 30 and greater than or equal to 15 5. Click the update button Expected The schedule is updated in the system. results Updated list of course offering will be shown on the schedule of this student. Test Cases of Manage Course Catalogue Use Case Add new course to course catalogue successfully Name Test case: Add new course to course catalogue successfully Requirement All fields of course information are filled with valid information Preconditions The webpage that allows user to input information of a course is displayed 157
  • 158. Vision and Scope Document Steps 1. Provide course’s ID in the ID textbox 2. Provide course’s Name in the name textbox 3. Provide number of credits of the course in the credit textbox 4. Choose the faculty of the department where the course belongs from dropdown list 5. Provide the description of the course in the description text area. 6. Click on add button Expected 1. The course is added to the system results 2. The summary of course’s information has been added to the system is displayed Fail to add a course when one or some or all fields are empty Name Test case: Fail to add a course when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to input information of a course is displayed Steps 1. Provide empty course’s ID in the ID textbox or/and 2. Provide empty course’s Name in the name textbox or/and 3. Provide empty number of credits of the course in the credit textbox or/and 4. Choose the faculty of the department where the course belongs from dropdown list 5. Provide the empty description of the course in the description text area 6. Click on add button Expected 1. The course is NOT added to the system results 2. The user is redirected to the error page with a warning “Fail to add the course to course catalogue. You must provide all information” 158
  • 159. Vision and Scope Document Fail to add a course when inputting special character(s) Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. Name Test case: Fail to add a course when inputting special character(s) to one or some or all fields Requirement All fields are filled with data but ID or name containing special character(s) Preconditions The webpage that allows user to input information of a course is displayed Steps 1. Provide course’s ID containing special character(s)in the ID textbox or/and 2. Provide course’s Name containing special character(s) in the name textbox or/and 3. Provide number of credits of the course in the credit textbox or/and 4. Choose the faculty of the department where the course belongs from dropdown list 5. Provide the description of the course in the description text area 6. Click on add button Expected 3. The course is NOT added to the system results 4. The user is redirected to the error page with a warning “Fail to add the course to course catalogue. ID and Name cannot contain special character(s)” Search for course by ID or Name Name Test case: Search course by course ID or/and by course name Requirement User wants to find information of a specific course with course’s ID or name. Preconditions The webpage allows user to find courses is displayed Steps 1. Provide an ID in the ID textbox or/and 2. Provide a name in the name textbox 159
  • 160. Vision and Scope Document 3. Click on search button Expected results The information of course with given ID or/and name is displayed Fail to search for course by ID or Name when inputting invalid ID and/or Name Name Test case: Fail to search course by course ID or/and by course name when providing invalid course ID or/and course name Requirement User wants to find information of course whose ID or/and name does not exist in the system, then the system must notify the user about this Preconditions The webpage allows user to find courses is displayed Steps 1. Provide an invalid ID in the ID textbox or/and 2. Provide an invalid name in the name textbox 3. Click on search button Expected results The user is redirected to the error page with a warning “The desired course is not found” Fail to search for course by ID or Name when inputting empty ID and/or empty Name Name Test case: Fail to search course by course ID or/and by course name when providing empty course ID or/and course name Requirement User wants to find information of a specific course’s ID or list of courses with given name. Preconditions The webpage allows user to find courses is displayed Steps 1. Provide an empty ID in the ID textbox or/and 2. Provide an empty name in the name textbox 3. Click on search button 160
  • 161. Vision and Scope Document Expected results The user is redirected to the error page with a warning “You must provide an ID or/and course name” Update course with valid information successfully Name Test case: Update a course with valid information successfully Requirement All fields of course information are filled with valid information Preconditions The webpage that allows user to update information of a course is displayed Steps 1. Provide course’s ID in the ID textbox or/and 2. Provide course’s Name in the name textbox or/and 3. Provide number of credits of the course in the credit textbox or/and 4. Choose the faculty of the department where the course belongs from dropdown list or/and 5. Provide the description of the course in the description text area. 6. Click on add button Expected 1. The course is updated results 2. The summary of course information has been updated is displayed Fail to update a course when one or some or all fields are empty Name Test case: Fail to add a course when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to input information of a course is displayed Steps 1. Provide empty course’s ID in the ID textbox or/and 2. Provide empty course’s Name in the name textbox or/and 3. Provide empty number of credits of the course in the credit textbox or/and 4. Choose the faculty of the department where the course belongs from dropdown list 161
  • 162. Vision and Scope Document 5. Provide the empty description of the course in the description text area 6. Click on add button Expected 1. The course is NOT updated results 2. The user is redirected to the error page with a warning “Fail to update the course to course catalogue. You must provide all information” Fail to update a course when inputting special character(s) Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. Name Test case: Fail to update a course when inputting special character(s) to one or some or all fields Requirement All fields are filled with data but ID or name containing special character(s) Preconditions The webpage that allows user to input information of a course is displayed Steps 1. Provide course’s ID containing special character(s)in the ID textbox or/and 2. Provide course’s Name containing special character(s) in the name textbox or/and 3. Provide number of credits of the course in the credit textbox or/and 4. Choose the faculty of the department where the course belongs from dropdown list 5. Provide the description of the course in the description text area 6. Click on add button Expected 1. The course is NOT updated results 2. The user is redirected to the error page with a warning “Fail to update the course to course catalogue. ID and Name cannot contain special character(s)” 162
  • 163. Vision and Scope Document Update operation is canceled Name Test case: Update operation is canceled Requirement When user decides to cancel updating, the system must allow him/her to stop the operation Preconditions The webpage that allows user to update information of a course is displayed. (To be noted that we have test cases searching for course above already. There’s no need to repeat it here.) Steps Click on cancel button Expected results The course is NOT updated in the system User is redirected to his/her main pages Delete a course Name Test case: Delete a course Requirement When user decides to delete the selected course, the system removes that course from the system Preconditions The webpage that allows user to delete information of a course is displayed. (To be noted that we have test cases searching for course above already. There’s no need to repeat it here.) Steps Click on delete button Expected results The system deletes the selected course from the system User is redirected to his/her main page Delete operation is canceled Name Test case: Delete operation is canceled Requirement When user decides to cancel deletion, the system allows user to cancel the operation 163
  • 164. Vision and Scope Document Preconditions The webpage that allows user to delete information of a course is displayed. (To be noted that we have test cases searching for course above already. There’s no need to repeat it here) Steps Click on cancel button Expected results The selected course is NOT deleted from the system User is redirected to his/her main page Test Cases of Manage User Account Use Case Create a new user account successfully Name Test case: Create new user account successfully Requirement All fields of account information are filled with valid information Preconditions The webpage that allows user to input information of an account is displayed Steps 1. Provide username in the username textbox 2. Choose a role from the drop down list 3. Provide the description of the account in the description text area. 4. Other information will be used with default values specified in the use-case specification of Manage user account use case 5. Click on create button Expected 1. The account is added to the system results 2. The summary of account’s information has been added to the system is displayed Fail to create a new user account when the username that user has provided existing in the system already Name Test case: Create a new user account with the username existing in the system already Requirement All fields of account information are filled with information 164
  • 165. Vision and Scope Document Preconditions The webpage that allows user to input information of an account is displayed Steps 1. Provide username in the username textbox. But this username has been being used by another account. 2. Choose a role from the drop down list 3. Provide the description of the account in the description text area. 4. Other information will be used with default values specified in the use-case specification of Manage user account use case 5. Click on create button Expected 1. The account is NOT added to the system results 2. The user is redirected to the error page with the warning “This username has been being used by another user” Fail to create a new user account when inputting empty username Name Test case: Create a new user account when inputting empty username Requirement Not fields of account information are filled with information Preconditions The webpage that allows user to input information of an account is displayed Steps 1. Provide empty username in the username textbox 2. Choose a role from the drop down list 3. Provide the description of the account in the description text area. 4. Other information will be used with default values specified in the use-case specification of Manage user account use case 5. Click on create button Expected 1. The account is NOT added to the system results 2. The user is redirected to the error page with the warning “You must provide all information” 165
  • 166. Vision and Scope Document Fail to create a new user account when the inputs containing special character(s) Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. Name Test case: Create a new user account when inputting empty username Requirement All fields of account information are filled with information Preconditions The webpage that allows user to input information of an account is displayed Steps 6. Provide username containing special character(s) in the username textbox 7. Choose a role from the drop down list 8. Provide the description of the account containing special character(s) in the description text area. 9. Other information will be used with default values specified in the use-case specification of Manage user account use case 10. Click on create button Expected 1. The account is NOT added to the system results 2. The user is redirected to the error page with a warning “Fail to update the course to course catalogue. The input(s) cannot contain special character(s)” Search for account by username Name Test case: Search for account by username Requirement User wants to find information of a specific account by username. Preconditions The webpage allows user to find accounts is displayed Steps 1. Provide username in the username textbox 2. Click on search button Expected results The information of account with given username is displayed 166
  • 167. Vision and Scope Document Fail to search for account by empty username Name Test case: Search for account by empty username Requirement User wants to find information of a specific account by username. Preconditions The webpage allows user to find accounts is displayed Steps 1. Provide empty username in the username textbox 2. Click on search button Expected results The user is redirected to the error page with a warning “Username cannot be empty.” Fail to search for account by username that does not exist in the system Name Test case: Search for account by username that does not exist in the sysem Requirement User wants to find information of a specific account by username. Preconditions The webpage allows user to find accounts is displayed Steps 1. Provide username in the username textbox. That username does not exist in the system. 2. Click on search button Expected results The user is redirected to the error page with a warning “The account with the given username does not exist in the system.” Fail to search for account by username containing special characters(s) Name Test case: Search for account by username containing special character(s) 167
  • 168. Vision and Scope Document Requirement User wants to find information of a specific account by username. Preconditions The webpage allows user to find accounts is displayed Steps 1. Provide username containing special character(s) in the username textbox 2. Click on search button Expected results The user is redirected to the error page with a warning “Username cannot contain special character(s).” Update an account Name Test case: Update an account Requirement All fields of account information are filled with valid information Preconditions The webpage that allows user to update information of an account is displayed Steps 1. Provide new username in the username textbox and/or 2. Choose a role from the drop down list and/or 3. Provide the description of the account in the description text area and/or 4. Choose the status of the account from the drop down list and/or 5. Click on update button Expected 1. The account is updated to the system results 2. The summary of account’s information has been updated to the system is displayed Update operation is canceled Name Test case: Update operation is canceled Requirement When user decides to cancel updating, the system must allow him/her to stop the 168
  • 169. Vision and Scope Document operation Preconditions The webpage that allows user to update information of a account is displayed. (To be noted that we have test cases searching for account above already. There’s no need to repeat it here.) Steps Click on cancel button Expected results The account is NOT updated in the system User is redirected to his/her main pages Delete an account Name Test case: Delete an account Requirement When user decides to delete the selected account, the system removes that account from the system Preconditions The webpage that allows user to delete information of a account is displayed. (To be noted that we have test cases searching for account above already. There’s no need to repeat it here.) Steps Click on delete button Expected results The system deletes the selected account from the system User is redirected to his/her main page Delete operation is canceled Name Test case: Delete operation is canceled Requirement When user decides to cancel deletion, the system allows user to cancel the operation Preconditions The webpage that allows user to delete information of a account is displayed. (To be noted that we have test cases searching for account above already. There’s no need to repeat it here) Steps Click on cancel button 169
  • 170. Vision and Scope Document Expected results The selected account is NOT deleted from the system User is redirected to his/her main page Test Cases of Non-functional requirement testing Switch from Vietnamese to English Name Test case: Switch from Vietnamese to English Requirement The system must have ability to allow user to view the system in English while he/she is viewing the system in Vietnamese Preconditions The system is displaying text in Vietnamese Steps 1. Click on Vietnamese button Expected 1. The system displayed text in English results Switch from English to Vietnamese Name Test case: Switch from English to Vietnamese Requirement The system must have ability to allow user to view the system in Vietnamese while he/she is viewing the system in English Preconditions The system is displaying text in English Steps 1. Click on Vietnamese button Expected 1. The system displayed text Vietnamese results Load testing with 15 requests at the same time Name Test case: Load testing with 15 requests at the same time Requirement The system must have ability to response many requests at the same time Test with 15 requests at the same time 170
  • 171. Vision and Scope Document Preconditions The resource to be requested is available Steps 1. 15 requests are submitted at the same time Expected 1. The time for system to response all the requests is less than 10 results seconds Load testing with 25 requests at the same time Name Test case: Load testing with 25 requests at the same time Requirement The system must have ability to response many requests at the same time Test with 25 requests at the same time Preconditions The resource to be requested is available Steps 1. 25 requests are submitted at the same time Expected 1. The time for system to response all the requests is less than 10 results seconds C- Appendix Message Type Context Error Messages Actions ID Wrong password or username cannot MS001 Info Authentication Failed OK be found. Account locked. Please wait for 30 MS002 Info Account locked OK minutes or contact the administrator. This account is being used by another MS003 Info Account being used OK user. MS004 Question Delete a department OK – Cancel Are you sure you want to delete the 171
  • 172. Vision and Scope Document selected department? Are you sure you want to update the MS005 Question Update a lecturer OK – Cancel current displayed lecturer? Are you sure you want to delete the MS006 Question Delete a lecturer OK – Cancel selected lecturer? Are you sure you want to update the MS007 Question Update a student OK – Cancel modified student? Are you sure you want to delete the MS008 Question Delete a student OK – Cancel selected student? MS009 Info Student not found The selected student does not exist OK 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 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 30 You cannot register more than 30 MS014 Info OK credits credits Register less than 15 You cannot register less than 15 MS015 Info OK credits credits Are you sure you want to submit this MS016 Question Submit a schedule OK – Cancel schedule? 172
  • 173. Vision and Scope Document Reset changes to a Are you sure you undo all the MS017 Question OK – Cancel schedule changes you have made? D- Inspection Checklist The following checklist items apply to the test plan. Completeness Does the document meet all established templates and standards? Is the document complete? Are there any requirements that are not tested? Are there any features that are planned for testing but should be excluded? Feasibility Can the testing as planned be accomplished within the known cost and schedule constraints? Can every test described in the test plan be reasonably conducted? Environment Is the description of the environment complete? Is the test plan traceable to any nonfunctional requirements that define the operating environment? Performance Does the test plan account for the expected load for concurrent users, large databases, or other performance requirements? Can the performance tests be traced back to requirements in the specification? Acceptance Criteria Do the acceptance criteria match the standards of the organization? The following checklist items apply to the test cases: Clarity Does each test case have a clear flow of events? 173
  • 174. Vision and Scope Document Does each test case test only one specific interaction? Does each test case describe the interaction using specific user interface and data elements? Is each test case repeatable by someone uninitiated on the project? Completeness Is every requirement in the SRS verified fully with individual test cases? Are all of the steps in each test case necessary? Are there any steps that are missing? Are all alternative paths and exceptions accounted for? Accuracy For every action, is there an expected result? For every behavior in the requirement, is there a verification of the actual behavior? Is the test case data specific if data must be entered or modified, is that data provided? Traceability Is each test case uniquely identified with a name and a number? Can each test case be traced back to a specific requirement? 174
  • 175. Vision and Scope Document Review 4 & Testing Demo Document 28/12/2007 Ho Chi Minh National University – International University Instructor: Phan Viet Hoang December 28th , 2007 Date Version 1.0 Status Baseline Author Team TiHonMumMim(Group 6) Reviewer Team TiHonMumMim(Group 6) Documenter Nguyen Duc Quan Team member Signature Nguyen Duc Quan Le Vu Hoang Tran Minh Phung Phan Duy Tan Huynh Da Thuc 175
  • 176. Vision and Scope Document Testing demo In this part, we will introduce what we will perform in the testing demo for review 4. We will perform 3 kinds of tests. They are Unit testing, Functional requirement testing, and Non- Functional requirements testing. Due to the large number of classes, test cases for functional requirements, and non-functional requirements, and the recommendations for quality assurance from Prof. Phan Hoang and Ms. Sang, we will use check list and test some classes (not all classes) for Unit testing, and smoke tests (a collection of some test cases, not all tests cases) for functional and non-functional requirements testing. All 3 kinds of tests will be performed automatically. 176
  • 177. Vision and Scope Document Unit testing As we wrote in the Test Plan and Test Case document (document for review 3), we will use EJB3Unit to do Unit Testing. Our team will choose persistence classes (entities) to run demo for Unit Testing. Please check the system architecture with layer model to see where entities are used. Because we use EJB3Unit instead of JUnit to test persistence classes, we can use check list to make sure that entities are implemented correctly. The following check list contains standard checks that a persistence class must pass to be accepted. Test write: test writing operation to database check whether writing data to database is successful or not Test write null field: not allow write null data to our system database Test write read: test reading and writing data with relationships and constraints Test getter setter: test whether get and set methods of each entity work correctly or not The testing result of Unit Testing will be showed in the testing report later. Functional requirement testing In this part we will introduce the smoke test for functional requirements testing. As Prof.Phan Hoang and Ms. Sang recommended that we should choose which test cases that we feel most confident to run the testing demo. Therefore, we try to perform smoke test with all test cases of Login and Logout use case, Manage Course Offering use case, Register courses use case, and Manage Department Information. Test Cases of Log in and Log out Use Case User logs in successfully with valid username and password Name Test case: User logs in successfully with valid username and password Requirement The user is logged in correctly after providing correct username and password Preconditions The user is at the homepage or the log in page Steps 4. Provide valid username in the username textbox 5. Provide valid password in the password textbox 6. Click on log in button 177
  • 178. Vision and Scope Document Expected results The user is redirected to the specific homepage of that user Fail to login the system when providing invalid username Name Test case: Fail to login the system when providing invalid username Requirement The user is not logged in when providing invalid username Preconditions The user is at the homepage or the log in page Steps 4. Provide invalid username in the username textbox 5. Provide password in the password textbox or let password field be empty 6. Click on log in button Expected results The user is redirected to the error page with a warning “You have provided invalid username or invalid password” Fail to login the system when providing username or password containing special character(s) Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. Name Test case: Fail to login the system when providing username or password containing special character(s) Requirement The user is not logged in when providing username or password containing special character(s). Preconditions The user is at the homepage or the log in page Steps 4. Provide username containing special character(s) in the username textbox or/and 5. Provide password containing special character(s) in the password textbox or let password field be empty 6. Click on log in button Expected results The user is redirected to the error page with a warning “Username and Password cannot contain special character(s)” 178
  • 179. Vision and Scope Document Fail to login the system when providing valid username and invalid password Name Test case: Fail to login the system when providing valid username and invalid password Requirement The user is not logged in when providing valid username and invalid password Preconditions The user is at the homepage or the log in page Steps 4. Provide valid username in the username textbox 5. Provide invalid password in the password textbox 6. Click on log in button Expected results The user is redirected to the error page with a warning “You have provided invalid username or invalid password” Fail to login the system when providing empty username Name Test case: Fail to login the system when providing empty username Requirement The user is not logged in when providing empty username Preconditions The user is at the homepage or the log in page Steps 4. Provide empty username in the username textbox 5. Provide password in the password textbox or let password field be empty 6. Click on log in button Expected results The user is redirected to the error page with a warning “You must provide both username and password” Fail to login the system when providing valid username and empty password Name Test case: Fail to login the system when providing valid username and empty 179
  • 180. Vision and Scope Document password Requirement The user is not logged in when providing valid username and empty password Preconditions The user is at the homepage or the log in page Steps 4. Provide valid username in the username textbox 5. Provide empty password in the password textbox 6. Click on log in button Expected results The user is redirected to the error page with a warning “You must provide both username and password” User account is locked after failing to log in 3 times Name Test case: User account is locked after failing to log in 3 times Requirement User account is locked after failing to log in 3 times with a specific username Preconditions The user is at the homepage or the log in page Steps 5. Provide valid username in the username textbox or/and 6. Provide invalid or empty password in the password textbox 7. Click on log in button 8. Repeat above process for 3 times Expected results The user is redirected to the error page with a warning “You have provided invalid username or invalid password” After the 3rd time, the user account with given user name is locked out and a warning is issued “Account locked. Please wait for 30 minutes or contact the administrator” User logs in the system using an account is being used by another user Name Test case: User logs in the system using an account is being used by another user Requirement User CAN NOT log in the system using account is being used by another user 180
  • 181. Vision and Scope Document Preconditions A given account is being used by user 1 Steps 4. User 2 provides username of user 1 exactly 5. User 2 provides password of user 1 exactly 6. Click on log in button Expected results User 2 is redirected to the error page with a warning “This account is being used by another user” User logs in the system using an account is being locked Name Test case: User logs in the system using an account is being locked Requirement User CAN NOT log in the system using account is being locked Preconditions A given account is being locked by logging in fail 3 times Steps 4. Provides username of given account being locked 5. Provide password of given account being locked 6. Click on log in button Expected results User is redirected to the error page with a warning “This account is being locked. Please wait for 30 minutes or contact the administrator” Change password successfully Name Test case: Change password successfully Requirement The user wants to update password All old and new passwords must be provided Preconditions The user clicks on the “change password” The webpage that allows user to change password is displayed Steps 5. Enter old password 6. Enter new password 7. Enter confirmed password 181
  • 182. Vision and Scope Document 8. Click on the Recovery password button Expected results The old password is changed into new password Fail to change password when old or new or confirmed password is empty Name Test case: Fail to change password Requirement Try to change password when old or new or confirmed password is not input Preconditions The user clicks on the “change password” The webpage that allows user to change password is displayed Steps 5. Let old password empty or/and 6. Let new password empty or/and 7. Let confirmed password empty or/and 8. Click on the Recovery password button Expected results Notify user about empty fields Fail to change password when old password is incorrect Name Test case: Fail to change password Requirement Try to change password when providing incorrect old password Preconditions The user clicks on the “change password” The webpage that allows user to change password is displayed Steps 5. Enter wrong password 6. Enter new password empty 7. Enter confirmed password empty 8. Click on the Recovery password button Expected results Notify user that the current password is wrong 182
  • 183. Vision and Scope Document Recover the password successfully Name Test case: Recover the password successfully Requirement The user lost or forget the password and wants to reset the password Input right answer Preconditions The user clicks on the “Forget password” The system warns the user about recovering the password Steps 1. Specify the answer for the security question in the text box 2. Click on the Recovery password button Expected results The system issues the message indicates the password has been reset to the default password “Abcd1234” and warns the user to change their password for the next log in The password is reset to the default password “Abcd1234” The system redirects the user to the log in page Fail to reset password when inputting wrong answer for the security question Name Test case: Fail to reset password when inputting wrong answer for the security question Requirement The user lost or forget the password and wants to reset password Input wrong answer Preconditions The user clicks on the “Forget password” The system warns the user about recovering the password Steps 3. Specify the wrong answer of the security question in the text box 4. Click on the Recovery password button Expected results The system issues the message “The answer is not correct” The system redirects the user to the recover password page to choose another 183
  • 184. Vision and Scope Document question or answer the selected again Fail to reset password when inputting answer containing special character(s) for security question Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. Name Test case: Fail to reset password when inputting answer containing special characters for the security question Requirement The user lost or forget the password and wants to reset password The answer contains special characters Preconditions The user clicks on the “Forget password” The system warns the user about recovering the password Steps 3. Specify the answer containing special character(s) for the security question in the text box 4. Click on the Recovery password button Expected results The system issues the message “The answer cannot contain special character(s)” The system redirects the user to the recover password page to choose another question or answer the selected again Fail to reset password when inputting empty answer for the security question Name Test case: Fail to reset password when inputting empty answer for the security question Requirement The user lost or forget the password and wants to reset password Let answer be empty Preconditions The user clicks on the “Forget password” 184
  • 185. Vision and Scope Document The system warns the user about recovering the password Steps 3. Leave the answer text box blank 4. Click on the Recovery password button Expected results The system issues the message “The answer cannot be empty” The system redirects the user to the recover password page to choose another question or answer the selected again Test Cases of Manage Course Offering Use Case Create list of courses offering successfully Name Test case: Create list of courses offering successfully Requirement List of courses offering does not exist yet Academic affair staff wants to create new list course offering Preconditions The user must log in as the Academic Affair Staff The webpage that allows user to create list of courses offering is displayed Steps 8. Click on the button Manage Course Offering 9. Click on the button Create a list of course offering 10. Click on the drop down list to choose the desired faculty 11. Click on the check box to choose the subject which is selected to offer 12. Click on the drop down list to choose the lecturers for the selected courses 13. Click on the Submit button to create the list of course offering for the selected faculty 14. Click on the OK button to confirm the operation Expected results The new list of courses offering is created The system displayed the list of course offering that has been created The system redirects to the Manage Course Offering page 185
  • 186. Vision and Scope Document Update the list of course offering Name Test case: Update the list of course offering Requirement The list of courses offering exists in the system Academic affair staff wants to update list of courses offering Preconditions The user must log in as the Academic Affair Staff The webpage that allows user to create list of courses offering is displayed Steps 8. Click on the button Manage Course Offering 9. Click on the button Update list of course offering 10. Click on the drop down list to choose the desired faculty 11. Check or uncheck the check box of each course to change the list of course offering 12. Change the lecturer for each course (if desired) 13. Click on the Update button 14. Click on the OK button to confirm the operation Expected results The confirmation displayed The list of course offering is updated with the changes of the user The updated list of course offering is displayed after the operation completed Cancel during the Create list of course offering operation Name Test case: Cancel during the Create list of course offering operation Requirement Academic affair staff is being in the creating list of courses offering process. Preconditions The user must log in as the Academic Affair Staff User is being in the creating list of courses offering process Steps 8. Click on the button Manage Course Offering 186
  • 187. Vision and Scope Document 9. Click on the button Create a list of course offering 10. Click on the drop down list to choose the desired faculty 11. Click on the check box to choose the subject which is selected to offer 12. Click on the drop down list to choose the lecturers for the selected courses 13. Click on the Submit button to create the list of course offering for the selected faculty 14. Click on the Cancel button Expected results No list of course offering is created The system redirects to the Manage Course Offering page Cancel during the Update list of course offering operation Name Test case: Cancel during the Update list of course offering operation Requirement Academic affair wants to cancel the updating list of courses offering process Preconditions The user must log in as the Academic Affair Staff User is being in the creating list of courses offering process Steps 8. Click on the button Manage Course Offering 9. Click on the button Update list of course offering 10. Click on the drop down list to choose the desired faculty 11. Check or uncheck the check box of each course to change the list of course offering 12. Change the lecturer for each course (if desired) 13. Click on the Update button 14. Click on the Cancel button to confirm the operation Expected results List of courses offering is not updated The system redirects to the Manage Course Offering page 187
  • 188. Vision and Scope Document Fail to create an empty list of course offering Name Test case: Fail to create an empty list of course offering Requirement Academic affair tries to create an empty list of courses offering or creates an empty list of courses offering by accident Preconditions The user must log in as the Academic Affair Staff The webpage that allows user to create list of courses offering is displayed Steps 8. Click on the button Manage Course Offering 9. Click on the button Create a list of course offering 10. Click on the drop down list to choose the desired faculty 11. Don’t click any check box in order not to select any course 12. Click on the drop down list to choose the lecturers for the selected courses 13. Click on the Submit button to create the list of course offering for the selected faculty 14. Click on the OK button to confirm the operation Expected results No empty list is created The system issued warning about the empty list of course offering The system redirects to the Create list of course offering and let the user to create the non – empty list Update list of course offering while there’s no list of course offering for specific faculty Name Test case: Update list of course offering while there’s no list of course offering for specific faculty Requirement Academic affair staff tries to update list of courses offering while has not been created. Then the system must notify him/her about the unavailable status of list of courses offering. 188
  • 189. Vision and Scope Document Preconditions 3. The user must log in as the Academic Affair Staff 4. The selected faculty has no list of course offering Steps 4. Click on the button Manage Course Offering 5. Click on the button Update list of course offering 6. Click on the drop down list to choose the desired faculty Expected results A warning is displayed “There’s no list of course offering in this faculty. Cannot update” Test Cases of Manage Department Information Use case Add a department with valid information successfully Name Test case: Add a department with valid information successfully Requirement All fields are filled with valid data Preconditions The webpage that allows user to input information of a department is displayed Steps 7. Provide department’s name in the name textbox 8. Provide department’s location in the location textbox 9. Provide department’s dean in the dean textbox 10. Provide faculty information that the department has 11. Provide department description in the description text area 12. Click on add button Expected results 1. The department is added to the system 2. The summary of department has been added to the system is displayed Fail to add a department with name that already exists in the system Name Test case: Fail to add a department with name that already exists in the system Requirement All fields are filled with data 189
  • 190. Vision and Scope Document Preconditions The webpage that allows user to input information of a department is displayed Steps 7. Provide department’s name (which already exist in the system) in the name textbox 8. Provide department’s location in the location textbox 9. Provide department’s dean in the dean textbox 10. Provide faculty information that the department has 11. Provide department description in the description text area 12. Click on add button Expected results 1. The department is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the department to the system. The name of the department that you have provided already exists in the system” Fail to add a department when one or some or all fields are empty Name Test case: Fail to add a department when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to input information of a department is displayed Steps 7. Provide empty department’s name in the name textbox or/and 8. Provide empty department’s location in the location textbox or/and 9. Provide empty department’s dean in the dean textbox or/and 10. Provide empty faculty information that the department has or/and 11. Provide department description in the description text area or/and 12. Click on add button Expected results 1. The department is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the department to the system. You must provide all information” 190
  • 191. Vision and Scope Document Fail to add a department when inputting special character(s) to one or some or all fields Special Characters: special characters are characters which are not the alphabet (A – Z, a-z) and numeric (0-9) space characters. Name Test case: Fail to add a department when inputting special character(s) to one or some or all fields Requirement All fields are filled with data Preconditions The webpage that allows user to input information of a department is displayed Steps 7. Provide department’s name containing special character(s) in the name textbox or/and 8. Provide department’s location containing special character(s) in the location textbox or/and 9. Provide department’s dean containing special character(s) in the dean textbox or/and 10. Provide faculty information containing special character(s) or/and 11. Provide department description containing special character(s) in the description text area or/and 12. Click on add button Expected results 1. The department is NOT added to the system 2. The user is redirected to the error page with a warning “Fail to add the department to the system. Some fields contains special character(s)” Update a department with valid information successfully Name Test case: Update a department with valid information successfully Requirement All fields are filled with valid data Preconditions The webpage that allows user to update information of a department is displayed Steps 7. Provide department’s name in the name textbox or/and 191
  • 192. Vision and Scope Document 8. Provide department’s location in the location textbox or/and 9. Provide department’s dean in the dean textbox or/and 10. Provide faculty information that the department has or/and 11. Provide department description in the description text area or/and 12. Click on add button Expected results 1. The department is updated in the system 2. The summary of department has been updated is displayed Fail to update a department with name that already exists in the system Name Test case: Fail to update a department with name that already exists in the system Requirement All fields are filled with data Preconditions The webpage that allows user to update information of a department is displayed Steps 7. Provide department’s name (which already exist in the system) in the name textbox or/and 8. Provide department’s location in the location textbox or/and 9. Provide department’s dean in the dean textbox or/and 10. Provide faculty information that the department has or/and 11. Provide department description in the description text area or/and 12. Click on add button Expected results 1. The department is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the department in the system. The name of the department that you have provided already exists in the system” 192
  • 193. Vision and Scope Document Fail to update a department when one or some or all fields are empty Name Test case: Fail to update a department when one or some or all fields are empty Requirement NOT all fields are filled with data Preconditions The webpage that allows user to update information of a department is displayed Steps 7. Provide empty department’s name in the name textbox or/and 8. Provide empty department’s location in the location textbox or/and 9. Provide empty department’s dean in the dean textbox or/and 10. Provide empty faculty information that the department has or/and 11. Provide department description in the description text area or/and 12. Click on add button Expected results 1. The department is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the department in the system. You must provide all information” Fail to update a department when inputting special character(s) to one or some or all fields Special Characters: special characters are characters which are not the alphabet (A – Z, a-z)and numeric (0-9) and space characters. Name Test case: Fail to update a department when inputting special character(s) to one or some or all fields Requirement All fields are filled with data Preconditions The webpage that allows user to update information of a department is displayed Steps 7. Provide department’s name containing special character(s) in the name textbox or/and 8. Provide department’s location containing special character(s) in the location 193
  • 194. Vision and Scope Document textbox or/and 9. Provide department’s dean containing special character(s) in the dean textbox or/and 10. Provide faculty information containing special character(s) or/and 11. Provide department description containing special character(s) in the description text area or/and 12. Click on add button Expected results 1. The department is NOT updated in the system 2. The user is redirected to the error page with a warning “Fail to update the department in the system. Some fields contains special character(s)” Update cancel Name Test case: Update cancel Requirement When user decides to cancel updating, the system must allow him/her to stop the operation Preconditions The webpage that allows user to update information of a department is displayed Steps Click on add button Expected results The department is NOT updated in the system User is redirected to his/her main page Delete a department Name Test case: Delete a department Requirement When user decides to delete the selected department, the system removes that department from the system Preconditions The webpage that allows user to delete information of a department is displayed Steps 4. User chooses a department to delete from a drop down list. 194
  • 195. Vision and Scope Document 5. Verify that the system retrieves and displays the department information for user and prompts message MS004 to the Academic Affair Staff to confirm the deletion of the Department. 6. User confirms to delete the selected department by clicking on delete button. Expected results The system deletes the selected department from the system Delete cancel Name Test case: Delete cancel Requirement When user decides to cancel deletion, the system allows user to cancel the operation Preconditions The webpage that allows user to delete information of a department is displayed Steps 4. User chooses a department to delete from a drop down list. 5. Verify that the system retrieves and displays the department information for user and prompts message MS004 to the Academic Affair Staff to confirm the deletion of the Department. 6. User click on cancel button. Expected results The selected department is NOT deleted from the system User is redirected to his/her main page Test Cases of Register Course Use Case We will filter the prerequisites courses before showing the list of courses that a specific student can register. Therefore, that student can register any course in the list of courses offering that student can see. Fail to register more than 30 credits Name Test case: Fail to register more than 30 credits Requirement All the courses he/she wants to register has been checked Total number of credits is greater than 30 195
  • 196. Vision and Scope Document Preconditions The webpage allows user to register for courses is displayed Steps 5. Click register course offering button 6. Select courses from list of courses offering by checking the checkbox of the courses offering 7. Repeat step 2 until the total number of credits is greater than 30 8. Click on the Register button Expected results The system prompts the user with a warning message “You are not allowed to register more than 30 credits” Fail to register less than 15 credits Name Test case: Fail to register less than 15 credits Requirement All the courses he/she wants to register has been checked Total number of credits is less than 15 Preconditions The webpage allows user to register for courses is displayed Steps 5. Click register course offering button 6. Select courses from list of courses offering by checking the checkbox of the courses offering 7. Repeat step 2 until but make sure that the total number of credits is less than 15 8. Click on the Register button Expected results The system prompts the user with a warning message “You are not allowed to register less than 15 credits” Register for courses successfully Name Test case: Register for courses successfully Requirement Student registers for courses to create his/her schedule (please see the definition of SCHEDULE in the glossary part) 196
  • 197. Vision and Scope Document That student does not have schedule yet The total number of credits is less than or equal to 30 and greater than or equal to 15 Preconditions The webpage allows student to register for courses is displayed Steps 5. Click register course offering button. 6. Select courses offering from a list of available course offerings of this student that the system displays. 7. Repeat step 2 and make sure that the total of credits is less than or equal to 30 and greater than or equal to 15. 8. Click the submit button Expected results The schedule of that student is created in the system. List of course offering will be shown on the schedule of this student. 197
  • 198. Vision and Scope Document Update the existing schedule successfully Name Test case: update the existing schedule successfully Requirement Student has his/her schedule already (please see the definition of SCHEDULE in the glossary part) That student wants to modify his/her schedule The total number of credits is less than or equal to 30 and greater than or equal to 15 Preconditions The webpage allows student to register for courses is displayed Steps 6. Click the update schedule button. 7. Check some more courses that he/she wants to register and/or 8. Uncheck some courses that he/she does not want to register 9. Repeat step 2 or/and 3 if needed and make sure that The total number of credits is less than or equal to 30 and greater than or equal to 15 10. Click the update button Expected The schedule is updated in the system. results Updated list of course offering will be shown on the schedule of this student. Non-functional requirement testing Test Cases of Non-functional requirement testing Switch from Vietnamese to English Name Test case: Switch from Vietnamese to English Requirement The system must have ability to allow user to view the system in English while he/she is viewing the system in Vietnamese Preconditions The system is displaying text in Vietnamese Steps 2. Click on Vietnamese button 198
  • 199. Vision and Scope Document Expected 2. The system displayed text in English results Switch from English to Vietnamese Name Test case: Switch from English to Vietnamese Requirement The system must have ability to allow user to view the system in Vietnamese while he/she is viewing the system in English Preconditions The system is displaying text in English Steps 2. Click on Vietnamese button Expected 2. The system displayed text Vietnamese results Load testing with 15 requests at the same time Name Test case: Load testing with 15 requests at the same time Requirement The system must have ability to response many requests at the same time Test with 15 requests at the same time Preconditions The resource to be requested is available Steps 2. 15 requests are submitted at the same time Expected 2. The time for system to response all the requests is less than 10 results seconds Load testing with 25 requests at the same time Name Test case: Load testing with 25 requests at the same time Requirement The system must have ability to response many requests at the same time Test with 25 requests at the same time Preconditions The resource to be requested is available Steps 1. 25 requests are submitted at the same time Expected 3. The time for system to response all the requests is less than 10 results seconds 199
  • 200. Vision and Scope Document System architecture introduction In this part, we will provide a brief description of OURS architecture so that you can see the system in a systematic way and test it easily. From the updated requirement, our team sees that the number of functions the system provides is too large in comparison with the scope of the system. This brings us to the decision to divide the original system into many subsystems as follow. System architecture with sub-system model System architecture with layer model We use J2EE technologies to impalement OURS. The following is the layer model view of OURS. 200
  • 201. Vision and Scope Document We will introduce all technologies that we use to develop OURS. - Client layer: This layer is used directly by end user of OURS. The web browser will help end user to interact with OURS by rendering the user interface of OURS. We recommend to use Internet Explorer 7.0 as web browser for developing, testing, and running OURS - Presentation layer: This layer manages and represents the user interface of OURS. We use AJAX (with Open Rico), Validation Framework, and Struts Framework (this framework is the key of presentation layer) to implement the presentation layer of OURS. - Business Logic layer: This layer is the place we define and manage all business rules that the system must satisfy and support the university business process, in particular course registration process. We use EJB3.0 (The latest technology of J2EE for business login layer) to implement business logic layer. - Persistence layer: This layer allows the system to access the database in an object- oriented manner by using EJB entities. - Database system layer: This layer is the place for OURS stores all data in a database. We use MySql 5.0 for the database of OURS. How to download & install tools In this part, we will introduce all the tools, where to download them or their libraries, and how to install them (if any of them requires installation before we can use it). o JDK 1.6.x 1. Download JDK for Windows (You need to accept license agreement before downloading ) at https://sdlc1a.sun.com/ECom/EComActionServlet;jsessionid=8D963E27810 5AC56A9ADEAA4FBD103B8# 201
  • 202. Vision and Scope Document 2. Double-click on the package you have downloaded to install the JDK 3. Follow the instruction of installation. You should use default values specified by the instruction and click all “Next” buttons so that you will feel easier to monitoring it later. o Environment variables after finishing the JDK installation: 1. Right click on My computer, then choose Properties. 2. Click the Advanced tab. 3. Click Environment variables. 4. For either a user or a system variable, do the following steps: Click New to add new variable name and value. o Variable name: PATH o Variable value: Depend on how you install JDK. It will be similar to this : C:Program FilesJavajdk1.6.0_02bin Click New to add new variable name and value: o Variable name: JAVA_HOME o Variable value: Depend on how you install JDK. It will be similar to this: C:Program FilesJavajdk1.6.0_02 o Glassfish 2.0 1. Download application server Glassfish V2.0 at http://java.net/download/javaee5/v2_branch/promoted/WINNT/glassfish- installer-v2-b58g.jar 2. Make sure that you have set the environment variables (PATH and JAVA_HOME) correctly 3. Click Start 4. Choose Run 5. Type: CMD, then press Enter , and the console application will be displayed, 6. Type: java -Xmx256m -jar filename.jar With filename is the name of file you have downloaded. It is the package of Glassfish V2.0. This command will unbundle Glassfish and create a new directory structure rooted under a directory named 'glassfish'. 7. Environment variables for ANT (ANT is a common tool used J2EE application development for building the application): Right click on My computer, then choose Properties. Click the Advanced tab. Click Environment variables. For either a user or a system variable, do the following steps: o Click New to add new variable name and value:  Variable name: ANT_HOME  Variable value: Depend on how and where you extract the Glassfish V2.0. It will be similar to this: 202
  • 203. Vision and Scope Document 8. Go to Glassfish folder where the program has been extracted by using CD command of MS-DOS. This command depends on where your Glassfish folder is. It should be similar to: CD glassfish then press Enter. 9. The real installation of glassfish will be done when you execute the ANT command. We use Windows operating system. Therefore, we type: libantbinant -f setup.xml o MySQL 5.0.x (To download at http://dev.mysql.com , you have to register an account to be member of the website. Therefore, there’s no direct link to download) 1. Download MySql Essential 5.0 at http://dev.mysql.com/downloads/mysql/5.0.html#win32 2. Double-Click on the package has been downloaded, and then follow the instruction of the installation. To be easy to use later, you should use all default values specified by the instruction and click on all “Next” buttons. However, both the username and password used for administrator of MySql should be “root”. o MySql Gui Tools 5.0.x 1. Download MySql Gui Tools at http://dev.mysql.com/downloads/gui- tools/5.0.html 2. Double-Click on the package has been downloaded, and then follow the instruction of the installation. To be easy to use later, you should use all default values specified by the instruction and click on all “Next” buttons. o MySql Connector 5.0.x 1. Download MySql-connector-Java at http://dev.mysql.com/downloads/connector/j/5.0.html o NetBean 6.0 1. Download the Netbean IDE verion 6.0 at http://download.netbeans.org/netbeans/6.0/final/bundles/netbeans-6.0- windows.exe 2. Double-Click on the package has been downloaded to start setup 3. Follow the instruction of the installation. To be easy to use later, you should use all default values specified by the instruction and click on all “Next” buttons o Junit 1. Download Junit 4.x at http://sourceforge.net/project/downloading.php?group_id=15278&use_mi rror=jaist&filename=junit4.4.zip&85130481 2. Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 3. Add JUnit to the classpath: 203
  • 204. Vision and Scope Document set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%junit.jar Note: To run your JUnit tests, you'll need the following elements in your CLASSPATH: o JUnit class files o Your class files, including your JUnit test classes o Libraries your class files depend on If attempting to run your tests results in a NoClassDefFoundError, then something is missing from your CLASSPATH. Windows Example: set CLASSPATH=%JUNIT_HOME%junit.jar;c:myprojectclasses;c: myprojectlibsomething.jar o EJB3Unit 1. Download all packages needed for EJB3Unit at https://sourceforge.net/project/showfiles.php?group_id=150949&package _id=166989&release_id=528475 o AdventNetQEngine_WebPerformance 1. Download QEngine_WebPerformance at http://www.adventnet.com/products/qengine/download.html 2. Double-Click on the package has been downloaded, and then follow the instruction of the installation. To be easy to use later, you should use all default values specified by the instruction and click on all “Next” buttons. o QuickTest Professional 9.2 1. Download QuickTest Professional at https://h10078.www1.hp.com/cda/hpdc/display/main/index.jsp?zn=bto&cp=54_ 4012_100__ 2. You have to register an account at the HP corporation websie before you are allowed to download the tool. Click New user please register On search fill, you type quicktest to find QuickTest Professional tool Click on HP QuickTest Professional 9.2 Evaluation in result Click Agree button to go next page Click on hyperlink in URL line at Important Software Download Links 204
  • 205. Vision and Scope Document 3. After downloading, double-Click on the package has been downloaded, and then follow the instruction of the installation. To be easy to use later, you should use all default values specified by the instruction and click on all “Accept” or “I agree” and “Next” buttons. 4. To be noticed that this software requires Dot Net Framework to install it. How to install OURS This part of the document is a guide on how to deploy the system to the Java application server. We provide 3 separate packages for the 3 layers of our system: presentation layer (.war package), business layer (.jar package) and database storage. o Database: Restore database from back up file: 1. Login to the database as Administrator: Run the MySQL Administrator and fill in the required fields: Server Host: if you have gone through a normal installation procedure for MySQL, the default value here should be “localhost”. Port: the port for the Application server to connect to the database server. The default value is “3306”. Username and Password: username and password is used to authorize user to access to the database. Type the username and password you used when installing MySQL. Default value is “root” “root”. Press “OK” button. 2. Restore back up file: On the left side of the application, you will see some tasks such as: Server Information, Service Control, Startup Variables… click on the “Restore” session. Click on the “Open Backup File”. Browse to the location of the database back up file then open. Check the 2 check box in the Options area. Click on “Start Restore”.  Now the all the database records have been loaded into the database server. You can click on “Catalogs” and check if the schema “ours- silverbullet” presents. o Web part: Deploy Web part 1. Login the application server First startup the application server. Open the command line, type “cmd” then enter. Type the following command: 205
  • 206. Vision and Scope Document <GlassfishPath>binasadmin start-domain domain1, enter then wait for the server to start. Open command line or any browser and type in http://localhost:4848 You will be redirect to the login page. Provide the username and password, the default value for username is “admin” and password is “adminadmin”. 2. Deploy the .war file: On the left menu, click on “Web Applications”, on the main content, click on “Deploy”. Click on “Browse”, locate the oursWeb.war file then open. Click on “OK” button to start deploy the web layer. o EJB part: 1. Login the application server: repeat the step above if you haven’t logged in yet. 2. Connection pool: On the left menu Click on ResourcesJDBCConnections Pool. Click “New…” button. Fill the general settings then click ok o Name: mysqlPool o Resource Type: javax.sql.DataSource o Database Version: MySQL On Step 2 of 2, go to additional properties table, check all the properties then click “Delete Properties” Add 6 new properties, these are the configuration of the database server, adjust if necessary. o serverName: localhost o port: 3306 o networkProtocol: jdbc:mysql o username: root o password: root o databaseName: ours-silverbullet Finich. You can click on “Ping” to make sure the information use type is correct. 3. Configure data source On the left menu, go to ResourcesJDBCJDBC Resources Add New. Fill in the new jdbc resource information: o JDNI name: ours-1.1 o Pool Name: mysqlPool Click OK 206
  • 207. Vision and Scope Document 4. Deploy EJB part: On the left menu, click on EJB Modules. Click deploy Browser to the system business layer package OURS1.1.1 then open Click on “OK” to start deploying. How to run OURS o Application server and database server have started already 1. Launch OURS by typing the following URL in Internet Explorer or in Firefox or any other browsers http://localhost:8080/oursWeb/ o Application server or/and database server not been started 1. Start application server: Looking for “bin” folder of the Glassfish server, and then double click on the file named “asadmin.exe”. The path of bin folder will be similar to “C:Program Filesglassfish-v2bin”. When the console application is displayed, type the command “start-domain”, the server will be started. 2. Launch OURS by typing the following URL in Internet Explorer or in Firefox or any other browsers http://localhost:8080/oursWeb/ 207
  • 208. Vision and Scope Document How to setup and run tests of OURS o Unit testing 1. Open Netbean 6.0 by double clicking on its shortcut(it is on your desktop by default) 2. Open the Unit test project. We put all the persistence classes and their test classes in the Unit test project. 3. Run the test by clicking on run, choose run test. 4. Note that if you Netbean IDE does not have library of EJB3Unit, you have to download it and add it to the library by right clicking on the project; choose add library menu item, and then choose the library you have downloaded. o Functional requirement testing 1. Start server where OURS is deployed(see the part of How to run OURS) 2. Start the QuickTest Professional by double clicking on the shortcut of the QuickTest Professional program 3. Create a new test by selecting new button 4. You have to provide the URL you want to test. In this case it is any URL of OURS. It should be http://localhost:8080/oursWeb/ 5. Now, the program will allow you to record the action you perform on the URL you have specified. 6. Stop the recording by clicking on the stop button. 7. After you finish you action, you can input many different inputs in the data table. This will help you to test the function automatically, instead of input data again each time the action is repeated. o Non-functional requirement testing 1. Multi-language checks Run OURS and switch between English and Vietnamese by click on the Vietnamese or English button which is on top of the website. 2. Load test Start QEngine server by double click on the shortcut of QEngine (which is put on your desktop by default) Choose new transaction  specify the name of the transaction Wait for the program to process. It will ask you to specify the URL to test. You have to provide the URL of OURS Wait for the program to records the information, then stop the recording The program will show you how it processes the load test 208
  • 209. Vision and Scope Document How to use OURS This document is about guiding user to use OURS. It includes “How to Use” guidelines of main functions of the system. Although this part is optional, our group still wants to provide a brief description of the real user manual, so that user will feel easier to have the basic ideas about OURS. Login and Logout This feature allows user to log in to the system to achieve the access permission to perform other functions that are granted to that specific user. It also lets user log out to end his/her session View Academic History Log in 1. Enter the username in the username textbox 2. Enter the password in the password textbox 3. Click on the sign in button 4. Redirected to the desired page with the status logged on Log out 1. Click on the log out button 2. Redirected to the main page with the status logged out Recover Password 1. Click on the “Forget password” link 2. Specify the answer of the security question in the text box 3. Click on the Recovery password button Register Course This feature allows a Student to register course offerings in the current semester. 1. Click on register courses button 2. Check the checkbox(es) to select the course(s) you want to register. If you do not want to register for the course(s) you have checked, just simply uncheck the checkbox(es) of the course(s). 3. Click on submit button View Academic History This feature allows a Student to view his studying progress. The Student can see the courses he has taken as well as the scores and status (passed or failed). 1. Choose a filter group: View All, View by specific year and semester, View by passed and failed status. 209
  • 210. Vision and Scope Document 2. One filter is chosen. 3. Click View button. Manage Department Information This feature allows Academic Affair Staff to manage department and faculty information. This includes adding, updating, and deleting department and faculty from the system. Add a department 1. Provide department’s name in the name textbox 2. Provide department’s location in the location textbox 3. Provide department’s dean in the dean textbox 4. Provide faculty information that the department has 5. Provide department description in the description text area 6. Click on Add button Update a department 1. Provide department’s name in the Name textbox or/and 2. Provide department’s location in the Location textbox or/and 3. Provide department’s dean in the Dean textbox or/and 4. Provide faculty information that the Department has or/and 5. Provide department description in the Description text area or/and 6. Click on Add button Delete a department 1. Chooses a department to delete from a drop down list. 2. System displays a message warns the user about the deletion 3. Confirms to delete the selected department by clicking on delete button Manage Student Information This feature allows the Academic Affair Staff to manage student information in the registration system. This includes adding, updating, deleting, and searching Students from the system Add a student 8. Provide student’s name in the name textbox 9. Provide student’s ID in the ID textbox 10. Choose student’s faculty in the list of faculty 11. Choose student’s academic duration in the range list 12. Choose student’s academic year in the list 13. Choose semester of this academic year. 14. Choose course of this semester. 210
  • 211. Vision and Scope Document 15. Click on add button Search a student by Student ID/Student name 1. Chooses ID and Name filter from the filter drop down list 2. Provide an ID in the ID textbox or/and 3. Provide a name in the name textbox 4. Click on search button Search a student by Faculty/Academic duration 1. Chooses faculty and academic duration filter from the filter drop down list 2. Choose a faculty from the drop down list 3. Choose an academic duration from drop down list 4. Click on the Search button Search a student by Academic year/Semester/Course 1. Chooses academic year, semester, and course filter from the filter drop down list 2. Choose a academic year from the academic year drop down list or/and 3. Choose a semester from the semester drop down list or/and 4. Choose a course from the course drop down list 5. Click on search button Update a student 1. Provide student’s name in the name textbox or/and 2. Provide student’s ID in the ID textbox or/and 3. Choose student’s faculty in the list of faculty or/and 4. Choose student’s academic duration in the range list or/and 5. Choose student’s academic year in the list or/and 6. Choose semester of this academic year or/and 7. Choose course of this semester or/and 8. Click on update button Delete a student 1. Choose a student to be deleted 2. System warns the user about the deletion 3. Click on the Delete button to confirm Manage Course Offering This feature allows Academic Affairs to monitor course offerings in one semester of specific year. Create list of courses offering 1. Click on the button Manage Course Offering 2. Click on the button Create a list of course offering 3. Click on the drop down list to choose the desired faculty 211
  • 212. Vision and Scope Document 4. Click on the check box to choose the subject which is selected to offer 5. Click on the drop down list to choose the lecturers for the selected courses 6. Click on the Submit button to create the list of course offering for the selected faculty 7. Click on the OK button to confirm the operation Update a list of course offering 1. Click on the button Manage Course Offering 2. Click on the button Update list of course offering 3. Click on the drop down list to choose the desired faculty 4. Check or uncheck the check box of each course to change the list of course offering 5. Change the lecturer for each course (if desired) 6. Click on the Update button 7. Click on the OK button to confirm the operation Manage Lecturer Information This feature allows the Academic Affair Staff to manage lecturer information in the registration system. This includes adding, updating, deleting, and searching lecturers from the system. Add a lecturer 1. Provide lecturer’s name in the Name textbox 2. Choose lecturer’s date of birth in the Calendar 3. Provide lecturer’s cell-phone number in the cell-phone textbox 4. Provide lecturer’s email address in the Email textbox 5. Provide lecturer’s department where that lecturer belongs in the department textbox 6. Provide lecturer’s degree in the degree textbox 7. Click on add button Look for a lecturer 1. User chooses the department where the lecturer belongs 2. Verify that the system retrieves and displays the list of lecturers of that department 3. User choose a lecturer from the list 4. Verify that the summary of information of selected lecturer is displayed Update a lecturer 1. Provide lecturer’s name in the name textbox or/and 2. Choose lecturer’s date of birth in the calendar or/and 3. Provide lecturer’s cell-phone number in the cell-phone textbox or/and 4. Provide lecturer’s email address in the email textbox or/and 212
  • 213. Vision and Scope Document 5. Provide lecturer’s department where that lecturer belongs in the department textbox or/and 6. Provide lecturer’s degree in the degree textbox or/and 7. Click on add button Delete a lecturer 1. Select the lecturer to be deleted 2. Click on the deleted button 3. System warns the user about the deletion 4. Click on the Delete button to confirm Manage Financial Activities This feature allows Financial Office Staff to monitor student’s tuition fee. This includes viewing and updating the tuition fee status of students. View tuition fee by student ID or/and by student name 1. Chooses ID and Name filter from the filter drop down list 2. Provide an ID in the ID textbox or/and 3. Provide a name in the name textbox 4. Click on search button View tuition fee by faculty or/and by academic duration 1. Chooses faculty and academic duration filter from the filter drop down list 2. Choose a faculty from the drop down list 3. Choose a academic duration from drop down list 4. Click on search button View tuition fee by academic year, semester, and course 1. Chooses academic year, semester, and course filter from the filter drop down list 2. Choose a academic year from the academic year drop down list or/and 3. Choose a semester from the semester drop down list or/and 4. Choose a course from the course drop down list 5. Click on search button Update tuition fee status of a student 1. Choose a student from the list 2. Change status of tuition fee of that student by choose tuition fee status from the stats drop down list 3. Click on submit button 213
  • 214. Vision and Scope Document Manage Course Catalogue This feature allows the Academic Affair Staff to manage Course Catalog information in the registration system. This includes adding, updating, deleting, and searching a course from the course catalog of the university Add new course to course catalogue successfully 1. Provide course’s ID in the ID textbox 2. Provide course’s Name in the name textbox 3. Provide number of credits of the course in the credit textbox 4. Choose the faculty of the department where the course belongs from dropdown list 5. Provide the description of the course in the description text area. 6. Click on add button Update course with valid information successfully 1. Provide course’s ID in the ID textbox or/and 2. Provide course’s Name in the name textbox or/and 3. Provide number of credits of the course in the credit textbox or/and 4. Choose the faculty of the department where the course belongs from dropdown list or/and 5. Provide the description of the course in the description text area. 6. Click on add button Manage User Account This feature allows the Administrator to manage user account information in the system. This includes creating, updating, deleting, and searching user account(s) in the system Create a new user account 1. Provide username in the ID textbox 2. Choose a role from the drop down list 3. Provide the description of the account in the description text area. 4. Click on create button Update an account 1. Provide new username in the ID textbox and/or 2. Choose a role from the drop down list and/or 3. Provide the description of the account in the description text area and/or 4. Choose the status of the account from the drop down list and/or 214
  • 215. Vision and Scope Document 5. Choose the secret question from the drop down list and/or 6. Provide the answer to the answer textbox 7. Click on update button 215

×