《探究软件项目失败与软件需求的关系及解决方案》由会员分享，可在线阅读，更多相关《探究软件项目失败与软件需求的关系及解决方案（5页珍藏版）》请在金锄头文库上搜索。
1、探究软件项目失败与软件需求的关系及解决方案一、问题背景需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目 中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关 重要的影响。尽管如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与 或接触到的一些项目来看,有在校内做的课程实训项目，也有出去实习在公司做的实际项目， 它们的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的 是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开 发是一项系统工作，而不是简单的技术工作，只有系统的了解
2、和掌握需求的基本概念、方法、 手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理 工作。需求分析的过程，也叫做需求工程和需求阶段,它包括了需求开发和需求管理两个部分。 需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四 个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他 们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活 动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主 观性和可描述性差的
3、特点，因此，需求分析工作往往面临着一些潜在的风险。这些风险主要 体现在以下两个方面：1.在初期的需求开发阶段，需求人员不能准确、全面的获取项目相关需求。 一方面 是因为用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的 需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么 就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况 往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助 他们梳理思路，搞清用户的真实需求。另一方面，一些业务人员日常工作繁忙，他们不 愿意付出更多的时间和精力向分析人员讲解业务，配合
4、力度不够，这加大分析人员的工 作难度和工作量，也可能导致因业务需求不足而使系统无法使用。除了这两方面的外部 原因，需求人员在编写文档时，不规范的文档编写所产生的需求描述二义性，以及对项 目需求描述的完整性和细化性不满足项目要求，也往往会加大后期开发人员对项目开发 的难度甚至开发出不符合客户要求的项目产品，导致项目的最终失败。2.用户需求的不断变更。过去，在传统软件行业里，开发的流程一般是：先作需求分析，然后确定功能，最 后实施开发。也就是说，需求分析之后，需求基本就很少变了，会在相当长一段时间内， 维持一个稳定的需求。但是，在进入互联网软件时代后，事情已经发生了变化，仅就需求而言，“朝令夕改”
5、 已经不是什么新鲜事，作为系统的实现者，我们当然都希望需求越稳定越好，但那仅仅是“理 想”，甚至，有时仅仅是“梦想”。因为，对于一个尚未成熟的市场，尚未成熟的互联网产 品或者尚未成熟的团队来说，需求变动的推动者，可能是市场，可能是用户，也可能仅仅是 老板的一句话，你无法说这个改动是对是错，很多的情况下，对于我们而言，最切实可行的 条路，就是：摆正心态，积极应对。二、解决方案面对这两个问题，如何做好需求工作？这不仅要求分析人员具有丰富的需求分析经验和 良好的专业素质，能够在实际工作中面对不同的单位、不同的部门、不同的人员、不同的文 化、不同的关系、不同的管理水平等等不同的情况，还要求这个项目的需
6、求团队能够建立一 个有效的工作机制，只有建立了工作机制，才能保证需求工作按照既定方案执行，需求开发 和管理的参与者才会在一种有序的状态下工作。对于第一个问题中用户不能充分表达自身需求以及业务人员对项目问题关注度不够高， 我们可以以下一些措施来进行改善：1抓住用户决策者最迫切和最关心的问题，引起重视。用户方决策者对项目的关心重视 程度是项目能否顺利开展的关键，决策者的真实意图也是用户方的最终需求，因此，在开发 过程中要利用一切机会了解决策者关心的问题，同时也要让他们了解项目的情况。在诸如谈 判、专题汇报、协调会议、领导视察、阶段性成果演示等过程中用简短明确的语言或文字抓 住领导最关心的问题，引导
7、他们了解和重视项目的开发。2建立良好的沟通环境和氛围。分析人员与用户沟通的程度关系到需求分析的质量，因 此建立一个良好的沟通氛围、处理好分析人员与用户之间的关系显得尤其重要，一般情况， 用户作为投资方会有一些心理优势，希望他们的意见得到足够的重视，分析人员应该充分的 认识到这一点，做好心理准备，尽量避免与他们发生争执，因为我们的目的是帮助用户说出 他们的最终需要。在彼此沟通的过程中做到：态度上要尊重对方，但不谦恭。谦恭可能会让 用户一时感到满意，但对长期合作并没有好处，尤其是在发生冲突的时候，用户会习惯性地 感到自己的优势，而忽略分析人员的意见；分析人员要努力适应不同用户的语言表达方式。 每个
8、人都有自己的表达方式，所以优秀的分析人员应该是一个优秀的“倾听者”，他们能很 快的适应用户的语言风格，理解他们的意思；善于表达自己，善于提问。分析人员在开口前 应该先让对方充分表达他的意思，在领会了后，自己再说，尽量不要抢话。对于第一个问题中需求人员在需求整理时，文档编写不规范，时常需求描述出现多义性， 就需要规范需求开发方法，对需求人员的行为进行约束：（1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的 简单模型。（2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需 求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。（3）需求优
9、先级：确定使用实例、产品特性或单项需求实现的优先级别。以优先级为 基础确定产品版本将包括哪些特性或哪类需求。（4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型， 用户通过评价原型更好地理解所要解决的问题。（5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮 助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致 的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作 用图。（6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员 使用统一的数据定义。在需求阶段，数据字典至少应
10、定义客户数据项，确保客户与开发小组 是使用一致的定义和术语。此外，还可以根据NASASEL方法对最终的需求规格说明书进行评审，它是由美国国家航 空和航天局软件工程实验室开发的五大常用国际软件工程规范之一，它对软件需求过程的评 价标准是：清晰、完整、一致、可测试。（1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大 的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量 采用主语+动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修 饰这些复杂的表达方式。除了语言的二义性之外，注意不要使用行话，就是计算机术语。需 求分析最重要的
11、是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使 用了行话，就会造成用户理解上的困难。（2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开 发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是， 需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需 求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最 初的需求计划制定到最后的需求评审。（3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。 在需求过程中，开发人员需要把一致性关系进行细化，比如用户
12、需求不能超出预前指定的范 围。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最 初的实现目标。（4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人 说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。实 际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求 分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户 的需要，保证软件系统是成功的。对于第二个用户需求不断变更的问题，这是一个不可避免的问题，对于一个一个项目产 品来说，往往会受压于市场环境，受压于同类产品竞
13、争，也可能是受压于用户，这些方方面 面的原因，都可能造成项目需求的变更。所以我们要做的不是被动地去避免这个问题，而是 要考虑一下在我们团队内部，以何种开发方式，以何种流程，以何种组织架构来灵活适应这 种经常性的需求变化。首先，需要有效控制需求变更，既不能一概拒绝客户的变更要求，也不能一味地迁就客 户，所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是 对变更进行管理，确保变更有序进行。这就要求我们在项目初期就明确合同约束，规定何种 情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程； 建立需求基线，明确和树立需求基线是需求变更的依据，在开
14、发过程中，需求确定并经过评 审后（客户参与评审），建立第一个需求基线。此后每次变更并经过评审后，都要重新确定 新的需求基线；建立变更审批流程，明确需求变更审批环节、审批人员、审批事项、审批流 程;还有最重要的一点是确认客户是否接受变更的代价，要让客户认识到变更都是有代价的， 要和客户一起判断需求变更是否依然进行。其次，除了在管理角度制定合理有效的体制来控制需求变更之外，还要在软件分析和设 计的角度中，通过采用合理的分析设计方法，进行可扩展性设计可以有效地降低需求变更引 起的风险和维护代价。要拥抱需求变更，很重要的一点就是需要建立合理的项目体系结构。软件体系结构的设 计是从结构的角度对整个系统进
15、行分析，选择合适的构件，安排构件间的相互作用以及他们 之间的约束，形成一个系统框架以满足用户需求。在设计软件体系结构时，不仅应该想到如 何完成满足现在已经提出的用户需求，同时也应适当地考虑到需求的变更。采用有弹性和可扩展的软件体系结构设计可以有效地降低需求变更引起的风险和维护 代价，能够在项目范围未发生变化的前提下很好地适应需求的变化。体系结构的灵活和可扩 展性设计使得开发者可以在这种体系结构上面进行各个功能层的组合和分离，也可以将各个 功能层分布在各个不同的服务器上共同提供服务，因而能够快速的对需求变更作出响应，并 且对已经开发好的系统产生尽可能少的影响。体系结构的设计除了考虑到体系结构的灵活性和可扩展性以外，还应尽量采用松散耦合 的结构，使得结构中的各个构件之间的关联程度尽可能的少，这样就能在需求发生变更时一 个构件的变化对另一个构件产生尽可能少的影响。
