Khi khách hàng và đội ngũ phát triển không hiểu nhau, điều gì có thể xảy ra trong dự án phát triển phần mềm?
Khi khách hàng và đội ngũ phát triển không hiểu đúng yêu cầu, có thể dẫn đến phát triển sai tính năng hoặc thất bại trong triển khai. Để tránh điều này, BA cần một công cụ mạnh mẽ để ghi lại rõ ràng yêu cầu của khách hàng và đảm bảo tính nhất quán trong suốt quá trình phát triển, và đó chính là SRS (Software Requirements Specification).
Định nghĩa SRS (Software Requirements Specification)
SRS (Software Requirements Specification) là tài liệu ghi lại chi tiết các yêu cầu phần mềm mà hệ thống cần thực hiện. Nó giúp các bên liên quan (khách hàng, đội ngũ phát triển, kiểm thử) hiểu rõ yêu cầu và hướng phát triển phần mềm.
SRS có những thành phần nào?
- Yêu cầu chức năng: Các tính năng mà phần mềm cần có (ví dụ: thanh toán trực tuyến).
- Yêu cầu không chức năng: Các yêu cầu về hiệu suất, bảo mật, khả năng mở rộng.
- Tiêu chí kiểm tra: Các tiêu chuẩn để đánh giá phần mềm có đúng yêu cầu không.
- Quản lý thay đổi: Theo dõi và điều chỉnh yêu cầu khi cần thiết.
Tình huống thực tế: Phát triển tính năng thanh toán trực tuyến
Mô tả tình huống:
Giả sử bạn là một BA đang làm việc với khách hàng yêu cầu phát triển tính năng thanh toán trực tuyến. Khách hàng nói: Tính năng thanh toán phải nhanh và an toàn. Tuy nhiên, yêu cầu này quá mơ hồ và không đủ rõ ràng.
Câu hỏi cần làm rõ:
- Thời gian xử lý thanh toán là bao lâu?
- Phương thức bảo mật nào sẽ được sử dụng? (Ví dụ: mã hóa, xác thực hai yếu tố)
- Tính năng cần tích hợp với các cổng thanh toán nào?
- Sự an toàn có bao gồm bảo vệ thông tin cá nhân của khách hàng không?
- Có cần hỗ trợ nhiều loại thẻ tín dụng không?
- Thời gian hoàn tiền là bao lâu?
- Có cần thông báo cho khách hàng khi thanh toán thành công không?
Ví dụ: Tính năng thanh toán trực tuyến
Sau khi hỏi các câu hỏi như:
- Thời gian xử lý thanh toán là bao lâu?
- Phương thức bảo mật nào sẽ được sử dụng? (Ví dụ: mã hóa, xác thực hai yếu tố)
- Tính năng cần tích hợp với các cổng thanh toán nào?
SRS sẽ ghi nhận các yêu cầu như sau:
1. Yêu cầu chức năng
1.1. Thời gian xử lý thanh toán
- Thời gian xử lý thanh toán phải không quá 5 giây.
- Hệ thống phải đảm bảo rằng người dùng sẽ nhận được thông báo thanh toán thành công hoặc thất bại trong vòng 5 giây kể từ khi bắt đầu thanh toán.
1.2. Phương thức bảo mật
- Hệ thống sẽ sử dụng mã hóa SSL để bảo vệ các giao dịch.
- Xác thực hai yếu tố (2FA) sẽ được áp dụng cho các giao dịch thanh toán có giá trị lớn hơn $100.
1.3. Cổng thanh toán: Tính năng thanh toán cần phải tích hợp với các cổng thanh toán sau:
- Stripe: Để xử lý thẻ tín dụng và thẻ ghi nợ.
- PayPal: Cho các giao dịch quốc tế.
- Apple Pay và Google Pay: Để hỗ trợ thanh toán nhanh chóng trên thiết bị di động.
1.4. Bảo vệ thông tin cá nhân
- Tính năng thanh toán phải bảo vệ thông tin cá nhân của khách hàng, bao gồm số thẻ tín dụng và thông tin thanh toán.
- Hệ thống phải tuân thủ các tiêu chuẩn bảo mật của PCI-DSS (Payment Card Industry Data Security Standard).
2. Yêu cầu không chức năng
2.1. Hiệu suất: Hệ thống thanh toán phải có khả năng xử lý ít nhất 500 giao dịch/giây trong thời gian cao điểm.
2.2. Khả năng mở rộng: Hệ thống phải có khả năng mở rộng để xử lý lượng giao dịch tăng lên ít nhất 100% trong vòng 12 tháng.
Tại sao SRS là công cụ không thể thiếu đối với BA?
- Giảm thiểu sự hiểu lầm:
SRS giúp đảm bảo rằng yêu cầu của khách hàng được ghi lại một cách chi tiết, tránh những hiểu lầm giữa các bên liên quan. Điều này giúp đội ngũ phát triển hiểu chính xác yêu cầu và tránh làm việc không đúng hướng.
- Cải thiện giao tiếp
Khi tất cả các yêu cầu được mô tả rõ ràng trong SRS, việc giao tiếp giữa BA, khách hàng và đội ngũ phát triển trở nên dễ dàng và hiệu quả hơn. Điều này giúp giảm thiểu sai sót và đảm bảo mọi bên đều hiểu rõ về mục tiêu của dự án.
- Tăng hiệu quả phát triển:
Một SRS rõ ràng giúp đội ngũ phát triển biết chính xác những gì cần phải làm, từ đó tăng năng suất và chất lượng công việc. Họ không phải mất thời gian làm lại các phần do sự không rõ ràng trong yêu cầu ban đầu.
- Tạo cơ sở để kiểm tra và đánh giá:
Với SRS, việc kiểm tra chất lượng sản phẩm sẽ trở nên dễ dàng hơn, vì tất cả yêu cầu đều đã được ghi lại chi tiết. Khi phần mềm hoàn thành, đội ngũ phát triển có thể so sánh với SRS để đảm bảo rằng sản phẩm đáp ứng đúng yêu cầu.
- Quản lý thay đổi yêu cầu:
Trong suốt quá trình phát triển, yêu cầu của khách hàng có thể thay đổi. SRS giúp BA và các bên liên quan dễ dàng theo dõi và quản lý các thay đổi này, đảm bảo rằng phần mềm cuối cùng vẫn đáp ứng đúng mong muốn của khách hàng.
Cấu trúc cơ bản của SRS gồm ?
- Giới thiệu: Mục đích tài liệu/ Phạm vi của hệ thống/ Đối tượng và người sử dụng tài liệu
- Mô tả tổng quan hệ thống: Tổng quan về hệ thống và các chức năng chính
- Yêu cầu chức năng: Mô tả chi tiết các tính năng mà phần mềm phải có
- Yêu cầu không chức năng: Các yêu cầu về hiệu suất, bảo mật, tính mở rộng, giao diện người dùng, v.v.
- Ràng buộc hệ thống: Các yêu cầu về công nghệ, phần cứng, môi trường hoạt động
- Yêu cầu về giao diện: Giao diện người dùng, giao diện hệ thống, giao diện với phần mềm khác
- Tiêu chí kiểm tra và chấp nhận: Các tiêu chuẩn để kiểm tra và chấp nhận sản phẩm
- Quản lý thay đổi: Cách thức quản lý và cập nhật các thay đổi trong yêu cầu
- Phụ lục: Các tài liệu bổ sung, định nghĩa thuật ngữ, sơ đồ, biểu đồ
Kết luận: SRS là công cụ quan trọng giúp BA đảm bảo chất lượng dự án
SRS không chỉ là một tài liệu quan trọng mà còn là công cụ thiết yếu giúp kết nối khách hàng và đội ngũ phát triển phần mềm. Một SRS rõ ràng và chi tiết sẽ đảm bảo rằng mọi yêu cầu của khách hàng được hiểu đúng và thực hiện chính xác, giúp giảm thiểu rủi ro và đảm bảo chất lượng dự án.
Hãy coi SRS là công cụ quan trọng để đảm bảo sự thành công của mọi dự án phần mềm. Đối với mỗi BA, việc hiểu rõ và áp dụng SRS vào công việc hàng ngày sẽ giúp bạn đạt được mục tiêu phát triển sản phẩm phần mềm tốt nhất cho khách hàng.
Hãy tham gia cộng đồng của chúng tôi tại “Học BA từ số 0” để nhận các chia sẻ xung quanh nghề BA thực chiến, thiết thực và hữu ích nhé!
