Mẫu mô tả những thông tin cần phải có trong tài liệu đặc tả yêu cầu phần mềm SRS. Tài liệu này cung cấp những đề mục, yêu cầu cần phải có trong tài liệu.......................................................................................................................................................................
1 Giới thiệu Phần giới thiệu giải thích ý nghĩa SRS nói chung, phạm vi nhóm bạn cấu trúc 1.1 Mục đích Ở đây, giải thích mục tiêu cấu trúc tài liệu phần mềm SRS: loại yêu cầu giải quyết, nhân sử dụng Giữ cho phần ngắn gọn: 1-2 đoạn văn đủ 1.2 Đối tượng dự định Bạn sâu giải thích cách bên nhóm liên quan làm việc với SRS, tham gia vào trình phát triển SRS Họ thường chủ sở hữu sản phẩm, nhà đầu tư, nhà phân tích kinh doanh, nhà phát triển, đơi người kiểm tra nhân viên vận hành Toàn cấu trúc xác định cách tiếp cận phát triển phần mềm bạn thiết lập tổ chức nhóm 1.3 Mục đích sử dụng Mơ tả tình mà nhóm bạn sử dụng SRS Thơng thường, sử dụng trường hợp sau: thiết kế động não tính 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 đo lường thành cơng nhóm tình xung đột bên liên quan có tầm nhìn khác sản phẩm thực tốt KHAI THÁC Phạm vi Phần bao gồm phạm vi sản phẩm, bạn cần phải trình bày tổng quan nhanh hệ thống - mục đích chính, chức vị trí Nó so sánh với cách bạn giải thích sản phẩm họp bên liên quan ngoại trừ việc phép nghiên cứu sâu chi tiết kỹ thuật Phần phải mô tả: Tất loại người dùng dự kiến tương tác với hệ thống Tất phần thiết yếu kiến trúc 1.5 Định nghĩa từ viết tắt Trong suốt tài liệu bạn, nhóm thường xuyên sử dụng số từ định Loại bỏ hiểu lầm tiềm ẩn, cho phép nhà phát triển tham gia giải tình xung đột dễ dàng bạn hiểu rõ nghĩa từ Các thành phần nêu tạo thành định nghĩa Các định nghĩa cung cấp thông tin chức năng, công nghệ 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) bên liên quan Bạn sử dụng từ viết tắt để viết SRS nhanh bạn chọn làm Tài liệu đọc miễn có bao gồm bảng định nghĩa Mô tả chung Trong phần thứ hai, bạn mơ tả tính sản phẩm, người dùng mục tiêu phạm vi hệ thống cho người đọc Mơ tả tập trung vào tính kiến trúc phần mềm mà khơng sâu vào chi tiết cụ thể tiện ích bổ sung kết nối 2.1 Nhu cầu Người dùng Phần vấn đề lựa chọn, số tổ chức chọn khơng đưa vào tài liệu kỹ thuật SRS họ Chúng tin tốt hết bạn nên liệt kê vấn đề bạn muốn giải với chức Nó hữu ích sau chức động não giám sát Bạn quay lại phần lúc trình phát triển sản phẩm xem liệu nhóm trải nghiệm người dùng có lạc khỏi đường định hay không Nhu cầu đề cập đến vấn đề mà người dùng giải với hệ thống Bạn chia nhu cầu thành danh mục phụ bạn đối phó với đối tượng phân khúc cao Cố gắng không vào chi tiết nhu cầu người dùng Bạn cần để lại khoảng trống để giải thích, đề phịng trường hợp vấn đề trở nên quan trọng bạn nghĩ ban đầu 2.2 Giả định Phụ thuộc Giả định giả định nhóm sản phẩm khả sản phẩm 99% tình Chẳng hạn, thật tự nhiên giả định tảng hỗ trợ người lái xe điều hướng vào ban đêm sử dụng chủ yếu chế độ ban đêm Ý nghĩa giả định gì? Chúng cho phép bạn tập trung vào tính quan trọng ứng dụng trước tiên Giả định giúp hiểu nhà thiết kế phải phát triển giao diện phù hợp với tầm nhìn bóng tối cho trợ lý lái xe ban đêm Một số người dùng chắn mở ứng dụng ngày, khoảng thời gian dài, bạn không cần phải đưa yếu tố liên quan vào nguyên mẫu Các tính yêu cầu hệ thống Phần trình bày chi tiết tính sản phẩm tiêu chí thực thi Vì hai phần trước đề cập đến tồn sản phẩm, bạn tìm thấy mơ tả toàn diện 3.1 Yêu cầu chức nêu danh sách chức thực hệ thống Những tiêu chí liên quan đến “cái tạo ra?” “làm nào” “khi nào” Các yêu cầu chức bắt đầu cách mô tả chức yêu cầu dựa mức độ cần thiết ứng dụng Nếu bạn muốn làm việc trước tiên, bạn bắt đầu với thiết kế, sau bạn nên bắt đầu phát triển Các yêu cầu chức không sâu vào chi tiết ngăn xếp công nghệ chúng thay đổi dự án tiến triển Thay tập trung vào logic bên trong, yêu cầu chức tập trung vào chức người dùng cuối 3.2 Yêu cầu giao diện bên Yêu cầu chức phần quan trọng đặc tả yêu cầu hệ thống Để bao gồm tất tính cần thiết hệ thống, bạn 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 Thông thường, thành phần thiết kế SRS coi tách biệt với phần phụ trợ logic nghiệp vụ Điều có ý nghĩa nhà thiết kế thay nhà phát triển xử lý phần lớn lĩnh vực này, mà nơi bắt đầu q trình phát triển sản phẩm Tùy thuộc vào dự án, yêu cầu giao diện bên ngồi 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 giao diện bên ngồi mơ tả phần tử trang hiển thị cho khách hàng cuối Chúng bao gồm danh sách trang, yếu tố thiết kế, chủ đề phong cách chính, chí yếu tố nghệ thuật, v.v 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 sản phẩm nêu rõ điều kiện mà sản phẩm sử dụng Chúng thường liên quan đến thơng số kỹ thuật tính phần cứng Yêu cầu phần cứng SRS thường xác định theo phạm vi tối thiểu tối đa, ngưỡng hiệu suất sản phẩm tối ưu Việc tạo yêu cầu hệ thống trước bắt đầu tạo sản phẩm khó khăn, điều cần thiết Các nhà phát triển phải tuân thủ yêu cầu phần cứng để họ khởi động lại dự án sau Các ứng dụng dành cho thiết bị di động (có nhiều biến số cần xem xét) ứng dụng cần khả phản hồi cao (trò chơi, sản phẩm có VR / AR IoT) đặc biệt dễ bị công 3.4 Yêu cầu phi chức Đối với nhiều tổ chức, phần SRS phần khó Nếu yêu cầu chức giải câu hỏi tạo gì, tiêu chuẩn phi chức xác định cách thức Họ thiết lập tiêu chí theo mức độ hiệu hệ thống phải hoạt động Tất ngưỡng hiệu suất, bảo mật khả sử dụng bao gồm lĩnh vực Giá trị thực điều khiến khó xác định yêu cầu phi chức Khó xác định cụm từ “đồng thời” “tính di động” chúng có nhiều cách hiểu khác cho tất bên liên quan Do đó, chúng tơi chủ trương cho điểm u cầu phi chức Bạn truy cập lại yêu cầu dự án lúc để xem liệu hệ thống có đáp ứng kỳ vọng ban đầu hay không