軟件需求分析

　　過去的10年，毫無疑問是中國軟件業發展最快的10年。當咱們剛剛畢業的時候，還在使用VB、PB開發一些簡單的數據庫應用，而如今卻幾乎看不到它們的蹤跡，換來的是諸如J2EE和.NET這樣的大型web應用。而這期間，RUP、XP、敏捷開發、持續集成••••••一個接一個的新概念層出不窮，使人眼花繚亂。如今想來，恍如隔世。

　　

過去的10年，毫無疑問是中國軟件業發展最快的10年。當咱們剛剛畢業的時候，還在使用VB、PB開發一些簡單的數據庫應用，而如今卻幾乎看不到它們的蹤跡，換來的是諸如J2EE和.NET這樣的大型web應用。而這期間，RUP、XP、敏捷開發、持續集成••••••一個接一個的新概念層出不窮，使人眼花繚亂。如今想來，恍如隔世。

需求開發可進一步分爲：問題獲取、分析、編寫規格說明和驗證四個階段。這些子項包括軟件類產品中需求收集、評價、編寫文檔等全部活動。需求開發活動包括如下幾個方面：

肯定產品所指望的用戶類別。

獲取每一個用戶類的需求。

瞭解實際用戶任務和目標以及這些任務所支持的業務需求。

分析源於用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息。

將系統級的需求分爲幾個子系統，並將需求中的一部份分配給軟件組件。

瞭解相關質量屬性的重要性。

商討實施優先級的劃分。

將所收集的用戶需求編寫成文檔和模型。

評審需求規格說明，確保對用戶需求達到共同的理解與認識，並在整個開發小組接受說明以前將問題都弄清楚。

需求管理須要「創建並維護在軟件工程中同客戶達成的合同」 。這種合同都包含在編寫的需求文檔與模型中。客戶的接受僅是需求成功的一半，開發人員也必須可以接受他們，並真正把需求應用到產品中。一般的需求管理活動包括：

定義需求基線（迅速制定需求文檔的主體）。

評審提出的需求變動、評估每項變動的可能影響從而決定是否實施它。

以一種可控制的方式將需求變動融入到項目中。

使當前的項目計劃與需求一致。

估計變動需求所產生影響並在此基礎上協商新的承諾，這種承諾具體體如今項目解決方案上。

讓每項需求都能與其對應的設計、源代碼和測試用例聯繫起來以實現跟蹤。

在整個項目過程當中跟蹤需求狀態及其變動狀況。

以上幾點說明是我總結了成功實施項目後系統分析人員的經驗，同時也根據國內外的其餘系統實施的相關成功經驗，進行了總結。

4．需求的類型

下面這些定義是需求工程領域中常見術語的定義。

軟件需求包括三個不一樣的層次：業務需求、用戶需求和功能需求（也包括非功能需求）。

1．業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與範圍文檔中予以說明。

2．用戶需求(user requirement) 文檔描述了用戶使用產品必需要完成的任務，這在使用實例（use case）文檔或方案腳本說明中予以說明。

3．功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而知足了業務需求。

在
軟件需求規格說明書
（SRS）中說明的功能需求充分描述了軟件系統所應具備的外部行爲。軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的做
用。對一個大型系統來講，軟件功能需求也許只是系統需求的一個子集，由於另一些可能屬於子系統（或軟件部件）。

做爲功能需求的補充，軟
件需求規格說明還應包括非功能需求，它描述了系統展示給用戶的行爲和執行的操做等。它包括產品必須聽從的標準、規範和合約；外部界面的具體細節；性能要
求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟件產品設計和構造上的限制。質量屬性是經過多種角度對產品的特色進行描述，從而反映產品
功能。多角度描述產品對用戶和開發人員都極爲重要。

下面以一個字處理程序爲例來講明需求的不一樣種類。業務需求多是：「用戶能有效地糾正
文檔中的拼寫錯誤」，該產品的包裝盒封面上可能會標明這是個知足業務需求的拼寫檢查器。而對應的用戶需求多是「找出文檔中的拼寫錯誤並經過一個提供的替
換項列表來供選擇替換拼錯的詞」。同時，該拼寫檢查器還有許多功能需求，如找到並高亮度提示錯詞的操做；顯示提供替換詞的對話框以及實現整個文檔範圍的替
換。

