《软件需求最佳事件》-阅读感二

首先介绍了需求相关败因总结简要分析。
第一是需求不完整 。那么什么样的需求是完整的呢，显然用户代表要比开发人员更适合对完整性进行评价，，但是软甲需求规格说明书中去充斥着数据字典管理、报表子系统
新增客户之类的以技术唱主角儿字眼与结构，显然将用户排除在有效读者群之外，书中介绍了可以用“业务向导”的组织结构，还有就是利用树形层次结构将宏观信息与微观信息进行有效的剥离，树形层次结构应该面向不同的层面：决策者，事务管理层，操作层，需求验证的本是需求质量关，其目标是暴露出更多的错误，也就是我们要的不是签字而是指出潜在的问题与错误，将需求分成不同的部分，让合适的人去验证适当的部分，然后再汇总起来才是解决之道。
第二是缺乏用户参与。用户一般都不能有效的参与到项目中来有这个几个原因：事不关己高高挂起，主动参与意识与获得的利益成正比，逃离无趣区，被你赶走。
第三是不切实际的用户期望，用户总是很天真的提出了大量的需求，有些事技术上根本无法实现的，有些死推落的预算的费用与时间预算内无法实现的，问题根源就是软件的无形和成本的不透明性。
第四十需求变得更加频繁，这是比较广泛的问题，对于到底哪种变更时比较多的，国内对变更的分类，统计的做法是不普遍的，另一方面用户并没有意识到变更对软件项目的负面影响
第五是提供了不再需要的案例和场景。
老师已经给我们展示过那副迷途漫画，究其最后做出的东西大相径庭的原因一方面是沟通失真