Tài liệu SRS là gì? Khái niệm mà bất cứ BA nào cũng cần biết

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

Tài liệu SRS là từ viết tắt Software Requirements Specification dịch ra tiếng Việt là tài liệu đặc tả, đây là một loại tài liệu dùng để mô tả một cách chi tiết nhất về những chức năng, yêu cầu, phi chức năng của hệ thống.

Tài liệu này sẽ có thể hỗ trợ để có thể đưa ra được một mức độ cao những nhóm các module hoặc những tính năng của hệ thống và được dùng trong việc đọc toàn bộ những stakeholders - Stakeholders là những người thuộc bên thứ ba, liên quan tới một công ty ví dụ như họ có thể là những cổ đông. Đây được xem là một tài liệu quan trọng cho system analyst và business Analyst.

Tài liệu SRS sẽ mô tả toàn bộ những chức năng và những cấu trúc của hai hệ thống là NFR và FR, tài liệu SRS còn đóng một vai trò là cầu nối liên kết giữa nhưng gì mà BR muốn và từ đó hệ thống có thể đáp ứng và thực hiện được. Nhờ vào những yêu cầu mà SRS đã liệt kê ra, nó có thể giúp cho việc tính toán được những chi phí hoặc ước lượng scope của dự án mà bạn có thể thực hiên dễ dàng và nhanh chóng hơn nhiều.

Sự quan trọng của tài liệu SRS

Đầu tiên, tài liệu SRS giúp cho những stakeholders sẽ đều có thể hiểu được hệ thống theo cùng một hướng mà không để xảy ra những tình trạng chín người mười ý, thứ hai dựa vào những yêu cầu của khách hàng mà tài liệu SRS có thể giúp cho đội phát triển hệ thống có thể xây dựng được chuẩn xác nhất những tính năng và không đi lạc hướng.

Thứ ba đó là tài liệu SRS giúp cho nhiều nhà kiểm thử hệ thống có thể đọc hiểu được và từ đó viết được những trường hợp thử nghiệm. Thứ tư là tài liệu SRS còn 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 dễ dàng và nhanh chóng hơn nhiều.

Một dự án phần mềm có thể được khởi đầu và hoàn thành mà không cần sử dụng tới những tài liệu như SRS, điều này chỉ dành cho những loại dự án nhỏ nhất trong một thời gian vô cùng ngắn nhưng đối với những kỳ dự án phần mềm nào đã được thực hiện trong hơn một tuần, bạn cần phải có SRS.

SRS còn giúp xác định được mục tiêu và phạm vi chi tiết nhất của một dự án phần mềm, có thể cung cấp một cái nhìn tổng quát nhất về những dự án trước khi bắt đầu. SRS còn tạo thêm cơ sở cho sự thống nhất giữa đơn vị phát triển và khách hàng về những gì mà sản phẩm phần mềm có thể dự kiến sẽ thực hiện, mô tả đủ nhất và chi tiết nhất về những chức năng mong muốn của phần mềm đã được chỉ định trong SRS. Điều này sẽ có thể giúp cho người dùng cuối cùng có thể xác minh xem phần mềm có thể đáp ứng được những nhu cầu đã được chỉ định hay chưa, nếu không có SRS thì những nhà phát triển phần mềm sẽ không biết rằng họ hiện có đang phát triển sản phẩm theo đúng những nhu cầu của khách hàng hay không?

SRS còn giúp tối ưu hoá được quá trình phát triển phần mềm, việc chuẩn bị SRS yêu cầu bắt buộc những bên liên quan phải suy nghĩ kỹ lưỡng về toàn bộ những yêu cầu của họ trước khi việc thiết kế phần mềm được bắt đầu, do vậy mà có thể giảm thiểu những những thao tác thiết kế lại, kiểm thử và mã hoá lại. SRS chính là cơ sở đánh giá, cải tiến cũng như bảo trì phần mềm, việc kiểm tra kỹ lưỡng trong và sau khi phát triển phần mềm sẽ sớm phát hiện ra những sai sót giúp khắc phục được vấn đề dễ dàng hơn nhiều.

Những thành phần chính trong tài liệu SRS

Phần đầu tiên 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ẽ bao gồm

• Purpose sẽ là mục mô tả chi tiết nhất về những mục đích và ý nghĩa của tài liệu SRS, giúp cho ta có thể hiểu được những khái niệm của tài liệu SRS và sự quan trọng của nó.
• Application Overview là mục mô tả về những hệ thống một cách tổng quan nhất, hệ thống nhìn chung phải chắc chắn đảm bảo được nhưng yếu tố tổng quát về hệ thống, tính năng ra sao, quyền sử dụng của ai, mục đích của hệ thống được xây dựng ra làm gì?
• Intended Audience and Reading Suggestions đây được xem là một mục mô tả những đối tượng sở hữu tài liệu SRS và họ sẽ có những mục đích gì.
• Abbreviations: Tại mục này, những mục viết tắt sẽ có thể được định nghĩa giúp cho người dùng có thể nắm rõ hơn nữa.
• References: Đây được xem là mục dùng cho việc mô tả hoặc đính kèm những loại tài liệu liên quan mà bạn mong muốn.