從以上定義能夠發現，需求並未包括設計細節、實現細節、項目計劃信息或測試信息。需求與這些沒有關係，它關注的是充分說明你究竟想開發什麼。
項目也有其它方面的需求，如開發環境需求或發佈產品及移植到支撐環境的需求。儘管這些需求對項目成功也相當重要，但它們並不是本書所要討論的。

5．需求分析的原則

不重視需求過程的項目隊伍將自作自受。需求工程中的缺陷將給項目成功帶來極大風險，這裏的「成功」是指推出的產品能以合理的價格、及時地在功能、質量上徹底知足用戶的指望。下面將討論一些需求風險。

不適當的需求過程所引發的一些風險:

1. 無足夠用戶參與

客
戶常常不明白爲何收集需求和確保需求質量需花費那麼多功夫，開發人員可能也不重視用戶的參與。究其緣由：一是由於開發人員感受與用戶合做不如編寫代碼有
意思；二是由於開發人員以爲已經明白用戶的需求了。在某些狀況下，與實際使用產品的用戶直接接觸很困難，而客戶也不太明白本身的真正需求。但仍是應讓具備
表明性的用戶在項目早期直接參與到開發隊伍中，並一同經歷整個開發過程。

系統人員在實踐過程當中，也有些感受，在實施一家公司的項目時，若無足夠的用戶參與，系統人員得到的需求是片面的，不完整的，這樣系統在需求之初就埋下風險。

2. 用戶需求的不斷增長

在開發中若不斷地補充需求，項目就越變越龐大以至超過其計劃及預算範圍。計劃並不老是與項目需求規模與複雜性、風險、開發生產率及需求變動實際狀況相一致，這使得問題更難解決。實際上，問題根源在於用戶需求的改變和開發者對新需求所做的修改。

要
想把需求變動範圍控制到最小，必須一開始就對項目視圖、範圍、目標、約束限制和成功標準給予明確說明，並將此說明做爲評價需求變動和新特性的參照框架。說
明中包括了對每種變動進行變動影響因素分析的變動控制過程，有助於全部風險承擔者明白業務決策的合理性，即爲什麼進行某些變動，相應消耗的時間、資源或特性
上的折中。

產品開發中不斷延續的變動會使其總體結構日漸紊亂，補丁代碼也使得整個程序難以理解和維護。插入補丁代碼使模塊違背強內聚、鬆耦合的設
計原則，特別是若是項目配置管理工做不完善的話，收回變動和刪除特性會帶來問題。若是你儘早地區別這些可能帶來變動的特性，你就能開發一個更爲健壯的結
構，並能更好地適應它。這樣設計階段需求變動不會直接致使補丁代碼，同時也有利於減小因變動致使質量的降低。

3. 模棱兩可的需求

模棱兩但是需求規格說明中最爲可怕的問題。它的一層含義是指諸多讀者對需求說明產生了不一樣的理解；另外一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。

模棱兩可的需求會使不一樣的風險承擔者產生不一樣的指望，它會使開發人員爲錯誤問題而浪費時間，而且使測試者與開發者所指望的不一致。一位系統測試人員曾告訴我，她所在的測試組常常對需求理解有誤，以至不得不重寫許多測試用例並重作許多測試。

處
理模棱兩可需求的一種方法是組織好負責從不一樣角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。若是不一樣的評審者從不一樣的角度對需
求說明給予解釋，但每一個評審人員都真正瞭解需求文檔，這樣二義性就不會直到項目後期才被發現，那時再發現的話會使得更正代價很大。

4. 沒必要要的特性

「畫
蛇添足」是指開發人員力圖增長一些「用戶欣賞」但需求規格說明中並未涉及的新功能。常常發生的狀況是用戶並不認爲這些功能性頗有用，以至在其上耗費的努力
「白搭」了。開發人員應當爲客戶構思方案併爲他們提供一些具備創新意識的思路，具體提供哪些功能要在客戶所需與開發人員在容許時限內的技術可行性之間求得
平衡，開發人員應努力使功能簡單易用，而不要未經客戶贊成，擅自脫離客戶要求，自做主張。

