案例：需求问题的解决方案

讨论时间：2012-09-14下午13:00至14:45

参与人员：EPG3人，需求开发部门负责人一名，项目经理一名

 

1现象与问题：

（1）开发人员反映需求没有说清楚， 写的人认为需求很清楚了。

（2）是写清楚，还是说清楚？以谁的意见为主？如果说清楚呢，语言没有证据，不如文字规范。将来发生了需求变更时有争议。

（3）需求人员没有讲解约定俗成的，默认的东西，开发人员没有概念。

（4）需求人员抱怨开发人员写的软件的易用性差。

2解答：

（1）需求和开发人员的接口关系是否定义清楚了？目前有CRS，SRS两个文档，有格式的标准，有无内容的标准？要求细到功能点，但是大家理解不一致。功能点细到什么程度，没有要求，只是评审专家来把握。

       把开发人员和需求人员叫到一起进行讨论，找出历史的10份CRS,SRS来，大家一起来点评，什么地方好，什么地方差，差的是否可以避免，是否可以固化下来检查单，好的地方是否可以发扬？

（2）是否可以建立标准的业务术语或者叫领域模型，对于新人进行培训。对最常遇到的术语进行规范。

（3）在wiki系统中针对每个需求的讨论记录，都记录下来，都通过文字进行需求的沟通。

（4）文字+语言交流，语言交流如何做？

                 A 需求交底：需求人员给设计人员，开发人员，测试人员；

                       可能存在多次交底；

                       可能持续2周；

                 B 逆向培训：开发人员给需求人员，需求人员点评理解的正确性；

                 C 结对设计：开发人员和测试人员守着一台电脑，互相讨论对需求的理解，设计人员在EXCEL中写设计要点，测试人员写测试要点。

（5）原型法的使用

                界面原型谁来做？

                界面原型是否确认过？

                需求人员掌握原型开发工具AXURE，进行原型的开发。

                不能补写原型！要在开发之前完成原型。

（6）多次需求确认法：

                第1次：文字确认。访谈客户后，把访谈记录让客户确认：是否正确，是否完备？

                第2次：低保真的原型确认，访谈完成后快速构造出界面原型，让客户确认；

                第3次：高保真的原型确认，安排开发计划先开发界面，后开发逻辑，高保真的原型再让客户来确认；

                第n次：每完成一个功能就给客户演示软件，让客户确认软件。

                在多次确认时，客户会有需求变更，要提变更，不要到最后才变更！

（7）在需求讨论、需求评审、需求确认时，测试人员是否参与了？

                有时在讨论需求时，也讨论了设计方案，测试人员认为听不懂，不愿意参与。

                讨论的时候主持人需要注意不要跑题。

                参与的目的就是验证需求的可测试性。需求是否可测？

                针对每个需求是否编写了验收标准？测试驱动的开发，测试设计前移！

（8）能否进行功能点估算？

                如果能够按照功能点估算方法估算出功能点，则需求就足够详细了。

（9）在敏捷中是如何解决的？不照搬但是可以借鉴敏捷的一些思想进来。

                A 用户故事：4段论=用户角色+功能+目的+验收标准

                B PO讲解需求，补充需求。

                C 实时验收需求

                D 需求的变更反应在下一个迭代中。

                E 在迭代结束时，调整后续的开发顺序。

（10）对于非功能性需求。

               实现定义：

               A 各个非功能性需求的缺省定义，是最低值；

               B 常见非功能性需求的设计解决方案；

               C 常见非功能性需求的测试解决方案

              各个具体项目在此基础上进行裁剪。

（11）对于需求的投入要平衡质量与进度。

              是否有足够的人力投入到需求开发？

              是否有足够的时间投入到需求开发？

              如果投入不充分，可以选择哪些实践？

              上述的实践是否可以定义一个最小集？