第3章結構化分析本章要點可行性研究獲取需求的方法結構化分析過程快速原型分析方法成本/效益分析可行性研究開發軟件需要解決的問題：Whytodo?—可行性研究Whattodo?—需求分析Howtodo?—系統設計可行性研究是以預測為提前，以投資效果為目的，從技術上、經濟上、管理上進行全面分析研究的方法。問題定義問題定義是軟件工程過程中最簡短的階段，是一個項目的開始。問題定義階段必須回答的關鍵問題是“要解決的問題是什么”。規范的問題定義：思想上重視客觀全面地定義嚴格評審深入分析可行性研究的內容回答是否可行最短時間最小代價四個方面的可行性技術可行性（預期功能、質量、效率）經濟可行性（性價比-成本效益短長期效益）社會可行性（市場與政策）人的可行性可行性研究過程接受委托書組建研究小組事前調查編制研究計劃簽訂合同或協議正式調查分析研究優化和選擇方案可行性研究報告主要內容引言可行性研究前提對現有系統的分析對所建議系統的技術可行性分析對所建議系統的經濟可行性分析社會因素可行性分析其他可供選擇的方案結論意見7循環可行性研究的步驟復查系統規模和目標研究現有系統功能導出新系統模型重新定義問題導出和分析各種可選解決方案推薦行動方針草擬開發計劃書寫文檔提交審查81復查系統規模和目標問題定義階段的成果系統規模和目標報告書復查任務改正含糊的、二義的描述改正不正確的描述核查系統限制和約束92研究現有系統功能分析現有系統高層系統流程圖確定系統功能比較新舊系統新系統必須完成舊系統的基本功能新系統必須改正舊系統存在問題新系統必須比舊系統增收入、減支出103導出新系統模型舊系統邏輯模型新系統目標和規模邏輯模型描述工具數據流圖數據字典用例圖新系統邏輯模型114重新定義問題復查問題定義、規模和目標根據新系統模型分析員誤解用戶遺漏重新定義問題循環（定義，分析，求解，重定義）125導出和分析可選解決方案從邏輯模型導出物理系統方案不同角度多個方案分析各種可選方案技術可行性操作可行性經濟可行性為可行方案制定初步進度計劃136推薦行動方針得出可行性研究結果繼續開發終止項目推薦解決方案成本/效益147草擬開發計劃為推薦方案確定開發計劃進度開發人員硬件設備軟件工具各階段成本估計158書寫文檔提交審查可行性研究報告各步驟結果推薦方案開發計劃等需求分析需求的基本概念

寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什么。需求獲取是十分困難的用戶不清楚自己的希望用戶與開發人員領域不同不同用戶需求可能有矛盾需求經常性的變更需求分析的任務深入描述軟件的功能和性能確定軟件設計的約束和軟件同其它系統元素的接口細節定義軟件的其它有效性需求需求分析研究的對象是軟件項目的用戶要求準確地表達被接受的用戶要求確定被開發軟件系統的系統元素將功能和信息結構分配到這些系統元素中需求分析的任務就是借助于當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統的“做什么”的問題。19需求分析的步驟(1)調查研究從系統的角度來理解軟件并評審軟件范圍是否恰當確定對目標系統的綜合要求，即軟件的需求提出這些需求實現條件，以及需求應達到的標準20軟件的需求包括：功能需求性能需求環境需求可靠性需求安全保密要求用戶界面需求資源使用需求成本消耗需求開發進度需求預先估計以后系統可能達到的目標21

調查研究的另一項工作是建立分析所需要的通信途徑，以保證能順利地對問題進行分析。22(2)分析與綜合從數據流和數據結構出發，逐步細化所有的軟件功能，找出系統各元素之間的聯系、接口特性和設計上的約束，分析它們是否滿足功能要求，是否合理。剔除其不合理的部分，增加其需要部分。最終綜合成系統的解決方案，給出目標系統的詳細邏輯模型。23常用的分析方法面向數據流的結構化分析方法(SA)面向數據結構的Jackson方法(JSD)面向數據結構的結構化數據系統開發方法(DSSD)面向對象的分析方法(OOA)等24(3)書寫文檔系統規格說明書數據要求說明書用戶系統描述修正的開發計劃25需求分析流程26準備調查

