BRD, PRD và SRS khác nhau thế nào? PO cần viết cái nào?

Ba tài liệu yêu cầu trả lời ba câu hỏi khác nhau: vì sao làm, làm gì cho ai, và hệ thống phải chạy ra sao. Bài này giúp bạn biết khi nào cần cái nào.

Viết bởi Phan Lâm Duy Khôi

BRD nói vì sao doanh nghiệp cần làm và mục tiêu kinh doanh, PRD nói sản phẩm làm gì cho ai và đo thành công thế nào, còn SRS mô tả chi tiết hệ thống phải hoạt động ra sao. Ở nhiều team, PO giữ PRD và backlog, góp ý cho BRD và rà SRS, nhưng tên gọi và người viết thay đổi theo công ty.

BRD, PRD và SRS khác nhau thế nào?

BRD trả lời vì sao doanh nghiệp nên làm một việc, PRD trả lời sản phẩm sẽ làm gì cho ai và đo thành công ra sao, còn SRS mô tả chi tiết hệ thống phải hoạt động thế nào. Ở nhiều team, PO giữ PRD và backlog, góp ý cho BRD và rà SRS, nhưng tên gọi và người viết khác nhau tùy công ty.

Đây là tình huống minh họa. Bạn vừa nhận vai trò PO ở một công ty phần mềm làm dự án cho khách. Buổi đầu, trưởng nhóm nói: “Khách gửi BRD rồi, em viết PRD đi, bên BA sẽ làm SRS sau.” Bạn gật đầu, rồi về mở Google gõ “BRD là gì”. Kết quả trả về ba mẫu khác nhau, mỗi mẫu có mục lục gần giống nhau, và bạn không biết phần nào là việc của mình.

Một tuần sau, BA gửi bản SRS nháp đầu tiên. Bạn mở cả ba file: BRD của khách, PRD bạn đang viết và SRS nháp. Cả ba đều có mục “phạm vi”, cả ba đều nhắc tới “người dùng”, và con số mục tiêu trong BRD khác với con số trong bản PRD bạn đang viết. Câu hỏi thật không còn là “mẫu nào đúng” nữa. Câu hỏi là: mỗi tài liệu dùng để quyết định điều gì, ai đọc nó, và bạn cần viết tới đâu.

Vì sao ba loại tài liệu này dễ bị nhầm?

Nhầm lẫn này không phải do bạn đọc chưa kỹ. Có ít nhất bốn lý do khiến ranh giới giữa BRD, PRD và SRS rất mờ.

  • Tên gọi không thống nhất. Có công ty gọi mọi tài liệu yêu cầu là “spec”, có nơi dùng FRD thay cho SRS, có nơi gọi PRD là “tài liệu tính năng”. Cùng một tên có thể chứa nội dung khác nhau ở hai công ty.
  • Chuẩn quốc tế dùng tên khác thực tế. Bộ chuẩn ISO/IEC/IEEE 29148 về kỹ thuật yêu cầu dùng các tên như BRS (business requirements specification) và SRS (software requirements specification). Nhiều team lại quen gọi là BRD, còn PRD thì xuất phát từ cách làm product management hơn là từ chuẩn này.
  • Ba tài liệu nói về cùng một việc ở ba độ sâu. Chúng đều có phạm vi, người dùng và mục tiêu, nên nhìn mục lục thì giống nhau. Khác nhau nằm ở câu hỏi mỗi tài liệu phải trả lời và người dùng nó để ra quyết định.
  • Vai trò cũng chồng lên nhau. PO, PM và BA cùng làm việc với yêu cầu, nên ai viết tài liệu nào phụ thuộc vào cách công ty chia việc. Nếu bạn chưa rõ ranh giới giữa ba vai trò này, bài so sánh PO, PM và BA sẽ giúp bạn trước.

Thêm vào đó, nhiều team làm agile không viết đủ ba tài liệu. Atlassian mô tả PRD trong agile là một trang tập trung vào hiểu chung, nhu cầu khách hàng và sự linh hoạt, tránh đặc tả quá chi tiết. Phần chi tiết được chia nhỏ vào backlog dưới dạng user story. Vì vậy, khi đọc tin tuyển dụng hay nghe ai đó nói “viết SRS”, bạn nên hỏi lại họ đang dùng tên đó cho nội dung gì.

BRD, PRD, SRS và FRD là gì?

Cách dễ nhớ nhất là gắn mỗi tài liệu với một câu hỏi. BRD hỏi “vì sao”, PRD hỏi “làm gì, cho ai”, SRS hỏi “hệ thống phải chạy thế nào”. FRD là một phần của câu hỏi cuối, chỉ tập trung vào chức năng.

