1. Giới thiệu -

Phần giới thiệu giải thích ý nghĩa SRS nói chung, phạm vi của nó đối với nhóm của bạn và cấu trúc của nó.

1.1. Mục đích

Ở đây, giải thích mục tiêu và cấu trúc của tài liệu phần mềm SRS: các loại yêu cầu sẽ được giải quyết, cũng như nhân sự sẽ sử dụng nó.

Giữ cho phần này ngắn gọn: 1-2 đoạn văn là đủ.

1.2. Đối tượng dự định

Bạn có thể đi sâu và giải thích cách các bên và nhóm liên quan sẽ làm việc với SRS, cũng như tham gia vào quá trình phát triển SRS. Họ thường là chủ sở hữu sản phẩm, nhà đầu tư, nhà phân tích kinh doanh, nhà phát triển, đôi khi là người kiểm tra và nhân viên vận hành. Toàn bộ cấu trúc được xác định bởi cách tiếp cận phát triển phần mềm của bạn và thiết lập tổ chức của nhóm.

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

Mô tả các tình huống mà nhóm của bạn sẽ sử dụng SRS. Thông thường, nó được sử dụng trong các trường hợp sau:

• thiết kế và động não các tính năng mới
• lập kế hoạch thời gian dự án, nước rút, ước tính chi phí
• đánh giá rủi ro
• giám sát và đo lường thành công của nhóm
• các tình huống xung đột khi các bên liên quan có tầm nhìn khác nhau về một sản phẩm được thực hiện tốt.

KHAI THÁC. Phạm vi

Phần này bao gồm phạm vi của sản phẩm, vì vậy bạn sẽ cần phải trình bày tổng quan nhanh về hệ thống - mục đích chính, chức năng và vị trí của nó. Nó có thể so sánh với cách bạn giải thích một sản phẩm tại cuộc họp các bên liên quan ngoại trừ việc nó được phép nghiên cứu sâu hơn về các chi tiết kỹ thuật.

Phần này phải mô tả:

• Tất cả các loại người dùng dự kiến ​​​​sẽ tương tác với hệ thống
• Tất cả các phần thiết yếu của kiến ​​trúc

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

Trong suốt tài liệu của bạn, nhóm thường xuyên sử dụng một số từ nhất định. Loại bỏ mọi hiểu lầm tiềm ẩn, cho phép các nhà phát triển mới tham gia và giải quyết các tình huống xung đột sẽ dễ dàng hơn nếu bạn hiểu rõ nghĩa của những từ này.

Các thành phần nêu trên tạo thành một định nghĩa. Các định nghĩa cung cấp thông tin về chức năng, công nghệ cơ bản, cá nhân mục tiêu, thực thể kinh doanh (người dùng, khách hàng, người trung gian) và các bên liên quan. Bạn có thể sử dụng một từ viết tắt để viết SRS của mình nhanh hơn nếu bạn chọn làm như vậy. Tài liệu sẽ có thể đọc được miễn là có bao gồm bảng định nghĩa.

2. Mô tả chung

Trong phần thứ hai, bạn mô tả các tính năng chính của sản phẩm, người dùng mục tiêu và phạm vi hệ thống cho người đọc. Mô tả này chỉ tập trung vào các tính năng chính và kiến ​​trúc phần mềm mà không đi sâu vào chi tiết cụ thể về các tiện ích bổ sung và kết nối.

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

Phần này là một vấn đề lựa chọn, vì vậy một số tổ chức chọn không đưa nó vào tài liệu kỹ thuật SRS của họ. Chúng tôi tin rằng tốt hơn hết bạn nên liệt kê các vấn đề bạn muốn giải quyết với chức năng của mình ngay bây giờ. Nó sẽ hữu ích sau này trong khi các chức năng động não và giám sát. Bạn có thể quay lại phần này bất kỳ lúc nào trong quá trình phát triển sản phẩm và xem liệu nhóm trải nghiệm người dùng có đi lạc khỏi con đường đã định hay không.

Nhu cầu đề cập đến các vấn đề mà người dùng sẽ có thể giải quyết với hệ thống. Bạn có thể chia những nhu cầu này thành các danh mục phụ nếu bạn đối phó với đối tượng được phân khúc cao. Cố gắng không đi vào chi tiết về nhu cầu của từng người dùng. Bạn cần để lại một khoảng trống để giải thích, đề phòng trường hợp một vấn đề trở nên quan trọng hơn bạn nghĩ ban đầu.

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

Giả định là những giả định của nhóm về sản phẩm và khả năng của sản phẩm sẽ đúng trong 99% tình huống. Chẳng hạn, thật tự nhiên khi giả định rằng một nền tảng hỗ trợ người lái xe điều hướng vào ban đêm sẽ được sử dụng chủ yếu ở chế độ ban đêm.

