1. 簡介[
軟體需求規約
(srs)
的簡介應提供整個文件的概述。它應包括軟體需求規約的目的、範圍、定義、首字母縮寫詞、縮略語、參考資料和概述。] [
注：軟體需求規約完整地記錄對系統或系統一部分的所有軟體需求。以下是乙個採用用例建模的專案的典型軟體需求規約概述。此工件由包含用例模型的用例、適用的補充規約及其他支援資訊的包組成。有些軟體需求規約沒有採用用例建模，它在乙個文件中記錄了所有需求，而適用的部分可從補充規約（此後將不再需要）中插入，這種軟體需求規約的模板請參見
rup_srs.dot。]
[軟體需求規約可能會有許多不同的組織方式。有關以上兩種組織方式的進一步闡述以及軟體需求規約的其他組織方式，請參見
[ieee830-1998]。]
1.1 目的[
闡明此軟體需求規約的目的。
]軟體需求規約應詳細地說明所確定的應用程式或子系統的外部行為。它還要說明非功能性需求、設計約束以及提供完整、綜合的軟體需求說明所需的其他因素。
] 1.2 範圍[
簡要說明此軟體需求規約適用的軟體應用程式、特性或其他子系統分組、與其相關的用例模型，以及受到此文件影響的任何其他事物。
] 1.3
定義、首字母縮寫詞和縮略語
[此小節應提供正確理解軟體需求規約所需的全部術語的定義、首字母縮寫詞和縮略語。可以通過參考專案詞彙表來獲取這些資訊。
] 1.4
參考資料
[此小節應完整地列出軟體需求規約中其他部分所引用的所有文件。每個文件應標有標題、報告號（如果適用）、日期和出版單位。列出可從中獲取這些參考資料的**。這些資訊可以通過參考附錄或其他文件來提供。
] 1.5 概述[
此小節應說明軟體需求規約其他部分所包含的內容，並解釋文件的組織方式。
] 2.
整體說明
[軟體需求規約的這一節應說明影響產品及其需求的一般因素。本節並不列出具體的需求，而只是提供在第
3 節中詳述的各種需求的背景，以使這些需求便於理解。其中包括產品總體效果、產品功能、使用者特徵、約束、假設與依賴關係、需求子集等內容。
] 2.1
用例模型調查
[當採用用例建模時，此節將概述適用於該子系統或特性的用例模型或用例模型的子集。其中包括所有用例和主角的名稱列表及簡要說明，以及適用的各種圖和關係。請參見用例模型調查報告，它在此處可用作附件。
] 2.2
假設與依賴關係
[本節說明所有重要的技術可行性假設、子系統或構件可用性假設，或者可作為此軟體需求規約所述軟體可行性的基礎的其他與專案有關的假設。
] 3.
具體需求
[軟體需求規約的這一節應包括所有的軟體需求，其詳細程度應使設計人員能夠設計出可以滿足這些需求的系統，並使測試人員能夠測試該系統是否滿足這些需求。當利用用例建模時，這些需求在用例和適用的補充規約中記錄。如果沒有利用用例建模，則可以將補充規約的概要直接插入此節。
] 3.1
用例報告
[在用例建模過程中，用例通常會定義系統的大部分功能性需求，以及一些非功能性需求。對於以上用例模型中的每個用例或其子集，都需在此節中引用或附上用例報告。務必要明確地標明每一需求。
] 3.2
補充需求
[補充規約記錄未包含在用例中的需求。應在此處列出補充規約中適用於該子系統或特性的具體需求，並對這些需求加以改進，以足夠詳細地說明該子系統或特性。這些需求可以直接記錄在此文件中，也可單獨儲存為補充規約，補充規約在此處可用作附件。務必要明確地標明每一需求。
] 4.
支援資訊
[支援資訊用於使軟體需求規約更易於使用。它包括：
• 目錄
• 索引
• 附錄
其中可以包括用例示意板或使用者介面原型。如果包含附錄，軟體需求規約應明確指出是否將附錄當作需求的一部分。
]
系統分析與設計專案報告
16340302 趙公尺 final report 在此次的合作專案中，我們六個人都很盡職盡職，大家日常分配的工作 畫圖 寫文件 提建議 週末小會 以及階段成品測試等。當然最重要的就是自己負責的那一部分內容。而我當初選擇的是後端，在後端框架搭建好之後，我們進行任務的分配，我得到了屬於自己的任務，然後...
系統分析與設計個人報告
在本次專案中，我們實現了乙個網頁端的 掙閒錢 專案，我在課程作業中主要負責前端的工作，包括登入，註冊頁面的實現，頁面路由的簡單管理。登入，註冊頁面的頁面設計是由專案的頁面ui設計同學負責設計的，是使用了axure來設計頁面元素，然後我使用vue實現這兩個頁面的外觀以及內部功能邏輯。由於是第一次接觸v...
推薦系統 分析
收集使用者資訊的行為記錄模組 分析使用者喜好的模型分析模組 推薦演算法模組 推薦演算法 1.基於內容的推薦系統 content based recommendation 2.協同過濾推薦系統 collaborative filtering recommendation 3.混合推薦系統 hybrid...