01軟件需求之思想和方法論

.軟件需求的思想與方法論 61.1高質(zhì)量需求工程的意義 61.2需求工程與需求開(kāi)發(fā)方法論 61.2.1需求工程模型 61.2.2需求開(kāi)發(fā)的基本概念 81.2.3軟件質(zhì)量與需求開(kāi)發(fā) 101.2.4正確的需求開(kāi)發(fā)方法論 122.優(yōu)秀需求規(guī)格說(shuō)明具有的特性 142.1需求具有清晰的層次 142.2良好的需求描述的特征 152.3良好需求規(guī)格說(shuō)明的特征 162.4對(duì)軟件工程方法的重新思考 172.4.1瀑布方式的問(wèn)題 173需求的滾動(dòng)式完善模式 193.1需求在動(dòng)態(tài)中的滾動(dòng)完善 193.2更點(diǎn)放在哪里更合適？ 203.3現(xiàn)代軟件過(guò)程域之間的關(guān)系 214.復(fù)雜系統(tǒng)的需求分解 224.1前期進(jìn)行合理劃分 224.1.1子系統(tǒng)的分解原則 224.1.2功能單元的分解原則 234.1.3關(guān)于派生的需求 244.1.4處理極其復(fù)雜的系統(tǒng)的建議 245.分層的需求組織方法 255.1分層的需求創(chuàng)建過(guò)程 255.1.1創(chuàng)建系統(tǒng)級(jí)的需求規(guī)格說(shuō)明 265.1.2進(jìn)行子系統(tǒng)劃分 265.1.3開(kāi)發(fā)子系統(tǒng)需求規(guī)格說(shuō)明 265.1.4對(duì)子系統(tǒng)進(jìn)行劃分 265.2自上而下與自下而上 275.2.1自上而下 275.2.2自下而上 275.2.3關(guān)注相互間的關(guān)系 275.3需求開(kāi)發(fā)需要堅(jiān)持規(guī)范 285.3.1為什么要強(qiáng)調(diào)堅(jiān)持規(guī)范 285.3.2規(guī)范不是教條 285.3.3堅(jiān)持規(guī)范性的文檔是必須的 295.3.4編寫(xiě)便于閱讀的需求 296.需求開(kāi)發(fā)過(guò)程定義 296.1開(kāi)發(fā)客戶(hù)需求 306.2開(kāi)發(fā)產(chǎn)品需求 326.3分析和確認(rèn)需求 357.利用需求模式重構(gòu)問(wèn)題 397.1對(duì)功能分解的再討論 397.2利用模式解決劃分中的困難 407.3需求模式與需求復(fù)用 417.4通過(guò)業(yè)務(wù)事件發(fā)現(xiàn)模式 437.5通過(guò)抽象形成模式 457.5.1需求抽象的一般方法 457.5.2特定領(lǐng)域的模式 467.5.3跨領(lǐng)域的模式 477.5.4復(fù)用的趨勢(shì) 47

說(shuō)明引言在軟件組織中，需求分析師的作用舉足輕重。統(tǒng)計(jì)表明，軟件缺陷一半以上的原因來(lái)自于需求分析中的問(wèn)題。僅憑這個(gè)數(shù)字，就足以告訴我們要提高軟件的質(zhì)量、增強(qiáng)產(chǎn)品的競(jìng)爭(zhēng)力，培養(yǎng)高水平的分析師隊(duì)伍，建立有效的需求團(tuán)隊(duì)，定義合理的需求過(guò)程，堅(jiān)持正確的需求規(guī)范是多么重要。但是目前在軟件需求分析領(lǐng)域，還存在著過(guò)程粗糙、方法隨意、分析欠深入等問(wèn)題，進(jìn)而極大的影響產(chǎn)品質(zhì)量，這正是在軟件項(xiàng)目中，我們需要對(duì)需求分析下功夫的最大原因，我們有理由認(rèn)為需求分析是奠定優(yōu)秀軟件的基礎(chǔ)，本課程的主要思想如下：1，需求工程在整個(gè)軟件工程中的地位十分特殊，良好的需求將支撐整個(gè)工程項(xiàng)目有序而高效的進(jìn)展，并對(duì)產(chǎn)品質(zhì)量控制提供依據(jù)。目前在創(chuàng)新成為重要主題的環(huán)境下，軟件開(kāi)發(fā)已演變成通過(guò)反饋逐步求精的過(guò)程，在這個(gè)過(guò)程中需求變更不可避免，因此我們不再認(rèn)為需求僅僅是一個(gè)前期的工作，而幾乎在每一個(gè)具體過(guò)程域中都在發(fā)揮作用。這就必須通過(guò)需求管理確保需求變更不至于對(duì)開(kāi)發(fā)造成混亂，由此對(duì)需求管理提出了苛刻的要求。2，軟件需求是一項(xiàng)在復(fù)雜環(huán)境中高風(fēng)險(xiǎn)、高影響力的活動(dòng)，所以單靠經(jīng)驗(yàn)肯定是不行的，我們需要把問(wèn)題抽象出來(lái)進(jìn)行理論分析，發(fā)現(xiàn)它們之間的邏輯，通過(guò)縝密的邏輯思維，從系統(tǒng)的觀點(diǎn)把方方面面的問(wèn)題都關(guān)注到。這就需要以工程學(xué)的方法來(lái)處理需求，這要求分析師對(duì)需求過(guò)程有透徹的理解。3，需求分析的本質(zhì)是在問(wèn)題域中，為現(xiàn)實(shí)世界中的問(wèn)題找到解決方案。事實(shí)上軟件工程學(xué)就是發(fā)現(xiàn)問(wèn)題并提出解決方案的一種工程方法。為了對(duì)“問(wèn)題”這個(gè)主題有更加透徹的理解，我們需要更加理性的來(lái)探討“問(wèn)題”。需求分析師對(duì)于問(wèn)題域的理解應(yīng)該非常深入，需要有能力技巧性的處理問(wèn)題域和問(wèn)題框架，從而提出解決問(wèn)題的產(chǎn)品構(gòu)思。4，需求分析師不能僅僅是記錄員，他需要理解客戶(hù)思維，幫助客戶(hù)理清問(wèn)題。這就需要分析師的工作有一整套方法論來(lái)支撐。包括業(yè)務(wù)建模、產(chǎn)品建模、在建模的過(guò)程中收集與理清想法，把握問(wèn)題的關(guān)鍵，發(fā)現(xiàn)需求背后的需求，從而構(gòu)思出真正符合客戶(hù)需要的產(chǎn)品。在這樣的過(guò)程中，要求分析師應(yīng)該具有相當(dāng)強(qiáng)的歸納能力。5，軟件產(chǎn)品的價(jià)值在于其不斷的創(chuàng)新，企業(yè)唯有將創(chuàng)新納入有效的管理規(guī)劃之中，遵循明確的指導(dǎo)原則和方法論，進(jìn)行持續(xù)不斷的系統(tǒng)化創(chuàng)新，才能長(zhǎng)久地保持競(jìng)爭(zhēng)優(yōu)勢(shì)。分析師的作用不僅僅是了解客戶(hù)的需要，更需要在早期以一種創(chuàng)新思維參與產(chǎn)品構(gòu)思，幫助客戶(hù)從自己的現(xiàn)狀中釋放出來(lái)，這就要求分析師具有很強(qiáng)的創(chuàng)新能力。6，為了提高需求分析的質(zhì)量，除了要系統(tǒng)研究需求分析中的方法論以外，更要研究需求過(guò)程中的質(zhì)量控制問(wèn)題。需求的質(zhì)量控制不僅僅是評(píng)審，在整個(gè)需求分析過(guò)程中都需要有可控制的質(zhì)量保證，我們必須對(duì)每一種需求開(kāi)發(fā)方法的優(yōu)點(diǎn)與局限性理解深刻，把合適的方法用在合適的地方，從而極大的提升需求分析的質(zhì)量，以得到高質(zhì)量的軟件產(chǎn)品。7，目前在需求分析中廣泛使用著用例方法，但這也是誤解最多的一種方法。我們必須對(duì)用例有深刻而正確的理解。如果編寫(xiě)恰當(dāng)，不需要把用例轉(zhuǎn)換為需求的其它形式，就可以準(zhǔn)確地對(duì)系統(tǒng)行為進(jìn)行詳細(xì)地描述。編寫(xiě)有效用例，正確而專(zhuān)業(yè)的書(shū)寫(xiě)需求文檔，完整定義功能性、非功能性需求及其測(cè)試條件，都是提升需求分析質(zhì)量的重要控制點(diǎn)。8，近年來(lái)，由于項(xiàng)目越來(lái)越大、越來(lái)越復(fù)雜，應(yīng)對(duì)軟件的易變性就不可能完全從需求分析方法本身解決問(wèn)題，而需要有更加合理的項(xiàng)目過(guò)程。需求分析師需要對(duì)軟件開(kāi)發(fā)過(guò)程及其相應(yīng)的需求分析方法有深刻的理解，從而主動(dòng)使需求分析成為整個(gè)軟件開(kāi)發(fā)過(guò)程有效的一環(huán)，為高質(zhì)量軟件開(kāi)發(fā)提供關(guān)鍵的支撐，這一切都對(duì)需求分析人員提出了十分苛刻的要求。本課程的授課特點(diǎn)是在理論指導(dǎo)下進(jìn)行案例教學(xué)，通過(guò)匯集許多專(zhuān)家多年來(lái)理論和實(shí)踐的總結(jié)，使課程既有理論高度，又通過(guò)“沙盤(pán)推演”提升實(shí)踐技巧，使理論與實(shí)踐完美結(jié)合，達(dá)到從根本上提升企業(yè)需求分析能力的目的。在授課過(guò)程中還根據(jù)不同項(xiàng)目特點(diǎn)提出不同的建模與需求分析方法，畢竟一個(gè)高級(jí)分析人員最重要的特征，就是根據(jù)具體環(huán)境，尋找更加合適的方法，從而避免死板僵化毫無(wú)生氣的分析模式，代之以生動(dòng)活潑富有創(chuàng)造性的分析過(guò)程，通過(guò)學(xué)習(xí)，希望國(guó)內(nèi)IT企業(yè)項(xiàng)目開(kāi)發(fā)達(dá)到一個(gè)新的水平。