首先，需求分析員應當起草需求調查問題表，將調查重點鎖定在該問題表內，否則調查工作將變得漫無邊際。問題表可以有多份，隨著調查的深入，問題表將不斷地被細化。根據經驗，用戶通常沒有耐心回答復雜的論述題，所以問題表應當以“選擇題”和“是非題”為主。制定問題表最簡便的方法就是從《用戶需求說明書》的模板中提取需求問題。其次，需求分析員應當確定需求調查的方式，例如：與用戶交談，向用戶提問題。向用戶群體發調查問卷。參觀用戶的工作流程，觀察用戶的操作。與同行、專家交談，聽取他們的意見。分析已經存在的同類軟件產品，提取需求。從行業標準、規則中提取需求。從Internet上搜查相關資料。最后，需求分析員與被調查者建立聯系，確定調查的時間、地點、人員等，撰寫需求調查計劃。要特別留意的是不要漏掉典型的用戶。

如何開展需求調查

27執行調查

準備工作完畢后，需求分析員按照計劃執行調查。在調查過程中隨時記錄（或存儲）需求信息。需求分析員與用戶面談時應當注意以下事項：

如果與用戶約好了時間，切勿遲到或早退。要注意禮節，盡可能獲得用戶的好感，并為下次打擾他們埋下伏筆。需求分析員應事先了解用戶的身份、背景，以便隨機應變。IT人士不可貌相，有些大企業的領導其外表很土氣，象農民。如果你路上碰到他，以為是個勤雜工，說：“喂，老師傅，來幫我拎東西。”也許這筆生意就泡湯了。需求調查不象偵探推理那樣從蛛絲馬跡著手，應該先了解宏觀問題，再了解細節問題。如果雙方氣氛融洽，可以采用靈活的訪談形式，輕易不要打斷用戶的談話。當雙方對某些問題的交流合乎邏輯地結束后，即可繼續討論問題表中的其它問題。盡可能避免為用戶添麻煩，但也不能怕給用戶添麻煩而降低需求調查的力度。避免片面地聽取某些用戶的需求而忽視其它用戶的需求。28《用戶需求說明書》與《產品需求規格說明書》的主要區別與聯系前者主要采用自然語言（和應用域術語）來表達用戶需求，其內容相對于后者而言比較粗略，不夠詳細。后者是前者的細化，更多地采用計算機語言和圖形符號來刻畫需求，產品需求是軟件系統設計的直接依據。兩者之間可能并不存在一一映射關系，因為軟件開發商會根據產品發展戰略、企業當前狀況適當地調整產品需求，例如用戶需求可能被分配到軟件的數個版本中。軟件開發人員應當依據《產品需求規格說明書》來開發當前產品。

撰寫《用戶需求說明書》29用戶需求說明書的參考模板30什么是好的需求規格說明書1正確

需求規格說明書應當正確地反映用戶的真實意圖，“正確”是《產品需求規格說明書》最重要的屬性。如果“不正確”僅僅是由于錯別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開發方和用戶必須對《需求規格說明書》進行確認。2清楚清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚：文檔的結構、段落是否亂七八糟？上下文是否不連貫？文檔的語句是否含糊其詞、羅里羅嗦？看了半天是否還不明白需求究竟是什么？313無二義性

“無二義性”是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導致人們誤解需求而開發出偏離需求的產品。為了使需求無二義性，人們在寫《產品需求規格說明書》時措詞應當準確，切勿模棱兩可。4一致

“一致”（Consistent）是指《產品需求規格說明書》中各個需求之間不會發生矛盾。矛盾常常潛伏在需求文檔的上下文中。5必要

《產品需求規格說明書》中的各項需求對用戶而言應當都是必要的。可以把“必要”比喻為“雪中送炭”。“必要”往前一步，要么是“畫蛇添足”要么是“錦上添花”。32“畫蛇添足”顯然是壞事，會導致開發人員多干一些吃力不討好的工作。所以要盡量剔除需求規格說明書中“畫蛇添足”的那些需求。“錦上添花”是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發者應當集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應當在《產品需求規格說明書》中將那些“錦上添花”的需求設置為較低的優先級。

6完備“完備”（Complete）是指《產品需求規格說明書》中沒有遺漏一些必要的需求。人們往往傾向于關注系統的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。不完備的《產品需求規格說明書》將導致產生功能不完整的軟件，用戶在使用該軟件時可能無法完成預期的任務。

