軟件工程模型與方法-軟件需求分析

?2009

BUPTTSEG軟件工程模型與方法

Models&MethodsofSoftwareEngineering第四章軟件需求分析

通信軟件工程中心本章內容4.1什么是軟件的需求4.2軟件需求分析的目標和任務4.3軟件需求分析建模的原則和方法4.4軟件需求工程4.5軟件需求分析過程

通信軟件工程中心本章目標為何要進行軟件的需求分析？軟件的需求分析處于軟件生命周期的那個階段？起到什么作用？怎樣才能做好軟件需求分析？軟件需求分析的過程和步驟是什么？軟件需求分析的最終結果是什么？

通信軟件工程中心4.1什么是軟件的需求4.1.1需求的定義4.1.2需求分析失敗案例

通信軟件工程中心4.1.1需求的定義需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什么。Boehm給出軟件需求的定義：研究一種無二義性的表達工具，它能為用戶和軟件人員雙方都接受，并能夠把“需求”嚴格地、形式地表達出來?！靶枨?、設計、編程、測試四者究竟哪個環(huán)節(jié)最重要？”首先，每個環(huán)節(jié)都是很重要，任何一個環(huán)節(jié)出現問題，都會導致軟件的質量問題。但是，從風險管理的角度來看，需求是軟件產品的起源，因而是最重要的一個環(huán)節(jié)。

通信軟件工程中心4.1.2需求分析失敗案例某大型的電信設備供應商，案例中涉及6個部門A,B,C,D,E和F，它們之間的關系如下圖所示：F客戶E：網管軟件承包商D銷售機構A：增值業(yè)務研發(fā)機構C：項目管理機構B：核心平臺研發(fā)機構一年前，B研制了一種數據接入服務器的原型。B對A講：“我們的接入服務器前途很好，請你們幫助開發(fā)網管軟件（屬于增值業(yè)務范疇），大家合作把產品做好，一起發(fā)財。”D對B和A講：“你們把接入服務器和網管軟件做好，我們負責賣，掙了錢大家一起分?！?/p>

通信軟件工程中心4.1.2需求分析失敗案例A覺得機會難得，于是向C申請立項。立項后，A把項目外包給專業(yè)做網管軟件的公司E，期望半年內完成。由于接入服務器是B的，于是A和E就派開發(fā)人員到B處搞需求分析。B的接入服務器并不成熟，老在變，三方折騰了好久，最終E用了一年時間把接入服務器的網管軟件做出來了。

E把網管軟件交付給A，A付清了E的開發(fā)費用，再把網管軟件交付給D，D再賣給客戶F（某地電信局）。F對D講：“你們的網管軟件不是我們想要的東西，等你們把軟件改好后我們再付錢?！盌趕緊對A講：“兄弟阿，貨已經出手了，但是不對路，請趕緊把它改好，不然大家都沒錢賺?！盇很憤怒，怨天不公：“我們辛苦了一年，又花了很多錢，可是產品做完了卻沒人要，豈有此理！”

通信軟件工程中心4.1.2需求分析失敗案例禍不單行的是，C來找A的麻煩：“你們的項目延期半年多了，經費也用光了，請盡快結束項目?！盇的那位項目經理為此每天愁眉苦臉，他的上司請來幾位參謀商量對策，設法把事情搞定。大家挖空心思只想出一個餿主意：既然套子是B下的，那么就把套子還給B。要設法把“那么好”的網管產品轉讓給B，只要B能給我們成本費，以后就跟B拜拜。這個案例的問題根源在于進行軟件開發(fā)之前沒有搞清楚網管軟件的需求，這都是B,A,E閉門造車惹的禍。最可悲的是，相關責任人關心的是如何把事情“完成”，而不是深刻了解用戶的具體需求。這種類似的事情在軟件開發(fā)行業(yè)中經常發(fā)生而且還會繼續(xù)發(fā)生，最主要的是每發(fā)生一次就損失大量的人力和物力。

