?? 需求工程——如何進行軟件需求分析.htm
字號:
<TABLE cellSpacing=0 cellPadding=0 width=780 align=center border=0>
<TBODY>
<TR>
<TD vAlign=top>
<TABLE cellSpacing=0 cellPadding=0 width="95%" align=center border=0>
<TBODY>
<TR>
<TD vAlign=bottom height=40>
<DIV align=center><B>如何進行軟件需求分析</B>
<HR width="80%" noShade SIZE=1>
</DIV></TD></TR>
<TR>
<TD class=hui vAlign=top height=20>
<DIV class=hui24 align=center>51CMM.COM原創 作者：曹偉</DIV></TD></TR>
<TR>
<TD class=hui14 background="">
<CENTER><B>1．概念</B></CENTER> 需求的定義包括從用戶角度（系統的外部行為），以及從開發者角度（一些內部特性）來闡述需求。<BR> 關鍵的問題是一定要編寫需求文檔。我曾經目睹過一個項目中途更換了所有的開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說：“我們想與你談談你的需求。”客戶的第一反應便是：“我已經將我的要求都告訴你們前任了，現在我要的就是給我編一個系統”。而實際上，需求并未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。<BR> 需求的另外一種定義認為需求是“用戶所需要的并能觸發一個程序或系統開發工作的說明”。有些需求分析專家拓展了這個概念：“從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等”。這些定義強調的是產品是什么樣的，而并非產品是怎樣設計、構造的。而下面的定義則從用戶需要進一步轉移到了系統特性：<BR>需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。<BR> 從上面這些不同形式的定義不難發現：并沒有一個清晰、毫無二義性的“需求”術語存在，真正的“需求”實際上在人們的腦海中，這個人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對。系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識。<BR>任何文檔形式的需求（例如如下將要描述的需求規格說明書）僅是一個模型，一種描述。<BR>
<CENTER><B>2．需求分析的任務</B></CENTER>開發軟件系統最為困難的部分就是準確說明開發什么。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統的接口。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，并且以后再對它進行修改也極為困難。<BR>目前，國內產品的龐雜，一家企業可能有幾個系統并立運行，它們之間接口是系統開發人員最頭痛的問題。<BR>對于商業最終用戶應用程序，企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的。但是對于我們開發人員來說，并沒有編寫出客戶認可的需求文檔，我們如何知道項目于何時結束？而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？<BR> 然而，即便并非出于商業目的的軟件需求也是必須的。例如庫、組件和工具這些供開發小組內部使用的軟件。當然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現重復返工這種不可避免的后果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國內的軟件開發者身上發生。<BR> 近來，我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件。不幸的是，當他們開發完這個工具后，發現這個工具不能打印出源代碼文件，使用者當然希望有這個功能。結果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構思準確，如果我們沒有編寫文檔，軟件達不到期望目標也只能是咎由自取了。<BR> 相反的情況，我曾見一個要集成到“錯誤跟蹤系統”中的簡單界面寫了一頁需求說明。而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用。他們依據需求對系統進行測試時，此系統不僅非常清晰地實現了所有必需功能，而且未發現任何錯誤。<BR> 事實上，需求文檔在開發過程中一直起指導作用。<BR>
<CENTER><B>3．需求分析過程</B></CENTER> 可把整個軟件需求工程研究領域劃分為需求開發和需求管理兩部分更合適，如圖4-1所示：<BR> <IMG
height=196 src="需求工程——如何進行軟件需求分析.files/No0201.jpg" width=515>圖4-1
需求工程域的層次分解示意圖<BR> 需求開發可進一步分為：問題獲取、分析、編寫規格說明和驗證四個階段。這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動。需求開發活動包括以下幾個方面：<BR>
確定產品所期望的用戶類別。<BR>
獲取每個用戶類的需求。<BR>
了解實際用戶任務和目標以及這些任務所支持的業務需求。<BR>
分析源于用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息。<BR>
將系統級的需求分為幾個子系統，并將需求中的一部份分配給軟件組件。<BR>
了解相關質量屬性的重要性。<BR>
商討實施優先級的劃分。<BR>
將所收集的用戶需求編寫成文檔和模型。<BR>
評審需求規格說明，確保對用戶需求達到共同的理解與認識，并在整個開發小組接受說明之前將問題都弄清楚。<BR> 需求管理需要“建立并維護在軟件工程中同客戶達成的合同”
。這種合同都包含在編寫的需求文檔與模型中。客戶的接受僅是需求成功的一半，開發人員也必須能夠接受他們，并真正把需求應用到產品中。通常的需求管理活動包括：<BR>
定義需求基線（迅速制定需求文檔的主體）。<BR>
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。<BR>
以一種可控制的方式將需求變更融入到項目中。<BR>
使當前的項目計劃與需求一致。<BR>
估計變更需求所產生影響并在此基礎上協商新的承諾，這種承諾具體體現在項目解決方案上。<BR>
讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤。<BR>
在整個項目過程中跟蹤需求狀態及其變更情況。<BR>以上幾點說明是我總結了成功實施項目后系統分析人員的經驗，同時也根據國內外的其他系統實施的相關成功經驗，進行了總結。<BR>
<CENTER><B>4．需求的類型</B></CENTER> 下面這些定義是需求工程領域中常見術語的定義。<BR> 軟件需求包括三個不同的層次：業務需求、用戶需求和功能需求（也包括非功能需求）。<BR> 1．業務需求（business
requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。<BR> 2．用戶需求(user
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -