一、需求的作用

需求是解決問題的前提。

其中標註為軟體系統工程的一些活動，是作為系統工程工作的一部分被實施的。

Q：什麼樣的陳述可以被稱為需求?
1.這個需求是否有必要？–>必要的（Necessary）
2.會不會產生歧義？–>無歧義（Unambiguous）
3.能不能測試？–>可測試（Testable）
4.能不能跟蹤？–>可跟蹤（Trackable）
5.能不能測量？–>可測量（Measurable）

二、需求分類

需求分為功能性需求；效能需求；外部介面需求；設計約束需求；質量屬性需求。

功能需求是整個需求的主體，即沒有功能需求，就沒有非功能需求，即效能需求、外部介面需求、設計約束和質量屬性。

非功能需求對功能需求而言，可以是一對多的，例如：

三、需求發現——怎麼提需求？

常用的發現初始需求的技術，包括：

3.1自悟（Introspection）

需求人員把自己作為系統的終端使用者，審視該系統並提出問題：“如果是我使用這一系統，則我需要……”

3.2 交談

為了確定系統應該提供的功能，需求人員通過提出問題，使用者回答，直接詢問使用者想要的是一個什麼樣的系統。
成功條件：交談通常是一種比自悟更好的技術。
這種途徑成功與否依賴於：
需求人員是否具有“正確提出問題”的能力，回答人員是否具有“揭示需求本意”的能力。

存在的風險：在交談期間需求可能不斷增長，或是以前沒有認識到的合理需求的一種表現，說是“完美蠕行”（Creeping elegance）病症的體現，以至於很難予以控制，可能導致超出專案成本和進度的限制。
應對措施：專案管理人員和客戶管理人員應該定期地對交談過程的結果進行復審。

3.3 觀察

通過觀察使用者執行其現行的任務和過程，或通過觀察他們如何操作與所期望的新系統有關的現有系統，瞭解系統執行的環境，特別是瞭解要建的新系統與現存系統、過程以及工作方法之間必須進行的互動。儘管瞭解的這些資訊可以通過交談獲取，但“第一手材料”一般總是能夠比較好的“符合現實”的。

存在的風險：
一一客戶可能抵觸這一觀察。其原因是他們認為開發者打擾了他們的正常業務。
一一客戶還可能認為開發者在簽約之前，就已經熟悉了他們的業務。

3.4 小組會（Group session）

舉行客戶和開發人員的聯席會議，與客戶組織的一些代表共同開發需求。其中：

通常是由開發組織的一個代表作為首席需求工程師或軟體工程專案經理，主持這一會議。但還可以採用其它形式，這依賴於其應用領域和主持人的能力。主持人的作用主要是掌握會議的程序。

必須仔細地選擇該小組的成員，不僅要考慮他們對現存的和未來執行環境的理解程度，還要考慮他們的人品。

3.5提煉（Extraction）

複審技術文件（例如，有關需要的陳述，功能和效能目標的陳述，系統規約介面標準，硬體設計文件以及ConOps文件），並提出相關的資訊。

適用條件：提煉方法是針對已經有了部分需求文件的情況。依據產品的本來情況，可能有很多文件需要複審，以確定其中是否包含相關聯的資訊。在有的情況，也可能只有少數文件需更釘審

以上方法需要綜合運用到一個專案中。

四、需求規約

一個需求規約是一個軟體項/產品/系統所有需求陳述的正式文件，是一個軟體產品/系統的概念模型。
一般來說，SRS應必須具有以下4個性質：
①重要性和穩定性程度（Ranked for importance and stability）.例如：基本需求、可選的需求和期望的需求。
②可修改的（Modifiable）：在不過多地影響其它需求的前提下，可以容易地修改一個單一需求.
③完整的（Complete）：沒有被遺漏的需求.
④一致的（Consistent）：不存在互斥的需求.

其中，就功能的需求規約來說，還應考慮以下問題：
（1）功能源。
（2）功能共享的資料。
（3）功能與外部介面的互動。
（4）功能所使用的計算資源。

在獲取以上初始需求的基礎上，可採用ICEE標準830-1998所給出的格式，完成一個完整的需求文件草案的編制工作。

學習筆記來源於中國大學Mooc上北京大學的《軟體工程》選修課。