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

Hiện nay, công nghiệp 4.0 phát triển mạnh mẽ dẫn đến có rất nhiều các công ty sản xuất phần mềm đã được hình thành và phát triển. Để mang lại một sản phẩm phần mềm chất lượng, đáng tin cậy thì việc phân tích là một khâu vô cùng quan trọng trong quá trình xây dựng phần mềm. 

Tài liệu đặc tả SRS là những yêu cầu về sản phẩm mà đội phát triển đang cần. Chính vì lẽ đó nên tài liệu đặc tả vô cũng quan trọng trong quá trình phát triển phần mềm. Vậy tài liệu srs là gì? Hãy cùng testerpro.vn tìm hiểu về nó qua bài viết dưới đây.

Tài liệu SRS là gì? 

• SRS document là gì hay tài liệu SRS là gì ? Nó là cụm từ viết tắt của từ Software Requirement specification có nghĩa là viết tài liệu đặc tả yêu cầu. Nó được sử dụng để mô tả chi tiết các yêu cầu về chức năng và phi chức năng của hệ thống. Các yêu cầu về chức năng giúp mô tả được các chức năng của hệ thống phần mềm  và các thành phần của nó. 
• Các yêu cầu phi chức năng là mô tả các đặc điểm hoạt động của hệ thống phần mềm và các thành phần của nó. Tài liệu đặc tả bao gồm tất các định nghĩa, yêu cầu của người dùng và yêu cầu của hệ thống. Nó không phải là tài liệu thiết kế mà nó chỉ thiết lập những gì mà hệ thống phải làm chứ không phải mô tả nó làm như nào?
• Đến đây bạn đã hiểu được một cách khái quát nhất về tài liệu srs là gì đúng không nào. Nó được dùng cho tất cả các Stakeholders đọc và hiểu được các nghiệp vụ của các chức năng, …Là một tài liệu vô cùng quan trọng cho đội phát triển và đội kiểm thử phần mềm.

Vai trò của tài liệu SRS

Sau khi tìm hiểu về tài liệu srs là gì thì hãy nhau khám phá tầm quan trọng của tài liệu này nhé! SRS là một tài liệu vô cùng quan trọng trong quá trình phát triển phần mềm:

• Giúp các đội phát triển xây dựng hệ thống  được chính xác, đặc tả được các tính năng, không đi lạc hướng so với các yêu cầu của khách hàng.
• Giúp các bên liên quan hiểu được rõ ràng về hệ thống đi theo một hướng và tránh gặp phải các trường hợp mỗi người mỗi ý.
• Việc bảo trì hệ thống 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.
• Tài liệu kiểm thử SRC  giúp các chuyên viên kiểm thử hệ thống hiểu được để từ đó xây dựng nên các kịch bản kiểm thử chi tiết.

Tài liệu SRS cần có những đặc điểm gì?

• Tài liệu chính xác: là điều vô cùng quan trọng để bảo đảm rằng SRS luôn phản ánh được các chức năng và các đặc điểm kỹ thuật của sản phẩm
• Tính rõ ràng: Rõ ràng tốt hơn mơ hồ, nó không phải là văn học nên không cần văn phong những điều cơ bản nhất không thể bỏ qua được là sự rõ ràng
• Hoàn tất: Đây không phải là ý kiến mà nó là những yêu cầu của khách hàng bạn không thể nào bỏ qua được 
• Phù hợp: Tài liệu đặc tả viết tắt hay các định nghĩa phải sử dụng nhất quán trong bộ SRS
• Xếp hạng mức quan trọng: Bạn cần phải xếp hạng mức độ mức quan trọng để xác minh được các yêu cầu 
• Kiểm chứng: Cần phải có phương pháp xác minh các yêu cầu
• Có thể sửa đổi: Các thay đổi với các yêu cầu cần phải thực hiện có hệ thống và tác động đến các yêu cầu khác cần phải được xem xét
• Tính truy nguyên: truy xuất được nguồn gốc ngay từ đầu 

Các thành phần chính của tài liệu SRS

Sau khi tìm hiểu tài liệu srs là gì cùng vai trò của nó thì hãy cùng khám phá cấu trúc của cấu trúc tài liệu srs: 

