没有遗漏管理.docVIP

没有遗漏管理 　　在软件开发过程中如果只有一条真理的话，那一定是:需求的变化是永恒的，需求不可能是完备的。需求的变更不一定是坏事，也有可能是商业机会，对市场敏感的人可以从变化中发现机会。 　　 　　这是一个强调流程的时代，许多论述软件开发流程、业务建模合重建的书籍和文献纷纷出版，评测和验证有效的软件开发流程的标准逐步普及和推广。社会和企业的发展对软件的依赖越来越深，进一步推动了软件开发流程的发展，系统质量得到提高。但是既然这样，那么今天频频发生的软件项目失败的案例如何解释？ 　　1995年开始，美国对全国范围内的8000个软件项目进行跟踪调查，结果表明，有1/3的项目没能完成，而在完成的2/3的项目中，又有1/2的项目没有成功实施。他们仔细分析失败的原因后发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。 　　 　　从Rational的标准开发流程图(图1)中看出，需求分析在启动阶段占有很大比例。 　　软件需求既是整个软件开发项目的最关键的一个输入，又是软件项目最难把握的问题，好的需求管理是项目成功的第一要素。 　　 　　复杂的需求 　　 　　与传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点: 　　1、需求不总是显而易见的，而且来自各个方面 　　在大多数的软件系统中，最终用户可能都不清楚自己的需求是什么。如果用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到筋疲力尽了。 　　2、需求并不总是容易用文字明白无误地表达 　　因为用户根本不去读那上百页的需求文档。不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。 　　3、如果不加控制、需求的数量就会无法控制 　　需求如何做到没有遗漏？如何准确划定系统的范围？这是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，必须建立一个基线。 　　4、需求可能对时间很敏感 　　为了确保需求的正确性，完备性，项目经理往往坚持在需求阶段花费大量的时间，但是客户与公司的高层领导却不这么认为，看到项目迟迟没有实际可运行的软件担心不已！这些人会发疯似的逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变需求折腾得筋疲力尽，也希望尽快结束此阶段。 　　5、存在不同类别的需求，其详细程度各不相同 　　需求到底要描述得多细，才算可以结束？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家（项目干系人）认为描述清楚了，就可以进入下一阶段了。 　　6、需求会发生变更 　　在软件开发过程中如果只有一条真理的话，那一定是:需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现机会。 　　 　　需求管理流程图 　　 　　美国国家航天局（NASA）的软件开发过程中的概念，软件需求过程的标准是:清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪的、可修改的等。 　　需求管理包括需求从获取、分析、处理和验证的过程。 　　1、需求分析 　　问题分析可以通过了解问题及干系人的最初需要，提供高层解决方案来实现。它是为找出“隐藏在问题之后的问题”而进行的推理和分析。问题分析期间，将对“什么是面临实际问题”和“谁是项目干系人”达成一致。 　　可以通过建立项目视图的方式进行分析，如表1所示。 　　 　　2、理解需求 　　需求来自各个方面，比如来自客户、合作伙伴、最终用户或是某领域的专家。你需要掌握如何准确判断需求来源于哪方面、如何接近这些来源并从中获取信息。 　　控制重点是需求范围（也就是项目视图中的内容），而不是功能的细节。其中要特别关注非功能软件需求，主要包括: 　　◆关注产品的质量需求 　　◆关注产品的环境需求 　　◆关注产品的设计约束 　　◆关注产品的开发策略 　　◆关注产品的问题信息 　　◆关注产品的沿用信息 　　这些问题同样也是软件项目的需求，或者是往往容易被忽略的需求的外延，控制需求范围（外延）也是项目管理者的责任。 　　3、确立需求 　　确立系统的功能需求指的是解释需求，并整理为对要构建系统的意义明确的说明。在系统定义的初期要确定以下内容:需求构成、文档格式、语言形