337可實現《產品需求規格說明書》中的各項需求對開發方而言應當都是可實現的（Attainable）。“可實現”意味著在技術上是可行的，并且滿足時間、費用、質量等約束。營銷人員和用戶談生意時，為了能拿到“單子”，他們往往對用戶提出的需求“來者不拒”。吹牛皮雖然不犯法，但是《產品需求規格說明書》可是白紙黑字啊。經過雙方確認的《產品需求規格說明書》相當于商業合同，如果開發方不能夠實現《產品需求規格說明書》中的內容，那就是違約，可能會被罰款的。對于合同項目，如果開發方不能確信某些需求是否可實現，則應事先與用戶協商，達成一致的處理意見，避免將來發生商業糾紛。348可驗證

《產品需求規格說明書》中的各項需求對用戶方而言應當都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發生商業糾紛。例如，摩天大樓的一項需求是“抗十二級臺風”，這個需求看起來堂而皇之，但是如何驗證呢？當摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風來試驗？如果雙方都認可“采用計算機模擬十二級臺風”等效于實際測試，那么這項需求就是“可驗證”的。9確定優先級為什么要確定需求的“優先級”？理論上講，軟件的所有需求都應當被實現。但是在現實之中，項目存在“進度、費用、人力資源”等限制。在項目剛開始的時候，開發方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨“進度延誤、費用超支、人員不足”等問題，這時就亂套了。人們想出了“取舍”辦法：先做優先級高的需求，后做（甚至放棄）優先級低的需求，這樣可以將風險降到最低。35需求的優先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發方共同確定需求的優先級。10闡述“做什么”而不是“怎么做”

《產品需求規格說明書》的重點是闡述“做什么”，而不是闡述“怎么做”。“怎么做”是系統設計和實現階段的事情。國內的很多軟件公司里，開發人員常常身兼數職，可能把需求開發、系統設計、編程等工作從頭做到尾。所以他們在調查、分析、定義需求時，自然會想到“怎么做”，這并沒有什么過錯。如果在調查、定義需求時想好了“怎么做”，當然應該寫下來，否則豈不浪費！關鍵是不要將“怎么做”寫到需求規格說明書里面，記錄在其它文檔里就行了。36結構化分析方法

面向數據流進行需求分析的方法結構化分析方法適合于數據處理類型軟件的需求分析具體來說，結構化分析方法就是用抽象模型的概念，按照軟件內部數據傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的軟件為止37結構化分析方法使用工具：

數據流圖數據詞典結構化語言

IPO處理描述判定表與判定樹38數據流圖從數據傳遞和加工的角度，以圖形的方式刻畫數據流從輸入到輸出的傳輸變換過程。是結構化系統分析的主要工具。數據流圖的特性：抽象性、概括性、層次性數據流圖39

加工(數據變換)是數據流圖的核心，一個處理可以表示一個程序、一個模塊或多個程序，也可以是人工處理過程。為使系統清晰，每個處理應給予一個編號，并寫出處理的名稱。數據輸入的源點（Source）或數據輸出的匯點(Sink)其中要注明源點或匯點的名字數據流被加工的數據與流向，箭頭邊應給出數據流名字，可用名詞或名詞性短語命名。數據存儲文件保存數據的地方，它可以是文件，數據庫表或是它們的一部分，用名詞或名詞性短語命名。數據流圖中的主要圖形元素N140數據流與數據加工之間的關系41數據流圖的層次結構為了表達數據處理過程的數據加工情況，需要采用層次結構的數據流圖。按照系統的層次結構進行逐步分解，并以分層的數據流圖反映這種結構關系，能清楚地表達和容易理解整個系統42數據流圖的功能系統分析員用這種工具可以自頂向下分析系統信息流程可在圖上劃出需要計算機處理的部分根據數據存儲，進一步作數據分析，向數據庫設計過渡根據數據流向，定出存取放式。對應一個處理過程，用相應的語言、判定表等工具表達處理方法。43

分層數據流圖的設計方法

第一步，畫子系統的輸入輸出

把整個系統視為一個大的加工，然后根據數據系統從哪些外部實體接收數據流，以及系統發送數據流到那些外部實體，就可以畫出輸入輸出圖。這張圖稱為頂層圖。第二步，畫子系統的內部

把頂層圖的加工分解成若干個加工，并用數據流將這些加工連接起來，使得頂層圖的輸入數據經過若干加工處理后，變成頂層圖的輸出數據流。這張圖稱為0層圖。從一個加工畫出一張數據流圖的過程就是對加工的分解。44

分層數據流圖的設計方法

