參與人員角色及職責
項目負責人
– 參與評審給定的需求
– 確認需求規(guī)格說明書、并簽字
– 提出需求和需求變更請求，確認修改方案和結(jié)果并簽字
– 主持三方SCCB會議
用戶代表
– 參與評審給定的需求
– 確認需求規(guī)格說明書、并簽字
– 提出需求和需求變更請求，確認修改方案和結(jié)果并簽字
項目總負責人-部門經(jīng)理/副經(jīng)理）
– 評審需求管理活動
– 參與給定需求、需求規(guī)格說明書的評審和基線產(chǎn)品評審
– 主持內(nèi)部SCCB會議
內(nèi)部SCCB
– 需求基線建立后，內(nèi)部人員提出的重大變更或意見分歧由內(nèi)部SCCB解決。
開發(fā)組長
– 組織、開展需求交流活動、
– 組織基線文檔的編寫、審查、評審
– 對客戶需求精練和細化、建立與客戶需求一致的產(chǎn)品、和產(chǎn)品構(gòu)件初步需求
– 跟蹤需求變更、對重大問題擬定初步的變更方案和實施計劃提交內(nèi)部SCCB 評審
– 審查工作產(chǎn)品，以便與需求變更保持一致
– 根據(jù)確定的需求和變更修改方案調(diào)整開發(fā)計劃、分配任務
開發(fā)組成員
– 參與需求分析、收集、整理、評審活動
– 參與文檔化需求、基線文檔的編寫
– 跟蹤需求變更、及時反映客戶的需求、需求變更批準后修改程序和相關(guān)文檔。
– 定期維護系統(tǒng)功能狀態(tài)跟蹤表、統(tǒng)計用戶問題數(shù)以及解決狀態(tài)
– 按照開發(fā)計劃完成任務，為設計、編碼工作做必要的準備
測 試 組
-- 根據(jù)需求規(guī)格說明書編寫相應的驗收方案、驗收大綱、驗收用例；需求變更批準后調(diào)整測試計劃、修改驗收方案、驗收大綱、驗收用例
– 跟蹤測試開發(fā)組修改的問題
維護組
– 收集用戶電話、E-mail、公告欄提出的需求提交開發(fā)組
SQA工程師
– 審查需求活動、工作產(chǎn)品，并報告檢查結(jié)果
– 每月統(tǒng)計系統(tǒng)功能變更數(shù)、變更率
– 參加給定需求、需求規(guī)格說明書的評審和基線產(chǎn)品評審
配置管理員
– 負責基線文檔和工作文檔的管理
– 按照基線變更控制規(guī)程存取基線文檔
需求管理活動過程
如下圖所示：
活動過程
需求獲取方式
- 問卷調(diào)查
- 與不同層次、不同類型的用戶面談
- 現(xiàn)場觀摩工作流程，觀察實際操作
- 從行業(yè)標準中提出需求
- 文檔追溯（公司內(nèi)部，客戶現(xiàn)場，記得涉密材料一定要專人管理）
- 外聘相關(guān)行業(yè)專家
- 原型法、用例法、流程圖法等直觀表現(xiàn)形式
需求分析方法及要點
- 分析需求，判斷是否滿足項目的高層需求的目標。
- 確保需求具備完整性、正確性、可行性、無二義性、及可驗證性：
- 利用技術(shù)術(shù)語將用戶需求描述成產(chǎn)品需求。
- 建立需求跟蹤矩陣，標識需求的優(yōu)先級別、標識對成本、進度、功能、性能等有強烈影響的關(guān)鍵需求；建立和維護用戶需求與功能需求之間的映射，以便需求發(fā)生變化時評估其對產(chǎn)品的影響。
- 逐級分解功能需求，將產(chǎn)品需求分配到對應的功能。
- 將產(chǎn)品需求分配給不同的產(chǎn)品組件。
- 確定接口需求，包括系統(tǒng)內(nèi)部不同組件的需求及本系統(tǒng)與其它系統(tǒng)的接口。
- 編寫用戶使用手冊，設立不同的場景分析用戶深層次的需求。
- 編寫驗收測試用例，每個軟件需求，都應形成測試用例或驗證方法（如：演示、分析、審查等方法），以確保該需求可以得到驗證。
- 編寫用戶使用手冊、驗收測試用例的過程要說明操作步驟和結(jié)果。
- 通過上述方法不斷細化、分析需求，逐級分解功能需求、
需求確認
活動1：內(nèi)部評審
《需求規(guī)格說明書》編寫完成之后，應對其進行正式技術(shù)評審。找出需求中存在的問題，進行更改；最終得到項目負責人簽字、相關(guān)組/人認可。
活動2：外部評審
《需求規(guī)格說明書》內(nèi)部評審通過后、應提交甲方評審、得到甲方項目負責人簽字、有關(guān)方面認可。
需求跟蹤
目前作者所接觸到的根據(jù)需求的最有效和最普遍的需求跟蹤方法是通過映射的方法建立需求跟蹤矩陣來實現(xiàn)。
正向跟蹤：檢查需求文檔中的每個需求是否都能在后續(xù)的工作成果中找到對應點，沒有的對應點要分析、是后續(xù)產(chǎn)品遺漏還是需求沒有及時更新，制定解決方案，指定相關(guān)人解決；消除不一致性后，項目經(jīng)理更新需求跟蹤矩陣。
逆向跟蹤：檢查設計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處，沒有出處的要確認、是后續(xù)產(chǎn)品的錯誤還是需求沒有及時更新，制定解決方案，指定相關(guān)人解決；消除不一致性后，項目經(jīng)理更新需求跟蹤矩陣。
需求變更流程
任何的項目執(zhí)行過程，都會涉及需求的變更，控制好變更流程，大大減少工作量。
過程文檔
- 需求規(guī)格說明書、包括以下需求要素：
項目基本情況（背景、目標、范圍、系統(tǒng)特點）、用戶分析、假定和約束、項目風險、業(yè)務需求、功能需求、性能需求、其他非功能需求（外部接口需求等）、系統(tǒng)運行環(huán)境等；
- 需求調(diào)查報告：
需求訪談、調(diào)查后編寫，作為需求規(guī)格說明書的準備材料
- 需求跟蹤矩陣
建立和維護用戶需求與功能需求之間的映射，以便需求發(fā)生變化時評估其對產(chǎn)品的影響；
- 系統(tǒng)功能狀態(tài)跟蹤表
系統(tǒng)功能列表、逐級列出系統(tǒng)功能、標注各功能狀態(tài)；
- 統(tǒng)計新增、修改、刪除功能數(shù)、功能變更率
- 用戶變更請求與處理單
- 會議概要，現(xiàn)場情況記錄
- 資料接收清單
防止文檔移交過程中丟失
- DEMO/原型
- 可視化頁面：操作頁面、PPT、業(yè)務流程圖、輸入/輸出數(shù)據(jù)表等
- 業(yè)務流程說明、各模塊功能說明、接口說明、及系統(tǒng)非功能性需求說明等
- 驗收大綱、測試用例
依據(jù)需求規(guī)格說明書、用戶認可的文檔化需求、以及任何相關(guān)資料、驗收標準編寫；
目的是確認需求而不僅僅是驗證需求。
- 用戶使用手冊
依據(jù)需求規(guī)格說明書、和用戶使用的場景編寫。
- 用戶提供資料：
用戶認可的文檔化需求、以及任何相關(guān)資料、行業(yè)法律/法規(guī)等
常用工具
1、Axure RP
StarUML
Microsoft Visio
XMind
常用模板
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權(quán)，不承擔相關(guān)法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。
