下决心系统学习下GJB5000、CMMI中关于需求开发与管理方面的要求，与敏捷模式对比起来看。
刚看了GJB5000中的内容，有点小兴奋。其内容没有一处提“敏捷”，但实质上吸收了敏捷思想。
一、在目的中强调：
“需求开发活动不强调顺序与线性关系，允许交叉、迭代和反复，需求管理活动则贯穿产品或项目的整个生命周期。”——这里已经接受了需求是不断迭代反复的过程，在后面的具体实践中还会提到。
“需求开发与管理的对象是所有需求，包括顾客需求、产品需求和产品部件需求，其中产品和产品部件在概念上是递归的，既适用于系统于子系统，也适用于软件与软件部件。”——我们有时候在纠结概念上的准确定义，这里的“递归”帮我们解套了。
二、具体实践
1、获取和开发顾客需求
在实施要点中，明确提出了：
“用户很少能确切地知道需要什么，原型或迭代开发过程能更有效地帮助获悉产品需求”。——这一点已经成了普遍的共识。
“将需求条目化，更有利于需求追踪和变更管理”。——条目化是后面的追踪与变更管理的前提，具体如何落到实处成为了关键。原来的word文档中的章节条目，不能算是真的条目化。
2、获得对需求的理解和承诺
“组织或项目应明确合适的需求提供者”。“明确需求的正式来源和认可的需求提供者，避免需求来源过多”——在实践中这一条极容易被忽略掉。这一条又极其重要。多个翻车项目，都有没有执行这一条的教训。
“需求变更可能导致项目计划、活动和工作产品发生变化，也须征得项目参与者的承诺”——需求的变更管理，如何落到实处是件极其困难的事情。
3、开发运行方案和场景
用户故事方法就是以此为重点。用户需求一定要描述出用户的业务场景。
此活动的内容相比用户故事，应是更宏观一些的视角，可以理解为史诗级、特性级故事。应用用户故事、故事地图的形式，配合以流程图、原型界面等手段，描述清楚业务需求的具体应用场景。
4、开发产品和产品部件需求
这部分是我们理解的从用户需求到软件需求的过程。开放功能需求，性能需求，接口需求，其它非功能需求等。
“这里应用递归开发。产品需求、产品部件需求在每个较低层递归地开发，与技术解决方案形成迭代。需求开发是逐级分解、逐步求精的过程”。——用户故事的精炼过程。与技术解决方案如何形成迭代？在这里，针对具体的低层级的功能，在用户故事方法中，仍然会用到“开发运行方案和场景”，通过“验收标准”明确运行方案和场景。
一个大故事（需求）要逐步拆解为小故事（小需求），到合适的粒度才停止拆解。何为合适？我理解为，能够描述清楚具体的验收标准，即为合适——团队对如何对该需求进行验收，能够列出几条来。当然，有可能现在觉得清晰了，具体动手开发的时候又觉得有含糊的地方，那就再拆分一层。
拆分的时机：此处没有明确，但既然是不断递归，与技术方案迭代，而且在”1 获取和开发顾客需求“中也说了”原型或迭代开发过程能更有效地帮助获悉产品需求“，那就还是按迭代来比较实际，近期要干的拆解细致，远期的不妨放一放，在要真的进入开发之前再投入精力做细致分析。
这一步是将第三个环节”开发运行方案和场景“里的内容，一步步的具体落实到每一个软件功能点上。对于非功能需求，通过这种分解模式，一部分会转化为功能需求（用户故事），一部分会转化为技术要求（技术故事）。例如可维护性设计，可能会被转化为一个用户故事：”作为运维人员，可以远程部署更新系统的升级程序包，以节约系统升级人工成本“。如可靠性需求，可能会被转化为一个用户故事，”作为一个单据录入人员，希望系统具备数据临时自动存储与恢复功能，以避免在系统异常崩溃时造成未主动存盘的数据丢失“。
通过需求条目化、需求递归开发的实践，每一个提出的需求最终都不能含糊其辞，必然会被分解落实到具体的技术解决方案上去。
通过迭代开发的模式，将需求分析的整体过程拉长，对需求分析人员及用户的进度压力都减轻了。
5、分析并确认需求
实施要点：
“在开发工作的早期，与最终用户一起执行需求确认”
“持续地进行需求确认，可以确保相关方的需求得到正确地定义”——每个迭代的需求梳理、每个迭代验收评审、每日站会时与用户代表的沟通，都时持续地进行需求确认的体现。
“在需求开发早期，与软件任务方、系统人员、开发方、测试人员等各相关方一起，以集同审查的形式对需求进行确认和技术交底”——用户故事共创工作坊是一种实践方式，让开发人员、测试人员编写用户故事中的验收标准，团队进行同行审查也是一种实践方式。
6、建立并维护需求双向可追溯性
“建立并维护需求双向可追溯性，保证计划、活动和工作产品与需求一致”——该项实践在传统的开发过程中是一个大难题。但在敏捷实践中，却是被化解到每天的具体执行活动中去了，在无需强调的情况下就解决了，只是没有一个“显性”的跟踪矩阵。团队的每项工作，都是从放在故事地图或者看板上的“故事”(需求)栏开始的，没有需求输入，就没有后续的设计、开发、测试等一系列活动。技术团队自己想做的技术类任务，也必须在需求处放置一个技术类故事，“放置”这个动作，触发技术团队与PO的沟通，需要PO同意添加这项技术类任务。而传统模式中容易含糊的非功能需求，在此种模式下，也无法含糊其辞：只要列出一个需要处理的需求，团队就不得不对它进行讨论和处理，必须分解出可以执行的任务来，并且在看板上必须完成闭环处理。这就是看板、每日站会、DoD（Definition of Done，完成的定义）系列实践综合在一起的魔力。
就以下两个问题咨询了5000审核的老师：
——Q1：我们一定要一个需求双向跟踪矩阵吗？
——A1：她认为只要能够做到双向的追溯就可以，并不一定要一个形式上的双向跟踪矩阵。
——Q2：用户需求与软件需求一定要区分开吗？在我们的系统中，统一叫”用户故事“，只是一个层层分解的关系
——A2：这个还是应该区分以下的。用户需求是设计输入，软件需求是需求分析活动的输出。这两者还是不同的。（在之前调研的某家企业，他们将史诗当作了用户需求，其下面的故事就是软件需求。在我们这里可以将史诗理解为大的软件模块）