Cuộc cách mạng công nghiệp 4.0 bùng nổi đã kéo theo rất nhiều công ty sản xuất phần mềm xuất hiện. Đối với những loại hình doanh nghiệp này, để phát triển phần mềm thành công thì SRS là vô cùng quan trọng, vì tài liệu này chính là những yêu cầu về sản phẩm cần được thực hiện. Vậy cụ thể tài liệu SRS là gì và bao gồm những thành phần chính nào? Tất cả sẽ được Muaban.net bật mí trong bài viết dưới đây.
Tài liệu SRS là gì?
SRS là tài liệu đặc tả yêu cầu, được viết tắt từ Software Requiremnet Specification. Tài liệu này dùng để mô tả một cách chi tiết yêu cầu chức năng, phi chức năng và các yêu cầu về dữ liệu, giao diện khác của hệ thống. Nhờ vào SRS mà Stakeholders có thể đọc và hiểu được các nghiệp vụ của các chức năng. Đây là tài liệu vô cùng quan trọng đối với đội phát triển và đội thử nghiệm phần mềm.
Vai trò của tài liệu SRS trong sự phát triển của sản phẩm
Như đã nói ở trên, SRS có vai trò quan trọng với đội phát triển và thử nghiệm sản phẩm phần mềm. Vậy tại sao lại cần tài liệu SRS?
- Giúp stakeholders hiểu được hệ thống theo cùng một hướng: Nhờ có tài liệu đặc tả yêu cầu SRS mà tất cả các stakeholders, hay còn được gọi là bên thứ ba có thể dễ dàng hiểu được hệ thống theo đúng hướng, tránh trường hợp mỗi người hiểu theo một cách khác nhau.
- Đội phát triển dựa vào đây để xây dựng hệ thống chính xác: Để các tính năng được xây dựng đúng như yêu cầu của khách hàng là một điều không dễ dàng. Vì vậy đội phát triển phần mềm cần có tài liệu SRS để có thể xây dựng hệ thống chính xác, đúng ý, không bị lạc hướng.
- Giúp tester hiểu được để viết test case: Các tester- đội thử nghiệm phần mềm cần dựa vào tài liệu SRS này để có thể hiểu được từ đó xây dựng các kịch bản kiểm thử chi tiết nhất.
- Bảo trì và cải tiến hệ thống: Nhờ vào tài liệu SRS mà việc bảo trì hệ thống hoặc cải tiến các chức năng trong hệ thống trở nên nhanh chóng và dễ dàng hơn.
Thành phần chính của các tài liệu đặc tả yêu cầu SRS
Introduction – Phần giới thiệu
Đây là thành phần đầu tiên của tài liệu SRS. Phần giới thiệu bao gồm các chi tiết:
- Purpose: Mục này dùng để mô tả chi tiết mục đích và ý nghĩa của tài liệu SRS, từ đó giúp người đọc hiểu rõ hơn khái niệm và tầm quan trọng của tài liệu này.
- Application Overview: Mục này sẽ giúp người đọc có cái nhìn tổng quan về hệ thống mình muốn làm. Để đảm bảo tài liệu đầy đủ thì mục này cần phải bao gồm các yếu tố như: khái quát được hệ thống, các tính năng chính, quyền sử dụng và mục đích hệ thống này được xây dựng để làm gì, phục vụ cho ai,…
- Intended Audience and Reading Suggestions: Ở đây mô tả đối tượng nào sử dụng tài liệu SRS và họ cần thực hiện những gì.
- Abbreviations: Giải thích, định nghĩa các từ viết tắt trong tài liệu.
- References: Mục này dùng để đính kèm các tài liệu, mô tả liên quan.
Tham khảo các công việc đang được tuyển tại đây:
![[KingFoodMart] Tuyển Dụng Bán Hàng, Thu Ngân, Bảo Vệ, Tạp Vụ](https://cloud.muaban.net/images/thumb-glist/2024/06/21/476/79c20bdbad414cbaac21cc0a47705293.jpg "SRS là gì? Phân biệt sự khác nhau giữa 3 tài liệu SRS, BRD và FRS")
![[HCM] Tuyển Dụng Nhân Sự THÁNG 7 - Bảo Vệ - Tạp Vụ - Đóng Gói](https://cloud.muaban.net/images/thumb-glist/2024/06/25/298/b562c925fc574bec931105c339057843.jpg "SRS là gì? Phân biệt sự khác nhau giữa 3 tài liệu SRS, BRD và FRS")
High Level Requirement – Yêu cầu mức tổng thể
Phần này bao gồm :
- Object Relationship Diagram: Mô hình này thể hiện mối quan hệ tĩnh giữa các đối tượng nêu trong hệ thống. Một đối tượng được xem như một thực thể cụ thể trong hệ thống.
- Workflow Diagram: Mục này hiển thị chuỗi công việc hoặc các bước thực hiện của người dùng. Mỗi hành động của người dùng sẽ được hiển thị trong từng giai đoạn quy trình nghiệp vụ của hệ thống.
- State Transition Diagram: Phần này mô tả trạng thái theo từng bước của workflow, giúp người đọc có thể biết được người thực hiện là ai, có tác động như thế nào đến trạng thái trong quy trình của hệ thống.
- Use Case Diagram: Sơ đồ này thể hiện cách những người dùng sử dụng, tương tác với các tính năng của hệ thống.
Security Requirement – Phần yêu cầu bảo mật
Phần này gồm các mô tả đầy đủ về nhiệm vụ, chức năng của người dùng, bên cạnh đó chỉ ra các quyền của người dùng. Ngoài ra, ở đây còn hiển thị bảng ma trận các nhiệm vụ của mỗi người sử dụng hệ thống.
Use Case Specification – Phần đặc tả Use Case
Phần này gồm các yêu cầu chức năng của hệ thống, đi kèm với mô tả chi tiết các nhiệm vụ cần được thực hiện về hành vi, đầu vào và đầu ra dự kiến. Bên cạnh đó, mục này còn hiển thị những tương tác giữa tác nhân bên ngoài vào hệ thống và kết quả của tương tác đó.
Wireframe – Thiết kế màn hình
Thiết kế màn hình là mục cho phép đính kèm tài liệu giúp cho người đọc có thể dễ dàng di chuyển đến màn hình hệ thống. Nhờ đó việc xác nhận yêu cầu chức năng hệ thống với khách trở nên nhanh chóng hơn, đồng thời giúp cho khách hàng dễ dàng hiểu và hình dung về hệ thống, thể hiện sự thấu hiểu các yêu cầu khách hàng của nhà phân tích nghiệp vụ. Ngoài ra, phần này còn giúp chứng minh năng lực của đội làm dự án.
Other Requirement – Các yêu cầu khác
Các yêu cầu bổ sung đối với hệ thống sẽ được thể hiện chi tiết tại đây. Phần này sẽ được chuyển đến các yêu cầu phi hệ thống.
Integration – Tích hợp
Phần này được sử dụng với mục đích đính kèm các tài liệu liên quan đến các hệ thống bên ngoài.
Appendices – Phụ lục
Phần này cho phép người dùng định nghĩa các lỗi tin nhắn (error message) hoặc các mẫu email (email template) dùng trong hệ thống.
Các bước chuẩn bị trước cho yêu cầu kiểm tra phần mềm
Bước 1: Lên kế hoạch và kiểm soát cho việc kiểm tra
Mục đích của bước này nhằm chỉ ra các loại kiểm tra cần được triển khai, bao gồm hai hành động chính:
Lên kế hoạch kiểm tra
- Xác định các phương hướng tiếp cận kiểm tra.
- Xác định chiến lược kiểm tra, mô tả các thành phần cần có trong một chu kỳ phát triển phần mềm như: các mục tiêu kiểm tra, các phương pháp kiểm tra, tổng thời gian và nguồn lực cho các dự án.
- Xác định các nguồn lực cần như: nhân lực, phần mềm, phần cứng, môi trường,…
- Lên lịch phân tích và thiết kế các trường hợp kiểm tra, thực hiện vaf đánh giá kết quả kiểm tra.
- Xác định các tiêu chí kết thúc việc kiểm tra.
Kiểm soát việc kiểm tra
- Đo lường, phân tích kết quả kiểm tra
- Theo dõi ghi lại tiến độ, độ bao phủ và các tiêu chí kết thúc kiểm tra
- Cung cấp thông tin về việc kiểm tra
- Tiến hành khắc phục (nếu cần)
- Ra quyết định.
Bước 2: Phân tích, thiết kế
Bước này nhằm chỉ định ra các test case và các bước chi tiết kiểm tra cho mỗi phiên PM.
Bước 3: Thực hiện kiểm tra
Tại bước này, người kiểm tra sẽ thực hiện các bước đã được thiết kế và ghi nhận kết quả.
Bước 4: Đánh giá kết quả nhận được và báo cáo
Toàn bộ quá trình kiểm tra sẽ được đánh giá, xem xét và đưa ra các yêu cầu thay đổi liên quan.
Bước 5: Đóng hoạt động kiểm tra
Bước này nhằm kết thúc việc kiểm tra phần mềm và sẵn sàng giao thành quả đến tay khách hàng.
Phân biệt các tài liệu SRS, BRD và FRS
Các Business Analyst thường phải biết cách tạo ra 9 tài liệu quan trọng, trong đó có 3 tài liệu rất dễ nhầm lẫn là SRS, BRD và FRS. Vậy điểm khác nhau và cách phân biệt 3 tài liệu này là gì?
BRD (viết tắt của Business Requirement Document) là tài liệu mô tả chiến lược của công ty cần đạt được. Ngoài ra, BRD còn thể hiện nhu cầu hay mối quan tâm 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, tài liệu này trả lời cho câu hỏi tại sao có các yêu cầu trên và kết quả mong đợi, sự thay đổi từ hệ thống. BRD được sử dụng bởi các nhà tài trợ, BA, nhà quản lý cấp cao và cấp trung.
FRS (viết tắt của Functional Requirement Specifications) là tài liệu thể hiện thông số kỹ thuật yêu cầu của chức năng. Đây là loại tài liệu được thể hiện chi tiết nhất trong 3 loại. Tài liệu này sẽ trả lời cho câu hỏi hệ thống dự kiến hoạt động “như thế nào” để thỏa mãn hay đạt được các yêu cầu nêu trong các tài liệu BRD và SRS.
FRS xây dựng nên các mô tả chi tiết, rõ ràng về từng yêu cầu chức năng trong từng trường cùng với sự tương tác của người dùng trên từng trang của hệ thống. FRS được tạo nên từ quan điểm của người sử dụng và cách mà hệ thống sẽ tương tác với họ. Tài liệu FRS sau khi hoàn thành sẽ được xem xét bởi quản lý dự án, sau đó sẽ đưa cho khách hàng để xác nhận lại lần cuối. Sau khi được xác nhận, đây sẽ là bản chuẩn về cách thức hoạt động của phần mềm.
Ngoài ra, bạn có thể dựa vào bảng sau để phân biệt 3 tài liệu SRS, BRD và FRS:
| Software Requirement Specification (SRS) | Business Requirement Document (BRD) |
Functional Requirement Specification (FRS) |
|
| Được tạo bởi | Business Analyst/ System Analyst | Business Analyst | Business Analyst/ System Analyst, Analyst Leads/ Implementation Leads |
| Bao gồm | Các chi tiết yêu cầu chức năng, phi chức năng và use cases | Yêu cầu mức tổng quát và yêu cầu của các bên liên quan. | Yêu cầu chức năng, sơ đồ luồng dữ liệu và UML |
| Được dùng bởi | Project Managers, SMEs, technical and implementation leads | Nhà quản trị cấp cao và cấp trung | Technical leads, đội phát triển và đội kiểm thử phần mềm |
| Giai đoạn |
Giai đoạn lập kế hoạch (Planning Phase) |
Invitation Phase. Đây là tài liệu đầu tiên trong quy trình phát triển của tổ chức |
Giai đoạn lập kế hoạch (Planning Phase) |
| Trả lời cho câu hỏi | “Cái gì” hay yêu cầu nào cần được đáp ứng. | “Tại sao” có các yêu cầu trên. |
Hệ thống dự kiến sẽ được hoạt động “như thế nào”. |
Tổng kết
Bên trên là những kiến thức về tài liệu đặc tả yêu cầu SRS cùng với tầm quan trọng của tài liệu này, những thành phần chính cấu tạo nên SRS, các bước chuẩn bị trước cho yêu cầu kiểm tra phần mềm và cách phân biệt 3 tài liệu SRS, BRD, FRS. SRS là tài liệu có vai trò vô cùng quan trọng, giúp cho đội phát triển phần mềm hiểu được chính xác những yêu cầu của khách hàng, từ đó tạo ra sản phẩm phù hợp.
Chính vì thế, nếu bạn quan tâm đến phát triển hệ thống thì đừng bỏ qua bài viết này nhé! Vẫn còn rất nhiều bài viết bổ ích đang chờ bạn đọc tại Muaban.net.
>>> Xem thêm:
- IT là gì? Những điều cần biết về công việc của ngành IT?
- RSM là gì? 5 yêu cầu không thể bỏ qua khi muốn trở thành một RSM chuyên nghiệp
- Chia sẻ kinh nghiệm du học Canada bổ ích và cần thiết nhất từ những người đi trước
