title: 敏捷软件需求管理
date: 2017-10-23 10:29:39

tags: 需求管理

严格的来讲，这个标题的说法并不是很严肃，这篇文章的目的不是建立一个敏捷软件需求管理的流程，而是去探索一种需求管理的实践，解决现在工作中遇到的困惑和困难。为了将问题解释的更清楚，我需要先从流程定义说起。

流程定义

?
上面这个图是一个典型的IPD（集成产品开发）流程图，从大的视角来看，这就是一个典型的瀑布模型，需要有前一个阶段的成果作为后一阶段的输入，后一阶段的工作才能开展，这样当然没有错，不过有时候会显得低效和无法满足项目的需求。
同样，我也拿出我们研发层的各阶段的定义，进而进一步探讨。
?

从图和表中点后可以看到，需求分析集中在项目的前期的阶段，理所当然，需求就要作为后续工作的输入，因此需求很重要，这都知道，所以在图中也设置了需求的技术评审，但需求的技术评审并不能保证全部的质量。

总结来说，需求很重要，但需求又大多数集中于前端部分，不好管控，怎么保证需求高质量的分析，发现和实现都是比较困难的事情。

需求层次

产品开发规程中，对需求层次的定义是：

class="language-flow">op=>operation: 用户需求
op1=>operation: 产品需求
op2=>operation: 软件（子系统）需求

op(right)->op1(right)->op2

1. 用户需求是顶层需求，直接反应用户的需要，要能反映出临床用户的需要，作为临床确认的依据；
2. 产品需求是对用户需求的细化，除了要考虑用户的临床需要，临床场景，还需要考虑公司的业务目标，产品的竞争等因素，主要用于定义产品是什么样子；
3. 子系统需求是对产品需求的细化，考虑技术因素，用什么样的技术等来满足产品需求，以达到产品需求的定义。

软件需求为什么重要

我们公司大部分产品都是软件密集型产品。我们先来看看软件密集型产品的定义。

软件密集型定义：

所谓的系统就是客户要的东西，软件通常只是客户要的东西中其中的一部分，而不是全部，除了软件还有其他东西，比如客户要一个数控机床，除了软件之外还有机械部分，还有硬件部分。 软件密集型系统，应该是指系统中软件是主要部分，在开发软件的成本占系统成本的大部分。

产品的类型

从定义来看，毫无疑问，拿监护仪来作为分析对象的话，我们的产品肯定是软件密集型产品无疑。因此无论是在产品的使用和产品的开发上，软件都占了很重要的一部分。

软件开发的工作量的评估

软件行业中各工种所占比重或权重，有几种估算方法。

常规估计法：

软件各个生命阶段时间大致分布：
计划阶段占2%~3%；
需求分析占10%~25%;
软件设计占20%~25%;
编码占15%~20%；
测试和调试占30%~40%

差别估计法：

差别估计法：总比重是53
计划和需求：6
产品设计：10
详细设计：12
编码单元设计：16
集成和系统测试：9

IBM估算模型：

IBM估算模型：（总比重10）
软件计划：1
需求分析：1.5
设计：3.0
编码：1.0
测试：3.5

虽然这是对软件行业中需求的评估，但我们开发的系统是软件密集型系统，所以有一定的代表性。典型的项目中，需求的工作量需要占到10%~25%，就算我们采信IBM的估算模型，需求分析工作量也需要占到15%，但目前我们是不够的，当然，也不能说我们现在的投入不够15%我们就不去把需求做好，而是想办法做到尽可能的好。

可以看出，一个正经的软件产品开发流程，理性的去评估软件需求分析的工作量是很重要的，不仅影响到需求分析的产出，也影响到软件设计的输入。

典型软件生命周期模型简介

传统的瀑布模型讲究的是每一个阶段性的工作成果，并把上一阶段的成果作为下一阶段的输入，这种模型的典型问题就是上一阶段的延迟和延期会导致下一阶段的延迟和延期，环环相扣，导致项目最终延期。

近年比较流行的迭代模型，摒弃了传统的需求分析，设计，编码，测试的流程，而是将整个生命周期变成若干个冲刺（Sprint）阶段，而每一个阶段都是由以上若干或者全部传统的流程组成，在每一个阶段中，都会包含下面四个阶段：初始阶段，细化阶段，构建阶段，交付阶段。
1. 在初始阶段中，确认本次冲刺的范围，边界，系统选择的架构，计划，以及所需要的资源等信息。
2. 在细化阶段中，对问题进行建域，创建开发案例，创建模板以及准备工具等。
3. 在构建阶段的主要任务就是完成构建的开发并且进行测试，将完成的构建集成为产品，并且测试所有的功能（CI）。
4. 在交付阶段，主要是完成本次冲刺，将软件产品交付给相关的干系人。

