軟件需求是(1)用戶解決問(wèn)題或達(dá)到目標(biāo)所需的條件或權(quán)能(CapaBIlity)。
(2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。
(3)一種反映上面(1)或(2)所描述的條件或權(quán)能的文檔說(shuō)明。
（IEEE軟件工程標(biāo)準(zhǔn)詞匯表(1997年)中定義）
需求工程是隨著計(jì)算機(jī)的發(fā)展而發(fā)展的，在計(jì)算機(jī)發(fā)展的初期，軟件規(guī)模不大，軟件開(kāi)發(fā)所關(guān)注的是代碼編寫(xiě)，需求分析很少受到重視。后來(lái)軟件開(kāi)發(fā)引入了生命周期的概念，需求分析成為其第一階段。隨著軟件系統(tǒng)規(guī)模的擴(kuò)大，需求分析與定義在整個(gè)軟件開(kāi)發(fā)與維護(hù)過(guò)程中越來(lái)越重要，直接關(guān)系到軟件的成功與否。人們逐漸認(rèn)識(shí)到需求分析活動(dòng)不再僅限于軟件開(kāi)發(fā)的最初階段，它貫穿于系統(tǒng)開(kāi)發(fā)的整個(gè)生命周期。80年代中期，形成了軟件工程的子領(lǐng)域——需求工程(requirement engineering, RE)。進(jìn)入90年代以來(lái)，需求工程成為研究的熱點(diǎn)之一。從1993年起每?jī)赡昱e辦一次需求工程國(guó)際研討會(huì)(ISRE)，自1994年起每?jī)赡昱e辦一次需求工程國(guó)際會(huì)議(ICRE)，在1996年Springer-Verlag發(fā)行了一新的刊物——《Requirements Engineering》。一些關(guān)于需求工程的工作小組也相繼成立，如歐洲的RENOIR(Requirements Engineering Network of International COOPerating RESearch Groups )，并開(kāi)始開(kāi)展工作。
二、軟件需求的層次
下面這些定義是需求工程領(lǐng)域中常見(jiàn)術(shù)語(yǔ)的定義說(shuō)明。
軟件需求包括三個(gè)不同的層次—業(yè)務(wù)需求、用戶需求和功能需求—也包括非功能需求。業(yè)務(wù)需求( business requirement)反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說(shuō)明。用戶需求(user requirement) 文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例(Use Case)文檔或方案腳本(scenario)說(shuō)明中予以說(shuō)明。功能需求(functional requirement)定義了開(kāi)發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。所謂特性(feature)是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理能力并滿足業(yè)務(wù)需求。軟件需求各組成部分之間的關(guān)系如圖所示。
作為補(bǔ)充，軟件需求規(guī)格說(shuō)明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對(duì)開(kāi)發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制。質(zhì)量屬性是通過(guò)多種角度對(duì)產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對(duì)用戶和開(kāi)發(fā)人員都極為重要。 值得注意的一點(diǎn)是，需求并未包括設(shè)計(jì)細(xì)節(jié)、實(shí)現(xiàn)細(xì)節(jié)、項(xiàng)目計(jì)劃信息或測(cè)試信息。需求與這些沒(méi)有關(guān)系，它關(guān)注的是充分說(shuō)明你究竟想開(kāi)發(fā)什么。
Frederick BrOOks在他1987年的經(jīng)典的文章“No Silver Bullet：Essence and AccIDEnts ofSoftware Engineering ”中充分說(shuō)明了需求過(guò)程在軟件項(xiàng)目中扮演的重要角色：
開(kāi)發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么。最為困難的概念性工作便是編寫(xiě)出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。同時(shí)這也是一旦做錯(cuò)，將最終會(huì)給系統(tǒng)帶來(lái)極大損害的部分，并且以后再對(duì)它進(jìn)行修改也極為困難。
為什么這么說(shuō)呢，因?yàn)樵诖蠖鄶?shù)的軟件系統(tǒng)中，最終用戶可能都不清楚他的需求是什么，這是千真萬(wàn)確的。如果你的用戶告訴你需求就是這些了，不要相信他，繼續(xù)刨根問(wèn)底，直到你們都筋疲力盡了。
雖然聽(tīng)上去有些不可思議，但這是教訓(xùn)之談，在我從事的項(xiàng)目之中，沒(méi)有一個(gè)用戶在軟件接近完成的時(shí)候打電話對(duì)我說(shuō)，我看了你們的軟件，我想我必須改動(dòng)一些地方。在那些日子中，我甚至得了一種電話鈴音恐懼癥。
三、需求風(fēng)險(xiǎn)
下面列出了在做需求分析時(shí)一些很危險(xiǎn)的做法，如果你發(fā)現(xiàn)你的一些做法與之相似，那么，給自己一些時(shí)間，好好思考一下，這些做法會(huì)對(duì)你的軟件產(chǎn)生致命的影響。
1. 無(wú)足夠用戶參與
客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費(fèi)那么多功夫，開(kāi)發(fā)人員可能也不重視用戶的參與。究其原因：一是因?yàn)榕c用戶合作不如編寫(xiě)代碼有意思；二是因?yàn)殚_(kāi)發(fā)人員覺(jué)得已經(jīng)明白用戶的需求了。在某些情況下，與實(shí)際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應(yīng)讓具有代表性的用戶在項(xiàng)目早期直接參與到開(kāi)發(fā)隊(duì)伍中，并一同經(jīng)歷整個(gè)開(kāi)發(fā)過(guò)程。 最重要的就是用戶必須要重視他的軟件，必須讓他明白：如果失敗，他的損失最大(當(dāng)然你的損失也不小，但這時(shí)候你必須讓他重視這項(xiàng)工作)。如果用戶不夠重視，想辦法解決，否則你就不用再繼續(xù)了。
2. 用戶需求的不斷增加
在開(kāi)發(fā)中若不斷地補(bǔ)充需求，項(xiàng)目就越變?cè)烬嫶笠灾鲁^(guò)其計(jì)劃及預(yù)算范圍。這使得問(wèn)題更難解決。實(shí)際上，問(wèn)題根源在于用戶需求的改變和開(kāi)發(fā)者對(duì)新需求所作的修改。要想把需求變更范圍控制到最小，必須一開(kāi)始就對(duì)項(xiàng)目視圖、范圍、目標(biāo)、約束限制和成功標(biāo)準(zhǔn)給予明確說(shuō)明，并將此說(shuō)明作為評(píng)價(jià)需求變更和新特性的參照框架。說(shuō)明中包括了對(duì)每種變更進(jìn)行變更影響因素分析的變更控制過(guò)程，有助于所有風(fēng)險(xiǎn)承擔(dān)者明白業(yè)務(wù)決策的合理性，即為何進(jìn)行某些變更，相應(yīng)消耗的時(shí)間、資源或特性上的折中。
產(chǎn)品開(kāi)發(fā)中不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù)。插入補(bǔ)丁代碼使模塊違背強(qiáng)內(nèi)聚、松耦合的設(shè)計(jì)原則，特別是如果項(xiàng)目配置管理工作不完善的話，收回變更和刪除特性會(huì)帶來(lái)問(wèn)題。如果你盡早地區(qū)別這些可能帶來(lái)變更的特性，你就能開(kāi)發(fā)一個(gè)更為健壯的結(jié)構(gòu)，并能更好地適應(yīng)它。這樣設(shè)計(jì)階段需求變更不會(huì)直接導(dǎo)致補(bǔ)丁代碼，同時(shí)也有利于減少因變更導(dǎo)致質(zhì)量的下降。
最糟糕的莫過(guò)于用戶覺(jué)得如果不再加點(diǎn)什么功能就對(duì)不起自己。我曾經(jīng)看過(guò)一個(gè)數(shù)據(jù)倉(cāng)庫(kù)的一期工程，在設(shè)計(jì)階段沒(méi)有很好的定義范圍，當(dāng)我向項(xiàng)目管理者提出這個(gè)問(wèn)題的時(shí)候，他認(rèn)為都已經(jīng)說(shuō)好了，合同上也寫(xiě)清楚了，并沒(méi)有加以重視。可是最后，用戶提出的修改意見(jiàn)已經(jīng)遠(yuǎn)遠(yuǎn)超出了范圍，項(xiàng)目時(shí)間也延長(zhǎng)了一倍。整個(gè)的項(xiàng)目組成員疲憊不堪，可是卻不斷的接到用戶投訴說(shuō)項(xiàng)目失敗。
3. 模棱兩可的需求
模棱兩可是需求規(guī)格說(shuō)明中最為可怕的問(wèn)題(Lawrence 1996)。它的一層含義是指諸多讀者對(duì)需求說(shuō)明產(chǎn)生了不同的理解；另一層含義是指單個(gè)讀者能用不止一個(gè)方式來(lái)解釋某個(gè)需求說(shuō)明。
模棱兩可的需求會(huì)使不同的風(fēng)險(xiǎn)承擔(dān)者產(chǎn)生不同的期望，它會(huì)使開(kāi)發(fā)人員為錯(cuò)誤問(wèn)題而浪費(fèi)時(shí)間，并且使測(cè)試者與開(kāi)發(fā)者所期望的不一致。一位系統(tǒng)測(cè)試人員曾告訴我，她所在的測(cè)試組經(jīng)常對(duì)需求理解有誤，以致不得不重寫(xiě)許多測(cè)試用例并重做許多測(cè)試。
模棱兩可的需求帶來(lái)不可避免的后果便是返工—重做一些你認(rèn)為已做好的事情。返工會(huì)耗費(fèi)開(kāi)發(fā)總費(fèi)用的40%，而70%～85%的重做是由于需求方面的錯(cuò)誤所導(dǎo)致的(leffingwell 1997)。想像一下如果你能減少一半的返工會(huì)是怎樣的情況？你能更快地開(kāi)發(fā)出產(chǎn)品，在同樣的時(shí)間內(nèi)開(kāi)發(fā)更多、更好的產(chǎn)品，甚至能偶爾回家休息休息。
處理模棱兩可需求的一種方法是組織好負(fù)責(zé)從不同角度審查需求的隊(duì)伍。僅僅簡(jiǎn)單瀏覽一下需求文檔是不能解決模棱兩可問(wèn)題的。如果不同的評(píng)審者從不同的角度對(duì)需求說(shuō)明給予解釋?zhuān)總€(gè)評(píng)審人員都真正了解需求文檔，這樣二義性就不會(huì)直到項(xiàng)目后期才被發(fā)現(xiàn)，那時(shí)再發(fā)現(xiàn)的話會(huì)使得更正代價(jià)很大。
4. 不必要的特性
“畫(huà)蛇添足”是指開(kāi)發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說(shuō)明中并未涉及的新功能。經(jīng)常發(fā)生的情況是用戶并不認(rèn)為這些功能性很有用，以致在其上耗費(fèi)的努力“白搭”了。
開(kāi)發(fā)人員應(yīng)當(dāng)為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識(shí)的思路，具體提供哪些功能要在客戶所需與開(kāi)發(fā)人員在允許時(shí)限內(nèi)的技術(shù)可行性之間求得平衡，開(kāi)發(fā)人員應(yīng)努力使功能簡(jiǎn)單易用，而不要未經(jīng)客戶同意，擅自脫離客戶要求，自作主張。
同樣，客戶有時(shí)也可能要求一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能，而實(shí)現(xiàn)這些功能只能徒耗時(shí)間和成本。為了將“畫(huà)蛇添足”的危害盡量減小，應(yīng)確信：你明白為什么要包括這些功能，以及這些功能的“來(lái)龍去脈”，這樣使得需求分析過(guò)程始終是注重那些能使用戶完成他們業(yè)務(wù)任務(wù)的核心功能。
時(shí)刻記?。很浖晒Φ臉?biāo)準(zhǔn)是是否解決用戶的問(wèn)題，而不是它有多Cool的功能。
5. 過(guò)于精簡(jiǎn)的規(guī)格說(shuō)明
有時(shí)，客戶并不明白需求分析有如此重要，于是只作一份簡(jiǎn)略之至的規(guī)格說(shuō)明，僅涉及了產(chǎn)品概念上的內(nèi)容，然后讓開(kāi)發(fā)人員在項(xiàng)目進(jìn)展中去完善，結(jié)果很可能出現(xiàn)的是開(kāi)發(fā)人員先建立產(chǎn)品的結(jié)構(gòu)之后再完成需求說(shuō)明。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況(McConnell 1996)，不過(guò)商業(yè)應(yīng)用大多都不是這種情況。在大多數(shù)情況下，這會(huì)給開(kāi)發(fā)人員帶來(lái)挫折(使他們?cè)诓徽_的假設(shè)前提和極其有限的指導(dǎo)下工作)，也會(huì)給客戶帶來(lái)煩惱(他們無(wú)法得到他們所設(shè)想的產(chǎn)品)。
6. 忽略了用戶分類(lèi)
大多數(shù)產(chǎn)品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同。如果你不能在項(xiàng)目早期就針對(duì)所有這些主要用戶進(jìn)行分類(lèi)的話，必然導(dǎo)致有的用戶對(duì)產(chǎn)品感到失望。例如，菜單驅(qū)動(dòng)操作對(duì)高級(jí)用戶太低效了，但含義不清的命令和快捷鍵又會(huì)使不熟練的用戶感到困難。
7. 不準(zhǔn)確的計(jì)劃
“上述是我對(duì)新產(chǎn)品的看法，好，現(xiàn)在你能告訴我你什么時(shí)候能完成嗎？”許多開(kāi)發(fā)人員都遇到這種難題。對(duì)需求分析缺乏理解會(huì)導(dǎo)致過(guò)分樂(lè)觀的估計(jì)，而當(dāng)不可避免的超支發(fā)生時(shí)，會(huì)帶來(lái)頗多麻煩。據(jù)報(bào)道，導(dǎo)致需求過(guò)程中軟件成本估計(jì)極不準(zhǔn)確的原因主要有以下五點(diǎn)：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說(shuō)明和不完善的需求分析(Davis 1995)。
對(duì)不準(zhǔn)確的要求所提問(wèn)題的正確響應(yīng)是“等我真正明白你的需求時(shí)，我就會(huì)來(lái)告訴你”?；诓怀浞中畔⒑臀唇?jīng)深思的對(duì)需求不成熟的估計(jì)很容易為一些因素左右。要作出估計(jì)時(shí)，最好還是給出一個(gè)范圍(如最好的情況下，很可能的，最壞情況下)或一個(gè)可信賴(lài)的程度(我有9 0 %的把握，我能在8周內(nèi)完成)。未經(jīng)準(zhǔn)備的估計(jì)通常是作為一種猜測(cè)給出的，聽(tīng)者卻認(rèn)為是一種承諾。因此我們要盡力給出可達(dá)到的目標(biāo)并堅(jiān)持完成它。
四、什么是優(yōu)秀的需求
討論軟件需求的文章有很多，對(duì)于需求的標(biāo)準(zhǔn)也不盡相同，這里我想用NASA的軟件開(kāi)發(fā)過(guò)程中的概念，軟件需求過(guò)程的標(biāo)準(zhǔn)是：清楚(Clear)、完整(Complete)、一致(ConsiSTent)、可測(cè)試(Testable)，此外還有其他的概念，如可跟蹤的、可修改的等等。
清楚：目前大多數(shù)的需求分析采用的仍然是自然語(yǔ)言（因?yàn)槿绻捎眯问交Z(yǔ)言的話，和用戶的溝通將成為一個(gè)大問(wèn)題，這意味著客戶在開(kāi)發(fā)軟件之前必須先進(jìn)行形式化語(yǔ)言培訓(xùn)，這是不現(xiàn)實(shí)的）。自然語(yǔ)言對(duì)需求分析最大的弊病就是它的二義性。所以我們不得不對(duì)需求分析中采用的語(yǔ)言做某些限制。例如盡量采用主語(yǔ)＋動(dòng)作的簡(jiǎn)單表達(dá)方式。說(shuō)白了，需求分析中的描述讓人看上去像是剛學(xué)習(xí)寫(xiě)作的小孩子就對(duì)了，千萬(wàn)不要采用疑問(wèn)句、修飾這些華麗的表達(dá)方式。
除了語(yǔ)言的二義性之外，主意不要使用行話，就是計(jì)算機(jī)術(shù)語(yǔ)。需求分析最重要的是和用戶溝通，可是用戶多半不是計(jì)算機(jī)的專(zhuān)業(yè)人士，如果在需求分析中使用了行話，就會(huì)造成用戶理解上的困難。
打個(gè)比方，如果你要做一個(gè)銀行的信用卡系統(tǒng)，你就可以這樣描述軟件需求：銀行的卡部管理信用卡，每張信用卡只屬于一個(gè)帳戶。信用卡有卡號(hào)、余額。一張信用卡有多筆的交易記錄。
完整：再也沒(méi)有什么比軟件開(kāi)發(fā)接近完成是發(fā)現(xiàn)遺漏了一項(xiàng)需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遺漏需求而不得不返工，這簡(jiǎn)直就是惡夢(mèng)?？墒橇钊诉z憾的是，需求的遺漏是很經(jīng)常發(fā)生的事情，不僅僅是你的問(wèn)題，更多的問(wèn)題發(fā)生在用戶那里，他們不知道該做些什么。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過(guò)程的各方各面，貫穿了整個(gè)過(guò)程，從最初的計(jì)劃制定到最后的需求評(píng)審。至于完整性的詳細(xì)討論，我們會(huì)在下面的章節(jié)中討論，現(xiàn)在你只需要拼命的想象缺乏完整性的壞處，直到你出了一身的冷汗。出了嗎？好，那我們繼續(xù)。
一致：一致性也是一個(gè)比較大的概念，很難用幾句話講清楚。還記得我們?cè)陂_(kāi)始的時(shí)候提到的需求的層次嗎？簡(jiǎn)單的來(lái)說(shuō)，就是用戶需求必須和業(yè)務(wù)需求一致，功能需求必須和用戶需求一致。嚴(yán)格的遵守不同層次間的一致性關(guān)系，就可以保證最后開(kāi)發(fā)出來(lái)的軟件系統(tǒng)不會(huì)偏離最初的實(shí)現(xiàn)目標(biāo)。在實(shí)現(xiàn)過(guò)程中，我們還必須把一致性關(guān)系細(xì)化。比如說(shuō)用戶需求不能超出先前指定的范圍。
可測(cè)試：大家覺(jué)得一個(gè)項(xiàng)目的測(cè)試從什么時(shí)候開(kāi)始呢？有人說(shuō)從編碼完成后開(kāi)始。更清楚一點(diǎn)的說(shuō)是編碼的時(shí)候同時(shí)進(jìn)行單元測(cè)試，編碼完成后進(jìn)行系統(tǒng)測(cè)試。這些都沒(méi)有錯(cuò)。但是實(shí)際上測(cè)試是從需求分析過(guò)程就開(kāi)始了。需求分析是測(cè)試計(jì)劃的輸入和參照。這就要求需求分析是可測(cè)試的。什么是可測(cè)試呢？“我們要用新的系統(tǒng)完成報(bào)表自動(dòng)化處理”，你覺(jué)得這個(gè)需求是可測(cè)試的嗎？當(dāng)然不是，報(bào)表包括哪些？自動(dòng)化處理的標(biāo)準(zhǔn)是什么？這些在需求中都沒(méi)有說(shuō)明。因此這項(xiàng)需求是無(wú)法測(cè)試的，就是不具有可測(cè)試性。說(shuō)到這里，大家可能就會(huì)明白之前的需求的幾項(xiàng)標(biāo)準(zhǔn)都是為了保證需求的可測(cè)試性的。事實(shí)就是這樣，只有系統(tǒng)的所有需求是可以被測(cè)試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統(tǒng)是成功的。
五、軟件需求過(guò)程
軟件需求工程主要包括兩個(gè)方面：需求開(kāi)發(fā)和需求管理。
需求開(kāi)發(fā)可進(jìn)一步分為：需求獲取、需求分析、編寫(xiě)需求規(guī)格和需求驗(yàn)證四個(gè)階段。各階段說(shuō)明如下：
需求獲取階段：
這一階段的核心任務(wù)就是確定三個(gè)層次的需求，對(duì)于業(yè)務(wù)層要強(qiáng)調(diào)明確業(yè)務(wù)總目標(biāo)及使用范圍，對(duì)于用戶層，要強(qiáng)調(diào)明晰用戶工作流程，對(duì)于功能層還要收集系統(tǒng)運(yùn)行環(huán)境的限制等非功能性需求。不同的時(shí)間、不同的用戶會(huì)由于不同的業(yè)務(wù)目標(biāo)及使用范圍而提出不盡相同的需求，同時(shí)由于沒(méi)有約定提出方式也會(huì)有各不相同的表現(xiàn)形式。針對(duì)上述問(wèn)題，首先要確定用戶代表并對(duì)其在需求中的主次地位于以劃分；其次要確定需求的整個(gè)開(kāi)發(fā)過(guò)程，最后還要明確不同層次的需求要以約定的形式出具文檔，以備雙方的交流及問(wèn)題檢查。
需求分析階段：
這一階段的核心任務(wù)就是確定并完善需求。初期階段所獲得的大量需求往往是不系統(tǒng)、不完整甚至個(gè)別需求是錯(cuò)誤的、不必要的，只有通過(guò)提煉、分析和仔細(xì)審查需求，彼此溝通，采用適當(dāng)?shù)谋憩F(xiàn)形式，比如繪制業(yè)務(wù)目標(biāo)關(guān)聯(lián)圖、繪制功能結(jié)構(gòu)示意圖、編制數(shù)據(jù)字典、編寫(xiě)用戶實(shí)例等，明白需求含義并找出其中的錯(cuò)誤、遺漏或不足的地方，尤其是應(yīng)采用特定符號(hào)標(biāo)識(shí)需求優(yōu)先級(jí)。
編寫(xiě)需求規(guī)格階段：
這一階段的任務(wù)強(qiáng)調(diào)將已收集并做分析處理的需求經(jīng)編制整理形成規(guī)范化的可視文檔，即軟件需求規(guī)格說(shuō)明書(shū)。
需求驗(yàn)證階段。
本階段是需求開(kāi)發(fā)工作的最后階段，要確定在第三階段所編制的需求文檔是否與預(yù)期結(jié)果一致，是否符合高質(zhì)量需求的評(píng)價(jià)標(biāo)準(zhǔn)。這項(xiàng)工作可以通過(guò)評(píng)審來(lái)完成。評(píng)審可以根據(jù)用戶代表的個(gè)人偏好、習(xí)慣予以審查需求，也可以遵循行業(yè)質(zhì)量控制辦法制定嚴(yán)格的步驟進(jìn)行審查，這主要取決于項(xiàng)目的大小、需求及各個(gè)部分的重要程度。
需求管理需要"建立并維護(hù)在軟件工程中同客戶達(dá)成的契約"。這種契約都包含在編寫(xiě)的需求規(guī)格說(shuō)明與模型中?？蛻舻慕邮軆H是需求成功的一半，開(kāi)發(fā)人員也必須能夠接受他們，并真正把需求應(yīng)用到產(chǎn)品中。
通常的需求管理活動(dòng)包括：
定義需求基線(迅速制定需求文檔的主體)。
評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它。
以一種可控制的方式將需求變更融入到項(xiàng)目中。
使當(dāng)前的項(xiàng)目計(jì)劃與需求一致。
估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾(約定)。
讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來(lái)以實(shí)現(xiàn)跟蹤。
在整個(gè)項(xiàng)目過(guò)程中跟蹤需求狀態(tài)從其變更情況。
六、軟件需求方法
軟件需求分析方法大體分為如下四類(lèi)：結(jié)構(gòu)化方法、面向?qū)ο蠓椒?/a>、面向控制方法和面向數(shù)據(jù)方法。限于篇幅，本文將主要從結(jié)構(gòu)化方法和面向?qū)ο?/a>方法以及RUP三個(gè)方面進(jìn)行簡(jiǎn)要的探討。
結(jié)構(gòu)化分折(Structured Analysis, SA)方法是一種單純的由頂向下逐步求精的功能分解方法。分析員首先用上下文圖表(稱(chēng)為數(shù)據(jù)流圖DFD)表示系統(tǒng)的所有輸入／輸出，然后反復(fù)地對(duì)系統(tǒng)求精，每次求精都表示成一更詳細(xì)的DFD從而建立關(guān)于系統(tǒng)的一個(gè)DFD層次。為保存DFD中的這些信息，使用數(shù)據(jù)字典來(lái)存取相關(guān)的定義、結(jié)構(gòu)及目的。SA方法是目前實(shí)際應(yīng)用效力廣泛的需求工程技術(shù)。它具有較好的分別、抽象能力，為開(kāi)發(fā)小組找到了一種中間語(yǔ)言，易于軟件人員所掌握。但它離應(yīng)用領(lǐng)域尚有一定的距離，難以直接應(yīng)用領(lǐng)域術(shù)民與軟件設(shè)計(jì)也有一段不小的距離因而為開(kāi)發(fā)小組的思想交流帶來(lái)了一定的困難。
面向對(duì)象（Object Oriented, OO）的方法把分析建立在系統(tǒng)對(duì)象以及對(duì)象間交互的基礎(chǔ)之上，使得我們能以3個(gè)最基本的方法框架——對(duì)象及其屬性、分類(lèi)結(jié)構(gòu)和集合結(jié)構(gòu)來(lái)定義和溝通需求。面向?qū)ο蟮膯?wèn)題分析模型從3個(gè)側(cè)面進(jìn)行描述，即對(duì)象模型(對(duì)象的靜態(tài)結(jié)構(gòu))、動(dòng)態(tài)模型(對(duì)象相互作用的順序)和功能模型(數(shù)據(jù)變換及功能依存關(guān)系)。需求工程的抽象原則、層次原則和分割原則同樣適用于面向?qū)ο蠓椒?，即?duì)象抽象與功能抽象原則是一樣的，也是從高級(jí)到低級(jí)、從邏輯到物理，逐級(jí)細(xì)分．每一級(jí)抽象都重復(fù)對(duì)象建模(對(duì)象識(shí)別)一動(dòng)態(tài)建模(事件識(shí)別)一功能建模(操作識(shí)別)的過(guò)程，直到每一個(gè)對(duì)象實(shí)例在物理(程序編碼)上全部實(shí)現(xiàn)為止。
面向?qū)ο笮枨蠓治?OORA)利用一些基本概念來(lái)建立相應(yīng)模型，以表達(dá)目標(biāo)系統(tǒng)的不同側(cè)面。盡管不同的方法所采用的具體模型不盡相同，但都無(wú)外乎用如下五個(gè)基本模型來(lái)描述軟件需求:
整體—部分模型：該模型描述對(duì)象(類(lèi))是如何由簡(jiǎn)單的對(duì)象（類(lèi)）構(gòu)成的。將一個(gè)復(fù)雜對(duì)象(類(lèi))描述成一個(gè)由交互作用的若干對(duì)象(類(lèi))構(gòu)成的結(jié)構(gòu)的能力是OO途徑的突出優(yōu)點(diǎn)。該模型亦稱(chēng)聚合模型。
分類(lèi)模型：分類(lèi)模型描述類(lèi)之間的繼承關(guān)系。與聚合關(guān)系不同，它說(shuō)明的是一個(gè)類(lèi)可以繼承另一個(gè)或另一些類(lèi)的成分，以實(shí)現(xiàn)類(lèi)中成分的復(fù)用。
類(lèi)—對(duì)象模型：分析過(guò)程必須描述屬于每個(gè)類(lèi)的對(duì)象所具有的行為，這種行為描述的詳細(xì)程度可以根據(jù)具體情況而定。既可以只說(shuō)明行為的輸入、輸出和功能，也可以采用比較形式的途徑來(lái)精確地描述其輸入、輸出及其相應(yīng)的類(lèi)型甚至使用偽碼或小說(shuō)明的形式來(lái)詳細(xì)刻畫(huà)。
對(duì)象交互模型：一個(gè)面向?qū)ο蟮南到y(tǒng)模型必須描述其中對(duì)象的交互方法。如前所述，對(duì)象交互是通過(guò)消息傳遞來(lái)實(shí)現(xiàn)的。事實(shí)人對(duì)象交互也可看作是對(duì)象行為之間的引用關(guān)系。因此，對(duì)象交互模型就要刻畫(huà)對(duì)象之間的消息流。對(duì)應(yīng)于不同的詳細(xì)程度，有不同的消息流描述分析，分析人員應(yīng)根據(jù)具體館況而選擇。一般地，一個(gè)詳細(xì)的對(duì)象交互模型能夠說(shuō)明對(duì)象之間的消息及其流向，并且同時(shí)說(shuō)明該消息將激活的對(duì)象及行為。一個(gè)不太詳細(xì)的對(duì)象交互模型可以只說(shuō)明對(duì)象之間有消息，并指明其流向即可。還有一種狀況就是介于此兩者之間。
狀態(tài)模型：在狀態(tài)模型中，把一個(gè)對(duì)象看作是一個(gè)有限狀態(tài)機(jī)，由一個(gè)狀態(tài)到另一狀態(tài)的轉(zhuǎn)變稱(chēng)作狀態(tài)轉(zhuǎn)換。狀態(tài)模型將對(duì)象的行為描述成其不同狀態(tài)之間的通路。它也可以刻畫(huà)動(dòng)態(tài)系統(tǒng)中對(duì)象的創(chuàng)建和廢除，并稱(chēng)由對(duì)象的創(chuàng)建到對(duì)象的廢除狀態(tài)之間的退路為對(duì)象的生存期。
狀態(tài)模型既可以用狀態(tài)轉(zhuǎn)換因的圖形化手段，又可用決策表或稱(chēng)決策矩陣的形式來(lái)表。
3、基于RUP的軟件需求
RUP（Rational Unified Process）是Rational公司開(kāi)發(fā)和維護(hù)的過(guò)程產(chǎn)品。RUP是工程化的軟件開(kāi)發(fā)過(guò)程，它提供了在開(kāi)發(fā)機(jī)構(gòu)中分派任務(wù)和責(zé)任的紀(jì)律化方法。RUP不僅僅是一個(gè)簡(jiǎn)單的過(guò)程，而是一個(gè)通用的過(guò)程框架，可用于各種不同類(lèi)型的軟件系統(tǒng)、各種不同的應(yīng)用領(lǐng)域、各種不同類(lèi)型的組織、各種不同的功能級(jí)別以及各種不同的項(xiàng)目規(guī)模。RUP的突出特點(diǎn)可以由以下三個(gè)關(guān)鍵詞來(lái)體現(xiàn)——用例驅(qū)動(dòng)、以構(gòu)架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構(gòu)架提供了一種結(jié)構(gòu)來(lái)指導(dǎo)迭代過(guò)程中的工作，而用例則確定了目標(biāo)井驅(qū)動(dòng)每次迭代的工作。
進(jìn)行需求分析的基礎(chǔ)是要獲得用戶的需要，為了完成這一工作，必須建立業(yè)務(wù)模型，通過(guò)描述業(yè)務(wù)規(guī)則、業(yè)務(wù)邏輯，明確業(yè)務(wù)過(guò)程并對(duì)其進(jìn)行規(guī)范、優(yōu)化。對(duì)于一個(gè)系統(tǒng)，在建立業(yè)務(wù)模型時(shí)，應(yīng)從3個(gè)方面來(lái)描述其特性：功能、行為、數(shù)據(jù)，對(duì)應(yīng)于這些特性。
4、軟件需求方法的比較分析
基于上述分析可知，結(jié)構(gòu)化分析方法與面向?qū)ο蠓治龇椒ǖ膮^(qū)別主要體現(xiàn)在兩個(gè)方面：
* 將系統(tǒng)分解成于系統(tǒng)的方式不同。前者將系統(tǒng)描述成一組交互作用的處理，后者則描述成一組交互作用的對(duì)象。
* 子系統(tǒng)之間的交互關(guān)系的描述方式不一樣。前者加工之間的交互是通過(guò)不太精確的數(shù)據(jù)流來(lái)表示的，而后者對(duì)象之間通過(guò)消息傳遞交互關(guān)系。
因此，面向?qū)ο筌浖枨蠓治龅慕Y(jié)果能更好地刻畫(huà)現(xiàn)實(shí)世界，處理復(fù)雜問(wèn)題，對(duì)象比過(guò)程更具有穩(wěn)定性，便于維護(hù)與復(fù)用。
（出處:UML軟件工程，博客中國(guó)）
七、軟件需求說(shuō)明書(shū)
軟件需求說(shuō)明書(shū)的編制是為了使用戶和軟件開(kāi)發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解， 使之成為整個(gè)開(kāi)發(fā)工作的基礎(chǔ)。編制軟件需求說(shuō)明書(shū)的內(nèi)容要求如下：
1 引言
1．1編寫(xiě)目的
說(shuō)明編寫(xiě)這份軟件需求說(shuō)明書(shū)的目的，指出預(yù)期的讀者。
1．2背景
說(shuō)明：
a．待開(kāi)發(fā)的軟件系統(tǒng)的名稱(chēng)；
b．本項(xiàng)目的任務(wù)提出者、開(kāi)發(fā)者、用戶及實(shí)現(xiàn)該軟件的計(jì)算中心或計(jì)算機(jī)網(wǎng)絡(luò)；
C．該軟件系統(tǒng)同其他系統(tǒng)或其他機(jī)構(gòu)的基本的相互來(lái)往關(guān)系。
1．3定義
列出本文件中用到的專(zhuān)門(mén)術(shù)語(yǔ)的定義和外文首字母組詞的原詞組。
1．4參考資料
列出用得著的參考資料，如：
a．本項(xiàng)目的經(jīng)核準(zhǔn)的計(jì)劃任務(wù)書(shū)或合同、上級(jí)機(jī)關(guān)的批文；
b．屬于本項(xiàng)目的其他已發(fā)表的文件；
c．本文件中各處引用的文件、資料、包括所要用到的軟件開(kāi)發(fā)標(biāo)準(zhǔn)。 列出這些文件資料的標(biāo)題、文件編號(hào)、發(fā)表日期和出版單位，說(shuō)明能夠得到這些文件資料的來(lái)源。
2 任務(wù)概述
2．1目標(biāo)
敘述該項(xiàng)軟件開(kāi)發(fā)的意圖、應(yīng)用目標(biāo)、作用范圍以及其他應(yīng)向讀者說(shuō)明的有關(guān)該軟件開(kāi)發(fā)的背景材料。解釋被開(kāi)發(fā)軟件與其他有關(guān)軟件之間的關(guān)系。如果本軟件產(chǎn)品是一項(xiàng)獨(dú)立的軟件，而且全部?jī)?nèi)容自含，則說(shuō)明這一點(diǎn)。如果所定義的產(chǎn)品是一個(gè)更大的系統(tǒng)的一個(gè)組成部分，則應(yīng)說(shuō)明本產(chǎn)品與該系統(tǒng)中其他各組成部分之間的關(guān)系，為此可使用一張方框圖來(lái)說(shuō)明該系統(tǒng)的組成和本產(chǎn)品同其他各部分的聯(lián)系和接口。
2．2用戶的特點(diǎn)
列出本軟件的最終用戶的特點(diǎn)，充分說(shuō)明操作人員、維護(hù)人員的教育水平和技術(shù)專(zhuān)長(zhǎng)，以及本軟件的預(yù)期使甩頻度。這些是軟件設(shè)計(jì)工作的重要約束
2．3假定和約束
列出進(jìn)行本軟件開(kāi)發(fā)工作的假定和約束，例如經(jīng)費(fèi)限制、開(kāi)發(fā)期限等。
3 需求規(guī)定
3．1對(duì)功能的規(guī)定
用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項(xiàng)定量和定性地?cái)⑹鰧?duì)軟件所提出的功能要求，說(shuō)明輸入什么量、經(jīng)怎樣的處理、得到什么輸出，說(shuō)明軟件應(yīng)支持的終端數(shù)和應(yīng)支持的并行操作的用戶數(shù)。
3．2對(duì)性能的規(guī)定
3．2．1精度
說(shuō)明對(duì)該軟件的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過(guò)程中的精度。
3．2．2時(shí)間特性要求
說(shuō)明對(duì)于該軟件的時(shí)間特性要求，如對(duì)：
a．響應(yīng)時(shí)間；
b．更新處理時(shí)間；
c．?dāng)?shù)據(jù)的轉(zhuǎn)換和傳送時(shí)間；
d．解題時(shí)間； 等的要求。
3．2．3靈活性
說(shuō)明對(duì)該軟件的靈活性的要求，即當(dāng)需求發(fā)生某些變化時(shí)，該軟件對(duì)這些變化的適應(yīng)能力，如：
a．操作方式上的變化；
b．運(yùn)行環(huán)境的變化；
c．同其他軟件的接口的變化；
d．精度和有效時(shí)限的變化；
e．計(jì)劃的變化或改進(jìn)。
對(duì)于為了提供這些靈活性而進(jìn)行的專(zhuān)門(mén)設(shè)計(jì)的部分應(yīng)該加以標(biāo)明。
3．3輸人輸出要求
解釋各輸入輸出數(shù)據(jù)類(lèi)型，并逐項(xiàng)說(shuō)明其媒體、格式、數(shù)值范圍、精度等。對(duì)軟件的數(shù)據(jù)輸出及必須標(biāo)明的控制輸出量進(jìn)行解釋并舉例，包括對(duì)硬拷貝報(bào)告（正常結(jié)果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報(bào)告的描述。
3．4數(shù)據(jù)管理能力要求
說(shuō)明需要管理的文卷和記錄的個(gè)數(shù)、表和文卷的大小規(guī)模，要按可預(yù)見(jiàn)的增長(zhǎng)對(duì)數(shù)據(jù)及其分量的存儲(chǔ)要求作出估算。
3．5故障處理要求
列出可能的軟件、硬件故障以及對(duì)各項(xiàng)性能而言所產(chǎn)生的后果和對(duì)故障處理的要求。
3．6其他專(zhuān)門(mén)要求
如用戶單位對(duì)安全保密的要求，對(duì)使用方便的要求，對(duì)可維護(hù)性、可補(bǔ)充性、易讀性、可靠性、運(yùn)行環(huán)境可轉(zhuǎn)換性的特殊要求等。
4 運(yùn)行環(huán)境規(guī)定
4．1設(shè)備
列出運(yùn)行該軟件所需要的硬設(shè)備。說(shuō)明其中的新型設(shè)備及其專(zhuān)門(mén)功能，包括：
a．處理器型號(hào)及內(nèi)存容量；
b．外存容量、聯(lián)機(jī)或脫機(jī)、媒體及其存儲(chǔ)格式，設(shè)備的型號(hào)及數(shù)量；
c．輸入及輸出設(shè)備的型號(hào)和數(shù)量，聯(lián)機(jī)或脫機(jī)；
d．?dāng)?shù)據(jù)通信設(shè)備的型號(hào)和數(shù)量；
e．功能鍵及其他專(zhuān)用硬件
4．2支持軟件
列出支持軟件,包括要用到的操作系統(tǒng)、編譯（或匯編）程序、測(cè)試支持軟件等。
4．3 接口
說(shuō)明該軟件同其他軟件之間的接口、數(shù)據(jù)通信協(xié)議等。
4．4控制
說(shuō)明控制該軟件的運(yùn)行的方法和控制信號(hào)，并說(shuō)明這些控制信號(hào)的來(lái)源。
聯(lián)系客服