Phần Introduction – Phần giới thiệu

• Purpose: Các mô tả chi tiết về các mục đích và ý nghĩa của tài liệu đặc tả yêu cầu, giúp người đọc có thể hiểu được những khái niệm cũng như tầm quan trọng của tài liệu
• Application Overview: Có cái nhìn tổng quan hơn về hệ thống đảm bảo các yếu tố như các tính năng của hệ thống, các quyền sở hữu, các mục đích  của hệ thống được sinh ra để làm gì?
• Intended Audience and Reading Suggestions: Giúp mô tả các đối tượng sở hữu SRS cũng như các mục đích sử dụng
• Abbreviations: Danh sách các từ viết tắt giúp người sử dụng hiểu được ý nghĩa 
• References: Các mục đích kèm theo các mô tả tài liệu liên quan

>>> Tìm hiểu ngay: Cách viết đặc tả yêu cầu phần mềm

Phần high level Requirement – Yêu cầu mức tổng quan

• Mô tả các thực thế quan hệ giữa các đối tượng của hệ thống (Object RelationShip Diagram)
• Workflow Diagram: Giúp đảm nhiệm hiển thị các chuỗi công việc hay các bước người dùng thực hiện. Mỗi hành động của người dùng giúp hiển thị được từng giai đoạn của một hệ thống
• State Transition Diagram: Đây là một trạng thái từng bước giúp người đọc có thể biết ai là người đang thực hiện điều đó và nó tác động như thế nào đến trạng thái của hệ thống
• Use Case Diagram: Đây là sơ đồ thể hiện người dùng có thể thực hiện những chức năng nào của hệ thống.

Mục Security Requirement – Các yêu cầu về bảo mật

Giúp mô tả đầy đủ các permission tương ứng với từng actor của hệ thống. Các Actor thực hiện các chức năng và nhiệm vụ của mỗi người cùng các quyền thực hiện của từng người trong hệ thống.

Đặc tả các use case

Bao gồm các chức năng của hệ thống để giúp nêu ra chi tiết những gì mà hệ thống phải làm ở đầu vào, các hành vi cũng như đầu ra dự kiến. Cùng với đó có các tác nhân bên ngoài bảo vệ hệ thống và các kết quả tương tác của họ.

Phần Wireframe – thiết kế màn hình 

Đây là một mục đính kèm với tài liệu đặc tả yêu cầu giúp người đọc có thể di chuyển được đến màn hình của hệ thống. Có một số chức năng của thiết kế màn hình yêu cầu 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. Để có thể hiểu được và có cái nhìn chính xác hơn về hệ thống cũng như việc thấu hiểu hơn các yêu cầu của khách hàng. Các nhà phân tích nghiệp vụ và thể hiện được năng lực trong nhóm dự án. 

Các thành phần khác

• Xác định các yêu cầu chức năng của hệ thống với khách hàng nhanh hơn
• Giúp khách hàng hiểu và hình dung về hệ thống một cách dễ dàng hơn
• Thể hiện được những yêu cầu của BA và những yêu cầu mong đợi của khách hàng 
• Giúp chứng minh được năng lực của team dự án 
• Dễ tiếp cận, nắm bắt cũng như hiểu nhanh hơn về hệ thống

Phần integration – Yêu cầu tích hợp 

Giúp bạn có thể đính kèm được các tài liệu, nội dung liên quan đến hệ thống bên ngoài. 

Phần Appendices – Mục lục 

Cho phép bạn bạn định nghĩa ra các lỗi tin nhắn trong hệ thống hay các email bản mẫu trong hệ thống. 

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

Về cách viết SRS thì bạn cần bắt đầu với khung và thông tin chung về phần mềm bạn đang phát triển. Sau đó hoàn thiện các chi tiết để tạo thành bản phác thảo của mình. Quy trình viết tài liệu SRS được thực hiện gồm các bước sau:

Tạo dàn ý