五种生命周期模型请参考 似水流年的博客

定义我们自己的流程

流程框架和概述

现阶段来说，影响我们软件需求交付质量的是把一件庞大的工作就是作为一件庞大的工作来做，而且要求一次性交付。这种一锤子买卖是影响到需求分析和设计人员交付的质量的，同时也影响需求评审人员对于需求的理解。要让一个评审人员在几个小时或几天内消化一个需要花一年以上或者几年的产品，有一定的困难，这种情况下，很难保证后续有人会改变主意，进而导致发生已经确定的需求的变更，应该说是在所难免的。

那么我们定义自己的流程，需要吸收迭代模型把大事“化小”（划小）的思维，将一个规模特别大的事情，划分成若干件规模可控的事情来进行。也就是把软件需求的工作打散，放到开发阶段去做去完成，这样来保证项目最后产品的交付时间。当然，打散并不意味这我们前期就不需要做需求分析了，我们先看看流程图。

st=>start: 开始
e=>end: 结束
op=>operation: 1. 产品需求定义
op1=>operation: 2. 软件需求基线定义
op2=>operation: 2.1 软件需求基线评审
cond=>condition: 2.2 基线范围完整？
op3=>operation: 2.3 提交TR1阶段软件需求
op4=>operation: 3. 启动需求细化工作
cond1=>condition: 3.1 软件需求是否模块化
op5=>operation: 3.2 安排轮次开发内的需求内容
op6=>operation: 3.3 模块级需求细化
op7=>operation: 3.4 模块级需求评审
op8=>operation: 4. 需求实现
op9=>operation: 5. 需求Demo和验收
op10=>operation: 5.1 输出需求状态清单
op11=>operation: 6. 输出字符串清单并评审

st->op
op->op1
op1->op2(right)->cond(no,left)->op1
cond(yes,right)->op3
op3->op4->cond1(no)->op4
cond1(yes)->op5
op5->op6
op6->op7
op7->op8
op8->op9
op9->op10
op10->op11
op11->e

流程操作指引

根据产品开发规程的定义，各种角色一定要在各个阶段完成各阶段的内容和输出，应该理解，这样的定义从框架性的流程上来讲是没有问题的，是合理的，否则就不好把控了，同时这也符合医疗仪器开发本身流程的严肃性，满足FDA guidance中提出的Define，Document，Do的3D思维。

产品需求定义

产品需求的输出要在项目前期进行输出，应该是毫无疑问的，产品需求决定这项目的范围，因此，让项目团队明白自己要开发一个什么样的产品，大的方向是什么，这是需求工程师的职责。尤其是我们开发的大多数产品都不仅仅只涉及到软件，还涉及到硬件、结构、工业设计、算法、附件等领域，因此让大家能够有一个工作的基础很重要。

产品需求定义中，需要定义出产品的定义、产品的配置、产品能够提供的服务、产品的功能性需求、产品的重要非功能性需求、产品的安全及环境要求、产品的整机外观等要求、产品需要使用到的附件要求、产品升级、保养维护等要求以及产品需要满足的法规和政策的要求，详细内容可以参考《XXX产品需求模板》的定义。

软件需求基线的定义

基线(Baseline)，基线是 软件文档或 源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布.

软件需求基线是一个基础稳定版本的需求，我们这里提出的基线定义并不完完全全是跟严格意义的基线的定义一样，实际上我们这里定义的基线是软件项目范围的基线。对于这个版本的软件需求，要求是覆盖产品需求中应该分解到软件需求的所有内容，可以粗，不可漏，可以指导软件系统进行概要和系统设计，能够满足TR1阶段的要求。
在表达方式上，可以将整体按照模块划分为多个文档（推荐），而这个基线文档的多个章节，对多个模块的主要功能做抽象，可以用用例图或功能树或列表的表达方式，可以参考我另外一篇文章需求建模和表达的技术。

软件需求基线评审

