需求方面的小调查

1. 需求是否经常发生变更
   a. 是
   b. 否

2. 需求变更方式所占比率
   a. 增加需求文档未定义的新功能
   b. 需求文档已定义， 但细节不足， 随着开发的深入发现需要补充大量细节， 以至工作量大幅超出原有估计
   c. 需求文档已定义， 但需要大幅修改实现方式， 以至不得不重新设计实现方案
   d. 其他

3. 需求变更发生原因所占比率
   a. 需求文档中的范围及约束定义不明确
   b. 需求文档对业务实现方式描述严重不足， 偏离客户实际期望
   c. 客户缺乏对软件系统的认识，无法从软件系统的角度清晰表述实际需求
   d. 系统投入使用后，随着客户对业务软件认识的加深，从操作角度出发提出更好的实现方式
   e. 其他

4. 应对需求变更的有效手段
   a. 对客户有强势的影响力，可以将需求压下去或重新签订变更合同
   b. 增加人力投入
   c. 加班
   d. 改善系统架构，尽可能削减需求变更引发的额外成本
   e. 其他

5. 减少需求变更的有效手段
   a. 有资深行业专家，对业务的理解比客户本身更深刻
   b. 采用开发原型及早收集尽可能多的客户需求
   c. 现场开发、现场客户
   d. 其他

6. 如果我们将用户认可并接受的最终代码视为最完整的需求文档（涵盖客户显式、隐式、业务、交互、安全及性能等方面的一切需求）
   那么需求文档里面所定义的显式需求占完整需求的百分之几？


就本人的经验而言，对于大部分项目来说，2b, 2c, 3c, 3d的情况最普遍，最有效的手段是4.d

1.b，
2.a，
3.e，需求文档对业务实现方式描述不足或有误， 偏离客户实际期望，易用性考察不足
4.e，按照需求变更就是了，基本上对构架没有影响
5.abc
6.Unknow

确认1是b吗？确定需求是否变更是以合同签订时确认的SRS来作参考的，只要没有写入SRS的一律归入需求变更范围。

是b啦。
签订合同时确实有个功能列表，但现在已经被所有的人“遗忘”
关键还是这个客户代理很重要，他出色的完成了任务。
返工的功能极少，易用性稍微差点，这也是领域专家容易犯的错误。

我觉得问题里面还是隐含了很多前提的，和我们的操作模式不太一致