需求分析與建模
需求分析與建模
需求分析的?的
需求分析就是選擇?種業務導向的線索將零散的需求串起來，形成?個體系完整、內容清晰的框架，以指導后續的設計和開發?作。
要避免的誤區：需求分析的任務不是分析系統如何實現?戶的需要。
需求分析做的是什么？
需求分析就是先分解，再提煉，在這個過程中消除?盾。
這?值得?提的是，分解這個過程，其注意事項如下。
分解是?種?頂向下的?法，按任何?種線索進?分解時，就會破壞其他線索的完整性。例如，如果以“事”為線索，分解后就會出現相互交疊的情況，也就在多個事件中都涉及相同的類。
分解結構的?種?式如下：
（1）以業務流程為主線索的分解結構
（2）以程序結構為主線索的分解結構
（3）基于場景的分解結構
（4）基于數據的分解結構
什么是需求建模？
需求建模就是采??字、圖形化、表格化、公式化的?式，按照系統需求情況對系統進?可視化描述，提供?種詳細說明系統的結構或?為的?法。
需求建模的?的
幫助我們按照實際情況或按我們需要的樣式對系統進?可視化，提供?種詳細說明系統的結構或?為的?法；給出有個指導系統構造的模板，對我們所作出的決策進?浪費。
建模的要點與原則
模型是?來溝通的，僅當需要時才構建它。
在建模時遵循以下原則：
（1）選擇創建什么模型對如何動?解決問題和如何形成解決?案之間有著必然的聯系。
（2）模型也有精度。
（3）每個系統最好使?獨?的模型處理。
選擇使?UML建模的原因是什么？
UML是統?建模語?（UnifiedModelingLanguage）的縮寫，它發表于1997年，是?個?持模型化和軟件系統開發的圖形化語?，為軟件開發的所有階段提供模型化和可視化?持。使?UML可以幫助溝通與交流，輔助應?設計和?檔的?成，還能夠闡釋系統的結構和?為。UML定義了多種圖形化的符號來描述軟件系統部分或全部的靜態結構和動態結構。
可選擇的UML圖有哪些？
截?UML2.0?共有13種圖形（UML1.5定義了9種，2.0增加了4種）。分別是：?例圖、類圖、對象圖、狀態圖、活動圖、順序圖、協作圖、構件圖、部署圖9種，包圖、組合結構圖、交互概覽圖3種。
?例圖：從?戶?度描述系統功能。
類圖：描述系統中類的靜態結構。
對象圖：系統中的多個對象在某?時刻的狀態。
狀態圖：是描述狀態到狀態控制流，常?于動態特性建模
活動圖：描述了業務實現?例的?作流程
順序圖：對象之間的動態合作關系，強調對象發送消息的順序，同時顯?對象之間的交互
協作圖：描述對象之間的協助關系
構件圖：?種特殊的UML圖來描述系統的靜態實現視圖
部署圖：定義系統中軟硬件的物理體系結構
包圖：對構成系統的模型元素進?分組整理的圖
組合結構圖：表?類或者構建內部結構的圖
交互概覽圖：?活動圖來表?多個交互之間的控制關系的圖
建模前需理清框架和脈絡
在這個階段，需要理清需求的結構框架（領域類圖）和?為脈絡（流程圖和?例圖），該?作的輸?是需求定義階段產?的業務事件列表和報表列表，輸出的是領域模型和?例模型，對應于RUP中細化階段的第?次迭代。【RUP（Rational Unified Process），統?軟件開發過程，統?軟件過程是?個?向對象且基于?絡的程序開發?法論。】
該階段的?的就是標識出絕?部分的?例，?成領域模型。
確定需求細節
這個階段的任務就是對?例模型、領域模型標識出?例、領域類的細節進?填充。
對于組織?為需求的?例，我們要填充?例的事件流；
對于組織數據（結構）需求的領域類，我們要填充它的字段與格式。
對于組織?為需求的?例，要細化的東西主要包括事件流、相關需求與功能點、界?原型，以及特定于該?例的規則與約束。
需求=?為需求+結構需求+接?需求。
其中，?為需求與結構需求是核?部分，接?需求是輔助需求。
什么是接?需求？
那?有分解，那?就有接?。這?接?指的是兩個獨?系統之間同步數據或訪問對?程序的途徑。所謂接?需求，就是指滿??戶需要，在系統之間或者模塊之間訪問?式。每次主題域劃分就應該思考主題域之間有什么樣的服務接?，每次將主題域劃分成不同的業務事件。
建議
第?，建模時要善于、敢于拋棄細節，不要過早地專研到業務活動的具體步驟中，這樣可能會導致流程圖的規模被擴?，破壞?標。
第?，拋棄?次成型的思路，不要精雕細琢，?是出草圖、談問題、修正草稿、再討論、在修正，…，最終達成共識。