第一步，畫子系統的輸入輸出

把整個系統視為一個大的加工，然后根據數據系統從哪些外部實體接收數據流，以及系統發送數據流到那些外部實體，就可以畫出輸入輸出圖。這張圖稱為頂層圖。第二步，畫子系統的內部

把頂層圖的加工分解成若干個加工，并用數據流將這些加工連接起來，使得頂層圖的輸入數據經過若干加工處理后，變成頂層圖的輸出數據流。這張圖稱為0層圖。從一個加工畫出一張數據流圖的過程就是對加工的分解。45第三步，畫加工的內部

把每個加工看作一個小系統，把加工的輸入輸出數據流看成小系統的輸入輸出流。于是可以象畫0層圖一樣畫出每個小系統的加工的DFD圖。第四步，畫子加工的分解圖

對第三步分解出來的DFD圖中的每個加工，重復第三步的分解過程，直到圖中尚未分解的加工都是足夠簡單的（即不可再分解）。至此，得到了一套分層數據流圖。第五步，對數據流圖和加工編號

對于一個軟件系統，其數據流圖可能有許多層，每一層又有許多張圖。為了區分不同的加工和不同的DFD子圖，應該對每張圖進行編號，以便于管理。46分層的數據流圖47在多層數據流圖中，頂層流圖僅包含一個加工，它代表被開發系統。它的輸入流是該系統的輸入數據，輸出流是系統所輸出數據底層流圖是指其加工不需再做分解的數據流圖，它處在最底層中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續細化，形成子圖。48結構化分析方法步驟示例

商店業務處理系統49這個數據流圖只是一個高層的系統邏輯模型，它反映了目標系統要實現的功能數據流圖繪制步驟首先畫系統的輸入輸出，即先畫頂層數據流圖。頂層流圖只包含一個加工，用以表示被開發的系統，然后考慮該系統有哪些輸入數據、輸出數據流。頂層圖的作用在于表明被開發系統的范圍以及它和周圍環境的數據交換關系。

畫系統內部，即畫下層數據流圖。不再分解的加工稱為基本加工。一般將層號從0開始編號，采用自頂向下，由外向內的原則。畫0層數據流圖時，分解頂層流圖的系統為若干子系統，決定每個子系統間的數據接口和活動關系。50【例題】

考務處理系統的分層數據流圖如下圖所示。 該考務處理系統有如下功能：①對考生送來的報名表進行檢查； ②對合格的報名表編好準考證號碼后將準考證送給考生，并將匯總后的考生名單送給閱卷站； ③對閱卷站送來的成績表進行檢查，并根據考試中心指定的合格標準審定合格者； ④填寫考生通知單（內容包含考試成績及合格/不合格標志），送給考生； ⑤按地區、年齡、文化程度、職業、考試級別等進行成績分類統計及試題難度分析，產生統計分析表。 515253應注意的問題：①適當地為數據流、加工、文件、數據的源/匯點命名。名字應反映該元素的實際含義，避免空洞的名字。如數據、信息處理、計算等名字都不好。②畫數據流時不要夾帶控制流。數據流圖中各種數據的加工沒有考慮時序關系，引入控制流后，加工之間就有了時序關系，這與畫數據流圖不考慮實現細節的初衷相違背。③一個加工的輸出數據流不要與該加工的輸入數據流重名，即使它們的組成成分相同。例如圖(c)中加工1.1的輸入數據流“報名表”與輸出數據流“合格報名表”。④允許一個加工有多個數據流流向另一個加工，也允許一個加工有兩個相同的輸出數據流流向兩個不同的加工。⑤保持父圖與子圖的平衡。就是說，父圖與它的子圖的輸入數據流與輸出數據流應當在數量與名字上都相同。特別的是，如果父圖的一個輸入（或輸出）數據流對應于子圖中幾個輸入（或輸出）數據流，但子圖中這幾個數據流中的數據項合起來正好是父圖中的那個數據流，這時它們還算是平衡的。例如，圖(b)中加工2的輸出數據流“統計分析表”是由“難度分析表”和“分類統計表”組成，那么圖(b)與圖(d)仍滿足父圖與子圖平衡的條件。⑥在自頂向下的分解過程中，若一個文件首次出現時只與一個加工有關，那么這個文件應作為這個加工的內部文件而不必畫出。例如，圖(d)中的文件“試題得分表”就是圖(b)中加工的內部文件，所以在圖(b)中沒有畫出。⑦保持數據守恒。就是說，一個加工的所有輸出數據流中的數據必須能從該加工的輸入數據流中直接獲得，或者是通過該加工產生的數據。54檢查和修改數據流圖的原則數據流圖上所有圖形符號只限于前述四種基本圖形元素數據流圖的主圖必須包括前述四種基本元素，缺一不可數據流圖的主圖上的數據流必須封閉在外部實體之間每個加工至少有一個輸入數據流和一個輸出數據流55在數據流圖中，需按層給加工框編號。編號表明該加工所處層次及上下層的父圖與子圖的對應關系任何一個數據流子圖必須與它上一層的一個加工對應，兩者的輸入數據流和輸出數據流必須一致。此即父圖與子圖的平衡圖上每個元素都必須有名字數據流圖中不可夾帶控制流初畫時可以忽略瑣碎的細節，以集中精力于主要數據流56數據流圖的優缺點總體概念強，每一層都明確強調干什么，需要什么，給出什么。可以反映出數據的流向和處理過程。由于自頂向下分析，容易及早發現系統各部分的邏輯結構，也容易修正。不直觀，一般都要在作業流程分析的基礎上加以概括、抽象、修正來得到。人工繪制太麻煩，工作量較大。57數據字典數據字典與數據流圖配合，能清楚地表達數據處理的要求數據字典的內容：

