Hỏi đáp công nghệ

SRS là gì? Cách viết tài liệu SRS cực hiệu quả

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Table of Contents

Các đặc tả yêu cầu rõ ràng, ngắn gọn và có thể thực thi được giúp các nhóm phát triển tạo ra một sản phẩm phù hợp. Làm thế nào để chúng ta tổ chức và trình bày các yêu cầu này? Đó là lý do chúng ta cần đến Tài liệu đặc tả yêu cầu phần mềm, hay còn gọi là SRS. Nhưng SRS là gì và khi nào bạn nên sử dụng nó?

Trong blog này, Hỏi đáp Công nghệ sẽ phác thảo một bản tài liệu đặc tả yêu cầu điển hình, bao gồm cách xác định mục đích của sản phẩm, mô tả những gì bạn đang xây dựng, nêu chi tiết các yêu cầu và cuối cùng, cung cấp nó để được phê duyệt. Chúng ta cùng bắt đầu nhé!

srs là gì
SRS là gì?

SRS là gì?

SRS được viết tắt của software requirements specification, dịch sang tiếng Việt là tài liệu đặc tả yêu cầu. SRS là tài liệu mô tả phần mềm sẽ hoạt động như thế nào và dự kiến ​​sẽ hoạt động ra sao. Nó cũng mô tả chức năng mà sản phẩm cần để đáp ứng tất cả các nhu cầu của các bên liên quan (doanh nghiệp, người dùng).

Một SRS có thể được tóm tắt đơn giản gồm 4 yếu tố sau:

  • Xác định mục đích của sản phẩm.
  • Mô tả những gì bạn đang xây dựng.
  • Chi tiết các yêu cầu.
  • Giao nó để được phê duyệt.

Một tài liệu SRS tốt sẽ xác định mọi thứ từ cách phần mềm sẽ tương tác khi được nhúng vào phần cứng cho đến các kỳ vọng khi được kết nối với phần mềm khác. Một tài liệu SRS tốt hơn cũng tính đến người dùng trong đời thực và sự tương tác giữa con người với sản phẩm.

Tại sao tài liệu SRS rất quan trọng?

SRS cung cấp cho bạn một bức tranh toàn cảnh về toàn bộ dự án mà bạn tham gia. Nó cung cấp một nguồn chân lý duy nhất và thống nhất mà mọi nhóm tham gia phát triển sẽ tuân theo. Đó là kế hoạch hành động cho dự án và giữ cho tất cả các nhóm tham gia – từ nhóm phát triển đến bảo trì – có cùng một tầm nhìn.

Bố cục này không chỉ giữ cho các nhóm của bạn hoạt động đồng bộ mà còn đảm bảo đáp ứng được từng yêu cầu cụ thể. Cuối cùng, nó có thể giúp bạn đưa ra các quyết định quan trọng về vòng đời của sản phẩm, chẳng hạn như khi nào nên gỡ bỏ một tính năng lỗi thời.

Thời gian cần thiết để viết một SRS được tùy thuộc vào từng giai đoạn phát triển. Nó cho phép nhóm của bạn hiểu rõ hơn về sản phẩm, về nội bộ nhóm và thời gian hoàn thành dự án.

Tóm lại, tài liệu đặc tả SRS có vai trò vô cùng quan trọng trong quá trình phát triển một phần mềm với các vai trò như sau:

  • Giúp cho các bên thứ ba – các stakeholders cùng tất cả các nhóm tham gia dự án dễ dàng hiểu được hệ thống theo cùng một hướng, tránh trường hợp mỗi người hiểu một cách.
  • Giúp cho đội developer xây dựng hệ thống một cách chính xác, chuẩn chỉnh, đặc tả được các tính năng, không đi lạc hướng và gây sai sót so với yêu cầu của khách hàng.
  • SRS giúp tester hệ thống đọc hiểu từ đó xây dựng nên một kịch bản kiểm thử chi tiết nhất.
  • Giúp cho việc bảo trì và cải tiến các chức năng của hệ thống một cách nhanh chóng và dễ dàng nhất.

