《软件需求最佳实践》阅读笔记02

第4章 需求定义的最佳实践

需求定义，顾名思义，就是要确定项目的宏观需求。换句话说，就是定义项目的业务需求，就是明确项目的目的和范围。

需求定义的时机，应该是项目启动时要解决的问题，也就是在项目立项是完成的。

需求定义的理念与策略

1. 破解混沌不清的项目目标

a)        内部寻根

b)        外部溯源，企业/组织中的项目有时不是内部发起的，二是受到了一些外部条件的影响，这时就需要从外部找信息

1. 需求定义的理念，goals（目标）—problem（问题）—option（可选方案）—answer（建议方案）

问题分析的五步法

l  在问题定义上达成共识

l  理解根本原因，也就是分析问题背后的问题

l  确定相关人员和用户

l  定义解决方案的界限

l  确定加载解决方案上的约束

在问题定义上达成共识

1. 问题定义的技巧，对问题进行了确定的定义，意味着成功解决了一半。
2. 影响人群分析的技巧，可以对影响人群进行分析，从中可能得出一些很有意思的的推断和结论。

分析问题背后的问题，在问题被定义出来之后，接下来要做的就是分析问题背后的问题，也就是寻找问题的本源。

1. 鱼骨图，也称为因果鱼骨图，他是一种直观的图形找出问题或现象的所有潜在原因的方法。
2. 帕累托分析法，用于记录和分析与某一问题有关的资料，以便突出最重要的区域、投入或事项。发雷拓分析法经常揭示出这样的现象：少数失误应该为大量的质量成本负责。
3. 小结，以上两种方法都是站在问题域的角度进行的分析，因此当这些分析完成之后，需求人员应该判断哪些原因是可以通过信息系统解决的，从而使得系统目标的确立更加科学，需求的范围也更易于确定。

确定相关人员和用户，当问题明确并找到了重要的原因之后，可以说系统的目标也就基本明确了。接下来的任务就是明确

1. Stakeholder解析
2. 用户分析，用户实际上也是stakeholder的一类，他们是直接使用系统的人群，由于他们直接作用于系统，因此需要了解他们的特点、能力，所以就将他们单列出来。

定义解决方案的界限

1. 范围vs边界，范围是指系统设计那些内容，而边界则是系统与人的职责边界
2. 确定边界
3. 边界谈判，用户永远希望花同样的钱，获得尽可能多的功能。
4. 创新边界

 

 

确定加在解决方案上的约束

类别	约束	说明
技术开发	技术约束	技术选择有何限制？限制在已有平台或技术上？禁止使用新技术？需要购买软件包吗
	预期软硬件环境	建立在现有系统上？需要维护与原系统的兼容性？必须支持什么操作系统？现有的网络环境是什么
	预期的使用环境	有户外作业吗？有特殊的工作环境吗？
项目实施	经济约束	项目的预算是多少
	行政约束	存在许可问题？潜在的内在外部政治问题？部门间问题
	进度及资源约束	进度要求？已有资源？外部劳动力可用与否？有无扩展资源
	环境约束	合法吗？有特殊的安全性要求吗？需要满足其他标准限制吗？

 

戒语：

l  清晰的项目目标和范围定义，能够引导需求工作顺利进行。

l  对混沌不清的目标，可以通过内部寻根或外部溯源来破解

l  对问题进行了正确的定义，意味着成功解决了一半。而在问题定义时应该善于使用转换和本源两个技巧。

l  需求定义阶段要善于将未知解问题转换成已知问题。

l  在确定某问题的解决方案时，一定要思考是否会引发新问题。

l  直接修改错误，不要用其他方案来弥补错误。

l  鱼骨图是为解决问题找到了耙子，帕累托图则边上了环数。

转载于:https://www.cnblogs.com/maosonglin/p/8304169.html