-Tài Liệu SRS là Gì ?

Tài liệu SRS là từ viết tắt của Software Requirement Specification.

Dịch ra tiếng việt là tài liệu đặc tả yêu cầu.
SRS là tài liệu được sử dụng để mô tả chi tiết các yêu cầu chức năng và phi chức năng
của hệ thống. Tài liệu này sẽ hỗ trợ đưa ra các tính năng của hệ thống hay dùng cho
việc đọc hiểu hệ thống của bên thứ ba liên quan đến công ty. Đây là một tài liệu quan
trọng cho đội phát triển (system analyst, business analyst, code) và kiểm thử (tester).
Nội dung của SRS là mô tả các chức năng và cấu trúc của hệ thống là FR và NFR.

SRS còn đóng vai trò là cầu nối liên kết giữa người dùng và nhà sáng tạo và từ đó hệ
thống có thể đáp ứng được đúng mục đích và yêu cầu của người sử dụng.

Ngoài ra, dựa vào các yêu cầu mà SRS thống kê, ta có thể đánh giá được số lượng
scope, thời gian hoàn thành hay những chi phí cần đáp ứng giúp hoàn thành sản phẩm
một cách nhanh chóng và dễ dàng hơn.

-Tác dụng của SRS

- Nó Giúp cho các bên thứ ba – stakeholders có liên quan đến doanh
nghiệp có thể hiểu được hệ thống theo cùng một ý nghĩa và tránh việc
hiểu sai , mỗi người hiểu một cách khác nhau.
- Dựa Vào Việc tham khảo ý kiến của khách hang thì tài liệu srs 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.
- Ngoài ra ,nó còn giúp các nhà kiểm thử hệ thống có khả năng đọc hiểu dẽ
dàng hơn , 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.

 Với những lợi ích trên của tài liệu srs thì chúng ta có thể thấy được tầm quan
trọng của tài liệu này là rất lớn với hệ thống và hỗ trợ đắc lực cho các nhà
phân tích và kiểm thử .

-Những thành phần chính có trong SRS

Thành phần chính của tài liệu đặc tả yêu cầu SRS

(8 phần)

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)

Nhiệm vụ của phần này là mô tả đầy đủ về nhiệm vụ của người dùng hệ
thống, chức năng của người dùng, đồng thời chỉ ra các quyền của người
dùng trong hệ thống. Bảng ma trận các nhiệm vụ với mỗi người sử dụng
hệ thống sẽ được hiển thị trong phần này.

Đặc tả Use Case (Use Case Specification)

Tại phần đặc tả Use Case, các chức năng của hệ thống và mô tả chi tiết
các nhiệm vụ sẽ phải thực hiện về hành vi và đầu vào, đầu ra. Cùng với
đó, những tương tác của những tác nhân bên ngoài vào hệ thống và kết
quả của việc tương tác đó sẽ được hiển thị ở phần này.

Đặ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ế màn hình là mục có thể đính kèm tài liệu để người đọc có thể dễ
dàng di chuyển trên màn hình hệ thống. Mục đích của việc thiết kế màn
hình là xác nhận yêu cầu về chức năng hệ thống với khách hàng một cách
nhanh chóng, dễ dàng, giúp khách hàng có cái nhìn chính xác về hệ thống,
thể hiện sự thấu hiểu yêu cầu khách hàng của các nhà 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.
-Những tài liệu giống SRS
Ngoài SRS tài liệu thì còn những loại tài liệu khác , ví dụ như là: BRD ,
PVD , FRS

1 . BRD
Theo định nghĩa được công nhận trên toàn thế giới về BRD là:
Tập hợp các yêu cầu nghiệp vụ và yêu cầu của các bên liên quan
(BRD ghi lại những mong muốn của doanh nghiệp hơn là các yêu
cầu)
BRD thường là loại tài liệu có đầu tiên trong quy trình phát triển
của tổ chức. Nó mô tả chiến lược của công ty mà họ đang nỗ lực
để đạt được trong tương lai bằng cách tạo ra một sản phẩm/ dịch
vụ. Bên cạnh đó, BRD còn bao gồm mối quan tâm/ nhu cầu của
các bên liên quan đến sản phẩm/dịch vụ cuối cùng. Nói cách
khác, BRD là câu trả lời cho câu hỏi “Tại sao?” Có các yêu cầu
trên, kết quả mong đợi – sự thay đổi gì từ hệ thống.
Ví dụ về BRD: Công ty muốn cải thiện hiệu suất làm việc bằng
cách theo dõi thời gian dành cho từng hoạt động của nhân viên.
Người BA luôn luôn là người chuẩn bị tài liệu này sau những buổi
nói chuyện đầu tiên với doanh nghiệp và các bên liên quan. Sự
xác nhận cuối cùng lại từ những bên liên quan chính sẽ là đảm
bảo rằng BA đã nắm bắt chính xác kì vọng của họ cũng như tại
sao họ muốn như vậy .
Đối tượng sử dụng BRD là các nhà tài trợ, quản lí cấp cao, quản lí
cấp trung và BA.

2. PVD
Là loại tài liệu ghi nhận lại tầm nhìn và những kết quả mong đợi
trong tương lại đối với dự án. Cụ thể hơn, PVD sẽ làm rõ các câu
hỏi chính như:
Lý do tại sao nên thực hiện dự án này?
 Mục đích của dự án để phục vụ nhu cầu nào hay giải quyết
vấn đề gì?
Phạm vi dự án như thế nào? Ai sẽ là những có ảnh hưởng và
bị ảnh hưởng khi thực thi dự án này?
Kết quả mong đợi của dự án là gì và nó sẽ được đo lường
trên những tiêu chí nào? 
Đối tượng sử dụng PVD là bộ phận quản lí cấp cao bên phía
doanh nghiệp và BA để có thể chắc rằng những hai bên đã
hiểu rõ và hiểu đúng những kết quả thay đổi mong đợi
trong tương lai với doanh nghiệp. 

3. FRS
FRS là loại tài liệu chi tiết nhất trong 3 loại trên, và sẽ là loại tài
liệu cuối cùng trả lời cho câu hỏi “Như thế nào?”, tức là hệ
thống dự kiến sẽ hoạt động như thế nào để làm thỏa mãn các yêu
cầu nêu trong BRD và SRS.
Theo định nghĩa đã được công nhận, FRS là tài liệu chi tiết để xây
dựng đầy đủ các tiểu tiết có trong yêu cầu chức năng của dự án.
FRS xây dựng các mô tả chi tiết, rõ ràng từng yêu cầu chức năng
trong từng trường, và tương tác của người dùng trên từng trang
của hệ thống.
FRS được thể hiện dưới các process flow diagrams (tạm dịch: sơ
đồ dòng quy trình), UML diagrams, wireframs.
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ọ. Lúc này, team Dev sẽ phải rõ chính xác họ
cần làm gì và team QA/testing cần biết có những kịch bản test
nào cho hệ thống.
Tài liệu FRS do BA hoặc SA chuẩn bị, và sau khi hoàn thành sẽ
đưa cho quản lí dự án xem xét. Tiếp theo, FRS sẽ được được đưa
cho khách hàng, xác nhận lại lần cuối. Một khi đã có sự xác nhận
của các bên, tài liệu này sẽ là bản tiêu chuẩn về cách thức hoạt
động của phần mềm.
Đối tượng sử dụng FRS là trưởng bộ phận kỹ thuật, Team Dev và
Team Testing.