Phân biệt BRD, SRS, FRS chi tiết và rõ ràng trong BA

Phân biệt BRD, SRS, FRS chi tiết và rõ ràng trong BA

13/05/2024

538

0

Chia sẻ lên Facebook
Phân biệt BRD, SRS, FRS chi tiết và rõ ràng trong BA

Phân biệt BRD, SRS, FRS như thế nào? Ban lãnh đạo, người dùng cuối sẽ đọc loại tài liệu nào? Còn Developer, Tester, Business Analyst sẽ đọc loại tài liệu nào? Nội dung chính được đề cập trong các tài liệu này là gì? Nếu bạn mới bước chân vào lĩnh vực công nghệ thông tin và còn mơ hồ về những khái niệm này, hãy đọc bài viết sau đây của Topchuyengia để có câu trả lời chi tiết nhất.

BRD, SRS, FRS là gì?

Phân biệt BRD, SRS, FRS

Khi phân biệt BRD, SRS, FRS, có thể thấy cả ba đều có mục tiêu chung là mô tả những yêu cầu “phải có” khi phát triển phần mềm. Tuy nhiên, để thấy rõ sự khác biệt, hãy cùng Topchuyengia tìm hiểu khái niệm của từng loại yêu cầu qua bài viết dưới đây.

Business Requirement Document - BRD

Business Requirement Document (hay BRD, tạm dịch: Tài liệu yêu cầu kinh doanh) là tài liệu đầu tiên trong quy trình phát triển của một sản phẩm hoặc dịch vụ. Tài liệu này mô tả một cách chi tiết và chính xác về chiến lược của công ty cũng như những mục tiêu cao cả mà họ đang nỗ lực để đạt được trong tương lai bằng cách tạo ra một sản phẩm hoặc dịch vụ. 

 

Ngoài ra, BRD cũng bao gồm những mối quan tâm và nhu cầu của các bên liên quan dành cho sản phẩm hoặc dịch vụ cuối cùng. Do đó, việc tạo BRD được coi là một nghiệp vụ quan trọng mà BA cần nắm rõ, để có thể dễ dàng phân tích và tương tác với khách hàng của doanh nghiệp. 

 

BRD tập trung mô tả các yêu cầu kinh doanh và không đi sâu vào các yêu cầu kỹ thuật. Đồng thời,  BRD được thiết kế dưới dạng tài liệu cơ bản và dễ đọc, nên các bên liên quan như quản lý dự án, khách hàng và nhà đầu tư đều có thể dễ dàng hiểu rõ về những nội dung mà tài liệu này cung cấp. Điều này tạo ra một cơ sở chung và thống nhất, giúp cho quá trình truyền đạt thông tin giữa các bên trở nên hiệu quả và dễ dàng.

Tìm hiểu thêm: Tổng hợp kiến thức của BA từ cơ bản đến nâng cao

BRD sẽ đại diện cho câu hỏi “Tại sao?” cho những yêu cầu, bao gồm sự thay đổi kết quả của hệ thống sắp xây dựng. Dưới đây là một ví dụ về cấu trúc của một BRD hoàn chỉnh và đầy đủ.

  • Tổng quan về doanh nghiệp bao gồm thông tin về sứ mệnh, tầm nhìn, sản phẩm, và dịch vụ mà doanh nghiệp cung cấp.
  • Phạm vi dự án giúp các bên liên quan xác định các mục tiêu kinh doanh rõ ràng cùng với các kết quả mà dự án sẽ đạt được.
  • Mục tiêu kinh doanh bao gồm các mục tiêu, kế hoạch kinh doanh của các dự án mà bạn đang hướng đến. Những mục tiêu này cần được lập thành văn bản rõ ràng để gắn kết các bên liên quan của dự án có hướng đi rõ ràng.
  • Lộ trình dự án bao gồm các cột mốc quan trọng của dự án và các cuộc họp của các bên liên quan cùng với các mốc thời gian ước tính trước.
  • Tham vấn các bên liên quan đến dự án thông việc tổ chức cuộc họp để thảo luận và tìm kiếm giải pháp sau khi dự án khởi động thành công.

Ví dụ, nếu bạn đang xây dựng một hệ thống quản lý nhân sự cho một công ty, BRD có thể bao gồm các yêu cầu như quản lý thông tin nhân viên, quản lý lương, quản lý thời gian làm việc và quản lý quyền lợi nhân viên,...

System Requirement Specification - SRS

Phân biệt BRD, SRS, FRS

