.軟件需求的思想與方法論 61.1高質(zhì)量需求工程的意義 61.2需求工程與需求開發(fā)方法論 61.2.1需求工程模型 61.2.2需求開發(fā)的基本概念 81.2.3軟件質(zhì)量與需求開發(fā) 101.2.4正確的需求開發(fā)方法論 122.優(yōu)秀需求規(guī)格說明具有的特性 142.1需求具有清晰的層次 142.2良好的需求描述的特征 152.3良好需求規(guī)格說明的特征 162.4對軟件工程方法的重新思考 172.4.1瀑布方式的問題 173需求的滾動式完善模式 193.1需求在動態(tài)中的滾動完善 193.2更點(diǎn)放在哪里更合適？ 203.3現(xiàn)代軟件過程域之間的關(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)建過程 255.1.1創(chuàng)建系統(tǒng)級的需求規(guī)格說明 265.1.2進(jìn)行子系統(tǒng)劃分 265.1.3開發(fā)子系統(tǒng)需求規(guī)格說明 265.1.4對子系統(tǒng)進(jìn)行劃分 265.2自上而下與自下而上 275.2.1自上而下 275.2.2自下而上 275.2.3關(guān)注相互間的關(guān)系 275.3需求開發(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編寫便于閱讀的需求 296.需求開發(fā)過程定義 296.1開發(fā)客戶需求 306.2開發(fā)產(chǎn)品需求 326.3分析和確認(rèn)需求 357.利用需求模式重構(gòu)問題 397.1對功能分解的再討論 397.2利用模式解決劃分中的困難 407.3需求模式與需求復(fù)用 417.4通過業(yè)務(wù)事件發(fā)現(xiàn)模式 437.5通過抽象形成模式 457.5.1需求抽象的一般方法 457.5.2特定領(lǐng)域的模式 467.5.3跨領(lǐng)域的模式 477.5.4復(fù)用的趨勢 47

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

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