在评审上，这篇需求应该是一个高层次的定义，应组织以下评审人员应该涵盖产品经理、产品线经理、需求技术经理、软件技术经理、项目经理、软件系统工程师、开发代表、测试代表、市场代表进行会议评审，在这个评审上，大家对软件系统的范围达成一致。在责任上，除了需求工程师的主体责任外，需求技术经理、软件技术经理及系统工程师应该对需求所表达的内容负责重要的审核责任，识别出技术风险和需求镀金。

提交TR阶段软件需求

同时，该文档应该进行PLM的线上评审，并按照《评审审查表》的定义选取相应的角色进行线上的评审，并完成TR1的软件需求的受控和归档。

启动模块需求细化工作

这实际上是第三阶段工作的总称，模块需求细化的前提是划分好了模块，我们在前一阶段需求基线化的时候，我们是需要做好这件事情的。当然，这件事情应由需求工程师来主导，软件系统工程师参与，立足于对系统功能的分解来完成，而不是系统的设计的模块化，因此这里讲的是需求模块化。如果说这个阶段发现需求模块化的程度是不够的，我们需要再进行这个工作，否则，后续的工作开展会比较困难。

安排轮次开发的需求内容

在每一轮需求的实现，也就是敏捷模型里边说的冲刺的时候，所开发的需求的规模都应该是可控和可开发的。也就说，在每一轮开发中，需求应该被定义到可开发的程度，并被开发人员理解，能够被转化为设计语言，建议的执行方式是：

op0=>operation: 需求定义（上一轮次计划本轮次开发的需求）
op1=>operation: 召开轮次启动会（明确本轮次开发的内容，确定下一轮次开发内容）
op2=>operation: 需求分解和解读

op0->op1->op2

这个阶段的工作实际上是整个软件开发的关键，在这里，这个团队明确了本轮次的开发任务和冲刺目标，所以这个阶段对软件项目经理的要求是很高的，对各个岗位的工程师要求是团队要对完成目标达成共识。职责如下:
1. 需求工程师：保证本轮次要开发的需求已经得到细化，并提交PLM同行技术评审，在轮次开的的第一周组织软件工程师进行需求的解读和分解，将需求传达下去；
2. 软件工程师：在轮次开发的第一周参与需求的解读和分解，积极理解需求。设想需求设计和需求实现的方案，如果存在需求问题，及时发现；
3. 测试工程师：在轮次开发的第一周参与需求的解读和分解，积极理解需求。设想测试的方案和测试用例的编写，如果存在需求问题，及时发现；
4. 系统工程师：理解需求，考虑系统设计方案
5. 软件项目经理：确保轮次的第一周的开发资源参与需求解读；
6. 软件技术经理：审核软件需求，从技术的角度评估需求的可实现性等问题；
7. 需求技术经理：审核软件需求，审核需求的完整性和合理性。

形式方面的建议，建议主要的需求工程师、软件工程师、测试工程师闭关进行需求的解读和分解，确保需求得到恰当的理解。

需求实现

该阶段的任务由软件项目经理主导，该阶段中，需求工程师要保持与开发团队沟通，及时跟进落实情况，及时发现问题和进行修正。在该阶段中，需求工程师要进行下一阶段所需开发的需求进行细化，及时排除可能出现的障碍。

需求Demo和验收

需求开发完成后，及时得到需求的确认和反馈，对于开发团队来说，是非常重要的，在这一阶段，也就是开发工作完成后，软件项目经理应该组织需求工程师、产品经理、整机项目经理、产品线经理、市场代表、需求技术经理、软件技术经理机型需求Demo，演示开发完成情况。这一阶段同时需求工程师要完成需求完整状态的检查，输出该轮次的需求状态表。

多语言字符串清单并评审

在完成Demo后，软件项目经理需要将本轮次新增的字符串导出为指定格式的多语言字符串表交付需求工程师，需求工程师完成中文解释的添加，并提交PLM进行同行技术评审，字符串处理方法请参考《监护多语言字符串管理规范》。

总结

应当理解，把需求能够落实到产品中，也是一项非常重要的工作，所以需求工程师在这里要主动积极的把需求传达下去，因此在需求传达的路径上，需求工程师要负主要责任。
同样的，开发团队应该理解，我们一致的目标是把需求实现，达到产品的要求，以实现临床应用和企业的目标，开发团队在这里应该摒弃专业组的界限，为共同的目标服务。

软件需求是一个沟通的过程，我们尽量前期阐述明确，减少后期的沟通工作和变更。