需求管理成熟度的五個級別

1、需求管理成熟度的五個級別編輯點評：需求分析決定了項目成功的關(guān)鍵因素，是整個軟件開發(fā)過程中的一個重要環(huán)節(jié)。作者在文中介 紹了一下需求管理成熟度的六個級別。需求管理是軟件開發(fā)全生命周期重要的一個環(huán)節(jié)，我們每個人都知道它的重要性，但是 要真做做好并不簡單，我也寫了一本在線電子書業(yè)務(wù)分析與需求pdf來講解需求相關(guān)內(nèi)容。 對于每種技術(shù)和方法，就像以前我寫過的企業(yè)架構(gòu)成熟度模型(EAMM)的一樣，我們都 不可能一下子就精通，而是按照一種學(xué)習(xí)的曲線進展，本篇本篇主要介紹一下需求管理成熟 度的六個級別。How Rtionl RequisitePro Supports RMM LevelsRational Re

2、quisitePro FeatureMaturity LevelDynamic integration between Microsoft Word and requirements databaseOne Written Two OrganizedSecure central requirements repositoryTwo OrganizedUser securityTwo OrganizedRequirements revision historyTwo OrganizedWeb interfaceTwo OrganizedRequirements project templates

3、Three StructuredUser-defined requirement types, requirements attributes, and document typesThree StructuredRequirements attributes and query capabilityThree StructuredRequirements traceability and coverage analysisFour TracedImpact of requirement changeFour TracedIntegrations with other software dev

4、elopment toolsFive Integrated級別0：沒有需求(no requirements)聃目授理掛路理盥由方折加是這Z設(shè)計的皖序曷是這么蜩寫的 離止履向是達倉描盈的客戶是這樣描述需求的舞作中甫了這樣笛工目就是以我的的的支持露it命祥孑黯雅麻夔的沒有任何明確的需求被記錄下來，他們假定知道要構(gòu)建什么，希望節(jié)省需求的時間來做 開發(fā)，但這勢必會給開發(fā)工作帶來混亂，因為需求是一項比較復(fù)雜的工程，并不能通過假定 就可以明確軟件功能，這樣做很可能會導(dǎo)致所做的產(chǎn)品并不是用戶所需要的。級別一：被記錄的需求(Written Requirements)企業(yè)向開發(fā)商提交初步的需求開發(fā)商開發(fā)需求規(guī)約

5、企業(yè)進行需求評審/驗證，并提出修改意見開發(fā)商提交修改后的需求規(guī)約企業(yè)提出進一步修改意見開發(fā)商提交再次修改后的需求規(guī)約企業(yè)認(rèn)可需求規(guī)約混亂的沒有需求級別上升一步的就是簡單的寫出需求。雖然只是簡單書寫需求，但是相對于沒有需求級別來說已經(jīng)可以感受到很多好處了:與客戶有一個基本的約定。如果寫的好，需求能夠清晰地描述你對客戶需要的理解，他們可以通過閱讀需求來檢查是否與他們想的一致開發(fā)團隊的每個成員通過需求可以很好的支持他們的工作。架構(gòu)師和設(shè)計師可以開始考慮如何架構(gòu)系統(tǒng)來支持客戶期望，也可以支持測試人員及早開始測試案例的 編寫，當(dāng)然更能支持開發(fā)人員理解軟件要求來編寫代碼需求可以讓新來的成員更快速的了解系統(tǒng)

6、是什么要得到這些好處，我們也需要付出一些成本：需要有人花時間來寫需求為了保證需求的及時性，需要不斷地維護需求級別二：被組織的需求(Organized)Project SponsorProject ManagementbusinessrequirementsRequirements AnalystTestingii + 7 j requirements User Representatives M expectationsand constraints ?Other Stakeholdersand complexity informationfunctfonal andnonfunctional

7、requirementsfunctional andnonfunctionalrequirements需求的目的是為了清晰地與用戶、客戶和其他涉眾(例如開發(fā)團隊)等人就問題的解決 方案進行溝通。級別二關(guān)注需求質(zhì)量、格式化、安全和存儲，以及版本管理。質(zhì)量：好的需求容易讓大家明白，架構(gòu)師、開發(fā)人員和測試人員也都能很好的使用 它，不好的需求會導(dǎo)致大家比較模糊、認(rèn)識存在差異等問題。格式化：需求必須以統(tǒng)一的方式來描述，例如序號、標(biāo)題、字體、表格等，可以使 得文檔更容易閱讀、理解和使用，文檔模板可以幫助我們以統(tǒng)一格式來編制可訪問性、安全性和版本管理：當(dāng)存在很多需求時，我們會經(jīng)常遇到不知道在哪里 可以找到需

8、要的需求，這時我們就需要有一個統(tǒng)一管理需求地方級別三：結(jié)構(gòu)化需求(Structured)ConstraintsBusiness RulesExternal InterfacesBusiness RequirementsQuality AHributesFunctional Requt re meritsSystem RequirementsUser Requirements級別三開始對需求進行歸類，它們是功能性需求還是非功能性需求？是業(yè)務(wù)需求還是系 統(tǒng)需求？是特性還是軟件需求？客戶、市場和用戶需求是什么？區(qū)分這些可以幫助我們更好 的理解和管理需求。之前級別都是用一些文字類語言來描述，而級別三是

9、一種結(jié)構(gòu)化需求， 例如給需求添加一些屬性。FunctionalNonfuncfionalVision and Scope Document -Use-Case Document :Software Requirements Specification級別四：可跟蹤性需求（Traced）需DetailedDetailedProductProduct ocijnnieritationLiocumentationi2. Trace requirements into design3. Trace requirements into test procedures4. Trace requiremen

10、ts into user documental2. Trace requirements into design3. Trace requirements into test procedures1B Trace Mpdevel requirementsinto detailed requiiremeotsRequirememts(Features)Requlreinems| Use Case s |Scftware DesignDeSCrlpfilCiniObiSet hflod回舊RetjuiremeotsRequlrememsSoftware： DesigmDeSCrlptOnOEyect Mod 包舊1. Trace top-level requirementsinto detailed requirementsI race requirerrdocumentaticiin求本身就是層級的，由業(yè)務(wù)需求到用戶需求再到系統(tǒng)需求;而需求又與開發(fā)和測試有所關(guān)聯(lián)，通過可跟蹤性管理，我們可以知道在更改一個需求時，會影響到哪些子需求以及相關(guān)的同級需求，還能夠分析出影響哪些開發(fā)和測試內(nèi)容。級別五：集成化需求(Integrated)通常我們做了很多需求，但是并