需求管理成熟度的五个级别

1、需求管理成熟度的五个级别编辑点评：需求分析决定了项目成功的关键因素，是整个软件开发过程中的一个重要环节。作者在文中介 绍了一下需求管理成熟度的六个级别。需求管理是软件开发全生命周期重要的一个环节，我们每个人都知道它的重要性，但是 要真做做好并不简单，我也写了一本在线电子书业务分析与需求pdf来讲解需求相关内容。 对于每种技术和方法，就像以前我写过的企业架构成熟度模型(EAMM)的一样，我们都 不可能一下子就精通，而是按照一种学习的曲线进展，本篇本篇主要介绍一下需求管理成熟 度的六个级别。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设计的皖序曷是这么蜩写的 离止履向是达仓描盈的客户是这样描述需求的舞作中甫了这样笛工目就是以我的的的支持露it命祥孑黯雅麻夔的没有任何明确的需求被记录下来，他们假定知道要构建什么，希望节省需求的时间来做 开发，但这势必会给开发工作带来混乱，因为需求是一项比较复杂的工程，并不能通过假定 就可以明确软件功能，这样做很可能会导致所做的产品并不是用户所需要的。级别一：被记录的需求(Written Requirements)企业向开发商提交初步的需求开发商开发需求规约

5、企业进行需求评审/验证，并提出修改意见开发商提交修改后的需求规约企业提出进一步修改意见开发商提交再次修改后的需求规约企业认可需求规约混乱的没有需求级别上升一步的就是简单的写出需求。虽然只是简单书写需求，但是相对于没有需求级别来说已经可以感受到很多好处了:与客户有一个基本的约定。如果写的好，需求能够清晰地描述你对客户需要的理解，他们可以通过阅读需求来检查是否与他们想的一致开发团队的每个成员通过需求可以很好的支持他们的工作。架构师和设计师可以开始考虑如何架构系统来支持客户期望，也可以支持测试人员及早开始测试案例的 编写，当然更能支持开发人员理解软件要求来编写代码需求可以让新来的成员更快速的了解系统

6、是什么要得到这些好处，我们也需要付出一些成本：需要有人花时间来写需求为了保证需求的及时性，需要不断地维护需求级别二：被组织的需求(Organized)Project SponsorProject ManagementbusinessrequirementsRequirements AnalystTestingii + 7 j requirements User Representatives M expectationsand constraints ?Other Stakeholdersand complexity informationfunctfonal andnonfunctional

7、requirementsfunctional andnonfunctionalrequirements需求的目的是为了清晰地与用户、客户和其他涉众(例如开发团队)等人就问题的解决 方案进行沟通。级别二关注需求质量、格式化、安全和存储，以及版本管理。质量：好的需求容易让大家明白，架构师、开发人员和测试人员也都能很好的使用 它，不好的需求会导致大家比较模糊、认识存在差异等问题。格式化：需求必须以统一的方式来描述，例如序号、标题、字体、表格等，可以使 得文档更容易阅读、理解和使用，文档模板可以帮助我们以统一格式来编制可访问性、安全性和版本管理：当存在很多需求时，我们会经常遇到不知道在哪里 可以找到需

8、要的需求，这时我们就需要有一个统一管理需求地方级别三：结构化需求(Structured)ConstraintsBusiness RulesExternal InterfacesBusiness RequirementsQuality AHributesFunctional Requt re meritsSystem RequirementsUser Requirements级别三开始对需求进行归类，它们是功能性需求还是非功能性需求？是业务需求还是系 统需求？是特性还是软件需求？客户、市场和用户需求是什么？区分这些可以帮助我们更好 的理解和管理需求。之前级别都是用一些文字类语言来描述，而级别三是

9、一种结构化需求， 例如给需求添加一些属性。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求本身就是层级的，由业务需求到用户需求再到系统需求;而需求又与开发和测试有所关联，通过可跟踪性管理，我们可以知道在更改一个需求时，会影响到哪些子需求以及相关的同级需求，还能够分析出影响哪些开发和测试内容。级别五：集成化需求(Integrated)通常我们做了很多需求，但是并