一樣，客戶有時也可能要求一些看上去很「酷」，但缺少實
用價值的功能，而實現這些功能只能徒耗時間和成本。爲了將「多此一舉」的危害儘可能減少，應確信：你明白爲何要包括這些功能，以及這些功能的「來龍去
脈」，這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能。

 

5. 過於精簡的規格說明

有時，客戶並不明白需求分析有如此重要，因而只做
一份簡略之至的規格說明，僅涉及了產品概念上的內容，而後讓開發人員在項目進展中去完善，結果極可能出現的是開發人員先創建產品的結構以後再完成需求說
明。這種方法可能適合於尖端研究性的產品或需求自己就十分靈活的狀況。但在大多數狀況下，這會給開發人員帶來挫折（使他們在不正確的假設前提和極其有限的
指導下工做），也會給客戶帶來煩惱（他們沒法獲得他們所設想的產品）。

6. 忽略了用戶分類

大多數產品是由不一樣的人使用
其不一樣的特性，使用頻繁程度也有所差別，使用者受教育程度和經驗水平也不盡相同。若是你不能在項目早期就針對全部這些主要用戶進行分類的話，必然致使有的
用戶對產品感到失望。例如，菜單驅動操做對高級用戶過低效了，但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難。

7. 不許確的計劃

據統計，致使需求過程當中軟件成本估計極不許確的緣由主要有如下五點：頻繁的需求變動、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析。

對
不許確的要求所提問題的正確響應是「等我真正明白你的需求時，我就會來告訴你」。基於不充分信息和未經深思的對需求不成熟的估計很容易爲一些因素左右。要
做出估計時，最好仍是給出一個範圍。未經準備的估計一般是做爲一種猜想給出的，聽者卻認爲是一種承諾。所以咱們要盡力給出可達到的目標並堅持完成它。

6．需求分析人員和用戶的合做關係

優
秀的軟件產品是創建在優秀的需求基礎之上的。而高質量的需求來源於客戶與開發人員之間有效的交流與合做。一般，開發人員與客戶或客戶代理人，如市場人員間
的關係反而會成爲一種對立關係。雙方的管理者都只想本身的利益而擱置用戶提供的需求從而產生摩擦，在這種狀況下，不會給雙方帶來一點益處。

只
有當雙方參與者都明白要成功本身須要什麼，同時也應知道要成功合做方須要什麼時，才能創建起一種合做關係。因爲項目壓力與日漸增，全部風險承擔者有着一個
共同的目標這一點容易被遺忘。其實你們都想開發出一個既能實現商業價值，又能知足用戶須要，還能使開發者感到知足的優秀軟件產品。

軟件客戶需求權利書列出了十條關於客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求。每一項權利都對應着軟件開發人員、分析人員的義務。而軟件客戶需求義務書也列出了十條關於客戶在需求過程當中應承擔的義務。若是願意，能夠將其做爲開發人員的權利書。

客戶有以下權利：

1：要求分析人員使用符合客戶語言習慣的表達

需求討論應集中於業務須要和任務，故要使用業務術語，你應將其教給分析人員，而你 不必定要懂得計算機的行業術語。

2：要求分析人員瞭解客戶的業務及目標

通
過與用戶交流來獲取用戶需求、分析人員才能更好地瞭解你的業務任務和怎樣才能使產品更好地知足你的須要。這將有助於開發人員設計出真正知足你的須要並達到
你指望的優秀軟件。爲幫助開發人員和分析人員，能夠考慮邀請他們觀察你或你的同事是怎樣工做的。若是新開發系統是用來替代已有的系統，那麼開發人員應使用
一下目前的系統，這將有利於他們明白目前系統是怎樣工做的，其工做流程的狀況，以及可供改進之處。

3：要求分析人員編寫軟件需求規格說明

