Người phân tích nghiệp vụ (3) cần hiểu và phân biệt được các khái niệm tài liệu yêu cầu như Tài liệu yêu cầu nghiệp vụ-brd (tạm dịch: Tài liệu yêu cầu nghiệp vụ), Đặc tả tài liệu yêu cầu phần mềm- srs (tạm dịch: Đặc tả yêu cầu phần mềm) và Đặc tả yêu cầu chức năng-frs (tạm dịch: Đặc tả yêu cầu chức năng). Trong bài viết này, bac sẽ giúp bạn hiểu sự khác biệt.
Phân tích kinh doanh được điều chỉnh bởi các khuôn khổ cụ thể nên được sử dụng trong bất kỳ dự án thực tế nào. Nhưng về babok hay cmmi, không có tiêu chuẩn nào về cấu trúc tổng thể, nội dung và mức độ chi tiết trong các tài liệu chính thức. Do đó, đối với mỗi dự án, tổ chức cần điều chỉnh các tài liệu yêu cầu này theo các quy trình và tiêu chuẩn của công ty cũng như các nguồn lực sẵn có.
Thông tin được mô tả dưới đây nhất quán với các thông lệ về tài liệu dự án (Thông lệ về tài liệu dự án) và phân tích kinh doanh (Phân tích doanh nghiệp) được chấp nhận. phong phú nhất.
1. Tài liệu yêu cầu nghiệp vụ-brd
Theo định nghĩa được quốc tế công nhận, brd là: tập hợp các yêu cầu kinh doanh và yêu cầu của các bên liên quan (brd ghi lại mong muốn của doanh nghiệp hơn là yêu cầu)
p>
brd thường là loại tài liệu đầu tiên xuất hiện trong quy trình phát triển của một tổ chức. Nó mô tả các mục tiêu cấp cao mà công ty đang cố gắng đạt được trong tương lai bằng cách tạo ra một sản phẩm/dịch vụ. Ngoài ra, brd còn bao gồm những mối quan tâm/nhu cầu của các bên liên quan đến sản phẩm/dịch vụ cuối cùng. Nói cách khác, brd là câu trả lời cho câu hỏi “Tại sao?”. Với các yêu cầu trên, kết quả mong đợi – những thay đổi nào đã được thực hiện đối với hệ thống.
Ví dụ brd: Một công ty muốn cải thiện hiệu suất công việc bằng cách theo dõi lượng thời gian mà nhân viên dành cho từng hoạt động.
Tài liệu này luôn do người thứ ba chuẩn bị sau các cuộc gặp ban đầu với doanh nghiệp và các bên liên quan. Xác nhận cuối cùng với các bên liên quan chính sẽ đảm bảo rằng bạn nắm bắt được chính xác những gì họ mong đợi và lý do họ muốn điều đó (bối cảnh kinh doanh).
Người dùng
brd là Nhà tài trợ, Quản lý cấp cao, Quản lý cấp trung và thứ ba.
2. Đặc tả tài liệu yêu cầu phần mềm-srs
Bí danh:
- Tài liệu yêu cầu sản phẩm (prd)
- hoặc Đặc tả yêu cầu hệ thống (srs)
- Module Đăng nhập: Xác thực người dùng dựa trên thông tin đăng nhập vào hệ thống, chỉ cho phép người dùng đã đăng ký đăng nhập.
- Module quản trị viên: gồm các chức năng cho phép quản trị viên quản lý người dùng: thêm, sửa, xóa người dùng; phân quyền/nhóm người dùng, thêm mục,…
- Mô-đun Nhân viên: Bao gồm các tính năng giúp nhân viên ghi lại thời gian và công việc của họ, chỉnh sửa thông tin cá nhân, xem báo cáo ngày làm việc, v.v…
- Mô-đun báo cáo: Dành riêng cho quản trị viên, cho phép họ lấy báo cáo về nhân viên và dự án. Quản trị viên cũng có quyền xuất tài liệu dưới dạng .xlsx hoặc .pdf.
- Tài liệu đặc tả chức năng (fsd),
- Đặc tả chức năng (fs),
- Thông số kỹ thuật của sản phẩm,
- Và một mục đặc tả chức năng (fs).
- Nhập tên người dùng: là hộp văn bản cho phép người dùng nhập tên người dùng dựa trên địa chỉ email công ty đã đăng ký của họ
- Nhập mật khẩu: là hộp văn bản cho phép người dùng nhập mật khẩu. Mật khẩu không được hiển thị và được mã hóa dưới dạng “*”.
- Nút Gửi: Sau khi nhấn vào nút này, hệ thống sẽ xác nhận thông tin đăng nhập có chính xác hay không. Nếu tên người dùng hoặc mật khẩu không chính xác, thông báo “Tên người dùng/mật khẩu không hợp lệ” sẽ được hiển thị,…
- https://thebusinessanalystjobdescription.com/documents-created-by-a-business-analyst/
- https://www.smartsheet.com/free-feft-specation-templates
- https://thebusinessanalystjobdescription.com/brd-vs-srs-vs-frs-detailed-comparison/
- Chìa khóa thành công của nhà phân tích kinh doanh.
- Công cụ kỹ năng phân tích kinh doanh.
- Phân tích nghiệp vụ cơ bản 3.0.
- Phân tích kinh doanh nâng cao 3.0.
- Chuẩn bị cho kỳ thi chứng chỉ iiba 3.0.
- Hà Nội – Business Analytics 3.0.
- Hà Nội – Advanced Business Analytics 3.0.
Sau khi chuẩn bị tài liệu brd, tức là trả lời câu hỏi “Tại sao?”, hệ thống cần được xây dựng, và bước tiếp theo là tìm câu trả lời cho câu hỏi “ Gì?”. “, yêu cầu nào được đặt ra để đáp ứng nhu cầu kinh doanh.
Theo định nghĩa quốc tế, srs là một tài liệu yêu cầu chi tiết có cấu trúc, bao gồm các yêu cầu chức năng (để mô tả hành vi của người dùng) và các yêu cầu phi chức năng (non-function requests) và các yêu cầu phần mềm khác.
Ví dụ: Các mô-đun bắt buộc của hệ thống theo dõi nhân viên như sau
srs là một tài liệu quan trọng đóng vai trò là cầu nối giữa các yêu cầu kinh doanh và những gì được ghi lại dưới dạng bố cục, đặc điểm và quy trình của hệ thống đang được xây dựng.
Dựa trên các yêu cầu phần mềm được ghi lại rõ ràng trong srs, việc ước tính chi phí và thời gian cần thiết để hoàn thiện hệ thống cũng rất hữu ích. Đây cũng là cơ sở để hai bên ký kết hợp đồng.
Nếu brd do bạn chuẩn bị thì srs sẽ do chuyên viên phân tích hệ thống (sa) thực hiện. Tuy nhiên, thực tế tại một số DN nếu không có TĐG thì bố sẽ làm việc này. Lúc này, bên thứ ba cần tổng hợp nhu cầu của từng bên liên quan, phân tích chi tiết các chức năng của phần mềm, liệt kê lại yêu cầu kỹ thuật của từng chức năng. Điều này đảm bảo rằng mỗi yêu cầu được liệt kê trong srs sẽ đáp ứng các mục tiêu kinh doanh có trong brd.
Sử dụng srs cho người quản lý dự án, chuyên gia về chủ đề, người đứng đầu kỹ thuật và triển khai.
Lưu ý: Trong một số doanh nghiệp hoặc dự án nhỏ, bạn sẽ không cần sử dụng srs, vì brd chi tiết bao gồm các yêu cầu chức năng và phi chức năng của hệ thống.
3. Đặc tả yêu cầu chức năng-frs
Bí danh:
Phần thứ 3 là phần chi tiết nhất trong 3 phần trên và sẽ là phần cuối cùng trả lời câu hỏi “Làm thế nào?”, hệ thống dự kiến sẽ hoạt động như thế nào để đáp ứng các yêu cầu và srs được nêu trong các brd. p>
Theo định nghĩa được chấp nhận, một frs là một tài liệu chi tiết nêu chi tiết tất cả các chi tiết có trong các yêu cầu chức năng của dự án.
Ví dụ, trong module đăng nhập sẽ có thông tin chi tiết:
frs Thiết lập các mô tả rõ ràng, chi tiết về từng yêu cầu chức năng trong từng miền và tương tác của người dùng trên từng trang của hệ thống.
frs Được hiển thị dưới dạng lưu đồ, sơ đồ uml, khung dây.
frs được tạo từ quan điểm của người dùng và cách hệ thống sẽ tương tác với họ. Tại thời điểm này, nhóm phát triển phải biết chính xác những gì họ cần làm và nhóm QA/kiểm thử cần biết kịch bản kiểm thử nào có sẵn cho hệ thống.
Tệp frs do cha hoặc sa chuẩn bị và sẽ được gửi cho người quản lý dự án để xem xét sau khi hoàn thành. Tiếp theo, frs sẽ cung cấp cho khách hàng, xác nhận lại lần cuối. Sau khi được tất cả các bên chấp thuận, tài liệu này sẽ trở thành phiên bản tiêu chuẩn về cách thức hoạt động của phần mềm.
Đối tượng mục tiêu của frs là trưởng bộ phận kỹ thuật, nhóm phát triển và nhóm thử nghiệm.
Tóm tắt ngắn so sánh brd và frd:
Để rõ ràng, hãy xem Định nghĩa thuật ngữ, So sánh/Ví dụ:
Vui lòng điền vào biểu mẫu để tải xuống tài liệu mẫu và ví dụ về brd vs srs vs frs
Tài nguyên:
Bacs.vn Khóa học phân tích nghiệp vụ dành cho bạn
Các khóa học trực tuyến:
Các khóa học ngoại tuyến:
tại tp.hcm:
Tại Hà Nội:
Tham khảo lịch trình hiện tại cho tất cả các khóa học hiện tại.
bac biên tập nội dung