软件需求分析阅读报告一

　　　　　　　　　　　　　　　　　　　　《软件需求最佳实践》第一章 需求实践现状分析

　　通过阅读第一章，作者通过列举了Standish Group的研究，分析到了如下的十大成功保证和十大败因。这个表格的数据对我将来做项目有很大的帮助，通过这个表格我明白了今后我做项目的时候需要注意的地方

成功的十大因素有及其权重：

1. 用户的参与                                              15.9%
2. 执行层的支持                                           13.9%
3. 清晰地需求描述                                        13.0%
4. 合适的规划                                               9.6%
5. 现实的客户期望                                        8.2%
6. 较小的里程碑                                            7.7%
7. 有才能的员工                                            7.2%
8. 主权                                                         5.3%
9. 清晰的愿景和目标                                     2.9%
10. 努力的工作和稳定的员工                           2.4%
11. 其他                                                         13.9%

失败因素及其权重：

1.  不完善的需求                                          13.1

2.  缺乏用户参与                                          12.4

3.  资源不足                                                 10.6%

4.  不切实际的用户期望                                9.9%

5.  缺乏执行层的支持                                   9.3%

6.  需求变更频繁                                          8.7%

7.  规划不足                                                 8.1%

8.  提供了不再需要的                                   7.5%

9.  缺乏IT管理                                              6.2%

10. 技术能力缺乏                                         4.3%

11. 其他                                                       9.9%

　　由于近期正在学习软件需求分析，所以比较关注需求分析方面的成功因素和失败因素。在这十大成功保证中有三个是与需求分析相关的因素（用户的参与、清晰的需求描述、现实的客户期望）总权重高达37.1%。而十大败因中与需求分析直接相关的高达五个（不完善的需求、缺乏用户参与、不切实际的用户期望、需求变更频繁、提供了不再需要的）累计权重高达51.6%。由此可见，需求分析问题对项目的影响有多大。

下面进行相关败因的分析

1. 不完整的需求

　　对于需求的完整性，应该是用户代表比开发人员更具合适对需求的完整性进行分析。然而我们看开发人员的《需求规格说明书》的时候，却发现里边的内容全都是一些专业术语，这样做显然会将技术功底并不怎么深厚的代表排除在有效读者群之外。要想让比开发人员更适合评价需求完整性的用户代表更好地参与完整性评价，就必须采用“业务导向”的组织结构，而不是用一大堆的专业术语取描述业务需求。另外，在验证需求完整性的时候，现在的公司经常会出现需求验证变成需求确定的情况，需求验证本来是需求质量关，其目标时暴露出更多的需求错误，要的不是确认签字而是指出其中的错误，而确认代表了职责，因此用户代表们经常会在写下这责的基础上履行形式上的义务。