分
析人員要把從你和其餘客戶那裏得到的全部信息進行整理，以區分開業務需求及規範、功能需求、質量目標、解決方法和其它信息。經過這些分析就能獲得一份軟件
需求規格說明。而這份軟件需求規格說明便在開發人員和客戶之間針對要開發的產品內容達成了協議。軟件需求規格說明書能夠用一種你認爲易於翻閱和理解的方式
組織編寫。要評審編寫出的規格說明以確保它們準確而完整地表達了你的需求。一份高質量的軟件需求規格說明能有助於開發人員開發出真正須要的產品。

4：要求獲得需求工做結果的解釋說明

分
析人員可能採用了多種圖表做爲文字性軟件需求規格說明的補充。由於如工做流程圖那樣的圖表能很清楚地描述出系統行爲的某些方面。因此需求說明中的各類圖表
有着極高的價值。雖然它們不太難於理解，可是你極可能對此並不熟悉。所以能夠要求分析人員解釋說明每張圖表的做用或其它的需求開發工做結果和符號的意義，
及怎樣檢查圖表有無錯誤及不一致等。

5：要求開發人員尊重你的意見

若是用戶與開發人員之間不能相互理解，那關於需求的討論將會有障礙，共同合做能使你們「兼聽則明」。參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們爲項目成功所付出的時間。一樣，客戶也應對開發人員爲項目成功這一共同目標所做出的努力表示尊重與感激。

6：要求開發人員對需求及產品實施提供建議，拿出主意

通
常，客戶所說的「需求」已經是一種實際可能的實施解決方案，分析人員將盡力從這些解決方法中瞭解真正的業務及其需求，同時還應找出已有系統不適合當前業務之
處，以確保產品不會無效或低效。在完全弄清業務領域內的事情後，分析人員有時就能提出至關好的改進方法。有經驗且富有創造力的分析人員還能提出增長一些用
戶並未發現的頗有價值的系統特性。

7：描述產品易使用的特性

你能夠要求分析人員在實現功能需求的同時還要注重軟件的易用
性。由於這些易用特性或質量屬性能使你更準確、高效地完成任務。例如，客戶有時要求產品要「用戶友好」或「健壯」或「高效率」，但這對於開發人員來講，太
主觀了並沒有實用價值。正確的應是：分析人員經過詢問和調查瞭解客戶所要的友好、健壯、高效所包含的具體特性。

8：調整需求，容許重用已有的軟件組件

需
求一般要有必定的靈活性。分析人員可能發現已有的某個軟件組件與你描述的需求很相符。在這種狀況下，分析人員應提供一些修改需求的選擇以便開發人員可以在
新系統開發中重用一些已有的軟件。若是有可重用的機會出現，同時你又能調整你的需求說明，那就能下降成本和節省時間，而沒必要嚴格按原有的需求說明開發。所
以說，若是想在產品中使用一些已有的商業經常使用組件，而它們並不徹底適合你所需的特性，這時必定程度上的需求靈活性就顯得極爲重要了。

9：得到知足客戶功能和質量要求的系統

每一個人都但願項目得到成功。但這不只要求你要清晰地告知開發人員關於系統「作什麼」所需的全部信息，並且還要求開發人員能經過交流了解清楚取捨與限制。必定要明確說明你的假設和潛在的指望。不然，開發人員開發出的產品極可能沒法讓你滿意。

客戶有下列義務：

1：給分析人員講解你的業務

分析人員要依靠你給他們講解的業務概念及術語。但你不能期望分析人員會成爲該領域的專家，而只能讓他們真正明白你的問題和目標。不要指望分析人員能把握大家業務的細微與潛在之處，他們極可能並不知道那些對於你和你的同事來講理所固然的「常識」。

2：抽出時間清楚地說明並完善需求

客
戶很忙，常常在最忙的時候還得參與需求開發。但不管如何，你有義務抽出時間參與「頭腦風暴」會議的討論，接受採訪或其它獲取需求的活動。有時分析人員可能
先覺得明白了你的觀點，而事後發現還須要你的講解。這時，請耐心一些對待需求和需求的精化工做過程當中的反覆，由於它是人們交流中的很天然的現象，況且這對
軟件產品的成功極爲重要。

3：準確而詳細地說明需求

