軟件工程原理計算機系統工程概念系統分析和定義硬件軟件系統（總體）設計硬件工程軟件工程計算機軟件計算機軟件定義（GB）：

a.與計算機系統的操作有關的計算機程序、規程、規則，以及可能有的文件、文檔及數據。

b.與計算機系統的操作有關的程序、規程、規則及任何與之有關的文檔。什么是軟件？軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序，數據及其相關文檔的完整集合。程序是按事先設計的功能和性能要求執行的指令序列數據是使程序能正常操縱信息的數據結構文檔是與程序開發，維護和使用有關的圖文材料軟件的特點軟件是一種邏輯實體，而不是具體的物理實體。因而具有抽象性軟件的生產與硬件不同，在它的開發過程中沒有明顯的制造過程在軟件的運行和使用期間，沒有硬件那樣的機械磨損，老化問題軟件的開發和運行常受到計算機系統的限制，對計算機系統有著不同程度的依賴性軟件的開發至今尚未完全擺脫手工藝的開發方式軟件本身是復雜的實際問題的復雜性程序邏輯結構的復雜性軟件成本相當昂貴相當多的軟件工作涉及到社會因素軟件的分類—按功能進行劃分系統軟件操作系統數據庫管理系統設備驅動程序通信處理程序等支撐軟件文本編輯程序文件格式化程序磁盤向磁帶向數據傳輸的程序程序庫系統支持需求分析、設計、實現、測試和管理的軟件

應用軟件商業數據處理軟件工程與科學計算軟件計算機輔助設計／制造軟件系統仿真軟件智能產品嵌入軟件醫療、制藥軟件事務管理、辦公自動化軟件計算機輔助教學軟件軟件的分類—按規模進行劃分類別參加人員數研制期限源程序行數

微型 1 1～4周0.5k小型1 1～6月1k～2k中型2～5 1～2年5k～50k大型5～20 2～3年50k～100k甚大型100～10004～5年1M(=1000k)極大型2000～50005～10年1M～10M

軟件的分類按工作方式劃分：實時處理軟件分時軟件交互式軟件批處理軟件按服務對象的范圍劃分：項目軟件產品軟件按使用的頻度進行劃分：一次使用頻繁使用按軟件失效的影響進行劃分：高可靠性軟件一般可靠性軟件軟件發展階段程序設計階段—50至60年代程序系統階段—60至70年代軟件工程階段—70年代以后軟件危機...計算機硬件性能／價格比和質量穩步提高軟件成本逐年上升，質量沒有可靠的保證軟件已成為限制計算機系統發展的關健因素將軟件開發和維護過程中遇到的一系列嚴重問題統稱為“軟件危機”在６０年代后期開始認真研究解決軟件危機的方法，逐步形成了新興的計算機軟件工程學...軟件危機什么是軟件危機？軟件危機是指在計算機軟件的開發和維護中所遇到的一系列嚴重問題。幾乎所有軟件都不同程度地存在這些問題概括地說軟件危機包含兩方面問題：如何開發軟件，怎樣滿足對軟件的日益增長的需求如何維護數量不斷膨脹的已有軟件軟件危機主要表現１．對軟件開發成本和進度的估計很不準確２．用戶對“已完成的”軟件不滿意的現象經常發生３．軟件產品的質量靠不住４．軟件不可維護５．軟件沒有適當的文檔資料６．軟件成本占計算機系統總成本的比例逐年上升７．軟件開發生產率提高的速度遠遠跟不上計算機應用迅速普及深入的趨勢產生軟件危機的原因一方面與軟件本身的特點有關在軟件運行前，軟件開發過程的進展難衡量，質量難評價，因此管理和控制軟件開發過程相當困難；在軟件運行中，軟件維護意味著改正或修改原來的設計，較難維護；軟件的顯著特點是規模龐大，復雜度超線性增長。要保證高質量大型軟件的開發，極端復雜困難，不僅涉及技術問題（如分析方法、設計方法、版本控制），更重要的是必須有嚴格而科學的管理。另一方面與軟件開發和維護方法不正確有關，這是主要原因。特別是忽視軟件需求分析的重要性忽視軟件需求分析的重要性對用戶要求沒有完整準確的認識就匆忙著手編寫程序軟件開發與編程等同忽略文檔軟件定義不明輕視維護對軟件開發的錯誤認識（1）已經有了關于建造軟件的標準和規程使用了嗎？開發者知道嗎？適用嗎？完整嗎？已經有了很好的軟件開發工具還需要計算機輔助軟件工程（CASE）工具對軟件開發的錯誤認識（2）如果計劃落后，可以增加人員趕回來給一個已經延遲的軟件項目增加人手只會使其更加延遲原有人員需要抽實踐訓練新手有了目標的一般描述就可以開始寫程序不完善的系統定義是項目失敗的主要原因對軟件開發的錯誤認識（3）項目需求不斷變化，但軟件很靈活，變化能夠很容易地得到滿足軟件需求的變化確實是經常的，但其產生的影響隨著引入的時間不同而不同寫出程序并使其正常運行，工作就結束了越早開始寫程序，就要花越長時間才能夠完成對軟件開發的錯誤認識（4）在程序真正開始運行前，無法評估其質量正式的技術評審質量過濾器成功項目唯一應該提交的就是運行程序軟件=程序+文檔+數據文檔是成功開發的基礎文檔為維護提供指導解決辦法...全面解決軟件危機需要一系列綜合措施：在軟件研制的各個階段采用好的工具；對軟件的實現提供有效的構件塊；為保證軟件質量提供自動設計技術；以及為協調、控制、管理提供基本理論和技術——軟件工程。...解決辦法軟件工程這一要素將駕馭前面的工具、構件決和技術軟件工程把管理、控制、評審等方法與分析、設計、編碼、測試、維護等技術結合起來沒有堅實的軟件開發方法學，即使最先進的工具和技術也不能使軟件危機有所減輕軟件工程—工程化方法用于解決任何產品開發的一種工程化方法是：要求在定義、開發和維護階段的每一步中都采用經過驗證的方法要求一系列的復查，以便在產品開發中保證質量規定在每一步中要產生的特定的文檔鼓勵能夠加速開發的各種工具和方法的使用與研制提供從原始產品概念到最后產品制造的一個可追溯的途徑軟件工程是使計算機軟件走向工程科學的途徑軟件工程—軟件工程定義軟件工程是為了經濟地獲得可靠的和能在實際機器上高效運行的軟件而建立和使用的好的工程原則。（FritzBauer1969)軟件工程是應用于計算機軟件的定義、開發和維護的一整套方法、工具、文檔、實踐標準和工序。（GB）軟件工程：（1）將系統化的、規范的、可度量的方法應用于軟件的開發、運行和維護的過程，即將工程化應用于軟件中。（2）（1）中所述方法的研究。（IEEE93）軟件工程是模仿在硬件研制中行之有效的一套計劃、管理、技術、方法，基于軟件的生存期概念而建立起來的。軟件工程的定義Boehm：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料FritzBauer：建立并使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法軟件工程三要素：方法、工具和過程軟件工程方法為軟件開發提供了“如何做”的技術軟件工具為軟件工程方法提供了自動的或半自動的軟件支撐環境軟件工程—視圖1...質量焦點過程方法工具...軟件工程—視圖1質量焦點：任何工程方法必須以有組織的質量保證為基礎。質量的理念刺激不斷過程改進，導致出現更加成熟的軟件工程方法。它是軟件工程的根基。過程：軟件工程的基礎是過程。軟件工程過程是將技術層結合在一起的凝聚力，使得軟件能夠合理地和及時地開發出來。方法：軟件工程方法層提供了建造軟件在技術上需要“怎么做”。工具：在工具層對過程和方法提供了自動和半自動的支持。軟件工程—生存期概念計算機軟件生存期中有三個階段：定義階段、開發階段、維護階段。定義階段：為軟件項目做出計劃、預算資金和進度，分析并規定詳細的需求——做什么開發階段：用經過驗證的各種設計、編碼和測試方法把軟件需求轉變為一個可執行的程序——怎么做維護階段：糾正所遇到的各種問題，修正軟件使之適合于不同的工作環境，增強功能要求——改變每一個階段都有一系列的工程步驟，每一步都以能加以復查并可移交才作為結束軟件工程知識結構2001年5月ISO/IECJTC1（ISO和IEC的第一聯合技術委員會）發布了《SWEBOK指南V0.95(試用版)》（GuidetotheSoftwareEngineeringBodyofKnowledge,簡稱SWEBOK）SWEBOK把軟件工程學科的主體知識分為10個知識領域。軟件工程知識結構

