Theo thông kê của TheBusinessAnalyst, mang 9 loại tài liệu QUAN TRỌNG được tạo bởi bất kể BA nào ?! (Nghĩa là một BA nào cũng đều có phải ghi nhận “mần” 9 loại tài liệu này)
100 phần quà card 100k dành tặng cho member https://viettingame.com/: Click tại đây
BAC sẽ ra mắt và so sánh đặc tính của 3 loại tài liệu: 1 –mục 5 – Business Requirement Document (BRD), 2 – mục 8 – System requirement specification (SRS)/ System Requirement Document (SRD) và 3 – mục 7 – Functional requirement specification (FRS)/ Functional Specification Document (FSD):
Một người phân tích nghiệp vụ ứng dụng (Business Analyst (BA)) cần hiểu và phân biệt được những quan điểm về tài liệu yêu cầu như Business Requirement Document – BRD (Tạm dịch: Tài liệu yêu cầu nghiệp vụ), Software Requirement Documen Specifications – SRS (Tạm dịch: Thông số kỹ thuật kỹ thuật yêu cầu của ứng dụng) và Functional Requirement Specifications – FRS (Tạm dịch: Thông số kỹ thuật kỹ thuật yêu cầu của tính năng). Trong nội dung bài viết này, BAC sẽ cùng chúng ta tìm hiểu sự không giống nhau giữa chúng.
Đang xem: Tài liệu srs
Việc phân tích nghiệp vụ (Business Analysis) được phân bổ bởi những khung tiêu chuẩn chỉnh rõ ràng và chúng nên được sử dụng trong bất kì dự án công trình thực tiễn nào. Tuy nhiên, ko hề mang một quy chuẩn chỉnh nào về cấu trúc tổng thể, nội dung, và mức độ cụ thể trong những tài liệu chính thống về BA như BABOK hay CMMI. Vì như thế vậy, so với từng dự án công trình, những tổ chức cần điều chỉnh những tài liệu yêu cầu này tùy từng quy trình và tiêu chuẩn chỉnh của siêu thị cũng như nguồn lực sẵn mang của họ.
Thông tin mô tả dưới trên đây thích ứng với những phân tích tài liệu dự án công trình (Project Document Practices) và phân tích nghiệp vụ (Business Analysis) được đồng ý thoáng rộng nhất.
1. Business Requirement Document – BRD
Theo định nghĩa được thừa nhận trên toàn toàn cầu về BRD là: Tập hợp những yêu cầu nghiệp vụ và yêu cầu của những bên liên quan (BRD ghi lại những mong muốn của doanh nghiệp hơn là những yêu cầu)
BRD thông thường là loại tài liệu mang trước nhất trong quy trình phát triển của tổ chức. Nó mô tả chiến lược của siêu thị (Company’s high-level goals) mà người ta đang nỗ lực để đạt được trong tương lai bằng phương pháp tạo ra một thành phầm/ dịch vụ. Ngoài ra, BRD còn bao hàm mối ưa chuộng/ nhu yếu của những bên liên quan tới thành phầm/dịch vụ sau cuối. Nói cách khác, BRD là câu vấn đáp cho thắc mắc “Vì sao?” Sở hữu những yêu cầu trên, hậu quả mong đợi – sự thay đổi gì từ khối hệ thống.
Ví dụ về BRD: Nhà hàng muốn nâng cao hiệu suất thao tác bằng phương pháp theo dõi thời hạn giành cho từng sinh hoạt của nhân viên.
Người BA luôn luôn luôn luôn là người sẵn sàng tài liệu này sau những buổi thủ thỉ trước nhất với doanh nghiệp và những bên liên quan. Sự xác nhận sau cuối lại từ những bên liên quan chính sẽ là đảm nói rằng BA đã thâu tóm đúng đắn kì vọng của họ cũng như vì sao họ muốn như vậy (context của doanh nghiệp).
Đối tượng người tiêu dùng sử dụng BRD là những nhà tài trợ, quản lí cấp cao, quản lí cấp trung và BA.
2. Software Requirement Documen Specifications – SRS
Tên thường gọi khác:
Product Requirements Document (PRD)haySystem Requirements Specification(SRS)
Sau lúc đã sẵn sàng tài liệu BRD, tức là đã vấn đáp được thắc mắc “Vì sao?” Cần xây dựng khối hệ thống này, sẽ tới bước tìm câu vấn đáp cho thắc mắc “Dòng gì?”, tức là những yêu cầu nào được đưa ra để thỏa mãn nhu cầu được nhu yếu của doanh nghiệp.
Theo định nghĩa quốc tế, SRS là tài liệu yêu cầu mang cấu trúc và cụ thể, bao hàm những yêu cầu tính năng (The Functional Requirtements, sử dụng để minh họa hành vi người sử dụng) và Phi tính năng (Non-Functional Requirements – mô tả điểm sáng) cùng toàn bộ trường hợp khác mà ứng dụng cần thỏa mãn nhu cầu.
Vi dụ: Những modules cần phải có cho khối hệ thống theo dõi nhân viên như sau
Module đăng nhập: Xác thực người sử dụng dựa trên thông tin đăng nhập đã nhập vào khối hệ thống, và chỉ cho phép người sử dụng đã đăng kí đăng nhập.Module Administrator: Bao hàm chức năng cho phép quản trị viên quản lí người sử dụng: Thêm, chỉnh sửa, xóa người sử dụng; phân quyền / nhóm người sử dụng, thêm dự án công trình, ….Module nhân viên: Bao hàm chức năng giúp nhân viên ghi nhận lại thời gain và những công việc mà người ta đã làm, chỉnh sửa thông tin cá thể, xem report ngày thao tác, …Module report: Dành riêng cho Admin, cho phép họ trích xuất ra những report về nhân viên, dự án công trình. Admin cũng đều có quyền xuất tài liệu dưới những file như .xlsx hoặc .pdf.
SRS là một tài liệu quan trọng như cầu nối Một trong những gì doanh nghiệp muốn và những gì được tài liệu dưới dạng bố cục, điểm sáng, quy trình mà khối hệ thống đang xây dựng.
Nhờ vào những yêu cầu ứng dụng được ghi nhận rõ rệt trong SRS cũng giúp ước tính kinh tế và thời hạn cần phải có để hoàn thiện khối hệ thống. Phía trên cũng là trung tâm để tạo lập hợp đồng giữa những bên.
Xem thêm: trò chơi Tần Mỹ Nhân trò chơi Trực tuyến Nào Các bạn Cũng Sẽ Bắt gặp, Mỹ Nhân Ngư
Nếu BRD do những BA sẵn sàng thì SRS sẽ được làm bởi những nhà phân tích khối hệ thống (the system analyst – SA). Tuy nhiên, trong thực tiễn ở một vài doanh nghiệp, không tồn tại SA thì BA sẽ là người làm chuyện này. Lúc này, người BA cần tiến hành tổng hợp yêu cầu của từng bên liên quan, phân tích cụ thể chức năng của ứng dụng và liệt kê lại những yêu cầu kĩ thuật so với từng tính năng đó. Điều đó đảm nói rằng, từng yêu cầu được liệt kê trong SRS sẽ thỏa mãn nhu cầu những tiềm năng sale mang trong BRD.
Đối tượng người tiêu dùng sử dụng SRS là quản lí dự án công trình, Chuyên Viên tư vấn trong nghành nghề (Subject Matter Experts), trưởng cơ quan kỹ thuật và thực thi.
Ghi chú: Trong một vài doanh nghiệp hoặc dự án công trình nhỏ sẽ không còn cần sử dụng tới SRS vì thế trong BRD cụ thể đã bao hàm những yêu cầu tính năng và phi tính năng của khối hệ thống.
3. Functional Requirement Specifications – FRS
Tên thường gọi khác:
Functional Specifications Document (FSD),Functional Specification (FS),Product Specification,and Functional SpecsProjec(FS).
FRS là loại tài liệu cụ thể nhất trong 3 loại trên, và sẽ là loại tài liệu sau cuối vấn đáp cho thắc mắc “Ra sao?”, tức là khối hệ thống dự kiến sẽ sinh hoạt ra sao để làm thỏa mãn nhu cầu những yêu cầu nêu trong BRD và SRS.
Theo định nghĩa đã được thừa nhận, FRS là tài liệu cụ thể để xây dựng tương đối đầy đủ những tiểu tiết mang trong yêu cầu tính năng của dự án công trình.
Ví dụ: Trong module đăng nhập sẽ sở hữu những cụ thể:
Nhập username: Là hộp văn phiên bản cho phép người sử dụng nhập tên đăng nhập theo địa chỉ email siêu thị đã đăng kí cho họNhập password: Là hộp văn phiên bản cho phép người sử dụng nhập mật khẩu. Mật khẩu ko được hiển thị và được mã hóa dưới dạng dấu ‘*’.Nút submit: Lúc nhấp chuột vào nút này, khối hệ thống sẽ xác nhận thông tin đăng nhập đã đúng hay chưa. Trong trường hợp tên đăng nhập hoặc mật khẩu ko đúng sẽ hiện thông tin “Tên đăng nhập/ Mật khẩu ko đúng”, …
FRS xây dựng những mô tả cụ thể, rõ rệt từng yêu cầu tính năng trong từng trường, và tương tác của người sử dụng trên từng trang của khối hệ thống.
FRS được thể hiện dưới những process flow diagrams (tạm dịch: sơ đồ dòng quy trình), UML diagrams, wireframs.
FRS được tạo từ quan điểm của người sử dụng và cách mà khối hệ thống sẽ tương tác với họ. Lúc này, team Dev sẽ phải rõ đúng đắn họ cần phải làm những gì và team QA/testing nên biết mang những kịch phiên bản test nào cho khối hệ thống.
Tài liệu FRS do BA hoặc SA sẵn sàng, và sau lúc hoàn thành sẽ đưa cho quản lí dự án công trình xem xét. Tiếp theo, FRS sẽ được được đưa cho quý khách hàng, xác nhận lại lần cuối. Một lúc đã mang sự xác nhận của những bên, tài liệu này sẽ là phiên bản tiêu chuẩn chỉnh về phương pháp sinh hoạt của ứng dụng.
Xem thêm: trò chơi Half Life – Tải về Half Life 1
Đối tượng người tiêu dùng sử dụng FRS là trưởng cơ quan kỹ thuật, Team Dev và Team Testing.
Tổng hợp ngắn so sánh BRD và FRD:
Tìm hiểu thêm thêm những định nghĩa thuật ngữ(glossary), so sánh/ ví dụ minh họa để rõ hơn:
Vui lòng điền thông tin qua form để tải mẫu tài liệu và ví dụ của BRD vs SRS vs FRS