System Requirement Specification (hay SRS, tạm dịch: Thông số kỹ thuật yêu cầu của phần mềm) là tài liệu mô tả các yêu cầu kỹ thuật của một sản phẩm hoặc dịch vụ. SRS đặc tả chi tiết từng chức năng và tính năng của sản phẩm hoặc dịch vụ, cũng như các yêu cầu kỹ thuật khác như hiệu suất, độ tin cậy và bảo mật.

 

SRS cũng là một quy trình quan trọng tạo tiền đề cho sự thống nhất khi xây dựng hệ thống. Và trong thực tế thì tài liệu này thường sẽ được tạo bởi những chuyên gia kỹ thuật và nhóm phát triển. 

 

SRS sẽ cung cấp hướng dẫn chi tiết cho team phát triển về cách xây dựng, triển khai và kiểm soát phần mềm, đồng thời SRS cũng chính là cơ sở để đánh giá hiệu suất cuối cùng của sản phẩm. Không thể phủ nhận rằng, SRS đóng vai trò cực kỳ quan trọng, giúp nhà phát triển đảm bảo rằng phần mềm sẽ đáp ứng đầy đủ và chính xác những tiêu chí cũng như kỳ vọng của người sử dụng cuối cùng.

 

SRS sẽ đại diện cho câu hỏi “Cái gì?”, nghĩa là những gì nhà phát triển cần làm để tạo ra một hệ thống đạt yêu cầu. Dưới đây là các bước cơ bản để viết một SRS chi tiết và đầy đủ:

  • Xác định mục đích sản phẩm mà bạn muốn phát triển.
  • Mô tả những gì bạn đang xây dựng cho dự án của mình.
  • Mô tả chi tiết yêu cầu của các bên liên quan mà phần mềm đó cần đáp ứng.
  • Giao SRS cho bên có chuyên môn phê duyệt

Ví dụ nếu có một công ty sản xuất muốn phát triển một hệ thống quản lý sản xuất mới. SRS cho hệ thống quản lý sản xuất này sẽ bao gồm các thông tin sau:

 

Mục tiêu của sản phẩm là giúp công ty sản xuất quản lý hiệu quả các hoạt động sản xuất của mình. Còn người thực hiện theo mục tiêu là nhân viên sản xuất, quản lý sản xuất và các nhà quản lý cấp cao.

  • Yêu cầu chức năng cơ bản bao gồm quản lý nguyên vật liệu, quản lý quy trình sản xuất, quản lý chất lượng sản phẩm
  • Yêu cầu chức năng bổ sung bao gồm tự động hóa các quy trình sản xuất, theo dõi hiệu suất sản xuất
  • Yêu cầu phi chức năng gồm hệ thống phải tuân thủ các quy định của ngành, hệ thống phải luôn sẵn sàng hoạt động và hệ thống phải có khả năng mở rộng để đáp ứng nhu cầu phát triển của công ty

Tuy nhiên, khi viết SRS bạn cần ghi nhớ một số lưu ý sau:

  • SRS phải bao gồm tất cả các yêu cầu của sản phẩm hoặc dịch vụ.
  • SRS phải được viết bằng ngôn ngữ rõ ràng và dễ hiểu.
  • SRS phải được cập nhật thường xuyên để phản ánh các thay đổi của yêu cầu.

Functional Requirement Specification - FRS

Phân biệt BRD, SRS, FRS

Functional Requirement Specification (hay FRS, tạm dịch: ) là tài liệu mô tả các yêu cầu chức năng của một sản phẩm hoặc dịch vụ. FRS được xem như bước theo sau BRD và SRS, đại diện cho câu hỏi “Như thế nào?” khi xây dựng hệ thống, đồng thời đóng vai trò là “kim chỉ nam” giúp nhóm phát triển hiểu rõ nhiệm vụ cụ thể mà họ cần phải thực hiện trong dự án.

 

Trong FRS, mỗi yêu cầu chức năng được mô tả chi tiết, bao gồm cả thông tin về đầu vào, xử lý, đầu ra và các ràng buộc cụ thể. Ngoài ra, ở một số trường hợp nhất định, các tình huống kiểm thử và các yêu cầu hiệu suất cũng sẽ được liệt kê, với mục đích đảm bảo rằng hệ thống hoạt động một cách tối ưu và đúng kế hoạch ban đầu vạch ra.

 

