需求生命周期管理

背景

回顾很多项目或者产品，我们发现现在的版本和当初的理解或者设想是天壤之别，这是什么原因，对于这种情况又应该如何处理呢？

业务分析的交付物是需求文档，业务分析整个过程随着对业务的逐步深入，观察视角的变化，以及干系人之间的磨合碰撞，会衍生出需求的真相，以及产生新的业务理解和需求，因此，从需求的开始到需求的结束，可以说是需求的一个成长史，也是需求的一个变化史，所以对于业务的理解可以说是不断变化的，众人的观念也是不断变化，需要逐步的达成一致，同时，要规定好在这个变化中对于各类的管理规范，因为，变化会带来设计的变更，落地时间，风险，成本等一系列的问题。

每个参与业务分析和需求管理的人员都要对业务理解变更牢记在心，并且高度重视。

任务

需求生命周期的管理核心如下

不难发现，主要就是变化和评估的管理过程。其五大任务如下

Trace Requirements: 分析和维护需求和设计，方案等，目的就是一致性检查，是否符合业务需求。

Maintain Requirements: 确保需求和设计一致性，保证需求作为基础材料被正确复用。

Prioritize Requirements: 抓大放小，控制需求的优先级别

Assess Requirements Changes: 评估需求变更，变更引发会引发系列问题，控制项目风险。

Approve Requirements: 让变更协同，让干系人认同变更，风险共担，需求知识共同协同。

五大任务对应很多输出：

简化的一下就是对于需求和设计的版本管理。

这里强调一点关于跟踪的流程，给出的例子很有意思

就是相关性的各类验证，这个东西，在做需求管理计划中一定要特别关注。

各个任务的细节没有必要展开，在这个环节，我们必须很清楚对于需求生命周期管理的重要性的澄清。

看模板

关于需求和设计文档的模板，根据项目情况，都可以找到很多，这里不用特别呈现。

想重点强调的一点是，关于需求管理计划的模板，以此为把手，来控制整个需求的生命周期管理。需要包含以下内容，作为参考

计划中，定义好大家需要遵守的规则，比如以下内容就很重要：

比如其中的重中之重：

Every high level/business requirement is associated with at least one Use Case.

· Every business requirement has one or more functional requirements that trace to it.

参照以下规则，指定项目业务分析中，关于需求生命周期的管理规范。

1.1. TRACEABILITY RULES

The string in brackets following each heading indicates the format for each unique identifier for each requirement type. A child requirement type traces back to a parent requirement type.

1.2. HIGH-LEVEL REQUIREMENTS (HR[xxx])

High level requirements are determined by the business and captured by a project BA. Every high level requirement has at least one business requirement that traces to it. The high level requirement may be traced to a market rule if it is applicable.

1.3. BUSINESS REQUIREMENTS (BR[xxx])

Every business requirement traces back to at least one high level requirement or a market rule. If a business requirement cannot be traced to a high level requirement or a market rule, this should be discussed with the project manager and business SMEs. If a high level requirement or a rule cannot be found for a business requirement, then this business requirement may be outside the agreed scope.

· Every high level/business requirement is associated with at least one Use Case.

· Every business requirement has one or more functional requirements that trace to it.

· Every business requirement has at least one test script that traces to it.

· A business requirement may have one or many change requests that trace to it.

· A business requirement may have one, many or no resolved issues that trace to it.

1.4. FUNCTIONAL REQUIREMENTS (FR[xxx])

Every functional requirement traces to one and only one business requirement. Every functional requirement has at least one test script that traces to it.

1.5. BUSINESS RULES (BL[xxx])

Every business rule imposed by the business must be associated with at least one Use Case. A business rule may trace back to a market rule.

1.6. MARKET RULES (ML[xxx])

Every market rule imposed by the industry must be associated with at least one Use Case. A market rule may trace to a business rule.