《软件需求最佳实验》阅读计划一

1. CHAOS Report调查结果显示:软件项目成功因素的前三名:用户的参与;执行层的支持和清晰的需求描述。失败的前三名是:不完整的需求,缺乏用户参与和资源不足。

2.采用数据说话是技术人员走向成熟的一个要点。

3.想让用户代表能够更好地参与到完整性评价中来,就必须采用“业务导向”的组织结构,而是不让用户将一大堆技术动作翻译到自己的业务场景中去。

4. 需求验证本是需求质量关,其目标是暴露更多的错误,也就是说我们要的不是签字,而是指出潜在的问题与错误!

5.需求规格说明书应该采用业务导向的属性层次结构来组织。树形层次结构应该面向不同的层面:决策者(高层),事务管理层(中层),操作层(基层)将需求分成不同的部分,让合适的人验证适当的部分,然后再汇总。

6. 对于需求分析员而言,真正的专业主义是基于业务利益(解决问题,创造机会,提高管控力等)的沟通。

7.不切实际的用户期望的原因在于软件的无形和成本的不透明。

8.到底谁才是知道用户最需要什么功能的人呢?产品经理,开发人员还是用户代表?其实最了解用户需求的是软件本身。看访问量!

9.优先级的划分经常是拍脑袋的产物。

10.解决沟通失真的方案:1 文档;2 Re-view. (缓解沟通失真的最有效的方法是及时复述.)

11.项目经理的需求控制:有些需求“表面上”是控制下去了,但却在后面以“需求变更”的形式全回来了。

12. 需求分析的本质在于业务分析,而非技术分析。方法:多问why.

13.有种低效的管理叫“打地鼠”,有种低质的医术叫“头痛医头,脚痛医脚”,有种低级的观点是“软件项目失败的关键在于项目管理技能不足。”

14.以“定性”的方法来描述非功能需求,实际上就是一种无效信息传递。

才读完了第一章,就有很多感触和共鸣。以上更多摘抄的是结论,而就本书的写作方法而言,既有归纳也有演绎,很给力。

posted @ 2015-11-13 09:10  twenty丶two  阅读(165)  评论(0编辑  收藏  举报