几点前辈的项目的看法。

请各位将Xx项目需求调研过程中的好的经验、建议反馈上来。

陈工：

不足：在业务扩展方面思考不够仔细。

两个存在矛盾的地方：

1、不想扩展用户的思路，怕引出更多复杂的需求。

2、又怕没有分析透彻用户的需求，导致无法考虑到的路径。

遵循的原则：？如何才能把握到合适的尺度

用户有很多种，所以对不同的用户要采取不同的方式和方法，感觉没有绝对的方法，还是要靠经验。

这里朱工经验挺多，学习到不少。特别是分析后说服用户不去做这个需求的引导技巧。

我以往没有这种思路，我的思路是尽可能的去帮助用户设计和实现需求。而在如何说服和引导用户

不做某个需求方面存在不足。这个比较深的体会到这一点。

个人认为好的做法：对把握不准的需求，可以先记录用户的需求，再与开发设计讨论复杂度和实现方式后，再同用户沟通具体实现。

朱工：

先列几个个人看法，希望抛砖引玉：

1.关于调研准备工作：充分准备可以提高效率，获得正确的调研结果，比如：可以在调研前花上几天时间，将该项目相关资料、前期整理的业务流程、系统范围、该企业现有的前期获取的各种制度等仔细阅读和了解，并整理问题，也可以向对方索取部分资料，消化后，整理出初步的业务流程、业务逻辑等，再过去和用户集中调研时，问题就很清晰，可以得到很好的沟通效果。我们这次这方面前面大概一周准备，但资料取的不够，以后需要加强，确定项目组调研成员后，就要有计划展开积极的准备工作。

2.调研结果的确认：调研结果必须有记录，对讨论得到的流程、业务规则都要做好记录，并及时和用户确认。此处最好用描述单方式，对单个模块确认，最后结果以需求规格书做最后确认。 描述单确认时，可以使用加批注的方式，记录一些未定问题，挨个解决后再去掉批注。

3.对于接口部分需求，一般都涉及技术处理和业务流程交互，此时最好是由技术和业务分析人员搭档处理。

待补充...

朱工：

昨天会议讨论的问题及处理方式，大家可以继续补充：

1.两个存在矛盾的地方：1、不想扩展用户的思路，怕引出更多复杂的需求。2、又怕没有分析透彻用户的

需求，导致无法考虑到的路径。遵循的原则，才能把握到合适的尺度？
对把握不准的需求，可以先记录用户的需求，再与开发设计讨论复杂度和实现方式后，形成最佳方案建议

给用户；以后可以以产品方式推部分建议方案。

2。如何做好调研准备工作？
充分的调研准备可以提高效率，获得正确的调研结果，比如：可以在调研前花上几天时间，将该项目相关

资料、前期整理的业务流程、系统范围、该企业现有的前期获取的各种制度等仔细阅读和了解，并整理问

题，也可以向对方索取部分资料，消化后，整理出初步的业务流程、业务逻辑等，再过去和用户集中调研

时，问题就很清晰，可以得到很好的沟通效果。我们这次这方面前面大概一周准备，但资料取的不够，以

后需要加强，确定项目组调研成员后，就要有计划展开积极的准备工作。

3.如何做好调研结果的确认工作？
调研结果必须有记录，对讨论得到的流程、业务规则都要做好记录，并及时和用户确认。处最好用描述单

方式，对单个模块确认，最后结果以需求规格书做最后确认。 描述单确认时，可以使用加批注的方式，

记录一些未定问题，挨个解决后再去掉批注。

4.如何做好相关系统接口调研？
对于接口部分需求，一般都涉及技术处理和业务流程交互，此时最好是由技术和业务分析人员搭档处理。

5.如何做好需求变更记录？
每个描述单进行需求确认时，需要通过修订形式，记录变更内容，并加入VSS中，以便跟踪变更记录。

6.调研前是否需要对调研用户进行培训？
建议首次集中调研前准备调研问卷，调研前安排时间，和用户就调研问卷做一个沟通，由用户进行问卷的

确认和资料提供。
不过此问卷一般也需要企业的积累，将自身产品的主要流程、规则等要点都归纳整理出来才可以。

7.调研计划如何制定和如何分工？
可能情况下，可以独立完成项目调研工作；
合作完成的大项目，需要根据业务情况熟悉程度进行分工；调研过程中，尽量每次结束都安排内部一个讨

论，整理结果、分析问题及预备方案；不确定问题，需要安排时间与技术人员沟通确认。

8.用例粒度如何把握？
建议抓重点，将复杂业务流程进行细化，其中重点用例，需要细化到细节的流程、细节规则、UI、字段属

性等。一句话：重点流程重点处理，一般的流程中用例，只需要写出代表性的即可。
一个大项目，有六到八十个用例就挺多了。

9.非功能性需求谁提出来？
XX项目，XXIT自身有此一套非功能性需求提出机制；
别的项目不一定每个企业都有这样的能力，我们可以借鉴XX的内容，摘取合理部分提供给对方。