需求管理

需求捕获（RE）被ABC过程委员会确定为一个需要改进的领域，该委员会是2000 年CAST会议后为此建立的组织。CENA赞助一个团队在此领域开展工作，并已取得以下成果。

介绍需求捕获的阶段组成——现场启动

介绍需求捕获指南之需求捕获技术

介绍需求捕获的阶段组成——现场最佳实践和场外分析

需求捕获不象是拔牙…但也比较类似。常见的问题是，软件工程师缺乏准备，同时需要该产品的组织或个人缺乏兴趣。一般大家都会认为客户会对产品很感兴趣，因为该产品会解决客户面临的问题。但通常客户希望开发人员已经知道相关知识或不愿意耗费时间为软件产品提供基础材料。无疑，这些观点是错误的 ，但是客观存在的。可以使用需求捕获列表来验证你的项目在需求捕获方面进展如何。在这个列表中，越多问题的答案是否定的，那么需求捕获失败的可能性就越高。

需求捕获的阶段组成－现场执行

做软件需求最重要就是分解用例场景，没有用例就不是需求。软件工程这类书要学，不过软件工程软件需求最关键就是用例场景的合理建立，这条，好象没有什么大学教科书谈到，仿佛中国的大学计算机科学系教师统统没有做过软件项目的，完全没有这个概念。所谓的软件需求，如果不是变成走不通的伪代码，就是用不上的美工方案，程序员对此除了干瞪眼是没辄的。

小型软件项目，通常是指工作量在3-12人月之间的项目，在小型软件开发企业中，这类项目一般是放任自流，少有管理。在这类项目中，项目经理的角色常常由公司老总或部门老总亲自充当， 项目往往具有投资少、人员少、时间紧、需求不明确等特点。由于针对小型项目，缺乏科学有效的管理方式，或企业难以负担类似于大型软件开发的管理成本，这类项目的开发过程往往会产生诸如项目进度难以控制、产品缺陷多、后期维护工作量大、客户满意度低、文档缺乏等诸多问题。一项调查表明，大约有70%的小型软件开发项目超出了预期时间，90%以上的项目费用超出预算。因此，小型项目迫切需要引入适度的开发管理。本文将针对小型软件项目开发过程中的核心管理问题给出一些行之有效的解决方案。

变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。

成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。

在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题根源之所在。

本文通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。

项目范围管理是指对项目包括什么与不包括什么的定义与控制过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。

需求，大家常挂在嘴边。测试的以没有需求而烦恼，开发的也以没有明确的需求而尴尬。有一种说法，80%的缺陷直接或间接地来自需求，这可能是二八原理的估算，无论8成也好，6成也好，需求的重要性已达到共识。

软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题。

这一篇文章更注重于实际，举出了在业务建模简短需要注意的一些原则和实践，每一条都来自于实践之中，也都有理论的支持。其中的很多内容更是经过多次的失败才总结出来的。相信大家如果能够理解这些原则和实践的某些方面，至少能够避免重蹈覆辙。

在我们的文章中，根据UP的思想，称之为"业务建模".所有的项目都有业务建模时期。

根据个人的经验，如果照合同中列出的项目范围来做，从狭义的项目范围角度来说是可以完成的，但客户既然付了钱，他将不断努力最大化他的利益，扩充并充实需求的内容，所以项目组面临着项目中从始至终需求不断变化的过程。

本文介绍了需求管理的必要性，并介绍了控制需求渐变的一些方法。

做软件需求最重要就是分解用例场景，没有用例就不是需求。