軟件需求軟件設計軟件構造軟件測試軟件維護軟件配置管理軟件工程管理軟件工程過程軟件工程工具和方法軟件質量軟件工程的基本原理B.W.Boehm（1983）1)用分階段的生命周期計劃嚴格管理;2)堅持進行階段評審;3)實行嚴格的產品控制;4)采用現代程序設計技術;5)結果應能清楚地審查;6)開發小組的人員應該少而精;7)承認不斷改進軟件工程實踐的必要性。計劃管理缺乏科學而周密的計劃是軟件開發普遍現象不成功軟件項目一半以上由于計劃不周造成應把軟件生存期劃分為若干階段，制定科學周密、切實可行的計劃，并嚴格按計劃進行管理，這是軟件項目取得成功的先決條件計劃所做的和按計劃去做計劃一般包括：項目開發計劃、軟件配置管理計劃、軟件質量保證計劃、軟件測試計劃等評審在每個階段都進行嚴格的評審，以便盡早發現在軟件開發過程中所犯的錯誤，是一條必須遵循的重要原則質量保證工作不能等到程序編制完成后才進行：1.程序中的大部分錯誤是在編碼之前造成的2.錯誤的檢測與改正時間越晚，所付出的代價也就越高。3.錯誤還會被“放大”配置管理...軟件研制各階段產生的文檔、報告、程序清單和數據等，構成軟件配置全部軟件配置是一個軟件產品的真正代表，必須使其保持精確和一致為了保持軟件配置的一致性，必須實行嚴格的產品控制，對變更進行嚴格的控制和管理...配置管理配置管理是標識和確定系統中配置項的過程，在系統整個生存周期內控制這些項的投放和變更，記錄并報告配置的狀態和變更要求，驗證配置項的完整性和正確性。它包括對軟件配置的標識、控制、審計、記錄等一系列的活動在軟件研制過程中，由業已經過正式審核與同意，可用作下一步開發的基礎，并且只有通過正式的修改管理步驟方能加以修改的規格說明或產品形成了配置管理的基線軟件開發方法和工具軟件工程鼓勵研制和采用各種先進的軟件開發方法和工具各種軟件開發方法的出現和采用大大改善了軟件的開發效率和維護效率軟件工程輔助工具、計算機輔助軟件工程（ＣＡＳＥ）環境工具和環境的使用進一步提高了軟件的開發效率、維護效率和軟件質量文檔...軟件研制是腦力勞動，具有不可見性為了實現對軟件研制過程的管理，在軟件研制的每個階段，都應按規定的格式編寫出完整準確的文檔文檔是軟件中不可缺少的組成部分...文檔的作用1)作為階段工作成果和結束標志；2)向管理人員提供軟件開發過程中的進展和情況，把軟件開發過程中的一些“不可見的”事物轉換成“可見的”文字資料；3)記錄開發過程中的技術信息，便于協調以后的軟件開發、使用和修改；4)提供對軟件的有關運行、維護和培訓的信息，便于各類人員之間相互了解彼此的工作；5)向潛在用戶報告軟件的功能和性能，使他們能判定該軟件能否服務于自己的需要。開發小組軟件開發小組的組成人員的素質應該好，而人數則不宜過多開發小組人員的素質和數量是影響軟件產品質量和開發效率的重要因素隨著開發人員數目的增加，因為交流情況討論問題造成的通信開銷也急劇增加組成少而精的開發小組是一條基本原理不斷改進僅有前面六條基本原理并不能保證軟件開發和維護的過程能趕上時代前進的步伐、跟上技術的不斷進步Boehm提出應把承認不斷改進軟件工程實踐的必要性作為軟件工程的第七條基本原理不僅要積極地采納新的軟件技術，而且要注意不斷總結經驗軟件工程基本原則-1抽象采用分層次抽象，自頂向下、逐層細化的辦法控制軟件開發過程的復雜性。信息隱蔽將模塊設計成“黑箱”，實現的細節隱藏在模塊內部，不讓模塊的使用者直接訪問。這就是信息封裝，使用與實現分離的原則。模塊化如C語言程序中的函數過程，C++語言程序中的類。模塊化有助于信息隱蔽和抽象，有助于表示復雜的系統。局部化要求在一個物理模塊內集中邏輯上相互關聯的計算機資源，保證模塊之間具有松散的耦合，模塊內部具有較強的內聚。這有助于控制解的復雜性。軟件工程基本原則-2確定性

軟件開發過程中所有概念的表達應是確定的、無歧義性的、規范的。一致性整個軟件系統的各個模塊應使用一致的概念、符號和術語。程序內部接口應保持一致。軟件和硬件、操作系統的接口應保持一致。系統規格說明與系統行為應保持一致。用于形式化規格說明的公理系統應保持一致。完備性軟件系統不丟失任何重要成分，可以完全實現系統所要求功能的程度。為了保證系統的完備性，在軟件開發和運行過程中需要嚴格的技術評審?？沈炞C性開發大型的軟件系統需要對系統自頂向下、逐層分解。系統分解應遵循系統易于檢查、測試、評審的原則，以確保系統的正確性。軟件研制過程模型軟件生存周期從產品的設想到不再使用，包含軟件開發、運行、維護全過程軟件開發包含一系列階段、活動和里程碑，如需求分析、設計、編碼、測試軟件研制過程模型給出了將這些基本階段進行有機組合的結構性模型生存周期支持過程2配置管理1文檔編制8問題解決3質量保證4驗證5確認6聯合評審7審核生存周期基本過程2供應1獲取3開發4運作5維護生存周期組織過程1管理3改進2基礎設施4培訓瀑布模型軟件測試詳細設計軟件實現系統需求軟件需求概要設計1970年由W.Royce提出瀑布模型描述從60年代開始，為解決軟件危機逐漸發展起軟件工程。瀑布模型則是傳統軟件工程的基礎。瀑布模型的基本思想是將軟件生命周期劃分為若干明確定義的階段。需求捕獲是軟件生命周期的第一個階段；上一個階段生成規定的軟件中間產品（軟件文檔，偽碼等），傳到下一階段作進一步加工，最后得到目標產品。瀑布模型是一個理想化過程，瀑布模型特點(1)階段間具有順序性和依賴性(2)推遲實現的觀點(3)質量保證的觀點瀑布模型的使用風險和適用情況使用風險需求未被充分理解系統太大而不能一次實現事先打算采用的技術迅速發生變化需求迅速發生變化有限的資源無法利用某一中間產品適用情況所有的系統功能一次交付時必須同時淘汰全部老系統時瀑布模型V模型系統需求軟件需求概要設計詳細設計單元測試組裝測試編碼確認測試系統聯試詳細設計概要設計軟件需求系統需求型號任務編譯后的單元測試后的單元組裝后的軟件測試后的軟件交付軟件驗證驗證驗證驗證驗證驗證驗證與確認驗證與確認

