專業定義
軟件工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分别給出了自己的定義：
（1）、BarryBoehm：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。
（2）、IEEE在軟件工程術語彙編中的定義：軟件工程是：1.将系統化的、嚴格約束的、可量化的方法應用于軟件的開發、運行和維護，即将工程化應用于軟件；2.在1中所述方法的研究
（3）、FritzBauer在NATO會議上給出的定義：建立并使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法。
目前比較認可的一種定義認為：軟件工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正确的管理技術和當前能夠得到的最好的技術方法結合起來。
（4）、《計算機科學技術百科全書》中的定義：軟件工程是應用計算機科學、數學及管理科學等原理，開發軟件的工程。軟件工程借鑒傳統工程的原則、方法，以提高質量、降低成本。其中，計算機科學、數學用于構建模型與算法，工程科學用于制定規範、設計範型(paradigm)、評估成本及确定權衡，管理科學用于計劃、資源、質量、成本等管理。
比較認可的一種定義認為：軟件工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正确的管理技術和當前能夠得到的最好的技術方法結合起來。
發展過程
軟件是由計算機程序和程序設計的概念發展演化而來的，是在程序和程序設計發展到一定規模并且逐步商品化的過程中形成的。軟件開發經曆了程序設計階段、軟件設計階段和軟件工程階段的演變過程。
程序設計階段
程序設計階段出現在1946年～1955年。此階段的特點是：尚無軟件的概念，程序設計主要圍繞硬件進行開發，規模很小，工具簡單，無明确分工（開發者和用戶），程序設計追求節省空間和編程技巧，無文檔資料（除程序清單外），主要用于科學計算。
軟件設計階段
軟件設計階段出現在1956年～1970年。此階段的特點是：硬件環境相對穩定，出現了“軟件作坊”的開發組織形式。開始廣泛使用産品軟件（可購買），從而建立了軟件的概念。随着計算機技術的發展和計算機應用的日益普及，軟件系統的規模越來越龐大，高級編程語言層出不窮，應用領域不斷拓寬，開發者和用戶有了明确的分工，社會對軟件的需求量劇增。但軟件開發技術沒有重大突破，軟件産品的質量不高，生産效率底下，從而導緻了“軟件危機”的産生。
軟件工程階段
自1970年起，軟件開發進入了軟件工程階段。由于“軟件危機”的産生，迫使人們不得不研究、改變軟件開發的技術手段和管理方法。從此軟件産生進入了軟件工程時代。此階段的特定是：硬件已向巨型化、微型化、網絡化和智能化四個方向發展，數據庫技術已成熟并廣泛應用，第三代、第四代語言出現；第一代軟件技術：結構化程序設計在數值計算領域取得優異成績；第二代軟件技術：軟件測試技術、方法、原理用于軟件生産過程；第三代軟件技術：處理需求定義技術用于軟件需求分析和描述。
培養目标
軟件工程的目标是：在給定成本、進度的前提下，開發出具有可修改性、有效性、可靠性、可理解性、可維護性、可重用性、可适應性、可移植性、可追蹤性和可互操作性并且滿足用戶需求的軟件産品。追求這些目标有助于提高軟件産品的質量和開發效率，減少維護的困難。下面分别介紹這些概念。
（1）可修改性（modifiablity）。容許對系統進行修改而不增加原系統的複雜性。它支持軟件的調試與維護，是一個難以達到的目标。
（2）有效性（efficiency）。軟件系統能最有效地利用計算機的時間資源和空間資源。各種計算機軟件無不将系統的時/空開銷作為衡量軟件質量的一項重要技術指标。很多場合，在追求時間有效性和空間有效性方面會發生矛盾，這時不得不犧牲時間效率換取空間有效性或犧牲空間效率換取時間有效性。時/空折衷是經常出現的。有經驗的軟件設計人員會巧妙地利用折衷概念，在具體的物理環境中實現用戶的需求和自己的設計。
（3）可靠性（reliability）。能防止因概念、設計和結構等方面的不完善造成的軟件系統失效，具有挽回因操作不當造成軟件系統失效的能力。對于實時嵌入式計算機系統，可靠性是一個非常重要的目标。因為軟件要實時地控制一個物理過程，如宇宙飛船的導航、核電站的運行，等等。如果可靠性得不到保證，一旦出現問題可能是災難性的，後果将不堪設想。因此在軟件開發、編碼和測試過程中，必須将可靠性放在重要地位。
（4）可理解性（understandability）。系統具有清晰的結構，能直接反映問題的需求。可理解性有助于控制軟件系統的複雜性，并支持軟件的維護、移植或重用。
（5）可維護性（maintainability)。軟件産品交付用戶使用後，能夠對它進行修改，以便改正潛伏的錯誤，改進性能和其他屬性，使軟件産品适應環境的變化，等等。由于軟件是邏輯産品，隻要用戶需要，它可以無限期的使用下去，因此軟件維護是不可避免的。軟件維護費用在軟件開發費用中占有很大的比重。可維護性是軟件工程中一項十分重要的目标。軟件的可理解性和可修改性有利于軟件的可維護性。
（6）可重用性（reusebility）。概念或功能相對獨立的一個或一組相關模塊定義為一個軟部件。軟部件可以在多種場合應用的程度稱為部件的可重用性。可重用的軟部件有的可以不加修改直接使用，有的需要修改後再用。可重用軟部件應具有清晰的結構和注解，應具有正确的編碼和較低的時/空開銷。各種可重用軟部件還可以按照某種規則存放在軟部件庫中，供軟件工程師選用。可重用性有助于提高軟件産品的質量和開發效率、有助于降低軟件的開發和維護費用。從更廣泛的意義上理解，軟件工程的可重用性還應該包括：應用項目的重用，規格說明（也稱為規約）的重用，設計的重用，概念和方法的重用，等等。一般來說，重用的層次越高，帶來的效益也就越大。
（7）可适應性（adaptability）。軟件在不同的系統約束條件下，使用戶需求得到滿足的難易程度。适應性強的軟件應采用廣為流行的程序設計語言編碼，在廣為流行的操作系統環境中運行，采用标準的術語和格式書寫文檔。适應性強的軟件較容易推廣使用。
（8）可移植性（portability）。軟件從一個計算機系統或環境搬到另一個計算機系統或環境的難易程度。為了獲得比較高的可移植性，在軟件設計過程中通常采用通用的程序設計語言和運行環境支撐。對依賴于計算機系統的低級（物理）特征部分，如編譯系統的目标代碼生成，應相對獨立、集中。這樣，與處理機無關的部分就可以移植到其他系統上使用。可移植性支持軟件的課重用性和課适應性。
（9）可追蹤性（tracebility）。根據軟件需求對軟件設計、程序進行正向追蹤，或根據程序、軟件設計對軟件需求進行逆向追蹤的能力。軟件可追蹤性依賴于軟件開發各個階段文檔和程序的完整性、一緻性和可理解性。降低系統的複雜性會提高軟件的可追蹤性。軟件在測試或維護過程中或程序在執行期間出現問題時，應記錄程序事件或有關模塊中的全部或部分指令現場，以便分析、追蹤産生問題的因果關系。
（10）可互操作性（interoperability）。多個軟件元素相互通信并協同完成任務的能力。為了實現可互操作性，軟件開發通常要遵循某種标準，支持折衷标準的環境将為軟件元素之間的可互操作提供便利。可互操作性在分布計算環境下尤為重要。
軟件工程活動是“生産一個最終滿足需求且達到工程目标的軟件産品所需要的步驟”。主要包括需求、設計、實現、确認以及支持等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟件需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟件體系結構，包括子系統、模塊以及相關層次的說明、每一模塊接口定義。詳細設計産生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。确認活動貫穿于整個開發過程，實現完成後的确認，保證最終産品滿足用戶的要求。支持活動包括修改和完善。伴随以上活動，還有管理過程、支持過程、培訓過程等。
過程
生産一個最終能滿足需求且達到工程目标的軟件産品所需要的步驟。軟件工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、确認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟件需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟件系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的接口定義。詳細設計産生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。确認活動貫穿于整個開發過程，實現完成後的确認，保證最終産品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴随以上過程，還有管理過程、支持過程、培訓過程等。
原則
軟件工程的原則是指圍繞工程設計、工程支持以及工程管理在軟件開發過程中必須遵循的原則。軟件工程的原則有以下四項基本原則：
1）選取适宜開發範型。
該原則與系統設計有關。在系統設計中，軟件需求、硬件需求以及其他因素之間是相互制約、相互影響的，經常需要權衡。因此，必須認識需求定義的易變性，采用适宜的開發範型予以控制，以保證軟件産品滿足用戶的要求。
2）采用合适的設計方法。
在軟件設計中，通常要考慮軟件的模塊化、抽象與信息隐蔽、局部化、一緻性以及适應性等特征。合适的設計方法有助于這些特征的實現，以達到軟件工程的目标。
3）提供高質量的工程支持。
“工欲善其事，必先利其器”。
在軟件工程中，軟件工具與環境對軟件過程的支持頗為重要。軟件工程項目的質量與開銷直接取決于對軟件工程所提供的支撐質量和效用。
4）重視開發過程的管理。
軟件工程的管理，直接影響可用資源的有效利用，生産滿足目标的軟件産品，提高軟件組織的生産能力等問題。因此，僅當軟件過程得以有效管理時，才能實現有效的軟件工程。
這一軟件工程框架告訴我們，軟件工程的目标是可用性、正确性和合算性；實施一個軟件工程要選取适宜的開發範型，要采用合适的設計方法，要提供高質量的工程支撐，要實行開發過程的有效管理；軟件工程活動主要包括需求、設計、實現、确認和支持等活動，每一活動可根據特定的軟件工程，采用合适的開發範型、設計方法、支持過程以及過程管理。根據軟件工程這一框架，軟件工程學科的研究内容主要包括：軟件開發範型、軟件開發方法、軟件過程、軟件工具、軟件開發環境、計算機輔助軟件工程(CASE)及軟件經濟學等。
基本原理
自從1968年提出“軟件工程”這一術語以來，研究軟件工程的專家學者們陸續提出了100多條關于軟件工程的準則或信條。美國著名的軟件工程專家巴利·玻姆（Barry Boehm）綜合這些專家的意見，并總結了美國天合公司（TRW）多年的開發軟件的經驗，于1983年提出了軟件工程的七條基本原理。
玻姆認為，這七條原理是确保軟件産品質量和開發效率的原理的最小集合。它們是相互獨立的，是缺一不可的最小集合；同時，它們又是相當完備的。
人們當然不能用數學方法嚴格證明它們是一個完備的集合，但是可以證明，在此之前已經提出的100多條軟件工程準則都可以有這七條原理的任意組合蘊含或派生。下面簡要介紹軟件工程的七條原理：
1、用分階段的生命周期計劃嚴格管理
這一條是吸取前人的教訓而提出來的。統計表明，50%以上的失敗項目是由于計劃不周而造成的。在軟件開發與維護的漫長生命周期中，需要完成許多性質各異的工作。這條原理意味着，應該把軟件生命周期分成若幹階段，并相應制定出切實可行的計劃，然後嚴格按照計劃對軟件的開發和維護進行管理。玻姆認為，在整個軟件生命周期中應指定并嚴格執行6類計劃：項目概要計劃、裡程碑計劃、項目控制計劃、産品控制計劃、驗證計劃、運行維護計劃。
2、堅持進行階段評審
統計結果顯示：大部分錯誤是在編碼之前造成的，大約占63%錯誤發現的越晚，改正它要付出的代價就越大，要差2到3個數量級。因此，軟件的質量保證工作不能等到編碼結束之後再進行，應堅持進行嚴格的階段評審，以便盡早發現錯誤。
3、實行嚴格的産品控制
開發人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要采用科學的産品控制技術來順應這種要求。也就是要采用變動控制，又叫基準配置管理。當需求變動時，其它各個階段的文檔或代碼随之相應變動，以保證軟件的一緻性。
4、采納現代程序設計技術
從六、七時年代的結構化軟件開發技術，到最近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經充分認識到：方法大似氣力。采用先進的技術即可以提高軟件開發的效率，又可以減少軟件維護的成本。
5、結果應能清楚地審查
軟件是一種看不見、摸不着的邏輯産品。軟件開發小組的工作進展情況可見性差，難于評價和管理。為更好地進行管理，應根據軟件開發的總目标及完成期限，盡量明确地規定開發小組的責任和産品标準，從而使所得到的标準能清楚地審查。
6、開發小組的人員應少而精
開發人員的素質和數量是影響軟件質量和開發效率的重要因素，應該少而精。這一條基于兩點原因：高素質開發人員的效率比低素質開發人員的效率要高幾倍到幾十倍，開發工作中犯的錯誤也要少的多；當開發小組為N人時，可能的通訊信道為N(N-1)/2，可見随着人數N的增大，通訊開銷将急劇增大。
7、承認不斷改進軟件工程實踐的必要性
遵從上述六條基本原理，就能夠較好地實現軟件的工程化生産。但是，它們隻是對現有的經驗的總結和歸納，并不能保證趕上技術不斷前進發展的步伐。因此，玻姆提出應把承認不斷改進軟件工程實踐的必要性作為軟件工程的第七條原理。根據這條原理，不僅要積極采納新的軟件開發技術，還要注意不斷總結經驗，收集進度和消耗等數據，進行出錯類型和問題報告統計。這些數據既可以用來評估新的軟件技術的效果，也可以用來指明必須着重注意的問題和應該優先進行研究的工具和技術。
方法學習
軟體工程的方法有很多方面的意義。包括專案管理，分析，設計，程序的編寫，測試和質量控制。
軟體設計方法可以區别為重量級的方法和輕量級的方法。重量級的方法中産生大量的正式文檔。
著名的重量級開發方法包括ISO9000，CMM，和統一軟體開發過程（RUP）。
輕量級的開發過過程沒有對大量正式文檔的要求。着名的輕量級開發方法包括極限編程（XP）和敏捷流程（AgileProcesses）。
根據《新方法學》這篇文章的說法，重量級方法呈現的是一種防禦型的姿态。在應用重量級方法的軟體組織中，由于軟體項目經理不參與或者很少參與程序設計，無法從細節上把握項目進度，因而會對項目産生恐懼感，不得不要求程式設計師不斷撰寫很多“軟體開發文檔”。而輕量級方法則呈現“進攻型”的姿态，這一點從XP方法特别強調的四個準則—“溝通、簡單、反饋和勇氣上有所體現。目前有一些人認為，重量級方法合于大型的軟體團隊（數十人以上）使用，而“輕量級方法”适合小型的軟體團隊（幾人、十幾人）使用。當然，關于重量級方法和輕量級方法的優劣存在很多争論，而各種方法也在不斷進化中。
一些方法論者認為人們在開發中應當嚴格遵循并且實施這些方法。但是一些人并不具有實施這些方法的條件。實際上，采用何種方法開發軟體取決于很多因素，同時受到環境的制約。
主要課程
外語、高等數學、線性代數、高等代數、電子技術基礎、離散數學、計算機引論（C語言）、數據結構、C++程序設計、彙編語言程序設計、算法設計與分析、計算機組成原理與體系結構、數據庫系統、計算機網絡、軟件工程、軟件測試技術、軟件需求與項目管理、軟件設計實例分析、CMM/ISO9000等。
發展方向
敏捷開發（Agile Development）被認為是軟體工程的一個重要的發展。它強調軟體開發應當是能夠對未來可能出現的變化和不确定性作出全面反應的。
敏捷開發被認為是一種“輕量級”的方法。在輕量級方法中最負盛名的應該是“極限編程”（Extreme Programming，簡稱為XP）。而與輕量級方法相對應的是“重量級方法”的存在。重量級方法強調以開發過程為中心，而不是以人為中心。重量級方法的例子比如CMM/PSP/TSP。
面向側面的程序設計（Aspect Oriented Programming，簡稱AOP）被認為是近年來軟體工程的另外一個重要發展。這裡的方面指的是完成一個功能的對象和函數的集合。在這一方面相關的内容有泛型編程（Generic Programming）和模闆。
需求分析
軟件工程中包含需求、設計、編碼和測試四個階段，其中需求工程是軟件工程第一個也是很重要的一個階段，本文以醫院管理系統為例詳細介紹了需求工程的構成和進行方法。
首先人們必須了解需求工程和其他項目過程的關系：
圖1需求與其他項目過程的關系
軟件需求包括三個不同的層次-業務需求、用戶需求和功能需求-也包括非功能需求：業務需說明了提供給客戶和産品開發商的新系統的最初利益，反映了組織機構或客戶對系統、産品高層次的目标要求，它們在項目視圖與範圍文檔中予以說明；用戶需求文檔描述了用戶使用産品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明；功能需求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。
需求開發
需求開發又分為需求獲取、需求分析、編寫規格說明書和需求驗證。以下列出和講解分析常規的步驟，當然應按照項目的大小和特點等實際情況我們應該自己确定合适的步驟。
1．需求獲取：
1）确定需求開發過程：确定需求開發過程确定如何組織需求的收集、分析、細化并核實的步驟，并将它編寫成文檔。對重要的步驟要給予一定指導，這将有助于分析人員的工作，而且也使收集需求活動的安排和進度計劃更容易進行。
2）編寫項目視圖和範圍文檔：項目視圖和範圍文檔應該包括高層的産品業務目标，所有的使用實例和功能需求都必須遵從能達到的業務需求。項目視圖說明使所有項目參與者對項目的目标能達成共識。而範圍則是作為評估需求或潛在特性的參考。
a、1背景在這一部分，總結新産品的理論基礎，并提供關于産品開發的曆史背景或形勢的一般性描述。
a、2業務機遇描述現存的市場機遇或正在解決的業務問題。描述商品競争的市場和信息系統将運用的環境。包括對現存産品的一個簡要的相對評價和解決方案，并指出所建議的産品為什麼具有吸引力和它們所能帶來的競争優勢。
a、3業務目标用一個定量和可測量的合理方法總結産品所帶來的重要商業利潤，把重點放在給業務的價值上。
a、4客戶或市場需求描述一些典型客戶的需求，包括不滿足現有市場上的産品或信息系統的需求。提出客戶目前所遇到的問題在新産品中将可能（或不可能）出現的闡述，提供客戶怎樣使用産品的例子。确定了産品所能運行的軟、硬件平台。
a、5提供給客戶的價值确定産品給客戶帶來的價值，并指明産品怎樣滿足客戶的需要。
a、6業務風險總結開發（或不開發）該産品有關的主要業務風險，例如市場競争、時間問題、用戶的接受能力、實現的問題或對業務可能帶來的消極影響。預測風險的嚴重性，指明你所能采取的減輕風險的措施。
b.1項目視圖陳述編寫一個總結長遠目标和有關開發新産品目的的簡要項目視圖陳述。項目視圖陳述将考慮權衡有不同需求客戶的看法。它可能有點理想化，但必須以現有的或所期待的客戶市場、企業框架、組織的戰略方向和資源局限性為基礎。
b.2主要特性包括新産品将提供的主要特性和用戶性能的列表。強調的是區别于以往産品和競争産品的特性。可以從用戶需求和功能需求中得到這些特性。
b.3假設和依賴環境在構思項目和編寫項目視圖和範圍文檔時，要記錄所作出的任何假設。通常一方所持的假設應與另一方不同。
c.1首次發行的範圍總結首次發行的産品所具有的性能。描述了産品的質量特性，這些特性使産品可以為不同的客戶群提供預期的成果。c.2随後發行的範圍如果你想象一個周期性的産品演變過程，就要指明哪一個主要特性的開發将被延期，并期待随後版本發行的日期。
c.3局限性和專用性明确定義包括和不包括的特性和功能的界線是處理範圍設定和客戶期望的一個途徑。列出風險承擔者們期望的而你卻不打算把它包括到産品中的特性和功能。
d.1客戶概貌客戶概述明确了這一産品的不同類型客戶的一些本質的特點，以及目标市場部門和在這些部門中的不同客戶的特征。
d.2項目的優先級一旦明确建立項目的優先級，風險承擔者和項目的參與者就能把精力集中在一系列共同的目标上。達到這一目的的一個途徑是考慮軟件項目的五個方面：性能、質量、計劃、成本和人員。e.産品成功的因素明确産品的成功是如何定義和測量的，并指明對産品的成功有巨大影響的幾個因素。不僅要包括組織直接控制的範圍内的事務，還要包括外部因素。如果可能，可建立測量的标準用于評價是否達到業務目标.
3）用戶群分類：産品的用戶在很多方面存在着差異，例如：用戶使用産品的頻度、他們的應用領域和計算機系統知識、他們所使用的産品特性、他們所進行的業務過程、他們在地理上的布局以及他們的訪問優先級。根據這些差異，你可以把這些不同的用戶分成小組。用戶類不一定都指人，你可以把其它應用程序或系統接口所用的硬件組件也看成是附加用戶類的成員。以這種方式來看待應用程序接口，可以幫助你确定産品中那些與外部應用程序或組件有關的需求。将用戶群分類并歸納各自特點為避免出現疏忽某一用戶群需求的情況，要将可能使都有所差異。詳細描述出它們的個性特點及任務狀況，将有助于産品設計。
4）選擇産品代表：擇每類用戶的産品代表為每類用戶至少選擇一位能真正代表他們需求的人作為那一類用戶的代表并能作出決策。這對于内部信息系統的開發是最易實現的，因為此時，用戶就是身邊的職員。而對于商業開發，就得在主要的客戶或測試者中建立起良好的合作關系，并确定合适的産品代表。他們必須一直參與項目的開發而且有權作出決策。每一個産品代表者代表了一個特定的用戶類，并在那個用戶類和開發者之間充當主要的接口。
5）建立核心隊伍：建立起典型用戶的核心隊伍把同類産品或産品的先前版本用戶代表召集起來，從他們那裡收集目前産品的功能需求和非功能需求。這樣的核心隊伍對于商業開發尤為有用，因為你擁有一個龐大且多樣的客戶基礎。與産品代表的區别在于，核心隊伍成員通常沒有決定權。
6）确定使用實例：讓用戶代表确定使用實例從用戶代表處收集他們使用軟件完成所需任務的描述-使用實例，讨論用戶與系統間的交互方式和對話要求。在編寫使用實例的文檔時可采用标準模版，在使用實例基礎上可得到功能需求。
一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和交互順序。因此，一個使用實例是相關的用法說明的集合，并且一個說明是使用實例的例子。在描述時列出執行者和系統之間相互交互或對話的順序。當這種對話結束時，執行者也達到了預期的目的。
對于一些複雜的使用實例，畫出圖形分析模型是有益的，這些模型包括數據流程圖、實體關系圖、狀态轉化圖、對象類和聯系圖。
使用實例的描述并不向開發者提供他們所要開發的功能的細節。為了減少這種不确定性，需要把每一個使用實例叙述成詳細的功能需求。每一個使用實例可引伸出多個功能需求，這将使執行者可以執行相關的任務；并且多個使用實例可能需要相同的功能需求。使用實例方法給需求獲取帶來的好處來自于該方法是以任務為中心和以用戶為中心的觀點。比起使用以功能為中心的方法，使用實例方法可以使用戶更清楚地認識到新系統允許他們做什麼。
每一個使用實例都描述了一個方法，用戶可以利用這個方法與系統進行交互，從而達到特定的目标。使用實例可有效地捕捉大多數所期望的系統行為，但是你可能有一些需求，這些需求與用戶任務或其他執行者之間的交互沒有特定的關系。這時你就需要一個獨立的需求規格說明。
7）召開應用程序開發聯系會議：召開應用程序開發聯系會議應用程序開發聯系會議是範圍廣的、簡便的專題讨論會，也是分析人員與客戶代表之間一種很好的合作辦法，并能由此拟出需求文檔的底稿。該會議通過緊密而集中的讨論得以将客戶與開發人員間的合作夥伴關系付諸于實踐。
8）分析用戶工作流程：分析用戶工作流程觀察用戶執行業務任務的過程。畫一張簡單的示意圖（最好用數據流圖）來描繪出用戶什麼時候獲得什麼數據，并怎樣使用這些數據。編制業務過程流程文檔将有助于明确産品的使用實例和功能需求。你甚至可能發現客戶并不真地需要一個全新的軟件系統就能達到他們的業務目标。
9）确定質量屬性：确定質量屬性和其它非功能需求在功能需求之外再考慮一下非功能的質量特點，這會使你的産品達到并超過客戶的期望。對系統如何能很好地執行某些行為或讓用戶采取某一措施的陳述就是質量屬性，這是一種非功能需求。聽取那些描述合理特性的意見：快捷、簡易、直覺性、用戶友好、健壯性、可靠性、安全性和高效性。你将要和用戶一起商讨精确定義他們模糊的和主觀言辭的真正含義。
10）檢查問題報告：通過檢查當前系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新産品或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息。
11）需求重用：跨項目重用需求如果客戶要求的功能與已有的産品很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。
軟件需求
軟件需求包括3個不同的層次――業務需求、用戶需求和功能需求。除此之外，每個系統還有各種非功能需求。
業務需求（Business requirement）表示組織或客戶高層次的目标。業務需求通常來自項目投資人、購買産品的客戶、實際用戶的管理者、市場營銷部門或産品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目标。使用前景和範圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。
用戶需求（user requirement）描述的是用戶的目标，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什麼。
功能需求（functional requirement）規定開發人員必須在産品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定”。功能需求描述是開發人員需要實現什麼。
系統需求（system requirement）用于描述包含多個子系統的産品（即系統）的頂級需求。系統可以隻包含軟件系統，也可以既包含軟件又包含硬件子系
軟件工程專業學生就業前景
作為“朝陽行業”，軟件行業的發展雖然受到全球金融危機的影響，但是從目前的形勢來看，軟件工程專業在未來多年内仍将是就業形勢看好的專業。09年就業調查顯示，軟件工程就業率及就業工資水平均居高校各專業前列。這主要源自于軟件行業的快速發展和政府經濟結構調整而對軟件人才的迫切需求，據估計，我國目前存在着80萬的軟件人才缺口，而對軟件人才的需求也以每年20%的速度遞增。
目前我國的軟件行業規模不是很大，有些軟件企業在軟件制作上，也隻是采用了一些軟件工程的思想，距離大規模的工業化大生産比較還是有一定的差距；原因有管理體制的問題，市場問題，政策問題，也有軟件工程理論不全面和不完善的問題。所以軟件工程的研究和應用，以及我國軟件行業的進一步發展，都需要一定的既有軟件工程的理論基礎和研究能力，又有一定的實踐經驗的軟件工程科學技術人員來推動。軟件工程的前途是光明的。
鑒于目前我國軟件行業仍然處于發展的初期階段，而又是國家未來發展的方向，預計未來幾年裡，我國軟件教育和軟件培訓市場依然很大，這也從一個側面說明軟件行業對人才的巨大需求。軟件工程人才的就業前景十分看好。未來幾年，國内外高層次軟件人才将供不應求。畢業生主要在各大軟件公司、企事業單位、高等院校、各大研究所、國防等重要部門從事軟件設計、開發、應用與研究工作。有數據表明，我國軟件出口規模達到215億元，軟件從業人員達到72萬人，在中國十大IT職場人氣職位中，軟件工程師位列第一位，軟件工程人才的就業前景十分樂觀。
