前言
軟件需求這門課我基本上沒怎麼聽，但是老師課上完後就考試真的是很怕，給了一些重點範圍，我整理了一下，雖然不一定全，但至少應該掌握這些。
軟件危機及其表現
軟件危機是指落後的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一系列嚴重問題的現象。
表現：
1) 軟件需求增長得不到滿足
2) 軟件生產高成本、價格昂貴
3) 軟件生產進度無法控制
4) 軟件需求定義不準確
5) 軟件質量不易保證
6) 軟件可維護性差
軟件過程模型的概念
軟件過程模型又稱為軟件開發模型，它是軟件開發全部過程，活動和任務的結構框架。
瞭解瀑布模型（優缺點），原型模型，up模型，敏捷過程
瀑布模型
瀑布模型的優點：
簡單易用，將複雜的軟件開發過程明確分解為幾個順序的步驟，降低開發軟件的複雜性。有利於大型軟件開發過程中人員組織、管理。有利於軟件開發方法和工具的研究，從而提高了大型項目開發的質量和效率。
嚴格，第一是每個步驟的嚴格，每個步驟都有明確的標準和技術審查，儘量減少每個步驟的錯誤，同時減少對下個階段的影響。第二是對文檔的嚴格要求，每個階段都有各自的規格說明書。
瀑布模型的缺點：
開發過程一般不能逆轉，否則代價太大；很難嚴格按該模型進行；（很難清楚地給出所有的需求。
一次性：單向開發，開發期間沒有迭代過程，無法適應用戶不明確的需求或需求出現變動，難以適應現代軟件開發模式的問題。
用戶的風險：瀑布模型順序嚴格，用戶到軟件開發結束才能看到最終結果，可能離用戶預期的需求有很大差距，開發風險大。
瀑布模型的使用範圍：用戶的需求非常清楚全面，且在開發過程中沒有或很少變化,對軟件的應用領域很熟悉；用戶的使用環境非常穩定；開發工作對用戶參與的要求很低。
快速原型模型
快速原型模型的優點：可以得到比較良好的需求定義，容易適應需求的變化；有利於開發與培訓的同步；費用低、開發週期短且對用戶更友好。
快速原型模型的缺點：客戶與開發者對原型理解不同； 準確的原型設計比較困難； 不利於開發人員的創新。
快速原型模型的使用範圍：對所開發的領域比較熟悉而且有快速的原型開發工具；項目招投標時，可以以原型模型作為軟件的開發模型；進行產品移植或升級時，或對已有產品原型進行客戶化工作時，原型模型是非常適合的。
UP模型（統一過程模型）
（過程框架：初始，細化，構造，移交）
統一過程模型：是風險驅動的，基於用例技術，以架構為中心的，迭代的，可配置的軟件開發流程
五個核心工作流程：需求 分析 設計 實現 測試
敏捷過程（agile process）
是一種以人為核心、迭代、循序漸進的開發方法。它是由17個工程師為了解決日益龐大的開發團隊和繁瑣的開發過程、大量的文檔中解脫開發人員的工作量達成的一項共識。在敏捷過程中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特徵。簡言之，就是把一個大項目分為多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程中軟件一直處於可使用狀態。
敏捷過程是全一個全新的新理論。他不同於原來的6Sigma，ISO9000和CMM。細心的人們可以發現，敏捷過程也借鑑了大量軟件工程中的方法。迭代與增量開發，這兩種在任何一本軟件工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有更多。
改善，而非創新。敏捷過程可理解為在原有軟件開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷過程繼承了不少原有方法的優勢。“在敏捷軟件開發的過程中，我們每兩週都會得到一個可以工作的軟件，”Fowler介紹，“這種非常短的循環，使終端客戶可以及時、快速地看到他們花錢構建的軟件是一個什麼樣的結果。”
敏捷過程的價值觀:
個體和交互 勝過 過程和工具
可以工作的軟件 勝過 面面俱到的文檔
客戶合作 勝過 合同談判
響應變化 勝過 循環計劃
鼓勵和側重左側的內容，不是完全的支持。她強調人的作用，希望在開發團隊中有優秀的開發人員。
需求分類(描述角度，需求有哪幾種）
1）功能需求： 和系統主要工作相關的需求，即在不考慮物理約束的情況下，用戶希望系統所能夠執行的活動，這些活動可以幫助用戶完成任務。功能需求主要表現為系統和環境之間的行為交互。
功能需求三個不同抽象層次之間有緊密的聯繫
l 業務需求：反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與範圍文檔中予以說明。
l 用戶需求：文檔描述了用戶使用產品必須要完成的任務，這在使用實例（use-case）文檔或方案腳本(scenario)說明中予以說明。
l 功能需求：定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。所謂特性(feature)是指邏輯上相關的功能需求的集合，給用戶提供處理能力並滿足業務需求。軟件需求各組成部分之間的關係如圖所示。
軟件需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規範和合約；外部界面的具體細節。
2）性能需求：系統整體或其組成部分應該擁有的性能特徵，如CPU使用率和內存使用率等。
3）質量屬性：系統完成工作的質量，即系統需要在一個“好的程度”上實現功能需求，如可靠性程度和可維護性程度等。
4）對外接口：系統和環境中其他系統之間需要建立的接口，包括硬件接口，軟件接口和數據庫接口等。
5)約束：進行系統構造時需要遵守的約束，如編譯語言和硬件設施等。
除了上述5中明確的軟件需求類別以外，還指出項目中也可能出現邏輯數據需求等其他特殊類型的需求。
在非功能需求中質量屬性對系統成敗的影響極大，因此在某些情況下，非功能需求又被用來特指質量屬性。
需求工程及過程
需求工程是軟件工程的核心組成部分，是指應用有效技術、方法進行需求分析，確定客戶需求，幫助分析和設計人員理解問題，並定義目標系統的一門學科。
它把整個軟件需求工程研究領域劃分為需求開發和需求管理兩部分。
需求管理和開發
需求獲取：需求獲取是從人、文檔、或環境中獲取需求的過程，必須用各種方法和技術來發現需求，需求開發的過程包含學習和認知的兩個過程，學習和認知是遞進的。具體有：1收集背景資料2、獲取問題與目標，定義項目前景和範圍3、識別涉眾，選擇信息的來源4、選擇獲取方法，執行獲取、獲取功能與非功能需求5、記錄獲取結果
需求分析：1、背景資料2、問題分析、目標分析、業務分析、確定系統邊界3、軟件需求建模4、細化需求5、確定優先級6、需求協商
需求規格說明： 1、定製文檔模板2、編寫文檔
需求驗證：1、執行驗證2、問題修正
需求管理：1、建立和維護需求基線集2、建立需求和跟蹤信息3、進行變更控制、
需求開發過程是迭代和併發的。
需求開發過程與軟件工程過程的相互影響：
需求獲取和需求分析是相互交織的，需求獲取與需求分析是需求開發過程的兩個主要活動
需求獲取的難點
1) 用戶和開發人員的背景不同，立場不同
2) 普通用戶缺乏概括性、綜合的表述能力
3) 用戶存在認知困境
4) 用戶越俎代庖
5) 缺乏用戶參與
2，需求獲取的活動
1) 研究應用背景，建立初始的知識框架
2) 根據獲取的需要，採用必要的獲取方法和技巧
3) 現行確定獲取的內容和主題，設定場景
4) 分析用戶的高（深）層目標，理解用戶的意圖
5) 進行涉眾分析，針對涉眾的特點展開工作
需求獲取的方法
1) 傳統方法:
常見的有問卷調查、面談、文檔分析、文檔檢查和需求剝離等
2) 集體獲取方法：
該類方法將很多涉眾集中在一起，通過與涉眾的討論發現需求，並在討論中達成需求的一致，同時它還可以有效利用時間。常見的優頭腦風暴、專題討論會、JAD（聯合應用開發）和JRP（聯合需求計劃等）
3) 原型：
原型方法在軟件系統的很多開發階段都起著十分重要的作用，其中就包括需求獲取。在需求模糊和不確定性較大的情況下，原型方法尤其有效。
4) 模型驅動方法
該類方法都有一個定義明確的模型，模型的定義方式確定了所要收集的的信息類型，模型建立和完善的過程就是進行需求獲取的過程。常見的有面向目標的方法、基於場景的方法和基於用例的方法。
5) 認知方法
該類方法起源於知識系統中的知識獲取方法，以認知的方式獲取用戶無法表達的潛在知識。常見的優任務分析和協議分析等。
6) 基於上下文的方法
前面5種方法基本都以用戶的語言表達為主要關注點，相比之下基於上下文的方法更加註重用戶在一定環境下表現出來的行為，通過分析用戶的行為得到信息。常見的有觀察、民族誌和話語分析。
需求獲取的來源
1) 涉眾：包括用戶、客戶、領域專家以及市場人員、銷售人員等其他用戶替代源。
2) 硬數據：包括登記表格、單據、報表等定量文檔，以及備忘錄、日誌等定性文檔。
3) 相關產品：包括原有系統、競爭產品及協作產品（和解系統存在接口的其他軟件系統）。
4) 重要文檔：包括原有系統的規格說明、競爭產品的規格說明、協作產品的規格說明及客戶的需求文檔（委託開發的規格說明、招標書）。
5) 相關技術標準和法規：包括相關法律、法規及規章制度，行業規範、行業標準及領域參考模型。
什麼是涉眾
所有對軟件系統開發和應用具有發言權和決定權的人統稱為涉眾。
定義：所有能夠影響軟件系統的實現，或者會被實現後的軟件系統所影響的個體和團體。
涉眾的分類
客戶、用戶、領域專家、開發者、管理者、市場、法律、法規、政策、標準、規範。
涉眾的分析過程
一個典型的涉眾分析過程，它從比較容易發現的初始涉眾出發，先後執行涉眾識別、涉眾描述、涉眾評估和涉眾代表選擇4個步驟，最終完成涉眾分析的各項任務。
對涉眾的深入理解：涉眾特徵描述，不僅有利於進行項目前景與範圍的確定，而且對整個軟件開發而言都是重要的參考信息，所有涉眾特徵描述信息需要記錄下來，在項目的各個開發階段共享使用。
面談的問題的類型及其優缺點
開放式問題
優點：讓被會見者感到自在；會見者可以收集被會見者使用的詞彙，這能反應他的教育、價值標準、態度和信念；提供豐富的細節。
缺點：提此類問題可能會產生太多不相干的細節；面談可能失控；開放式回答會花費大量的時間才能獲得有用的信息。
封閉式問題
優點：節省時間；切中要點；保持對面談的控制；快速探討大規範問題；得到貼切的數據。
缺點：使被會見者厭煩；得不到豐富的細節；出於上述原因。失去主要思想；不能和麵談者建立友好關係。
面談的類別及其適用場景
結構化面談：通常被用來獲取一些比較確定或者選擇空間比較有限的信息，一些統計性傾向信息的獲取也可以使用結構化面談
半結構化面談：通常用來在一個基礎框架下處理探索性的問題。即會見者對面談主提有一定的瞭解，能夠建立一個基礎框架，並據此制定面談問題和麵談結構，然後根據探索性需要進行策略的使用和調整。半結構化是在需求中應用最多的一種面談類型，能夠處理大部分需求獲取任務。
非結構化面談：
非結構化面談較多使用開放式問題。
原型的分類及其用法
水平和垂直的原型
水平原型也叫做“行為原型” (behavioral prototype)，這是我們和業務人員經常談到的原型 。探索預期系統的一些特定行為，並達到細化需求的目的。當用戶在考慮原型中所提出的功能可否使他們完成各自的業務任務時，原型使用戶所探討的問題更加具體化。它更多從業務需求著手，應用在需求階段。
垂直原型（vertical prototype），也叫做結構化原型或概念的證明，實現了一部分應用功能。當預期實現階段可能存在技術風險時，可以開發一個垂直原型。比起在軟件的需求開發階段，垂直原型更常用於軟件的設計階段以減少風險。
拋棄型原型或進化型原型
從原型存在生命時機考慮分為拋棄型原型和進行型原型，拋棄型原型不作為最終產品的一部分，只是作為探索性的回答一些需求問題，細化需求並提高需求質量。由於在開發階段最終將拋棄這些原型，因此不需要花太大力氣去建立該原型。
進化型原型是在已經清楚地定義了需求的情況下，為開發漸進式產品提供了堅實的開發基礎，作為產品的部分實現。與拋棄型原型的快速、粗略的特點相 比，進化式模型一開始就必須具有健壯性和產品質量級的代碼。因此，對於描述相同的功能，建立進化型原型比建立拋棄型原型所花的時間要多。一個進化型原型必須設計為易於升級和優化的，因此，你必須重視軟件系統性和完整性的設計原則。要達到進化型原型的質量要求並沒有捷徑。進化型原型一般在處理架構時會採用。
原型的優缺點
要點
準備原型
決定原型方法：拋棄型還是進化型原型？水平還是垂直型原型？
標識需要建模的功能點
製作原型
構建原型是一個迭代的過程，開始先勾畫出整個系統的輪廓，例如子系統、模塊，然後再是具體模塊邏輯、功能、規則等
使用一致的界面樣式
評估原型
從流程、數據和業務規則來驗證原型是否捕獲了用戶的需要
使用時需要考慮的地方
好處
1) 使用圖形化表現，方便溝通，可以更有效地確認和發現需求
2) 原型允許用戶早期交互和反饋
3) 拋棄型原型是一種快速發現和確認不同需求的方法
4) 垂直型原型能夠表示現有技術的可行性
壞處
1) 如果業務更關注“怎麼做”而不是“做什麼”時，使用原型會花費較多時間
2) 原型會誤導用戶對未來系統有不切實際的期望，例如性能、完整數據、可靠性等
需求分析的方法
1) 傳統分析
2) 結構化分析
3) 信息工程
4) 面向對象分析
建模的方法和手段
UML（統一建模語言）是一種標準的圖形化建模語言，它是面向對象分析與設計的一種標準表示。
用例建模：用例圖和用例說明描述用戶需求。
靜態建模：通過類圖/對象圖描述系統中的對象如何組成系統。
動態建模：描述系統動態行為和控制結構。主要有順序圖、協作圖、狀態圖、活動圖。
實現模型：描述了系統現實時的特性，即物理架構，包括組件圖和部署圖。
預定酒店的例子
1）用例模型
2）用例描述
3）根據用例描述畫出類圖和交互圖
