Trong thời kỳ hiện nay, với sự tiến bộ của Cách mạng Công nghiệp 4.0, nhiều doanh nghiệp phát triển phần mềm đã xuất hiện và phát triển mạnh mẽ. Tài liệu Specifying Requirements (SRS) được xem là tập hợp các yêu cầu về sản phẩm mà nhóm phát triển phần mềm cần thực hiện. Điều này làm cho SRS trở thành một phần quan trọng không thể thiếu trong quy trình phát triển phần mềm.
Bài viết này sẽ giải thích chi tiết về tài liệu SRS, đồng thời hướng dẫn cách xây dựng một tài liệu này một cách chuẩn mực. Chúng tôi sẽ cùng nhau tìm hiểu về nội dung của tài liệu SRS và các bước cần thực hiện để đảm bảo rằng nó đáp ứng các tiêu chuẩn chất lượng và hiệu suất trong quá trình phát triển phần mềm.
Tài liệu đặc tả yêu cầu SRS là gì?
Tài liệu SRS là gì?
Tài liệu SRS là viết tắt của “Software Requirement Specification,” được dịch là “tài liệu đặc tả yêu cầu” trong tiếng Việt. Đây là một tài liệu quan trọng trong quá trình phát triển hệ thống, chứa đựng thông tin chi tiết về các yêu cầu chức năng và phi chức năng của hệ thống. Nó không chỉ hỗ trợ việc xác định các tính năng cụ thể của hệ thống mà còn giúp các bên liên quan hiểu rõ hơn về cấu trúc và hoạt động của nó.
SRS đóng vai trò quan trọng đối với đội ngũ phát triển, bao gồm các chuyên gia phân tích hệ thống, chuyên gia kinh doanh và lập trình viên. Nó cũng là một tài liệu quan trọng cho đội kiểm thử. Nội dung của SRS bao gồm mô tả chi tiết về chức năng (FR) và phi chức năng (NFR) của hệ thống. Tài liệu này không chỉ làm cầu nối giữa người sử dụng và nhà phát triển, mà còn giúp đảm bảo rằng hệ thống sẽ đáp ứng đúng mục đích và yêu cầu của người sử dụng.
Bằng cách thống kê các yêu cầu, SRS cung cấp thông tin quan trọng để đánh giá phạm vi dự án, thời gian hoàn thành, và chi phí dự kiến. Điều này giúp đội ngũ phát triển đánh giá được số lượng công việc cần thực hiện, dự đoán thời gian và nguồn lực cần thiết, giúp tăng cường khả năng hoàn thành sản phẩm một cách hiệu quả và hiệu quả hơn.
Tầm quan trọng của tài liệu SRS
SRS là tài liệu đặc tả vô cùng quan trọng trong quá trình phát triển phần mềm, nó có vai trò:
- Giúp cho các bên thứ ba – stakeholders đều hiểu được hệ thống theo cùng một hướng, tránh trường hợp mỗi người một ý.
- Giúp cho đội phát triển xây dựng hệ thống một cách chính xác, đặc tả được các tính năng, không đi lạc hướng so với yêu cầu của khách hàng.
- SRS giúp tester hệ thống đọc hiểu từ đó xây dựng nên kịch bản kiểm thử chi tiết nhất.
- Giúp cho việc bảo trì hệ thống và cải tiến những chức năng của hệ thống một cách nhanh chóng và dễ dàng.
Tài liệu SRS giúp đội phát triển xây dựng sản phẩm một cách chính xác
Thành phần chính của tài liệu đặc tả yêu cầu SRS
Phần giới thiệu – Introduction
Phần đầu tiên của tài liệu SRS chính là phần giới thiệu. Phần này bao gồm các nội dung:
- Purpose: mô tả chi tiết về mục đích và ý nghĩa của tài liệu đặc tả yêu cầu, giúp người đọc hiểu được khái niệm và tầm quan trọng của nó.
- Application Overview: mô tả hệ thống một cách tổng quan. Nhìn chung, hệ thống phải đảm bảo dduocj các yếu tố như khái quát hệ thống, tính năng, quyền sử dụng, mục đích của hệ thống sinh ra để làm gì,…
- Intended Audience and Reading Suggestions: mô tả các đối tượng sở hữu tài liệu SRS và mục đích sử dụng.
- Abbreviations: danh sách các từ viết tắt và ý nghĩa giúp người đọc nắm rõ hơn.
- References: mục đính kèm mô tả các tài liệu liên quan.
Yêu cầu mức tổng thể (High Level Requirement)
Những thông tin chi tiết trong phần này gồm có:
- Object Relationship Diagram: mô hình thể hiện mối quan hệ tĩnh giữa các đối tượng của hệ thống. Một đối tượng được xem là một thực thể trong hệ thống.
- Workflow Diagram: là phần đảm nhiệm hiển thị chuỗi công việc hoặc các bước người dùng thực hiện. Mỗi hành động của người dùng hệ thống sẽ được hiển thị ở từng giai đoạn của hệ thống.
- State Transition Diagram: mô tả trạng thái theo từng bước của workflow từ đó người đọc có thể biết được ai là người thực hiện điều đoa và nó có tác động như thế nào đến trạng thái của hệ thống.
- Use Case Diagram: sơ đồ thể hiện cách người dùng sử dụng các tính năng của hệ thống.
Yêu cầu về bảo mật (Security Requirement)
Phần này nhằm mục đích trình bày chi tiết về nhiệm vụ của người dùng trong hệ thống, cũng như chức năng và quyền lợi mà họ có. Trong phạm vi này, bảng ma trận nhiệm vụ sẽ được hiển thị, mô tả rõ nhiệm vụ tương ứng với mỗi người sử dụng trong hệ thống.
Đặc tả Use Case (Use Case Specification)
Trong phần mô tả Use Case, việc xác định các chức năng của hệ thống và chi tiết hóa các nhiệm vụ liên quan đến hành vi, đầu vào và đầu ra là rất quan trọng. Đồng thời, phần này cũng tập trung mô tả những tương tác giữa các tác nhân bên ngoài và hệ thống, cũng như hiển thị kết quả của những tương tác đó.
Đặc tả Use Case mô tả những nhiệm vụ sẽ phải thực hiện về hành vi đầu vào và đầu ra
Thiết kế màn hình (Wireframe)
Thiết kế giao diện đóng vai trò quan trọng trong việc hỗ trợ người đọc trong việc tương tác với hệ thống. Điều này được thể hiện thông qua khả năng kết hợp các tài liệu một cách hợp lý để tạo ra một màn hình dễ dàng di chuyển. Mục tiêu chính của việc thiết kế giao diện là nhanh chóng và thuận tiện xác nhận yêu cầu chức năng từ phía khách hàng. Điều này giúp khách hàng có cái nhìn chính xác về cách hệ thống hoạt động và đồng thời thể hiện sự thấu hiểu đối với yêu cầu của họ từ phía các chuyên gia phân tích nghiệp vụ.
Các yêu cầu khác (Other Requirement)
Phần này sẽ thể hiện chi tiết các yêu cầu bổ sung đối với hệ thống, phần này sẽ chuyển đến các yêu cầu phi hệ thống.
Yêu cầu tích hợp (Integration)
Bạn có thể đính kèm các tài liệu hoặc các nội dung liên quan đến các hệ thống bên ngoài vào phần này.
Phụ lục (Appendices)
Mục đích của phần này là cho phép người dùng định nghĩa được các lỗi tin nhắn trong hệ thống hoặc các email mẫu trong hệ thống.
Phân biệt các tài liệu SRS, BRD và FRS
Các Business Analyst (BA) thường phải tạo ra 9 tài liệu quan trọng, trong đó có 3 tài liệu gây nhầm lẫn nhất là SRS, BRD và FRS. Để phân biệt được giữa chúng, hãy hiểu rõ về mỗi loại tài liệu.
Business Requirement Document (BRD) viết tắt của Tài liệu Yêu cầu Nghiệp vụ. Đây là tài liệu quan trọng nhất trong quá trình phát triển tổ chức. BRD chứa mô tả về chiến lược mà công ty đang cố gắng đạt được trong tương lai. Nó không chỉ ghi lại yêu cầu nghiệp vụ mà còn thể hiện mối quan tâm và nhu cầu của các bên liên quan đối với sản phẩm và dịch vụ cuối cùng. Nói một cách đơn giản, BRD trả lời câu hỏi vì sao có các yêu cầu cụ thể, mục tiêu mong đợi là gì, và sự thay đổi cần thiết từ hệ thống. BRD được thiết kế để phục vụ đối tượng sử dụng như nhà tài trợ, quản lý cấp cao, quản lý cấp trung và Business Analyst.
Vì vậy, để phân biệt giữa SRS, BRD và FRS, cần tập trung vào BRD như một tài liệu chiến lược, mô tả rõ ràng về mục tiêu và mong đợi của công ty, cũng như nhu cầu của các bên liên quan.
Sự khác biệt giữa các tài liệu BRD, FRD và SRS là gì?
FRS (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 chi tiết nhất trong 3 loại tài liệu này, nó sẽ hệ thống dự kiến hoạt động như thế nào để thỏa mãn các yêu cầu được nêu trong các tài liệu BRD và SRS.
FRS xây dựng mô tả chi tiết, rõ ràng từng yêu cầu chức năng trong từng trường, và 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 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ọ. Tài liệu FRS sau khi hoàn thành sẽ được đưa đến cho quản lý dự án xem xét, tiếp theo sẽ đưa cho khách hàng và được xác nhận lại lần cuối. Sau khi được xác nhận, tài liệu này sẽ là bản chuẩn về cách thức hoạt động của phần mềm.
Tổng kết
Dưới đây là những kiến thức liên quan đến tài liệu SRS, bao gồm các thành phần quan trọng của nó và cách phân biệt SRS với các tài liệu BRD và FRS. Sau khi đọc bài viết, bạn đã có hiểu biết về tài liệu SRS chưa? SRS, hay tài liệu đặc tả yêu cầu, đóng một vai trò vô cùng quan trọng trong quá trình phát triển hệ thống. Nó giúp đội ngũ phát triển hiểu rõ hơn về các yêu cầu của khách hàng, từ đó có thể tạo ra sản phẩm đáp ứng đầy đủ nhu cầu và mục đích sử dụng của họ. Do đó, nếu bạn đang mơ ước trở thành một nhà phát triển hệ thống hoặc một kiểm thử viên, hãy không bao giờ bỏ qua tài liệu này. Hãy duy trì việc theo dõi trên trang web để cập nhật những thông tin hữu ích nhất.
