软件需求最佳实践(2)

需求验证是一种质量活动，在这里要注意验证和确认的区别，一般验证活动主要方式就是Reivew，而Reivew根据正式程度又包括了审查，多人复审，单人复审等多种方式。需求验证的五大要素包括：

• 思想：找到尽可能多的错误
• 方法：从非正式的开始，并逐渐形成文化
• 语言：从评价者转化为建议者，强调协作者进来减少用你哪里错了，而多用我建议如何
• 人员：平等而且合适，减少不相关人员的参与
• 内容：不是全部而是最合适

需求管理的三大内容是基线，变更和状态跟踪。其实基线和变更都属于配置管理的需求跟踪。需求跟踪又包括了对需求-》设计-》测试整个需求链的跟踪，同时也包括了对需求实现状态的跟踪。在这个过程中基线是迭代开发的基础，但是迭代开发往往又是最难去规划和打基线的。在这里的原因是我们是以整个文档作为基线的对象，而不是以文档中的条目化需求作为基线的对象。另外对于变更管理其核心作用是通过变更管理减少变更对目标的影响。

迭代开发和分阶段开发

• 迭代开发是以时间(迭代周期)来划分，而分阶段开发是以任务完成来划分。
• 迭代周期一般比较短而分阶段开发的每个阶段会比较长。
• 迭代不响应变更，需要变更会转入下次迭代；分阶段开发响应变更导致混乱和计划失效。

在RUP的三要素中最后一个就是增量迭代，但是要注意到迭代是手段，增量是目标。而且每一个迭代其本身就是一个微型的瀑布。迭代使目标更加容易分解和明确。

估算是在项目管理中做项目计划的基础，不能因为估算不准确而不去做估算和计划，坚持估算和检查估算历史数据的收集就不断的纠正估算的经验数据，而使估算准确性得到提高。同时，估算的本质是计算单元和复杂因子，首先要选择好相应的估算方法，如在需求早期往往并不适合用功能点法进行估算；其次就是要识别计算单元，然后再确定具体的复杂度。

• 估算是手段，估算需要在执行过程中多次调整。
• 估算应该是基于权重的，比如我们用的根据规模到工作量的方法，比如要考虑人员效率的影响。
• 在估算后可以根据关键用例来确定第一个迭代周期的长度。

需求变更是无法避免的，但是我们要尽量减少和控制变更带来的影响。需求变更是需求管理的一个核心内容，有了需求变更自然会涉及到需求基线和配置管理的内容。例如我们可以讲对于已经基线的配置项要修改都必须要走变更流程等。对于需求变更主要有以下重点：

• 是控制变更而不是避免变更。
• 控制变更的目的是减少变更的影响，客户要意识到变更是有成本的。
• 需求团队的贡献在于尽早标识变更。
• 需要建立统一的平台来捕获，管理和控制变更。

目标的寻找方法可以用GPOA方法：GOAL-Problem-Option-Answer。在确定项目目标和范围的时候，我们往往容易提出类似要建立一个先进的信息系统一类的不清晰的目标。而如何破解不清晰的目标？可以从两个方面来考虑:内部溯源(项目的原始发起人，沟通)；外部寻因(受到外部刺激)

RUP中的问题分析五步法:

• 在问题的定义上达成共识，问题定义清楚往往问题就解决了一半。
• 要多为问题背后的问题，探求问题的本质和根源。(如鱼骨图+帕累托图)。
• 确定Stakeholders和用户，高层，中层和操作层各自的价值和关注点是什么？
• 定义解决方案系统的范围-》黑盒思维-》主题域划分-》主题域内的流程和请求
• 确定解决方案的约束

对于访谈这块的案例和实战都很好，暂时不展开了，感觉还是有很多原来在访谈中没有注意的内容，特别是开门点和访谈策略两个方面。具体综述下高层访谈主要关注点:
开门点：易于回答而且激发其兴趣

• 访谈策略：Review验证最后结果，问题不要太大，连续，挖掘不够有时候只听到一个问题
• 问题类型和挖掘：上下文，问题暴露后的分解，发展机会，约束
• 其它策略：还应该找哪些人做进一步的交流

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15027599/viewspace-563290/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15027599/viewspace-563290/