1
Bạn cần hỗ trợ?

Nhận định Srs Là Gì – Phân Biệt Các Tài Liệu Brd Vs Srs Vs Frs

Review Srs Là Gì – Phân Biệt Các Tài Liệu Brd Vs Srs Vs Frs là conpect trong content hiện tại của Myphamngahan.com. Theo dõi bài viết để biết đầy đủ nhé.


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ử.

Bạn đang xem: Srs là gì

2. Tại sao lại cần tài liệu SRSGiú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 SRSIntroduction – Giới thiệuHigh Level Requirement – Yêu cầu mức tổng thể Security Requirement – Các yêu cầu về bảo mậtUse Case Specification – Đặc tả use case Wireframe – Thiết kế các màn hìnhOther Requirement – Các yêu cầu khácIntegration – Yêu cầu tích hợpAppendices – Phụ lục

*

4. Mục IntroductionChi 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.

Xem thêm: Calo Là Gì – Calo: Không Chỉ Là Con Số!

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ốngError 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.

Xem thêm: Cgi Là Gì – Cgi Hoạt động Như Thế Nào

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.

Chuyên mục: Hỏi Đáp