BÀI CHO YỀU CÂU RÕ RÀNG VÀ MỘT NEW DEV VÀ CÓ MANY

CHANGE

Question 1
Considering the specific situation and my role assigned to implement this project, I
recommend applying the AGILE Scrum development process. Agile Scrum is an
adaptable, iterative design and development method that enables the team to adjust to
the needs that change over time. By encouraging significant user involvement, this
strategy also makes communication and collaboration easier, which is crucial considering
the team's interdisciplinary makeup. Agile Scrum additionally permits regular testing and
revision, guaranteeing the system's reliability. The following are the requirements that
affect my decision:

● Reliability:

The initial requirements are clearly defined in terms of each function of each user
role, however these requirements may change after the development life cycle
because FU has not had such a system before.

● Types and number of requirements:

The requirements encompass both functional and non-functional aspects, as

listed above. They are explicit and free from ambiguity. The team comprehends
user needs and the solution, evident in the identification of five key system
features.

- For Lecturers/Staffs: The system allows lecturers and staff to register bus routes,
change bus routes and view currently registered

The system allows lecturers and staff to change bus routes and view currently
registered
- For Admin Staff: The system allows administrative staff to synthesize weekly bus
schedules of staffs and lecturers, schedule vehicles for bus routes, record and
summarize costs for bus trips.

- For Admin Manager: The system allows managers to view bus schedules for
weekly trips, approve weekly bus schedules, and view vehicle cost summary.

- For Academic Staff: The system allows entering lecturers lecture schedules
exported from FAP, synthesizing lecturers bus schedules from lecturers lecturer
schedules, transferring lecturers bus schedules to the administrative department.

- The system needs to allow users to log in with the FU’s email account on the
Gmail platform, ensuring information security. The system needs to ensure high
performance and security, requiring little training time no use. Users can use the
manual without having to attend official training courses.

● Development team :

The team is made up of four to six highly skilled and experienced developers. This
suggests that they have the potential to function well in a self-organizing team,
which is essential to the Agile Scrum process. In order to support the project,
which will profit from Scrum's collaborative nature, other department (admin
dept) employees will also join the team.

● User Involvement in the Project:

The project requires high involvement from users (lecturers, admin staff, admin
manager, academic staff) in providing feedback and iteratively refining the system.
Agile Scrum encourages regular user feedback, which can be incorporated into
system development in each sprint.

● Time Constraints and Managers' Expectation:

With a goal to have the first version of the system in use within 3 months and the
entire project completed within 6 months, Agile Scrum, with its emphasis on
delivering working software in short sprints (typically 2-4 weeks), can help the
team meet these deadlines.

● Customer/User

The system must cater to the needs of a variety of users (lecturers/staffs, admin
staff, admin manager and academic staff), and these needs may vary and evolve
over time. Agile Scrum, with its focus on user stories and regular feedback, can
help ensure that the system meets these diverse needs.

 To summarize, from the above points and arguments, I conclude that Agile
Scrum is the most suitable methodology for this project because it can
adapt to user requirements over time, and the employee resources
situation of the development team

Question 2
I recommend a combination of both Whitebox and blackbox for this team. For the
Developer, I let it use both whitebox and blackbox using the Unitest method to
test the code and the Integration method to test the components to see if they
work well or not.
Because Optimize code by finding hidden errors.
Easily automate test cases
More thorough testing as all code paths are usually covered.
Testing can be performed early in the software development process even when a
GUI (Graphical User Interface) is not available.

 Conclusion: I suggest using both blackbox and whitebox because each test
method has its own advantages. If we use either one, there is a risk of
 encountering errors during use throughout the product's life cycle, so we
should use both ways to avoid errors.

