讨论时间：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）对于需求的投入要平衡质量与进度。
是否有足够的人力投入到需求开发？
是否有足够的时间投入到需求开发？
如果投入不充分，可以选择哪些实践？
上述的实践是否可以定义一个最小集？
