需求分析與定義(軟件工程)

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

要想前面理解OOA思想UML是最好的幫助這裏我只是簡單的談了一下。



Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=576756

 

 

 

 

 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章