Đây là bước đầu tiên nhưng rất quan trọng định hình cho tài liệu. Với tạo dàn ý thì bạn có thể tự tạo hoặc dùng mẫu SRS có sẵn. Dàn ý tài liệu SRS được triển khai theo các ý sau: Giới thiệu, mục đích, đối tượng hướng đến, mục đích sử dụng. Ngoài ra còn có: phạm vi, định nghĩa, mô tả chung, nhu cầu của người dùng, giả định và sự phụ thuộc. Bên cạnh đó là yêu cầu chức năng, giao diện, tính năng hệ thống, yêu cầu phi lý.

Xác định mục đích

• Khi bạn đã có được dàn ý thì hãy biến nó thành những thông tin cụ thể. Đầu tiên cần xác định mục đích của sản phẩm trong phần giới thiệu SRS. Ở đây bạn mô tả đối tượng dự định và cách họ dùng sản phẩm.
• Các mục đích gồm: xác định phạm vi của sản phẩm cùng mô tả giá trị mà nó sẽ mang lại. Đồng thời cho biết ai sẽ sử dụng phần mềm cùng xem chi tiết cách nó sẽ giúp ích cho công việc của người dùng dự định.

Cung cấp cái nhìn tổng quan

• Nếu bạn đã xác định được mục đích của sản phẩm thì cần tóm tắt nó hoạt động như thế nào. Tại đây bạn đưa ra mô tả chung về các tính năng của phần mềm. Cùng cách chúng phù hợp với nhu cầu của con người.
• Bên cạnh đó thì bạn cũng sẽ mô tả các giả định bạn đang đặt ra về chức năng của sản phẩm. Cùng bất kỳ điều gì phụ thuộc vào nó trong hệ sinh thái công nghệ hiện tại.

Mô tả các yêu cầu chức năng và phi chức năng

• Đến đây thì bạn sẽ đi vào chi tiết, cụ thể hơn sau khi đã viết thông tin chung. Khi bạn có đầy đủ thông tin tổng quan trước khi thực hiện các yêu cầu chức năng và phi chức năng. Là nguồn tài liệu tham khảo để đảm bảo bạn đáp ứng nhu cầu cơ bản của người dùng khi điền thông tin chi tiết.
• Việc mô tả chi tiết các yêu cầu của hệ thống là yếu tố cần thiết nhất của tài liệu SRS. Nếu mô tả các yêu cầu chức năng đủ chi tiết thì các nhà phát triển có thể bắt đầu làm việc. Cùng các yêu cầu phi chức năng gồm thông số kỹ thuật bảo mật và hiệu suất.
• Nơi bạn thêm các dự thảo sử dụng để mô tả sinh động cách người dùng tương tác với hệ thống của bạn như thế nào. Cũng là nơi các mục tiêu của dự án được trình bày chi tiết và đo lường sự phát triển của dự án.

Thêm chi tiết bổ sung

Để hoàn thành tìa SRS thì bạn cần thêm bất kỳ chi tiết nào có thể giúp nhà phát triển hoàn thành công việc. Nó được thể hiện dưới dạng phụ lục, bảng chú giải thuật ngữ và tài liệu tham khảo.

Sự chấp thuận

• Sau khi bạn đã thêm đầy đủ chi tiết vào SRS để mô tả những gì hệ thống phải làm. Tiếp đó thì các bên liên quan sẽ tiến hành phê duyệt tài liệu. Có thể bạn sẽ phải thuyết trình trước những người tham gia vào quá trình phát triển.
• Bạn sẽ phải cập nhật lại tài liệu dựa trên phản hồi của các bên liên quan trước khi phê duyệt cuối cùng. Nếu nhận được sự chấp thuận thì có nghĩa là cả nhà phát triển và các bên liên quan đang làm cho tài liệu chính xác hơn. Điều đó chứng tỏ là dự án đã đi đúng hướng.

Ví dụ mẫu tài liệu SRS

Dưới dây là ví dụ về tài liệu SRS chi tiết dành cho ứng dụng mua sắm trực tuyến Lazada trên thiết bị di động.

Giới thiệu

Tài liệu đề cập đến kế hoạch phát triển cho Lazada, một ứng dụng dành cho thiết bị di động cho phép người dùng truy cập, tìm kiếm và mua các sản phẩm từ nhiều thương hiệu khác nhau. Kế hoạch này dành cho kỹ sư phần mềm, thiết kế, nhóm kiểm thử…