編寫一份清晰、準確的需求文檔是很困難的。因爲處理細節問題不但煩人
並且又耗時，故很容易留下模糊不清的需求。可是，在開發過程當中，必須得解決這種模糊性和不許確性。而你恰是爲解決這些問題做出決定的最佳人選。否則的話，
你就只好靠開發人員去正確猜想了。在需求規格說明中暫時加上待定（to be determined,
TBD也可採用漢語拼音略寫「DQD：待肯定」）的標誌是個不錯的辦法。用該標誌可指明瞭哪些須要進一步探討、分析或增長信息的地方。不過，有時也可能因
爲某個特殊需求難以解決或沒有人願意處理它而註上TBD標誌。儘可能將每項需求的內容都闡述清楚，以便分析人員能準確的將其寫進軟件需求規格說明中。若是你
一時不能準確表述，那就得容許獲取必要的準確信息這樣一個過程。一般使用所謂的原型技術。經過開發的原型，你能夠同開發人員一塊兒反覆修改，不斷完善需求定
義。

4：及時地做出決定

正如一位建築師爲你修建房屋，分析人員將要求你作出一些選擇和決定。這些決定包括來自多個用戶提
出的處理方法或在質量特性衝突和信息準確度中選擇折衷方案等。有權作出決定的客戶必須積極地對待這一切，儘快作處理、作決定。由於開發人員一般只有等你作
出了決定才能行動，而這種等待會延誤項目的進展。

5：尊重開發人員的需求可行性及成本評估

全部的軟件功能都有其成本價
格，開發人員最適合預算這些成本（儘管許多開發人員並不擅長評估預測）。你所但願的某些產品特性可能在技術上行不通，或者實現它要付出極爲高昂的代價。而
某些需求試圖在操做環境中要求不可能達到的性能或試圖獲得一些根本得不到的數據，開發人員會對此做出負面的評價意見，你應該尊重他們的意見。有時，你能夠
從新給出一個在技術上可行、實現上便宜的需求，例如，要求某個行爲在「瞬間」發生是不可行的，但換種更具體的時間需求說法（「在50ms之內」,但若沒有
準確的技術分析不能輕易下結論），這就能夠實現了。

6： 劃分需求優先級別

大多數項目沒有足夠的時間或資源來實現功能性
的每一個細節。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發的主要部分。只能由你來負責設定需求優先級，由於開發者並不可能按你的觀點決定
需求優先級。開發者將爲你肯定優先級提供有關每一個需求的花費和風險的信息。當你設定優先級時，你幫助開發者確保在適當的時間內用最小的開支取得最好的效
果。在時間和資源限制下，關於所需特性可否完成或完成多少應該尊重開發人員的意見。儘管沒有人願意看到本身所但願的需求在項目中未被實現，但畢竟是要面對
這種現實的。業務決策有時不得不依據優先級來縮小項目範圍或延長工期，或增長資源，或在質量上尋找折衷。

7：評審需求文檔和原型

正如咱們將在第1
4章討論的，不管是正式的仍是非正式的方式，對需求文檔進行評審都會對軟件質量提升有所幫助。讓客戶參與評審才能真正鑑別需求文檔是否的確完整、正確說明
了指望的必要特性。評審也給客戶表明提供一個機會，給需求分析人員帶來反饋信息以改進他們的工做。若是你認爲編寫的需求文檔不夠準確，就有義務儘早告訴分
析人員併爲改進提供建議。經過閱讀需求規格說明，很難想象實際的軟件是什麼樣子的。更好的方法是先爲產品開發一個原型。這樣你就能提供更有價值的反饋信息
給開發人員，幫助他們更好地理解你的需求。必須認識到：原型並不是是一個實際產品，但開發人員能將其轉變、擴充成功能齊全的系統。

8：需求出現變動要立刻聯繫

不
斷的需求變動會給在預約計劃內完成高質量產品帶來嚴重的負面影響。變動是不可避免的，但在開發週期中變動越在晚期出現，其影響越大。變動不只會致使代價極
高的返工，並且工期也會被迫延誤，特別是在大致結構已完成後又須要增長新特性時。因此一旦你發現須要變動需求時，請必定當即通知分析人員。

9：應遵守開發組織處理需求變動的過程

