软件需求阅读笔记01

什么是软件需求？

软件需求实际就是“业务知识+问题列表+其他元素”。软件需求的三层次：业务需求、用户需求、软件需求。需求也有着三种类型：功能需求、非功能需求、设计约束。

需求相关失败因分析

1. 不完整的需求
2. 缺乏用户参与
3. 不切实际的用户期望
4. 需求变更频繁
5. 提供了不再需要的

败因	解决方案：
1 不完整的需求	采用业务导向让用户参与到完整性评价当中，在实际过程中利用树形层次结构将宏观信息与微观信息进行有效的剥离。 分析: 利用树形层次结构面向不同的层面：决策层，事务管理层，操作层，让合适的人验证相关的部分，这样可以有效的避免事不关己，高高挂起。让用户逃离无趣区和有效的启发用户的积极性，减少被专业人士排除在系统的完整性评价之外
2 缺乏用户参与
3 不切实际的用户期望	由于软件的无形和成本的不透明，需要说明软件中不能完成的需求的原因
4 需求变更频繁	对变更进行分类，统计，有针对性的改进需求过程，提高设计的弹性
5 提供不在需要的	找到用户经常使用到的功能，也即用户的需求，放弃用户很少使用的功能模块的开发 具体方案：在每个功能模块入口处，放置一个计数器

一张漫画带来的思考

1.  沟通失真
2. 客户的需求放大（图1、10）
3. 项目经理的需求控制（图1、2）
4. 分析人员的技术加工（图3）
5. 编码人员的断章取义（图4）

失败的原因	分析原因与解决方案
1、沟通失真	分析： 每个角色（如项目经理，商业顾问等）更加自己的特点和需求对信息（漫画）进行了不同程度的加工，从而导致信息内容有很大的变化
	解决方案：     1、 利用文档：防止信息在传递的过程中走样     2、Reviews （评审）：在此审阅，需求人员在此用语言复述软件需求。
2、客户需求放大	分析： 1、客户希望支付的成本尽可能少，获得的效益尽可能多。 2、解决方案的选择权较给了不熟悉技术的客户。
	解决方案1：   1、需要提升软件估算实践的有效性   2、提高产业成熟度 解决方案2：    需求捕获的过程中多问为什么
3、项目经理的需求控制	分析： 需求捕获的过程中，导致需求产生了偏差，部分从技术的角度对需求进行了控制，造成无法对需求的有效理解
	解决方案：   减少技术在需求提取过程中的不利影响
4、分析人员的技术加工	分析：     分析人员对技术能力的追求高于业务能力的追求
	解决方案:     提高自己的业务分析能力
5、编码人员的断章取义	解决方案：业务场景是需求之魂

诫语

1. 需求规格说明书应该采用业务导向的树形层次结构来组织
2. 对于需求分析员而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控力等）的沟通
3. 缓解沟通失真的最有效的方法是及时复述
4. 需求分析的本质在于业务分析而不是技术分析
5. 业务场景是需求之魂