J.McDermid于1994年在“軟件工程師參考手冊”中提出增量模型軟件1：運行維護詳細設計編碼測試系統需求軟件需求概要設計軟件2：運行維護詳細設計編碼測試增量模型描述預先計劃的產品改進從一套給定的需求開始，通過一系列的造型實施開發，第一個造型納入一部分需求，下一個造型納入更多的需求，以此類推，直到系統完成在每個造型中實行必要的過程、活動和任務增量模型特點在開發每個造型時，開發過程中的活動和任務順序地或部分平行重疊地使用當相繼的造型在部分并發地被開發時，開發過程中的活動和任務可以在造型間平行地被采用增量模型的使用風險和適用情況風險需求未被很好地理解突然提出一些功能事先打算采用的技術迅速發生變化需求迅速發身變化長時期內有限的資源投入適用情況需要早期獲得功能中間產品可以提供使用系統被自然地劃分成增量工作人員和（或）資金可以逐步增加漸進模型開發1運行維護1開發3運行維護3開發2運行維護2漸進模型描述和特點通過造型開發系統需求不能被完全理解，且不能在初始時就確定需求一部分被預先定義，然后在每個相繼的造型中逐步完善每個造型被開發時，開發過程中的活動和任務順序地或部分重疊并行地被采用對所有造型，開發過程中的活動和任務通常按同意順序被重復使用采用漸進模型的一些原因1）需要某些用戶經驗來改進和完善需求；2）某些部分的實現可能取決于未來技術的可用性；3）某些新的用戶需求被預料到，但目前還不清楚；4）某些需求可能比遇到的那些還難以滿足，并且確定不允許因這些需求推遲可用的交付。漸進模型的使用風險和適用情況風險突然提出一些功能長時期內有限的資源投入適用情況需要早期獲得功能中間產品可以提供使用系統被自然地劃分成增量工作人員和（或）資金可以逐步增加需要用戶反饋來理解全部需求便于對技術變化的監督原型開發模型需求分析快速設計用戶評價原型建立原型生產產品修改原型原型分類拋棄式原型開發樣品式原型開發漸增式原型開發螺旋模型B.Boehm于1988年提出螺旋模型描述瀑布模型和漸進模型相結合，增加風險分析用來指導大型軟件項目的開發將開發劃分為制定計劃、風險分析、實施工程、客戶評估四類活動沿螺旋線每轉一圈，表示開發出一個更完善的新的軟件版本噴泉模型噴泉模型描述1990年B.H.Sollers和J.M.Edwards提出主要用于采用面向對象技術的項目噴泉體現迭代和無間隙的特征軟件的某些部分常常被重復工作多次，相關對象在每次迭代中隨之加入漸進的軟件成分在分析、設計、實現等各項活動之間無明顯邊界RUP模型軟件過程模型的選擇1）模型應符合軟件本身的性質（規模、復雜性）2）模型應滿足軟件應用系統整體開發進度要求3）模型應有可能控制并消除軟件開發風險4）模型應有可用的計算機輔助工具（如快速原型工具）的支持5）模型應與用戶和軟件開發人員的知識和技能相匹配6）模型應有利于軟件開發的管理與控制航天型號軟件研制過程模型航天型號研制經歷方案階段、模樣、初樣、試樣（正樣）、定型型號軟件研制通常也經歷模樣、初樣、試樣（正樣）模樣、初樣、正樣軟件是針對同一個軟件開展的循環研制，側重面不同。結合原型、漸進模型，以原型-基本型-更新型來形成航天型號軟件研制過程模型原型、基本型、更新型基本思想是：首先在需求尚不明確的情況下，對已知的需求和尚不能確定的需求進行分析整理，在此基礎上簡單地設計、編制軟件，產生一個軟件的原型，并對原型進行多方面的研究、分析和討論，以便確定所采取的技術實現方案是否可行，需求還要做哪些補充、修改和完善，從而獲得一個內容較完整、接口較明確的軟件需求和一個切實可行的軟件實現技術途徑；其次在軟件原型研制的基礎上，進行一次完整、嚴格的軟件研制工作，獲得一個高質量的軟件基本型；最后在軟件基本型的基礎上，針對更新的軟件需求，采用軟件更新與更改的的方法，對軟件進行更新，獲得軟件的更新型模樣、初樣、試樣-正樣模樣初樣正樣原型基本型更新型更新版本1更新版本2……原型軟件原型研制的目的是明確接口、確定需求、試驗系統方案需求分析：根據系統的任務分解和技術要求，對已知需求、應有需求、未確認需求等進行綜合分析，形成粗略的原型軟件需求規格說明。設計：對軟件的總體結構和接口進行設計，形成軟件設計說明。編碼調試：編制程序并調試通過。分析總結：運行軟件，并與系統總體、相應接口單位進行詳細的分析討論，對軟件需求進行補充、修改和完善，并確定技術途徑的可行性。對高質量要求的軟件研制，軟件原型研制所獲的程序應廢棄，不帶入以后的研制階段?；拘突拘脱兄频娜蝿帐歉鶕敬_定的軟件需求，全面開展軟件的研制工作，形成一個基本滿足系統對軟件各項要求的基本型軟件，以直接應用于型號或作為下一步更新的基礎。基本型軟件的研制，必須采用瀑布式開發過程，嚴格執行。研制階段包括：系統需求、軟件需求分析、概要設計、詳細設計、軟件實現、軟件組裝測試、軟件確認測試、系統聯試軟件開發方法軟件開發方法是軟件開發過程所遵循的方法和步驟，其目的在于有效地得到一些工作產品，既程序和文檔，并且滿足質量要求程序設計方法是軟件開發方法的組成部分此外還有分析方法和設計方法評價軟件開發方法的四大特征技術特征：支持各種技術概念的方法特色，如層次性、抽象性、并行性、安全性、正確性等使用特征：用于具體開發時的特色，如易理解性、易移植性、易復用性、工具的支持、任務范圍、使用的廣度、活動過渡的可行性、產品的易修改性、對正確性的支持等管理特征：增強對軟件開發活動管理的能力方面的特色，如易管理性、支持或阻礙團隊工作的程度、中間階段的確定、工作產品、配置管理、階段結束準則、費用估計等經濟特征：給軟件組織產生的在質量和生產力方面的可見效益，如分析活動的局部效益、全生存周期效益、獲得該開發方法的代價、使用它的代價、管理的代價等選用軟件開發方法的考慮因素1對該開發方法是否已具有經驗，或者已有受過培訓的人員2開發項目的進度、人員組成情況3為開發項目提供的資源如何4計劃、組織、管理的可行性5開發項目的領域知識準備情況航天的考慮結構化方法較全面、最成熟、最基礎、使用最廣泛、有成功經驗結構化方法適合航天軟件研制工作結構化方法是基礎性方法結構化方法包括就形成了配套的軟件結構化分析方法、結構化設計方法和結構化編程方法，其核心和基礎是結構化程序設計理論為什么要講這些所謂的“方法”？“我只要滿足需求就可以了，我自己開發使用什么方法你管不著?！薄斑@些方法根本沒有什么用處，我們那里高手很多，我們不屑于使用這些方法?！薄敖Y構化”起源：對GOTO的認識1968年Dijkstra在ACM通訊中發表了“GOTO語句是有害的”文章，認為：GOTO語句是有害的，是造成程序混亂的禍根，程序的質量與GOTO語句的數量成反比，應該在所有高級程序設計語言中取消GOTO語句激起了強烈的反響和長期廣泛的論戰論據1966年，Boehm和Jacopini證明了程序設計語言只要上旬、選擇和重復三種形式的控制結構就足以表達出各種其他形式的結構1970年McKeeman稱其XPL編譯程序僅用一個GOTO語句1972年C.Strachey設計的操作系統只在五處使用了標號和GOTO語句爭辯否定GOTO取消GOTO后，程序易理解、易排錯、易維護沒有其它好的結構代替GOTO的話，容易濫用GOTO無GOTO的程序容易進行正確性證明肯定GOTO在塊和進程的非正常出口處往往需要使用GOTO會使程序執行效率較高在合成程序目標時，GOTO語句往往是有用的，如返回語句用GOTO結論1974年Knuth發表了總結性文章：“帶有GOTO的結構化程序設計”令人信服地總結和證實了以下三點：濫用GOTO語句確實有害，應盡量避免完全避免使用GOTO語句也并非是個明智的方法，有些地方使用GOTO語句，會使程序流程更清楚、效率更高爭論的焦點不應該放在是否取消GOTO語句，而應該放在用什么樣的程序結構上最后一點使關鍵，肯定以提高程序清晰性為目標的結構化方法“方法”的核心是模型所謂的“方法”通常圍繞一系列的模型展開，給出這些模型的建立，校驗和轉換方法。COMPUTERMODELREALREAL仿自：CantwellSmith“Computers,ModelsandtheEmbeddingWorld”方法與模型計算機設計模型REAL實際分析模型分析編碼設計分析模型和設計模型分析模型：對當前所處的環境，或者現實情況建立的模型，用于分析和評估。設計模型：對未來要建造的系統或者環境建立的模型，用于系統實施，也用于交流和評價。建立模型有助于精確有效地表達和溝通。結構化方法結構化程序設計：一種良好定義的軟件開發技術，它采用自頂向下設計和實現方法，并嚴格地采用結構化程序的控制構造結構化方法的原則清晰第一效率第二設計先于編碼自頂向下逐步細化1清晰第一效率第二著名的“清晰第一，效率第二”已成為當今主導的程序設計風格“先求清楚后求快”“保持程序簡單以求快”“寫清楚——不要為‘效率’犧牲清晰”2設計先于編碼“開始寫程序越早，完成程序需要的時間就越長?！薄霸O計先于編碼”已成為所有程序設計必須遵守的一條原則。設計一定要利用各種設計工具來進行。3逐步細化的設計方法…逐步細化方法是結構化程序設計的心臟。1）中心思想a.程序設計是一個由粗到細的過程;b.程序設計不僅包括對控制結構的設計，也包括對數據結構的設計，兩者都要一步步地細化。3逐步細化的設計方法2）指導原則a.先分解主要問題，次要的問題可暫時擱置；b.堅持漸進的原則，每一步的變化不要太大；c.過程的細化與數據結構的細化宜并行、交叉地進行；d.選用適合于問題的設計工具；e.最后一步應詳細到所得結果可以直接翻譯為源程序。3）優點a.便于控制開發的復雜性;b.便于驗證程序的正確性。結構化方法采用的原則抽象逐步求精信息隱藏模塊化模塊獨立模塊化原則模塊是由邊界元素限定的相鄰的程序元素(例如，數據說明，可執行的語句)的序列，而且有一個總體標識符來代表它。模塊是構成程序的基本構件。模塊化就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求。模塊化原則主要思想是：將整個系統進行分解成為若干功能獨立的，能分別設計、編程和測試的模塊程序員能單獨地負責一個或幾個模塊的開發開發一個模塊不需要知道系統其它模塊的內部結構和編程細節模塊之間的接口盡可能簡明，模塊應盡可能彼此隔離模塊化和軟件成本Meyer模塊化五條標準…(1)模塊可分解性如果一種設計方法提供了把問題分解為子問題的系統化機制，它就能降低整個問題的復雜性，從而可以實現一種有效的模塊化解決方案。(2)模塊可組裝性如果一種設計方法能把現有的(可重用的)設計構件組裝成新系統，它就能提供一種并非一切都從頭開始做的模塊化解決方案。Meyer模塊化五條標準…(3)模塊可理解性如果可以把一個模塊作為一種獨立單元(無需參考其他模塊)來理解，那么，這樣的模塊是易于構造和易于修改的。(4)模塊連續性如果對系統需求的微小修改只導致對個別模塊，而不是對整個系統的修改，則修改所引起的副作用將最小。Meyer模塊化五條標準…(5)模塊保護性如果在一個模塊內出現異常情況時，它的影響局限在該模塊內部，則由錯誤引起的副作用將最小。模塊化應達到的要求具有可修改性：對整個系統的一次修改只涉及少數幾個模塊，這種局部性的修改不僅能滿足系統修改的要求，而且不會影響系統已經具有的良好質量具有易讀性：每個模塊的含義和職責被明確，模塊之間的接口關系清楚，從而降低復雜性，使得閱讀和理解比較方便具有易驗證性：只有每個模塊能實現正確，才可能使整個系統的正確性有必要的前提抽象人類在認識復雜現象的過程中使用的最強有力的思維工具是抽象。人們在實踐中認識到，在現實世界中一定事物、狀態或過程之間總存在著某些相似的方面(共性)。把這些相似的方面集中和概括起來，暫時忽略它們之間的差異，這就是抽象。抽象就是抽出事物的本質特性而暫時不考慮細節。逐步求精逐步求精是人類解決復雜問題時采用的基本技術，也是許多軟件工程技術的基礎。可以把逐步求精定義為：“為了能集中精力解決主要問題而盡量推遲對問題細節的考慮?！鼻缶珜嶋H上是細化過程。抽象與求精抽象與求精是一對互補的概念抽象使得設計者能夠說明過程和數據，同時卻忽略低層細節。可以把抽象看作是一種通過忽略多余的細節同時強調有關的細節，而實現逐步求精的方法。求精則幫助設計者在設計過程中揭示出低層細節。這兩個概念都有助于設計者在設計演化過程中創造出完整的設計模型。信息隱藏應用模塊化原理時，自然會產生的一個問題：“為了得到最好的一組模塊，應該怎樣分解軟件”Parnas提出的信息隱藏是模塊化程序設計的基本方法信息隱藏：為了實現部件的可見性控制，在分層構造軟件模塊時，要求這些部件只在模塊內部可見，在模塊外部不可見模塊獨立“模塊獨立”概念是模塊化、抽象、逐步求精和信息隱藏等概念的直接結果，也是完成有效的模塊設計的基本標準。模塊的獨立程度可以由兩個定性標準來度量，這兩個標準分別稱為內聚和耦合。耦合衡量不同模塊彼此間互相依賴(連接)的緊密程度；內聚衡量一個模塊內部各個元素彼此結合的緊密程度。耦合耦合是對一個軟件結構內不同模塊之間互連程度的度量。耦合強弱取決于模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。應該追求盡可能松散耦合的系統。研究、測試或維護任何一個模塊可以不需要對系統的其他模塊有很多了解。發生在一處的錯誤傳播到整個系統的可能性就很小。內聚內聚標志一個模塊內各個元素彼此結合的緊密程度，它是信息隱蔽和局部化概念的自然擴展。簡單地說，理想內聚的模塊只做一件事情。設計時應該力求做到高內聚，通常中等程度的內聚也是可以采用的，而且效果和高內聚相差不多；但是，低內聚很壞，不要使用。內聚和耦合內聚和耦合是密切相關的，模塊內的高內聚往往意味著模塊間的松耦合。內聚和耦合都是進行模塊化設計的有力工具，但是實踐表明內聚更重要，應該把更多注意力集中到提高模塊的內聚程度上。事實上，沒有必要精確確定內聚的級別。重要的是設計時力爭做到高內聚，并且能夠辨認出低內聚的模塊，有能力通過修改設計提高模塊的內聚程度降低模塊間的耦合程度，從而獲得較高的模塊獨立性。啟發規則以下的啟發規則有助于模塊化：改進軟件結構提高模塊獨立性模塊規模應該適中深度、寬度、扇出和扇入都應適當模塊的作用域應該在控制域之內力爭降低模塊接口的復雜程度設計單入口單出口的模塊模塊功能應該可以預測結構化方法圖示數據字典DFDSTDERD加工規約數據對象描述控制規約接口設計體系結構設計數據設計過程設計結構化分析方法結構化分析(SA)方法是結構化程序設計理論在軟件需求分析階段的運用。它是七十年代中期倡導的基于功能分解的分析方法，常用于基于瀑布模型的軟件研制過程的需求分析階段，其目的是幫助弄清用戶對軟件的需求。按照DeMarco的定義，“結構化分析就是使用數據流圖（ＤＦＤ）、數據字典（ＤＤ）、結構化英語、決策表和決策樹等工具，來建立一種新的、稱為結構化規格說明的目標文檔?！苯Y構化分析五個步驟1)通過對用戶的調查，以軟件的需求為線索，獲得當前系統的具體模型；2)去掉具體模型中非本質因素，抽象出當前系統的邏輯模型；3)根據計算機的特點分析當前系統與目標系統的差別，建立目標系統的邏輯模型；4)完善目標系統并補充細節，寫出目標系統的軟件需求規格說明；5)評審直到確認完全符合用戶對軟件的需求。八條指導原則1)請用戶共同參與開發；2)編寫用戶資料，考慮他們的專門技術水平和閱讀與使用資料的目的；3)使用畫圖工具做媒介，減少與用戶交流時發生問題的可能性；4)進行系統設計之前建立一個系統的邏輯模型；5)自頂向下進行分析設計；6)自頂向下的方法進行測試；7)驗收之前，就讓用戶看到系統的某些主要輸出，使用戶能夠盡早地看到結果，及時地提出意見；8)對系統的評價不僅是指開發和運行費用的評價，而是對整個生存過程中的費用和收益的評價。結構化分析方法四大特點一是用畫圖的方法二是自頂向下地分解三是強調邏輯而不是物理四是沒有重復性結構化分析的工具1)數據流圖(DFD)；2)控制流圖(CFD)；3)數據字典(DD)；4)控制邏輯表達方法,包括狀態轉換圖(STD)等；5)處理邏輯表達方法，包括結構化語言、判斷樹和判斷表；6)數據存儲結構規范化；7)數據立即存取圖(DIAD)。四句指導工作的準則分層分片，均衡分解；父子平衡，推遲細節。分層就是逐步細化；分片就是用一組數據流圖來代替一大張包羅萬象的總圖。均衡分解是指自頂向下畫分層數據流圖時，各個子系統的分解程度應大致均勻。父子平衡是指數據流圖的父圖與子圖在輸入數據和輸出數據上應該分別保持一致。推遲細節是指為了優先考慮重要問題，允許將一些細節推遲到下層數據流圖來處理。結構化設計方法70年代提出的面向數據流、重點確定軟件結構的設計方法“結構化設計就是采用最佳的可能方法設計系統的各個組成部分以及各成分之間的內部聯系的技術。也就是說，結構化設計是這樣一個過程，它決定用哪些方法把哪些部分聯系起來，才能解決好某個具體有清楚定義的問題?！被舅枷胧菍④浖O計成由相對獨立、單一功能的模塊組成的結構。評價模塊結構質量的兩個具體標準——內聚度和耦合度耦合度耦合度：耦合度是各模塊之間相互聯系的一種度量，它是對模塊獨立性的直接衡量，耦合度越弱就意味著模塊的獨立性越高，則模塊間相互影響就越小。耦合度的強弱可以由弱至強分為非直接耦合、數據耦合、特征耦合、控制耦合、外部耦合、公共耦合和內容耦合七個等級。內聚度內聚度是指一個模塊內部各成分（語句或語句段）之間的聯系程度，內聚度高，則模塊的相對獨立性勢必會提高。內聚度由低到高可劃分為偶然內聚、邏輯內聚、時間內聚、過程內聚、通訊內聚、順序內聚和功能內聚七個等級。結構化設計方法設計步驟1)建立初始結構圖;2)改進初始結構圖。建立初始結構圖開始細化/修改軟件需求規格說明中的數據流圖是變換型嗎？變換分析事物分析將映射得來的初始結構圖改進為最終結構圖對最終結構圖進行評審結束是否從數據流圖過渡到結構圖傳入傳入部分變換中心傳出部分（a）變換型結構傳出變換接受事務分析動作1動作2動作3接受部分事務中心（b）事務型結構DFD主模塊輸入模塊主加工模塊輸出模塊(a)事務控制模塊接受模塊動作發送模塊動作1模塊動作1模塊動作1模塊(b)SC改進初始結構圖…