數據流數據項數據存儲基本加工58（1）數據流數據流名稱及其編號數據流的來源：來自何方數據流的去向：去向何處數據流的組成：數據結構數據量的流通量：單位時間的傳輸次數高峰時期的流通量：業務的頻繁程度和時間有關59數據結構的描述60例存折格式

在取款數據流圖中，數據文件“存折”的格式如下圖所示：它在數據字典中的定義格式為：61存折＝戶名＋所號＋帳號＋開戶日＋性質＋(印密)＋1{存取行}50戶名＝2{字母}24所號＝“001”..“999”帳號＝“00000001”..“99999999”開戶日＝年＋月＋日性質＝“1”..“6”注：“1”表示普通戶，“5”表示工資戶等印密＝“0”注：印密在存折上不顯示存取行＝日期＋（摘要）＋支出＋存入＋余額＋操作＋復核62購書單發票領書單審查并開發票開領書單無效書單學生12各班學生用書表例：學生教材存量表63數據流條目說明舉例數據流名:發票別名:無簡述:學生購書時填寫的項目來源:學生去向:加工1“審查并開發票”組成:(學號)＋姓名＋｛書號＋數量｝數據流量:1000次/周

高峰值：開學期間1000次/天

64（2）數據項（數據元素）數據項名稱及編號：別名：取值的范圍和取值的含義數據項的長度：數據項所包含的字符或數字的位數65（3）數據存儲數據存儲的名稱及其編號：流入的數據流：指出其來源流出的數據流：指出其去向數據存儲的組成：指它所包含的數據項或數據結構66數據存儲的例子數據存儲名稱：銷售歷史編號：F05-01簡述：公司從九月初到目前為止所有配件的銷售量流入的數據流：“顧客的發貨單”，來源是“產生發貨單”處理邏輯流出的數據流：“銷售量”，去向是“產生銷售報表”處理邏輯數據存儲的組成：配件編號+日期+銷售量67（4）處理邏輯處理邏輯的編號及名稱簡述處理邏輯的輸入和輸出處理邏輯的主要功能處理邏輯的小說明（文檔之一）68加工邏輯說明結構化語言判定表判定樹

對數據流圖中每個基本加工都必須有一個加工小說明，給出這個加工的精確描述。小說明中應精確地描述加工的激發條件、加工邏輯、優先級、執行頻率和出錯處理等。對基本加工說明有三種描述方式：69結構化語言

介于自然語言和形式語言之間的語言結構化語言的特點：無確定語法可分層、嵌套70處理名:核實訂票處理(MHGP3200MD)編號:3.2激活條件:收到取訂票信息處理邏輯:1讀訂票旅客信息文件

2搜索此文件中是否有與輸入信息中姓名及身份證號相符的項

IF

有

THEN判斷余項是否與文件中信息相符

IF是THEN輸出已訂票信息

ELSE輸出未訂票信息

ELSE

輸出未訂票信息執行頻率:實時71判定表(決策表)描述多條件、多目標動作的形式化工具判定表舉例(計算機票折扣率)

旅游時間訂票量折扣量7