需求文档是否需要用户签字

在软件开发中，需求分析和需求管理一直被认为是软件开发成功与否的关键。 
  
在CMMI中，需求管理是CMMI2级的过程域，需求开发是CMMI3级的过程域。 
  
在瀑布型生命周期当中，安排了需求分析阶段，一般也安排需求分析里程碑评审。 
  
瀑布型生命周期存在了很多年，曾经几度写入到软件开发的国际标准、国家标准当中。 
  
  
由于瀑布型生命周期如瀑布般顺流而下，在设计阶段开始后，根据需求文档的结果来开 
展工作，要求需求文档的结果比较清晰、稳定。所以对于需求确认，往往地采用签字的 
方式，希望各方慎重、全面、充分的确定需求。 
  
签字确认需求文档这个做法几乎成为一个标准过程，在大大小小的软件开发中出现。  
  
那么软件工程发展了这么多年之后，发现经签字确认的需求仍然有大量的变更，不禁要 
问：需求文档需要签字确认吗？ 
  
在软件没有开发的时候，分析需求需要各类想象，对于目前一般规模的商业软件（全部 
12人月工作量以上）而言，而无论做得如何仔细，就算访问所有的干系人，也不能把所 
有环节全部考虑到。而在软件开发的过程中，时间在推移，随着时间的推移，用户的需 
求会不断的发掘、修正；开发人员对软件需求的认知也是随时间推移而渐渐的清晰。而 
随着软件的开发部署，经过初步的使用，变更的要求、升级的要求就自然的产生了。 
  
所以需求在变化，或者说需求在演化，这是客观规律。 
  
在需求的演化之中，签字确认有用吗？ 当然有用，用处是在这个签字的一瞬间保留了需 
求的一张快照，这张快照对于履行合同是有用的，在短期内指导后续的工作，但是除此 
之外并没有太大的用处。因为这演化中的需求会渐渐地与这张快照不一样。 
  
传统的瀑布型生命周期中就需要设计需求变更管理流程，每一次的变更都需要多方的签 
字确认。为了维护一致性，还需要追溯需求文档、设计文档、代码、测试用例的一致性 
。需求变更成为不少项目风险的最大来源，成为大量项目不成功的最大原因。 
  
签字的另一个问题是签字很麻烦，对于甲方而言，签字意味着责任，往往要拖到最后， 
认为各方面都没有问题后才能签字。而需求分析或变更都是后续工作的前提，签字的拖 
期也将推迟后续工作的开展。 
  
因此签字确认需求文档的弊端有： 
  
1，  签字不能真正的确认需求。 
  
2，  签字过程慢。 
  
所以，值得回过头来反思：签字确认的需求有用吗？有没有更好的方式？ 
  
如果需求文档写在软件运行之后，那么以软件运行的截屏为主体的需求文档肯定比软件 
运行之前想象之中的需求文档更加精准，而且书写文档所费工作量大大减少，而且这个 
需求文档经过简单的转换，就可以成为用户文档。 
  
怎么可能在没有需求文档的情况下，把软件开发出来？ 
  
完全有可能。回想下当年读书的教研组，回想下自己的编程经历，总有至少那么几次， 
在种种的原因下，在没有需求文档的情况下，软件已经编写好了。也许那个软件规模小 
些，质量不是太好，但确实是没有需求文档的情况下把它编了出来。 
  
所以没有需求文档是可以把软件开发出来的。 
  
为了保证这样的软件达到要求，显然需要另外的手段。笔者认为最要紧的手段是快速地 
将运行的软件给用户试用或观看，收集用户的反馈，根据用户反馈再修改。这是敏捷软 
件开发所倡导的“短迭代”和“可运行”+“反馈”。 
  
不签字的需求文档有如下的好处： 
  
1，  快！记录关键的需求，不必求全，细节可以在软件运行后再来确认和补充。 
  
2，  容易与用户沟通，达成口头认可，就可以开展后续工作。 
  
显然这里有这样的一个要求： 
  
需求的提供方需要不断澄清和讲述需求是什么样，要不断回答“这样行不行？”，要提 
出“不是这样的，应当…”。 
  
如果开始时不留详细文字，号称要敏捷，而在过程中开发方与需求提供方又没有频繁的 
沟通，那么谁来保证开发的东西是不是用户想要的？ 
  
   
  
以下的最近发生的实例。 
  
AB公司试图管理自主产品的许可证发布，保障软件不被盗版，并进行统计，要利用已经 
有的AI系统扩充这部分功能。新功能主要分成2块：1，产品管理，2，许可证发布 
  
在产品管理里主要维护产品和产品版本的信息。许可证发布中，根据已经有的产品版本 
来申请许可证，产品开发部门审批后，IM系统能够自动生成许可证。 
  
为了开发这部分功能，在2010年，项目组首先书写了长达86页的《产品管理模块功能需 
求规格书》，历经了2次会议评审后，进行开发。 
  