So sánh bốn loại tài liệu yêu cầu (vai trò người viết là cách chia việc hay gặp, không phải quy định)
Tài liệuTrả lời câu hỏiNgười đọc chínhAi hay viếtMức chi tiết và lúc dùng
BRD: business requirements documentVì sao doanh nghiệp cần làm, mục tiêu kinh doanh là gì, phạm vi tổng thể tới đâuBan lãnh đạo, người tài trợ dự án, khách hàng thuê làmBộ phận kinh doanh, BA, đôi khi PMThấp. Dùng lúc xin duyệt dự án, ngân sách hoặc ký hợp đồng
PRD: product requirements documentSản phẩm giải quyết vấn đề gì cho ai, làm gì trong lần này, đo thành công thế nàoDesigner, kỹ sư, stakeholder liên quanPO hoặc PMVừa. Dùng trước khi chia việc thành user story, cập nhật trong lúc làm
SRS: software requirements specificationHệ thống phải làm gì, xử lý dữ liệu và lỗi ra sao, đạt chuẩn hiệu năng, bảo mật nàoKỹ sư, kiểm thử viên, bên tích hợpBA, kỹ sư hoặc system analyst, PO rà lạiCao. Dùng khi có hợp đồng, kiểm định, nhiều hệ thống tích hợp
FRD: functional requirements documentChỉ phần chức năng: hệ thống phải làm những gìKỹ sư, kiểm thử viênBACao, nhưng thường không gồm yêu cầu phi chức năng

Vài điểm nên biết thêm về từng loại.

  • BRD đứng ở góc nhìn doanh nghiệp. Nó nêu vấn đề kinh doanh, mục tiêu đo được, các bên liên quan, ràng buộc về ngân sách, thời hạn hay pháp lý. BRD tốt không nhắc tới màn hình. Trong chuẩn 29148, tài liệu tương ứng gọi là BRS, mô tả yêu cầu kinh doanh hoặc nhiệm vụ của tổ chức.
  • PRD đứng ở góc nhìn người dùng và sản phẩm. Nó nói ai đang gặp vấn đề, sản phẩm sẽ đổi điều gì cho họ, phạm vi lần này và phần cố ý không làm. Atlassian gợi ý PRD đóng vai trò “trang đích” cho mọi thứ liên quan tới một nhóm vấn đề, từ mục tiêu, giả định tới user story và thiết kế.
  • SRS đứng ở góc nhìn hệ thống. Nó gồm yêu cầu chức năng (hệ thống phải làm gì) và yêu cầu phi chức năng (nhanh tới đâu, an toàn ra sao, chịu tải bao nhiêu). Chuẩn cổ điển cho SRS là IEEE 830-1998. Chuẩn này đã được thay bằng ISO/IEC/IEEE 29148 từ năm 2011, và 29148 có bản sửa năm 2018.
  • FRD thường được xem là một phần của SRS, chỉ chứa yêu cầu chức năng. Đây là cách gọi trong thực tế làm dự án, không phải một tài liệu riêng trong chuẩn 29148, nên mỗi công ty có thể hiểu hơi khác nhau.

Nếu bạn làm ở công ty sản phẩm theo agile, có thể bạn chỉ gặp một thứ: một PRD ngắn cộng với backlog. Nếu bạn làm ở công ty outsourcing, ngân hàng hay dự án nhà nước, bạn dễ gặp đủ BRD, SRS và các biên bản nghiệm thu đi kèm.

PO cần viết tài liệu nào?

Scrum Guide 2020 không nhắc tới BRD, PRD hay SRS. Nó chỉ nói PO chịu trách nhiệm quản lý Product Backlog hiệu quả, có thể giao người khác làm một phần, nhưng trách nhiệm vẫn là của PO. Vì vậy, thay vì hỏi “PO phải viết tài liệu nào”, câu hỏi hữu ích hơn là: tài liệu nào giúp backlog của bạn rõ, đúng và được ưu tiên đúng.

Một cách làm là đi qua bốn bước dưới đây trước khi mở bất kỳ mẫu nào.

Bốn bước chọn đúng mức tài liệu Bắt đầu từ người đọc và quyết định cần đưa ra, không bắt đầu từ mẫu.
  1. Hỏi người đọc: Ai sẽ dùng tài liệu này để quyết định gì
  2. Tìm thứ đã có: BRD, hợp đồng, PRD cũ, backlog hiện tại
  3. Chọn mức: Vì sao, làm gì cho ai, hay hệ thống chạy ra sao
  4. Viết phần mình, link phần khác: Mỗi thông tin chỉ nằm ở một chỗ