1）減少塊間聯系，降低耦合度：可從方式、作用、數量等方面著手，其中最常用的是減少模塊間傳遞的參數個數；2）消除管道性模塊，提高內聚度：管道性模塊的塊內聯系很弱，只是像管道一樣將一些參數從主模塊傳送到它的幾個下層模塊，對這樣的模塊，應予以消除；3）適當考慮系統將來可能發生的變化；改進初始結構圖4）注意模塊的大?。合拗颇K大小是降低復雜性的手段之一；5）適當調整調用和被調用的次數，即深度、寬度、扇出和扇入都要適當。一個模塊調用或被調用過多，往往是設計不好的跡象；6）整體考慮問題：即盡可能研究整張結構圖，而不是只分別考慮一張結構圖的各個部分。三條指導規則1）對模塊分割、合并和變動模塊調用關系的指導規則2）保持高扇入/低扇出的規則3）把作用域保持在控制域之內的規則對模塊分割、合并和變動模塊調用關系的指導規則分割或合并結構圖中的模塊，應以提高模塊獨立性為首要的標準：力求提高內聚，降低耦合，簡化接口，少用全局性和控制型信息要適當考慮快的大小對模塊位置應否變更，視處理是否方便來定，不必拘泥于數據流圖保持高扇入/低扇出的規則扇入數指調用該模塊的模塊個數扇出數指該模塊調用的模塊個數扇入高則上級模塊多，能增加利用率扇出低則下級模塊少，能減少復雜度扇出數以３－４為宜，最好不超過5-7軟件結構通常具有“甕”形或“清真寺”形的形狀把作用域保持在控制域之內的規則一個模塊的控制域，等于模塊本身加上其下級模塊。一個模塊的作用域，是受這個模塊中的判定所影響的模塊。規則的含義是：a.作用域不要超過控制域的范圍；b.軟件系統的判定，其位置離受它控制的模塊越近越好。結構化編程方法用一組標準的準則和工具從事程序設計，稱為結構化程序設計；這些準則和工具包括一組基本控制結構，自頂向下擴展原則，模塊化和逐步求精結構化編程方法派生于結構化程序設計理論，它要求使用順序、選擇、循環等基本控制結構，并遵循增加程序產量、提高程序可讀性、容易測試和驗證的原則來編寫程序。結構化編程應遵循的原則…1)使用程序設計語言中的順序、選擇、循環等有限的控制結構表示程序的控制邏輯；2)選用的控制結構只準許有一個入口和一個出口；3)程序語句組成容易識別的塊，每塊只有一個入口和一個出口；4)復雜結構應該用嵌套的基本控制結構來實現；結構化編程應遵循的原則5)語言中所沒有的控制結構，應該采用前后一致的方法來模擬；6)嚴格控制GOTO語句，僅在下列情況才可使用：a.用一個非結構化的程序設計語言去實現一個結構化的構造；b.若不使用GOTO語句會使功能模糊；c.在某種可以改善而不是損害程序可讀性的情況下。結構化編程方法的主要優點1)易于理解、使用和維護。程序員采用結構化編程方法，降低了程序的復雜性，因此容易編寫程序。程序員能夠進行逐步求精、程序證明和測試，以確保程序的正確性，程序容易閱讀并被人理解，便于用戶使用和維護。2)提高編程工作的效率，降低了軟件開發成本。由于結構化編程方法能夠把錯誤控制到最低限度，因此能夠減少調試和查錯時間。結構化程序是由一些為數不多的基本結構模塊組成，這些模塊甚至可以由機器自動生成，從而極大地減輕了編程工作量。結構化方法的缺點著名的“兩個鴻溝”“數據和過程的鴻溝”“分析和設計的鴻溝”專注于過程的分析模型，其抗擊變動的能力和可復用性就相對較差。軟件開發的原則（1）規范嚴格的原則遵循嚴格化原則，可以達到開發出正確、成功的軟件產品的目的軟件開發過程是創造性的工作過程，但嚴格化不會抑制創造性嚴格的分析設計可以增強對創造性成果的信心嚴格化對可靠性、維護性、可移植性、可理解性等產生影響過程詳細記錄可供精確地掌握和控制開發過程軟件開發的原則（2）分隔化的原則解決復雜問題時從不同的方面把問題分隔開，然后單獨集中精力解決每一個方面的問題分隔化原則是要將相互關系不太緊密的方面分割開，對相互聯系僅考慮其影響分隔的途徑：以時間次序、以質量指標、以軟件規模、以不同的視圖、以開發人員的技能軟件開發的原則（3）模塊化的原則先對復雜問題進行分析，找出基本要素，盡量使之獨立，然后各個擊破簡單的單元易于加工、維修，可以標準化、通用化復雜問題的分解，基于自頂向下的思路已有模塊的組合，基于自底向上的思路軟件開發的原則（4）抽象化的原則重要、帶有普遍意義特征的方面或內容被抽象出來，次要的、缺乏普遍意義的方面或內容被忽略抽象是分隔化原則的一種特殊應用軟件開發的原則（5）預見變動的原則軟件由于其錯誤、新需求、新環境而產生變化要求開發時就要考慮到軟件變動的要求PARNAS的原則開發系列產品漸進開發，從子集出發，信息隱藏，保持接口不變采用為變化而設計的技術軟件開發的原則（6）通用化的原則盡量找出對類似問題或相關問題的具有一定普遍意義的解決方法，并在相應產品開發中應用，使軟件產品具有一定的通用性對普遍性、通用性問題的解決方法具有質量、經濟方面的價值對通用和專用，需要在經濟和效率方面進行權衡通用性原則是設計通用的軟件產品的一個最基本原則軟件開發的原則（7）逐步完善的原則由于難以確定用戶的具體需求，只能從不完善逐步走向完善必須注意：記錄每一個有意義的漸進文檔必須盡早反映變動，變動得到控制MICROSOFT在采用逐步完善原則方面取得了成功軟件開發的原則（8）有關軟件質量的原則用戶至上的原則以用戶的利益為前提處處為用戶使用方便著想千方百計幫助用戶使用好軟件注意與用戶的交流質量可靠的原則在質量、成本之間進行權衡軟件開發的原則（9）有關軟件文檔的原則文檔標準化原則用戶手冊簡明原則用詞規范盡可能使用用戶的專業術語或行話通俗易懂描述的句子不要太長軟件開發的原則（10）有關設計編碼的原則根據文檔設計（需求記錄在文檔）注意概念的完整整個軟件要適于變動、易于維護程序編制簡明清晰注意技術與工具更新軟件開發的原則（11）有關軟件測試的原則測試的獨立性原則克服心理障礙獨立公正專業優勢成功的測試是發現問題的測試要分析錯誤產生的原因，舉一反三需求分析概念軟件需求的定義客戶定義的“需求”對開發者是一個較高層次的產品概念。開發者所說的“需求”對用戶來說像是詳細說明。軟件需求包含多個層次，不同層次的需求從不同角度與不同程度反映著細節問題。IEEE軟件工程術語（1997）的需求定義：（1）用戶解決問題或達到目標所需的條件或能力。（2）系統或系統部件要滿足合同、標準、規范或其它正式強制性文件所需具有的條件或能力。（3）反映上面（1）或（2）所描述的條件或能力的文檔說明。上述定義包括從用戶（外部）、從開發者（內部）角度來闡述需求。需求的層次業務需求（businessrequirement）：反映組織機構或客戶對系統、產品高層次的目標要求。用戶需求（userrequirement）：描述用戶使用產品必須要完成的任務。功能需求（functionalrequirement）：定義開發人員必須實現的軟件功能。需求規格說明中還包括非功能需求。軟件需求各組成部分之間關系業務需求用戶需求功能需求系統需求質量屬性其它非功能需求約束條件項目視圖與范圍文件使用實例文檔軟件需求規格說明需求管理的困難性不成熟的需求分析無足夠用戶參與用戶需求的不斷增加摸棱兩可的需求不必要的特征（鍍金）過于精簡的規格說明忽略了用戶分類不準確的計劃高質量需求過程的獲益開發后期和整個維護階段的重做的工作大大減少Boehm發現可以節省成本68倍有研究認為可以節省成本200倍強調產品開發中的通力合作，面向市場，讓用戶積極參與，可以建立忠實的客戶關系，避免在無用功能上白耗精力，彌補用戶期望和開發者實際開發間的期望鴻溝采用系統方法將需求分配到各子系統可以簡化集成有效的變更控制和影響分析能降低變更的負面影響清晰、無二義的需求文檔有利于測試需求說明的特征完整性正確性可行性必要性劃分優先級無二義性可驗證性需求規格說明的特點完整性先用TBD標明缺項在開發前必須解決所有TBD一致性可修改性每項需求只在SRS中出現一次可追蹤性結構、粒度方便設計、實現、測試的追蹤誰是客戶定制軟件：合同甲方（提出方）通用軟件：高層管理者和（或）市場部嵌入式軟件：軟件所屬計算機系統客戶的權利1要求分析人員使用符合客戶語言習慣的表達2要求分析人員了解客戶的業務及目標3要求分析人員編寫軟件需求規格說明4要求得到需求工作結果的解釋說明5要求開發人員尊重你的意見6要求開發人員對需求及產品實施提供建議7描述產品易使用的特性8調整需求，允許重用已有的軟件組件9要求對變更的代價提供真實可信的評估10獲得滿足客戶功能和質量要求的系統客戶的義務1給分析人員講解你的業務2抽出時間清楚地說明并完善需求3準確而詳細地說明需求4及時地作出決定5尊重開發人員的需求可行性及成本評估6劃分需求優先級別7評審需求文檔和原型8需求出現變更要馬上聯系9應遵守開發機構處理需求變更的過程10尊重開發人員采用的需求工程過程對簽定需求協議的認識簽約是客戶同意需求的標志行為客戶不應當忽略簽約的嚴肅性開發方不應當因此拒絕變更簽約應當建立在一個需求協議的基線上應當理解為：“我同意這份文檔表達了目前我們對項目軟件需求的了解。進一步的變更可在此基礎上通過項目定義的變更過程來進行。我知道變更可能會使我們要重新協商成本、資源和項目時間工期任務等。”需求開發過程需求開發過程需求獲取需求分析編寫需求規格說明需求驗證知識培訓需求管理項目管理需求獲取的內容在同用戶的交流過程中收集各種用戶的信息認真理解用戶的各項要求澄清模糊排除不合理明確約束分析人員的兩個信條第一：只有在徹底了解和掌握了用戶的全部意圖之后，才有可能建立起成功的軟件系統。第二：一切從用戶的角度著想，在條件允許的情況下，應盡可能地保證用戶從所構造的軟件系統中獲得最大的利益。容易產生的問題交流障礙誤解各方缺乏共同的語言“完整性”問題需求永遠會變化用戶本身的意見不一致錯誤的要求認識上混淆目標和需求需求獲取的過程確定需求開發過程編寫項目目標和范圍文檔將用戶群分類并歸納各自特點選擇各類用戶的產品代表建立起典型用戶的核心隊伍讓用戶代表確定使用實例召開應用程序開發聯系會議分析用戶工作流程確定質量屬性和其它非功能屬性通過檢查當前系統的問題報告來進一步完善需求跨項目重用需求工作流程用戶調查具體模型邏輯抽象當前系統邏輯模型當前系統計算機化評審修改正式模型完善細節目標系統目標系統初始模型經認可的問題需求系統模型用戶建立模型的步驟分析現有系統和過程，建立物理模型抽取特征，建立舊系統的邏輯模型根據新的要求，補充和建立新的邏輯模型需求分析的任務需求分析的內容提煉、分析和仔細審查已收集到的需求確保所有利益相關者都明白其含義并找出其中的錯誤、遺漏或其它不足的地方是從用戶最初的非形式化需求到滿足用戶要求的軟件產品的映射過程是對用戶意圖不斷進行提示和判斷的過程需求分析的步驟繪制系統關聯圖創建用戶接口（界面）原型分析需求可行性確定需求的優先級別為需求建立模型創建數據字典使用質量功能調配（QFD）明確哪些是客戶最關心的特征編制需求規格說明的過程采用軟件需求規格說明（SRS）模版指明需求的來源為每項需求注上標號記錄業務規范（操作原則）創建需求跟蹤矩陣需求規格說明的作用為用戶、分析人員和設計人員之間的交流提供方便支持目標軟件系統的確認控制軟件開發進程軟件需求規格說明文檔條目1范圍2引用文檔3工程需求3.1外部接口需求3.2功能需求3.3內部接口3.4數據元素要求3.5適應性要求3.6容量和時間要求3.7安全要求3.8保密要求3.9設計約束3.10軟件質量因素3.11人的工程需求3.12需求的可跟蹤性4合格性需求4.1合格性方法4.2特殊的合格性需求5交付準備軟件需求必須包括的屬性1）標識：每項軟件需求都必須有標識，使以后的各階段容易跟蹤。2）需要：基礎軟件需求必須用上述標識標明?；A軟件需求是非協商性的；其它不那么重要的需求是可協商的。3）優先級：對于遞增式交付，每一項需求必須包括優先級程度，以便決定研制進度。4）穩定性：某些需求在軟件生存期內是穩定的；另一些可能是更依賴來自各設計階段的反饋，或可能在軟件生存期內要有所修改，這種非穩定性需求應當被指出。5）源：每一項軟件需求都必須有一個能回溯到系統需求的索引。6）清晰性：如果需求有一個并且只有一個解釋它就是清晰的。7）驗證性：每一軟件需求都必須是能被驗證的。這意味著必須能做到：檢查需求已經體現在設計中；證明該軟件將實現需求；測試該軟件確實能實現需求。IEEE需求規格說明的編寫8原則1從實際重分離功能，描述“做什么”不描述“怎么做”2要求有一個面向處理的軟件系統規格說明語言，以描述軟件系統的動態行為3必須對以該軟件為元素的系統進行說明，以描述清楚之間的關系4必須對軟件系統的運行環境進行說明，以保持接口描述的一致性5必須是認識的模型而不是實際的模型6必須是可操作的7必須容忍不完備性和可修改性8必須局部化和松散耦合，使得變化時只修改一個片段SRS編寫風格（Kovitz1999)保持語句和段落的簡短采取主動語態的表達方式編寫具有正確的語法、拼寫和標點的完整句子使用的術語和詞匯表中所定義的應該一致需求陳述應該采用一致的樣式，如“主體+動作+可觀察的結果”避免使用模糊的、主觀的術語以避免不確定性避免使用比較性的詞匯需求表達需求說明語句保持語句和段落的簡短采用主動語態的表達方式編寫具有正確的語法和標點的完整句子使用的術語應該和詞匯表中定義的一致需求陳述應該具有一致的式樣，例如“系統必須……”，或者“用戶必須……”，并緊跟一個行為動作和可觀察的結果，例如“倉庫管理子系統必須現實一張在所請求的倉庫中有存貨的藥品名單。”需求表達為了減少不確定性，避免采用模糊的、主觀的術語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術、優越的、可接受的和健壯的。避免使用比較性的詞匯，例如：提高，最大化，最小化和最佳化。定量地說明所需要提高的程度或者說清一些參數可接受的最大值和最小值。需求表達“產品必須在固定的時間間隔內提供狀態消息，并且每次時間間隔不得小于60秒”后臺任務管理器應該在用戶界面的指定區域顯示狀態消息在后臺任務進程啟動之后，消息必須每隔60（+_10）秒更新一次，并且保持連續的可見性。如果正在正常處理后臺任務進程，那么后臺任務管理器必須顯示后臺任務進程已完成的百分比當完成后臺任務時，后臺任務管理器必須顯示一個“已完成”的消息。如果后臺任務中止執行，那么后臺任務管理器必須顯示一個出錯信息。需求表達“產品必須在顯示和隱藏非打印字符之間進行瞬間切換”“用戶在編輯文檔時，通過激活特定的觸發機制，可以在顯示和隱藏所有HTML標記之間進行切換?！毙枨蟊磉_“分析程序應該能生成HTML標記出錯的報告，這樣就可以使HTML的初學者使用它來迅速排錯”在HTML分析程序完全分析完一個文件后，該分析程序必須生成一個出錯報告，這個報告中包含了在分析文件中所發生錯誤的HTML所在的行號以及文本內容，還包含了對每個錯誤的描述。如果分析過程中未發生任何錯誤，就不必生成任何錯誤報告需求驗證審查需求文檔以需求為依據編寫測試用例編寫用戶手冊確定判別產品合格的準則需求驗證的內容一致性：任何需求不與其它需求矛盾可行性：現有技術條件下可以實現完整性：包括用戶需要的每一個功能和性能有效性：正確有效，確實能夠解決用戶面對的問題知識培訓培訓需求分析人員培訓軟件需求的用戶代表和管理人員讓開發人員了解應用領域的基本概念編寫項目術語匯編分析員的職責１）作為管理員、用戶和顧客的顧問；２）從各種來源收集數據，并綜合問題的解答；３）分析新的系統，并評價現有的系統；４）準備文檔和管理報告；５）理解硬件和軟件的界面；６）為了產生軟件需求規格說明，必要時要進行一些研究工作；７）為編寫軟件需求規格說明主持座談會；８）不斷吸收先進技術。分析員的素質１）能夠合乎邏輯地、象征性地、抽象地、創造性地思考問題；２）能作為小組中的一個成員很好地開展工作；３）熟悉計算機硬件和軟件的能力；４）自覺遵守時間，能按規定的進度完成任務；５）在系統的分析和設計中能發揮其他人的作用；６）能保持教師和學生的雙重身份，愿意培養其他人，而他本人亦能通過夜校、自學、培訓班等不斷提高；７）能夠傾聽別人的意見，但又能根據客觀事實來作決策，而不是依賴別人的意見；８）熟悉商業和政策管理部門的組織、原則。分析員應該顯示的性格特征1）善于領會一些抽象的概念，重新整理使之成為各種邏輯成分，并根據各種邏輯成分綜合出問題的解決辦法。2）善于從各種相應沖突或混淆的原始資料中汲取恰當的依據。3）能夠理解用戶——需求者的環境。4）具備把系統的硬件部分和（或）軟件部分應用于用戶——需求者環境的能力。5）具備良好的用書面或口頭形式進行討論及交換意見的能力。6）具有“既能看到樹木，又能看到森林”的能力。需求管理確定需求變更控制過程建立變更控制委員會（CCB）進行需求變更影響分析跟蹤所有受需求變更影響的工作產品建立需求基準版本和需求控制版本文檔維護需求變更歷史記錄跟蹤每項需求的狀態衡量需求穩定性使用需求管理工具與需求分析相關的項目管理選擇一種合適的軟件開發模型基于需求的項目計劃發生需求變更時協商項目約定文檔化和管理與需求相關的風險跟蹤需求工程耗費的工作量需求分析方法工具描述工具數據流圖(DataFlowDiagram，簡稱DFD)控制流圖(ControlFlowDiagram，簡稱CFD)狀態轉換圖（StateTransitiondiagram，簡稱STD）數據字典(DataDictionary，簡稱DD)處理說明分析模型的結構實體—關系圖狀態—遷移圖數據流圖數據對象描述加工規格說明數據字典控制規格說明數據和控制模型的關系過程模型PSPECDFD控制模型CSPECCFD控制輸入數據輸出控制輸出數據輸入數據條件過程啟動數據流圖:DFD（DataFlowDiagram）數據流圖是用來描述系統邏輯模型的一種圖形工具數據流圖從數據傳遞和加工的角度，以圖形的方式刻畫數據流從輸入到輸出的移動變換過程數據流圖圖符2.1打印數據流DataFlow加工處理Process外部實體ExternalEntity數據存儲DataStore數據流圖圖符說明數據流：箭頭表示數據流方向。一般在旁邊標注數據流名。加工處理：對數據進行加工、處理和變換，從而實現某個功能或操作外部實體：表示要加工處理的數據是從外部得到或從外部提供，同時也是數據結果的接收者，可以是人、組織、其它系統數據存儲：表示處理過程中存放各種數據的文件建立DFD的步驟由外向里：先畫系統的輸入輸出，然后畫系統的內部，再畫處理的內部。由頂向下：頂層、中間層、底層數據流圖逐層分解：從外向里數據流圖的層次結構為了表達數據處理過程的數據加工情況，需要采用層次結構的數據流圖。按照系統的層次結構進行逐步分解，并以分層的數據流圖反映這種結構關系，能清楚地表達和容易理解整個系統數據流圖的層次頂層DFD用一個加工處理表示軟件含所有相關外部實體含外部實體與軟件中間的數據流不含數據存儲唯一描述軟件的作用范圍，對總體功能、輸入、輸出進行抽象描述，反映軟件和系統、環境的關系ABC軟件abcd頂層數據流圖軟件系統外部實體外部實體……外部實體外部實體……輸入數據流輸入數據流輸出數據流輸出數據流中間和底層DFD2.1aaa2.2bbb2.3cccddd數據分層的數據流圖F0A0B0F11A0B0F12F13F14F15p1C1D1M1N1F21M1F22N1F23K2F24W2F25p1Y2X2第n

