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 tồn bộ sản phẩm, bạn sẽ tìm thấy mơ tả tồn diện hơn ở đây.
3.1 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 u cầu về giao diện bên ngồ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 ngồ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.