Khi mục tiêu, phạm vi hoặc quy tắc thay đổi, sửa ở đúng một tài liệu rồi kiểm tra các link trỏ tới nó.

Bước 2 rất dễ bị bỏ qua. Nhiều thông tin bạn định viết vào PRD đã nằm sẵn trong BRD hoặc trong hợp đồng. Chép lại sẽ tạo ra hai bản, và sớm muộn hai bản sẽ lệch nhau. Link tới tài liệu gốc thì chỉ có một chỗ phải sửa.

Ở bước 3, bộ lọc dưới đây giúp bạn quyết định cần tài liệu nào cho một yêu cầu cụ thể. Mỗi câu trả lời “có” đưa bạn đi tiếp. Câu trả lời “không” cho biết tài liệu nào còn thiếu.

Yêu cầu này cần tài liệu nào? Đi từ trên xuống. Dừng ở câu đầu tiên bạn trả lời “không”, bổ sung tài liệu đó rồi quay lại.

Có một yêu cầu mới cần ghi lại

  1. Lý do kinh doanh, ngân sách và người duyệt đã rõ chưa? Cần BRD hoặc một trang business case trước. Ở nhiều team, bộ phận kinh doanh hoặc BA dẫn phần này, PO góp phần vấn đề người dùng.
  2. Team đã thống nhất vấn đề, người dùng, phạm vi và cách đo thành công? Viết PRD, ưu tiên bản một trang. Ở nhiều team, đây là phần PO giữ.
  3. Developers đã đủ thông tin để ước lượng và kiểm thử từ user story và tiêu chí chấp nhận? Bổ sung đặc tả chi tiết (SRS hoặc FRD) cho riêng phần phức tạp, viết cùng BA và Developers.
  4. Backlog hiện tại đã đủ cho mọi bên cần đặc tả chính thức (nếu có), như hợp đồng, kiểm định hay đối tác tích hợp? Có bên cần đặc tả chính thức mà backlog chưa đủ: viết SRS theo mẫu bên đó yêu cầu, ví dụ theo cấu trúc của ISO/IEC/IEEE 29148.

Dùng PRD ngắn và backlog. Không cần thêm tài liệu cho yêu cầu này.

Bộ lọc này cho thấy một điều quan trọng: SRS không phải bước bắt buộc sau PRD. Với nhiều tính năng vừa và nhỏ, user story kèm tiêu chí chấp nhận kiểm được là đủ chi tiết. SRS đáng viết khi có một người đọc thật sự cần nó: Developers khi phần nào đó quá phức tạp để gói trong user story, kiểm thử viên của khách hàng, đơn vị kiểm định hay đội tích hợp ở công ty khác. Bài PRD một trang có thêm bộ lọc “Bạn có cần một spec đầy đủ không?”: với thanh toán, pháp lý, dữ liệu cá nhân hay thay đổi khó hoàn tác, nên viết spec đầy đủ và giữ trang một trang làm điểm vào.

Nếu PRD là phần của bạn, hãy bắt đầu từ bài hướng dẫn PRD một trang, rồi chia việc thành user story và viết tiêu chí chấp nhận cho từng story.

Ví dụ: một yêu cầu viết ở ba mức

Ví dụ minh họa dưới đây dùng một cửa hàng trà online giả định tên Trà Lá. Bộ phận vận hành than rằng nhiều đơn giao thất bại vì khách không có nhà. Yêu cầu ban đầu chỉ là một câu: “Cho khách chọn khung giờ giao hàng.” Mọi con số trong bảng đều là số giả định để minh họa.

