10 – Tài liệu SRS

1. Tài liệu SRS là gì?

• Là tài liệu đặc tả yêu cầu của hệ thống.
• Viết tắt của System/Software Requirement Specification.
• Mô tả chi tiết yêu cầu chức năng, phi chức năng của hệ thống. Các yêu cầu chung, yêu cầu về dữ liệu, giao diện, etc.
• Dùng cho tất cả Stakeholders đọc và hiểu được các nghiệp vụ của các chức năng, etc.
• Là tài liệu quan trọng cho đội phát triển và kiểm thử.

2. Tại sao lại cần tài liệu SRS

• Giúp cho tất cả các stakeholders đều hiểu hệ thống theo cùng một hướng.
• Giúp cho đội phát triển dựa vào để xây dựng các tính năng chính xác với yêu cầu của KH.
• Giúp tester đọc hiểu và viết được test case.
• Giúp cho việc bảo trì và cải tiến hệ thống sau này dễ dàng hơn.

3. Thành phần chính trong tài liệu SRS

• Introduction – Giới thiệu
• High Level Requirement – Yêu cầu mức tổng thể
• Security Requirement – Các yêu cầu về bảo mật
• Use Case Specification – Đặc tả use case
• Wireframe – Thiết kế các màn hình
• Other Requirement – Các yêu cầu khác
• Integration – Yêu cầu tích hợp
• Appendices – Phụ lục

4. Mục Introduction

Chi tiết trong phần Introduction gồm:

1.Purpose: Mục này mô tả chi tiết về ý nghĩa và mục đích của tài liệu SRS, giúp mọi người hiểu rõ hơn về tài liệu SRS là gì và tại sao nó lại quan trọng.

2.Application Overview: Mục này mô tả tổng quan về hệ thống mà mình muốn làm. Tổng quan phải đảm bảo được yếu tố như: Mô tả được khái quát về hệ thống là gì ? Gồm những tính năng nào chính, ai có quyền và mục đích của hệ thống sinh ra phục vụ cho ai, etc.

3.Intended Audience and Reading Suggestions: Mục này mô tả việc tài liệu SRS dành cho những đối tượng nào và họ sẽ làm gì.

4.Abbreviations: Định nghĩa những từ viết tắt được sử dụng trong tài liệu. Ví dụ: SRS là System Requirement Specification, etc.

5.References: Cho phép bạn đính kèm hoặc mô tả về những tài liệu liên quan tới hệ thống.

5. Mục High Level Requirement và Security

Chi tiết trong phần High Level Requirement gồm:

1.Object Relationship Diagram: ORD là mô hình mối quan hệ tĩnh giữa các đối tượng trong hệ thống. Một đối tượng có thể được mô tả như một thể hiện của một thực thể cụ thể trong hệ thống.

2.Workflow Diagram: Phần này hiển thị luồng công việc hoặc các bước được thực hiện bởi mỗi người dùng hệ thống để hoàn tất quy trình kinh doanh. Các hành động của người dùng được hiển thị trong từng giai đoạn quy trình nghiệp vụ của hệ thống và những gì xảy ra trước khi nó có thể chuyển sang giai đoạn tiếp theo, hoặc trở lại giai đoạn trước.

• Workflow mô tả luồng công việc và các bước được thực hiện bởi mỗi User trong Hthống, để hoàn tất quy trình kinh doanh cụ thể.
• Các steps trong workflow phải đảm bảo việc thay đổi trạng thái của quy trình.

3.State Transition Diagram: Mô tả từng trạng thái theo từng step của workflow. Người dùng nhìn vào State Transition có thể hình dung được tương ứng mỗi step trong workflow thì ai là người thực hiện, và những action đó làm thay đổi trạng thái trong quy trình hệ thống ntn?

4.Use Case Diagram: Sơ đồ để thể hiện cách những user trong hệ thống tương tác với các tính năng trong hệ thống.

6. Mục Security Requirement

Mô tả đầy đủ về permission của từng actor trong hệ thống. Actor nào làm những chức năng gì, etc.

• Bảng matrix về các permission tương ứng với từng actors trong hthống.
• Chỉ ra rằng, với Actors bất kỳ họ có quyền thực hiện những actions gì trong hệ thống

7. Mục Use case Specification

Phần này bao gồm các yêu cầu chức năng của hệ thống, trong đó nêu chi tiết những gì hệ thống phải làm về đầu vào, hành vi và đầu ra dự kiến.

Nó gợi ra sự tương tác giữa (các) tác nhân và hệ thống, hành vi của hệ thống và kết quả tương tác của họ.

8. Các phần khác

Wireframe: Mục này cho phép bạn đính kèm tài liệu wireframe để người đọc có thể refer được đến screen.

• Xác nhận yêu cầu chức năng của hệ thống với KH nhanh hơn.
• KH hiểu và hình dung hệ thống dễ dàng hơn.
• Thể hiện hiểu yêu cầu của BA với những mong đợi của KH.
• Chứng minh năng lực của team dự án.
• Internal team dễ tiếp cận, nắm bắt và hiểu rõ về hệ thống nhanh hơn.
• Công cụ: Khuyến nghị figma.com, Balsamiq mockups, …

Other requirement: Mô tả những phần yêu cầu thêm về hệ thống, cái này thuộc non-functional requirement.

Integration: Mục này cho phép bạn mô tả hoặc đính kèm tài liệu liên quan đến các hệ thống ngoài.

Appendices:

• Email template: Mục này cho phép bạn định nghĩa ra các email template dùng trong hệ thống
• Error message: Mục này cho phép bạn định nghĩa ra các error message trong hệ thống.

9. Thành phần chính trong tài liệu Wireframe đính kèm

Tài liệu gồm các sheet chính như sau:

1.Table of Contents: Định nghĩa tất cả các url dẫn đến từng sheet trong tài liệu wireframe, đây cũng được coi là direction của file. Điều này giúp người đọc có thể điều hướng đến từng sheet một cách dễ dàng.

2.Version history: Mô tả cách đánh các version của tài liệu, đồng thời lưu lại tất cả những lần nâng cấp version và những lần chỉnh sửa, nội dung chỉnh sửa, ai chỉnh sửa, etc.

3.System’s screen: Liệt kê danh sách những screen trong hệ thống, trong hệ thống có bao nhiêu screen chính thì tương ứng với bấy nhiều sheets. Tuy nhiên việc bố trí screen và các sheet tương ứng phụ thuộc vào cách bố trí của mỗi người.

Cách sử dụng figma cơ bản: xem tại đây

Tải về template SRS tham khảo