通信軟件工程中心4.2軟件需求分析的目標和任務需求分析是一項必須的軟件工程活動。它在系統(tǒng)需求分析和軟件設計之間起到橋梁的作用：它使得軟件開發(fā)人員在系統(tǒng)分析的基礎上深入描述軟件的功能和性能、指明軟件和其他系統(tǒng)元素的接口，建立軟件必須滿足的約束條件。它允許軟件開發(fā)人員對關鍵問題進行細化，并構建相應的分析模型：數據、功能和行為模型。分析模型成為設計模型的基礎，需求規(guī)格說明書也為軟件測試人員和用戶提供了軟件質量評估的依據。它能準確表達用戶對系統(tǒng)的各項要求。

通信軟件工程中心4.2軟件需求分析的目標和任務軟件需求分析的對象是用戶要求。其任務是要準確地定義新系統(tǒng)的目標。回答系統(tǒng)必須“做什么”的問題并編制需求規(guī)格說明書。作為目標系統(tǒng)的參考，需求分析的任務就是借助于（業(yè)務）系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)的“做什么”的問題。軟件開發(fā)的目標需求分析的目標

通信軟件工程中心4.2軟件需求分析的目標和任務（1）獲得當前系統(tǒng)的物理模型：分析、理解當前系統(tǒng)（人工處理或原計算機系統(tǒng)）是如何運行的，了解其組織機構、輸入輸出、資源利用情況和日常數據處理過程。（2）抽象出當前系統(tǒng)的邏輯模型：在理解當前系統(tǒng)“怎樣做”的基礎上，抽取其“做什么”的本質。（3）建立目標系統(tǒng)的邏輯模型：分析目標系統(tǒng)與當前系統(tǒng)邏輯上的差別，明確目標系統(tǒng)到底要“做什么”，進而從當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型。（4）對邏輯模型的補充：包括說明目標系統(tǒng)的用戶界面、系統(tǒng)細節(jié)和性能限制等。

通信軟件工程中心4.3需求分析建模的原則和方法4.3.1數據建模4.3.2功能和行為建模4.3.3問題劃分

通信軟件工程中心需求分析的三元模型需求分析方法的一組操作性原則是：問題的信息域必須被表示和理解。軟件將完成的功能必須被定義。軟件的行為（作為外部事件的結果）必須被表示。描述信息、功能和行為的模型必須被劃分，使得可以用層次的方式揭示細節(jié)。分析過程應該遵從自頂向下，逐層細化的原則。需求分析的三元模型：數據模型——第1條原則功能模型——第2條原則行為模型——第3條原則

通信軟件工程中心需求工程的指導性原則首先要正確地理解問題，再建立分析模型。記錄每個需求的起源及原因，保證需求的可回溯性。開發(fā)一個能使用戶能夠了解人機交互過程的原型。因為對軟件質量的感覺經常基于對界面“友好性”的感覺。使用多個需求視圖。建立數據模型、功能模型和行為模型，為軟件工程師提供三種不同的視圖，增加識別不一致性的基礎。給需求賦予優(yōu)先級。緊張的開發(fā)時間要求盡量避免一次性實現每個軟件需求，應采用迭代增量的開發(fā)模型。努力刪除歧義性。因為大多數需求以自然語言描述，存在歧義性的可能性，正式的技術評審是發(fā)現并刪除歧義性的一種有效方法。

通信軟件工程中心4.3.1數據建模信息域包含三個不同的數據和控制視圖：信息內容和關系；信息流；信息結構。信息流表示了數據和控制在系統(tǒng)中流動時變化的方式信息內容表示了個體數據和控制對象；數據和控制對象可和其他的數據和控制對象關聯信息結構表示了各種數據和控制項的內部組織

