需求分析與定義 |
|
1. 軟件需求： 軟件需求分為三大部分： 1)、功能需求：指系統需要完成那些事情，即向用戶(hù)提供那些功能。 2)、非功能需求：指產(chǎn)品所具備的品質(zhì)和屬性，比如可靠性、擴展性、響應時(shí)間、性能等等。。。 3)、設計約束：也稱(chēng)條件約束、補充規則。比如用戶(hù)要安裝該產(chǎn)品他需要有什么樣的必備條件。（系統對操作系統的要求、硬件環(huán)境的要求等等…..）
在做需求調查時(shí)需要做到兩W一H即 What、Where、How 1)、What-----應該收集什么信息 2)、Where----從什么地方收集 3)、How-------用什么機制或技術(shù)來(lái)收集
需求分析通常包括六個(gè)方面： 1)、繪制系統上下文范圍關(guān)系圖：主要用于定義系統與系統外部實(shí)體間的界限和接口的簡(jiǎn)單模型，他可以為需求確定一個(gè)范圍。其實(shí)就是DFD的0層圖。 2)、創(chuàng )建用戶(hù)接口原型：這里我們可以把他看成是用戶(hù)操作的一個(gè)雛形，什么意思呢就是我們通常所說(shuō)的界面用戶(hù)通過(guò)一系列的操作完成他想達到的效果的接口。 3)、分析需求的可行性：這個(gè)需求我們應該用什么技術(shù)解決，他實(shí)現后的性能怎么樣，是否與其他需求相重合或是矛盾，這里一定要注意不要把系統的這個(gè)需求怎么用代碼實(shí)現想進(jìn)去。在需求分析時(shí)應多注意需求本身是否有用不必考慮怎么實(shí)現。 4)、確定需求的優(yōu)先級：可采用滿(mǎn)意度/不滿(mǎn)意度指標來(lái)說(shuō)明（滿(mǎn)意度1-5 表示當需求被實(shí)現時(shí)用戶(hù)的滿(mǎn)意程度；不滿(mǎn)意度取值同理） 5)、為需求建立模型：這里可以用UML創(chuàng )建用例圖或是E-R圖再加上少量的文字描述。 6)、使用質(zhì)量功能調配（QFD）：這里我的理解是分析員根據需求的理解發(fā)現隱藏需求而這些需求是用戶(hù)也沒(méi)有想到的需求，系統實(shí)現后會(huì )給用戶(hù)一個(gè)驚喜，而沒(méi)實(shí)現用戶(hù)也不會(huì )有抱怨。
現在比較流行的軟件需求分析方法有4種，其中3種理論比較成熟。 1)、結構化分析方法（Struetured Analysis,SA）：這個(gè)大家想必很熟悉了不在復述。 2)、軟系統方法：這只是過(guò)度性的方法論他的出現只是證明結構化分析方法的一些不足。因為結構化分析方法采用的相對形式化的模型不僅與社會(huì )觀(guān)格格不入，而且在解決“不確定性”時(shí)顯得十分無(wú)力。 3)、面向對象分析方法（Object Oriented Analysis，OOA）：這也是我下文想講的分析方法 4)、面向問(wèn)題域的分析（Problem Domain Oriented Analysis,PDOA）：OOA也存在著(zhù)很多不足，但PDOA現在正在研究中所以未被廣泛應用。這里需要注意的是：在軟件開(kāi)發(fā)中有很多需求分析方法他們沒(méi)有好壞之分只要你運用得當照樣可以做出一個(gè)很好的系統，依據個(gè)人對某個(gè)方法的理解用自己最擅長(cháng)的方法是最明智的選擇。
面向對象這個(gè)概念很簡(jiǎn)單但也很復雜我在這里不做深入探討。我將從實(shí)際出發(fā)來(lái)和大家一起探討下在實(shí)際開(kāi)發(fā)中我們應該怎么做。 OOA的精髓在于世間萬(wàn)物均為對象采用OOA方法在整個(gè)過(guò)程中包括2個(gè)工作任務(wù)：建立一個(gè)反應問(wèn)題域靜態(tài)關(guān)系的概念模型，就是我們通常所說(shuō)的類(lèi)圖；另一個(gè)反應系統行為的動(dòng)態(tài)模型，即用例模型那么我們在實(shí)際開(kāi)發(fā)中到底怎么做呢？ 1）建立域模型 尋找類(lèi)：在尋找類(lèi)時(shí)有多種方法典型的是根據需求文檔用“名詞動(dòng)詞法”來(lái)尋找，找出備選類(lèi)后再從中尋找出真正的類(lèi)。（注意在用此方法時(shí)切記不要咬文嚼字專(zhuān)牛角尖在這里花費很長(cháng)的時(shí)間） 確定類(lèi)之間的關(guān)聯(lián)：這個(gè)過(guò)程是迭代的我們需要理清楚這些類(lèi)之間的關(guān)系如關(guān)聯(lián)、繼承、聚合等然后通過(guò)UML記錄下來(lái)。類(lèi)之間的關(guān)系不是一下子就能確定下來(lái)的是要慢慢完善的為類(lèi)添加職責：這里就可以理解成為類(lèi)添加所需要的屬性和方法。 域模型的詳細度：這里不做太多要求可以寫(xiě)的很詳細也可以寫(xiě)的簡(jiǎn)單寫(xiě)，可以把握好一個(gè)原則：只要能有利于團隊更好的開(kāi)發(fā)就是好模型。 2）建立用例模型 什么是用例： 用例實(shí)例是在系統中執行的一系列動(dòng)作，這些動(dòng)作將生成對特定參與者可見(jiàn)的價(jià)值結果。（用例實(shí)例就是常說(shuō)的“使用場(chǎng)景“）一個(gè)用例定義一組用例實(shí)例。 識別參與者： 用例主要是為了讓客戶(hù)直觀(guān)的理解需求那么這里參與者是必不可少的這樣才能形象的勾畫(huà)出系統某個(gè)特定場(chǎng)景下的流程。 注意參與者不僅可以是人也可以是其他的事物如（其他系統、硬件設備、時(shí)鐘等等） 合并需求獲得的用例 繪制用例圖（如果對用例圖不清楚請參考UML相關(guān)文章） 細化用例描述 用例描述可以包括以下幾個(gè)部分： 用例名稱(chēng) 事件流：是該用例要完成的工作步驟 非功能需求 前置條件 后置條件 擴展點(diǎn) 優(yōu)先級別 3）要想做好需求分析光上面的用例是不夠的還有寫(xiě)建模技術(shù)也要有如：協(xié)作圖、順序圖和狀態(tài)圖 協(xié)作圖：是一種用以顯示對象如何被協(xié)調在一起執行用例的圖，用來(lái)識別協(xié)作完成給定業(yè)務(wù)的對象。 順序圖：是一種用以顯示用例對象之間消息順序的圖，他與協(xié)作圖表達的信息是一樣的知識顯示的方式有差別。 順序圖以圖形化的方式強調消息的順序，而非協(xié)作對象間的順序。他和協(xié)作圖統稱(chēng)為交互圖。 狀態(tài)圖：是一種用以顯示對象在生命周期和轉換期情況的圖 |
聯(lián)系客服