爲了將變動帶來的負面影響減小到最低限度，全部的參與者必須遵守項目的變動控制過程。這要求不放棄全部提出的變動，對每項要求的變動進行分析、綜合考慮，最後做出合適的決策以肯定將某些變動引入項目中。

10：尊重開發人員採用的需求工程過程

軟
件開發中最具挑戰性的莫過於收集需求並肯定其正確性。分析人員採用的方法有其合理性。也許你認爲需求過程不太划算，但請相信花在需求開發上的時間是「頗有
價值」的。若是你理解並支持分析人員爲收集、編寫需求文檔和確保其質量所採用的技術，那麼整個過程將會更爲順利。儘管去詢問分析人員爲何他們要收集某些
信息，或參與與需求有關的活動。

系統分析人員在開發過程當中可能會遇到如下問題，一些很忙的客戶可能不肯意積極參與需求過程，而缺乏客戶參與將極可能致使不理想的產品。故必定要確保需求開發中的主要參與者都瞭解並接受他們的義務。若是遇到分歧，經過協商以達成對各自義務的相互理解，這樣能減小從此的摩擦。

7．需求文檔

需
求開發的最終成果是：客戶和開發小組對將要開發的產品達成一致協議。協議綜合了業務需求、用戶需求和軟件功能需求。就像咱們早先所看到的，項目視圖和範圍
文檔包含了業務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產品的非功能需求文檔，包括質量屬性和外部接
口需求。只有以結構化和可讀性方式編寫這些文檔，並由項目的風險承擔者評審經過後，各方面人員才能確信他們所贊同的需求是可靠的。

你可使用如下三種方法編寫軟件需求規格說明：

用好的結構化和天然語言編寫文本型文檔。

創建圖形化模型，這些模型能夠描繪轉換過程、系統狀態和它們之間的變化、數據關係、邏輯流或對象類和它們的關係。

編寫形式化規格說明，這能夠經過使用數學上精確的形式化邏輯語言來定義需求。

由
於形式化規格說明具備很強的嚴密性和精確度，所以，所使用的形式化語言只有極少數軟件開發人員才熟悉，更不用說客戶了。雖然結構化的天然語言具備許多缺
點，但在大多數軟件工程中，它還是編寫需求文檔最現實的方法。包含了功能和非功能需求的基於文本的軟件需求規格說明已經爲大多數項目所接受。圖形化分析模
型經過提供另外一種需求視圖，加強了軟件需求規格說明。

軟件需求規格說明不只是系統測試和用戶文檔的基礎，也是全部子系列項目規劃、設計和編碼的基
礎。它應該儘量完整地描述系統預期的外部行爲和用戶可視化行爲。除了設計和實現上的限制，軟件需求規格說明不該該包括設計、構造、測試或工程管理的細
節。許多讀者使用軟件需求規格說明來達到不一樣的目的：

客戶和營銷部門依賴它來了解他們所能提供的產品。

項目經理根據包含在軟件需求規格說明中描述的產品來制定規劃並預測進度安排、工做量和資源。

軟件開發小組依賴它來理解他們將要開發的產品。

測試小組使用軟件需求規格說明中對產品行爲的描述制定測試計劃、測試用例和測試過程。

軟件維護和支持人員根據需求規格說明了解產品的某部分是作什麼的。

產品發佈組在需求規格說明和用戶界面設計的基礎上編寫客戶文檔，如用戶手冊和幫助屏幕等。

培訓人員根據需求規格說明和用戶文檔編寫培訓材料。

軟件需求規格說明做爲產品需求的最終成果必須具備綜合性：必須包括全部的需求。開發者和客戶不能做任何假設。若是任何所指望的功能或非功能需求未寫入軟件需求規格說明，那麼它將不能做爲協議的一部分而且不能在產品中出現。

我見過有一個項目忽然接到測試人員發出的錯誤災難的報告。結果是他們測試的是老版本的軟件需求規格說明，而他們以爲錯誤的地方正是產品所獨有的特性。他們的測試工做是徒勞的，由於他們一直在老版本的軟件需求規格說明中尋找錯誤的系統行爲。

在編寫軟件需求規格說明，但願讀者牢記如下的建議：

對節、小節和單個需求的號碼編排必須一致。

在右邊部分留下文本註釋區。

