《软件需求最佳实践》阅读笔记02
第4章 需求定义的最佳实践
需求定义，顾名思义，就是要确定项目的宏观需求。换句话说，就是定义项目的业务需求，就是明确项目的目的和范围。
需求定义的时机，应该是项目启动时要解决的问题，也就是在项目立项是完成的。
需求定义的理念与策略
- 破解混沌不清的项目目标
a) 内部寻根
b) 外部溯源，企业/组织中的项目有时不是内部发起的，二是受到了一些外部条件的影响，这时就需要从外部找信息
- 需求定义的理念，goals（目标）—problem（问题）—option（可选方案）—answer（建议方案）
问题分析的五步法
l 在问题定义上达成共识
l 理解根本原因，也就是分析问题背后的问题
l 确定相关人员和用户
l 定义解决方案的界限
l 确定加载解决方案上的约束
在问题定义上达成共识
- 问题定义的技巧，对问题进行了确定的定义，意味着成功解决了一半。
- 影响人群分析的技巧，可以对影响人群进行分析，从中可能得出一些很有意思的的推断和结论。
分析问题背后的问题，在问题被定义出来之后，接下来要做的就是分析问题背后的问题，也就是寻找问题的本源。
- 鱼骨图，也称为因果鱼骨图，他是一种直观的图形找出问题或现象的所有潜在原因的方法。
- 帕累托分析法，用于记录和分析与某一问题有关的资料，以便突出最重要的区域、投入或事项。发雷拓分析法经常揭示出这样的现象：少数失误应该为大量的质量成本负责。
- 小结，以上两种方法都是站在问题域的角度进行的分析，因此当这些分析完成之后，需求人员应该判断哪些原因是可以通过信息系统解决的，从而使得系统目标的确立更加科学，需求的范围也更易于确定。
确定相关人员和用户，当问题明确并找到了重要的原因之后，可以说系统的目标也就基本明确了。接下来的任务就是明确
- Stakeholder解析
- 用户分析，用户实际上也是stakeholder的一类，他们是直接使用系统的人群，由于他们直接作用于系统，因此需要了解他们的特点、能力，所以就将他们单列出来。
定义解决方案的界限
- 范围vs边界，范围是指系统设计那些内容，而边界则是系统与人的职责边界
- 确定边界
- 边界谈判，用户永远希望花同样的钱，获得尽可能多的功能。
- 创新边界
确定加在解决方案上的约束
|
类别 |
约束 |
说明 |
|
技术开发 |
技术约束 |
技术选择有何限制？限制在已有平台或技术上？禁止使用新技术？需要购买软件包吗 |
|
预期软硬件环境 |
建立在现有系统上？需要维护与原系统的兼容性？必须支持什么操作系统？现有的网络环境是什么 |
|
|
预期的使用环境 |
有户外作业吗？有特殊的工作环境吗？ |
|
|
项目实施 |
经济约束 |
项目的预算是多少 |
|
行政约束 |
存在许可问题？潜在的内在外部政治问题？部门间问题 |
|
|
进度及资源约束 |
进度要求？已有资源？外部劳动力可用与否？有无扩展资源 |
|
|
环境约束 |
合法吗？有特殊的安全性要求吗？需要满足其他标准限制吗？ |
戒语：
l 清晰的项目目标和范围定义，能够引导需求工作顺利进行。
l 对混沌不清的目标，可以通过内部寻根或外部溯源来破解
l 对问题进行了正确的定义，意味着成功解决了一半。而在问题定义时应该善于使用转换和本源两个技巧。
l 需求定义阶段要善于将未知解问题转换成已知问题。
l 在确定某问题的解决方案时，一定要思考是否会引发新问题。
l 直接修改错误，不要用其他方案来弥补错误。
l 鱼骨图是为解决问题找到了耙子，帕累托图则边上了环数。
