requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用實例（use   
            case）文檔或方案腳本說明中予以說明。<BR>&nbsp;&nbsp;&nbsp;&nbsp;3．功能需求(functional   
            requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。<BR>在軟件需求規格說明書   
            （SRS）中說明的功能需求充分描述了軟件系統所應具有的外部行為。軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。對一個大型系統來說，軟件功能需求也許只是系統需求的一個子集，因為另外一些可能屬于子系統（或軟件部件）。<BR>&nbsp;&nbsp;&nbsp;&nbsp;作為功能需求的補充，軟件需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟件產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對用戶和開發人員都極為重要。<BR>&nbsp;&nbsp;&nbsp;&nbsp;下面以一個字處理程序為例來說明需求的不同種類。業務需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器。而對應的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現整個文檔范圍的替換。<BR>&nbsp;&nbsp;&nbsp;&nbsp;從以上定義可以發現，需求并未包括設計細節、實現細節、項目計劃信息或測試信息。需求與這些沒有關系，它關注的是充分說明你究竟想開發什么。項目也有其它方面的需求，如開發環境需求或發布產品及移植到支撐環境的需求。盡管這些需求對項目成功也至關重要，但它們并非本書所要討論的。<BR>
            <CENTER><B>5．需求分析的原則</B></CENTER>不重視需求過程的項目隊伍將自食其果。需求工程中的缺陷將給項目成功帶來極大風險，這里的“成功”是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望。下面將討論一些需求風險。<BR>&nbsp;&nbsp;&nbsp;&nbsp;不適當的需求過程所引起的一些風險:<BR>&nbsp;&nbsp;&nbsp;&nbsp;1.   
            無足夠用戶參與<BR>&nbsp;&nbsp;&nbsp;&nbsp;客戶經常不明白為什么收集需求和確保需求質量需花費那么多功夫，開發人員可能也不重視用戶的參與。究其原因：一是因為開發人員感覺與用戶合作不如編寫代碼有意思；二是因為開發人員覺得已經明白用戶的需求了。在某些情況下，與實際使用產品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中，并一同經歷整個開發過程。<BR>&nbsp;&nbsp;&nbsp;&nbsp;系統人員在實踐過程中，也有些感覺，在實施一家公司的項目時，若無足夠的用戶參與，系統人員獲得的需求是片面的，不完整的，這樣系統在需求之初就埋下風險。<BR>&nbsp;&nbsp;&nbsp;   
            2.   
            用戶需求的不斷增加<BR>&nbsp;&nbsp;&nbsp;&nbsp;在開發中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算范圍。計劃并不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致，這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發者對新需求所作的修改。<BR>&nbsp;&nbsp;&nbsp;&nbsp;要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折中。<BR>&nbsp;&nbsp;&nbsp;&nbsp;產品開發中不斷延續的變更會使其整體結構日漸紊亂，補丁代碼也使得整個程序難以理解和維護。插入補丁代碼使模塊違背強內聚、松耦合的設計原則，特別是如果項目配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區別這些可能帶來變更的特性，你就能開發一個更為健壯的結構，并能更好地適應它。這樣設計階段需求變更不會直接導致補丁代碼，同時也有利于減少因變更導致質量的下降。<BR>&nbsp;&nbsp;&nbsp;&nbsp;3.   
            模棱兩可的需求<BR>&nbsp;&nbsp;&nbsp;&nbsp;模棱兩可是需求規格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明產生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。<BR>模棱兩可的需求會使不同的風險承擔者產生不同的期望，它會使開發人員為錯誤問題而浪費時間，并且使測試者與開發者所期望的不一致。一位系統測試人員曾告訴我，她所在的測試組經常對需求理解有誤，以致不得不重寫許多測試用例并重做許多測試。<BR>&nbsp;&nbsp;&nbsp;&nbsp;處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目后期才被發現，那時再發現的話會使得更正代價很大。<BR>&nbsp;&nbsp;&nbsp;&nbsp;4.   
            不必要的特性<BR>&nbsp;&nbsp;&nbsp;&nbsp;“畫蛇添足”是指開發人員力圖增加一些“用戶欣賞”但需求規格說明中并未涉及的新功能。經常發生的情況是用戶并不認為這些功能性很有用，以致在其上耗費的努力“白搭”了。開發人員應當為客戶構思方案并為他們提供一些具有創新意識的思路，具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡，開發人員應努力使功能簡單易用，而不要未經客戶同意，擅自脫離客戶要求，自作主張。<BR>&nbsp;&nbsp;&nbsp;&nbsp;同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實用價值的功能，而實現這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小，應確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能。<BR>&nbsp;&nbsp;&nbsp;&nbsp;5.   
            過于精簡的規格說明<BR>&nbsp;&nbsp;&nbsp;&nbsp;有時，客戶并不明白需求分析有如此重要，于是只作一份簡略之至的規格說明，僅涉及了產品概念上的內容，然后讓開發人員在項目進展中去完善，結果很可能出現的是開發人員先建立產品的結構之后再完成需求說明。這種方法可能適合于尖端研究性的產品或需求本身就十分靈活的情況。但在大多數情況下，這會給開發人員帶來挫折（使他們在不正確的假設前提和極其有限的指導下工作），也會給客戶帶來煩惱（他們無法得到他們所設想的產品）。<BR>&nbsp;&nbsp;&nbsp;&nbsp;6.   
            忽略了用戶分類<BR>&nbsp;&nbsp;&nbsp;&nbsp;大多數產品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經驗水平也不盡相同。如果你不能在項目早期就針對所有這些主要用戶進行分類的話，必然導致有的用戶對產品感到失望。例如，菜單驅動操作對高級用戶太低效了，但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難。<BR>&nbsp;&nbsp;&nbsp;&nbsp;7.   
            不準確的計劃<BR>&nbsp;&nbsp;&nbsp;&nbsp;據統計，導致需求過程中軟件成本估計極不準確的原因主要有以下五點：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析。<BR>對不準確的要求所提問題的正確響應是“等我真正明白你的需求時，我就會來告訴你”。基于不充分信息和未經深思的對需求不成熟的估計很容易為一些因素左右。要作出估計時，最好還是給出一個范圍。未經準備的估計通常是作為一種猜測給出的，聽者卻認為是一種承諾。因此我們要盡力給出可達到的目標并堅持完成它。<BR>
            <CENTER><B>6．需求分析人員和用戶的合作關系</B></CENTER>&nbsp;&nbsp;&nbsp;&nbsp;優秀的軟件產品是建立在優秀的需求基礎之上的。而高質量的需求來源于客戶與開發人員之間有效的交流與合作。通常，開發人員與客戶或客戶代理人，如市場人員間的關系反而會成為一種對立關系。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦，在這種情況下，不會給雙方帶來一點益處。<BR>&nbsp;&nbsp;&nbsp;&nbsp;只有當雙方參與者都明白要成功自己需要什么，同時也應知道要成功合作方需要什么時，才能建立起一種合作關系。由于項目壓力與日漸增，所有風險承擔者有著一個共同的目標這一點容易被遺忘。其實大家都想開發出一個既能實現商業價值，又能滿足用戶需要，還能使開發者感到滿足的優秀軟件產品。<BR>&nbsp;&nbsp;&nbsp;&nbsp;軟件客戶需求權利書列出了十條關于客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求。每一項權利都對應著軟件開發人員、分析人員的義務。而軟件客戶需求義務書也列出了十條關于客戶在需求過程中應承擔的義務。如果愿意，可以將其作為開發人員的權利書。<BR>客戶有如下權利：<BR>&nbsp;&nbsp;&nbsp;&nbsp;1：要求分析人員使用符合客戶語言習慣的表達<BR>需求討論應集中于業務需要和任務，故要使用業務術語，你應將其教給分析人員，而你   
            不一定要懂得計算機的行業術語。<BR>&nbsp;&nbsp;&nbsp;&nbsp;2：要求分析人員了解客戶的業務及目標<BR>&nbsp;&nbsp;&nbsp;&nbsp;通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業務任務和怎樣才能使產品更好地滿足你的需要。這將有助于開發人員設計出真正滿足你的需要并達到你期望的優秀軟件。為幫助開發人員和分析人員，可以考慮邀請他們觀察你或你的同事是怎樣工作的。如果新開發系統是用來替代已有的系統，那么開發人員應使用一下目前的系統，這將有利于他們明白目前系統是怎樣工作的，其工作流程的情況，以及可供改進之處。<BR>&nbsp;&nbsp;&nbsp;&nbsp;3：要求分析人員編寫軟件需求規格說明<BR>&nbsp;&nbsp;&nbsp;&nbsp;分析人員要把從你和其他客戶那里獲得的所有信息進行整理，以區分開業務需求及規范、功能需求、質量目標、解決方法和其它信息。通過這些分析就能得到一份軟件需求規格說明。而這份軟件需求規格說明便在開發人員和客戶之間針對要開發的產品內容達成了協議。軟件需求規格說明書可以用一種你認為易于翻閱和理解的方式組織編寫。要評審編寫出的規格說明以確保它們準確而完整地表達了你的需求。一份高質量的軟件需求規格說明能有助于開發人員開發出真正需要的產品。<BR>&nbsp;&nbsp;&nbsp;&nbsp;4：要求得到需求工作結果的解釋說明<BR>&nbsp;&nbsp;&nbsp;&nbsp;分析人員可能采用了多種圖表作為文字性軟件需求規格說明的補充。因為如工作流程圖那樣的圖表能很清楚地描述出系統行為的某些方面。所以需求說明中的各種圖表有著極高的價值。雖然它們不太難于理解，但是你很可能對此并不熟悉。因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發工作結果和符號的意義，及怎樣檢查圖表有無錯誤及不一致等。<BR>&nbsp;&nbsp;&nbsp;&nbsp;5：要求開發人員尊重你的意見<BR>&nbsp;&nbsp;&nbsp;&nbsp;如果用戶與開發人員之間不能相互理解，那關于需求的討論將會有障礙，共同合作能使大家“兼聽則明”。參與需求開發過程的客戶有權要求開發人員尊重他們并珍惜他們為項目成功所付出的時間。同樣，客戶也應對開發人員為項目成功這一共同目標所作出的努力表示尊重與感激。<BR>&nbsp;&nbsp;&nbsp;&nbsp;6：要求開發人員對需求及產品實施提供建議，拿出主意<BR>&nbsp;&nbsp;&nbsp;&nbsp;通常，客戶所說的“需求”已是一種實際可能的實施解決方案，分析人員將盡力從這些解決方法中了解真正的業務及其需求，同時還應找出已有系統不適合當前業務之處，以確保產品不會無效或低效。在徹底弄清業務領域內的事情后，分析人員有時就能提出相當好的改進方法。有經驗且富有創造力的分析人員還能提出增加一些用戶并未發現的很有價值的系統特性。<BR>&nbsp;&nbsp;&nbsp;&nbsp;7：描述產品易使用的特性<BR>&nbsp;&nbsp;&nbsp;&nbsp;你可以要求分析人員在實現功能需求的同時還要注重軟件的易用性。因為這些易用特性或質量屬性能使你更準確、高效地完成任務。例如，客戶有時要求產品要“用戶友好”或“健壯”或“高效率”，但這對于開發人員來說，太主觀了并無實用價值。正確的應是：分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性。<BR>&nbsp;&nbsp;&nbsp;&nbsp;8：調整需求，允許重用已有的軟件組件<BR>&nbsp;&nbsp;&nbsp;&nbsp;需求通常要有一定的靈活性。分析人員可能發現已有的某個軟件組件與你描述的需求很相符。在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能夠在新系統開發中重用一些已有的軟件。如果有可重用的機會出現，同時你又能調整你的需求說明，那就能降低成本和節省時間，而不必嚴格按原有的需求說明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們并不完全適合你所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;9：獲得滿足客戶功能和質量要求的系統<BR>&nbsp;&nbsp;&nbsp;&nbsp;每個人都希望項目獲得成功。但這不僅要求你要清晰地告知開發人員關于系統“做什么”所需的所有信息，而且還要求開發人員能通過交流了解清楚取舍與限制。一定要明確說明你的假設和潛在的期望。否則，開發人員開發出的產品很可能無法讓你滿意。<BR>客戶有下列義務：<BR>&nbsp;&nbsp;&nbsp;&nbsp;1：給分析人員講解你的業務<BR>&nbsp;&nbsp;&nbsp;&nbsp;分析人員要依靠你給他們講解的業務概念及術語。但你不能指望分析人員會成為該領域的專家，而只能讓他們真正明白你的問題和目標。不要期望分析人員能把握你們業務的細微與潛在之處，他們很可能并不知道那些對于你和你的同事來說理所當然的“常識”。<BR>&nbsp;&nbsp;&nbsp;&nbsp;2：抽出時間清楚地說明并完善需求<BR>&nbsp;&nbsp;&nbsp;&nbsp;客戶很忙，經常在最忙的時候還得參與需求開發。但無論如何，你有義務抽出時間參與“頭腦風暴”會議的討論，接受采訪或其它獲取需求的活動。有時分析人員可能先以為明白了你的觀點，而過后發現還需要你的講解。這時，請耐心一些對待需求和需求的精化工作過程中的反復，因為它是人們交流中的很自然的現象，何況這對軟件產品的成功極為重要。<BR>&nbsp;&nbsp;&nbsp;&nbsp;3：準確而詳細地說明需求<BR>&nbsp;&nbsp;&nbsp;&nbsp;編寫一份清晰、準確的需求文檔是很困難的。由于處理細節問題不但煩人而且又耗時，故很容易留下模糊不清的需求。但是，在開發過程中，必須得解決這種模糊性和不準確性。而你恰是為解決這些問題作出決定的最佳人選。不然的話，你就只好靠開發人員去正確猜測了。在需求規格說明中暫時加上待定（to   
            be determined,   
            TBD也可采用漢語拼音略寫“DQD：待確定”）的標志是個不錯的辦法。用該標志可指明了哪些需要進一步探討、分析或增加信息的地方。不過，有時也可能因為某個特殊需求難以解決或沒有人愿意處理它而注上TBD標志。盡量將每項需求的內容都闡述清楚，以便分析人員能準確的將其寫進軟件需求規格說明中。如果你一時不能準確表述，那就得允許獲取必要的準確信息這樣一個過程。通常使用所謂的原型技術。通過開發的原型，你可以同開發人員一起反復修改，不斷完善需求定義。<BR>&nbsp;&nbsp;&nbsp;&nbsp;4：及時地作出決定<BR>&nbsp;&nbsp;&nbsp;&nbsp;正如一位建筑師為你修建房屋，分析人員將要求你做出一些選擇和決定。這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息準確度中選擇折衷方案等。有權做出決定的客戶必須積極地對待這一切，盡快做處理、做決定。因為開發人員通常只有等你做出了決定才能行動，而這種等待會延誤項目的進展。<BR>&nbsp;&nbsp;&nbsp;&nbsp;5：尊重開發人員的需求可行性及成本評估<BR>&nbsp;&nbsp;&nbsp;&nbsp;所有的軟件功能都有其成本價格，開發人員最適合預算這些成本（盡管許多開發人員并不擅長評估預測）。你所希望的某些產品特性可能在技術上行不通，或者實現它要付出極為高昂的代價。而某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的數據，開發人員會對此作出負面的評價意見，你應該尊重他們的意見。有時，你可以重新給出一個在技術上可行、實現上便宜的需求，例如，要求某個行為在“瞬間”發生是不可行的，但換種更具體的時間需求說法（“在50ms以內”,但若沒有準確的技術分析不能輕易下結論），這就可以實現了。<BR>&nbsp;&nbsp;&nbsp;&nbsp;6：   
            劃分需求優先級別<BR>&nbsp;&nbsp;&nbsp;&nbsp;大多數項目沒有足夠的時間或資源來實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發的主要部分。只能由你來負責設定需求優先級，因為開發者并不可能按你的觀點決定需求優先級。開發者將為你確定優先級提供有關每個需求的花費和風險的信息。當你設定優先級時，你幫助開發者確保在適當的時間內用最小的開支取得最好的效果。在時間和資源限制下，關于所需特性能否完成或完成多少應該尊重開發人員的意見。盡管沒有人愿意看到自己所希望的需求在項目中未被實現，但畢竟是要面對這種現實的。業務決策有時不得不依據優先級來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。<BR>&nbsp;&nbsp;&nbsp;&nbsp;7：評審需求文檔和原型<BR>&nbsp;&nbsp;&nbsp;&nbsp;正如我們將在第1   
            4章討論的，無論是正式的還是非正式的方式，對需求文檔進行評審都會對軟件質量提高有所幫助。讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性。評審也給客戶代表提供一個機會，給需求分析人員帶來反饋信息以改進他們的工作。如果你認為編寫的需求文檔不夠準確，就有義務盡早告訴分析人員并為改進提供建議。通過閱讀需求規格說明，很難想象實際的軟件是什么樣子的。更好的方法是先為產品開發一個原型。這樣你就能提供更有價值的反饋信息給開發人員，幫助他們更好地理解你的需求。必須認識到：原型并非是一個實際產品，但開發人員能將其轉變、擴充成功能齊全的系統。<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8：需求出現變更要馬上聯系<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響。變更是不可避免的，但在開發周期中變更越在晚期出現，其影響越大。變更不僅會導致代價極高的返工，而且工期也會被迫延誤，特別是在大體結構已完成后又需要增加新特性時。所以一旦你發現需要變更需求時，請一定立即通知分析人員。<BR>&nbsp;&nbsp;&nbsp;&nbsp;9：應遵照開發組織處理需求變更的過程<BR>&nbsp;&nbsp;&nbsp;&nbsp;為了將變更帶來的負面影響減少到最低限度，所有的參與者必須遵照項目的變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最后作出合適的決策以確定將某些變更引入項目中。<BR>&nbsp;&nbsp;&nbsp;&nbsp;10：尊重開發人員采用的需求工程過程<BR>軟件開發中最具挑戰性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性。也許你認為需求過程不太劃算，但請相信花在需求開發上的時間是“很有價值”的。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質量所采用的技術，那么整個過程將會更為順利。盡管去詢問分析人員為什么他們要收集某些信息，或參與與需求有關的活動。<BR>&nbsp;&nbsp;&nbsp;&nbsp;系統分析人員在開發過程中可能會遇到以下問題，一些很忙的客戶可能不愿意積極參與需求過程，而缺少客戶參與將很可能導致不理想的產品。故一定要確保需求開發中的主要參與者都了解并接受他們的義務。如果遇到分歧，通過協商以達成對各自義務的相互理解，這樣能減少今后的摩擦。<BR>
            <CENTER><B>7．需求文檔</B></CENTER>&nbsp;&nbsp;&nbsp;&nbsp;需求開發的最終成果是：客戶和開發小組對將要開發的產品達成一致協議。協議綜合了業務需求、用戶需求和軟件功能需求。就像我們早先所看到的，項目視圖和范圍文檔包含了業務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產品的非功能需求文檔，包括質量屬性和外部接口需求。只有以結構化和可讀性方式編寫這些文檔，并由項目的風險承擔者評審通過后，各方面人員才能確信他們所贊同的需求是可靠的。<BR>&nbsp;&nbsp;&nbsp;&nbsp;你可以使用以下三種方法編寫軟件需求規格說明：<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            用好的結構化和自然語言編寫文本型文檔。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            建立圖形化模型，這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            編寫形式化規格說明，這可以通過使用數學上精確的形式化邏輯語言來定義需求。<BR>由于形式化規格說明具有很強的嚴密性和精確度，因此，所使用的形式化語言只有極少數軟件開發人員才熟悉，更不用說客戶了。雖然結構化的自然語言具有許多缺點，但在大多數軟件工程中，它仍是編寫需求文檔最現實的方法。包含了功能和非功能需求的基于文本的軟件需求規格說明已經為大多數項目所接受。圖形化分析模型通過提供另一種需求視圖，增強了軟件需求規格說明。<BR>&nbsp;&nbsp;&nbsp;&nbsp;軟件需求規格說明不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。除了設計和實現上的限制，軟件需求規格說明不應該包括設計、構造、測試或工程管理的細節。許多讀者使用軟件需求規格說明來達到不同的目的：<BR>&nbsp;&nbsp;&nbsp;   
            客戶和營銷部門依賴它來了解他們所能提供的產品。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            項目經理根據包含在軟件需求規格說明中描述的產品來制定規劃并預測進度安排、工作量和資源。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            軟件開發小組依賴它來理解他們將要開發的產品。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            測試小組使用軟件需求規格說明中對產品行為的描述制定測試計劃、測試用例和測試過程。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            軟件維護和支持人員根據需求規格說明了解產品的某部分是做什么的。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            產品發布組在需求規格說明和用戶界面設計的基礎上編寫客戶文檔，如用戶手冊和幫助屏幕等。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            培訓人員根據需求規格說明和用戶文檔編寫培訓材料。<BR>軟件需求規格說明作為產品需求的最終成果必須具有綜合性：必須包括所有的需求。開發者和客戶不能作任何假設。如果任何所期望的功能或非功能需求未寫入軟件需求規格說明，那么它將不能作為協議的一部分并且不能在產品中出現。<BR>&nbsp;&nbsp;&nbsp;&nbsp;我見過有一個項目突然接到測試人員發出的錯誤災難的報告。結果是他們測試的是老版本的軟件需求規格說明，而他們覺得錯誤的地方正是產品所獨有的特性。他們的測試工作是徒勞的，因為他們一直在老版本的軟件需求規格說明中尋找錯誤的系統行為。<BR>&nbsp;&nbsp;&nbsp;&nbsp;在編寫軟件需求規格說明，希望讀者牢記以下的建議：<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            對節、小節和單個需求的號碼編排必須一致。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            在右邊部分留下文本注釋區。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            允許不加限制地使用空格。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            正確使用各種可視化強調標志（例如，黑體、下劃線、斜體和其它不同字體）。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            創建目錄表和索引表有助于讀者尋找所需的信息。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            對所有圖和表指定號碼和標識號，并且可按號碼進行查閱。<BR>&nbsp;&nbsp;&nbsp;&nbsp;   
            使用字處理程序中交叉引用的功能來查閱文檔中其它項或位置，而不是通過頁碼或節號。<BR>&nbsp;&nbsp;&nbsp;&nbsp;為了滿足軟件需求規格說明的可跟蹤性和可修改性的質量標準，必須唯一確定每個軟件需求。這可以使你在變更請求、修改歷史記錄、交叉引用或需求的可跟蹤矩陣中查閱特定的需求。由于要達到這一目的，用單一的項目列表是不夠的，因此，我將描述幾個不同的需求標識方法，并闡明它們的優點與缺點?？梢赃x擇最適合你的方法。<BR>&nbsp;&nbsp;&nbsp;&nbsp;(1)   
            序列號最簡單的方法是賦予每個需求一個唯一的序列號，例如SRS-13。當一個新的需求加入到商業需求管理工具的數據庫之后，這些管理工具就會為其分配一個序列號（許多這樣的工具也支持層次化編號）。序列號的前綴代表了需求類型，例如SRS代表“軟件需求說明”。由于序列號不能重用，所以把需求從數據庫中刪除時，并不釋放其所占據的序列號，而新的需求只能得到下一個可用的序列號。這種簡單的編號方法并不能提供任何相關需求在邏輯上或層次上的區別，而且需求的標識不能提供任何有關每個需求內容的信息。<BR>&nbsp;&nbsp;&nbsp;&nbsp;(2)   
            層次化編碼這也許是最常用的方法。如果功能需求出現在軟件需求規格說明中第3 .   
            2部分，那么它們將具有諸如3.2.4.3這樣的標識號。標識號中的數字越多則表示該需求越詳細，屬于較低層次上的需求。即使在一個中型的軟件需求規格說明中，這些標識號也會擴展到許多位數字，并且這些標識也不提供任何有關每個需求目的的信息。如果你要插入一個新的需求，那么該需求所在部分其后所有需求的序號將要增加。刪除或移去一個需求，那么該需求所在部分其后所有需求的序號將要減少。但其他地方的引用將混亂，對于這種簡單的層次化編號的一種改進方法是對需求中主要的部分進行層次化編號，然后對于每個部分中的單一功能需求用一個簡短文字代碼加上一個序列號來識別。例如，軟件需求規格說明可能包含“第3.2.5部分—編輯功能”，并將此部分編寫成子模塊文檔，然后配置管理。<BR>&nbsp;&nbsp;&nbsp;&nbsp;有時，你覺得缺少特定需求的某些信息。在解決這個不確定性之前，可能必須與客戶商議、檢查與另一個系統的接口或者定義另一個需求。使用“待確定”（to   
            be determined,