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