1.軟件需求的思想與方法論需求分析并不是獨(dú)立存在，它與軟件工程方法密不可分。因此為了更全面的理解需求開(kāi)發(fā)方法，首先需要對(duì)現(xiàn)代軟件工程有個(gè)宏觀而全面的了解。同時(shí)對(duì)需求工程本身的有關(guān)問(wèn)題也需要全面闡述。本章將沿著如下圖所示思路逐漸展開(kāi)。1.1高質(zhì)量需求工程的意義最有用的產(chǎn)品是這樣一些產(chǎn)品，這些產(chǎn)品的開(kāi)發(fā)者理解產(chǎn)品應(yīng)該具備什么樣的功能，也了解產(chǎn)品必須以何種方式實(shí)現(xiàn)其目的，為了理解這一些，首先必須理解客戶(hù)希望完成哪種類(lèi)型的工作，而我們開(kāi)發(fā)出的產(chǎn)品將會(huì)以何種方式影響這些工作。產(chǎn)品為用戶(hù)所做的事情，以及產(chǎn)品在這種上下文背景中必須滿(mǎn)足的約束，就是產(chǎn)品的需求。在本課程講義一次又一次的重構(gòu)當(dāng)中，應(yīng)該說(shuō)第一章的變化是最大的，我們一直在思索，正確的、符合實(shí)際的需求工程理念到底應(yīng)該是什么樣的？和需求的本質(zhì)一樣：這一方面反映了人們認(rèn)識(shí)事物的螺旋上升觀念；另一個(gè)方面，也反映了社會(huì)環(huán)境和實(shí)踐過(guò)程的不斷變化，使我們對(duì)問(wèn)題的理解也發(fā)生很大變化。我們?cè)趯?shí)際工作中遇到了很多問(wèn)題，無(wú)論給項(xiàng)目還是我們自己都帶來(lái)了太多的困惑，但我們還是應(yīng)該站在更高的角度看問(wèn)題。如果在研究這些問(wèn)題的時(shí)候過(guò)于關(guān)注眼前的事情，往往就不能發(fā)現(xiàn)問(wèn)題的本質(zhì)。我們需要更深入的提煉出一些東西，凡事都有邏輯，我們需要理解一種體系和內(nèi)在的邏輯關(guān)系，需要提煉出一套思想和方法論。一句話(huà)，我們需要大思維。1.2需求工程與需求開(kāi)發(fā)方法論1.2.1需求工程模型為什么開(kāi)發(fā)軟件需求需要一套完整的工程方法呢？程序設(shè)計(jì)的有效性依賴(lài)于規(guī)格說(shuō)明，規(guī)格說(shuō)明的有效性依賴(lài)于對(duì)問(wèn)題域的理解。沒(méi)有好的需求，就沒(méi)有辦法驗(yàn)證程序設(shè)計(jì)的正確性，也就沒(méi)有辦法把程序與客戶(hù)的期望用一種邏輯性的方法聯(lián)系起來(lái)。特別是當(dāng)項(xiàng)目比較大需要很多人共同工作的時(shí)候，良好的需求可以保證整個(gè)開(kāi)發(fā)團(tuán)隊(duì)沿著規(guī)定的目標(biāo)一起前進(jìn)。大部分在軟件開(kāi)發(fā)中遇到的問(wèn)題，都是由于收集、編寫(xiě)、協(xié)商、修改產(chǎn)品需求過(guò)程中的手續(xù)和作法（方法）失誤帶來(lái)的。出現(xiàn)的問(wèn)題涉及到非正式信息的收集，未確定的或不明確的功能，未發(fā)現(xiàn)或未經(jīng)交流的假設(shè)，不完善的需求文檔，以及突發(fā)的需求變更要求。這一切都告訴我們，必須深入地研究和建立良好的需求工程方法。從宏觀上說(shuō)，我們可以把需求工程分為需求開(kāi)發(fā)和需求管理兩部分，如下圖所示。需求開(kāi)發(fā)的目的：是產(chǎn)生并分析客戶(hù)、產(chǎn)品和產(chǎn)品部件的需求，其過(guò)程建立了一套需求收集、建模、分析、和描述的順序、方法和模版，使需求可以以一種有序而深入的方式進(jìn)行。所謂需求分析，是把軟件系統(tǒng)的功能表示成單一的信息變換過(guò)程，需求分析也是一個(gè)分解和求精的過(guò)程。需求管理的目的：是管理項(xiàng)目的產(chǎn)品和產(chǎn)品部件的需求，并標(biāo)識(shí)這些需求與項(xiàng)目的計(jì)劃和工作產(chǎn)品之間的不一致性。由于需求在開(kāi)發(fā)過(guò)程中會(huì)發(fā)生若干變化，這會(huì)對(duì)管理過(guò)程的方方面面產(chǎn)生影響，所以必須建立一套規(guī)范的方法來(lái)從事管理。需求開(kāi)發(fā)與需求管理是相輔相成的兩類(lèi)活動(dòng)，它們共同構(gòu)成完整的需求工程體系，它們之間的關(guān)系如下圖所示。需求工程是軟件工程的子工程，由于軟件工程獨(dú)特的智力密集型特征，致使需求工程并不可能是一套約定俗成的概念和知識(shí)，用削足適履的方式，按著某些固定的方法到處套用就可以成功的了。相反，它體現(xiàn)為一種觀察問(wèn)題和解決問(wèn)題的方法，最終體現(xiàn)為理解和實(shí)施的能力，因此這一章的內(nèi)容就顯得舉足輕重。如果在一開(kāi)始就站到一個(gè)宏觀把握時(shí)空優(yōu)化理念的高度，那么當(dāng)進(jìn)入后面細(xì)節(jié)討論的時(shí)候，就會(huì)覺(jué)得心有靈犀、游刃有余了。1.2.2需求開(kāi)發(fā)的基本概念1）需求開(kāi)發(fā)的目的根據(jù)GJB5000A-2008“需求開(kāi)發(fā)（RD）”過(guò)程域?qū)π枨箝_(kāi)發(fā)的描述。需求開(kāi)發(fā)需要說(shuō)明三類(lèi)需求：客戶(hù)需求、產(chǎn)品需求和產(chǎn)品部件需求。需求是設(shè)計(jì)的基礎(chǔ)，所有的開(kāi)發(fā)項(xiàng)目都有需求，這些需求涉及利益相關(guān)方的需要，包括：與產(chǎn)品生存周期各階段有關(guān)的需要（例如，驗(yàn)收測(cè)試準(zhǔn)則）；與產(chǎn)品屬性（例如，安全性、可靠性、可維護(hù)性）有關(guān)的需要；與選擇設(shè)計(jì)解決方案（例如，集成、外購(gòu)產(chǎn)品）所引起的限制。2）需求的開(kāi)發(fā)的活動(dòng)為了達(dá)到上述目標(biāo)，需求開(kāi)發(fā)包括下列活動(dòng)：引出、分析、確認(rèn)和交流客戶(hù)需要、期望和限制，以獲得客戶(hù)需求，從而建立起對(duì)什么將滿(mǎn)足利益相關(guān)方的理解；收集并協(xié)調(diào)利益相關(guān)方的需要；開(kāi)發(fā)產(chǎn)品的生存周期需求（換句話(huà)說(shuō)，需求開(kāi)發(fā)并不僅僅是一個(gè)前期行為）；確定客戶(hù)需求；確定與客戶(hù)需求一致的初始的產(chǎn)品需求和產(chǎn)品部件需求。這里對(duì)產(chǎn)品需求有個(gè)定語(yǔ)：“初始”。這意味著需求可能在后期了解更多情況的時(shí)候發(fā)生進(jìn)一步精化和修改。而且需求也并不一定僅僅局限于業(yè)務(wù)分析。例如，客戶(hù)提出了一些特殊設(shè)計(jì)要求，就形成以這種設(shè)計(jì)要求為特征的客戶(hù)需求，會(huì)被進(jìn)一步加工為產(chǎn)品需求和產(chǎn)品部件需求。因此，需求開(kāi)發(fā)需要從各個(gè)角度思考問(wèn)題，才可能開(kāi)發(fā)出真正有效的需求來(lái)。在整個(gè)產(chǎn)品生命周期中，需求變更都是有可能的。例如，在以維護(hù)活動(dòng)為特征的項(xiàng)目中，產(chǎn)品或產(chǎn)品部件會(huì)根據(jù)現(xiàn)有需求、設(shè)計(jì)或?qū)崿F(xiàn)的改變而改變。需求的更改，可能由客戶(hù)或用戶(hù)提出文檔化的更改申請(qǐng)，或是由產(chǎn)品部門(mén)提出了新需求。從GJB5000A-2008對(duì)于需求開(kāi)發(fā)過(guò)程的描述中，我們會(huì)發(fā)現(xiàn)軟件工程方法已經(jīng)發(fā)生了一些引人注目的變化。首先，需求開(kāi)發(fā)并不僅僅是一個(gè)前期行為，在產(chǎn)品整個(gè)生存周期的各階段，都要標(biāo)識(shí)和精煉需求。再者，不再認(rèn)為需求開(kāi)發(fā)的結(jié)果是被凍結(jié)的。第三，需求的來(lái)源不僅僅是客戶(hù)，也來(lái)自于開(kāi)發(fā)團(tuán)隊(duì)，是一種各方面共同交流的結(jié)果。最后，更強(qiáng)調(diào)在整個(gè)開(kāi)發(fā)生命周期過(guò)程中對(duì)需求的協(xié)調(diào)、收集、反饋和精化。這些變化對(duì)于軟件工程方法論的影響十分關(guān)鍵。3）需求分析活動(dòng)正是在這個(gè)背景下，需求分析師思維方式需要有比較大的改變，需求分析已經(jīng)不再是前期收集、評(píng)審過(guò)后不管的形式了，需求開(kāi)發(fā)過(guò)程與產(chǎn)品技術(shù)解決方案過(guò)程將會(huì)在整個(gè)開(kāi)發(fā)生命周期中相互作用，這就要求分析師對(duì)于項(xiàng)目管理與技術(shù)實(shí)現(xiàn)要有更好的感覺(jué)。例如，通過(guò)對(duì)競(jìng)爭(zhēng)的備選方案進(jìn)行分析，可以幫助我們了解、定義和選擇所有層次的需求，這些分析活動(dòng)包括：分析每個(gè)產(chǎn)品生存周期階段的需要和需求，包括利益相關(guān)方的需要、運(yùn)行環(huán)境和反映全體客戶(hù)和最終用戶(hù)期望和滿(mǎn)意度的因素，如安全性、保密性和可支付能力；開(kāi)發(fā)運(yùn)行方案；定義必要的功能性。功能性定義也稱(chēng)為“功能分析”，所產(chǎn)生的功能的定義、它們的邏輯組合和它們與需求的關(guān)聯(lián)被稱(chēng)為“功能結(jié)構(gòu)”。4）某些需求可以從技術(shù)層面獲取通過(guò)不斷分析產(chǎn)品體系結(jié)構(gòu)的更深層次，可以是我們獲得足夠的細(xì)節(jié)，可以更好的定義需求，以進(jìn)行產(chǎn)品的詳細(xì)設(shè)計(jì)、編碼和測(cè)試。作為需求分析和運(yùn)行方案（包括功能性、支持、維護(hù)和退役）的結(jié)果，軟件的設(shè)計(jì)和編碼方案會(huì)產(chǎn)生更多的需求，例如：各種業(yè)務(wù)類(lèi)型的限制；技術(shù)限制；成本和成本因素限制；時(shí)間限制和進(jìn)度因素；對(duì)于風(fēng)險(xiǎn)的分析；客戶(hù)或最終用戶(hù)所暗示但未明確說(shuō)明的問(wèn)題：開(kāi)發(fā)者獨(dú)特的業(yè)務(wù)考慮、規(guī)則和法律等所產(chǎn)生的因素。通過(guò)迭代演化的運(yùn)行方案，建立邏輯實(shí)體（功能和子功能、對(duì)象類(lèi)和子類(lèi)）的層次結(jié)構(gòu)。初期得出的需求將被精煉、導(dǎo)出和分配到這些邏輯實(shí)體。需求和邏輯實(shí)體又會(huì)被分配到產(chǎn)品、產(chǎn)品部件、人員以及相關(guān)的過(guò)程或服務(wù)。當(dāng)然，我們也要注意到一個(gè)問(wèn)題的兩個(gè)方面，雖然我們關(guān)注了某些需求可以從技術(shù)層面獲取，但是也要避免需求說(shuō)明對(duì)技術(shù)產(chǎn)生過(guò)多的約束和影響。畢竟需求是對(duì)產(chǎn)品業(yè)務(wù)方面的說(shuō)明，而不能有任何技術(shù)實(shí)現(xiàn)上的偏好。5）利益相關(guān)方參與是關(guān)鍵正是現(xiàn)代軟件開(kāi)發(fā)的這種需求演化特征，利益相關(guān)方參與需求的開(kāi)發(fā)和分析就成為成功的關(guān)鍵。如何使利益相關(guān)方愿意參與需求開(kāi)發(fā)是需求分析人員的能力所在。我們必須使需求演化具有可視性，以模型來(lái)驅(qū)動(dòng)需求開(kāi)發(fā)將會(huì)減少人們交互的障礙。需求的描述常常是抽象的，以一種與技術(shù)無(wú)關(guān)的方式表達(dá)，這樣做的目的是為了便于理解和交流，使利益相關(guān)方的參與成為可能。1.2.3軟件質(zhì)量與需求開(kāi)發(fā)1）需求是產(chǎn)生軟件缺陷的最大原因隨著經(jīng)濟(jì)全球化進(jìn)程的不斷推進(jìn)，要增加產(chǎn)品的國(guó)際競(jìng)爭(zhēng)力，產(chǎn)品質(zhì)量作為經(jīng)濟(jì)發(fā)展的戰(zhàn)略問(wèn)題變得越來(lái)越重要。當(dāng)軟件產(chǎn)品在應(yīng)用領(lǐng)域中所占比例很小的時(shí)候，軟件質(zhì)量不好也可能并沒(méi)有太大的問(wèn)題。但是，當(dāng)軟件在應(yīng)用領(lǐng)域中占的比例很大的時(shí)候，軟件質(zhì)量問(wèn)題就可能釀成大禍。隨著社會(huì)運(yùn)轉(zhuǎn)的速度越來(lái)越快，人們對(duì)于自動(dòng)化系統(tǒng)的依賴(lài)也越來(lái)越大，在航天、航空、交通、金融等各個(gè)領(lǐng)域，都對(duì)軟件質(zhì)量提出了更苛刻的要求，我們必須改變我們的習(xí)慣和某些文化，為產(chǎn)品質(zhì)量投入更多的成本和關(guān)注。軟件質(zhì)量問(wèn)題相當(dāng)程度上是以軟件缺陷（defect）的形式出現(xiàn)的。軟件缺陷是由很多原因造成的，但從多和項(xiàng)目整個(gè)開(kāi)發(fā)周期的統(tǒng)計(jì)結(jié)果來(lái)看，我們會(huì)意外的發(fā)現(xiàn)需求規(guī)格說(shuō)明是造成軟件缺陷最多的地方，如下圖所示。換句話(huà)說(shuō)，需求分析的不到位，是產(chǎn)生軟件缺陷的最大原因。產(chǎn)生這種情況的原因如下：客戶(hù)一般是非計(jì)算機(jī)專(zhuān)業(yè)人員，軟件開(kāi)發(fā)人員與客戶(hù)溝通存在著比較大的困難，對(duì)要開(kāi)發(fā)的產(chǎn)品功能理解也不一致。由于軟件產(chǎn)品還沒(méi)有設(shè)計(jì)、開(kāi)發(fā)，完全靠想象去描述系統(tǒng)的實(shí)現(xiàn)結(jié)果，所以有些特性還不夠清晰?？蛻?hù)的需求總是在不斷的變化，容易引起前后文、上下文的矛盾和需求描述的不一致。需求分析沒(méi)有得到足夠的重視，在規(guī)格說(shuō)明書(shū)的設(shè)計(jì)和寫(xiě)作上投入的人力、時(shí)間都不足。沒(méi)有在整個(gè)開(kāi)發(fā)隊(duì)伍中進(jìn)行充分的溝通，有時(shí)只有架構(gòu)師得到比較多的信息，造成人們對(duì)問(wèn)題理解的不一致。2）需求對(duì)軟件質(zhì)量的影響軟件產(chǎn)品質(zhì)量并不能只靠在交付階段不斷加班、修修補(bǔ)補(bǔ)的滿(mǎn)足要求來(lái)達(dá)到的，而是要依靠整個(gè)開(kāi)發(fā)過(guò)程中的質(zhì)量控制。有的企業(yè)感覺(jué)實(shí)施高質(zhì)量軟件管理、需求、設(shè)計(jì)和質(zhì)量保證非常麻煩，抱怨投入的成本太高，推行起來(lái)很麻煩阻力很大，得不償失，真的是這樣嗎？沒(méi)有質(zhì)量控制的產(chǎn)品真的可以在競(jìng)爭(zhēng)中占據(jù)市場(chǎng)嗎？需求對(duì)軟件開(kāi)發(fā)各個(gè)方面都有顯著影響。好的需求有助于開(kāi)發(fā)小組對(duì)問(wèn)題的認(rèn)識(shí)一致，盡管有些并非出于商業(yè)目的的軟件，偶爾不需要文檔說(shuō)明就能與其他人意見(jiàn)較為一致。但更大更常見(jiàn)的情況還是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價(jià)遠(yuǎn)遠(yuǎn)超過(guò)重寫(xiě)一份需求文檔的代價(jià)。在需求分析中要善于發(fā)現(xiàn)隱性需求，不能只關(guān)注對(duì)所要求功能的正確表述，要把更多的精力放在異常情況的表述上，例如當(dāng)發(fā)生什么情況時(shí)會(huì)引發(fā)什么情況，該如何解決？要描述各種例外和異常情況，這樣的需求才可能給設(shè)計(jì)提供更多的信息與支持。正確的需求是測(cè)試的基礎(chǔ)，當(dāng)我們依據(jù)需求對(duì)系統(tǒng)進(jìn)行測(cè)試時(shí)，不僅能非常清晰地判斷系統(tǒng)是否實(shí)現(xiàn)了所有必需功能，而且可以輕易發(fā)現(xiàn)任何最終的錯(cuò)誤。因此，每一種例外都將作為一個(gè)場(chǎng)景進(jìn)行測(cè)試，這才會(huì)有很高的測(cè)試覆蓋率。如果需求分析并沒(méi)有發(fā)現(xiàn)到各種異常情況，也沒(méi)有提出處理這些異常的要求，在系統(tǒng)測(cè)試的時(shí)候也就不會(huì)對(duì)此進(jìn)行測(cè)試，這就形成了隱性Bug，結(jié)果會(huì)釀成重大事故。3）軟件開(kāi)發(fā)最困難的工作是編寫(xiě)需求需求開(kāi)發(fā)在軟件項(xiàng)目中扮演的角色非常重要：開(kāi)發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么。最為困難的概念性工作便是編寫(xiě)出詳細(xì)技術(shù)需求，這包括所有面向客戶(hù)、面向機(jī)器和其它軟件系統(tǒng)的接口。同時(shí)這也是一旦做錯(cuò)，最終會(huì)給系統(tǒng)帶來(lái)極大損害的部分，并且以后再對(duì)它進(jìn)行修改也極為困難。需求之難首先來(lái)自于很多人看不到它的難度，前期很少投入足夠的資源進(jìn)行需求開(kāi)發(fā)，就像在黑暗中前行，看不到陷阱往往就蘊(yùn)含著巨大的風(fēng)險(xiǎn)。一些不合理的需求往往使項(xiàng)目管理陷入災(zāi)難，開(kāi)發(fā)人員面對(duì)蠕動(dòng)的需求一籌莫展。要理解在了解客戶(hù)需要上所花的時(shí)間，是使項(xiàng)目成功的一種高層次的投資。這對(duì)于用戶(hù)應(yīng)用程序、企業(yè)信息系統(tǒng)和作為大系統(tǒng)的一部分的軟件產(chǎn)品是顯而易見(jiàn)的。對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，沒(méi)有編寫(xiě)出客戶(hù)認(rèn)可的需求文檔，他們?nèi)绾沃理?xiàng)目于何時(shí)結(jié)束？如果我們不知道什么對(duì)客戶(hù)來(lái)說(shuō)是重要的，那我們又如何能使客戶(hù)感到滿(mǎn)意呢？需求之難還來(lái)自于需求開(kāi)發(fā)人員的水平。需求并不僅僅是記錄客戶(hù)要求，更要發(fā)現(xiàn)隱含的需求，發(fā)現(xiàn)需求背后的需求。很多人認(rèn)為客戶(hù)提出的要求越少麻煩就越少，其實(shí)不然，很多問(wèn)題在后期終歸是要提出的，與其后期修修補(bǔ)補(bǔ)，不如前期就定義清楚，這樣更容易進(jìn)行良好的設(shè)計(jì)。需求分析人員必須學(xué)會(huì)從系統(tǒng)的角度看問(wèn)題，一個(gè)分析人員的價(jià)值就在于能看到系統(tǒng)，能盡早感知風(fēng)險(xiǎn)，能確定正確的目標(biāo)。在分析中要關(guān)注誰(shuí)推動(dòng)誰(shuí)，誰(shuí)拉動(dòng)誰(shuí)，誰(shuí)影響誰(shuí)，這就是系統(tǒng)分析的根本，也是需求開(kāi)發(fā)最困難的部分。需求本身就是一種約束，但又不能處處制造約束，約束過(guò)多照樣使項(xiàng)目難以成功。這里有個(gè)度的問(wèn)題。比如業(yè)務(wù)模塊怎么分解，接口如何定義，哪些是屬于需求的約束？哪些是屬于設(shè)計(jì)人員的職責(zé)范圍？這都需要很好的區(qū)分，需求只對(duì)產(chǎn)品交付和部件交互有重大影響的部分提供約束，但具體怎么區(qū)分就需要有經(jīng)驗(yàn)，需要?dú)w納總結(jié)，很難用一個(gè)簡(jiǎn)單的規(guī)則進(jìn)行說(shuō)明。4）需求分析人員應(yīng)該具備的素質(zhì)一個(gè)好的需求分析人員所具備的素質(zhì)，首先就是熱愛(ài)需求分析工作，對(duì)工作有興趣并且用心，三心二意應(yīng)付差事永遠(yuǎn)開(kāi)發(fā)不出好的需求。好的文章是改出來(lái)的，同樣好的需求是一次又一次反復(fù)琢磨、不斷否定之否定、深入又深入的發(fā)掘出來(lái)的。重視需求開(kāi)發(fā)、具備好的工作風(fēng)格、用心去開(kāi)發(fā)需求，這就容易獲得客戶(hù)的信任，使利益相關(guān)方的合作成為可能，這往往是產(chǎn)生優(yōu)良需求之本，也是產(chǎn)生優(yōu)秀產(chǎn)品設(shè)計(jì)的本源。需求分析人員要善于學(xué)習(xí)，每一個(gè)項(xiàng)目的需求開(kāi)發(fā)都是一次學(xué)習(xí)之旅，向客戶(hù)學(xué)習(xí)、向開(kāi)發(fā)人員學(xué)習(xí)、向一切內(nèi)行的人們學(xué)習(xí)，這就使我們有了更寬闊的眼界。我們?cè)谶@個(gè)過(guò)程中形成的理念、方法論、良好的性格以及正確的哲學(xué)觀念，將會(huì)使一切融會(huì)貫通，并引領(lǐng)我們走向成功。1.2.4正確的需求開(kāi)發(fā)方法論需求獲取的方法很多，那么什么樣的需求獲取方法才是正確的呢？研究方法論最基本的方式是首先明確目標(biāo)，然后關(guān)注錯(cuò)誤。正確的方法很多而且大多數(shù)不可復(fù)制，而錯(cuò)誤是可以復(fù)制的，更多地關(guān)注錯(cuò)誤可以用更少的代價(jià)確保方法正確，需求開(kāi)發(fā)的方法論從目標(biāo)看只有4條：1）關(guān)注規(guī)律而不僅僅是記錄需求過(guò)程之難并不在于某些書(shū)寫(xiě)標(biāo)準(zhǔn)或規(guī)范，也不是僅僅了解客戶(hù)需要什么，而是需要深入地從各個(gè)角度探究客戶(hù)需求，總結(jié)出客戶(hù)需求的本質(zhì)和將來(lái)變化的規(guī)律，這就對(duì)需求分析師提出了很高的要求。需求分析非常重要，如果事情說(shuō)不清楚，就沒(méi)有辦法做好。2）實(shí)行有效的通力合作正確的需求過(guò)程強(qiáng)調(diào)產(chǎn)品開(kāi)發(fā)中的通力合作，包括在整個(gè)項(xiàng)目過(guò)程中多的利益相關(guān)方的積極努力。收集需求能使開(kāi)發(fā)小組更好地了解市場(chǎng)，而市場(chǎng)因素是任何項(xiàng)目成功的一個(gè)關(guān)鍵因素。在產(chǎn)品開(kāi)發(fā)前了解這些比在遭到客戶(hù)批評(píng)后才意識(shí)到要節(jié)約很多成本。讓客戶(hù)和用戶(hù)積極參與需求收集過(guò)程能使產(chǎn)品更富有吸引力，而且能擁有忠實(shí)的客戶(hù)關(guān)系。3）全方位考慮需求問(wèn)題將選定系統(tǒng)的需求明確地分配到各軟件子系統(tǒng)，強(qiáng)調(diào)采用產(chǎn)品工程的系統(tǒng)方法。這樣能簡(jiǎn)化硬軟件的集成，也能確保軟硬件系統(tǒng)功能匹配適當(dāng)。有效的變更控制和影響分析過(guò)程也能降低需求變更帶來(lái)的負(fù)面影響。最后，將需求編寫(xiě)成清晰、無(wú)二義性的文檔將會(huì)極大地有利于系統(tǒng)測(cè)試，確保產(chǎn)品質(zhì)量，以使所有利益相關(guān)方感到滿(mǎn)意。讓我們來(lái)關(guān)注一下錯(cuò)誤的需求開(kāi)發(fā)方法，現(xiàn)實(shí)中我們會(huì)遇到太多的有缺陷的需求收集方法，歸納起來(lái)原因不外是下面幾點(diǎn)：1）無(wú)足夠用戶(hù)參與客戶(hù)經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費(fèi)那么多功夫，開(kāi)發(fā)人員可能也不重視客戶(hù)的參與。究其原因：一是因?yàn)榕c客戶(hù)合作不如編寫(xiě)代碼有意思；二是因?yàn)殚_(kāi)發(fā)人員覺(jué)得已經(jīng)明白客戶(hù)的需求了（加入了自己的想象，與客戶(hù)需求并不一致）。在某些情況下，與實(shí)際使用產(chǎn)品的用戶(hù)直接接觸很困難，而客戶(hù)也不太明白自己的真正需求。2）客戶(hù)需求的不斷增加在開(kāi)發(fā)中若不斷地補(bǔ)充需求，項(xiàng)目就越變?cè)烬嫶笠灾鲁^(guò)其計(jì)劃及預(yù)算范圍。計(jì)劃并不總是與項(xiàng)目需求規(guī)模與復(fù)雜性、風(fēng)險(xiǎn)、開(kāi)發(fā)生產(chǎn)率及需求變更實(shí)際情況相一致，這使得問(wèn)題更難解決。實(shí)際上，問(wèn)題根源在于客戶(hù)需求的改變和開(kāi)發(fā)者對(duì)新需求所作的修改。產(chǎn)品開(kāi)發(fā)中不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù)。插入補(bǔ)丁代碼使模塊違背高內(nèi)聚、松耦合的設(shè)計(jì)原則，特別是如果項(xiàng)目配置管理工作不完善的話(huà)，收回變更和刪除特性會(huì)帶來(lái)問(wèn)題。如果能夠盡早發(fā)現(xiàn)可能帶來(lái)變更的特性，我們就能開(kāi)發(fā)一個(gè)更為健壯的結(jié)構(gòu)，并能更好地適應(yīng)它。這樣設(shè)計(jì)階段需求變更不會(huì)直接導(dǎo)致補(bǔ)丁代碼，同時(shí)也有利于減少因變更導(dǎo)致質(zhì)量的下降。3）模棱兩可的需求模棱兩可是需求規(guī)格說(shuō)明中最為可怕的問(wèn)題。它的一層含義是指諸多讀者對(duì)需求說(shuō)明產(chǎn)生了不同的理解，但又以為達(dá)成一致了；另一層含義是指單個(gè)讀者能用不止一個(gè)方式來(lái)解釋某個(gè)需求說(shuō)明，使需求產(chǎn)生歧義。模棱兩可的需求會(huì)使不同的利益相關(guā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è)試。4）不必要的特性“畫(huà)蛇添足”是指開(kāi)發(fā)人員力圖增加一些“用戶(hù)欣賞”但需求規(guī)格說(shuō)明中并未涉及的新功能。經(jīng)常發(fā)生的情況是客戶(hù)并不認(rèn)為這些功能性很有用，以致在其上耗費(fèi)的努力“白搭”了。開(kāi)發(fā)人員應(yīng)當(dāng)為客戶(hù)構(gòu)思方案并為他們提供一些具有創(chuàng)新意識(shí)的思路，具體提供哪些功能要在客戶(hù)所需與開(kāi)發(fā)人員在允許時(shí)限內(nèi)的技術(shù)可行性之間求得平衡，開(kāi)發(fā)人員應(yīng)努力使功能簡(jiǎn)單易用，而不要未經(jīng)客戶(hù)同意，擅自脫離客戶(hù)要求，自作主張。同樣，客戶(hù)有時(shí)也可能要求一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能，而實(shí)現(xiàn)這些功能只能徒耗時(shí)間和成本。5）過(guò)于精簡(jiǎn)的規(guī)格說(shuō)明有時(shí)，客戶(hù)并不明白需求分析有如此重要，于是只要求一份簡(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)品或需求本身就十分靈活的情況。但在大多數(shù)情況下，這會(huì)給開(kāi)發(fā)人員帶來(lái)挫折，也會(huì)給客戶(hù)帶來(lái)煩惱，因?yàn)樗麄儫o(wú)法得到他們所設(shè)想的產(chǎn)品。2.優(yōu)秀需求規(guī)格說(shuō)明具有的特性如何才能開(kāi)發(fā)出更好的“需求規(guī)格說(shuō)明”？如何才能讓利益相關(guān)方更容易從不同角度對(duì)需求規(guī)格說(shuō)明進(jìn)行評(píng)審？只要我們?cè)诰帉?xiě)、評(píng)審需求時(shí)把下面這些特點(diǎn)銘記于心，就會(huì)寫(xiě)出更好的（盡管并不十分完美）需求文檔，同時(shí)也就有可能開(kāi)發(fā)出更好的產(chǎn)品，好的需求文檔應(yīng)該具備以下一些特點(diǎn)。2.1需求具有清晰的層次一個(gè)優(yōu)秀的便于閱讀的需求文檔應(yīng)該具備很強(qiáng)的層次感，在不同階段表達(dá)問(wèn)題的重點(diǎn)也不同，并且能夠在發(fā)展過(guò)程中不斷演進(jìn)。軟件需求包括三個(gè)不同的層次：客戶(hù)需求、產(chǎn)品需求、功能需求以及非功能需求，其各部分關(guān)系如下圖所示?？蛻?hù)需求：也稱(chēng)之為顧客需求，反映了組織機(jī)構(gòu)或客戶(hù)對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說(shuō)明。客戶(hù)需求一般表述比較抽象，缺乏很多必要的細(xì)節(jié)。產(chǎn)品需求：描述用戶(hù)使用產(chǎn)品必須要完成的任務(wù)，也稱(chēng)之為用戶(hù)需求。這種需求需要考慮產(chǎn)品的運(yùn)行方案，在用例（usecase）文檔或方案腳本（scenario）說(shuō)明中予以說(shuō)明。功能需求：定義了開(kāi)發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶(hù)能完成他們的任務(wù)，從而滿(mǎn)足了客戶(hù)需求。功能需求給用戶(hù)提供處理能力并滿(mǎn)足客戶(hù)需求。非功能需求：描述了產(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)品功能。軟件需求規(guī)格說(shuō)明（SoftwareRequirementsSpecification，SRS）：中說(shuō)明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說(shuō)明在開(kāi)發(fā)、測(cè)試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用。對(duì)一個(gè)復(fù)雜產(chǎn)品來(lái)說(shuō)，軟件功能需求也許只是系統(tǒng)需求的一個(gè)子集，因?yàn)榱硗庖恍┛赡軐儆谲浖考?。所有的用?hù)需求必須與客戶(hù)需求一致。產(chǎn)品需求使需求分析者能從中總結(jié)出功能需求以滿(mǎn)足客戶(hù)對(duì)產(chǎn)品的要求從而完成其任務(wù)，而開(kāi)發(fā)人員則根據(jù)功能需求來(lái)設(shè)計(jì)軟件以實(shí)現(xiàn)必須的功能。從以上定義可以發(fā)現(xiàn)，需求并未包括設(shè)計(jì)細(xì)節(jié)、實(shí)現(xiàn)細(xì)節(jié)、項(xiàng)目計(jì)劃信息或測(cè)試信息。需求與這些沒(méi)有關(guān)系，它關(guān)注的是充分說(shuō)明你究竟想開(kāi)發(fā)什么。2.2良好的需求描述的特征在“需求規(guī)格說(shuō)明”中，每一項(xiàng)需求都應(yīng)該具備如下特征，這也是后期檢查需求書(shū)寫(xiě)質(zhì)量的依據(jù)：完整性：每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚，以使開(kāi)發(fā)人員獲得設(shè)計(jì)和實(shí)現(xiàn)這些功能所需的所有必要信息。正確性：每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開(kāi)發(fā)的功能。若軟件需求與對(duì)應(yīng)的系統(tǒng)需求相抵觸則是不正確的。可行性：每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的限制范圍內(nèi)可以實(shí)施的。在獲取需求過(guò)程中最好始終有一位軟件工程小組的組員負(fù)責(zé)檢查技術(shù)可行性。必要性：每一項(xiàng)需求都應(yīng)把客戶(hù)真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來(lái)。“必要性”也可以理解為每項(xiàng)需求都是用來(lái)授權(quán)你編寫(xiě)文檔的“根源”。劃分優(yōu)先級(jí)：給每項(xiàng)需求、特性或用例分配一個(gè)實(shí)施優(yōu)先級(jí)，以指明它在特定產(chǎn)品中所占的分量。如果把所有的需求都看作同樣重要，那么項(xiàng)目管理者在開(kāi)發(fā)或節(jié)省預(yù)算或調(diào)度中就喪失控制自由度。無(wú)二義性：對(duì)所有需求說(shuō)明的讀者都只能有一個(gè)明確統(tǒng)一的解釋?zhuān)苊舛x性的有效方法包括對(duì)需求文檔的正規(guī)審查，編寫(xiě)測(cè)試用例，開(kāi)發(fā)原型等?？沈?yàn)證性：檢查一下每項(xiàng)需求是否能通過(guò)設(shè)計(jì)測(cè)試用例，來(lái)確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn)了。如果需求不可驗(yàn)證，則可確定其是主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗(yàn)證的。2.3良好需求規(guī)格說(shuō)明的特征從“需求規(guī)格說(shuō)明”文檔整體編寫(xiě)的角度上看，好的“需求規(guī)格說(shuō)明”還應(yīng)該具備如下特點(diǎn)：完整性：不能遺漏任何必要的需求信息。注重用戶(hù)的任務(wù)而不是系統(tǒng)的功能將有助于你避免不完整性。一致性：一致性是指與其它軟件需求或高層（系統(tǒng)，業(yè)務(wù)）需求不相矛盾。在開(kāi)發(fā)前必須解決所有需求間的不一致部分?？尚薷男裕涸诒匾獣r(shí)應(yīng)維護(hù)與修訂“需求規(guī)格說(shuō)明”。這就要求每項(xiàng)需求要獨(dú)立標(biāo)出，并與別的需求區(qū)別開(kāi)來(lái)。每項(xiàng)需求只應(yīng)在“需求規(guī)格說(shuō)明”中出現(xiàn)一次。這樣更改時(shí)易于保持一致性?？筛櫺裕簯?yīng)能在每項(xiàng)軟件需求與它的業(yè)務(wù)和設(shè)計(jì)元素、源代碼、測(cè)試用例之間建立起跟蹤鏈，這種可跟蹤性要求每項(xiàng)需求以一種結(jié)構(gòu)化的，粒度好的方式編寫(xiě)并單獨(dú)標(biāo)明，而不是大段大段的敘述。上述對(duì)于需求開(kāi)發(fā)的宏觀描述非常重要，它為我們下一步工作設(shè)定了一個(gè)目標(biāo)和界限，在出現(xiàn)困惑的時(shí)候，就不至于迷茫或者無(wú)從下手，思路也會(huì)更加清晰。2.4對(duì)軟件工程方法的重新思考要研究需求首先必須明確需求在軟件工程中的位置。2000年以后，軟件工程的思想和方法發(fā)生了引人注目的變化，這促使我們站在一個(gè)全新的角度來(lái)看待需求。2.4.1瀑布方式的問(wèn)題傳統(tǒng)軟件工程推薦的是一種瀑布式過(guò)程。這是一種順序的、基于活動(dòng)的思維定勢(shì)，這些活動(dòng)包括：需求收集、設(shè)計(jì)、編碼、測(cè)試、集成一直到驗(yàn)收。通過(guò)這種一級(jí)一級(jí)進(jìn)行的活動(dòng)，來(lái)確保開(kāi)發(fā)過(guò)程的有序。經(jīng)典的瀑布開(kāi)發(fā)過(guò)程如下圖所示。在瀑布模型下，需求開(kāi)發(fā)是一個(gè)前期的工作，要求在任何設(shè)計(jì)和實(shí)現(xiàn)工作之前，盡可能的推敲，把需求完全定義清楚，并把它穩(wěn)定下來(lái)，然后再建立系統(tǒng)高層模型，包括系統(tǒng)和子系統(tǒng)的框架以及基于服務(wù)的層等。在底層設(shè)計(jì)階段，可以精細(xì)的把客戶(hù)需求轉(zhuǎn)換為系統(tǒng)模型。然后在實(shí)現(xiàn)諸如編碼、測(cè)試、系統(tǒng)集成以及部署等下游模型。瀑布模型有8條經(jīng)典法則：在設(shè)計(jì)之前先要凍結(jié)需求。在詳細(xì)設(shè)計(jì)之前不要編碼。在集成之前要完成單元測(cè)試。必須有詳細(xì)的文檔。所有的交付文檔都需要詳細(xì)并且維護(hù)可追朔性。質(zhì)量評(píng)估必須是單獨(dú)的團(tuán)隊(duì)（QA）。高度精確的對(duì)所有的事情做計(jì)劃。審查所有的事情。確實(shí)，這是一種非常好的工作方式，除非你是要做軟件。至少，在現(xiàn)實(shí)中很少有客戶(hù)承認(rèn)需求已經(jīng)被凍結(jié)了，并且簽字承諾今后如果需求變更了客戶(hù)將負(fù)全部責(zé)任，如果這一條做不到，那后面所有的條條都將成為無(wú)木之本。一個(gè)典型的瀑布式開(kāi)發(fā)的場(chǎng)景如下圖所示。一群利益相關(guān)人與分析師從一組高層需求開(kāi)始討論，3個(gè)月后，分析師根據(jù)客戶(hù)要求把需求細(xì)化到了一定程度，他們書(shū)寫(xiě)出了需求規(guī)格說(shuō)明書(shū)作為這個(gè)階段的結(jié)束。需求規(guī)格說(shuō)明書(shū)經(jīng)過(guò)客戶(hù)評(píng)審，他們認(rèn)為這基本可以達(dá)到要求。管理層認(rèn)為他們已經(jīng)充分理解了需求，可以進(jìn)入設(shè)計(jì)階段了。需求規(guī)格說(shuō)明書(shū)被發(fā)送到了設(shè)計(jì)團(tuán)隊(duì)，設(shè)計(jì)師依據(jù)需求規(guī)格說(shuō)明書(shū)設(shè)計(jì)產(chǎn)品，2個(gè)月后，完成的設(shè)計(jì)又經(jīng)過(guò)了設(shè)計(jì)評(píng)審，被認(rèn)為符合要求，于是設(shè)計(jì)說(shuō)明書(shū)被發(fā)送到了編碼團(tuán)隊(duì)。5個(gè)月后，代碼開(kāi)始陸陸續(xù)續(xù)交給測(cè)試團(tuán)隊(duì)，測(cè)試團(tuán)隊(duì)開(kāi)始尋找代碼中的缺陷。項(xiàng)目經(jīng)理對(duì)這種有序的按計(jì)劃進(jìn)行的項(xiàng)目甚是滿(mǎn)意，但是歷經(jīng)一年后客戶(hù)看到了初步的版本，他們的反應(yīng)讓項(xiàng)目經(jīng)理大吃一驚，他們認(rèn)為這并不像他們當(dāng)初在需求規(guī)格說(shuō)明中規(guī)定的東西，于是客戶(hù)至上主義使項(xiàng)目經(jīng)理答應(yīng)進(jìn)行修改。問(wèn)題是不僅僅是編碼，一直到需求、設(shè)計(jì)、測(cè)試條件都發(fā)生了修改，找誰(shuí)？于是開(kāi)始發(fā)生混亂，到后來(lái)，客戶(hù)又提出加入新的需求（因?yàn)橐荒曛泻芏嘞敕ê铜h(huán)境變了），混亂開(kāi)始加劇，最終項(xiàng)目經(jīng)理失去了耐心，開(kāi)始與客戶(hù)爭(zhēng)吵，這種混亂降低了效率、增加了成本、破壞了質(zhì)量，開(kāi)發(fā)方的損失誰(shuí)來(lái)承擔(dān)？客戶(hù)沒(méi)有按期得到有用的產(chǎn)品，這個(gè)損失又是誰(shuí)來(lái)承擔(dān)？這種混亂到底是誰(shuí)造成的？到底發(fā)生了什么錯(cuò)？問(wèn)題出在哪里呢？關(guān)鍵是沒(méi)有認(rèn)識(shí)到，無(wú)論是客戶(hù)還是我們自己，對(duì)于需求的理解是一個(gè)漸進(jìn)的過(guò)程，這一方面來(lái)自于人們認(rèn)識(shí)事物的螺旋上升性，也來(lái)自于外部世界變化的快速性。在這個(gè)背景下我們有理由質(zhì)疑先有需求后有設(shè)計(jì)的觀念。無(wú)數(shù)事實(shí)告訴我們，無(wú)論人們對(duì)前期需求收集下了多么大的功夫，后期的需求變更都不可避免。特別是在今天創(chuàng)新成為重要主題的環(huán)境下，我們對(duì)于需求的看法也發(fā)生了很大的改變。3需求的滾動(dòng)式完善模式3.1需求在動(dòng)態(tài)中的滾動(dòng)完善正是由于無(wú)數(shù)個(gè)瀑布過(guò)程項(xiàng)目的失敗，才促使人們仔細(xì)研究需求過(guò)程的本質(zhì)。需求并不是一個(gè)獨(dú)立的東西，也不僅僅是一個(gè)前期的工作。需求是一個(gè)對(duì)客戶(hù)需要不斷理解和加深認(rèn)識(shí)的過(guò)程，因此我們必須理解關(guān)于認(rèn)識(shí)論的本質(zhì)。人們認(rèn)識(shí)事物，總是一種由粗而精，螺旋上升的過(guò)程，因此在項(xiàng)目過(guò)程中需求的變更是不可避免的。從另一方面說(shuō)，需求又和項(xiàng)目計(jì)劃息息相關(guān)，需求的變化必然會(huì)引起項(xiàng)目計(jì)劃的變更，這就需要用集成的觀點(diǎn)看問(wèn)題。當(dāng)我們嘗試用動(dòng)態(tài)的觀點(diǎn)看問(wèn)題時(shí)，軟件項(xiàng)目自然就會(huì)有一種獨(dú)特的漸進(jìn)特點(diǎn)，需求以及它所影響的項(xiàng)目計(jì)劃必然也會(huì)經(jīng)歷一個(gè)由粗而精、不斷完善的過(guò)程。也就是項(xiàng)目的需求在頻繁反饋中不斷變更、滾動(dòng)完善的模式，如下圖所示。一個(gè)項(xiàng)目初期需求可能比較粗糙，經(jīng)過(guò)實(shí)施校正、控制反饋之后，提出變更需求，再將變更后的需求輸入實(shí)施過(guò)程，在進(jìn)一步的控制反饋之后，再一次提出變更完善的需求……這個(gè)循環(huán)往復(fù)的過(guò)程可能會(huì)貫穿項(xiàng)目始終。正是這個(gè)原因，在現(xiàn)代軟件開(kāi)發(fā)理念中，需求的變更和變更申請(qǐng)占有很重要的地位。我們應(yīng)該深刻理解項(xiàng)目需求的兩難境地：一種傾向是：當(dāng)前景不確定因素太多的時(shí)候，通過(guò)猜測(cè)構(gòu)造一個(gè)似乎詳盡面面俱到的需求規(guī)格說(shuō)明，由于這個(gè)需求相當(dāng)繁復(fù)，在發(fā)生變化的時(shí)候根本無(wú)法更新這個(gè)復(fù)雜的需求文檔，結(jié)果原始的需求被束之高閣。另一種傾向是：初期需求編的太粗，以便留下變更的彈性，結(jié)果是需求的粗糙又為實(shí)施過(guò)程制造了大量新的不確定性因素，迫使需求反復(fù)修改，這種按下葫蘆浮起瓢的局面，最后導(dǎo)致了一個(gè)災(zāi)難性的后果，也就是需求變成了一個(gè)毫無(wú)威信的文字游戲，誰(shuí)也不認(rèn)真對(duì)待了。需求的滾動(dòng)完善模式，把需求失控的被動(dòng)變更，變成了可控的主動(dòng)變更，可以有效地解決上述矛盾。關(guān)鍵的問(wèn)題是，我們從思想層面不要認(rèn)為需求是一個(gè)固態(tài)不變的東西，也不能認(rèn)為只要我們付出足夠的努力，就可以發(fā)現(xiàn)所有包括潛在的需求，并且把需求凍結(jié)起來(lái)。需求是一個(gè)人們認(rèn)識(shí)世界的過(guò)程，不可避免的會(huì)受到認(rèn)識(shí)論規(guī)律的限制。認(rèn)清了這一點(diǎn)，我們就可以主動(dòng)尋找解決辦法。反之，我們除了牢騷滿(mǎn)腹唉聲嘆氣以外，恐怕再也沒(méi)什么好辦法了。3.2更點(diǎn)放在哪里更合適？問(wèn)題在于在這種需求可能發(fā)生變更、計(jì)劃也可能變更的環(huán)境下，如何保證開(kāi)發(fā)的有序、受控、便于管理并且符合標(biāo)準(zhǔn)呢？換句話(huà)說(shuō)，需求的變更點(diǎn)應(yīng)該在什么地方呢？需求的變更是隨時(shí)都可能發(fā)生的，隨意的變更需求致使需求發(fā)生蠕變，除了造成混亂以外沒(méi)有其它作用。為了減少需求變更對(duì)于開(kāi)發(fā)的不利影響，防止項(xiàng)目隨著需求變更也不斷隨需而變，我們可以制定這樣的規(guī)則，如下圖所示：首先：以每個(gè)里程碑為一個(gè)單元制定項(xiàng)目計(jì)劃，建議一個(gè)里程碑的時(shí)間長(zhǎng)度為項(xiàng)目整個(gè)生命周期的1/12左右，每個(gè)里程碑是一個(gè)完整的計(jì)劃、實(shí)施與控制過(guò)程，其任務(wù)就是交付一定數(shù)量的產(chǎn)品。其次：在一個(gè)里程碑時(shí)間段內(nèi)需求是不能變更的（如果客戶(hù)有變更要求可以說(shuō)：現(xiàn)在離里程碑點(diǎn)已經(jīng)不遠(yuǎn)了，先記下來(lái)，到那個(gè)時(shí)候一起討論），所有團(tuán)隊(duì)成員全力以赴達(dá)到里程碑目標(biāo)。最后：在每個(gè)里程碑點(diǎn)上，除了傳統(tǒng)的檢查評(píng)審以外，還需要加上一項(xiàng)，就是與客戶(hù)一起主動(dòng)尋求新的需求，進(jìn)而制定新的計(jì)劃，化被動(dòng)為主動(dòng)。這樣一來(lái)，需求管理與項(xiàng)目管理之間的集成關(guān)系就變得清晰了，從順序上來(lái)說(shuō)，在需求分析與計(jì)劃制定上要分三個(gè)層次來(lái)考慮問(wèn)題：首先考慮遠(yuǎn)期目標(biāo)，先有目標(biāo)分析，確定最終成功交付的一個(gè)稍稍模糊但是具有宏觀指導(dǎo)意義的目標(biāo)。遠(yuǎn)期宏觀需求不能沒(méi)有，不然會(huì)形成一個(gè)目光短淺隨需而變的開(kāi)發(fā)；也不能太詳細(xì)，否則會(huì)形成靠猜測(cè)形成的GlassCaseRequirements（玻璃柜需求），既無(wú)法更新，也無(wú)法應(yīng)對(duì)需求變更，最后這個(gè)需求被束之高閣，計(jì)劃也不會(huì)被遵循。然后是中期目標(biāo)，也就是里程碑目標(biāo)，根據(jù)需求的優(yōu)先級(jí)，設(shè)定每個(gè)里程碑需要交付的功能，也就是說(shuō)，里程碑計(jì)劃關(guān)注的是該點(diǎn)的結(jié)果，而不是活動(dòng)。最后才是近期目標(biāo)，以目前的里程碑（很多情況下還包括下一個(gè)里程碑）為界，進(jìn)行詳細(xì)的需求細(xì)化分析，然后再規(guī)劃里程碑期間的任務(wù)和活動(dòng)，這就可以根據(jù)現(xiàn)有的狀況來(lái)應(yīng)變，使計(jì)劃可以落實(shí)。從宏觀上說(shuō)，里程碑實(shí)施是動(dòng)態(tài)的，而里程碑評(píng)審是靜態(tài)的。對(duì)于變化而言，動(dòng)態(tài)過(guò)程中實(shí)施變化要比靜態(tài)過(guò)程實(shí)施變化難得多，所以堅(jiān)持了這個(gè)規(guī)則，就有可能在動(dòng)態(tài)實(shí)施與靜態(tài)變化之間實(shí)現(xiàn)了良好平衡。3.3現(xiàn)代軟件過(guò)程域之間的關(guān)系讓我們進(jìn)一步研究，符合上述所有理念的的軟件工程方法到底應(yīng)該是什么樣的？我們可以發(fā)現(xiàn)，現(xiàn)代軟件工程各個(gè)過(guò)程域之間的關(guān)系不再是一個(gè)線性的關(guān)系，而是一種迭代的關(guān)系，中間必須有計(jì)劃的加入各種反饋、控制和修正，如下圖所示（此圖取自于GJB5000A-2008，基于軍標(biāo)的軟件工程描述，可以認(rèn)為很好的詮譯了現(xiàn)代軟件工程思想）。需求開(kāi)發(fā)與管理并不是獨(dú)立存在的，而是需要與項(xiàng)目管理的其它領(lǐng)域整合在一起，形成一種集成管理體系。事實(shí)上未經(jīng)整合的各個(gè)領(lǐng)域管理規(guī)劃，是不宜于指導(dǎo)項(xiàng)目的實(shí)施和控制的，只有整合成一套集成管理之后，才具備指導(dǎo)實(shí)踐的實(shí)質(zhì)性意義，對(duì)此我們要有充分的理解。迭代式開(kāi)發(fā)方式的特點(diǎn)是：并不監(jiān)督一個(gè)長(zhǎng)期的計(jì)劃執(zhí)行，而是研究如何引領(lǐng)軟件項(xiàng)目通過(guò)“不確定性”所帶來(lái)的壕溝?！耙I(lǐng)”一詞隱含著這樣一層意思：管理層主動(dòng)參與，不斷糾正航向，目標(biāo)是生產(chǎn)出更好的軟件。而這個(gè)對(duì)于目標(biāo)的“瞄準(zhǔn)”是由利益相關(guān)人相互合作達(dá)成的。4.復(fù)雜系統(tǒng)的需求分解如果我們承認(rèn)需求變更是不可避免的，那么在這種變更環(huán)境下，如何確保需求開(kāi)發(fā)能夠支持這種變化呢？換句話(huà)說(shuō)，如何保證在需求發(fā)生變化的時(shí)候不至造成開(kāi)發(fā)的混亂呢？讓我們來(lái)觀察一下實(shí)踐中需求發(fā)生變化的規(guī)律，我們發(fā)現(xiàn)，大部分變更是在局部發(fā)生的，很少有在系統(tǒng)的全局的方面發(fā)生變更。在發(fā)生需求變更的時(shí)候，很多困難在于局部變更引起的互相影響，這種影響越大，變更就越困難?？偨Y(jié)這個(gè)規(guī)律，我們就可以制定一些對(duì)策。4.1前期進(jìn)行合理劃分為了限制變更的范圍，首先要做的事情就是在前期合理的劃分。4.1.1子系統(tǒng)的分解原則任何復(fù)雜系統(tǒng)，都可以分解成小問(wèn)題也就是子系統(tǒng)，每個(gè)子系統(tǒng)子系統(tǒng)都是具有完整系統(tǒng)架構(gòu)的復(fù)雜系統(tǒng)組成部分，它可以合理的解釋和證明、成功的設(shè)計(jì)與制造，然后在集成到整個(gè)系統(tǒng)中去。子系統(tǒng)還可以分解成子系統(tǒng)，這種分解（或逐步細(xì)化）過(guò)程會(huì)一直進(jìn)行下去，如下圖所示。如果我們能夠把變化限制在一個(gè)比較小的范圍內(nèi)，就可以極大的抑制需求變化給后期開(kāi)發(fā)帶來(lái)的不利影響。為此，每一個(gè)被分解出來(lái)的功能單元（子系統(tǒng)、產(chǎn)品部件）應(yīng)該是內(nèi)聚的，也就是內(nèi)部業(yè)務(wù)關(guān)系要緊密，外部的業(yè)務(wù)關(guān)系要松散。另一方面，任何功能單元（子系統(tǒng)、產(chǎn)品部件）之間不能直接交互，它們的交互必須通過(guò)上層管理單元來(lái)進(jìn)行。這種交互必須事先設(shè)定良好的接口，由于限制了變化的范圍，就可以保證任何功能單元的變化都不至于造成對(duì)其它方面的影響，如下圖所示。子系統(tǒng)的劃分有三項(xiàng)原則：對(duì)功能進(jìn)行分布和劃分，對(duì)于以最小的成本和最大的靈活性來(lái)完成系統(tǒng)整體的功能來(lái)說(shuō)是最優(yōu)的。每個(gè)子系統(tǒng)都可以被一個(gè)小型團(tuán)隊(duì)所定義、設(shè)計(jì)與開(kāi)發(fā)。在成功地模擬了子系統(tǒng)的其它子系統(tǒng)的接口之后，每個(gè)子系統(tǒng)都可以單獨(dú)進(jìn)行可靠性測(cè)試。從系統(tǒng)的角度考慮需求，就需要把子系統(tǒng)作為一個(gè)重要的實(shí)體加以考慮。首先賦予子系統(tǒng)功能描述（例如：子系統(tǒng)B將運(yùn)行風(fēng)速算法，并直接驅(qū)動(dòng)前導(dǎo)顯示器），然后再自上而下的分解需求。4.1.2功能單元的分解原則對(duì)于功能單元的劃分也有三項(xiàng)原則：功能單元切割規(guī)律如下圖所示，隨著單元數(shù)量的增加，開(kāi)發(fā)成本減低，但是系統(tǒng)集成的成本增加，所以最小成本的區(qū)域在一個(gè)合適的區(qū)間。也就是說(shuō)，單元并不是越小越好，只有單元數(shù)量適當(dāng)?shù)臅r(shí)候，總體成本才可能下降。一般保證單元數(shù)量處于最小成本區(qū)的方法，是力爭(zhēng)功能單元的大小以一個(gè)人在一個(gè)里程碑時(shí)間內(nèi)（或者說(shuō)一個(gè)迭代周期）能完成為好（類(lèi)似的，這里可以參照80原則，也就是一個(gè)任務(wù)的大小一般以80人時(shí)為合理）。應(yīng)該努力使每個(gè)單元的大小差別在一個(gè)數(shù)量級(jí)之內(nèi)。如果發(fā)現(xiàn)某個(gè)單元規(guī)模太大，就需要實(shí)現(xiàn)切割，然后針對(duì)這種切割的結(jié)果，反過(guò)來(lái)修改需求。系統(tǒng)工程學(xué)是以系統(tǒng)論的思想和系統(tǒng)方法論為基礎(chǔ)，借助控制論、運(yùn)籌學(xué)、統(tǒng)計(jì)學(xué)、信息處理和計(jì)算機(jī)技術(shù)，研究復(fù)雜系統(tǒng)的構(gòu)成和子系統(tǒng)的相互作用，對(duì)系統(tǒng)構(gòu)成要素、組織結(jié)構(gòu)、信息流動(dòng)和控制機(jī)構(gòu)進(jìn)行分析，從而掌握系統(tǒng)隨時(shí)間推移而產(chǎn)生的行為模式。需求工程是系統(tǒng)工程學(xué)的一個(gè)應(yīng)用，因此需求開(kāi)發(fā)人員必須有從系統(tǒng)的角度看問(wèn)題的能力。4.1.3關(guān)于派生的需求上述的工程方法可以看成一種問(wèn)題分析技術(shù)，幫助我們理解在系統(tǒng)中運(yùn)行的軟件的需求。這也是不斷把復(fù)雜系統(tǒng)分解為簡(jiǎn)單系統(tǒng)的過(guò)程。在這樣的情況下，我們會(huì)生成一些派生的需求，典型情況下，派生需求可以分成兩種：子系統(tǒng)需求：是子系統(tǒng)必須滿(mǎn)足，但隨最終用戶(hù)未必有直接利益的那種需求（例如：子系統(tǒng)A必須計(jì)算飛行器的空速）。接口需求：是子系統(tǒng)為了完成整體任務(wù)，必須與另一個(gè)子系統(tǒng)進(jìn)行通信產(chǎn)生的需求，子系統(tǒng)創(chuàng)建的同時(shí)也促進(jìn)了子系統(tǒng)之間接口的創(chuàng)建。但是這些子系統(tǒng)需求是真的需求嗎？對(duì)最終用戶(hù)來(lái)說(shuō)，它可能并不是重要的。但對(duì)于需求人員來(lái)說(shuō)，開(kāi)發(fā)人員也是需求的提供者，這些需求對(duì)于開(kāi)發(fā)人員是重要的，所以也是一種至關(guān)重要的需求。還需要注意的是，這些子系統(tǒng)需求是由系統(tǒng)的分解得來(lái)的，不同的分解方式會(huì)產(chǎn)生不同的派生需求。所以，在前期設(shè)計(jì)人員參加一些討論是非常有意義的。4.1.4處理極其復(fù)雜的系統(tǒng)的建議在處理極其復(fù)雜的系統(tǒng)的時(shí)候，我們可能需要考慮以下建議：開(kāi)發(fā)、理解和維護(hù)橫跨子系統(tǒng)的高層需求和用例。它們描述了系統(tǒng)的整體功能，這些用例提供了系統(tǒng)整體的工作背景，要確保你沒(méi)有“只見(jiàn)樹(shù)木，不見(jiàn)森林。”他們還有助于確保系統(tǒng)架構(gòu)設(shè)計(jì)支持最可能的使用場(chǎng)景。把劃分工作做得最好，并把功能限制在子系統(tǒng)范圍內(nèi)。在系統(tǒng)功能中使用對(duì)象技術(shù)原則：封裝和信息隱蔽。根據(jù)合同建立接口，使用消息而不是數(shù)據(jù)共享。當(dāng)對(duì)接口進(jìn)行仔細(xì)考慮。否則如果有什么變化（比如優(yōu)化）的話(huà)，接口兩端的同步將會(huì)非常困難。另一方面，如果將來(lái)兩個(gè)子系統(tǒng)之間的界限消失，比如系統(tǒng)工程師發(fā)現(xiàn)兩個(gè)子系統(tǒng)可以合并，合并將會(huì)非常困難?？纯茨芊裾业揭粋€(gè)資深工程師來(lái)幫助我們實(shí)施系統(tǒng)工程，如果他以前做過(guò)類(lèi)似的工作，他的經(jīng)驗(yàn)將會(huì)對(duì)我們有很大的幫助。此外這樣做的副產(chǎn)品是，這樣做有助于消除代溝。在多團(tuán)隊(duì)開(kāi)發(fā)的時(shí)候，最好有架構(gòu)團(tuán)隊(duì)集中開(kāi)發(fā)接口實(shí)現(xiàn)，否則，各個(gè)團(tuán)隊(duì)有很多工作是重復(fù)的，甚至?xí)l(fā)生沖突，包括接口。把接口作為正式的需求，可以避免很多集成上的問(wèn)題。5.分層的需求組織方法我經(jīng)?？吹饺藗儠?shū)寫(xiě)出一個(gè)偉大的似乎面面俱到的需求規(guī)格說(shuō)明，這種規(guī)格說(shuō)明不僅僅讀者難于閱讀，連編寫(xiě)者想讀第二遍都很難下決心。它所想表達(dá)的，只不過(guò)是說(shuō)我們已經(jīng)盡了足夠努力，至于讀不讀就是另一回事了。我們應(yīng)該反復(fù)強(qiáng)調(diào)的是：需求規(guī)格說(shuō)明是給讀者讀的。所有利益相關(guān)人，包括：客戶(hù)需要審查需求；設(shè)計(jì)者需要據(jù)此完成產(chǎn)品設(shè)計(jì)；管理者需要據(jù)此編寫(xiě)項(xiàng)目計(jì)劃；測(cè)試者需要據(jù)此編寫(xiě)測(cè)試案例。因此，需求的可讀性是一個(gè)關(guān)乎項(xiàng)目是否成功的關(guān)鍵因素。我們必須了解到，很少有需求能夠在單個(gè)文檔中定義，其原因是：系統(tǒng)可能非常復(fù)雜，建檔數(shù)量較大，需要有組織的和交互訪問(wèn)的技術(shù)。該系統(tǒng)可能是相關(guān)產(chǎn)品系列的一個(gè)成員，沒(méi)有什么文檔可以包括所有的規(guī)格說(shuō)明。所構(gòu)建的系統(tǒng)可能只是一個(gè)大型系統(tǒng)的子系統(tǒng)，僅能滿(mǎn)足所確定需求的一個(gè)子集。必須把市場(chǎng)和商業(yè)目標(biāo)從產(chǎn)品的詳細(xì)需求分離出來(lái)，這需要多個(gè)文檔。也可能在系統(tǒng)中建立制度或法規(guī)這樣的需求，這些需求可以在其它地方進(jìn)行建擋。在大多數(shù)情況下，我們可能需要維護(hù)組成多個(gè)需求集的需求，每個(gè)需求集反映了一個(gè)特殊系統(tǒng)加上若干子系統(tǒng)的集合的需求。5.1分層的需求創(chuàng)建過(guò)程對(duì)于非常復(fù)雜的系統(tǒng)，唯一合理的方法是把它創(chuàng)建成由多個(gè)子系統(tǒng)組成的系統(tǒng)，這些子系統(tǒng)有時(shí)是其它子系統(tǒng)構(gòu)成的系統(tǒng)。在特殊情況下，比如飛機(jī)控制系統(tǒng)，將包括上百個(gè)子系統(tǒng)，而每個(gè)子系統(tǒng)都有自己的硬件組件和軟件。5.1.1創(chuàng)建系統(tǒng)級(jí)的需求規(guī)格說(shuō)明在這樣的情況下，首先創(chuàng)建一個(gè)系統(tǒng)級(jí)的需求規(guī)格說(shuō)明，在不了解或者不引用任何子系統(tǒng)的情況下來(lái)描述系統(tǒng)的功能行為。例如飛機(jī)油料的裝載能力、爬升速度、飛行最大高度等等。這種規(guī)格說(shuō)明并不需要描述很多細(xì)節(jié)，力求在抽象層面從期整體上把需求說(shuō)明清楚。若干“用戶(hù)故事”經(jīng)過(guò)歸納整理，可以拼合成一些“主題”，這些主題潛在的就是一個(gè)子系統(tǒng)的需求描述。5.1.2進(jìn)行子系統(tǒng)劃分如同我們?cè)谏弦还?jié)討論過(guò)的，一旦對(duì)系統(tǒng)級(jí)的需求達(dá)成共識(shí)，就開(kāi)始系統(tǒng)工程活動(dòng)。我們可以把系統(tǒng)分解成多個(gè)子系統(tǒng)，描述子系統(tǒng)之間的接口，把系統(tǒng)級(jí)的需求分配到各個(gè)子系統(tǒng)，由此產(chǎn)生了系統(tǒng)架構(gòu)描述，定義了系統(tǒng)劃分以及系統(tǒng)之間的接口。5.1.3開(kāi)發(fā)子系統(tǒng)需求規(guī)格說(shuō)明下一步，為每個(gè)子系統(tǒng)開(kāi)發(fā)一個(gè)需求規(guī)格說(shuō)明，這些規(guī)格說(shuō)明應(yīng)該在不引用它自己的子系統(tǒng)的情況下，完整地描述它的外部行為。在這個(gè)過(guò)程中會(huì)產(chǎn)生一類(lèi)新的需求：派生需求。這類(lèi)需求不是描述整個(gè)系統(tǒng)的外部行為，而是描述子系統(tǒng)的外部行為，因此，系統(tǒng)設(shè)計(jì)過(guò)程為組成系統(tǒng)的子系統(tǒng)創(chuàng)建了新的需求。特別是系統(tǒng)之間的接口成為關(guān)鍵需求。本質(zhì)上這是子系統(tǒng)與另一個(gè)子系統(tǒng)之間的契約，或者是對(duì)子系統(tǒng)同意完成的事情的承諾。5.1.4對(duì)子系統(tǒng)進(jìn)行劃分一旦需求達(dá)成一致，再次進(jìn)行系統(tǒng)地分析和設(shè)計(jì)，如果需要，可以進(jìn)一步把子系統(tǒng)分解成它自己的子系統(tǒng)，并且分別開(kāi)發(fā)各個(gè)子系統(tǒng)的需求規(guī)格說(shuō)明，如下圖所示。每一層，都把來(lái)自上一層的需求規(guī)格說(shuō)明分配給適當(dāng)?shù)南乱患?jí)需求規(guī)格說(shuō)明。例如，燃料容量需求分配給燃料控制系統(tǒng)和燃料儲(chǔ)備系統(tǒng)，同時(shí)恰當(dāng)?shù)陌l(fā)現(xiàn)和定義新的需求。直到最底層的需求規(guī)格說(shuō)明指，也就是那些不能再分割的需求規(guī)格說(shuō)明。5.2自上而下與自下而上這種按層劃分的需求分析要求工作方法有兩個(gè)線路：5.2.1自上而下在系統(tǒng)的層面，仔細(xì)分析從總體的角度有哪些要求，這些要求如何聚合成若干比較大的子系統(tǒng)，這些子系統(tǒng)又需要達(dá)到哪些目標(biāo)？他們需要哪些功能集？交互上需要什么樣的接口？如何進(jìn)行測(cè)試？以此形成系統(tǒng)級(jí)的規(guī)格說(shuō)明。然后每個(gè)子系統(tǒng)再逐漸按層細(xì)分，逐漸求精達(dá)到所需要的精細(xì)度。5.2.2自下而上仔細(xì)分析下層系統(tǒng)的需求，分析這些需求是如何保證達(dá)成上層需求的，已有的需求集對(duì)于上層要求是不是充分而必要的？有沒(méi)有多余的部分？各個(gè)子部分交互的接口應(yīng)該是怎樣的？它們與上層的交互是不是符合上層接口規(guī)范？通過(guò)自下而上的分析以發(fā)現(xiàn)原來(lái)沒(méi)有發(fā)現(xiàn)的問(wèn)題。這種自上而下、自下而上的過(guò)程可能要反復(fù)多次，以確保整體上需求是合理的。在需求的書(shū)寫(xiě)方法上不要求所有需求都書(shū)寫(xiě)在一起，可以根據(jù)規(guī)劃把系統(tǒng)級(jí)、子系統(tǒng)級(jí)（或者更下層需求集）分開(kāi)書(shū)寫(xiě)、分別評(píng)審并且賦給不同的開(kāi)發(fā)團(tuán)隊(duì)。事實(shí)上從更廣大的眼光來(lái)看，任何一個(gè)軟件系統(tǒng)都不可能獨(dú)立存在，它們都是更大系統(tǒng)的一個(gè)子部分，因此這樣的處理方式是更符合實(shí)際情況、也是更有效的。5.2.3關(guān)注相互間的關(guān)系在以系統(tǒng)的角度處理需求的時(shí)候，我們的眼界要比較寬，要關(guān)注各個(gè)單元之間的關(guān)系，也要關(guān)注到變化對(duì)各個(gè)單元的影響，一個(gè)經(jīng)驗(yàn)豐富的需求開(kāi)發(fā)人員還應(yīng)該能預(yù)測(cè)變化點(diǎn)。一般來(lái)說(shuō)，對(duì)于需求開(kāi)發(fā)能力可分為三個(gè)層次：第一層次：可以看到需求與各個(gè)要素之間的互動(dòng)關(guān)系。這是算術(shù)級(jí)，能夠發(fā)現(xiàn)變化的產(chǎn)生。第二層次：能夠區(qū)別需求與其它互動(dòng)要素中主動(dòng)和被動(dòng)關(guān)系。這是代數(shù)級(jí)，能夠發(fā)現(xiàn)變化之間的因果關(guān)系，由因果關(guān)系更深一步發(fā)現(xiàn)反饋通道。最高層次：能夠判斷出各類(lèi)要素在不同時(shí)間段的主要和次要關(guān)系的轉(zhuǎn)化。這是導(dǎo)數(shù)級(jí)，能夠發(fā)現(xiàn)變化要素的變化趨勢(shì)。這些都對(duì)需求分析師提出了更高的要求。5.3需求開(kāi)發(fā)需要堅(jiān)持規(guī)范對(duì)于及其復(fù)雜的系統(tǒng)的需求開(kāi)發(fā)，特別是在易于變化的環(huán)境中，我們更需要強(qiáng)調(diào)堅(jiān)持規(guī)范，為什么呢？在這中間人們會(huì)有什么困惑呢？5.3.1為什么要強(qiáng)調(diào)堅(jiān)持規(guī)范談到需求開(kāi)發(fā)自然會(huì)遇到對(duì)于規(guī)范的理解，很多人對(duì)于執(zhí)行規(guī)范有天生的抵觸，也有人懷疑在軟件開(kāi)發(fā)中執(zhí)行規(guī)范會(huì)不會(huì)抑制了人們的創(chuàng)造力？是不是會(huì)提高產(chǎn)品開(kāi)發(fā)成本？會(huì)不會(huì)使項(xiàng)目延期？事實(shí)上需求開(kāi)發(fā)本身就是制定規(guī)范，需求是開(kāi)發(fā)、測(cè)試、驗(yàn)收的一種約束，沒(méi)有需求約束的開(kāi)發(fā)風(fēng)險(xiǎn)是非常大的。當(dāng)產(chǎn)品規(guī)模和重要性比較小的時(shí)候，適當(dāng)“短路”規(guī)范也不是不可以，但是當(dāng)產(chǎn)品規(guī)模很大、其重要性和影響力都很大的時(shí)候，不執(zhí)行規(guī)范風(fēng)險(xiǎn)就太大了。更重要的是身為中國(guó)人，在這個(gè)文化背景下人們對(duì)于規(guī)范大多數(shù)找不到感覺(jué)，人們習(xí)慣于來(lái)了風(fēng)就是雨，修修補(bǔ)補(bǔ)不斷加班，已經(jīng)到了嚴(yán)重影響產(chǎn)品質(zhì)量的程度。因此在中國(guó)文化這個(gè)大背景下更強(qiáng)調(diào)規(guī)范是完全必要的。5.3.2規(guī)范不是教條要注意的是，迭代（包括敏捷）并不是不要規(guī)范，而是更合理的應(yīng)用規(guī)范。規(guī)范并不是教條，制定良好的可執(zhí)行的規(guī)范就需要關(guān)注各個(gè)領(lǐng)域之間的互動(dòng)關(guān)系。實(shí)踐表明，在整個(gè)項(xiàng)目的進(jìn)展過(guò)程中，需求的變更不可避免，其影響力相當(dāng)大。需求的變更不可避免的會(huì)與各個(gè)要素產(chǎn)生互動(dòng)影響，而且大多數(shù)情況下處在一個(gè)主動(dòng)位置：需求的變化會(huì)引起重新設(shè)計(jì)，進(jìn)而影響計(jì)劃、時(shí)間、成本和質(zhì)量。需求的變化也會(huì)影響確認(rèn)和驗(yàn)證，質(zhì)量標(biāo)準(zhǔn)的變化會(huì)影響工期和成本。實(shí)踐中我們會(huì)發(fā)現(xiàn)，設(shè)計(jì)影響需求的情況也屢見(jiàn)不鮮。概而言之，需求對(duì)項(xiàng)目其它領(lǐng)域的影響可能是被動(dòng)的，也可能是主動(dòng)的，這種因果關(guān)系極其復(fù)雜，弄得不好會(huì)使項(xiàng)目一片混亂，這一切都構(gòu)成了項(xiàng)目開(kāi)發(fā)中中最具挑戰(zhàn)性的內(nèi)容。因此，加強(qiáng)規(guī)范性就要從需求對(duì)各個(gè)要素相互作用力的角度想問(wèn)題：到底是誰(shuí)在影響誰(shuí)？影響后又發(fā)生了什么？會(huì)有什么樣的結(jié)果？怎么來(lái)解決？這種解決方案是正反饋還是負(fù)反饋？如果是正反饋的話(huà)，如何改變反饋通道使其變?yōu)樨?fù)反饋呢？這是一個(gè)睿智的高級(jí)技術(shù)與管理人員必須時(shí)時(shí)纏繞在腦海中的問(wèn)題，這樣一來(lái)我們就有了大思維，有了解決問(wèn)題的能力。5.3.3堅(jiān)持規(guī)范性的文檔是必須的無(wú)論需求是表示成用戶(hù)故事、特性列表、用例集、或者是其它的形式，都必須獲取需求并形成文檔。一個(gè)由多人參與的工作不可避免的存在交流問(wèn)題，這就需要獲取一份能夠被復(fù)審和批準(zhǔn)，大家都認(rèn)可的，用來(lái)參考的文檔。傳統(tǒng)上，利用需求規(guī)格說(shuō)明這種大型文檔，來(lái)獲取和交流這種信息，盡管敏捷開(kāi)發(fā)基本理念似乎并不需要這樣的大型文檔。但對(duì)于大型復(fù)雜的敏捷項(xiàng)目，不可能沒(méi)有需求規(guī)格說(shuō)明就盲目的開(kāi)始項(xiàng)目開(kāi)發(fā)，關(guān)鍵是這種規(guī)格說(shuō)明的粒度要合理。5.3.4編寫(xiě)便于閱讀的需求需求的編寫(xiě)應(yīng)該便于閱讀并且與階段性的關(guān)注點(diǎn)保持一致。長(zhǎng)篇大論事無(wú)巨細(xì)匯集到一起的需求不容易閱讀、不便于開(kāi)發(fā)、更不能發(fā)揮應(yīng)有的作用。整個(gè)需求編寫(xiě)過(guò)程有點(diǎn)像編寫(xiě)書(shū)的提綱，一本書(shū)有部、章、節(jié)三級(jí)提綱，后面的二級(jí)提綱會(huì)隨著一級(jí)大綱的推進(jìn)而逐步展開(kāi)，而三級(jí)提綱將隨著二級(jí)提綱的推進(jìn)而逐步細(xì)化。需求的編寫(xiě)與匯集應(yīng)該進(jìn)行合理的分解，清晰的分離開(kāi)如下三個(gè)層次：宏觀層面的系統(tǒng)級(jí)需求、聚集層面的子系統(tǒng)需求（包括子系統(tǒng)接口）、細(xì)節(jié)層面的產(chǎn)品部件需求（包括模塊接口）。不同層面的需求應(yīng)該分開(kāi)書(shū)寫(xiě)，并且自上而下逐步分解和求精。需求的層次關(guān)系要很清楚，要注意下層需求對(duì)于上層目標(biāo)的支持關(guān)系。這種把不確定性因素逐步明朗、由粗變細(xì)、循序展開(kāi)的方法，可以同時(shí)兼顧需求的剛性和彈性、前瞻性、反饋性、準(zhǔn)確性等諸多要求。6.需求開(kāi)發(fā)過(guò)程定義為了正確進(jìn)行上述所有理念的需求開(kāi)發(fā)，讓需求開(kāi)發(fā)成為一種組織行為，我們需要定義一套行之有效的需求開(kāi)發(fā)過(guò)程。在定義過(guò)程的時(shí)候需要參照一些標(biāo)準(zhǔn)，以明確需求開(kāi)發(fā)所包含的范圍，下面的描述參照了GJB5000A-2008中“需求開(kāi)發(fā)（RD）”過(guò)程域的要求。描述過(guò)程首先需要明確目標(biāo)，再通過(guò)若干實(shí)踐確保這些目標(biāo)能夠達(dá)到。需求開(kāi)發(fā)過(guò)程中所產(chǎn)生的需求包括三類(lèi)：客戶(hù)需求、產(chǎn)品需求和產(chǎn)品部件需求。因此，需求開(kāi)發(fā)過(guò)程就應(yīng)該包括三個(gè)最基本的目標(biāo)：開(kāi)發(fā)客戶(hù)需求：定義一組客戶(hù)需求，用于開(kāi)發(fā)產(chǎn)品需求；開(kāi)發(fā)產(chǎn)品需求：涉及定義一組產(chǎn)品和產(chǎn)品部件的需求，用于設(shè)計(jì)產(chǎn)品和產(chǎn)品部件；分析和確認(rèn)需求：對(duì)客戶(hù)、產(chǎn)品和產(chǎn)品部件需求作必要分析，以定義、導(dǎo)出和理解該需求。第三個(gè)目標(biāo)和實(shí)踐的意圖是幫助前兩個(gè)目標(biāo)中的實(shí)踐，這就繪出了需求開(kāi)發(fā)總體過(guò)程如下圖所示。在實(shí)際項(xiàng)目中，為了達(dá)成這三個(gè)目標(biāo)其工作程序并不是順序的，其中會(huì)有相當(dāng)?shù)闹丿B、并發(fā)和反饋。過(guò)程非常重要，它給我們帶來(lái)了工作風(fēng)格上的條理性和方法。流程是底線，在流程的每個(gè)節(jié)點(diǎn)我們必須充分發(fā)揮人的主動(dòng)性、積極性和創(chuàng)造精神，工作成果是有質(zhì)量上的區(qū)別的，但有了這個(gè)底線就可以避免很多低級(jí)錯(cuò)誤，也可以避免很多模糊不確定之處。下面我們對(duì)需求開(kāi)發(fā)目標(biāo)與實(shí)踐進(jìn)行比較詳細(xì)的描述。6.1開(kāi)發(fā)客戶(hù)需求目的：將利益相關(guān)方的需要、期望、約束和接口轉(zhuǎn)換為文檔化的客戶(hù)需求。從目前各個(gè)企業(yè)需求開(kāi)發(fā)實(shí)踐來(lái)看，利益相關(guān)方的需要、期望、約束和接口往往標(biāo)識(shí)的不好或有矛盾，對(duì)后期開(kāi)發(fā)造成不小的負(fù)面影響。解決這個(gè)問(wèn)題的方法就是貫穿項(xiàng)目生存周期采用迭代的過(guò)程以達(dá)到這個(gè)目標(biāo)。在采用必需的迭代過(guò)程時(shí)，應(yīng)該吸納最終用戶(hù)或客戶(hù)的代表參與，以代表他們的需要并幫助解決矛盾。在很多情況下，機(jī)構(gòu)的客戶(hù)聯(lián)系部門(mén)、市場(chǎng)部門(mén)以及產(chǎn)品部門(mén)的成員可作為客戶(hù)代理來(lái)幫助呈請(qǐng)一些問(wèn)題。在創(chuàng)建客戶(hù)需求集時(shí)還應(yīng)該考慮環(huán)境、法律和其它限制。實(shí)踐1.1：引出需要需要采取各種方法來(lái)引出利益相關(guān)方對(duì)產(chǎn)品生存周期所有階段的需要、期望、限制和接口。引出過(guò)程不只是被動(dòng)的收集需求，更需要積極地標(biāo)識(shí)客戶(hù)未明確提出的額外需求。額外需求應(yīng)闡述各種產(chǎn)品生存周期活動(dòng)以及它們對(duì)產(chǎn)品的影響。引出需要的方法很多，例如可以采用如下一些方法：技術(shù)演示。接口控制工作組交流接口對(duì)于需求的影響。技術(shù)控制工作組交流設(shè)計(jì)對(duì)于需求的影響。。項(xiàng)目中間評(píng)審所發(fā)現(xiàn)的問(wèn)題和需要。提問(wèn)單、訪談和從最終用戶(hù)處獲得的運(yùn)行場(chǎng)景。運(yùn)行的逐步檢查和最終用戶(hù)任務(wù)分析。通過(guò)原型和模型發(fā)現(xiàn)需求。頭腦風(fēng)暴會(huì)以。質(zhì)量需求的展開(kāi)、分解與細(xì)化。市場(chǎng)調(diào)查、分析與綜合。Beta測(cè)試。從諸如文檔、標(biāo)準(zhǔn)和規(guī)格說(shuō)明等來(lái)源的摘錄。對(duì)現(xiàn)有產(chǎn)品、環(huán)境和工作模式的觀察以遞推到新產(chǎn)品的需要。使用案例分析。業(yè)務(wù)案例分析。對(duì)傳統(tǒng)產(chǎn)品進(jìn)行逆向工程。用戶(hù)滿(mǎn)意度調(diào)查。有些需求來(lái)源可能不能被用戶(hù)所標(biāo)識(shí)，但也是重要的來(lái)源，例如：目標(biāo)客戶(hù)的業(yè)務(wù)策略構(gòu)想。技術(shù)標(biāo)準(zhǔn)、業(yè)務(wù)標(biāo)準(zhǔn)。業(yè)務(wù)環(huán)境的需求（如：實(shí)驗(yàn)室、測(cè)試和其它設(shè)施以及信息技術(shù)基礎(chǔ)設(shè)施）。新技術(shù)的采用。從已有產(chǎn)品或產(chǎn)品部件中發(fā)現(xiàn)可重用產(chǎn)品/部件的相關(guān)需要。建議：利用引出需要、期望、限制和外部接口的時(shí)候應(yīng)該吸納利益相關(guān)方參與。實(shí)踐1.2：開(kāi)發(fā)客戶(hù)需求通過(guò)引出過(guò)程所收集的信息，將利益相關(guān)方的需要、期望、限制和接口轉(zhuǎn)換為客戶(hù)需求。己識(shí)別的客戶(hù)需求集應(yīng)該文檔化，此時(shí)應(yīng)該整理來(lái)自利益相關(guān)方的各種輸入，特別要關(guān)注獲得遺漏信息，并解決其中的矛盾?？蛻?hù)需求可以包括關(guān)于驗(yàn)證和確認(rèn)的需要、期望和限制。在某些情況下，客戶(hù)可能已經(jīng)提供了完整的需求，或者需求作為前一個(gè)項(xiàng)目活動(dòng)的輸出已經(jīng)存在。在這些情況下，也不應(yīng)被動(dòng)的認(rèn)為需求已經(jīng)完成，而是要注意客戶(hù)的需求可能與相關(guān)的利益相關(guān)方的需要、期望、限制和接口發(fā)生矛盾，此時(shí)需要發(fā)現(xiàn)和解決這些矛盾，在矛盾恰當(dāng)?shù)亟鉀Q后，需要將其轉(zhuǎn)換為相關(guān)的利益相關(guān)方認(rèn)可的完整客戶(hù)需求。客戶(hù)需求源自于精明的業(yè)務(wù)決策及其需求的技術(shù)效果，在產(chǎn)品生存周期各個(gè)階段，利益相關(guān)方應(yīng)該包括業(yè)務(wù)和技術(shù)職能兩方面。從這一點(diǎn)來(lái)看，需要把產(chǎn)品生存周期的階段性方案與產(chǎn)品的最終方案同時(shí)考慮。這意味著：在制定項(xiàng)目計(jì)劃的時(shí)候，每個(gè)里程碑處必須定義可以運(yùn)行的交付物，并且在每個(gè)里程碑開(kāi)始的時(shí)候，需要針對(duì)這些交付物的需求進(jìn)行細(xì)化。此實(shí)踐的典型工作產(chǎn)品包括：客戶(hù)需求；客戶(hù)關(guān)于進(jìn)行驗(yàn)證的限制；客戶(hù)關(guān)于進(jìn)行確認(rèn)的限制。建議：將利益相關(guān)方的需要、期望、限制和接口轉(zhuǎn)換為文檔化的客戶(hù)需求；確定驗(yàn)證和確認(rèn)的限制。6.2開(kāi)發(fā)產(chǎn)品需求目的：精煉和細(xì)化客戶(hù)需求，并詳細(xì)說(shuō)明需開(kāi)發(fā)的產(chǎn)品需求和產(chǎn)品部件需求。需求分析人員需要與運(yùn)行方案的開(kāi)發(fā)人員一起分析客戶(hù)需求，以導(dǎo)出更詳細(xì)、精確、稱(chēng)為“產(chǎn)品需求和產(chǎn)品部件需求”的需求集。產(chǎn)品和產(chǎn)品部件需求用以說(shuō)明與產(chǎn)品生存周期每一個(gè)階段有聯(lián)系的需要，產(chǎn)品需求中將包括接口的需求。產(chǎn)品需求有一部分是導(dǎo)出的，導(dǎo)出的產(chǎn)品需求起因于約束、對(duì)某些隱含問(wèn)題的考慮以及其它一些因素而間接產(chǎn)生的。要注意到，這些問(wèn)題在客戶(hù)需求基線中并沒(méi)有明確說(shuō)明，而這些因素是基于所選擇的系統(tǒng)架構(gòu)設(shè)計(jì)、開(kāi)發(fā)者獨(dú)特的業(yè)務(wù)考慮等因素所產(chǎn)生的。在迭代開(kāi)發(fā)的每個(gè)階段，在精化后續(xù)每個(gè)較低層需求集和功能結(jié)構(gòu)時(shí)，要一起再檢查這些需求，同時(shí)對(duì)優(yōu)先選用的產(chǎn)品方案精益求精。產(chǎn)品需求將被分配到產(chǎn)品功能和產(chǎn)品部件。需求對(duì)于問(wèn)題、功能、對(duì)象、測(cè)試或其它實(shí)體的追溯性要文檔化。對(duì)產(chǎn)品部件所分配的需求和功能，是產(chǎn)品設(shè)計(jì)的基礎(chǔ)。實(shí)踐2.1：確定產(chǎn)品需求和產(chǎn)品部件需求根據(jù)客戶(hù)需求確定并維護(hù)產(chǎn)品需求和產(chǎn)品部件需求。客戶(hù)需求可以用客戶(hù)領(lǐng)域的術(shù)語(yǔ)表示，可以是非技術(shù)性表述。產(chǎn)品需求是用技術(shù)術(shù)語(yǔ)表述的需求，換句話(huà)說(shuō)，產(chǎn)品需求應(yīng)該以可測(cè)試的方式來(lái)描述，這樣就能夠用于設(shè)計(jì)決策。這種轉(zhuǎn)換的例子如：在質(zhì)量功能描述中，將客戶(hù)希望映射為技術(shù)參數(shù)和驗(yàn)收標(biāo)準(zhǔn)。產(chǎn)品需求和產(chǎn)品部件需求強(qiáng)調(diào)客戶(hù)滿(mǎn)意度、業(yè)務(wù)目標(biāo)和項(xiàng)目目標(biāo)以及一些有聯(lián)系的屬性，如效能和可支付能力。導(dǎo)出的需求還包括其它生存周期階段（例如，生產(chǎn)、運(yùn)行和處置）的成本和績(jī)效，以便與業(yè)務(wù)目標(biāo)相容。這個(gè)實(shí)踐的一些典型工作產(chǎn)品包括：導(dǎo)出的需求；產(chǎn)品需求；產(chǎn)品部件需求。建議：使用產(chǎn)品和產(chǎn)品．部件的設(shè)計(jì)所必需的技術(shù)術(shù)語(yǔ)來(lái)開(kāi)發(fā)需求。包括開(kāi)發(fā)架構(gòu)的需求，這些需求闡述產(chǎn)品結(jié)構(gòu)設(shè)計(jì)所必需的關(guān)鍵產(chǎn)品質(zhì)量和性能。導(dǎo)出由設(shè)計(jì)決策所產(chǎn)生的需求。選擇某種技術(shù)，隨之帶來(lái)其它需求。建立和維護(hù)需求間的關(guān)系，以便在更改管理與需求分配期間加以考慮。通過(guò)維護(hù)需求追溯性的各需求之間的關(guān)系，能幫助評(píng)價(jià)需求更改的影響。實(shí)踐2.2：分配產(chǎn)品部件需求將需求分配到每個(gè)產(chǎn)品部件。初期的分配可能是不準(zhǔn)確的，這個(gè)過(guò)程又必須與設(shè)計(jì)方案過(guò)程交互作用，才能確定一些可行的解決方案。從這個(gè)意義上說(shuō)，需求與設(shè)計(jì)之間是有迭代性的。產(chǎn)品部件的需求包括為滿(mǎn)足需求的產(chǎn)品性能分配、設(shè)計(jì)約束和功能。如果在更高一級(jí)的需求中規(guī)定了性能，但這種性能需求是由兩個(gè)或更多產(chǎn)品部件負(fù)擔(dān)的情況下，必須將性能劃分為對(duì)每個(gè)產(chǎn)品部件的唯一分配，這將作為一種導(dǎo)出需求存在。此實(shí)踐的典型工作產(chǎn)品包括：需求分配表；暫時(shí)的需求分配方案；設(shè)計(jì)約束；導(dǎo)出的需求；導(dǎo)出需求之間的關(guān)系。建議：將需求分配到功能。將需求分配到產(chǎn)品部件。將設(shè)計(jì)約束分配到產(chǎn)品部件。將所分配需求之間的關(guān)系文檔化。這種關(guān)系包括依賴(lài)性，標(biāo)識(shí)出其中一個(gè)需求的更改可能影響其它需求。實(shí)踐2.3：標(biāo)識(shí)接口需求標(biāo)識(shí)功能（或?qū)ο螅┲g的接口。功能接口的預(yù)先定義，可以幫助技術(shù)解決方案過(guò)程中的備選方案的開(kāi)發(fā)。也有利于產(chǎn)品與產(chǎn)品部件的集成。因此，需要確定產(chǎn)品結(jié)構(gòu)中所標(biāo)識(shí)的產(chǎn)品或產(chǎn)品部件之間的接口需求。接口需求作為產(chǎn)品和產(chǎn)品部件集成的一部分受控約束，并且是結(jié)構(gòu)定義的有機(jī)組成部分。接口需求也是逐步細(xì)化的，初期的接口需求是比較上層得，隨著內(nèi)部部件的開(kāi)發(fā)，附加的接口被定義，并建立起更詳細(xì)的接口需求。此實(shí)踐的典型工作產(chǎn)品包括：接口需求。建議：.標(biāo)識(shí)產(chǎn)品外部和產(chǎn)品內(nèi)部的接口（例如，功能劃分或?qū)ο笾g）。在需求階段所標(biāo)識(shí)的接口一般處于頂層，隨著設(shè)計(jì)進(jìn)展會(huì)定義新的接口。在軟件架構(gòu)設(shè)計(jì)過(guò)程中會(huì)改變產(chǎn)品體系結(jié)構(gòu)，同時(shí)又會(huì)創(chuàng)建一些產(chǎn)品部件與外部部件之間新的接口。還應(yīng)標(biāo)識(shí)與產(chǎn)品有關(guān)的生存周期過(guò)程的接口，例如，預(yù)測(cè)與測(cè)試設(shè)備、支持系統(tǒng)的接口。開(kāi)發(fā)己標(biāo)識(shí)接口的需求。接口需求的定又包括其信源、信宿、激活源，以及軟件的數(shù)據(jù)特性等項(xiàng)（注意：信息傳播過(guò)程簡(jiǎn)單地描述為：信源→信道→信宿。其中，“信源”是信息的發(fā)布者，“信宿”是信息的接收者，即信息用戶(hù)）。6.3分析和確認(rèn)需求目的：分析和確認(rèn)需求，并開(kāi)發(fā)所需功能性的定義。本目標(biāo)的實(shí)踐支持目標(biāo)1“開(kāi)發(fā)客戶(hù)需求”和目標(biāo)2“開(kāi)發(fā)產(chǎn)品需求”兩方面需求的開(kāi)發(fā)。與這個(gè)目標(biāo)相關(guān)的實(shí)踐涉及關(guān)于用戶(hù)的預(yù)定環(huán)境分析和需求確認(rèn)。分析的目的是確定預(yù)定運(yùn)行環(huán)境對(duì)滿(mǎn)足利益相關(guān)方需要、期望、限制和接口的能力有什么影響。必須考慮可行性、任務(wù)需要、費(fèi)用限制、潛在市場(chǎng)規(guī)模、以及獲取策略等所有因素。在考慮這些問(wèn)題的時(shí)候還依賴(lài)于對(duì)產(chǎn)品預(yù)期的理解，必需的功能性定義也必須加以確定。要考慮所有規(guī)定的產(chǎn)品使用模式，并產(chǎn)生對(duì)實(shí)現(xiàn)關(guān)鍵功能序列的優(yōu)先級(jí)（時(shí)間）分析。應(yīng)該通過(guò)分析來(lái)確定滿(mǎn)足利益相關(guān)方需要、期望和約束的產(chǎn)品方案的備選需求，而后再將這些方案轉(zhuǎn)換為需求。與這個(gè)活動(dòng)并行，根據(jù)客戶(hù)輸入和初步產(chǎn)品方案，來(lái)確定評(píng)價(jià)產(chǎn)品有效性所用的參數(shù)。需要對(duì)需求進(jìn)行確認(rèn)，以增加最終產(chǎn)品在使用環(huán)境中按預(yù)定意圖執(zhí)行的可能性。實(shí)踐3.1：制定運(yùn)行方案和場(chǎng)景建立和維護(hù)運(yùn)行方案和相關(guān)聯(lián)的場(chǎng)景，而該運(yùn)行方案依賴(lài)于選定的設(shè)計(jì)。場(chǎng)景是用戶(hù)使用產(chǎn)品時(shí)，由事件觸發(fā)的、可能發(fā)生的活動(dòng)序列，用來(lái)使利益相關(guān)方的某些需要更明確。而產(chǎn)品的運(yùn)行方案通常既依賴(lài)于設(shè)計(jì)解決方案，也依賴(lài)于場(chǎng)景。例如．基于衛(wèi)星通信產(chǎn)品的運(yùn)行方案與基于地面線路通信產(chǎn)品的運(yùn)行方案就迥然不同。由于準(zhǔn)備初始運(yùn)行方案時(shí)一般尚未定義可供選擇的技術(shù)解決方案，所以在分析該需求時(shí)可以開(kāi)發(fā)一個(gè)草擬的解決方案提供使用場(chǎng)景。隨著解決方案決策的制定和較低層詳細(xì)需求的開(kāi)發(fā)，而對(duì)運(yùn)行方案進(jìn)行進(jìn)一步改進(jìn)。正如產(chǎn)品的設(shè)計(jì)決策可以變成產(chǎn)品部件的需求，運(yùn)行方案也可以變成產(chǎn)品部件的場(chǎng)景（需求）。演變運(yùn)行方案和場(chǎng)景使產(chǎn)品部件解決方案的選擇更容易，當(dāng)這些解決方案實(shí)現(xiàn)時(shí)，它們就能夠滿(mǎn)足產(chǎn)品預(yù)期的使用。在需求分析的時(shí)候，要用文檔記錄運(yùn)行方案和場(chǎng)景，同時(shí)記錄產(chǎn)品部件與環(huán)境、用戶(hù)、其他產(chǎn)品部件的交互方式。場(chǎng)景可以包括運(yùn)行活動(dòng)序列，要注意：這些運(yùn)行序列是客戶(hù)需求而不是運(yùn)行方案。此實(shí)踐的典型工作產(chǎn)品包括：運(yùn)行方案；產(chǎn)品安裝、運(yùn)行、維護(hù)和支持方案；處置方案；用況；時(shí)間表場(chǎng)景；新需求。建議：開(kāi)發(fā)運(yùn)行方案和場(chǎng)景，包括功能性、性能、維護(hù)、支持，合適時(shí)還包括如何處置異常。需要標(biāo)識(shí)和開(kāi)發(fā)符合在利益相關(guān)方的需要、期望和約束中所指定詳細(xì)程度的場(chǎng)景，其所建議的產(chǎn)品就在這種場(chǎng)景中運(yùn)行。定義產(chǎn)品將要運(yùn)行的環(huán)境，包括邊界和限制。評(píng)審運(yùn)行方案和場(chǎng)景，以改進(jìn)并發(fā)現(xiàn)新的需求。運(yùn)行方案和場(chǎng)景的開(kāi)發(fā)是一個(gè)迭代過(guò)程，應(yīng)定期地評(píng)審運(yùn)行方案和場(chǎng)景以確保它們與需求一致。評(píng)審可以用走查的方式。隨著產(chǎn)品和產(chǎn)品部件的選定，開(kāi)發(fā)詳細(xì)的運(yùn)行方案，在其中定義該產(chǎn)品、最終用戶(hù)和環(huán)境的交互，并且描述該運(yùn)行方案滿(mǎn)足運(yùn)行、維護(hù)、支持和處置等需要。實(shí)踐3.2：建立必需功能性的定義功能性定義也稱(chēng)為“功能分析”，描述哪些是產(chǎn)品預(yù)期要做的事情。功能性的定義可包括行動(dòng)、序列、輸入、輸出或傳達(dá)該產(chǎn)品使用方式的其它信息。功能的定義、它們的邏輯組合和它們與需求的關(guān)聯(lián)稱(chēng)為功能結(jié)構(gòu)。此實(shí)踐的典型工作產(chǎn)品包括：功能結(jié)構(gòu)；活動(dòng)圖和用例；建議：分析和量化最終用戶(hù)所需功能；分析需求以標(biāo)識(shí)邏輯的或功能的劃分（例如子功能）；按己建立的準(zhǔn)則將需求分組（例如，聚合類(lèi)似的功能性，分組內(nèi)部耦合度較高，分組之間耦合度較低），以便于需求分析，并使之更清晰；在產(chǎn)品部件開(kāi)發(fā)的整個(gè)過(guò)程，自始至終考慮關(guān)鍵功能的優(yōu)先級(jí)（時(shí)間）排序；將客戶(hù)需求分配到功能劃分、對(duì)象、人員或支持要素，以支持解決方案的整合；將功能和性能需求分配到功能和子功能。實(shí)踐3.3：分析需求分析需求以確保它們的必要性和充分性。任何某一層次的需求都是為更高一層目標(biāo)服務(wù)的，應(yīng)按照運(yùn)行方案和場(chǎng)景分析產(chǎn)品層次結(jié)構(gòu)中某一個(gè)層次的需求，以確定它們對(duì)于滿(mǎn)足更高層次的目標(biāo)是否必要而且充分。這個(gè)已分析的需求，為產(chǎn)品層次結(jié)構(gòu)中更低層次的更詳細(xì)、準(zhǔn)確的需求提供基礎(chǔ)。隨著需求被定義，必須了解這些需求與其更高層次需求和更高層次己定義功能的關(guān)系。在整個(gè)開(kāi)發(fā)期間，需要定期對(duì)這種分析進(jìn)行驗(yàn)證。此實(shí)踐的典型工作產(chǎn)品包括：需求缺陷報(bào)告；為解決缺陷而建議的需求更改；關(guān)鍵需求；技術(shù)性能測(cè)量項(xiàng)。建議：分析利益相關(guān)方的需耍、期望、約束和外部接口，以分層的方式排除矛盾，并組織成相關(guān)層次的需求集。分析需求以確定它們是否滿(mǎn)足更高層需求的目標(biāo)。分析需求以確保它們完備、可行、可實(shí)現(xiàn)和可驗(yàn)證。雖然是在設(shè)計(jì)過(guò)程決定具體解決方案的可行性，但這個(gè)建議可以使人們了解哪些需求影響可行性。標(biāo)識(shí)對(duì)成本、進(jìn)度、功能性、風(fēng)險(xiǎn)或性能有強(qiáng)烈影響的關(guān)鍵需求。標(biāo)識(shí)在開(kāi)發(fā)期間將要跟蹤的技術(shù)性能測(cè)量項(xiàng)。分析運(yùn)行方案和場(chǎng)景，以精煉客戶(hù)需要、約束和接口，并發(fā)現(xiàn)新需求。這種分析可能導(dǎo)致更詳細(xì)的運(yùn)行方案和場(chǎng)景，并支持導(dǎo)出新需求。實(shí)踐3.4分析需求以達(dá)到平衡利益相關(guān)方的需要和約束可能涉及成本、進(jìn)度、性能、功能性、可重用部件、可維護(hù)性或風(fēng)險(xiǎn)。所以，需要分析需求以平衡利益相關(guān)方的需要和約束。此實(shí)踐的典型工作產(chǎn)品包括：與需求有關(guān)的風(fēng)險(xiǎn)評(píng)估。建議：使用經(jīng)過(guò)證明的模型、仿真和原型來(lái)分析利益相關(guān)方需要和約束的平衡。這種分析的結(jié)果可用于降低產(chǎn)品成本和產(chǎn)品開(kāi)發(fā)中的風(fēng)險(xiǎn)。對(duì)需求和功能體系結(jié)構(gòu)進(jìn)行風(fēng)險(xiǎn)評(píng)估。檢查產(chǎn)品生存周期方案，以分析需求對(duì)風(fēng)險(xiǎn)的影響。實(shí)踐3.5確認(rèn)需求確認(rèn)需求以確保最終產(chǎn)品能在預(yù)期的用戶(hù)環(huán)境中正常運(yùn)行。在開(kāi)發(fā)工作的早期，與最終用戶(hù)一起進(jìn)行需求確認(rèn)，并導(dǎo)致產(chǎn)品最終確認(rèn)的信心，這個(gè)活動(dòng)應(yīng)與風(fēng)險(xiǎn)管理活動(dòng)整合，以獲得能夠指導(dǎo)開(kāi)發(fā)的需求。用于需求確認(rèn)的技術(shù)包括：分析。仿真。原型化。演示。此實(shí)踐的典型工作產(chǎn)品包括：分析方法和結(jié)果的記錄。建議：分析需求，以確定所得到的產(chǎn)品不能在其預(yù)定使用環(huán)境中合適執(zhí)行的風(fēng)險(xiǎn)。通過(guò)正開(kāi)發(fā)產(chǎn)品的演示（例如，原型、仿真和場(chǎng)景）并通過(guò)獲得利益相關(guān)方對(duì)產(chǎn)品演示的反饋意見(jiàn)來(lái)探討需求的充分性和完備性。根據(jù)需求確認(rèn)環(huán)境的關(guān)聯(lián)來(lái)對(duì)該設(shè)計(jì)進(jìn)行評(píng)估，以標(biāo)識(shí)確認(rèn)發(fā)現(xiàn)的問(wèn)題和暴露未陳述的需要和客戶(hù)需求。上述依據(jù)GJB5000A需求開(kāi)發(fā)過(guò)程的描述，使我們對(duì)于規(guī)范化的需求開(kāi)發(fā)有了一個(gè)宏觀的理解，也有了一種可以依據(jù)的信心。但是我們必須注意到，我們并不能僅僅依靠標(biāo)準(zhǔn)化的需求過(guò)程來(lái)完成需求開(kāi)發(fā)工作，我們還需要有更多的能力。我們已經(jīng)說(shuō)過(guò)，過(guò)程是一個(gè)底線，也就是說(shuō)不按照過(guò)程去做肯定是錯(cuò)的。但是我們可以做得更好，循規(guī)蹈矩的按照過(guò)程每一步都做到了，并不一定能產(chǎn)生良好的需求。在這個(gè)課程中，我們的宏觀指導(dǎo)是受這個(gè)過(guò)程控制的，但更側(cè)重于能力方面。也就是先有一個(gè)問(wèn)題，然后來(lái)探究解決這個(gè)問(wèn)題的辦法，這樣就可以使我們?cè)趯?shí)際需求開(kāi)發(fā)過(guò)程