ch4補充-需求補充

《ch4補充-需求補充》由會員上傳分享，免費在線閱讀，更多相關內(nèi)容在教育資源-天天文庫。

1、需求驗證需求管理訪談技巧訪談焦點確定風險需求驗證審查需求文檔在需求開發(fā)期間進行非正式評審。對需求文檔進行正式審查是保證軟件質(zhì)量的很有效的方法。組織一個由不同代表（如分析人員，客戶，設計人員，測試人員）組成的小組，對需求規(guī)格說明書及相關模型進行仔細的檢查。需求驗證（續(xù)）依據(jù)需求編寫測試用例根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測試用例?？蛻敉ㄟ^使用測試用例以確認是否達到了期望的要求。從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結(jié)果與測試用例相一致。要使用測試用例來驗證需求模型的正確性，如對話

2、框圖和原型等。需求驗證（續(xù)）確定合格的標準確定合格的標準讓用戶描述什么樣的產(chǎn)品才算滿足他們的要求和適合他們使用的。將合格的測試建立在使用情景描述或使用實例的基礎之上。需求驗證（續(xù)）需求確認簽字在主要的業(yè)務清楚以后即可以進行需求確認目的是確定需求基線不要期望所有的需求在簽字后不變需求管理大師說："沒有不變的需求，世上的軟件都改動過3次以上，唯一一個只改動過兩次的軟件的擁有者已經(jīng)死了，死在去修改需求的路上?！八孕枨蠊芾磉^程做的事情就是保證需求變更的可管理性。需求管理（續(xù)）需求基線軟件需求規(guī)格說明及相關分析模型。

3、經(jīng)評審批準，這些文檔就定義了開發(fā)工作的需求基線；建立需求基準版本和需求控制版本文檔確定一個需求基準，這是一致性需求在特定時刻的快照；之后的需求變更就遵循變更控制過程；每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。需求管理（續(xù)）需求變更控制確定需求變更控制過程，確定一個選擇、分析和決策需求變更的過程。需求變更控制流程需求管理（續(xù)）建立變更控制委員會組織一個由項目風險承擔者組成的小組作為變更控制委員會，由他們來確定進行哪些需求變更，此變更是否在項目范圍內(nèi)，估價它們，并對此評估作出決策

4、以確定選擇哪些，放棄哪些，并設置實現(xiàn)的優(yōu)先順序，制定目標版本；變更控制委員會成員可以是甲方與乙方的人員共同組成；定期進行需求變更評審會議；每次評審要有評審報告。需求管理（續(xù)）需求變更影響評估進行需求變更影響分析，應評估每項選擇的需求變更，以確定它對項目計劃安排和其它需求的影響。明確與變更相關的任務并評估完成這些任務需要的工作量。需求管理（續(xù)）需求變更時，修改需求跟蹤能力矩陣跟蹤所有受需求變更影響的工作產(chǎn)品當進行某項需求變更時，參照需求跟蹤能力矩陣找到相關的其它需求、設計模板、源代碼和測試用例，這些相關部分可能

5、也需要修改。需求管理（續(xù)）維護需求變更的歷史記錄記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負責更新和更新的新版本號等。在需求基線的基礎上記錄變更歷史記錄；針對每一個需求形成一個單獨記錄；需求類型功能性需求(FRs)功能性需求描述了一種系統(tǒng)特性，它支持某種角色使用系統(tǒng)完成某種商業(yè)操作。例：系統(tǒng)必須收集如下顧客信息—姓名及地址。非功能性需求(NFRs)非功能性需求描述了一種系統(tǒng)特性，它支持怎樣執(zhí)行某種操作。例：在網(wǎng)絡應用中系統(tǒng)必須能夠同時支持10位用戶使用。訪談技巧訪談并不是一項容易學習的技巧，這

6、里有如下技巧：與業(yè)務所屬者建立友善的關系，參與輕松的交談，但避免講笑話。仔細傾聽。溫和的掌握訪談方向，如果業(yè)務所屬者離題太遠則小心的打斷他的談話。仔細傾聽。重復不清楚的陳述并請求確認。仔細傾聽。獲得詳細記錄。仔細傾聽。愿景訪談焦點愿景訪談需要注意以下方面：用于項目的商業(yè)案例。用于項目的功能需求。風險。約束。項目干系人。業(yè)務案例問題為業(yè)務所屬者解釋為什么需要軟件。你當前的業(yè)務運轉(zhuǎn)情況是怎樣的？你的公司是干什么、做什么或是銷售什么的？公司的結(jié)構是怎樣的？我可以擁有一份公司的組織結(jié)構圖嗎（或是相關的業(yè)務單元）？新的

7、軟件系統(tǒng)打算怎樣支持業(yè)務？你的業(yè)務怎樣變革？你是否計劃擴展你的業(yè)務？公司是否可能會重組？用于發(fā)現(xiàn)功能需求的問題與業(yè)務所屬者解釋針對你的業(yè)務軟件必須做什么？讓業(yè)務所屬者列出（或描述）系統(tǒng)最重要的10項用例。與業(yè)務所屬者重申每一項用例。核實你對于每一項用例的理解。讓業(yè)務所屬者把用例按優(yōu)先級區(qū)分為以下等級：基本的(essential)、重要的(high-level)、后繼的(follow-on)。重復列出這些用例，并且詢問是否遺失了任何重要的用例。用于發(fā)現(xiàn)風險的問題有五個主要的風險區(qū)域。有一些問題可以幫助確定項目風

8、險：在你的業(yè)務中是否有其他小組做相似的功能？你計劃在項目中使用新技術嗎？（例如：J2EE?平臺或簡單對象訪問協(xié)議）你是否有開發(fā)的資源或是計劃把項目外包？你的團隊成員是否有必要的技能？哪個部分的業(yè)務最有可能改變，從而影響軟件系統(tǒng)？用于發(fā)現(xiàn)約束的問題這些問題用于發(fā)現(xiàn)項目中的隱藏約束。項目是否將運用特定的平臺開發(fā)？項目是否會需要特殊的技術？項目是否有固定的交付期限？系統(tǒng)是否與任何外部系統(tǒng)交互？在軟件的操作