Phần thứ hai yêu cầu mức tổng thể - High level requirement

Chi tiết trong phần thứ hai sẽ bao gồm những điều như sau:

• Object Relationships Diagram: Đây là một mô hình thể hiện mối quan hệ tĩnh giữa những đối tượng trong một hệ thống, một đối tượng sẽ được xem như là một thực thể chi tiết nhất trong hệ thống đó.
• Workflow Diagram: Đây được coi là một phần có vai trò đảm nhiệm và hiển thị chuỗi công việc hoặc những bước mà người dùng sẽ thực hiện để có thể quy trình kinh doanh được hoàn tất, mỗi một hành động mà người sử dụng hệ thống thực hiện sẽ hiển thị đầy đủ tron mỗi một giai đoạn của quy trình trong hệ thống.
• State Transition Diagram: Phần này được biết sẽ mô tả mỗi một trạng thái theo mỗi bước của workflow, người dùng nhìn vào có thể biết được ai đã là người thực hiện những hành động đó và những hành động này sẽ có những sự tác động tới trạng thái của quy trình hệ thống ra sao.
• Use Case Diagram: Đây là một sơ đồ thể hiện cách mà những người dùng hệ thống sẽ sử dụng những tính năng ra sao.

Phần thứ ba yêu cầu về sự bảo mật - Security Requirement

Phần này được biết sẽ đảm nhiệm những nhiệm vụ mô tả một cách chi tiết và đầy đủ nhất những nhiệm vụ của mỗi một người thuộc hệ thống đó, chức năng của những người đó là gì, đồng thời chỉ ra rằng mỗi một con người sẽ có quyền hành gì trong hệ thống đó.

Bảng ma trận về những nhiệm vụ tương ứng cũng sẽ tương ứng với mỗi một người trong hệ thống đó.

Phần thứ từ là đặc tả use case - Use case specification

Đây được biết là phần bao gồm những chức năng của hệ thống và có thể mô tả chi tiết nhất những nhiệm vụ hệ thống phải thực hiện về những hành vi đầu ra và đầu vào, đồng thời thì phần này thể hiện sự  tương tác của những tác nhân đã tác động vào hệ thống và hệ thống kết quả của việc tương tác đó.

Phần thứ năm - Thiết kế những màn hình - Wireframe

Đây được xem là một mục mà bạn có thể đính kèm thêm tệp tài liệu để người  đọc có thể di chuyển được tới màn hình của hệ thống và một số những 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ề những chức năng hệ thống đối với mỗi một khách hàng một cách dễ dàng và nhanh chóng nhất, để khách hàng có thể nhanh chóng và dễ dàng có cái nhìn chuẩn xác nhất về hệ thống, thể hiện được sự thấu hiểu rõ hơn về nhưng mong muốn và yêu cầu của khách hàng của nhiều nhà phân tích nghiệp vụ và thể hiện được năng lực của những nhóm trong dự án đó.

Phần thứ sáu - Những yêu cầu khác - Other Requirement

Phần này sẽ thể hiện những chi tiết, những yêu cầu về bổ sung trong hệ thống, và phần này sẽ thuộc về những bên yêu cầu phi hệ thống.

Phần thứ bảy - Yêu cầu tích hợp - Integration

Đây là một mục mà bạn có thể đính kèm tài liệu cũng như những mô tả các nội dung có liên quan tới những hệ thống bên ngoài.

Phần thứ tám - Phụ lục - Appendices

Mục này thông thường sẽ có hai loại nội dung cho phép bạn có thể định nghĩa ra được những loại lỗi tin nhắn trong hệ thống hoặc những loại email bản mẫu có trong hệ thống.

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

Những Business Analyst nào cũng nên tạo ra 9 loại tài liệu quan trọng và trong đó có tới ba loại tài liệu dễ và thường xuyên bị nhầm lẫn nhất đó là FRS, BRD và SRS, các bạn cũng hãy theo dõi phần dưới đây để tránh nhầm lẫn nhé.

Được biết tài liệu BRD là cụm từ viết tắt của cụm từ Business Requirement Document, có nghĩa là tài liệu và những yêu cầu nghiệp vụ, đây là một loại tài liệu đầu tiên mô tả được tạo ra quy trình phát triển của hệ thống trong công ty, tài liệu này mô tả những chiến lược của công ty có trong tương lai mà công ty mong muốn đạt được với hiệu quả cao nhất. Những người được quyền sử dụng tài liệu BRD là những nhà tài trợ của dự án hoặc công ty nào đó, quản lý và BA.

Tài liệu FRS là cụm từ viết tắt của cụm từ Functional Requirement Specifications và được hiểu là những tài liệu yêu cầu chức năng này, đây được xem là một tài liệu chi tiết nhất khi so sánh với tài liệu BRD và tài liệu SRS và đây được xem là tài liệu sẽ có những nhiệm vụ cuối cùng và được dự kiến có những hoạt động của hệ thống làm sao để có thể đáp ứng được hai yêu cầu của hệ thống trên.

Hy vọng những thông tin trên đã giúp bạn hiểu rõ hơn về khái niệm SRS và những thông tin có liên quan tới tài liệu SRS nhé.