Cách viết tài liệu SRS

srs là gì
SRS là gì? Cách viết tài liệu SRS

Viết một tài liệu SRS là cực kì quan trọng nhưng không phải lúc nào cũng dễ dàng thực hiện được. Dưới đây là năm bước bạn có thể làm theo để viết một tài liệu SRS hiệu quả.

Xác định Mục đích bằng dàn ý (Hoặc sử dụng SRS template)

Bước đầu tiên của bạn là tạo một bản phác thảo cho tài liệu đặc tả yêu cầu phần mềm của mình. Bản phác thảo này có thể do bạn tự tạo ra hoặc bạn có thể sử dụng mẫu SRS có sẵn.

Nếu bạn đang tự mình tạo ra những bản phác thảo này, thì đây là những gì mà outline của bạn có thể có:

  1. Giới thiệu

           1.1 Mục đích

           1.2 Đối tượng Dự kiến

           1.3 Mục đích sử dụng

           1.4 Phạm vi

           1.5 Định nghĩa và từ viết tắt

  1. Mô tả chung

           2.1 Nhu cầu của Người dùng

           2.2 Giả định và Phụ thuộc

  1. Các tính năng và yêu cầu của hệ thống

            3.1 Yêu cầu chức năng

            3.2 Yêu cầu về giao diện bên ngoài

            3.3 Tính năng hệ thống

            3.4 Yêu cầu phi chức năng

Đây là một bản phác thảo cơ bản và phiên bản của bạn có thể chứa nhiều hoặc ít mục hơn. Bây giờ bạn đã có một dàn ý cho tài liệu SRS của mình, hãy cùng lần lượt điền vào chỗ trống.

Xem thêm >> UAT là gì? Quy trình thực hiện UAT hiệu quả

Xác định mục đích của sản phẩm

Phần giới thiệu này rất quan trọng vì nó đặt ra những kỳ vọng mà chúng ta sẽ đạt được trong suốt SRS. Một số mục cần ghi nhớ khi xác định mục đích này bao gồm:

Đối tượng dự kiến và Mục đích sử dụng

Xác định ai trong tổ chức của bạn sẽ có quyền truy cập vào SRS và cách họ nên sử dụng nó. Điều này có thể bao gồm các developer, tester và người quản lý dự án. Nó cũng có thể bao gồm các bên liên quan trong các bộ phận khác, bao gồm các nhóm lãnh đạo, nhóm bán hàng và cả bên marketing. Xác định điều này ngay càng sớm thì bạn sẽ càng bớt công việc trong tương lai.

Phạm vi sản phẩm

Những lợi ích và mục tiêu mà chúng ta dự định có cho sản phẩm này là gì? Điều này phải liên quan đến các mục tiêu kinh doanh tổng thể, đặc biệt nếu các nhóm bên ngoài nhóm phát triển sẽ có quyền truy cập vào SRS.

Định nghĩa và từ viết tắt

Bao gồm danh sách các từ được viết tắt cùng ý nghĩa của chúng để giúp người đọc nắm rõ hơn.

Điều quan trọng là xác định các rủi ro trong dự án. Điều gì có thể xảy ra? Làm cách nào để giảm thiểu những rủi ro này? Ai chịu trách nhiệm về các hạng mục rủi ro này?
Ví dụ, nếu sự cố của một thiết bị y tế sẽ gây ra thương tích nhẹ thì đó là một mức độ rủi ro. Nếu tính đến khả năng xảy ra và mức độ nghiêm trọng, chúng ta có thể đưa ra chiến lược để giảm thiểu rủi ro này.

Mô tả những gì bạn sẽ xây dựng

Bước tiếp theo của bạn là đưa ra mô tả về những gì bạn sẽ xây dựng. Đây là một sản phẩm mới? Hay đây có phải là tiện ích bổ sung cho sản phẩm bạn đã tạo ra trước đó không? Nó sẽ tích hợp với một sản phẩm khác? Tại sao sản phẩm/tính năng này lại cần thiết? Nó dành cho ai?

