軟件需求

80年代中期，形成了軟件工程子領域——需求工程(requirement engineering, RE)。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，一些關於需求工程的工作小組相繼成立。需求工程是隨着計算機的發展而發展的，在計算機發展的初期，軟件規模不大，軟件開發所關注的是代碼編寫，需求分析很少受到重視。後來軟件開發引入了生命週期的概念，需求分析成為其第一階段。隨着軟件系統規模的擴大，需求分析與定義在整個軟件開發與維護過程中越來越重要，直接關係到軟件的成功與否。人們逐漸認識到需求分析活動不再僅限於軟件開發的最初階段，它貫穿於系統開發的整個生命週期。

進入90年代以來，需求工程成為研究的熱點之一。一些關於需求工程的工作小組也相繼成立，如歐洲的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（Rational Unified Process）是Rational公司開發和維護的過程產品。RUP是工程化的軟件開發過程，它提供了在開發機構中分派任務和責任的紀律化方法。RUP不僅僅是一個簡單的過程，而是一個通用的過程框架，可用於各種不同類型的軟件系統、各種不同的應用領域、各種不同類型的組織、各種不同的功能級別以及各種不同的項目規模。RUP的突出特點可以由以下三個關鍵詞來體現——用例驅動、以構架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構架提供了一種結構來指導迭代過程中的工作，而用例則確定了目標井驅動每次迭代的工作。

進行需求分析的基礎是要獲得用户的需要，為了完成這一工作，必須建立業務模型，通過描述業務規則、業務邏輯，明確業務過程並對其進行規範、優化。對於一個系統，在建立業務模型時，應從3個方面來描述其特性：功能、行為、數據，對應於這些特性。

基於上述分析可知，結構化分析方法與面向對象分析方法的區別主要體現在兩個方面：

* 將系統分解成於系統的方式不同。前者將系統描述成一組交互作用的處理，後者則描述成一組交互作用的對象。

* 子系統之間的交互關係的描述方式不一樣。前者加工之間的交互是通過不太精確的數據流來表示的，而後者對象之間通過消息傳遞交互關係。

因此，面向對象軟件需求分析的結果能更好地刻畫現實世界，處理複雜問題，對象比過程更具有穩定性，便於維護與複用。