容許不加限制地使用空格。

正確使用各類可視化強調標誌（例如，黑體、下劃線、斜體和其它不一樣字體）。

建立目錄表和索引表有助於讀者尋找所需的信息。

對全部圖和表指定號碼和標識號，而且可按號碼進行查閱。

使用字處理程序中交叉引用的功能來查閱文檔中其它項或位置，而不是經過頁碼或節號。

爲了知足軟件需求規格說明的可跟蹤性和可修改性的質量標準，必須惟一肯定每一個軟件需求。這可
以使你在變動請求、修改歷史記錄、交叉引用或需求的可跟蹤矩陣中查閱特定的需求。因爲要達到這一目的，用單一的項目列表是不夠的，所以，我將描述幾個不一樣
的需求標識方法，並闡明它們的優勢與缺點。能夠選擇最適合你的方法。

(1)
序列號最簡單的方法是賦予每一個需求一個惟一的序列號，例如SRS-13。當一個新的需求加入到商業需求管理工具的數據庫以後，這些管理工具就會爲其分配一
個序列號（許多這樣的工具也支持層次化編號）。序列號的前綴表明了需求類型，例如SRS表明「軟件需求說明」。因爲序列號不能重用，因此把需求從數據庫中
刪除時，並不釋放其所佔據的序列號，而新的需求只能獲得下一個可用的序列號。這種簡單的編號方法並不能提供任何相關需求在邏輯上或層次上的區別，並且需求
的標識不能提供任何有關每一個需求內容的信息。

(2) 層次化編碼這也許是最經常使用的方法。若是功能需求出如今軟件需求規格說明中第3 .
2部分，那麼它們將具備諸如3.2.4.3這樣的標識號。標識號中的數字越多則表示該需求越詳細，屬於較低層次上的需求。即便在一箇中型的軟件需求規格說
明中，這些標識號也會擴展到許多位數字，而且這些標識也不提供任何有關每一個需求目的的信息。若是你要插入一個新的需求，那麼該需求所在部分其後全部需求的
序號將要增長。刪除或移去一個需求，那麼該需求所在部分其後全部需求的序號將要減小。但其餘地方的引用將混亂，對於這種簡單的層次化編號的一種改進方法是
對需求中主要的部分進行層次化編號，而後對於每一個部分中的單一功能需求用一個簡短文字代碼加上一個序列號來識別。例如，軟件需求規格說明可能包含「第
3.2.5部分—編輯功能」，並將此部分編寫成子模塊文檔，而後配置管理。

有時，你以爲缺乏特定需求的某些信息。在解決這個不肯定性之
前，可能必須與客戶商議、檢查與另外一個系統的接口或者定義另外一個需求。使用「待肯定」（to be determined,
TBD或採用漢語拼音略寫DQD）符號做爲標準指示器來強調軟件需求規格說明中這些需求的缺陷。經過這種方法，你能夠在軟件需求規格說明中查找所要澄清需
求的部分。記錄誰將解決哪一個問題、怎樣解決及何時解決。把每一個TBD編號並建立一個TBD列表，這有助於方便地跟蹤每一個項目。

在繼續
進行構造需求集合以前，必須解決全部的TBD問題，由於任何遺留下來的不肯定問題將會增長出錯的風險和需求返工。當開發人員遇到一個TBD問題或其它模糊
之處時，他可能不會返回到原始需求來解決問題。多半開發者對它進行猜想，但並不老是正確的。若是有TBD問題還沒有解決，而你又要繼續進行開發工做，那麼盡
可能推遲實現這些需求，或者解決這些需求的開放式問題，把產品的這部分設計得易於更改。

編寫優秀的需求文檔沒有現成固定的方法，最好是根據經驗進行。從過去所遇到的問題中可以使你受益不淺。許多需求文檔能夠經過使用有效的技術編寫風格和使用用戶術語而不是計算機專業術語的方式得以改進。

你在編寫優秀的需求文檔時，但願讀者還需牢記如下幾點建議：

保持語句和段落的簡短。

採用主動語態的表達方式。

編寫具備正確的語法、拼寫和標點的完整句子。