層第n+1

層第n+2

層數據流圖的層次在多層數據流圖中，頂層流圖僅包含一個加工，它代表被開發系統。它的輸入流是該系統的輸入數據，輸出流是系統所輸出數據底層流圖是指其加工不需再做分解的數據流圖，它處在最底層中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續細化，形成子圖。數據流圖中的其它圖形元素ABC------有A則B或者C，或者兩者都有*ABC+ABC------有A則B與C，或者兩者同時有------有A則B或C，但不會同時有B與C------當A或B有一個存在就有CABC*ABC------只有當A與B都存在，則有CDFD規則和注意事項數據存儲不出現在頂層圖中，外部實體通常不出現在頂層圖外數據存儲之間不應該有數據流仔細、恰當地為處理命名：處理+對象仔細、恰當地為數據流命名：反映整體含義對處理建立唯一、層次性編號每個處理通常要求既有輸入又有輸出一個DFD的處理個數為7±2（魔數7±2）不要試圖讓DFD反映處理的順序檢查數據流圖的正確性a.數據守恒某個處理用以產生輸出的數據沒有輸入給這個處理，即出現遺漏另一種是一個處理的某些輸入并沒有在處理中使用以產生輸出b.數據存儲（文件）的使用數據存儲（文件）應被數據流圖中的處理讀和寫，而不是僅讀不寫、或僅寫不讀c.父圖和子圖的平衡父子關系和平衡規則父圖表示子圖間的接口，即數據流的方向和數量子圖代表父圖中某個處理的細節子圖個數不大于父圖中的處理個數所有子圖的輸入、輸出數據流和父圖中相應處理的輸入、輸出數據流必須一致父圖和子圖的平衡發票1.3開領書單領書單(a)父圖1.3.1學生領書單1.3.21.3.3教材(b)子圖遵守加工編號規則頂層加工不編號第二層的加工編號為1,2,3,…,n號第三層編號為1.1,1.2,1.3…n.1,n.2…等號依此類推人工銷售教材系統流程圖舉例學生開購書證明購書證明開購書發票

