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

Hiện nay, Business Analyst được viết tắt là BA là một ngày nghề mới mẻ nhưng cũng thu hút một lượng lớn người lớp trẻ với mức lương hấp dẫn và tính chất công việc khá thú vị. Tuy nhiên để bắt đầu trên con đường tương lai là một chuyên viên phân tích giải pháp thì bạn không được bỏ qua tài liệu SRS hay còn gọi là tài liệu đặc tả yêu cầu, một thứ quan trọng của ngành nghề này.

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

Khái niệm về tài liệu SRS

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.

Tầm quan trọng của tài liệu SRS

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.

Thứ tư, tài liệu SRS giúp cho việc bảo trì hệ thống và cải tiến các chức năng của hệ thống nhanh chóng và dễ dàng 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)

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ì,…

– Intended Audience and Reading Suggestions, đây là mục sẽ mô tả các đối tượng sở hữu tài liệu SRS và họ sẽ có mục đích làm gì 

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

Các yêu cầu về bảo mật (Security Requirement)

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 )

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

Cẩn thận tránh nhầm lẫn giữa các tài liệu SRS, BRD và FRS

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

Test scenario là gì?Tìm hiểu về kịch bản kiểm thử này đầy đủ nhất

Sau khi hiểu rõ về tài liệu SRS thì bạn có thể hứng thú đối với test scenario, một lĩnh vực có liên qua đến SRS.

Test scenario là gì

Chia sẻ: