过去十多年来，我一直听到人们抱怨一个问题：需求变化大。的确，需求变化大是个老、大、难问题。如何解决这个信息化/系统集成/软件工程的头号难题，值得我们认真深入地进行研讨。当今的软件工程已经超成熟了。解决需求变化大、变化多的难题，其实已经有很多成熟的技术和管理手段可以综合运用。从开发商的需求技术技能角度，应该尽可能地提高需求分析的精度和深度，比客户看得更多、更远。

20 年前诞生于复杂电信软件开发领域的 Use Case（用例）方法是解决需求变化大难题的一项重要技术。简单地说，用例就是利用自然语言用写计算机程序（包括前态、后态、基本流、异常等）的方式来写软件需求，它的最大一个优点就是能够用结构化的文本模板系统、规范地帮助我们挖掘出许多采用其它方法很难发现的隐蔽、复杂需求（扩展流、扩展条件等），从而可以有效地规避需求风险。推广和传播基于用例的统一需求分析和管理技术也是我过去十年来做的一件主要工作。

待续 ...

解决 IT/软件项目需求变化大的难题，不知大家有什么好建议和好办法？

[ 本帖最后由 张恂 于 2009-8-31 20:31 编辑 ]

学习。

尽可能正确的需求分析是基础，
1.通过需求评审对需求大方向进行确定，对相关责任人签责任书及需求确认书。
2.商务上需保证，对重大需求变更，需增加相应的合同金额，可按具体需求变更进行人月等估算，以便统计工作量。
这个只能对项目利润率有个基本的保证，但项目期限 等，题目就太大了。。。。

自己的一些理解，跟大家学习了

我觉得不是需求变化大的问题

根本是需求没有弄清楚

[ 本帖最后由 pmp_sean_huang 于 2009-9-1 10:29 编辑 ]

QUOTE:

---

原帖由 pmp_sean_huang 于 2009-9-1 10:21 发表
我觉得不是需求变化大的问题

根本是需求没有弄清楚

---

部分同意，呵呵
我所经手的项目，导致需求变化大的首要原因就是需求获取不全面，分析不到位。
个人认为，要保证如下方面，才能尽可能的了解用户需求：
1、识别项目干系人
很多时候，由于没能识别出来干系人，导致系统到了试运行阶段时，遇到强烈的阻力，干系人以我并没有确认你的需求结果而拒绝使用。
2、用例图和原型法结合来确认需求是否符合用户的真实意愿
我有个项目就是没有使用原型法，只有文字和用例图来描述，结果发现其实双方理解上有很大偏差，但是当时却没能体现出来。
3、干系人共同评审，而不是单独确认
有时候，干系人的需求是相冲突的，如果不是在一起共同评审，总会有一方不能接受你的方案。

之所以部分同意是因为用户的变更很大程度是想简化自己的操作，而不是原方案影响业务的日常运行。这个很令人烦恼，用户总是提出各种各样的要求来方便自己的操作，恨不能只按一个键就完成所有操作，所有的变更要求都沦为一种工具了。

[ 本帖最后由 susan_huangyong 于 2009-9-2 11:07 编辑 ]

敏捷方式開發，擁抱變化。

QUOTE:

---

原帖由 XJ6875 于 2009-9-1 09:05 发表

尽可能正确的需求分析是基础，

1.通过需求评审对需求大方向进行确定，对相关责任人签责任书及需求确认书。

2.商务上需保证，对重大需求变更，需增加相应的合同金额，可按具体需求变更进行人月等估算，以便统计工作量。

这个只能对项目利润率有个基本的保证，但项目期限 等，题目就太大了。。。。

自己的一些理解，跟大家学习了

---

不错！这几点都管用。当然，最好和迭代结合起来，避免瀑布式。

QUOTE:

---

原帖由 susan_huangyong 于 2009-9-1 16:52 发表

我所经手的项目，导致需求变化大的首要原因就是需求获取不全面，分析不到位。

个人认为，要保证如下方面，才能尽可能的了解用户需求：

1、识别项目干系人

很多时候，由于没能识别出来干系人，导致系统到了试运行阶段时，遇到强烈的阻力，干系人以我并没有确认你的需求结果而拒绝使用。

2、用例图和原型法结合来确认需求是否符合用户的真实意愿

我有个项目就是没有使用原型法，只有文字和用例图来描述，结果发现其实双方理解上有很大偏差，但是当时却没能体现出来。

---

Very good! 都是非常实在的教训和经验啊

如果采用敏捷迭代开发，1-3 的问题就全部解决了。

AID 相当于非抛弃的原型法。

预先全面的分析很重要，用户的及时验证和反馈也很重要。

QUOTE:

---

3、干系人共同评审，而不是单独确认

有时候，干系人的需求是相冲突的，如果不是在一起共同评审，总会有一方不能接受你的方案

---

即 review meeting

QUOTE:

---

之所以部分同意是因为用户的变更很大程度是想简化自己的操作，而不是原方案影响业务的日常运行。这个很令人烦恼，用户总是提出各种各样的要求来方便自己的操作，恨不能只按一个键就完成所有操作，所有的变更要求都沦为一种工具了。

---

这点要求很正当，你们 IT 部门好像没有理由拒绝。

[ 本帖最后由 张恂 于 2009-9-2 20:23 编辑 ]

QUOTE:

---

原帖由 pmp_sean_huang 于 2009-9-1 10:21 发表

我觉得不是需求变化大的问题

根本是需求没有弄清楚

---

QUOTE:

---

原帖由 张恂 于 2009-9-2 20:06 发表

这点要求很正当，你们 IT 部门好像没有理由拒绝。

---

张老师，这点我有不同意见哦

对于产品化的软件，用户一再的提出变更，可能只是为了比另一个报表多了个字段的报表，这完全可以将数据导出来然后自己再加工啊，用户只为了图自己的方便，不但不利于产品日后的升级，而且是一个无底洞，永远没有停止的时候。

对于定制开发的软件，如果仅为简化操作，对业务流程没有任何优化或效率的提高的话，我一般是拒绝的，呵呵