使用的術語與詞彙表中所定義的應該一致。需求陳述應該具備一致的樣式，例如「系統必須..」或者「用戶必須..」，並緊跟一個行爲動做和可觀察的結果。例如，「倉庫管理子系統必須顯示一張所請求的倉庫中有存貨的庫存清單。」

爲了減小不肯定性，必須避免模糊的、主觀的術語，例如，用戶友好、簡單、有效、、最新技術、優越的、可接受的等。當用客說「用戶友好」或者「快」時，你應該明確它們的真正含義而且在需求中闡明用戶的意圖。避免使用比較性的詞彙，定量地說明所須要提升的程度或者說清一些參數可接受的最大值和最小值。當客戶說明系統應該「處理」、「支持」或「管理」某些事情時，
你應該能理解客戶的意圖。因爲需求的編寫是層次化的，所以，能夠把頂層不明確的需求向低層詳細分解，直到消除不明確性爲止。

文檔的編寫人員不該該把多個需求集中在一個冗長的敘述段落中。在需求中諸如「和」，「或」之類的連詞就代表了該部分集中了多個需求。務必記住，不要在需求說明中使用「和/或」，「等等」之類的連詞。

8．需求分析的過程

需
求獲取是在問題及其最終解決方案之間架設橋樑的第一步。獲取需求的一個必不可少的結果是對項目中描述的客戶需求的廣泛理解。一旦理解了需求，分析者、開發
者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題以後才能開始設計系統，不然，對需求定義的任何改進，設計上都必須大
量的返工。把需求獲取集中在用戶任務上—而不是集中在用戶接口上—有助於防止開發組因爲草率處理設計問題而形成的失誤。

需求獲取、分析、
編寫需求規格說明和驗證並不遵循線性的順序，這些活動是相互隔開、增量和反覆的。當你和客戶合做時，你就將會問一些問題，而且取得他們所提供的信息（需求
獲取）。同時，你將處理這些信息以理解它們，並把它們分紅不一樣的類別，還要把客戶需求同可能的軟件需求相聯繫。而後，你可使客戶信息結構化，並編寫成文
檔和示意圖。下一步，就可讓客戶表明評審文檔並糾正存在的錯誤。這四個過程貫穿着需求開發的整個階段。

因爲軟件開發項目和組織文化的不
同，對於需求開發沒有一個簡單的、公式化的途徑。下面列出了1
4個步驟，你能夠利用它們指導你的需求開發活動。對於需求的任何子集，一旦你完成了第十三步，那麼你就能夠頗有信心地繼續進行系統的每一部分的設計、構
造，由於你將開發出一個好的產品:

1. 定義項目的視圖和範圍。

2. 肯定用戶類。

3. 在每一個用戶類中肯定適當的表明。

4. 肯定需求決策者和他們的決策過程。

5. 選擇你所用的需求獲取技術。

6. 運用需求獲取技術對做爲系統一部分的使用實例進行開發並設置優先級。

7. 從用戶那裏收集質量屬性的信息和其它非功能需求。

8. 詳細擬訂使用實例使其融合到必要的功能需求中。

9. 評審使用實例的描述和功能需求。

10. 若是有必要，就要開發分析模型用以澄清需求獲取的參與者對需求的理解。

11. 開發並評估用戶界面原型以助想像還未理解的需求。

12. 從使用實例中開發出概念測試用例。

13. 用測試用例來論證使用實例、功能需求、分析模型和原型。

14. 在繼續進行設計和構造系統每一部分以前，重複6~1 3步。

需求獲取多是軟件開發中最困難、最關鍵、最易出錯及最須要交流的方面。需求獲取只有經過有效的客戶—開發者的合做才能成功。分析者必須創建一個對問題進行完全探討的環境，而這些問題與產品有關。爲了方便清晰地進行交流，就要列出重要的小組，而不是假想全部的參與者都持有相同的見解。對需求問題的全面考察須要一種技術，利用這種技術不但考慮了問題的功能需求方面，還可討論項目的非功能需求。肯定用戶已經理解：對於某些功能的討論並不意味着即將在產品中實現
它。對於想到的需求必須集中處理並設定優先級，以免一個不能帶來任何益處的無限大的項目。