通信軟件工程中心4.3.2功能和行為建模功能模型：對進入軟件的信息和數據進行變換和處理的模塊，它必須至少完成三個常見功能：輸入、處理和輸出。行為模型：大多數軟件對來自外界的事件做出反應，這種刺激／反應特征形成了行為模型的基礎。行為模型創(chuàng)建了軟件狀態(tài)的表示，以及導致軟件狀態(tài)變化的事件的表示。功能模型和行為模型的作用如下：模型能夠幫助軟件開發(fā)人員快速準確的理解系統(tǒng)所涉及的信息、功能和動態(tài)行為；模型可成為后期軟件設計的基礎，為軟件設計人員提供了設計軟件功能的視圖化表示；模型能夠成為軟件測試和軟件評審的重要依據

通信軟件工程中心4.3.3問題劃分需求問題域涉及面廣泛而且復雜，以至于難以進行整體理解。為此，需要將這樣的問題劃分為易于理解的子問題，并建立各子問題間的關系以使得可以完成整個功能。軟件的信息、功能和行為域可以被劃分。在本質上，劃分將問題分解為其構成成分。在概念上，建立信息或功能的層次結構表示，通過進行自頂向下的分析，進而暴露更多的細節(jié)問題，并在各層次上進行各功能元素的分配。

通信軟件工程中心4.4軟件需求工程軟件的需求分析是一系列復雜的軟件工程活動，為了便于對需求進行更好的管理，人們把所有與需求直接相關的活動通稱為需求工程。需求工程需求開發(fā)需求變更控制需求管理需求確認需求跟蹤需求獲取需求分析需求定義用戶需求說明書軟件需求規(guī)格說明書需求跟蹤矩陣

需求評審報告

需求變更控制報告

通信軟件工程中心4.5軟件需求分析過程4.5.1軟件需求獲取的對象及注意事項4.5.2需求獲取4.5.3需求類別4.5.4需求分析與綜合4.5.5需求建模4.5.6編制需求分析文檔4.5.7需求確認4.5.8需求分析評審

通信軟件工程中心4.5.1軟件需求獲取的對象及注意事項需求獲取的對象：用戶“用戶”（user）是一種泛稱，它可細分為：“客戶”（Customer）：掏錢買軟件的用戶“最終用戶”（Enduser）：真正操作軟件的用戶“間接用戶”（或稱為關系人）如果軟件是面向企業(yè)用戶的，那么客戶與最終用戶通常不是同一個人。如果軟件是面向個人用戶的，那么客戶與最終用戶通常是同一個人。

通信軟件工程中心軟件需求獲取的注意事項用戶無法清晰地表達需求本身不清楚要做什么知道做什么卻表達不準確需求分析員的職責就是設法搞清楚用戶真正的需求。雙方或多方對需求的理解往往存在歧義需求會經常發(fā)生變化：避免由于溝通不充分而發(fā)生的變更；歡迎因環(huán)境變化造成的變更；需求變更并不可怕，可怕的是需求變更失去控制，導致項目混亂。

通信軟件工程中心4.5.2需求獲取目的獲取用戶（客戶與最終用戶）的需求信息，經過分析后產生《用戶需求說明書》。角色與職責需求分析員調查、分析用戶的需求，客戶與最終用戶提供必要的需求信息。啟動準則需求分析員已經確定輸入任何與用戶需求相關的材料主要步驟第一步：準備調查第二步：調查與記錄第三步：分析需求信息第四步：撰寫《用戶需求說明書》第五步：需求確認輸出《用戶需求說明書》結束準則需求分析員已經撰寫完成《用戶需求說明書》，確保無拼寫、排版等錯誤。并確?！队脩粜枨笳f明書》的內容無二義性，且涵蓋了所有的用戶需求。度量需求分析員統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經理。需求獲取流程：

通信軟件工程中心需求獲取的準備工作需求獲取的準備工作圍繞三項展開：調查什么？通過什么方式去調查？“何人”在“何時”調查？首先，應起草需求調查問題表，將重點鎖定在該問題表內，否則調查工作將變得漫無邊際。其次，應當確定需求調查的方式，比如：與用戶交談，向用戶提問題。參觀用戶的工作流程，觀察用戶的操作。向用戶群體發(fā)調查問卷。與同行、專家交談，聽取他們的意見。

