需求管理成熟度

级别一：被记录的需求（Written Requirements）

简单的写出需求。好处：

与客户有一个基本的约定。如果写的好，需求能够清晰地描述你对客户需要的理解，他们可以通过阅读需求来检查是否与他们想的一致

开发团队的每个成员通过需求可以很好的支持他们的工作。架构师和设计师可以开始考虑如何架构系统来支持客户期望，也可以支持测试人员及早开始测试案例的编写，当然更能支持开发人员理解软件要求来编写代码

需求可以让新来的成员更快速的了解系统是什么

成本：

需要有人花时间来写需求

为了保证需求的及时性，需要不断地维护需求

级别二：被组织的需求（Organized）

需求的目的是为了清晰地与用户、客户和其他涉众（例如开发团队）等人就问题的解决方案进行沟通。级别二关注需求质量、格式化、安全和存储，以及版本管理。

质量：好的需求容易让大家明白，架构师、开发人员和测试人员也都能很好的使用它，不好的需求会导致大家比较模糊、认识存在差异等问题。

格式化：需求必须以统一的方式来描述，例如序号、标题、字体、表格等，可以使得文档更容易阅读、理解和使用，文档模板可以帮助我们以统一格式来编制

访问性、安全性和版本管理：当存在很多需求时，我们会经常遇到不知道在哪里可以找到需要的需求，这时我们就需要有一个统一管理需求地方

级别三：结构化需求（Structured）

对需求进行归类，它们是功能性需求还是非功能性需求？是业务需求还是系统需求？是特性还是软件需求？客户、市场和用户需求是什么？区分这些可以帮助我们更好的理解和管理需求。之前级别都是用一些文字类语言来描述，而级别三是一种结构化需求，例如给需求添加一些属性。

级别四：可跟踪性需求（Traced）

需求本身就是层级的，由业务需求到用户需求再到系统需求；而需求又与开发和测试有所关联，通过可跟踪性管理，我们可以知道在更改一个需求时，会影响到哪些子需求以及相关的同级需求，还能够分析出影响哪些开发和测试内容。

级别五：集成化需求（Integrated）

通常我们做了很多需求，但是并没有一种集成化的方法把需求直接引入开发中，可能导致实现出来的是另一回事。集成化需求管理流程可以直接由需求导入软件设计、变更管理、测试和项目管理。团队将需求作为主要输入，如果将需求模型化，我们则可以通过模型化需求来开发应用程序，目标就是要做成能够让业务工程师来开发应用程序。