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