Cùng yêu cầu “chọn khung giờ giao hàng” ở ba mức tài liệu (ví dụ minh họa, số giả định)
Tài liệuCâu hỏi chínhCâu viết mẫuKhông nên viết ở đây
BRDVì sao Trà Lá cần làm việc này?Đơn giao thất bại lần đầu đang ở mức 8% (số giả định), mỗi lần giao lại tốn thêm phí vận chuyển. Mục tiêu: dưới 5% sau ba tháng ở hai thành phố đầu tiên. Ràng buộc: đối tác giao hàng phải nhận được khung giờ.Danh sách khung giờ, màn hình chọn giờ
PRDLàm gì, cho ai, đo thế nào?Khách đi làm giờ hành chính ở nội thành muốn nhận hàng khi có nhà. Lần này: chọn một trong ba khung giờ lúc thanh toán. Không làm: đổi khung giờ sau khi đơn đã xuất kho. Đo: tỷ lệ giao thành công lần đầu của đơn có chọn khung giờ.Tên trường dữ liệu, thiết kế API
SRSHệ thống phải chạy ra sao?Hệ thống hiển thị ba khung giờ 9h đến 12h, 13h đến 17h, 18h đến 21h. Khung giờ bị khóa khi đủ số đơn tối đa đã cấu hình hoặc khi còn dưới 2 giờ trước giờ bắt đầu. Danh sách khung giờ tải xong trong 1 giây (số giả định). Khi API đối tác giao hàng lỗi, ẩn lựa chọn khung giờ và cho đặt giao thường.Lý do kinh doanh, chiến lược mở rộng

Để ý vài điều. Mỗi tài liệu có một con số riêng và con số đó phục vụ người đọc của nó. BRD dùng tỷ lệ giao thất bại để lãnh đạo quyết có đầu tư hay không. PRD dùng tỷ lệ giao thành công lần đầu để team biết tính năng có ích sau khi ra mắt. SRS dùng thời gian tải và điều kiện khóa để kỹ sư xây và kiểm thử viên kiểm.

Phần “không làm” trong PRD và phần xử lý lỗi trong SRS cũng không chép lại nhau. PRD nói phạm vi bằng lời của người dùng. SRS nói cùng phạm vi đó bằng hành vi hệ thống. Nếu Trà Lá là một team nhỏ làm agile, phần SRS ở đây có thể nằm luôn trong tiêu chí chấp nhận của hai, ba user story mà không cần file riêng.

Nếu là FRD, tài liệu sẽ giữ phần khung giờ, điều kiện khóa và cách xử lý khi API lỗi, nhưng bỏ mốc 1 giây. Mốc đó là yêu cầu phi chức năng, nên phải được ghi ở chỗ khác, ví dụ trong một danh sách yêu cầu chung của hệ thống.

Mẫu: phần nào nằm ở tài liệu nào?

Mẫu dưới đây không phải một tài liệu để điền. Nó là bản đồ để bạn kiểm tra mỗi thông tin đang nằm đúng chỗ chưa. Bạn copy vào trang đầu của dự án, đánh dấu phần nào đã có, có ở tài liệu nào và ai giữ. Mẫu PRD chi tiết đã có trong bài PRD một trang, nên ở đây chỉ liệt kê tên phần.

Bản đồ tài liệu yêu cầu của dự án
Quy tắc: mỗi thông tin chỉ nằm ở một tài liệu. Các tài liệu khác link tới nó.

BRD (vì sao làm) | Người giữ: [tên] | Link: [link]
[ ] Vấn đề kinh doanh và bối cảnh
[ ] Mục tiêu kinh doanh đo được, kèm nguồn số
[ ] Phạm vi tổng thể và phần ngoài phạm vi
[ ] Các bên liên quan và người duyệt
[ ] Ràng buộc: ngân sách, thời hạn, pháp lý

PRD (làm gì, cho ai) | Người giữ: [tên PO hoặc PM] | Link: [link]
[ ] Vấn đề người dùng và nhóm người dùng
[ ] Mục tiêu sản phẩm và cách đo
[ ] Phạm vi lần này và phần không làm
[ ] Luồng chính
[ ] Câu hỏi mở, rủi ro, phụ thuộc

SRS hoặc FRD (hệ thống chạy ra sao) | Người giữ: [tên] | Link: [link] | Cần không: [có/không, vì sao]
[ ] Yêu cầu chức năng: hệ thống phải làm gì
[ ] Quy tắc nghiệp vụ và dữ liệu
[ ] Giao tiếp với hệ thống khác
[ ] Yêu cầu phi chức năng: hiệu năng, bảo mật, khả dụng
[ ] Xử lý lỗi và trường hợp biên
[ ] Cách kiểm chứng từng yêu cầu

Backlog | Người giữ: [tên PO] | Link: [link]
[ ] User story cho phạm vi lần này
[ ] Tiêu chí chấp nhận cho từng story

Thông tin đang nằm ở hai nơi: [liệt kê, chọn một nơi giữ, nơi kia đổi thành link]

Dòng cuối của mẫu là dòng đáng dùng nhất. Mỗi lần thấy cùng một con số hay một quy tắc xuất hiện ở hai tài liệu, hãy chọn một nơi giữ và đổi nơi kia thành link. Việc nhỏ này giúp tránh được nhiều cuộc tranh luận kiểu “nhưng tài liệu kia ghi khác”.

