需求工程部分知識點

1. 常見的IEEE1998，將需求分爲5類：功能需求、性能需求、質量需求、對外接口和約束。
2. 優秀需求的特徵：完整性、正確性、精確性（確定性）、可行性、必要性、無歧義、可驗證、一致性、可追蹤。
3. SRS（Software Requirements Specification）是軟件需求規格說明書
4. 高質量的SRS需要滿足：完整性、一致性、可追蹤行、可修改性。
5. 涉衆：與待開發系統有利益關係的人員或組織。其本身並不一定與系統開發有直接利益關係。
6. 需求獲取信息的來源可能有哪些：涉衆、硬數據、相關產品（現有系統等）、重要文檔、相關技術標準和技術法規。
7. 需求獲取的方法：面向目標（面向對象）、基於場景、面向方面、面向視點、基於知識。
8. 三類與需求獲取相關的現有系統：遺留系統和原有系統、競爭對手的系統、以及類似系統。
9. 需求獲取的常用方法：傳統方法、集體獲取方法、原型、模型驅動方法、認知方法、基於上下文的方法。
10. 文檔審查的三種方法：需求重用、文檔分析、需求剝離。
11. 數據流圖（DFD）的基本元素：外部實體、過程、數據流和數據存儲。
12. 涉衆分析包含的活動：涉衆識別、涉衆描述、涉衆評估、涉衆選擇。
13. 需求工程原型方法步驟：確定原型需求、原型開發、原型評估、原型修正。
14. 需求工程的方法分四類：面向對象、面向數據、面向控制、面向工程。
15. 常見的需求定義錯誤：沒有反應用戶真實需求、模糊和歧義的需求、信息遺漏、不必要的需求、不切實際的期望。
16. 微規格說明是一些被用來描述過程處理的技術，主要有三種技術：結構化英語、行爲圖、決策樹。
17. 用例模型的四種基本元素：用例、參與者、關係、系統邊界。
18. 面談中相關問題的組織結構：金字塔結構、漏斗結構、菱形結構。
19. 數據流圖（DFD）層次結構建立步驟：創建上下文圖、發現並建立DFD片段、根據DFD片段組合產生層圖、產生N層數據流圖。
20. 需求跟蹤的實現方法有：矩陣、實體聯繫模型和交叉引用。
21. 通用的跟蹤模型有：在系統定義領域跟蹤需求、在實現領域跟蹤需求、在測試領域跟蹤需求。
22. 軟件需求包括不同層次分別是：業務需求、用戶需求、功能需求、非功能需求。
23. 功能需求三個體現層次：業務需求、用戶需求、系統需求。
24. 面向對象建模中用到的技術包括：對象模型、用例模型、行爲模型、狀態機模型和對象約束語言。
25. 需求規格說明活動就是將需求和軟件解決方案進行定義和文檔化，並傳遞給開發人員的需求工程活動。
26. 業務需求、高層解決方案、系統邊界都因該定義到項目前景與範圍文檔。
27. 系統願景通常定義了系統的高層目標。
28. 功能需求說明了系統向用戶提供的功能。質量需求定義了待開發的質量屬性，即系統的性能、可靠性、穩定性等。約束是對開發或待開發系統屬性的限制。
29. 系統分析包括在對一個現有系統或過程進行分析的基礎上定義一個新系統（發佈版本）需求的各種不同方法。
30. 通常，新的系統實現了對現有系統和過程的自動化，並因此取代現有系統和過程。
31. 傳統的系統按照功能、數據和行爲來定義一個系統所期望實現的功能方面。
32. 結構化分析使用數據流圖來描述系統功能以及每個功能的輸入輸出。
33. 結構化分析方法一般會區分物理模型和邏輯模型。首先開發出一個物理的當前狀態模型，然後去掉其中的物理特性後就得到了當前狀態的模型。爲了定義系統需求，需要將所期望的變更集成到邏輯狀態模型中，從而定義出邏輯的期望狀態模型。結構化分析方法沒有爲邏輯模型的導出提供方法指導，本質系統分析方法很好地填補了這個缺失。
34. 需求製品來指代一個被文檔化的需求，因此一個需求製品使用特定的文檔格式來刻畫一個需求。
35. 用況聚集了同一個目標相關聯的多個場景。用況將一個主場景與相應的可替換場景和例外場景組織在一起，它包括上下文信息、主場景、可替換場景、例外場景。
36. 活動圖側重於描述在多個場景（例如屬於同一用況的場景）之間的控制流，及不同參與者的活動以及這些活動的可能順序，它是一種控制流圖。
37. 用例圖不適合用來描述系統參與者的交互（序列）。但特別適合用於系統中不同用況以及用況之間的可視化描述。
38. 需求開發的一般過程分爲需求獲取、需求建模、需求規格說明、需求驗證4個階段。
39. 評審類型：評審、走查、審查。
40. 需求變更的原因：對需求理解存在分岐、系統實施時間過長、用戶業務需求變更、正常升級。
41. 軟件需求的目標是充分、清晰、無歧義的表達。
42. 功能模型的構成要素主要有處理、數據流、動作對象、數據存儲四個方面。
43. 統一建模語言（UML）是一種面向對象的建模語言，它是運用統一的、標準化的標記和定義實現對軟件系統進行面向對象的描述和建模。主要應用與基於對象的面向對象方法。
44. 魚骨圖（又名因果圖、石川圖、Ishikawa），指的是一種發現問題“根本原因”的分析方法。可以用來挖掘出問題背後的問題。分爲整理問題型魚骨圖、原因型魚骨圖、對策型魚骨圖。其特點是簡捷實用，深入直觀。它看上去有些像魚骨，問題或缺陷（即後果）標在“魚頭”外。在魚骨上長出魚刺，上面按出現機會多寡列出產生問題的可能原因，有助於說明各個原因之間是如何相互影響的。
45. 需求管理體系包括：需求人員管理、需求工具管理、需求文檔管理、需求變更管理。
46. 主要的軟件過程模型：瀑布模型、演化模型（原型模型、增量模型、螺旋模型）、噴泉模型、基於構件的開發模型和形式化方法模型等。
47. 評價場景應該使用：正確性、完整性、簡單性、適應性、集成性、理解性、實現性準則。
48. 數據流圖有變換型和事務性兩種類型。
49. 軟件設計的原則：抽象與逐步求精、模塊化、信息隱藏等。
50. 軟件生命週期包括需求、設計、編碼、單元測試、驗收測試、維護六個階段。
51. 軟件的六個質量標準：功能性、可靠性、可用性、有效性、可維護性、可移植性。
52. 軟件工程三要素：方法、工具、過程。
53. 主要的軟件開發方法有：結構化開發方法、原型化開發方法、面向對象開發方法。
54. 需求分析的步驟：調查研究、分析與綜合、書寫文檔、需求分析評審。
55. 需求分析階段需要編寫的文檔：軟件需求規格說明書（SRS）、初步用戶使用手冊、確認測試計劃。
56. 統一軟件開發過程（RUP）：核心工作流：分爲6個核心過程工作流：商業建模、需求、分析和設計、實現、測試、部署。3個核心支持工作流：配置和變更管理、項目管理、環境。四個階段：初始階段、細化階段、構造階段、交付階段。十大要素：開發一個前景、達成計劃、標識和減小風險、分配和跟蹤任務、檢查商業理由、設計組件構架、構建和測試、驗證和評價結果、管理和控制變化、提供用戶支持。六大經驗：迭代式開發、管理需求、使用基於構件的體系架構、軟件的可視化建模、驗證軟件質量、控制軟件變更。
57. 需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。
58. 需求配置管理的好處：1、避免需求在未授權的情況下變更，或在有潛在破壞性的情況下不受限制的隨意變更；2、保護對需求文檔的修正；3、方便對文檔以前版本的檢索或重建；4、支持系統以增量的方式改進基線；5、避免對文檔的同時更新和衝突。
59. 實體-聯繫圖(ERD)的基本構建有：基本要素（數據對象（實體）、屬性、關係）和各種類型指示符。ERD提供了表示實體類型、屬性和聯繫的方法，用來描述現實世界的概念模型。
60. gantt圖（甘特圖、橫道圖）它是以圖示的方式通過活動列表和時間刻度形象地表示出任何特定項目的活動順序與持續時間。其內在思想簡單，基本是一條線條圖，橫軸表示時間，縱軸表示活動(項目)，線條表示在整個期間上 計劃和實際的活動完成情況。它直觀地表明任務 計劃在什麼時候進行，及實際進展與計劃要求的對比。由於 甘特圖形象簡單，在簡單、短期的項目中， 甘特圖都得到了最廣泛的運用。
61. 需求過程應建立3種模型：數據模型、功能模型、行爲模型。數據流圖（DFD）屬於功能模型，實體-聯繫圖（ERD）屬於數據模型，狀態轉移圖（STD）屬於行爲模型。
62. 面談的類別：結構化面談、半結構化面談、非結構化面談。
63. CRC (Class,Responsibility,and Collaboration)類，責任和交互，簡稱CRC卡片。 在面向對象程序設計中，用來闡述類、類的行爲和類的責任的一個非常好的途徑。
64. 原型的種類：探索式、實驗式、演化式。探索式和實驗式又稱作拋棄型原型。這兩種方法產生的原型往往是經歷了很多次錯誤的嘗試之後才產生的。這些錯誤的嘗試過程會在最終的原型產品當中留下痕跡，它們會使原型產品的質量很差。不能因爲拋棄型原型花費了成本和人力就將它整合到最終的產品中，這樣是得不償失的。因爲拋棄型原型是要被最終丟棄的，所以在構建時應該以最小的代價，爭取最快的速度。爲此，開發者可能會使用一些簡易的開發工具和不成熟的構造技術，也可能忽略或簡化一些和原型目標不相關的功能特徵。與拋棄型原型相反，演化式原型要求原型產品作爲資產沿着開發過程向後傳遞，並可能被後繼過程修改和增強，最後成功系統或產品的一個部分，因此演化模型必須具有健壯性，需要採用好的體系架構和設計原則，利用成熟的技術和熟練的工具構建。
65. 原型構建技術：水平構建原型（水平型原型）、垂直構建原型（垂直型原型）。 水平構建原型法：該方法僅僅實現選定功能所有層次中的某些特定層次，例如用戶界面層，他能夠處理較大範圍的功能，建立的原型產品成爲水平原型。垂直原型法：該方法會觸及選定功能實現的所有層次，處理的功能範圍較小，建立的原型產品成爲垂直原型。