作好需求分析設計
作好需求分析,是須要有必定的方式方法的,我總結的方法流程爲:獲取用戶 需求→分析用戶需求→編寫需求文檔→評審需求文檔→管理需求。3d
獲取用戶需求 blog
這是該階段的一個最重要的任務。如下爲獲取用戶需求須要執行的活動接口
瞭解客戶方的全部用戶類型以及潛在的類型。而後,根據他們的要求來肯定系統的總體目標和系統的工做範圍。開發
對用戶進行訪談和調研。交流的方式能夠是會議 、 電話、電子郵件、小組討論、模擬演示等不一樣形式。須要注意的是,每一次交流必定要有記錄,對於交流的結果還能夠進行分類,便於後續的分析活動。例如,能夠 將需求細分爲功能需求、非功能需求(如響應時間、平均無端障工做時間、自動恢復時間等)、環境限制、設計約束等類型。文檔
需求分析人員對收集到的用戶需求作進一步的分析和整理。原型
⑴對於用戶提出的每一個需求都要知道「爲何」,並判斷用戶提出的需求是否有充足的理由;基礎
⑵將那種以「如何實現」的表述方式轉換爲「實現什麼」的方式,由於需求分析階段關注的目標是「作什麼」,而不是「怎麼作」;可視化
⑶分析由用戶需求衍生出的隱含需求,並識別用戶沒有明確提出來的隱含需求(有多是實現用戶需求的前提條件),這一點每每容易忽略掉,常常由於對隱含需求考慮得不夠充分而引發需求變動。軟件
需求分析人員將調研的用戶需求以適當的方式呈交給用戶方和開發方的相關人員。你們共同確認需求分析人員所提交的結果是否真實地反映了用戶的意圖。需求分析人員在這個任務中須要執行下述活動:
⑴明確標識出那些未肯定的需求項(在需求分析初期每每有不少這樣的待定項);
⑵使需求符合系統的總體目標;
⑶保證需求項之間的一致性,解決需求項之間可能存在的衝突。
分析用戶需求
在不少情形下,分析用戶需求是與獲取用戶需求並行的,主要經過創建模型的方式來描述用戶的需求,爲客戶、用戶、開發方等不一樣參與方提供一個交流的渠道。這些模型是對需求的抽象,以可視化的方式提供一個易於溝通 的橋樑。用戶需求的分析與獲取用戶需求有着類似的步驟,區別在於分析用戶需求時使用模型來描述,以獲取用戶更明確的需求。分析用戶需求須要執行下列活動:
以圖形表示的方式描述系統的總體結構,包括系統的邊界與接口;
經過原型、頁面流或其它方式向用戶提供可視化的界面,用戶能夠對需求作出本身的評價;
系統可行性分析,需求實現的技術可行性、環境分析、費用分析、時間分析等;
以模型描述系統的功能項、數據實體、外部實體、實體之間的關係、實體之間的狀態轉換等方面的內容。
1、編寫需求文檔
需求文檔能夠使用天然語言或形式化語言來描述,還能夠添加圖形的表述方式和模型表徵的方式。需求文檔應該包括用戶的全部需求(功能性需求和非功能性需求)。
2、評審需求文檔
需求文檔完成後,須要通過正式評審,以便做爲下一階段工做的基礎。通常的評審分爲用戶評審和同行評審兩類。用戶和開發方對於軟件項目內容的描述,是以需求規格說明書做爲基礎的;用戶驗收的標準 則是依據需求規格說明書中的內容來制訂,因此評審需求文檔時用戶的意見是第一位的。而同行評審的目的,是在軟件項目初期發現那些潛在的缺陷或錯誤,避免這些錯誤和缺陷遺漏到項目的後續階段。
3、管理需求
需求的變動是不可避免的,如何以可控的方式管理軟件的需求,對於項目的順利進行有着重要的意義。若是匆匆忙忙地完成用戶調研與分析,則每每意味着不穩定的 需求。因此需求管理要保證需求分析各個活動都獲得了充分的執行。對於需求變動的管理,則主要使用需求變動流程和需求跟蹤矩陣的管理方式。
軟件需求來自系統工程與客戶兩個方面,其中客戶是主要的需求提供者(系統工程需求也來自於客戶)。客戶須要蒐集其最終用戶的需求並考慮自身的需求,而後再提供給開發方。假如客戶並未去認真蒐集最終用戶的需求,開發方便須要作到這一點,由於系統最終要知足最終用戶的需求。