發展歷程
軟體需求需求工程是隨著計算機的發展而發展的，在計算機發展的初期，軟體規模不大，軟體開發所關注的是代碼編寫，需求分析很少受到重視。後來軟體開發引入了生命周期的概念，需求分析成為其第一階段。隨著軟體系統規模的擴大，需求分析與定義在整個軟體開發與維護過程中越來越重要，直接關係到軟體的成功與否。人們逐漸認識到需求分析活動不再僅限於軟體開發的最初階段，它貫穿於系統開發的整個生命周期。80年代中期，形成了軟體工程的子領域——需求工程(requirement engineering, RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《Requirements Engineering》。一些關於需求工程的工作小組也相繼成立，如歐洲的RENOIR(Requirements Engineering Network of International Cooperating Research Groups )，並開始開展工作。
需求層次
軟體需求包括三個不同的層次—業務需求、用戶需求和功能需求—也包括非功能需求。業務需求( business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與範圍文檔中予以說明。用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用實例(use case)文檔或方案腳本(scenario)說明中予以說明。功能需求(functional requirement)定義了開發人員必須實現的軟體功能，使得用戶能完成他們的任務，從而滿足了業務需求。所謂特性(feature)是指邏輯上相關的功能需求的集合，給用戶提供處理能力並滿足業務需求。軟體需求各組成部分之間的關係如圖所示。
作為補充，軟體需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規範和契約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟體產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對用戶和開發人員都極為重要。 值得注意的一點是，需求並未包括設計細節、實現細節、項目計畫信息或測試信息。需求與這些沒有關係，它關注的是充分說明你究竟想開發什麼。
Frederick Brooks在他1987年的經典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分說明了需求過程在軟體項目中扮演的重要角色：
開發軟體系統最為困難的部分就是準確說明開發什麼。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟體系統的接口。如果前期需求分析不透徹，一旦做錯，將最終會給系統帶來極大損害的部分，並且以後再對它進行修改也極為困難，容易導致項目失敗。
過程標準
NASA的軟體開發過程中的概念中軟體需求過程的標準是：清楚(Clear)、完整(Complete)、一致(Consistent)、可測試(Testable)，此外還有其他的概念，如可跟蹤的、可修改的等等。
分析方法
軟體需求分析方法大體分為如下四類：結構化方法、面向對象方法、面向控制方法和面向數據方法。限於篇幅，將主要從結構化方法和面向對象方法以及RUP三個方面進行簡要的探討。
結構化分析方法
結構化分折(Structured Analysis,SA)方法是一種單純的由頂向下逐步求精的功能分解方法。分析員首先用上下文圖表(稱為數據流圖DFD)表示系統的所有輸入/輸出，然後反覆地對系統求精，每次求精都表示成一更詳細的DFD從而建立關於系統的一個DFD層次。為保存DFD中的這些信息，使用數據字典來存取相關的定義、結構及目的。SA方法是目前實際套用效力廣泛的需求工程技術。它具有較好的分別、抽象能力，為開發小組找到了一種中間語言，易於軟體人員所掌握。但它離套用領域尚有一定的距離，難以直接套用領域術民與軟體設計也有一段不小的距離因而為開發小組的思想交流帶來了一定的困難。
面向對象分析方法
面向對象（Object Oriented,OO）的方法把分析建立在系統對象以及對象間互動的基礎之上，使得我們能以3個最基本的方法框架——對象及其屬性、分類結構和集合結構來定義和溝通需求。面向對象的問題分析模型從3個側面進行描述，即對象模型(對象的靜態結構)、動態模型(對象相互作用的順序)和功能模型(數據變換及功能依存關係)。需求工程的抽象原則、層次原則和分割原則同樣適用於面向對象方法，即對象抽象與功能抽象原則是一樣的，也是從高級到低級、從邏輯到物理，逐級細分．每一級抽象都重複對象建模(對象識別)一動態建模(事件識別)一功能建模(操作識別)的過程，直到每一個對象實例在物理(程式編碼)上全部實現為止。
面向對象需求分析(OORA)利用一些基本概念來建立相應模型，以表達目標系統的不同側面。儘管不同的方法所採用的具體模型不盡相同，但都無外乎用如下五個基本模型來描述軟體需求：
整體—部分模型：該模型描述對象(類)是如何由簡單的對象（類）構成的。將一個複雜對象(類)描述成一個由互動作用的若干對象(類)構成的結構的能力是OO途徑的突出優點。該模型亦稱聚合模型。
分類模型：分類模型描述類之間的繼承關係。與聚合關係不同，它說明的是一個類可以繼承另一個或另一些類的成分，以實現類中成分的復用。
類—對象模型：分析過程必須描述屬於每個類的對象所具有的行為，這種行為描述的詳細程度可以根據具體情況而定。既可以只說明行為的輸入、輸出和功能，也可以採用比較形式的途徑來精確地描述其輸入、輸出及其相應的類型甚至使用偽碼或小說明的形式來詳細刻畫。
對象互動模型：一個面向對象的系統模型必須描述其中對象的互動方法。如前所述，對象互動是通過訊息傳遞來實現的。事實人對象互動也可看作是對象行為之間的引用關係。因此，對象互動模型就要刻畫對象之間的訊息流。對應於不同的詳細程度，有不同的訊息流描述分析，分析人員應根據具體館況而選擇。一般地，一個詳細的對象互動模型能夠說明對象之間的訊息及其流向，並且同時說明該訊息將激活的對象及行為。一個不太詳細的對象互動模型可以只說明對象之間有訊息，並指明其流向即可。還有一種狀況就是介於此兩者之間。
狀態模型：在狀態模型中，把一個對象看作是一個有限狀態機，由一個狀態到另一狀態的轉變稱作狀態轉換。狀態模型將對象的行為描述成其不同狀態之間的通路。它也可以刻畫動態系統中對象的創建和廢除，並稱由對象的創建到對象的廢除狀態之間的退路為對象的生存期。
狀態模型既可以用狀態轉換因的圖形化手段，又可用決策表或稱決策矩陣的形式來表。
基於RUP的軟體需求
RUP（RationalUnified Process）是Rational公司開發和維護的過程產品。RUP是工程化的軟體開發過程，它提供了在開發機構中分派任務和責任的紀律化方法。RUP不僅僅是一個簡單的過程，而是一個通用的過程框架，可用於各種不同類型的軟體系統、各種不同的套用領域、各種不同類型的組織、各種不同的功能級別以及各種不同的項目規模。RUP的突出特點可以由以下三個關鍵字來體現——用例驅動、以構架為中心、疊代和增量的。這些是RUP所特有的，也是同等重要的。構架提供了一種結構來指導疊代過程中的工作，而用例則確定了目標井驅動每次疊代的工作。
進行需求分析的基礎是要獲得用戶的需要，為了完成這一工作，必須建立業務模型，通過描述業務規則、業務邏輯，明確業務過程並對其進行規範、最佳化。對於一個系統，在建立業務模型時，應從3個方面來描述其特性：功能、行為、數據，對應於這些特性。
軟體需求方法的比較分析
基於上述分析可知，結構化分析方法與面向對象分析方法的區別主要體現在兩個方面：
* 將系統分解成於系統的方式不同。前者將系統描述成一組互動作用的處理，後者則描述成一組互動作用的對象。
*子系統之間的互動關係的描述方式不一樣。前者加工之間的互動是通過不太精確的數據流來表示的，而後者對象之間通過訊息傳遞互動關係。
因此，面向對象軟體需求分析的結果能更好地刻畫現實世界，處理複雜問題，對象比過程更具有穩定性，便於維護與復用。
