學習：軟體需求說明書

 

 

軟體需求是       (1)使用者解決問題或達到目標所需的條件或權能(Capability)。       (2)系統或系統組件要滿足合約、標準、規範或其它正式規定文檔所需具有的條件或權能。       (3)一種反映上面(1)或(2)所描述的條件或權能的文檔說明。              （IEEE軟體工程標準詞彙表(1997年)中定義） 一、軟體需求的發展       需求工程是隨著電腦的發展而發展的，在電腦發展的初期，軟體規模不大，軟體開發所關注的是代碼編寫，需求分析很少受到重視。後來軟體開發引入了生命週期的概念，需求分析成為其第一階段。隨著軟體系統規模的擴大，需求分析與定義在整個軟體開發與維護過程中越來越重要，直接關係到軟體的成功與否。人們逐漸認識到需求分析活動不再僅限於軟體開發的最初階段，它貫穿於系統開發的整個生命週期。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 ”中充分說明了需求過程在軟體項目中扮演的重要角色： 　　開發軟體系統最為困難的部分就是準確說明開發什麼。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向使用者、面向機器和其它軟體系統的介面。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，並且以後再對它進行修改也極為困難。 　　為什麼這麼說呢，因為在大多數的軟體系統中，終端使用者可能都不清楚他的需求是什麼，這是千真萬確的。如果你的使用者告訴你需求就是這些了，不要相信他，繼續刨根問底，直到你們都筋疲力盡了。 　　雖然聽上去有些不可思議，但這是教訓之談，在我從事的項目之中，沒有一個使用者在軟體接近完成的時候打電話對我說，我看了你們的軟體，我想我必須改動一些地方。在那些日子中，我甚至得了一種電話鈴音恐懼症。 三、需求風險 　　下面列出了在做需求分析時一些很危險的做法，如果你發現你的一些做法與之相似，那麼，給自己一些時間，好好思考一下，這些做法會對你的軟體產生致命的影響。 　　1. 無足夠使用者參與 　　客戶經常不明白為什麼收集需求和確保需求品質需花費那麼多功夫，開發人員可能也不重視使用者的參與。究其原因：一是因為與使用者合作不如編寫代碼有意思；二是因為開發人員覺得已經明白使用者的需求了。在某些情況下，與實際使用產品的使用者直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應讓具有代表性的使用者在項目早期直接參与到開發隊伍中，並一同經曆整個開發過程。 最重要的就是使用者必須要重視他的軟體，必須讓他明白：如果失敗，他的損失最大(當然你的損失也不小，但這時候你必須讓他重視這項工作)。如果使用者不夠重視，想辦法解決，否則你就不用再繼續了。 　　2. 使用者需求的不斷增加 　　在開發中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算範圍。這使得問題更難解決。實際上，問題根源在於使用者需求的改變和開發人員對新需求所作的修改。要想把需求變更範圍控制到最小，必須一開始就對項目視圖、範圍、目標、約束限制和成功標準給予明確說明，並將此說明作為評價需求變更和新特性的參照架構。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助於所有風險承擔者明白業務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折中。 　　產品開發中不斷延續的變更會使其整體結構日漸紊亂，補丁代碼也使得整個程式難以理解和維護。插入補丁代碼使模組違背強內聚、松耦合的設計原則，特別是如果項目組態管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你儘早地區別這些可能帶來變更的特性，你就能開發一個更為健壯的結構，並能更好地適應它。這樣設計階段需求變更不會直接導致補丁代碼，同時也有利於減少因變更導致品質的下降。 　　最糟糕的莫過於使用者覺得如果不再加點什麼功能就對不起自己。我曾經看過一個資料倉儲的一期工程，在設計階段沒有很好的定義範圍，當我向專案管理者提出這個問題的時候，他認為都已經說好了，合約上也寫清楚了，並沒有加以重視。可是最後，使用者提出的修改意見已經遠遠超出了範圍，項目時間也延長了一倍。整個的項目群組成員疲憊不堪，可是卻不斷的接到使用者投訴說項目失敗。 　　3. 模稜兩可的需求 　　模稜兩可是需求規格說明中最為可怕的問題(Lawrence 1996)。它的一層含義是指諸多讀者對需求說明產生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。 　　模稜兩可的需求會使不同的風險承擔者產生不同的期望，它會使開發人員為錯誤問題而浪費時間，並且使測試者與開發人員所期望的不一致。一位系統測試人員曾告訴我，她所在的測試組經常對需求理解有誤，以致不得不重寫許多測試案例並重做許多測試。 　　模稜兩可的需求帶來不可避免的後果便是返工—重做一些你認為已做好的事情。返工會耗費開發總費用的40%，而70%～85%的重做是由於需求方面的錯誤所導致的(leffingwell 1997)。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發出產品，在同樣的時間內開發更多、更好的產品，甚至能偶爾回家休息休息。 　　處理模稜兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模稜兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正瞭解需求文檔，這樣二義性就不會直到項目後期才被發現，那時再發現的話會使得更正代價很大。 　　4. 不必要的特性 　　“畫蛇添足”是指開發人員力圖增加一些“使用者欣賞”但需求規格說明中並未涉及的新功能。經常發生的情況是使用者並不認為這些功能性很有用，以致在其上耗費的努力“白搭”了。 　　開發人員應當為客戶構思方案並為他們提供一些具有創新意識的思路，具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡，開發人員應努力使功能簡單易用，而不要未經客戶同意，擅自脫離客戶要求，自作主張。 　　同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實用價值的功能，而實現這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小，應確信：你明白為什麼要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使使用者完成他們業務任務的核心功能。 　　時刻記住：軟體成功的標準是是否解決使用者的問題，而不是它有多Cool的功能。 　　5. 過於精簡的規格說明 　　有時，客戶並不明白需求分析有如此重要，於是只作一份簡略之至的規格說明，僅涉及了產品概念上的內容，然後讓開發人員在項目進展中去完善，結果很可能出現的是開發人員先建立產品的結構之後再完成需求說明。這種方法可能適合於尖端研究性的產品或需求本身就十分靈活的情況(McConnell 1996)，不過商業應用大多都不是這種情況。在大多數情況下，這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作)，也會給客戶帶來煩惱(他們無法得到他們所設想的產品)。 　　6. 忽略了使用者分類 　　大多數產品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經驗水平也不盡相同。如果你不能在項目早期就針對所有這些主要使用者進行分類的話，必然導致有的使用者對產品感到失望。例如，菜單驅動操作對進階使用者太低效了，但含義不清的命令和快速鍵又會使不熟練的使用者感到困難。 　　7. 不準確的計劃 　　“上述是我對新產品的看法，好，現在你能告訴我你什麼時候能完成嗎？”許多開發人員都遇到這種難題。對需求分析缺乏理解會導致過分樂觀的估計，而當不可避免的超支發生時，會帶來頗多麻煩。據報道，導致需求過程中軟體成本估計極不準確的原因主要有以下五點：頻繁的需求變更、遺漏的需求、與使用者交流不夠、品質低下的需求規格說明和不完善的需求分析(Davis 1995)。 　　對不準確的要求所提問題的正確響應是“等我真正明白你的需求時，我就會來告訴你”。基於不充分資訊和未經深思的對需求不成熟的估計很容易為一些因素左右。要作出估計時，最好還是給出一個範圍(如最好的情況下，很可能的，最壞情況下)或一個可信賴的程度(我有9 0 %的把握，我能在8周內完成)。未經準備的估計通常是作為一種猜測給出的，聽者卻認為是一種承諾。因此我們要儘力給出可達到的目標並堅持完成它。 四、什麼是優秀的需求 　　討論軟體需求的文章有很多，對於需求的標準也不盡相同，這裡我想用NASA的軟體開發過程中的概念，軟體需求過程的標準是：清楚(Clear)、完整(Complete)、一致(Consistent)、可測試(Testable)，此外還有其他的概念，如可跟蹤的、可修改的等等。 　　清楚：目前大多數的需求分析採用的仍然是自然語言（因為如果採用形式化語言的話，和使用者的溝通將成為一個大問題，這意味著客戶在開發軟體之前必須先進行形式化語言培訓，這是不現實的）。自然語言對需求分析最大的弊病就是它的二義性。所以我們不得不對需求分析中採用的語言做某些限制。例如盡量採用主語＋動作的簡單表達方式。說白了，需求分析中的描述讓人看上去像是剛學習寫作的小孩子就對了，千萬不要採用疑問句、修飾這些華麗的表達方式。 　　除了語言的二義性之外，主意不要使用行話，就是電腦術語。需求分析最重要的是和使用者溝通，可是使用者多半不是電腦的專業人士，如果在需求分析中使用了行話，就會造成使用者理解上的困難。 　　打個比方，如果你要做一個銀行的信用卡系統，你就可以這樣描述軟體需求：銀行的卡部管理信用卡，每張信用卡只屬於一個帳戶。信用卡有卡號、餘額。一張信用卡有多筆的交易記錄。 　　完整：再也沒有什麼比軟體開發接近完成是發現遺漏了一項需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遺漏需求而不得不返工，這簡直就是惡夢。可是令人遺憾的是，需求的遺漏是很經常發生的事情，不僅僅是你的問題，更多的問題發生在使用者那裡，他們不知道該做些什麼。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各方各面，貫穿了整個過程，從最初的計劃制定到最後的需求評審。至於完整性的詳細討論，我們會在下面的章節中討論，現在你只需要拚命的想象缺乏完整性的壞處，直到你出了一身的冷汗。出了嗎？好，那我們繼續。 　　一致：一致性也是一個比較大的概念，很難用幾句話講清楚。還記得我們在開始的時候提到的需求的層次嗎？簡單的來說，就是使用者需求必須和業務需求一致，功能需求必須和使用者需求一致。嚴格的遵守不同層次間的一致性關係，就可以保證最後開發出來的軟體系統不會偏離最初的實現目標。在實現過程中，我們還必須把一致性關係細化。比如說使用者需求不能超出先前指定的範圍。 　　可測試：大家覺得一個項目的測試從什麼時候開始呢？有人說從編碼完成後開始。更清楚一點的說是編碼的時候同時進行單元測試，編碼完成後進行系統測試。這些都沒有錯。但是實際上測試是從需求分析過程就開始了。需求分析是測試計劃的輸入和參照。這就要求需求分析是可測試的。什麼是可測試呢？“我們要用新的系統完成報表自動化處理”，你覺得這個需求是可測試的嗎？當然不是，報表包括哪些？自動化處理的標準是什嗎？這些在需求中都沒有說明。因此這項需求是無法測試的，就是不具有可測試性。說到這裡，大家可能就會明白之前的需求的幾項標準都是為了保證需求的可測試性的。事實就是這樣，只有系統的所有需求是可以被測試的，才能夠保證軟體始終圍繞著使用者的需要，保證軟體系統是成功的。 五、軟體需求過程       軟體需求工程主要包括兩個方面：需求開發和需求管理。       需求開發可進一步分為：需求萃取、需求分析、編寫需求規格和需求驗證四個階段。各階段說明如下：       需求萃取階段：       這一階段的核心任務就是確定三個層次的需求，對於業務層要強調明確業務總目標及使用範圍，對於使用者層，要強調明晰使用者工作流程，對於功能層還要收集系統運行環境的限制等非功能性需求。不同的時間、不同的使用者會由於不同的營運目標及使用範圍而提出不盡相同的需求，同時由於沒有約定提出方式也會有各不相同的表現形式。針對上述問題，首先要確定使用者代表並對其在需求中的主次地位於以劃分；其次要確定需求的整個開發過程，最後還要明確不同層次的需求要以約定的形式出具文檔，以備雙方的交流及問題檢查。       需求分析階段：       這一階段的核心任務就是確定並完善需求。初期階段所獲得的大量需求往往是不系統、不完整甚至個別需求是錯誤的、不必要的，只有通過提煉、分析和仔細審查需求，彼此溝通，採用適當的表現形式，比如繪製營運目標關聯圖、繪製功能結構、編製資料字典、編寫使用者執行個體等，明白需求含義並找出其中的錯誤、遺漏或不足的地方，尤其是應採用特定符號標識需求優先順序。       編寫需求規格階段：       這一階段的任務強調將已收集並做分析處理的需求經編製整理形成正常化的可視文檔，即軟體需求規格說明書。       需求驗證階段。       本階段是需求開發工作的最後階段，要確定在第三階段所編製的需求文檔是否與預期結果一致，是否符合高品質需求的評價標準。這項工作可以通過評審來完成。評審可以根據使用者代表的個人偏好、習慣予以審查需求，也可以遵循行業品質控制辦法制定嚴格的步驟進行審查，這主要取決於項目的大小、需求及各個部分的重要程度。       需求管理需要"建立並維護在軟體工程中同客戶達成的契約"。這種契約都包含在編寫的需求規格說明與模型中。客戶的接受僅是需求成功的一半，開發人員也必須能夠接受他們，並真正把需求應用到產品中。       通常的需求管理活動包括：           定義需求基準(迅速制定需求文檔的主體)。           評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。           以一種可控制的方式將需求變更融入到項目中。           使當前的專案計劃與需求一致。           估計變更需求所產生影響並在此基礎上協商新的承諾(約定)。           讓每項需求都能與其對應的設計、原始碼和測試案例聯絡起來以實現跟蹤。           在整個項目過程中跟蹤需求狀態從其變更情況。 六、軟體需求方法       軟體需求分析方法大體分為如下四類：結構化方法、物件導向方法、面向控制方法和面向資料方法。限於篇幅，本文將主要從結構化方法和物件導向方法以及RUP三個方面進行簡要的探討。 1、結構化分析方法       結構化分折(Structured Analysis, SA)方法是一種單純的由頂向下逐步求精的功能分解方法。分析員首先用上下文圖表(稱為資料流圖DFD)表示系統的所有輸入／輸出，然後反覆地對系統求精，每次求精都表示成一更詳細的DFD從而建立關於系統的一個DFD層次。為儲存DFD中的這些資訊，使用資料字典來存取相關的定義、結構及目的。SA方法是目前實際應用效力廣泛的需求工程技術。它具有較好的分別、抽象能力，為開發小組找到了一種中繼語言，易於軟體人員所掌握。但它離應用領域尚有一定的距離，難以直接應用領域術民與軟體設計也有一段不小的距離因而為開發小組的思想交流帶來了一定的困難。 2、物件導向分析方法       物件導向（Object Oriented, OO）的方法把分析建立在系統對象以及對象間互動的基礎之上，使得我們能以3個最基本的方法架構——對象及其屬性、分類結構和集合結構來定義和溝通需求。物件導向的問題分析模型從3個側面進行描述，即物件模型(對象的靜態結構)、動態模型(對象相互作用的順序)和功能模型(資料變換及功能依存關係)。需求工程的抽象原則、層次原則和分割原則同樣適用於物件導向方法，即對象抽象與功能抽象原則是一樣的，也是從進階到低級、從邏輯到物理，逐級細分．每一級抽象都重複對象建模(對象識別)一動態建模(事件識別)一功能建模(操作識別)的過程，直到每一個對象執行個體在物理(程式編碼)上全部實現為止。       物件導向需求分析(OORA)利用一些基本概念來建立相應模型，以表達目標系統的不同側面。儘管不同的方法所採用的具體模型不盡相同，但都無外乎用如下五個基本模型來描述軟體需求:       整體—部分模型：該模型描述對象(類)是如何由簡單的對象（類）構成的。將一個複雜物件(類)描述成一個由互動作用的若干對象(類)構成的結構的能力是OO途徑的突出優點。該模型亦稱彙總模型。       分類模型：分類模型描述類之間的繼承關係。與彙總關係不同，它說明的是一個類可以繼承另一個或另一些類的成分，以實作類別中成分的複用。       類—物件模型：分析過程必須描述屬於每個類的對象所具有的行為，這種行為描述的詳細程度可以根據具體情況而定。既可以只說明行為的輸入、輸出和功能，也可以採用比較形式的途徑來精確地描述其輸入、輸出及其相應的類型甚至使用偽碼或小說明的形式來詳細刻畫。       對象互動模型：一個物件導向的系統模型必須描述其中對象的互動方法。如前所述，對象互動是通過訊息傳遞來實現的。事實人對象互動也可看作是對象行為之間的參考關聯性。因此，對象互動模型就要刻畫對象之間的訊息流程。對應於不同的詳細程度，有不同的訊息流程描述分析，分析人員應根據具體館況而選擇。一般地，一個詳細的對象互動模型能夠說明對象之間的訊息及其流向，並且同時說明該訊息將啟用的對象及行為。一個不太詳細的對象互動模型可以只說明對象之間有訊息，並指明其流向即可。還有一種狀況就是介於此兩者之間。        狀態模型：在狀態模型中，把一個對象看作是一個有限狀態機器，由一個狀態到另一狀態的轉變稱作狀態轉換。狀態模型將對象的行為描述成其不同狀態之間的通路。它也可以刻畫動態系統中對象的建立和廢除，並稱由對象的建立到對象的廢除狀態之間的退路為對象的生存期。        狀態模型既可以用狀態轉換因的圖形化手段，又可用決策表或稱決策矩陣的形式來表。 3、基於RUP的軟體需求       RUP（Rational Unified Process）是Rational公司開發和維護的過程產品。RUP是工程化的軟體開發過程，它提供了在開發機構中指派任務和責任的紀律化方法。RUP不僅僅是一個簡單的過程，而是一個通用的過程架構，可用於各種不同類型的軟體系統、各種不同的應用領域、各種不同類型的組織、各種不同的功能層級以及各種不同的項目規模。RUP的突出特點可以由以下三個關鍵詞來體現——用例驅動、以構架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構架提供了一種結構來指導迭代過程中的工作，而用例則確定了目標井驅動每次迭代的工作。       進行需求分析的基礎是要獲得使用者的需要，為了完成這一工作，必須建立業務模型，通過描述商務規則、商務邏輯，明確業務過程並對其進行規範、最佳化。對於一個系統，在建立業務模型時，應從3個方面來描述其特性：功能、行為、資料，對應於這些特性。 4、軟體需求方法的比較分析       基於上述分析可知，結構化分析方法與物件導向分析方法的區別主要體現在兩個方面：       * 將系統分解成於系統的方式不同。前者將系統描述成一組互動作用的處理，後者則描述成一組互動作用的對象。       * 子系統之間的互動關係的描述方式不一樣。前者加工之間的互動是通過不太精確的資料流來表示的，而後者對象之間通過訊息傳遞互動關係。       因此，物件導向軟體需求分析的結果能更好地刻畫現實世界，處理複雜問題，對象比過程更具有穩定性，便於維護與複用。 （出處:UML軟體工程，部落格中國） 七、軟體需求說明書 　　軟體需求說明書的編製是為了使使用者和軟體開發人員雙方對該軟體的初始規定有一個共同的理解， 使之成為整個開發工作的基礎。編製軟體需求說明書的內容要求如下： 　　1　引言 　　1．1編寫目的 　　說明編寫這份軟體需求說明書的目的，指出預期的讀者。 　　1．2背景 　　說明： 　　a．待開發的軟體系統的名稱； 　　b．本項目的任務提出者、開發人員、使用者及實現該軟體的計算中心或電腦網路； 　　C．該軟體系統同其他系統或其他機構的基本的相互來往關係。 　　1．3定義 　　列出本檔案中用到的專門術語的定義和外文首字母組詞的原片語。 　　1．4參考資料 　　列出用得著的參考資料，如： 　　a．本項目的經核準的計劃任務書或合約、上級機關的批文； 　　b．屬於本項目的其他已發表的檔案； 　　c．本檔案中各處引用的檔案、資料、包括所要用到的軟體開發標準。 列出這些檔案資料的標題、檔案編號、發表日期和出版單位，說明能夠得到這些檔案資料的來源。 　　2　任務概述 　　2．1目標 　　敘述該項軟體開發的意圖、應用目標、作用範圍以及其他應向讀者說明的有關該軟體開發的背景材料。解釋被開發軟體與其他有關軟體之間的關係。如果本軟體產品是一項獨立的軟體，而且全部內容自含，則說明這一點。如果所定義的產品是一個更大的系統的一個組成部分，則應說明本產品與該系統中其他各組成部分之間的關係，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯絡和介面。 　　2．2使用者的特點 　　列出本軟體的終端使用者的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟體的預期使甩頻度。這些是軟體設計工作的重要約束 　　2．3假定和約束 　　列出進行本軟體開發工作的假定和約束，例如經費限制、開發期限等。 　　3　需求規定 　　3．1對功能的規定 　　用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟體所提出的功能要求，說明輸入什麼量、經怎樣的處理、得到什麼輸出，說明軟體應支援的終端數和應支援的並行操作的使用者數。 　　3．2對效能的規定 　　3．2．1精度 　　說明對該軟體的輸入、輸出資料精度的要求，可能包括傳輸過程中的精度。 　　3．2．2時間特性要求 　　說明對於該軟體的時間特性要求，如對： 　　a．回應時間； 　　b．更新處理時間； 　　c．資料的轉換和傳送時間； 　　d．解題時間； 等的要求。 　　3．2．3靈活性 　　說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如： 　　a．操作方式上的變化； 　　b．運行環境的變化； 　　c．同其他軟體的介面的變化； 　　d．精度和有效時限的變化； 　　e．計劃的變化或改進。 　　對於為了提供這些靈活性而進行的專門設計的部分應該加以標明。 　　3．3輸人輸出要求 　　解釋各輸入輸出資料類型，並逐項說明其媒體、格式、數值範圍、精度等。對軟體的資料輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。 　　3．4資料管理能力要求 　　說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對資料及其分量的儲存要求作出估算。 　　3．5故障處理要求 　　列出可能的軟體、硬體故障以及對各項效能而言所產生的後果和對故障處理的要求。 　　3．6其他專門要求 　　如使用者單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。 　　4　運行環境規定 　　4．1裝置 　　列出運行該軟體所需要的硬裝置。說明其中的新型裝置及其專門功能，包括： 　　a．處理器型號及記憶體容量； 　　b．外存容量、聯機或離線、媒體及其儲存格式，裝置的型號及數量； 　　c．輸入及輸出裝置的型號和數量，聯機或離線； 　　d．資料通信設備的型號和數量； 　　e．功能鍵及其他專用硬體 　　4．2支援軟體 　　列出支援軟體,包括要用到的作業系統、編譯（或彙編）程式、測試支援軟體等。 　　4．3 介面 　　說明該軟體同其他軟體之間的介面、資料通訊協定等。 　　4．4控制 　　說明控制該軟體的啟動並執行方法和控制訊號，並說明這些控制訊號的來源。 文章出自：http://hi.baidu.com/zwl232/blog/item/f5e38794f595141ed31b7057.html