Ví dụ, bạn đang phát triển một hệ thống quản lý nhân sự. Một trong những yêu cầu chức năng (FRS) có thể là:

  • Chức năng: Quản lý thông tin tất cả nhân viên
  • Mô tả: Hệ thống cần cung cấp khả năng thêm, xem, cập nhật và xóa thông tin nhân viên

Yêu cầu chi tiết:

  • Thêm thông tin nhân viên: Hệ thống cần cho phép người dùng nhập thông tin chi tiết của nhân viên mới, bao gồm tên, địa chỉ, số điện thoại, vị trí công việc và ngày bắt đầu làm việc.
  • Xem thông tin nhân viên: Hệ thống cần hiển thị thông tin chi tiết của mỗi nhân viên.
  • Cập nhật thông tin nhân viên: Hệ thống cần cho phép người dùng cập nhật thông tin của nhân viên.
  • Xóa thông tin nhân viên: Hệ thống cần cho phép người dùng xóa thông tin của nhân viên.

XEM THÊM:

So sánh BRD, SRS, FRS khác nhau thế nào?

Dưới đây là bảng so sánh điểm khác nhau giữa BRD, SRS và FRS

Yếu tố

BRD (Business Requirements Document)

SRS (Software Requirements Specification)

FRS (Functional Requirements Specification)

Mô tả

Mô tả yêu cầu kinh doanh cấp cao của một hệ thống, lợi ích, yêu cầu cơ bản, tính khả thi, rủi ro, kế hoạch triển khai

Tập trung vào yêu cầu chức năng và phi chức năng, giao diện, ràng buộc kỹ thuật, cũng như trường hợp sử dụng.

Chứa các yêu cầu chi tiết về thuật ngữ kỹ thuật và sơ đồ kỹ thuật như UML, luồng dữ liệu, đầu vào, đầu ra, quy trình xử lý, trường hợp sử dụng,, quy tắc kinh doanh, API.

Mục đích

Trả lời câu hỏi "Tại sao" về việc chuẩn bị yêu cầu.

Giải đáp câu hỏi "Cái gì" cần được đáp ứng.

Hướng tới phần "Cách thức" các yêu cầu sẽ được thực hiện như thế nào.

Giai đoạn chuẩn bị

Phân tích dự án.

Lập kế hoạch dự án.

Lập kế hoạch dự án.

Người tạo ra

Nhà phân tích kinh doanh (BA).

Nhà phân tích kinh doanh và nhà phân tích hệ thống.

Nhà phân tích kinh doanh, nhà phân tích hệ thống và nhóm triển khai.

Đối tượng sử dụng

Người dùng doanh nghiệp, ban lãnh đạo, người dùng cuối và các bên liên quan.

Chuyên gia và nhóm kỹ thuật.

Nhóm phát triển và nhóm kiểm thử.

 

Nói tóm lại, BRD sẽ tập trung vào yêu cầu kinh doanh tổng quan, còn SRS tập trung vào yêu cầu kỹ thuật và FRS là mô tả chi tiết về yêu cầu chức năng cụ thể của hệ thống. Cả ba tài liệu này đều đóng vai trò quan trọng đảm bảo các bên liên quan đều hiểu rõ và thống nhất ý kiến trong quá trình phát triển phần mềm.

 

Trên đây là những điểm giúp bạn phân biệt BRD, SRS, FRS rõ ràng nhất khi phát triển phần mềm. Hy vọng những thông tin trong bài viết này của Topchuyengia có thể giúp bạn hiểu rõ hơn về sự khác biệt giữa chúng, từ đó có thể áp dụng viết các yêu cầu chính xác, đầy đủ và chuyên nghiệp. Nếu bạn cần thêm thông tin hoặc hỗ trợ khi gặp khăn khi viết các tài liệu yêu cầu, hãy tham khảo lời khuyên của các chuyên gia giàu kinh nghiệm và kiến thức BA trên Askany nhé!

Tôi là Tô Lãm với hơn 4 năm kinh nghiệm trong lĩnh vực IT, Business Analyst, Data Analyst, Tracking,... cho rất nhiều doanh nghiệp SME. Tôi tốt nghiệp trường Công nghệ Thông tin cùng với kỹ năng và kiến thức trau dồi của mình, tôi mong muốn được chia sẻ các thông tin hữu ích dến với người đọc thông qua các bài viết trên Topchuyengia, mọi người hãy follow mình nhé.

Kinh nghiệm thực tế

Tư vấn 1:1

Uy tín

Đây là 3 tiêu chí mà TOPCHUYENGIA luôn muốn hướng tới để đem lại những thông tin hữu ích cho cộng đồng