Hiểu những câu hỏi này ở front end giúp việc tạo sản phẩm dễ dàng hơn nhiều cho tất cả những người tham gia.

Nhu cầu của người dùng

Mô tả ai sẽ sử dụng sản phẩm và cách thức họ sử dụng nó. Hiểu kĩ về người dùng và nhu cầu của họ là một phần quan trọng của quá trình phát triển sản phẩm.

Ai sẽ sử dụng sản phẩm? Họ là người dùng chính hay phụ? Bạn có cần biết về người mua sản phẩm cũng như người dùng cuối không? Như trong các thiết bị y tế, bạn cũng sẽ cần hiểu rõ nhu cầu của bệnh nhân.

Giả định và Phụ thuộc

Những gì chúng ta đang giả định liệu sẽ đúng không? Nói rõ hơn và đặt ra những giả định này trước thời hạn sẽ giúp bạn đỡ đau đầu sau này. Chúng ta đang giả định công nghệ hiện tại? Chúng ta có đang dựa trên một khuôn khổ Windows không? Chúng ta cần xem xét các giả định này để hiểu rõ hơn khi nào sản phẩm của chúng ta sẽ bị lỗi hoặc hoạt động không mượt mà.

Cuối cùng, bạn cần lưu ý xem dự án của bạn có bị phụ thuộc vào bất kỳ yếu tố bên ngoài nào hay không. Chúng ta có đang sử dụng lại một chút phần mềm từ một dự án trước đó không? Dự án mới này sau đó sẽ phụ thuộc vào hoạt động đó một cách chính xác và cần được đưa vào.

Chi tiết các yêu cầu cụ thể

Để nhóm phát triển của bạn đáp ứng đúng các yêu cầu được đưa ra, chúng ta PHẢI đưa vào càng nhiều chi tiết càng tốt. Điều này có thể làm bạn cảm thấy quá tải nhưng sẽ trở nên dễ dàng hơn khi bạn chia nhỏ các yêu cầu của mình thành các danh mục. Một số danh mục phổ biến có thể bao gồm:

Yêu cầu chức năng

Các yêu cầu chức năng là điều cần thiết đối với sản phẩm của bạn vì chúng cung cấp một số loại chức năng nhất định.

Tự đặt câu hỏi “chức năng này có bổ sung vào bộ chức năng của công cụ không?” Hoặc “Chức năng này cung cấp cái gì cho người dùng?” có thể giúp quá trình này trở nên dễ dàng. Đặc biệt trong các thiết bị y tế, các yêu cầu chức năng này có thể có một số rủi ro và yêu cầu.

Bạn cũng có thể có các yêu cầu giúp phác thảo cách phần mềm của bạn sẽ tương tác với các công cụ khác, dẫn đến các yêu cầu về giao diện bên ngoài.

Yêu cầu về giao diện bên ngoài

Yêu cầu giao diện bên ngoài là các loại yêu cầu chức năng cụ thể. Điều này đặc biệt quan trọng khi làm việc với các hệ thống nhúng. Chúng phác thảo cách sản phẩm của bạn sẽ giao tiếp với các thành phần khác.

Có một số loại giao diện bạn có thể được yêu cầu, bao gồm:

  • Người dùng
  • Phần cứng
  • Phần mềm
  • Thông tin liên lạc

Tính năng hệ thống

Tính năng hệ thống là các loại yêu cầu chức năng. Đây là những tính năng cần thiết để một hệ thống hoạt động.

Các yêu cầu phi chức năng khác

Các yêu cầu phi chức năng có thể cũng quan trọng như các yêu cầu chức năng. Chúng bao gồm:

  • Hiệu năng
  • Độ an toàn
  • Bảo mật
  • Chất lượng

