WAY TO ENTERPRISE
Lesson 27
Tài liệu đặc tả SRS
Agenda
I. Business Requirement Documents (BRD) II. Software Requirement Specifications (SRS) III. Functional Requirement Specifications (FRS) IV. User Requirement Documents (URD)
V. Ví dụ về SRS
I . Business Requirement Documents (BRD)
• Được tạo bởi: Business Analyst
• Bao gồm: Yêu cầu business ở mức cao và yêu cầu của các bên liên quan
• Được sử dụng bởi: Quản lý cấp trên và cấp trung
• Chuẩn bị trong : Giai đoạn invitation
• Trả lời câu hỏi: Tại sao các yêu cầu đang được thực hiện?
• Ví dụ: Nâng cao hiệu quả bằng cách theo dõi thời gian của nhân viên tại văn phòng.
=> Tại sao làm dự án này về mặt business, lý do về business cần làm và mang lại giá trị gì?
I . Business Requirement Documents (BRD)
• BRD ghi lại những mong muốn của doanh nghiệp hơn là các yêu cầu
• BRD thường là loại tài liệu có đầu tiên trong quy trình phát triển của tổ chức. Nó mô tả chiến lược của công ty (Company’s high-level goals) 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/ dịch vụ. Bên cạnh đó, BRD còn bao gồm 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.
I . Business Requirement Documents (BRD)
• BRD sẽ giúp BA giao tiếp, xác nhận tốt hơn về yêu cầu cần thiết. Giảm thiểu được những sai sót trong quá trình phát triển dự án
• Kết nối với các mục tiêu kinh doanh: Các yêu cầu kinh doanh được xác định rõ sẽ giúp đưa ra một điều lệ dự án, kết hợp chiến lược kinh doanh và các mục tiêu kinh doanh để phát triển nó thành một hệ thống CNTT trong giải pháp tổng thể.
• Tạo sự đồng thuận: Khi các yêu cầu được mô tả và tài liệu hóa, xác nhận từ các bên liên quan sẽ tạo ra sự đồng thuận trong quá trình phát triển.
• Tiết kiệm chi phí: BRD giúp giảm thiểu rủi ro về phạm vi dự án, giúp tiết kiệm thời gian và tiền bạc cho dự án
II . Software Requirement Specifications (SRS)
• Tên khác: Product requirements document (PRD) and system requirements Specification (SRS)
• Được tạo bởi: Business/ System analyst
• Bao gồm: Các yêu cầu chức năng chi tiết, các yêu cầu phi chức năng và các trường hợp sử dụng.
• Được sử dụng bởi: Quản lý dự án, kĩ thuật và trưởng nhóm triển khai.
• Chuẩn bị trong: Giai đoạn planning
• Trả lời câu hỏi: Yêu cầu gì phải được hoàn thành để đáp ứng nhu cầu kinh doanh.
• Ví dụ: Phần mềm được đề xuất sẽ chức các modun sau: đăng nhập, quản trị viên, nhân viên và báo cáo.
II . Software Requirement Specifications (SRS)
Theo định nghĩa quốc tế, SRS là tài liệu yêu cầu có cấu trúc và chi tiết, bao gồm các yêu cầu chức năng (The Functional Requirtements, dùng để minh họa hành vi người dùng) và Phi chức năng (Non-Functional Requirements – miêu tả đặc điểm) cùng tất cả trường hợp khác mà phần mềm cần đáp ứng.
II . Software Requirement Specifications (SRS)
Vi dụ: Các modules cần có cho hệ thống theo dõi nhân viên như sau
• Module đăng nhập: Xác thực người dùng dựa trên thông tin đăng nhập đã nhập vào hệ thống, và chỉ cho phép người dùng đã đăng kí đăng nhập.
• Module Administrator: Bao 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, chỉnh sửa, xóa người dùng; phân quyền / nhóm người dùng, thêm dự án, ….
• Module nhân viên: Bao gồm các chức năng giúp nhân viên ghi nhận lại thời gain và các công việc mà họ đã làm, chỉnh sửa thông tin cá nhân, xem báo cáo ngày làm việc, …
• Module báo cáo: Dành riêng cho Admin, cho phép họ trích xuất ra các báo cáo về nhân viên, dự án. Admin cũng có quyền xuất tài liệu dưới các file như .xlsx hoặc .pdf.
II . Software Requirement Specifications (SRS)
• SRS là một tài liệu quan trọng như cầu nối giữa những gì doanh nghiệp muốn và những gì được tài liệu dưới dạng bố cục, đặc điểm, quy trình mà hệ thống đang xây dựng.
• Nếu BRD do các BA chuẩn bị thì SRS sẽ được làm bởi các nhà phân tích hệ thống (the system analyst - SA). Tuy nhiên, trong thực tế ở một số doanh nghiệp, không có 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 chi tiết các chức năng của phần mềm và liệt kê lại các yêu cầu kĩ thuật đối với từng chức năng đó. Điều đó đảm bảo rằng, từng yêu cầu được liệt kê trong SRS sẽ đáp ứng các mục tiêu kinh doanh có trong BRD.
* Chú ý: Trong một số doanh nghiệp hoặc dự án nhỏ sẽ không cần sử dụng đến SRS vì trong 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.
III . Functional Requirement Specifications (FRS)
• Tên khác: Functional Specifications document (FSD), Functional specification (FS), Product Specification, and Functional Spec (FS)
• Được thực hiện bởi: Business/ System Analyst, Analyst/ Trưởng nhóm triển khai
• Bao gồm: Cá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: Trưởng nhóm kĩ thuật, nhóm dev và nhóm test.
• Chuẩn bị trong: Giai đoạn planning
• Trả lời câu hỏi: Hệ thống dự kiến sẽ hoạt động chính xác như thế nào?
• Ví dụ: Module Login sẽ chứa các trường như: nhập tên người dùng, nhập mật khẩu, nút gửi.
III . Functional Requirement Specifications (FRS)
Theo định nghĩa đã được công nhận, FRS là tài liệu chi tiết để xây dựng đầy đủ các tiểu tiết có trong yêu cầu chức năng của dự án.
Ví dụ: Trong module đăng nhập sẽ có các chi tiết:
• Nhập username: Là hộp văn bản cho phép người dùng nhập tên đăng nhập theo địa chỉ email công ty đã đăng kí cho họ
• Nhập password: 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 dấu ‘*’.
• Nút submit: Khi click vào nút này, 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 không đúng sẽ hiện thông báo “Tên đăng nhập/ Mật khẩu không đúng”, …
III . Functional Requirement Specifications (FRS)
• FRS xây dựng các mô tả chi tiết, rõ ràng từng yêu cầu chức năng trong từng trường, và tương tác của người dùng trên từng trang của hệ thống.
• FRS được thể hiện dưới các process flow diagrams (tạm dịch: sơ đồ dòng quy trình), UML diagrams, wireframes.
• FRS được tạo từ quan điểm của người dùng và cách mà hệ thống sẽ tương tác với họ.
Lúc này, team Dev sẽ phải rõ chính xác họ cần làm gì và team QA/testing cần biết có những kịch bản test nào cho hệ thống.
IV. User Requirement Documents (URD)
• Tài liệu hướng dẫn sử dụng (user guide), có chỗ còn gọi User requirement document (ERD) tài liệu dùng để cung cấp các hướng dẫn, chỉ dẫn cho người dùng của một hệ thống / sản phẩm cụ thể nào đó.
• URD được viết bởi Technical Writer (Người viết chuyên về kỹ thuật), Lập trình viên, Quản lý Sản phẩm / dự án hoặc nhân viên khác trong các Công ty nhỏ. Ở nhiều công ty người viết tài liệu user guide là QC/Tester hoặc BA
V. Ví dụ thực hành
Không hề có một quy 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ống về BA như BABOK hay CMMI. Vì vậy, đối với từng dự án, các tổ chức cần điều chỉnh các tài liệu yêu cầu này tùy theo quy trình và tiêu chuẩn của công ty cũng như nguồn lực sẵn có của họ.
V. Ví dụ thực hành
Một số loại Item tyle hay dùng khi viết SRS
• Label: Dạng text cố định
• Textbox: Mục nhập text
• Button: Nút bấm
V. Ví dụ thực hành
Một số loại Item tyle hay dùng khi viết SRS
• Listbox: Một danh sách tùy chọn hiển thị trong hộp danh sách và có thể chọn nhiều tùy chọn
• Combobox: Một danh sách tùy chọn và chỉ được chọn 1 tùy chọn
V. Ví dụ thực hành
Một số loại Item tyle hay dùng khi viết SRS
• Radiobutton: Thường dạng hình tròn, chỉ được chọn 1 giá trị trong 1 list giá trị
• Checkbox: Thường dạng ô vuông, có thể chọn nhiều giá trị trong 1 list giá trị
V. Ví dụ thực hành
Một số loại Item type hay dùng khi viết SRS
• Link: Click vào có thể dẫn đến 1 url khác
• Icon button: những button chỉ dùng icon để truyền đạt ý nghĩa chức năng
V. Ví dụ thực hành
Một số loại Item type hay dùng khi viết SRS
• Calendar: Kiểu chọn ngày tháng năm
• Avatar: Ảnh đại diện của người dùng
V. Ví dụ thực hành
Viết tài liệu đặc tả SRS của màn hình Login sau