通信軟件工程中心需求獲取的記錄準備工作完畢后，需求分析員按照計劃執(zhí)行調查。在調查過程中隨時記錄（或存儲）需求信息，建議采用表格的形式，如下圖：需求標題1調查方式調查人調查對象時間、地點需求信息記錄基本要素如“是什么”、“為什么”等

通信軟件工程中心需求獲取注意事項如果與用戶約好了時間，切勿遲到或早退。要注意禮節(jié)，盡可能獲得用戶的好感，并為下次打擾他們埋下伏筆。需求分析員應事先了解用戶的身份、背景，以便隨機應變。需求調查應該先了解宏觀問題，再了解細節(jié)問題。如果雙方氣氛融洽，可以采用靈活的訪談形式，輕易不要打斷用戶的談話。當雙方對某些問題的交流合乎邏輯地結束后，即可繼續(xù)討論問題表中的其它問題。盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調查的力度。避免片面地聽取某些用戶的需求而忽視其它用戶的需求。

通信軟件工程中心撰寫用戶需求說明書對收集到的所有需求信息進行分析，消除錯誤，歸納與總結共性的用戶需求。按照規(guī)定的文檔模板撰寫《用戶需求說明書》，調查過程中獲取的需求信息可以作為《用戶需求說明書》的附件。之后應當邀請同行專家和用戶一起評審《用戶需求說明書》，盡最大努力使《用戶需求說明書》能夠正確無誤地反映用戶的真實意愿。

通信軟件工程中心用戶需求說明書與

軟件需求規(guī)格說明書的區(qū)別前者主要采用自然語言來表達用戶需求，其內容相對于后者而言比較粗略，不夠詳細。后者是前者的細化，更多地采用計算機語言和圖形符號來刻畫需求，軟件需求是軟件系統(tǒng)設計的直接依據。兩者之間可能并不存在一一映射關系，因為軟件開發(fā)商會根據產品發(fā)展戰(zhàn)略、企業(yè)當前狀況適當地調整軟件需求，例如用戶需求可能被分配到軟件的數個版本中。軟件開發(fā)人員應當依據《軟件需求規(guī)格說明書》來開發(fā)當前產品。

通信軟件工程中心4.5.3需求類別功能需求：列舉出所開發(fā)軟件在功能上應做什么，這是最主要的需求。性能需求：給出所開發(fā)軟件的技術性能指標，尤其是系統(tǒng)的實時性和其他時間要求，如響應時間、處理時間、消息傳送時間等；資源配置要求，精確度，數據處理量等要求。環(huán)境需求：是對軟件系統(tǒng)運行時所處環(huán)境的要求。在硬件方面，采用什么機型、有什么外部設備、數據通信接口等等。在軟件方面，采用什么支持系統(tǒng)運行的系統(tǒng)軟件（指操作系統(tǒng)、網絡軟件、數據庫管理系統(tǒng)等）。在使用方面，需要使用部門在制度上、操作人員的技術水平上應具備什么樣的條件等等。

通信軟件工程中心4.5.3需求類別可靠性需求：指軟件的有效性和數據完整性。各種軟件在運行時失效的影響各不相同。在需求分析時，應對所開發(fā)軟件在投入運行后不發(fā)生故障的概率，按實際的運行環(huán)境提出要求。安全保密要求：工作在不同環(huán)境的軟件對其安全、保密的要求顯然是不同的，應當把這方面的需求恰當地做出規(guī)定。用戶界面需求：軟件與用戶界面的友好性是用戶能夠方便有效愉快地使用該軟件的關鍵之一。

通信軟件工程中心4.5.3需求類別資源使用需求：指所開發(fā)軟件運行時所需的數據、軟件、內存空間等各項資源，以及軟件開發(fā)時所需的人力、支撐軟件、開發(fā)設備等。軟件成本消耗與開發(fā)進度需求：在軟件項目立項后，要根據合同規(guī)定，對軟件開發(fā)的進度和各步驟的費用提出要求，作為開發(fā)管理的依據。預先估計以后系統(tǒng)可能達到的目標：在開發(fā)過程中，可對系統(tǒng)將來可能的擴充與修改做準備。一旦需要時，就比較容易進行補充和修改。

