Tài Liệu Srs Là Gì, Khái Niệm Mà Bất Cứ BA Nào Cũng Phải Thuộc Lòng
Có thể bạn quan tâm
Vậy chúng ta hãy cùng timviec365.vn tìm hiểu về khái niệm tài liệu SRS qua bài viết dưới đây nhé.
1. Khái niệm về tài liệu SRS
Để hiểu ứng dụng và cách sử dụng tài liệu SRS thì trước tiên bạn phải nắm được khái niệm và định nghĩa xem nó là gì.
Tài liệu SRS là từ viết tắt của Software Requirements Specification dịch ra tiếng Việt là tài liệu đặc tả yêu cầu, đây là loại tài liệu dùng để mô tả một cách chi tiết các yêu cầu chức năng, phi chức năng của hệ thống. Tài liệu này sẽ hỗ trợ để đưa ra một mức độ cao nhóm các module hoặc các tính năng của hệ thống, được dùng cho việc đọc tất cả Stakeholders (Stakeholders là những người ở bên thứ ba, liên quan đến một công ty, ví dụ họ có thể là các cổ đông,...). Đây là tài liệu quan trọng cho system analyst và business Analyst.
Tài liệu SRS sẽ mô tả các chức năng và cấu trúc của hai hệ thống là FR và NFR. Tài liệu SRS đóng vai trò là cầu nối liên kết giữa những gì BR muốn và từ đó hệ thống có thể đáp ứng mà thực hiện được.
Nhờ vào các yêu cầu mà SRS liệt kê ra, nó giúp cho việc tính toán các chi phí hay ước lượng scope của dự án mà bạn thực hiện nhanh chóng và dễ dàng hơn.
Ứng tuyển ngay: Việc làm Business Analyst
2. Tầm quan trọng của tài liệu SRS
Thứ nhất ,tài liệu SRS giúp cho các stakeholders đều cùng hiểu được hệ thống theo cùng một hướng mà không để phải xảy ra tình trạng chín người mười ý.
Thứ hai, dựa vào yêu cầu của khách hàng, tài liệu SRS giúp cho các đội phát triển hệ thống xây dựng được chính xác các tính năng, không đi lạc hướng.
Thứ ba, tài liệu SRS giúp cho các nhà kiểm thử hệ thống có thể đọc hiểu được từ đó mà viết được các trường hợp thử nghiệm.
Vào ngày thứ tư, tài liệu SRS hỗ trợ việc duy trì và nâng cấp các chức năng của hệ thống một cách nhanh chóng và thuận tiện hơn.
Đọc ngay: Bên trong bản mô tả công việc Business Analyst có gì?
3. Các thành phần chính trong tài liệu SRS:
3.1. Phần đầu tiên của sẽ là phần giới thiệu của tài liệu SRS (Introduction)
Chi tiết trong phần giới thiệu sẽ gồm:
- Purpose sẽ là mục mô tả chi tiết về các mục đích và ý nghĩa của tài liệu SRS, giúp cho ta hiểu được khái niệm của tài liệu SRS tầm quan trọng của nó.
- Application Overview là mục mô tả về hệ thống một cách tổng quan. Hệ thống nhìn chung phải đảm bảo được các yếu tố như khái quát về hệ thống, tính năng là gì, quyền sử dụng là của ai, mục đích của hệ thống sinh ra làm gì,...
- Đối tượng và Gợi ý Đọc, phần này sẽ mô tả người đích thực và mức đích sử dụng tài liệu SRS
- Abbreviations: ở mục này các mục viết tắt sẽ được định nghĩa giúp người dùng nắm rõ hơn.
- References: đây là mục dùng cho việc đính kèm, mô tả các tài liệu liên quan mà bạn muốn.
Khám phá thêm: Giúp CEO khai thác Bộ tài liệu quản lý 4.0 hiệu quả
3.2. Phần thứ hai là yêu cầu mức tổng thể (High Level Requirement)
Chi tiết trong phần này sẽ gồm có
- Object Relationship Diagram: đây là một mô hình thể hiện mối quan hệ tĩnh giữa các đối tượng ở trong hệ thống. Một đối tượng sẽ được xem như là một thực thể cụ thể trong hệ thống.
- Workflow Diagram: đây là phần sẽ đảm nhiệm hiển thị chuỗi công việc hoặc các bước mà người dùng thực hiện để quy trình kinh doanh được hoàn tất. Mỗi hành động mà người sử dụng hệ thống thực hiện sẽ được hiển thị ở từng giai đoạn của quy trình hệ thống.
- State Transition Diagram: phần này sẽ mô tả từng trạng thái theo từng bước của workflow. Người dùng nhìn vào thì có thể biết được ai đã là người thực hiện điều đó và những hành động đó thì có những tác động đến trạng thái của quy trình hệ thống như thế nào.
- Use Case Diagram: Đây là sơ đồ thể hiện cách mà người dùng hệ thống sử dụng các tính năng như thế nào.
Đừng bỏ qua: SDLC là gì? Bí mật thú vị về vòng đời phát triển phần mềm
3.3. Phần thứ ba là các yêu cầu về bảo mật (Security Requirement)
Phần này sẽ đảm nhiệm nhiệm vụ mô tả một cách đầy đủ về các nhiệm vụ của mỗi người trong hệ thống, chức năng của các người đó sẽ là gì. Đồng thời chỉ ra rằng từng người sẽ có quyền gì trong hệ thống.
Bảng ma trận về các nhiệm vụ tương ứng sẽ tương ứng với mỗi người trong hệ thống.
3.4. Phần thứ tư là đặc tả use case (Use Case Specification)
Đây là phần gồm những chức năng của hệ thống và mô tả chi tiết các nhiệm vụ hệ thống phải thực hiện về hành vi và đầu vào, đầu ra. Đồng thời phần này thể hiện sự tương tác của các tác nhân tác động vào hệ thống và hệ thống và kết quả của việc tương tác đó.
3.5. Phần thứ năm là thiết kế các màn hình (Wireframe )
Đây là mục mà bạn có thể đính kèm tài liệu để người đọc có thể di chuyển được đến màn hình của hệ thống.Một số các chức năng của thiết kế màn hình là có thể xác nhận yêu cầu về chức năng hệ thống đối với mỗi khách hàng một cách nhanh chóng và dễ dàng hơn, đề cho khách hàng có thể dễ dàng hiểu được và có cái nhìn chính xác về hệ thống, thể hiện được sự thấu hiểu yêu cầu của khách hàng của các nhà phân tích nghiệp vụ và thể hiện năng lực của các nhóm trong dự án.
3.6. Phần thứ sáu là 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 về hệ thống, phần này sẽ thuộc về bên các yêu cầu phi hệ thống.
3.7. Phần thứ bảy là yêu cầu tích hợp (Integration)
Đây là mục mà bạn có thể đính kèm tài liệu hoặc mô tả các nội dung liên quan đến các hệ thống bên ngoài.
3.8. Phần thứ tám là phụ lục (Appendices)
Mục này sẽ có hai nội dung cho phép bạn định nghĩa ra được các lỗi tin nhắn trong hệ thống hoặc các email bản mẫu trong hệ thống.
Tham khảo: Nghề Business Analyst là gì? Và những hiểu biết về Business Analyst
4. Cẩn thận tránh nhầm lẫn giữa các tài liệu SRS, BRD và FRS
Các Business Analyst nào cũng phải tạo ra 9 loại tài liệu quan trọng trong đó có 3 loại tài liệu dễ nhầm lẫn là SRS, BRD và FRS, các bạn hãy cũng theo dõi phần dưới đây để tránh nhầm lẫn nhé.
Tài liệu BRD là từ viết tắt của cụm từ Business Requirement Document có nghĩa là tài liệu về yêu cầu nghiệp vụ. Đây là loại tài liệu đầu tiên được tạo ra trong quy trình phát triển của một hệ thống công ty. Tài liệu này miêu tả các chiến lược của công ty trong tương lai mà công ty muốn đạt được với hiệu quả cao nhất.
Những người được phép sử dụng BRD là các nhà tài trợ của công ty hay dự án nào đó, quản lí và BA.
Tài liệu FRS là từ viết tắt của cụm từ Functional Requirement Specifications được hiểu là tài liệu yêu cầu chức năng. Đây là tài liệu chi tiết nhất so với tài liệu SRS và BRD và đây là tài liệu sẽ có nhiệm vụ cuối cùng, dự kiến các hoạt động của hệ thống làm sao để đáp ứng được hai yêu cầu của hệ thống trên.
Trên đây là những nội dung về tài liệu SRS, sẽ giúp các bạn chưa biết hoặc hiểu chưa rõ về SRS là gì và bao gồm những thành phần gì.
Từ khóa » Trong Srs Thì Yêu Cầu Có Thể Chia Ra Thành Các Lọai Nào Sau đây
-
SRS Là Gì Và Tầm Quan Trọng Của Tài Liệu Này Trong Quy Trình Sản Xuất ...
-
250 CÂU HỎI TRẮC NGHIỆM CÔNG NGHỆ PHẦN MỀM CÓ ĐÁP ÁN
-
Yêu Cầu Có Thể Chia Ra Thành Các Lọai Nào Sau đây?
-
Phân Tích Yêu Cầu Phần Mềm - Viblo
-
Tìm Hiểu Tài Liệu Srs Là Gì? Những điều Nên Biết Về Tài Liệu Này
-
Tài Liệu SRS Là Gì? Tìm Hiểu Vai Trò Và Cách Viết Tài Liệu SRS
-
SRS Là Gì? Phân Biệt Sự Khác Nhau Giữa 3 Tài Liệu SRS, BRD Và FRS
-
Tài Liệu 250 Câu Hỏi Trắc Nghiệm Công Nghệ Phần Mềm Có đáp án
-
Phân Biệt Các Tài Liệu BRD Vs SRS Vs FRS - BAC
-
Yêu Cầu Có Thể Chia Ra Thành Các Lọai Nào Sau đây?
-
Các Loại Tài Liệu Yêu Cầu Trong Dự án Phần Mềm | CodeStar Academy
-
Viết đặc Tả Use Case Sao đơn Giản Nhưng Hiệu Quả?
-
[PDF] TỰ ĐỘNG SINH BỘ KIỂM THỬ DỰA TRÊN TÀI LIỆU ĐẶC TẢ YÊU ...
-
Mời Thầu Dịch Vụ Thuê Ngoài Phát Triển Phần Mềm - SeABank