常見的ieee1998，將需求分為5類：功能需求、效能需求、質量需求、對外介面和約束。
優秀需求的特徵：完整性、正確性、精確性（確定性）、可行性、必要性、無歧義、可驗證、一致性、可追蹤。
srs（software requirements specification）是軟體需求規格說明書
高質量的srs需要滿足：完整性、一致性、可追蹤行、可修改性。
涉眾：與待開發系統有利益關係的人員或組織。其本身並不一定與系統開發有直接利益關係。
需求獲取的方法：面向目標（物件導向）、基於場景、面向方面、面向視點、基於知識。
需求獲取的常用方法：傳統方法、集體獲取方法、原型、模型驅動方法、認知方法、基於上下文的方法。
文件審查的三種方法：需求重用、文件分析、需求剝離。
資料流圖（dfd）的基本元素：外部實體、過程、資料流和資料儲存。
涉眾分析包含的活動：涉眾識別、涉眾描述、涉眾評估、涉眾選擇。
需求工程原型方法步驟：確定原型需求、原型開發、原型評估、原型修正。
需求工程的方法分四類：物件導向、面向資料、面向控制、面向工程。
常見的需求定義錯誤：沒有反應使用者真實需求、模糊和歧義的需求、資訊遺漏、不必要的需求、不切實際的期望。
微規格說明是一些被用來描述過程處理的技術，主要有三種技術：結構化英語、行為圖、決策樹。
用例模型的四種基本元素：用例、參與者、關係、系統邊界。
資料流圖（dfd）層次結構建立步驟：建立上下文圖、發現並建立dfd片段、根據dfd片段組合產生層圖、產生n層資料流圖。
需求跟蹤的實現方法有：矩陣、實體聯絡模型和交叉引用。
通用的跟蹤模型有：在系統定義領域跟蹤需求、在實現領域跟蹤需求、在測試領域跟蹤需求。
軟體需求包括不同層次分別是：業務需求、使用者需求、功能需求、非功能需求。
功能需求三個體現層次：業務需求、使用者需求、系統需求。
物件導向建模中用到的技術包括：物件模型、用例模型、行為模型、狀態機模型和物件約束語言。
需求規格說明活動就是將需求和軟體解決方案進行定義和文件化，並傳遞給開發人員的需求工程活動。
業務需求、高層解決方案、系統邊界都因該定義到專案前景與範圍文件。
系統願景通常定義了系統的高層目標。
功能需求說明了系統向使用者提供的功能。質量需求定義了待開發的質量屬性，即系統的效能、可靠性、穩定性等。約束是對開發或待開發系統屬性的限制。
系統分析包括在對乙個現有系統或過程進行分析的基礎上定義乙個新系統（發布版本）需求的各種不同方法。
通常，新的系統實現了對現有系統和過程的自動化，並因此取代現有系統和過程。
傳統的系統按照功能、資料和行為來定義乙個系統所期望實現的功能方面。
結構化分析使用資料流圖來描述系統功能以及每個功能的輸入輸出。
結構化分析方法一般會區分物理模型和邏輯模型。首先開發出乙個物理的當前狀態模型，然後去掉其中的物理特性後就得到了當前狀態的模型。為了定義系統需求，需要將所期望的變更整合到邏輯狀態模型中，從而定義出邏輯的期望狀態模型。結構化分析方法沒有為邏輯模型的匯出提供方法指導，本質系統分析方法很好地填補了這個缺失。
需求製品來指代乙個被文件化的需求，因此乙個需求製品使用特定的文件格式來刻畫乙個需求。
用況聚集了同乙個目標相關聯的多個場景。用況將乙個主場景與相應的可替換場景和例外場景組織在一起，它包括上下文資訊、主場景、可替換場景、例外場景。
活**側重於描述在多個場景（例如屬於同一用況的場景）之間的控制流，及不同參與者的活動以及這些活動的可能順序，它是一種控制流圖。
用例圖不適合用來描述系統參與者的互動（序列）。但特別適合用於系統中不同用況以及用況之間的視覺化描述。
需求開發的一般過程分為需求獲取、需求建模、需求規格說明、需求驗證4個階段。
評審型別：評審、走查、審查。
需求變更的原因：對需求理解存在分岐、系統實施時間過長、使用者業務需求變更、正常公升級。
軟體需求的目標是充分、清晰、無歧義的表達。
功能模型的構成要素主要有處理、資料流、動作物件、資料儲存四個方面。
統一建模語言（uml）是一種物件導向的建模語言，它是運用統一的、標準化的標記和定義實現對軟體系統進行物件導向的描述和建模。主要應用與基於物件的物件導向方法。
魚骨圖（又名因果圖、石川圖、ishikawa），指的是一種發現問題「根本原因」的分析方法。可以用來挖掘出問題背後的問題。分為整理問題型魚骨圖、原因型魚骨圖、對策型魚骨圖。其特點是簡捷實用，深入直觀。它看上去有些像魚骨，問題或缺陷（即後果）標在「魚頭」外。在魚骨上長出魚刺，上面按出現機會多寡列出產生問題的可能原因，有助於說明各個原因之間是如何相互影響的。
需求管理體系包括：需求人員管理、需求工具管理、需求文件管理、需求變更管理。
主要的軟體過程模型：瀑布模型、演化模型（原型模型、增量模型、螺旋模型）、噴泉模型、基於構件的開發模型和形式化方法模型等。
評價場景應該使用：正確性、完整性、簡單性、適應性、整合性、理解性、實現性準則。
資料流圖有變換型和事務性兩種型別。
軟體設計的原則：抽象與逐步求精、模組化、資訊隱藏等。
軟體生命週期包括需求、設計、編碼、單元測試、驗收測試、維護六個階段。
軟體的六個質量標準：功能性、可靠性、可用性、有效性、可維護性、可移植性。
軟體工程三要素：方法、工具、過程。
主要的軟體開發方法有：結構化開發方法、原型化開發方法、物件導向開發方法。
需求分析的步驟：調查研究、分析與綜合、書寫文件、需求分析評審。
需求分析階段需要編寫的文件：軟體需求規格說明書（srs）、初步使用者使用手冊、確認測試計畫。
統一軟體開發過程（rup）：核心工作流：分為6個核心過程工作流：商業建模、需求、分析和設計、實現、測試、部署。3個核心支援工作流：配置和變更管理、專案管理、環境。四個階段：初始階段、細化階段、構造階段、交付階段。十大要素：開發乙個前景、達成計畫、標識和減小風險、分配和跟蹤任務、檢查商業理由、設計元件構架、構建和測試、驗證和評價結果、管理和控制變化、提供使用者支援。六大經驗：迭代式開發、管理需求、使用基於構件的體系架構、軟體的視覺化建模、驗證軟體質量、控制軟體變更。
需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。
需求配置管理的好處：1、避免需求在未授權的情況下變更，或在有潛在破壞性的情況下不受限制的隨意變更；2、保護對需求文件的修正；3、方便對文件以前版本的檢索或重建；4、支援系統以增量的方式改進基線；5、避免對文件的同時更新和衝突。
實體-聯絡圖(erd)的基本構建有：基本要素（資料物件（實體）、屬性、關係）和各種型別指示符。erd提供了表示實體型別、屬性和聯絡的方法，用來描述現實世界的概念模型。
gantt圖（甘特圖、橫道圖）它是以圖標的方式通過活動列表和時間刻度形象地表示出任何特定專案的活動順序與持續時間。其內在思想簡單，基本是一條線條圖，橫軸表示時間，縱軸表示活動(專案)，線條表示在整個期間上 計畫和實際的活動完成情況。它直觀地表明任務 計畫在什麼時候進行，及實際進展與計畫要求的對比。由於 甘特圖形象簡單，在簡單、短期的專案中， 甘特圖都得到了最廣泛的運用。
需求過程應建立3種模型：資料模型、功能模型、行為模型。資料流圖（dfd）屬於功能模型，實體-聯絡圖（erd）屬於資料模型，狀態轉移圖（std）屬於行為模型。
面談的類別：結構化面談、半結構化面談、非結構化面談。
crc (class,responsibility,and collaboration)類，責任和互動，簡稱crc卡片。在物件導向程式設計中，用來闡述類、類的行為和類的責任的乙個非常好的途徑。
原型的種類：探索式、實驗式、演化式。探索式和實驗式又稱作拋棄型原型。這兩種方法產生的原型往往是經歷了很多次錯誤的嘗試之後才產生的。這些錯誤的嘗試過程會在最終的原型產品當中留下痕跡，它們會使原型產品的質量很差。不能因為拋棄型原型花費了成本和人力就將它整合到最終的產品中，這樣是得不償失的。因為拋棄型原型是要被最終丟棄的，所以在構建時應該以最小的代價，爭取最快的速度。為此，開發者可能會使用一些簡易的開發工具和不成熟的構造技術，也可能忽略或簡化一些和原型目標不相關的功能特徵。與拋棄型原型相反，演化式原型要求原型產品作為資產沿著開發過程向後傳遞，並可能被後繼過程修改和增強，最後成功系統或產品的乙個部分，因此演化模型必須具有健壯性，需要採用好的體系架構和設計原則，利用成熟的技術和熟練的工具構建。
原型構建技術：水平構建原型（水平型原型）、垂直構建原型（垂直型原型）。水平構建原型法：該方法僅僅實現選定功能所有層次中的某些特定層次，例如使用者介面層，他能夠處理較大範圍的功能，建立的原型產品成為水平原型。垂直原型法：該方法會觸及選定功能實現的所有層次，處理的功能範圍較小，建立的原型產品成為垂直原型
需求工程的推薦方法
需求工程推薦方法 知識技能 需求管理 專案管理 l培訓需求分析人員 l培訓使用者代表和管理人員 l培訓應用領域的開發人員 l彙編術語 l確定變更控制過程 l建立變更控制委員會 l進行變更影響分析 l跟蹤影響工作產品的每項變更 l編寫需求文件的基準版和控制版本 l維護變更歷史記錄 l跟蹤需求穩定性 l...
需求變更管理和需求的可追溯性
在專案管理過程中，總是難免會碰到需求的變更，需求變更之所以會產生，可能是使用者不能清晰描述需求或對需求也不是特別明確，也可能是開發人員對需求理解與使用者不一致，或者是使用者需求確實有更改，或者是遇到其他外部環境的影響 如國家政策 需求的變更總會對專案產生一定的影響，比如專案範圍 專案進度 專案質量 ...
專案需求的重要性
最近看到網上瘋傳的幾張，著實道出大家內心的想法呀！沒有經歷過的人恐怕真的無法體會到其中的 精髓 只有真正經歷的人，才能產生更多的共鳴吧。哈哈 最近跟乙個專案，從前期需求分析階段開始，由於整個 及其需求都不了解，討論需求的時候很難跟客戶產生共鳴，只好聽專案經理跟客戶一同討論。旁聽不懂的東西其實也挺煎熬...