通信軟件工程中心非功能性需求列表目標系統(tǒng)的限制性能實時性其他的時間限制資源利用，特別是硬件配置選型精確度、質量要求可靠性有效性完整性安全/保密性安全性保密性運行限制使用頻度、運行期限控制方式（本地還是遠程）對使用者的要求物理限制系統(tǒng)的規(guī)模等限制開發(fā)和維護的限制開發(fā)類型（實用型開發(fā)或試驗型開發(fā)）開發(fā)工作量估計；在采用具有試驗型的漸進開發(fā)方法時，對資源、開發(fā)時間及交付的安排開發(fā)方法質量控制標準里程碑和評審驗收標準優(yōu)先性和可維修性可維護性

通信軟件工程中心4.5.4需求分析與綜合需求獲取之后就需要對比較復雜的需求進行建模分析，進而逐步細化所有的軟件功能，找出系統(tǒng)各元素之間的聯系、接口特性和設計上的限制，分析它們是否滿足功能要求，是否合理。依據功能需求，性能需求，運行環(huán)境需求等，剔除其不合理的部分，增加其需要部分。最終綜合成系統(tǒng)的解決方案，給出目標系統(tǒng)的詳細邏輯模型。分析和綜合工作需要反復地進行，其過程將一直持續(xù)到分析員與用戶雙方都感到有把握正確地制定該軟件的需求規(guī)格說明為止。

通信軟件工程中心4.5.4需求分析與綜合需求分析的流程：目的定義準確無誤的軟件產品需求，產生《軟件需求規(guī)格說明書》。角色與職責需求分析員定義軟件需求。客戶與最終用戶確認軟件需求。啟動準則《用戶需求說明書》已經撰寫完成。輸入《用戶需求說明書》主要步驟第一步：細化并分析用戶需求第二步：撰寫軟件需求規(guī)格說明書第三步：軟件需求確認輸出《軟件需求規(guī)格說明書》結束準則《軟件需求規(guī)格說明書》已經撰寫完成。開發(fā)方和客戶方已經對產品需求進行了確認。度量需求分析員統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經理。

通信軟件工程中心4.5.5需求建模軟件開發(fā)人員還需要構造系統(tǒng)的分析模型，著重于描述系統(tǒng)必須做什么、而不是如何去做系統(tǒng)。給出系統(tǒng)的邏輯視圖，以及系統(tǒng)的物理視圖。邏輯模型給出軟件要達到的功能和處理數據之間的關系，而不是實現的細節(jié)。物理模型給出處理功能和數據結構的實際表示形式，這往往是由設備決定的。常用的建模分析方法有：面向數據流的結構化分析方法（簡稱SA）面向數據結構的Jackson方法（簡稱JSD）面向對象的分析方法（簡稱OOA）等以及用于建立動態(tài)模型的狀態(tài)遷移圖或Petri網等

通信軟件工程中心4.5.6編制需求分析文檔把描述需求的文檔稱為軟件需求規(guī)格說明書。為了確切表達用戶對軟件的輸入輸出要求，還需制定數據詞典及初步的用戶手冊，反映軟件的用戶界面和用戶使用的具體要求。從現實中分離功能，即描述要“做什么”而不是“怎樣實現”；要求使用面向處理的規(guī)格說明語言，從而得到“做什么”的規(guī)格說明。如果被開發(fā)軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中；規(guī)格說明必須包括系統(tǒng)運行環(huán)境，等；

通信軟件工程中心軟件需求規(guī)格說明書的特點正確性：不僅要正確書寫，最主要的是正確地表達用戶的需求。清晰性：需求地表達是否清晰易懂？文檔的結構、段落是否亂七八糟？上下文是否不連貫？文檔的