Ở mục “cách kiểm chứng”, các mẫu 29148 trong ReqView có một thuộc tính phương pháp kiểm chứng cho từng yêu cầu, gồm kiểm thử, trình diễn, xem xét và phân tích. Bạn không cần dùng đủ bốn cách. Chỉ cần mỗi yêu cầu có câu trả lời cho câu hỏi “làm sao biết nó đạt”.

Những lỗi dễ gặp khi viết tài liệu yêu cầu

  • Viết đủ ba tài liệu cho mọi tính năng. Tài liệu nhiều cho cảm giác chắc chắn, nhưng mỗi tài liệu thêm là một chỗ phải cập nhật. Hãy dùng bộ lọc ở trên và chỉ viết tài liệu có người đọc thật sự cần.
  • Chép cùng một thông tin vào nhiều nơi. Mục tiêu trong BRD, PRD và slide trình bày lệch nhau là chuyện dễ xảy ra. Một nơi giữ, các nơi khác link tới.
  • Để PRD thành SRS. PO tự viết tên trường dữ liệu, cấu trúc API hay cách lưu trữ. Những phần này kỹ sư làm tốt hơn, và viết sẵn sẽ làm team mất chỗ đóng góp.
  • Tin vào tên tài liệu thay vì nội dung. Công ty này gọi là SRS, công ty kia gọi là spec. Khi nhận một mẫu có sẵn, hãy hỏi người đọc của nó là ai và họ dùng nó để quyết định gì.
  • Bỏ quên yêu cầu phi chức năng. Tốc độ, bảo mật, phân quyền, khả năng chịu tải không hiện trên màn hình nên dễ bị quên, cho tới khi hệ thống chậm vào giờ cao điểm.
  • Viết yêu cầu không kiểm được. “Hệ thống chạy nhanh” hay “giao diện thân thiện” không giúp ai biết khi nào là đạt. Mỗi yêu cầu cần một con số, một điều kiện hoặc một kết quả nhìn thấy được.

Nếu bạn chưa quen làm việc với kỹ sư khi rà SRS, hãy đọc thêm bài về cách làm việc với dev khi không biết code. Bạn không cần hiểu cách hệ thống được xây, nhưng cần hỏi được nó có đúng với vấn đề và phạm vi đã thống nhất không.

Tóm tắt

  • BRD trả lời vì sao doanh nghiệp nên làm. PRD trả lời làm gì cho ai và đo thành công thế nào. SRS trả lời hệ thống phải chạy ra sao. FRD là phần chức năng của SRS.
  • Tên gọi và người viết khác nhau theo công ty. Chuẩn ISO/IEC/IEEE 29148, thay cho IEEE 830, dùng tên BRS và SRS.
  • Ở nhiều team, PO giữ PRD và backlog, góp ý cho BRD và rà SRS. Scrum Guide chỉ quy định PO chịu trách nhiệm Product Backlog, không quy định loại tài liệu.
  • Chọn tài liệu theo người đọc và quyết định cần đưa ra. Nhiều team agile chỉ cần PRD ngắn cộng user story và tiêu chí chấp nhận.
  • Mỗi thông tin chỉ nằm ở một tài liệu, các tài liệu khác link tới nó.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

Câu hỏi thường gặp

BRD là gì?

BRD (business requirements document) là tài liệu yêu cầu kinh doanh: nêu vấn đề của doanh nghiệp, mục tiêu cần đạt, phạm vi tổng thể và các ràng buộc như ngân sách hay thời hạn. Nó trả lời câu hỏi vì sao nên làm, chưa đi vào màn hình hay cách hệ thống chạy.

PRD và SRS khác nhau thế nào?

PRD mô tả sản phẩm giải quyết vấn đề gì cho ai, phạm vi và cách đo thành công. SRS mô tả chi tiết hệ thống phải làm gì và đạt tiêu chuẩn nào, gồm yêu cầu chức năng và phi chức năng, đủ để kỹ sư xây và kiểm thử viên kiểm.

Product Owner có phải viết SRS không?

Ở nhiều team, PO không viết SRS một mình. SRS có thể do BA hoặc Developers dẫn, còn PO rà để chắc nó khớp với vấn đề, phạm vi và thứ tự ưu tiên. Trong team agile nhỏ, phần chi tiết này có thể nằm ở user story và tiêu chí chấp nhận thay vì một SRS riêng.

Nguồn kiểm tra

Bài liên quan