發票收書費

領書單發書學生學生教材購銷系統購書單領書單缺書單進書通知進書通知保管員1銷售購書單領書單學生缺書單進書通知2采購保管員第1

層第2

層

教材存量表F1

缺書登記表F2外部實體外部實體

教材銷售子系統無效書單購書單1.3登記并開領書單1.2開發票1.1審查有效性1.4登記缺書1.5補售教材采購學生學生進書通知有效書單發票領書單暫缺書單1銷售購書單領書單缺書單進書通知2采購進書通知缺書登記表教材存量表學生保管員第2

層補售書單第3層

教材存量表F1

缺書登記表F2F1書號單價數量

各班用書表F3

售書登記表F4外部項1銷售購書單領書單缺書單進書通知2采購進書通知缺書登記表教材存量表學生保管員采購子系統

第2層第3

層缺書單2.3修改教材庫存和待購量銷售進書通知進書通知2.1按書號匯總缺書2.2按出版社統計缺書保管員

教材存量表F1

待購教材表F5

教材一覽表F6

缺書登記表F2控制板傳感器家庭安全軟件電話線警報控制板顯示警報類型傳感器狀態用戶命令和數據顯示數據電話號碼信號與用戶交互1配置系統2啟/停系統3顯示消息狀態5處理口令4監控系統6配置信息用戶命令和數據配置請求配置數據啟/?？诹钆渲脭祿渲脭祿?停消息顯示消息傳感器信息有效標識消息傳感器狀態電話號碼信號警報類型評價防備設置6.1顯示格式化6.2生成警報信號6.3撥電話6.5讀傳感器6.4配置信息傳感器標識,類型傳感器狀態電話號碼配置數據傳感器標識,定位警報數據傳感器信息電話號碼信號控制流圖（CFD）2.1打印控制流ControlFlow加工處理Process外部實體ExternalEntity數據存儲DataStore控制說明與用戶交互1配置系統2啟/停系統3顯示消息狀態5處理口令4監控系統6配置信息顯示動作狀態（完成、進行中）控制板控制板顯示警報電話線傳感器傳感器事件閃爍標志警報狀態時間溢出警報信號啟/停開關數據字典（DD）數據字典是對所有與系統相關的數據元素的一個有組織的列表，以及精確的、嚴格的定義，使得用戶和系統分析員對于輸入、輸出、存儲成分和中間計算結果有共同的理解。數據字典把不同的需求文檔和分析模型緊密結合在一起數據字典的作用DFD中的數據流、數據存儲表示某個有組織的數據集合，它們要由SA的其他描述工具-需求字典(數據字典)來描述，包括：詞條描述數據結構描述加工邏輯說明數據字典的內容DD包含的信息名稱（標識）別名來源去向組成（內容描述）流動屬性（頻率、數據量）補充信息數據的層次關系原數據元素組合項重復項選擇項可選項數據字典基本符號＝表示“等于”，“定義為”，“由什么構成”＋表示“與”，“和”[|]表示“或”，即選擇括號中用“|”號分隔的各項中的某一項{}表示“重復”，即括號中的項要重復若干次，重復次數的上下限也可以在括號邊上標出（）表示“可選”，即括號中的項可以沒有**表示“注釋”（1）數據流詞條描述數據流名：說明：簡要介紹作用即它產生的原因和結果數據流來源：來自何方數據流去向：去向何處數據流組成：數據結構數據量流通量：數據量，流通量舉例：購書單發票領書單審查并開發票開領書單無效書單學生12各班學生用書表學生教材存量表數據流詞條說明舉例數據流名:發票別名:

無簡述:

學生購書時填寫的項目來源:

學生去向:

加工1“審查并開發票”組成:(學號)＋姓名＋｛書號＋數量｝數據流量:1000次/周

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

（2）數據元素詞條描述數據元素名：類型：數字（離散值，連續值），文字（編碼類型）長度：取值范圍：相關的數據元素及數據結構：數據元素詞條舉例數據項名:貨物編號別名:G-No,G-num簡述:本公司的所有貨物的編號類型:字符串長度：10取值范圍及含義:

第1位：[J｜G](進口/國產)

第2-4位：LB01..LB29(類別)

第5-7位：“A00”..“A99”(規格)

第8-10位：“001”..“999”(品名編號)（3）數據文件詞條描述數據文件名：簡述：存放的是什么數據輸入數據：輸出數據：數據文件組成：數據結構存儲方式：順序，直接，關鍵碼存取頻率：數據文件（存儲）詞條舉例文件名:庫存記錄別名:無