在2010年12月开发了第1版后，发现仍然有不足，还需要添加其它功能，也有一些修改。 
  
  
对于2011年开始的修改，项目组在产品经理的建议下，不打算书写或修改需求功能规格 
书，采用敏捷开发的部分方法来处理。 
  
下面是2011年1月17日到2月22日，产品经理陆续写给项目组的“原始需求”： 
  
ID      标题    创建时间 
  
205453  经过审批的许可证，许可证申请者可以直接打印盖有章的书面许可证书  2011-2 
-22 14:28 
  
204436  每个许可证有唯一的编号  2011-2-12 8:45 
  
204348  合理化建议能够提供导入功能。    2011-2-10 15:42 
  
203959  IM系统能够让普通宝信员工签发最长半年的许可证    2011-1-26 9:58 
  
203958  自主产品加入内部定价    2011-1-26 9:36 
  
203957  自主产品的开发部门分管领导应当设置      2011-1-26 9:23 
  
203956  自主产品有不再应用的状态        2011-1-26 9:21 
  
203908  自主产品版本含许可证模式信息，申请许可证时不可以改变许可证模式  2011-1 
-25 10:38 
  
203455  许可证发布时同时记录最终用户联系人（包括email)和相应合同总金额和产品销 
售金额（如果有的话）    2011-1-17 15:35 
  
项目组在2月21日那个周开始了针对以上8个原始需求的迭代，计划3月31日做完上线。 
  
在这个期间，产品经理每隔2~3天就会到开发现场观看开发情况，提出意见和建议，有时 
一天之内会去多次。 
  
也利用即时通讯工具与开发人员交流，总共留下了217条对话记录。 
  
项目组搭建了一个测试环境，产品经理从3-14开始进行试用。 
  
在过程中，通过email，产品经理发出的变更有： 
  
3-14 许可证流程中取消“提出部门领导预审许可证申请”步骤 
  
3-15 许可证审批流程可以email+短信提醒 
  
3-15 对于产品开发部门审批这个环节，能够设置2人或多人可以审批。 
  
3-15自主产品管理页面中 “许可证申请审批人” 改名为“产品负责人”。在许可证申 
请审批时，产品负责人可以有代理人。 
  
3-21内部使用许可证的最长期限是1年 
  
3-29希望产品检索页面能提供中文全文的模糊检索或提供根据部门检索。 
  
3-29增加产品开发负责人的字段及相应的联系信息，原“产品负责人”应为“审批人” 
。审批人有A角，原代理人改为审批人B角。 
  
在过程中，开发人员记录到的来自于产品经理的意见有： 
  
1       生成导出纸质许可证 
  
2       直接生成许可证（临时许可证 ） 
  
3       纸质导出  过期时间 如果永久有效 显示为永久 
  
4       最终用户联系人 （可能是非宝钢的人员） 
  
5       许可证统计（依赖关系也统计出来） 
  
6       在许可证申请表上面 ，版本改为 不必填。最终用户联系人 联系方式必填 
  
7       许可证审批是 相应字段必须必填（提出人不必填，审批人必填） 
  
8       许可证审批人可以修改 不控制只读 
  
9       许可证页面基本信息页面布局调整（项目名称或事由 与 编号 的位置 对调等） 
  
10      许可证用途  内部使用（有效期控制1年） 
  
11      自主产品和自主产品第一个版本 增加快速入口（并控制相应权限） 
  
12      自主产品添加产品代理人字段，产品名录 应必选 
  
13      许可证用途  临时使用 （直接签发许可证 有效期3个月） 
  
14      许可证 需要添加 许可证数量 这个字段（用于统计，缺省是1）  
  
15      产品英文简称，产品代码不允许重名 
  
16      提交了 自主产品登记后，到达了任务中心 页面  ，这个不好。回到“自主品登记” 
页面为好 
  
17      许可证模式中 需要新加一种 “eCop许可证” 
  
18      impp50 添加负责人 代理人 联系方式 
  
19      控制产品负责人和产品代理人 权限 
  
20      email和短信提醒 
  
21      进行中的自主产品登记列表（菜单） 
  
22      电子许可证（依赖关系的产品名称不正确） 
  
23      许可证申请表 页面中的 运行所在的操作系统 中 添加多一个选项：其它（电子许可 
证 里为OTHER） 
  
24      被依赖签发的产品能在产品跟踪管理中查询出来，查询条件增加“许可证用途” 
  
4月1日，在没有需求说明规格书，当然不需要签名的情况下，这个功能模块上线，不过 
尚有几处修改没完成，总体达到了实用。 
  
以上文字就是在2011-4-1上线版本留下的最主要文字。 
  
如果仍然要求有需求规格说明书，4-1以后再来写需求规格说明书，那是很方便的事情， 
而且各方签字会很爽快。