Ý nghĩa của các giả định là gì? Chúng cho phép bạn tập trung vào các tính năng quan trọng nhất của ứng dụng trước tiên. Giả định này giúp hiểu rằng các nhà thiết kế phải phát triển một giao diện phù hợp với tầm nhìn trong bóng tối cho một trợ lý lái xe ban đêm. Một số người dùng chắc chắn có thể mở ứng dụng trong ngày, nhưng đó là một khoảng thời gian dài, vì vậy bạn không cần phải đưa các yếu tố liên quan vào nguyên mẫu ngay lập tức.

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

Phần này trình bày chi tiết các tính năng của sản phẩm và tiêu chí thực thi. Vì hai phần trước đề cập đến toàn bộ sản phẩm, bạn sẽ tìm thấy mô tả toàn diện hơn ở đây.

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

được nêu trong một danh sách các chức năng sẽ được thực hiện trong một hệ thống. Những tiêu chí này liên quan đến “cái gì sẽ được tạo ra?” hơn là “làm thế nào” và “khi nào”.

Các yêu cầu chức năng bắt đầu bằng cách mô tả chức năng được yêu cầu dựa trên mức độ cần thiết của nó đối với ứng dụng. Nếu bạn muốn làm việc trên nó trước tiên, bạn có thể bắt đầu với thiết kế, nhưng sau đó bạn nên bắt đầu phát triển. Các yêu cầu chức năng không đi sâu vào chi tiết về các ngăn xếp công nghệ vì chúng có thể thay đổi khi dự án tiến triển. Thay vì tập trung vào logic bên trong, các yêu cầu chức năng tập trung vào chức năng của người dùng cuối.

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

Yêu cầu chức năng là một phần quan trọng của đặc tả yêu cầu hệ thống. Để bao gồm tất cả các tính năng cần thiết của hệ thống, bạn sẽ cần 4-5 trang thông tin. Một số nhóm chia nhỏ chúng theo chủ đề để làm cho tài liệu dễ đọc hơn.

Thông thường, các thành phần thiết kế SRS được coi là tách biệt với phần phụ trợ và logic nghiệp vụ. Điều này có ý nghĩa vì các nhà thiết kế thay vì các nhà phát triển xử lý phần lớn lĩnh vực này, mà còn bởi vì nó là nơi bắt đầu quá trình phát triển sản phẩm.

Tùy thuộc vào dự án, các yêu cầu về giao diện bên ngoài có thể bao gồm bốn loại:

• Giao diện người dùng
• Giao diện phần mềm
• Giao diện phần cứng
• Giao diện truyền thông

Các yêu cầu về giao diện bên ngoài mô tả các phần tử trang sẽ hiển thị cho khách hàng cuối. Chúng có thể bao gồm danh sách các trang, yếu tố thiết kế, chủ đề phong cách chính, thậm chí cả yếu tố nghệ thuật, v.v. nếu chúng cần thiết cho sản phẩm.

3.3 Yêu cầu hệ thống

Yêu cầu hệ thống của sản phẩm nêu rõ các điều kiện mà sản phẩm có thể được sử dụng. Chúng thường liên quan đến các thông số kỹ thuật và tính năng phần cứng. Yêu cầu phần cứng SRS thường được xác định theo phạm vi tối thiểu và tối đa, cũng như ngưỡng hiệu suất sản phẩm tối ưu.

Việc tạo ra các yêu cầu hệ thống trước khi bắt đầu tạo ra một sản phẩm có vẻ khó khăn, nhưng nó là điều cần thiết. Các nhà phát triển phải tuân thủ các yêu cầu phần cứng để họ không phải khởi động lại dự án sau này. Các ứng dụng dành cho thiết bị di động (có nhiều biến số cần xem xét) và các ứng dụng cần khả năng phản hồi cao (trò chơi, bất kỳ sản phẩm nào có VR / AR hoặc IoT) đặc biệt dễ bị tấn công.

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

Đối với nhiều tổ chức, phần này của SRS là phần khó nhất. Nếu các yêu cầu chức năng giải quyết câu hỏi tạo ra cái gì, thì các tiêu chuẩn phi chức năng xác định cách thức. Họ thiết lập các tiêu chí theo mức độ hiệu quả của hệ thống phải hoạt động. Tất cả các ngưỡng về hiệu suất, bảo mật và khả năng sử dụng đều được bao gồm trong lĩnh vực này.

Giá trị thực là điều khiến khó xác định các yêu cầu phi chức năng. Khó xác định các cụm từ như “đồng thời” hoặc “tính di động” vì chúng có thể có nhiều cách hiểu khác nhau cho tất cả các bên liên quan. Do đó, chúng tôi chủ trương cho điểm mỗi yêu cầu phi chức năng. Bạn có thể truy cập lại các yêu cầu dự án của mình bất kỳ lúc nào để xem liệu hệ thống hiện tại có đáp ứng các kỳ vọng ban đầu hay không.