勇于直面需求变更.docxVIP

PAGE 1 PAGE 1 勇于直面需求变更  作者针对当前软件系统建设中普遍存在的需求变更问题提出了自己的见解，并提出除了从客观上采取加强培训和代价分析等方法外，更重要的是通过采用合理的分析设计方法，进行可扩展性设计可以有效地降低需求变更引起的风险和维护代价，并给出了可扩展性设计的一个详细例子。  软件系统开发过程中的需求变更问题  作为软件开发人员或者软件系统客户，相信我们都遭遇过因为需求变更而需要修改系统的状况，一般说来客户会要求转变界面，转变操作方式，甚至转变业务，说，当时我是那样要求的，不过现在我们的业务调整了…这时需要中断正在进行的工作，需要查证以往的资料，需要修正计划，需要…  需求包括业务需求、用户需求和功能需求。业务需求（BusinessRequirement）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（UserRequirement）描述了用户使用产品必需完成的任务，功能需求（FunctionalRequirement）定义了开发人员必需实现的软件功能。在软件系统开发过程中，有许多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有几方面的原因:  对需求的理解分歧  当客户向需求分析人员提出需求的时候往往是通过自然语言来表达的，这样的表达对于真实的需求来说是一种描述（甚至只是某个角度的描述），远远不能保证这样的描述可以得到百分之百的正确理解，或许在同客户交流的第一时刻就埋下了理解分歧的种子，打一个比方说客户说我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子，分析人员想，哦，墙、扇子、柱子、绳子这些我都知道，但是真的画出来的时候客户当然会跳起来了！这是理解分歧的问题，一般跟分析员的学问、背景，还有客户表述的标准程度、双方的交流状况有关；  系统实施时间过长  一个大中型系统的建设可能要连续一段时间，当客户提出要求之后，他当时并不能看到系统的运行状况，当双方认为理解也许没有分歧的时候（事实上还会有个Deadline），开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求；  客户详细状况不一  当前客户的状况不一，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求；也有可能客户所在的行业操作不规范，本身存在许多人为因素，这时候开发方更是需要随时预备应变；  开发本身要求  有可能是来自开发方自身版本升级或性能改进、设计修正的要求出现需求变更，这时更是无法绕开这个问题的了！  所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以不要幻想那么抱负的需求分析，当你开始一个项目的时候就应当意识到，客户需求变更一定会有的，那么对于这样的现状，我们该怎么办呢？客户是上帝，莫非我们就象以前一样，跟着客户的需求不停地修改软件，到最终工期延长，员工疲乏，成本成倍增长，客户满足度降低，原来的设计也会转变得支离破裂，系统难以维护？  客观面对需求变更  假如需求一定会变化，假如我们不得不面对，假如我们已经痛定思痛，想要变革，那么还有什么方法可以改善我们的现状?答案是有的。  加强人员培训  从客观方面可以采取的措施来说，首先，我想不容置疑的是加强对需求分析人员的培训，尽可能增加软件系统、行业的背景学问，提高与客户的沟通能力，增加服务意识和责任感，因为将要开发的系统直接建立在需求分析的基础上；同时规范需求分析人员和客户沟通的方式，以及规范需求说明的格式，假如可能的话，尽量采取象XP的UserStory，或者用户可以理解的用例图来对需求进行标准、规范的描述，保证双方在工具的协助下对需求达到共同的熟悉，这一点是老生常谈，就不多说。  确定文档的有效性（Validity）  顺便要提的一句是关于文档，需求文档是相当重要的，可是目前存在一种惊奇的现象，原来说必需要有文档，而且是根据某种特定的格式，当然这没有错，但接下来，却没有人关心文档的真正内容是否正确，格式是否真的合理，是否实用（而且许多状况下是在几天时间里赶出来或补上去的），例如我遇到一个例子，需要在原来的需求基础上进行后续开发，文档找到了，完全符合格式的要求，但是我在里面找到的线索是有限的，结果是自己花几天的时间查找数据表结构、甚至查看数据表的内容，询问当时的开发人员，才分析到所要的关系，这种状况在