Mô tả tổng thể

Trong thời đại thương mại điện tử đang phát triển mạnh mẽ, người dùng không ngừng tìm kiếm những cách thuận tiện, tối ưu thời gian nhất để mua sắm. Tuy nhiên, với rất nhiều thương hiệu và sản phẩm có sẵn, khách hàng có thể rất khó khăn trong việc tìm thấy thứ mà họ muốn. Lazada được phát triển nhằm mục đích giải quyết vấn đề này, giúp khách hàng có thể tìm thấy các sản phẩm chất lượng đến từ các shop uy tín.

Khách hàng

Mục tiêu là những cá nhân có sở thích mua sắm trực tuyến. Họ có hiểu biết về công nghệ và dễ dàng sử dụng các ứng dụng trên thiết bị di động

Tính năng

• Cho phép người dùng tạo tại khoản thông qua email, đăng nhập trực tiếp bằng tài khoản google, mạng xã hội
• Duyệt, tìm kiếm sản phẩm dựa trên thương hiệu, khu vực, khoảng giá…
• Người dùng có thể xem mô tả chi tiết về sản phẩm, hình ảnh và đánh giá
• Thêm sản phẩm vào giỏ hàng và thanh toán một cách an toàn thông qua nhiều phương thức khác nhau
• Theo dõi tình trạng đơn hàng
• Nhận thông báo về sản phẩm mới, mã giảm giá, khuyến mại…

Nền tảng

Ứng dụng sẽ được xây dựng bằng cách sử dụng React Native, một framework đa nền tảng cho phép phát triển cả ứng dụng Android và IOS. Ứng dụng sẽ được kết nối với API Rest được tạo bằng Node.js mà MongDB để lưu trữ và truy xuất thông tin.

Trách nhiệm phát triển

Nhóm phát triển sẽ chịu trách nhiệm lập trình ứng dụng, thiết kế giao diện người dùng và kiểm thử ứng dụng để đảm bảo chất lượng

User Class

Sẽ có hai loại người dùng cho Lazada: khách hàng và quản trị viên. Khách hàng sẽ sử dụng tất cả các tính năng, trong khi quản trị viên sẽ có quyền truy cập vào các tính năng bổ sung như quản lý danh sách sản phẩm…

Tính năng và yêu cầu hệ thống

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

• Người dùng có thể tìm kiếm dựa trên nhiều yếu tố khác nhau
• Xem chi tiết sản phẩm
• Thêm sản phẩm vào giỏi hàng và thanh toán

Giao diện nội bộ

Giao diện người dùng:

• Phần mềm phụ trợ: node.js
• Phần mềm cơ sở dữ liệu: MongDB
• Front-end: React Native

Giao diện phần cứng: Android, IOS

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

Yêu cầu thực thiện:

• Ứng dụng sẽ tải và sẵn sàng sử dụng trong vòng 5s
• Phản ứng với tương tác người dùng trong vòng 2s
• Cơ sở dữ liệu nên được tối ưu hóa đê đảm bảo hiệu suất truy vấn nhanh

Yêu cầu an toàn và bảo mật:

• Ứng dụng phải đảm bảo giao dịch an toàn và bảo vệ dự liệu người dùng thông qua mã hóa và các phương pháp bảo mật khác.
• Các khóa của API REST phải được lưu trữ an toàn

Thuộc tính chất lượng phần mềm:

• Nên có mục tiêu là 99,9% tính khả dụng để đảm bảo khách hàng có thể mua sắm bất cứ lúc nào
• Hiển thị chính xác thông tin sản phẩm và đảm bảo giao dịch an toàn
• Ứng dụng phải được tích hợp liên tục để các tính năng, bản cập nhật và bản sửa lỗi có thể được triển khai nhanh chóng mà không có thời gian ngừng hoạt động
• Giao diện phải trực quan và dễ điều hướng.

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

SRS Document

