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