Question 3
Four functional requirements:
o For Lecturer: The system allows lecturers and staff to register bus routes, change
bus routes and view currently registered
o For Admin Manager: The system allows managers to view bus schedules for
weekly trips, approve weekly bus schedules, and view vehicle cost summary.
o For Academic staff: The system allows administrative staff to synthesize weekly
bus schedules of staffs and lecturers, schedule vehicles for bus routes, record
and summarize costs for bus trips.
o Users: Users can use the manual without having to attend official training
courses.

Two non-functional requirements:

 Browser Compatibility: The system should be compatible with the latest versions of popular
web browsers (e.g., Chrome, Firefox, Safari).
 User Interface Consistency: The user interface should follow the company's branding
guidelines and maintain a consistent design.

Question 4
Question 5
Four test cases included:

Test case 1:
 Description: Test performance of the system
 Input: 10000 users online in this time.
 Expected: All user can online
 Output: All user can online
 Exception: System inform error message “API Connection Fail"
< Mô tả: Kiểm tra hiệu suất của hệ thống Đầu vào: 10000 người dùng trực tuyến trong thời gian này. Dự
kiến: Tất cả người dùng đều có thể trực tuyến Đầu ra: Tất cả người dùng có thể trực tuyến Ngoại lệ: Hệ
thống thông báo lỗi "Kết nối API không thành công">

Test case 2:
 Description: Test layout for each device
 Input: Open the screen of system in PC or mobile device
 Expected: Display successfully different layout for each device
 Output: Display successfully different layout for each device
 Exception: The UI does not meet the requirements
< Sự miêu tả: Bố cục thử nghiệm cho từng thiết bị Đầu vào: Mở màn hình hệ thống trong PC hoặc thiết bị
di động Dự kiến: Hiển thị thành công bố cục khác nhau cho từng thiết bị Đầu ra: Hiển thị thành công bố
cục khác nhau cho từng thiết bị Ngoại lệ: Giao diện người dùng không đáp ứng các yêu cầu>
 Test case 3:
 Description: Test Register Functional
 Input: User register the new account
 Expected: The system should add the new account in the system and allow new account can
join a system
 Output: The system adds the new account in the system success, that account can join and
use all device in the system
 Exception: If the system fails to add the new account in the system, that account can’t join
and use device, the system informs a message “This account is not exists”
< Mô tả: Chức năng đăng ký kiểm tra Đầu vào: Người dùng đăng ký tài khoản mới Dự kiến: Hệ thống
nên thêm tài khoản mới vào hệ thống và cho phép tài khoản mới có thể tham gia hệ thống Đầu ra: Hệ
thống thêm tài khoản mới trong hệ thống thành công, tài khoản đó có thể tham gia và sử dụng tất cả các
thiết bị trong hệ thống Ngoại lệ: Nếu hệ thống không thể thêm tài khoản mới vào hệ thống, tài khoản đó
không thể tham gia và sử dụng thiết bị, hệ thống sẽ thông báo "Tài khoản này không tồn tại">

Test Case 4:
 Description: Test the calculate vehicle cost functional.
 Input: All cost of vehicle
 Expected: The system should calculate a cost of each month.
 Output: The system displays a cost of total vehicle in each month.
 Exception: If the system fails to calculate and can’t display a result cost of vehicle in each
month.
< Sự miêu tả: Kiểm tra chức năng tính toán chi phí xe. Đầu vào: Tất cả chi phí xe Dự kiến: Hệ thống nên
tính toán chi phí của mỗi tháng. Đầu ra: Hệ thống hiển thị chi phí tổng số xe trong mỗi tháng. Ngoại lệ:
Nếu hệ thống không tính toán được và không thể hiển thị kết quả chi phí xe trong mỗi tháng.>

Question 6
The two user stories are:

- User Story 1:

 As a Admin Manager, I want to view vehicle cost summary such that I can
calculate a cost of vehicle in each month.
 - User Story 2:

 As a lecturer/staff, I want to change bus route such that I can change a

route I want to go in the next day.

Question 7
User story mapping for ‘Register Bus Route’
and ‘Change Bus Route’ featureas