• SRS là tài liệu yêu cầu có cấu trúc, đầy đủ gồm các yêu cầu chức năng (minh họa hành vi người dùng) cùng phi chức năng (mô tả đặc điểm). Đồng thời là tất cả trường hợp khác mà phần mềm cần đáp ứng.
• Tài liệu này rất quan trọng đóng vai trò kết nối giữa những điều doanh nghiệp muốn và những gì được thể hiện. Ở dạng bố cục, đặc điểm cùng quy trình mà hệ thống đang xây dựng.
• Theo các yêu cầu phần mềm được ghi nhận chi tiết trong SRS giúp bạn ước tính ngân sách và thời gian hoàn thiện hệ thống. Dựa vào đó mà doanh nghiệp có thể tạo lập hợp đồng giữa các bên. BRD do BA làm thì SRS được các nhà phân tích hệ thống SA thực hiện.
• Ở một số doanh nghiệp không có SA thì BA sẽ làm và cần tổng hợp yêu cầu của các bên liên quan. Tiếp đó phân tích chi tiết các chức năng của phần mềm rồi liệt kê các yêu cầu kỹ thuật đối với từng chức năng. Điều này đảm bảo từng yêu cầu được liệt kê ở SRS sẽ thỏa mãn các mục tiêu kinh doanh trong BRD.
• Tài liệu SRS dành cho quản lý dự án, chuyên viên tư vấn trong lĩnh vực, trưởng bộ phận kỹ thuật và thực thi. Ở một số doanh nghiệp hay dự án nhỏ không cần dùng SRS vì đã có chi tiết trong BRD.

Tài liệu BRD

• BRD là viết tắt của cụm Business Requirement Document dịch ra có nghĩa là tài liệu yêu cầu nghiệp vụ. Đây là tài liệu ghi lại các yêu cầu nghiệp vụ cùng yêu cầu của các bên liên quan. Thường thì BRD ghi lại những mong muốn của doanh nghiệp thay vì các yêu cầu.
• Loại tài liệu này xuất hiện đầu tiên trong quy trình phát triển của tổ chức. Thể hiện chiến lược của công ty đang nỗ lực để đạt được trong tương lai qua việc tạo sản phẩm hay dịch vụ.
• Ngoài ra, BRD còn thể hiện 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.
• BRD là đáp án cho câu hỏi tại sao có các yêu cầu trên, một kết quả mong đợi và sự thay đổi từ hệ thống. Tài liệu này dành cho các nhà tài trợ, quản lý cấp cao và cấp trung cùng BA.

Tài liệu FRS

• FRS là cụm từ viết tắt tiếng Anh của Functional Requirement Specifications. Tài liệu thể hiện thông số kỹ thuật để thiết lập đầy đủ các tiểu tiết có trong yêu cầu của chức năng của dự án.
• Đây là tài liệu chi tiết nhất trong số 3 loại tài liệu trên trả lời cho câu hỏi “Như thế nào?”. Nghĩa là hệ thống sẽ dự kiến hoạt động như thế nào để thỏa mãn các yêu cầu trong tài liệu BRD và SRS.
• Loại tài liệu này tạo dựng các mô tả chi tiết, rõ ràng từng yêu cầu chức năng của từng trường. Cùng tương tác của người dùng trên từng trang của hệ thống. FRS được biểu diễn qua các sơ đồ dòng quy trình (process flow diagrams), UML diagrams, wireframs.
• Được tạo ra từ quan điểm của người dùng và cách hệ thống tương tác với họ. Khi đó nhóm Dev sẽ phải biết chính xác họ cần làm gì và nhóm QA/testing cần biết tạo ra những kịch bản kiểm tra nào cho hệ thống.
• Tài liệu này do BA hoặc SA soạn ra và sau khi xong sẽ trình lên quản lý dự án xét duyệt. Sau đó FRS đươc gửi đến khách hàng để xác nhận lần cuối. Tài liệu khi có sự xác nhận của các bên thì sẽ bản tiêu chuẩn về cách thức vận hành 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.

Trên đây là những thông tin chi tiết về tài liệu srs là gì và cách viết cùng phân biệt với BRD và FRS. Mong rằng bạn đọc đã gỡ bỏ được những khúc mắc về vấn đề này. Hãy theo dõi Testerpro.vn thường xuyên để cập nhật tin tức mới nhất về kiểm thử nhé!