Tài liệu mô tả yêu cầu kinh doanh - BRD
BRD là viết tắt của Business Requirement Document. Đây là một loại tài liệu dùng để mô tả các yêu cầu kinh doanh của sản phẩm hoặc quy trình, cũng như kết quả cuối cùng dự kiến từ sản phẩm hoặc quy trình đó. Nói đơn giản, BRD là tập hợp các yêu cầu kinh doanh và yêu cầu khác từ các bên liên quan đến dự án.
Hiểu rõ khái niệm này sẽ giúp bạn phân biệt BRD, FRS và SRS là gì.
Nội dung của tài liệu mô tả yêu cầu kinh doanh chủ yếu tập trung vào việc giải đáp câu hỏi “giải pháp kinh doanh là gì”, thay vì “làm thế nào để đạt được giải pháp kinh doanh”. Do đó, nó chủ yếu tập trung vào các yêu cầu kinh doanh.
Tài liệu BRD được tạo ra với sự hợp tác của nhóm dự án bao gồm:
- BA – Business Analyst;
- Khách hàng;
- Các chuyên gia về chủ đề sản phẩm;
- Đối tác kinh doanh.
Tài liệu này cũng là một công cụ giao tiếp cho các bên liên quan và nhà cung cấp dịch vụ bên ngoài.
Tài liệu mô tả yêu cầu hệ thống – SRS có ý nghĩa như thế nào?
SRS hay Software Requirements Specification là một tài liệu chi tiết mô tả về hệ thống. Nó nêu rõ cách hệ thống hoàn chỉnh phải hoạt động và liệt kê các yêu cầu về:
- Phần cứng;
- Phần mềm;
- Chức năng;
- Hành vi của hệ thống.
Trong SRS, chỉ tập trung vào các yêu cầu về hành vi mà không xem xét các vấn đề kỹ thuật hay thiết kế.
Đặc tả yêu cầu hệ thống (SRS) thường bao gồm những nội dung chính sau:
- Quan điểm về sản phẩm;
- Chức năng của sản phẩm;
- Đặc điểm người dùng;
- Ràng buộc chung;
- Giả định và phụ thuộc;
- Yêu cầu giao diện bên ngoài;
- Yêu cầu chức năng;
- Lớp/Đối tượng;
- Yêu cầu phi chức năng;
- Yêu cầu nghịch đảo;
- Ràng buộc thiết kế;
- Sơ đồ trình tự;
- Sơ đồ luồng dữ liệu (DFD);
- Sơ đồ chuyển trạng thái (STD);
- Quy trình quản lý thay đổi.
Tài liệu mô tả yêu cầu chức năng hoặc thành phần – FRS
Sau khi đã hiểu sơ qua về BRD và SRS là gì, chúng ta tiếp tục tìm hiểu thêm về FRS.
FRS – Function Requirement Specification là tài liệu mô tả các yêu cầu chức năng hoặc các thành phần của hệ thống, bao gồm các hoạt động dự kiến của hệ thống như:
- Dữ liệu;
- Hoạt động;
- Đầu vào, đầu ra;
- Các thuộc tính của hệ thống.
Trong BRD, các yêu cầu được trình bày ở mức độ tổng quan và trừu tượng hơn. Trái lại, trong FRS, mỗi yêu cầu được miêu tả cụ thể và chi tiết hơn rất nhiều. Điều này giúp người đọc hiểu rõ từng khía cạnh của mỗi yêu cầu. Vì thế, FRS trở thành tài liệu yêu cầu chức năng mang tính kỹ thuật, chính xác và chi tiết hơn.
Vì tính chất kỹ thuật quan trọng, các tài liệu FRS được các nhà phát triển, người thử nghiệm và các bên liên quan kinh doanh của dự án sử dụng một cách đồng nhất.
So sánh chi tiết giữa Tài liệu BRD, FRS và SRS trong lĩnh vực kinh doanh
Khi tiến hành phân tích kinh doanh và nghiên cứu cách để ghi lại tất cả các yêu cầu khác nhau của dự án, chúng ta thường gặp các thuật ngữ BRD, FRS và SRS rất thường xuyên.
Việc phân tích kinh doanh được thực hiện dựa trên các tiêu chuẩn và khung được xác định cụ thể. Người thực hiện phân tích cần tuân theo các tiêu chuẩn và chuẩn mực này để thực hiện phân tích yêu cầu một cách hiệu quả. Tuy nhiên, không có hướng dẫn nội dung cụ thể nào để tham khảo khi xây dựng BRD, SRS và FRS.
Do đó, các tổ chức thường phải điều chỉnh các tài liệu yêu cầu này dựa trên quy trình và tiêu chuẩn của họ, nguồn lực có sẵn và loại dự án. Để hiểu rõ hơn về sự khác biệt và cách sử dụng của BRD, FRS và SRS, chúng ta sẽ tìm hiểu chi tiết trong nội dung so sánh dưới đây.
Bảng so sánh chi tiết
Nếu bạn đang tìm kiếm những thông tin so sánh tổng quan giữa 3 loại tài liệu yêu cầu kinh doanh này, bạn có thể tham khảo các ý chính sau:
- Thứ nhất: Tài liệu BRD hay tài liệu mô tả yêu cầu kinh doanh là tài liệu chứa các yêu cầu kinh doanh 'cấp cao', quan trọng, và tổng quan nhất của dự án.
- Thứ hai: Về SRS là gì, tài liệu này sẽ chứa các yêu cầu chức năng mà không đi vào chi tiết.
- Thứ ba: Đối với tài liệu FRS, nó lại mô tả chi tiết các yêu cầu chức năng với các luồng dữ liệu và sơ đồ UML.
So sánh chi tiết
Tiêu chí so sánh | Business Requirement Document BDR | Software Requirements Specification SRS | Function Requirement Specification FRS |
Tên gọi khác | Không có | Thông số kỹ thuật yêu cầu phần mềm (PRD) và đặc tả yêu cầu hệ thống | Tài liệu thông số chức năng (FSD), Tài liệu thông số sản phẩm (PSD), Thông số chức năng (FS) |
Người thực hiện | BA – Nhà phân tích kinh doanh | Nhà phân tích kinh doanh Nhà phân tích hệ thống | Nhà phân tích kinh doanh Nhà phân tích hệ thống Trưởng nhóm triển khai |
Nội dung | Yêu cầu kinh doanh cấp cao và yêu cầu của các bên liên quan | Yêu cầu chi tiết về chức năng, yêu cầu phi chức năng và các yêu cầu cụ thể khác | Yêu cầu chức năng chi tiết, luồng dữ liệu và sơ đồ UML |
Được sử dụng bởi | Quản lý cấp cao và cấp trung | Người quản lý dự án, doanh nghiệp vừa và nhỏ, trưởng nhóm kỹ thuật và triển khai | Trưởng nhóm kỹ thuật, nhóm phát triển và nhóm thử nghiệm |
Giai đoạn thực hiện | Giai đoạn khởi đầu dự án | Giai đoạn lập dự án | Giai đoạn lập dự án |
Mục tiêu, ý nghĩa | “Tại sao” các yêu cầu đang được thực hiện | Kế hoạch yêu cầu cái gì phải có để đáp ứng nhu cầu kinh doanh phần mềm | Làm thế nào để biết chính xác hệ thống dự kiến sẽ hoạt động như thế nào |
Tài liệu yêu cầu kinh doanh (BRD)
Tài liệu mô tả yêu cầu kinh doanh là tập hợp các yêu cầu mô tả các nhu cầu kinh doanh và yêu cầu từ các bên liên quan (nó ghi lại những yêu cầu mà doanh nghiệp quan tâm thay vì ghi lại các yêu cầu kỹ thuật).
Người thực hiện tài liệu
Sau khi phân tích công ty khách hàng và tương tác với các bên liên quan, BRD luôn được chuẩn bị bởi nhà phân tích kinh doanh của dự án. Sau khi BRD được chuẩn bị, thường sẽ được khách hàng xem xét và phê duyệt để đảm bảo đáp ứng chính xác kỳ vọng của doanh nghiệp và các bên liên quan chính.
Đối với FRS và SRS là gì cũng có những người thực hiện tương ứng.
Nội dung và ý nghĩa của tài liệu
BRD thường là một trong những tài liệu đầu tiên được tạo ra trong quá trình dự án. Nó mô tả các mục tiêu cấp cao mà công ty đang cố gắng đạt được hoặc các nhu cầu mà họ đang cố gắng đáp ứng bằng cách phát triển dịch vụ hoặc sản phẩm.
Tài liệu mô tả yêu cầu kinh doanh cũng bao gồm nhu cầu của các bên liên quan cụ thể, những người sẽ tương tác với sản phẩm hoặc dịch vụ cuối cùng. Để đáp ứng các yêu cầu, cải tiến và thay đổi trong tương lai của dự án, tất cả phải dựa trên các mục tiêu và nhu cầu được liệt kê trong BRD.
Các đối tượng chính của BRD bao gồm dự án, nhà tài trợ, quản lý cấp cao, quản lý cấp trung và nhà phân tích. Hãy nhớ phân biệt với nội dung và ý nghĩa của FRS và SRS là gì nhé.
Cần chuẩn bị những gì để tạo một BRD?
Trước khi tạo tài liệu yêu cầu kinh doanh, có một số bước bạn cần thực hiện:
- Bạn cần xác định nhu cầu của công ty/tổ chức.
- Thu hút tất cả các bên liên quan tham gia.
- Xác định các giai đoạn của dự án.
- Thiết lập các tiêu chuẩn/điểm chuẩn cho tất cả các yêu cầu của dự án.
- Có sẵn một quy trình để theo dõi lịch trình và đo lường các cột mốc quan trọng.
- Sử dụng một mẫu phù hợp.
Tài liệu đặc tả yêu cầu phần mềm (SRS)
Sau khi xác định được “lý do” dự án được thực hiện (qua BRD), bạn cần ghi lại các yêu cầu “Cái gì” phải được thực hiện để đáp ứng nhu cầu của doanh nghiệp. Bạn cần hiểu SPS là gì và nhận thức những khác biệt của tài liệu đặc tả yêu cầu phần mềm so với hai tài liệu khác.
Người thực hiện tài liệu
SRS hay Đặc tả yêu cầu phần mềm là tài liệu được chuẩn bị bởi một nhóm phân tích hệ thống. Tài liệu này mô tả:
- Phần mềm sẽ được phát triển như thế nào;
- Mục đích kinh doanh chính và;
- Chức năng của sản phẩm cùng với cách thức thực hiện các chức năng cốt lõi.
Nội dung và ý nghĩa của tài liệu SRS
Tài liệu SRS đóng vai trò cơ bản trong mọi dự án, với khung mẫu mà từng thành viên trong nhóm phải tuân thủ. Đây cũng là nền tảng của hợp đồng với các bên liên quan như người dùng và khách hàng, vì nó bao gồm tất cả chi tiết về:
- Chức năng của sản phẩm trong tương lai;
- Cách hoạt động của sản phẩm.
Tài liệu SRS được các nhà phát triển phần mềm sử dụng rộng rãi trong quá trình phát triển sản phẩm hoặc chương trình.
Vậy tài liệu SRS là gì?
SRS bao gồm cả yêu cầu chức năng và phi chức năng cũng như các trường hợp sử dụng. Một tài liệu SRS hoàn hảo không chỉ xem xét cách phần mềm tương tác với các thành phần khác hay khi tích hợp vào phần cứng, mà còn quan tâm đến người dùng tiềm năng và cách họ tương tác với phần mềm. Nó cũng bao gồm các tham chiếu đến bảng và sơ đồ để hiểu rõ về mọi chi tiết liên quan đến sản phẩm.
Tài liệu SRS giúp các thành viên trong nhóm từ các bộ phận khác nhau đồng nhất quan điểm và đảm bảo đáp ứng tất cả các yêu cầu. Ngoài ra, tài liệu này cũng giúp giảm thiểu chi phí và thời gian phát triển phần mềm.
Cách xây dựng Đặc tả yêu cầu phần mềm – SRS là gì?
Mẫu tài liệu SRS đầy đủ trong thử nghiệm là một trong những tài liệu quan trọng, được tham khảo nhiều lần bởi các nhà phát triển phần mềm và kỹ sư kiểm thử trong dự án.
Dưới đây là các bước để tạo ra tài liệu SRS vững chắc:
- 1. Tạo dàn ý hoặc sử dụng mẫu có sẵn để làm nổi bật mục đích của tài liệu.
2. Nói về mục đích của sản phẩm, bao gồm đối tượng mục tiêu, mục đích sử dụng và phạm vi sản phẩm.
3. Xác định sản phẩm dự định xây dựng, bao gồm nhu cầu, giả định và sự phụ thuộc của người dùng.
4. Nói về các yêu cầu chức năng và phi chức năng cụ thể, kể cả các thông số kỹ thuật giao diện bên ngoài và yêu cầu hệ thống.
5. Gửi tài liệu cho các bên liên quan trong dự án và nhận được sự chấp thuận của họ.
Tài liệu đặc tả yêu cầu chức năng (FRS)
Cuối cùng nhưng không kém phần quan trọng là tài liệu FRS.
FRS hay đặc tả yêu cầu chức năng là tài liệu mô tả các chức năng mà phần mềm hoặc sản phẩm phải thực hiện. Thực tế, nó là sự liên kết các hoạt động cần thiết để phát triển sản phẩm từ đầu đến cuối. FRS giải thích chi tiết về cách các thành phần sẽ hoạt động trong quá trình tương tác với người dùng.
Người thực hiện tài liệu
Tài liệu này được tạo ra bởi các nhà phát triển và kỹ sư phần mềm có trình độ, kết quả của sự hợp tác giữa người thử nghiệm và nhà phát triển. Sự khác biệt so với SRS là FRS không bao gồm các trường hợp sử dụng và có thể chứa sơ đồ và bảng biểu, tuy nhiên không bắt buộc.
Nội dung và ý nghĩa của tài liệu FRS
Tài liệu chi tiết nhất về cách hoạt động của phần mềm, bao gồm các khía cạnh kinh doanh, sự tuân thủ, yêu cầu bảo mật. FRS cần đáp ứng tất cả yêu cầu trong SRS và BRS, giúp nhà phát triển và kiểm thử hiểu rõ sản phẩm và các trường hợp thử nghiệm.
Cách chuẩn bị bản đặc tả yêu cầu chức năng
Cùng với BRS và SRS, FRS là trụ cột trong vòng đời phát triển và thử nghiệm phần mềm. Điều quan trọng là phải biết cách thực hiện mẫu FRS đầy đủ.
- Giới thiệu (bao gồm phạm vi dự án và tài liệu tham khảo)
- Mô tả chung (bao gồm tầm nhìn, giả định và hạn chế về sản phẩm)
- Yêu cầu cụ thể (bao gồm các thuộc tính hệ thống và yêu cầu cơ sở dữ liệu)
- Các trường hợp sử dụng chi tiết ở định dạng văn bản hoặc sơ đồ
- Câu chuyện của người dùng
- Cấu trúc phân chia công việc hoặc phân rã chức năng của phần mềm
- Tài liệu và nguyên mẫu phần mềm và thiết kế
Kết luận
Tất cả ba loại tài liệu SRS, FRS và BRD trong kiểm thử phần mềm là các khía cạnh không thể thiếu trong quy trình kiểm thử phần mềm hiệu quả và bền vững. Việc nhận biết và hiểu được FRS, BRD và SRS là gì sẽ trở thành một phần không thể thiếu trong quy trình đảm bảo chất lượng của bạn.