Mức độ quan trọng của loại yêu cầu này có thể khác nhau tùy thuộc vào ngành của bạn. Trong ngành thiết bị y tế, thường có những quy định yêu cầu theo dõi và hạch toán an toàn.

Gửi để phê duyệt

Vậy là chúng ta đã xong rồi đấy! Sau khi hoàn thành SRS, bạn sẽ cần phải được các bên liên quan chính phê duyệt phiên bản mới nhất của tài liệu srs.

Phân biệt các tài liệu SRS, BRD, FRS, SyRS

srs là gì
Phân biệt các tài liệu SRS, BRD, FRS, SyRS

Có 3 loại tài liệu dễ gây nhầm lẫn nhất cho các BA là SRS, BRD và FRS. Vậy có cách nào để phân biệt được 3 tài liệu này không?

BRD được viết tắt của từ Business Requirement Document – dịch tiếng Việt là tài liệu yêu cầu nghiệp vụ. Đây là loại tài liệu ghi lại các yêu cầu nghiệp vụ cùng những yêu cầu của các bên liên quan. Chúng ghi lại những mong muốn của doanh nghiệp đối với sản phẩm/tính năng hơn là yêu cầu.

BRD thường là tài liệu đầu tiên trong quy trình phát triển của công ty, dùng để mô tả chiến lược mà họ đã mong muốn đạt được trong tương lai. Hơn nữa, BRD cũng thể hiện mối quan tâm và nhu cầu của các bên liên quan đến các tính năng và dịch vụ cuối cùng. Nói một cách dễ hiểu nhất, đây là loại tài liệu để giải thích những câu hỏi tại sao có các yêu cầu trên, kèm theo một kết quả mong đợi và những sự thay đổi từ hệ thống. Đối tượng sử dụng BRD thường là các nhà tài trợ, bên thứ ba, các quản lý cấp cao, cấp trung và BA.

FRS (tiếng Anh là Functional Requirement Specifications) là loại tài liệu thể hiện các thông số kỹ thuật yêu cầu của chức năng. FRS là loại tài liệu chi tiết nhất trong 3 loại, nó sẽ cho biết hệ thống dự kiến hoạt động như thế nào để có thể thỏa mãn các yêu cầu đã được nêu trong các tài liệu BRD và SRS.

FRS liệt kê những mô tả rất chi tiết và rõ ràng cho từng yêu cầu chức năng trong từng trường tương ứng, cũng như sự tương tác của người sử dụng trên từng trang của hệ thống. FRS được tạo nên góc nhìn của người dùng và cách mà hệ thống sẽ tương tác lại với họ. Tài liệu FRS sau khi được hoàn thành sẽ được nộp lên cho quản lý dự án xem xét, tiếp theo sẽ tới tay khách hàng để được xác nhận lại lần cuối. Sau khi được xác nhận xong, tài liệu này sẽ trở thành bản chuẩn về cách phần mềm hoạt động.

Tài liệu đặc tả yêu cầu (SRS) bao gồm các mô tả chuyên sâu về phần mềm sẽ được phát triển. Đặc tả yêu cầu hệ thống (SyRS) thu thập thông tin về các yêu cầu đối với hệ thống. “Phần mềm” và “hệ thống” đôi khi được sử dụng thay thế cho nhau như SRS. Tuy nhiên, đặc tả yêu cầu phần mềm cung cấp chi tiết hơn so với đặc tả yêu cầu hệ thống.

Như vậy, trong bài viết trên, Hỏi đáp Công nghệ đã trả lời rất chi tiết câu hỏi SRS là gì, tại sao SRS lại quan trọng cũng như cách viết một tài liệu đặc tả yêu cầu một cách hiệu quả nhất. Hi vọng bạn hài lòng với các thông tin trên. Hãy chia sẻ cho bạn bè nếu bạn thấy bài viết có ích nhé!

Các bài viết liên quan

Leave a Comment

Email của bạn sẽ không được hiển thị công khai.

Bài viết liên quan