入是可用的。在激活的輸入?yún)^(qū)中，用戶根據(jù)他所采取的活動，可以導航到有限個其它對話元素。因此，許多用戶界面可以用狀態(tài)轉(zhuǎn)換圖中的一種稱為對話圖來建模。對話圖描繪了系統(tǒng)中的對話元素和它們之間的導航連接，但它沒有揭示具體的屏幕設計。
類圖：面向?qū)ο蟮能浖_發(fā)優(yōu)于結(jié)構(gòu)化分析和設計，并且它運用于許多項目的設計中，從而產(chǎn)生了面向?qū)ο蠓治觥⒃O計和編程的域。類圖是用圖形方式敘述面向?qū)ο蠓治鏊_定的類以及它們之間的關系
4. 需求驗證
1）審查需求文檔：對需求文檔進行正式審查是保證軟件質(zhì)量的很有效的方法。組織一個由不同代表（如分析人員，客戶，設計人員，測試人員）組成的小組，對需求規(guī)格說明書及相關模型進行仔細的檢查。另外在需求開發(fā)期間所做的非正式評審也是有所裨益的。
2）依據(jù)需求編寫測試用例：根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測試用例?？蛻敉ㄟ^使用測試用例以確認是否達到了期望的要求。還要從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結(jié)果與測試用例相一致。同時，要使用測試用例來驗證需求模型的正確性，如對話框圖和原型等。
3）編寫用戶手冊：在需求開發(fā)早期即可起草一份用戶手冊，用它作為需求規(guī)格說明的參考并輔助需求分析。優(yōu)秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能。而輔助需求如質(zhì)量屬性、性能需求及對用戶不可見的功能則在需求規(guī)格說明書中予以說明。
4）確定合格的標準：確定合格的標準讓用戶描述什么樣的產(chǎn)品才算滿足他們的要求和適合他們使用的。將合格的測試建立在使用情景描述或使用實例的基礎之上。
二、需求管理
需求開發(fā)的結(jié)果應該有項目視圖和范圍文檔、使用實例文檔、軟件需求規(guī)格說明及相關分析模型。經(jīng)評審批準，這些文檔就定義了開發(fā)工作的需求基線。這個基線在客戶和開發(fā)人員之間就構(gòu)筑了計劃產(chǎn)品功能需求和非功能需求的一個約定。需求約定是需求開發(fā)和需求管理之間的橋梁，需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動。
1．確定需求變更控制過程，確定一個選擇、分析和決策需求變更的過程。所有的需求變更都需遵循此過程，商業(yè)化的問題跟蹤工具都能支持變更控制過程。
2．建立變更控制委員會，組織一個由項目風險承擔者組成的小組作為變更控制委員會，由他們來確定進行哪些需求變更，此變更是否在項目范圍內(nèi)，估價它們，并對此評估作出決策以確定選擇哪些，放棄哪些，并設置實現(xiàn)的優(yōu)先順序，制定目標版本。
3．進行需求變更影響分析，應評估每項選擇的需求變更，以確定它對項目計劃安排和其它需求的影響。明確與變更相關的任務并評估完成這些任務需要的工作量。通過這些分析將有助于變更控制委員會作出更好的決策。影響分析可以提供對建議的變更的準確理解，幫助做出信息量充分的變更批準決策。通過對變更內(nèi)容的檢驗，確定對現(xiàn)有的系統(tǒng)做出是修改或拋棄的決定，或者創(chuàng)建新系統(tǒng)以及評估每個任務的工作量。進行影響分析的能力依賴于跟蹤能力數(shù)據(jù)的質(zhì)量和完整性。
4．跟蹤所有受需求變更影響的工作產(chǎn)品當進行某項需求變更時，參照需求跟蹤能力矩陣找到相關的其它需求、設計模板、源代碼和測試用例，這些相關部分可能也需要修改。這樣能減少因疏忽而不得不變更產(chǎn)品的機會，這種變更在變更需求的情況下是必須進行的。
5．建立需求基準版本和需求控制版本文檔確定一個需求基準，這是一致性需求在特定時刻的快照。之后的需求變更就遵循變更控制過程即可。每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。最好的辦法是使用合適的配置管理工具在版本控制下為需求文檔定位。
6．維護需求變更的歷史記錄記錄變