技术与市场 专题研究 第１８卷第８期２０１ １年 浅析需求分析在软件工程中的作用 张 毅 （广东松山职业技术学院计算机系，广东韶关 ５１２１２６） 摘 要：阐述了需求分析在软件工程项目设计中的重要作用，并指出软件项目的优劣取决于需求质量的高低；分析了需 求风险、标准、管理技巧等问题。 关键词：软件工程；需求分析 ｄｏｉ：ｌＯ．３９６９／ｊ．ｉｓｓｎ．１００６－８５５４．２０１１．０８．２４０ Ｏ 引言 ２软件工程中的需求工作流程 一般来说，一个软件产品从策划、定义开发、使用与维护直 软件需求是指用户对目标软件在功能、行为、性能、设计约 到最后废弃，需要经过一个漫长的时期，通常把这个时期称作 束等方面的期望。通过对问题及其环境的理解与分析，为问题 软件的“生命周期”，分为“软件定义”“软件开发”“运行与维护” 涉及的信息、功能及行为建立模型，将用户需求精确化、完全 三个阶段： 化，最终形成需求规格说明，整个活动构成软件开发生命周期 （１）软件定义阶段，主要进行软件目标的策划、可行性研究 的需求分析阶段。在需要的开发中，问题的获取包括业务需求、 和软件的需求分析工作，通过和用户多次交流，在所要开发的 用户需求、功能需求。业务需求的参与者主要是业务流程分析 软件必须“做什么”方面和用户达成一致（在开发构成中也允许 员，对企业目前的业务流程进行评估，确定进行何种程度的业 在严格的控制下进行需求变更）。 务建模；用户需求重心是如何收集用户需求，确定角色和用例， （２）软件开发阶段，主要对软件的体系架构、数据结构和主 获取需求的方法倾向组织访谈会；功能需求依赖于用户需求。 要算法进行设计和编码实现。对于编码结果，还要按照规范进 是用户需求在系统上的一个映射，为用户做一个软件原型是一 行测试后，才能最终交付使用。如前所述，在开发阶段也可能对 个很好的方法。 于此前不够准确的软件定义结果进行调整。 ３软件工程中的需求分析 （３）软件的运行与维护阶段，在软件生命周期中占据比例 需求分析包括提炼、分析和仔细审查已收集到的需求，以 最大，在软件运行过程中，分析和设计阶段的一些遗留缺陷可 确保所有承担风险者都明白其含义。能找出其错误、遗漏等地 能会逐步暴露；运行环境的演变也会对运行的环境提出变更要 方，分析的目的在于开发出高质量的需求。这样才能做出实用 求；用户新需求的提出则常常要求扩充现有软件的功能或者改 的项目估算并进行设计、构造和测试。通常把需求中的一部分 进其性能，所有这些要求与问题都必须通过“软件维护”工 用多种形式来描述，对这些不同视图的分析将揭示出一些更深 作去解决。在维护过程中，必须注意保持所有软件工作产品 的问题，这是单一视图无法提供的。分析还包括与客户的交流 之问的一致性。针对不同的需求，维护工作一般可以分为纠 以澄清某些混淆，并明确哪些需求是更为重要的。其目的是确 错性维护，适应性维护、扩充性维护和预防性维护等不同类 保所有风险承担者尽早地对项目达成共识并对将来的产品有 型。 个相同而清晰的认识。 可见，虽然软件的需求分析处在开发的第一阶段，但实行 （１）创建数据字典。数据字典是对系统用到的所有数据项 有效的需求工程管理的组织能获得多方面的好处，最大的好处 和结构的定义，以确保开发人员使用统一的数据定义。在需求 是在开发后期和整个维护阶段的重复的工作大大减少了。可以 阶段，数据字典至少应定义客户数据项以确保客户与开发小组 说，需求分析奠定了软件工程和项目管理的基础。 使用一致的定义和术语。 １ 软件工程中的需求分析概述 （２）确定需求的优先级别。应用分析方法来确定使用实例、 一个软件项目的开发主要分为五个阶段：需求分析阶段、 产品特性或单项需求实现的优先级别。以优先级为基础确定产 设计阶段、编码阶段、测试阶段和维护阶段。而需求分析阶段所 品版本将包括哪些特．陛或哪类需求。当允许需求变更时，在特 得到的结果是软件项目开发中其他四个阶段的必备条件。从以 定的版本中加入每一项变更，并在那个版本计划中做出需要的 往的经验来看，需求分析中的一个稍稍的偏差．就可能导致整 变更。 个项目无法达到预期的效果。需求分析是指理解用户需求，就 （３）分析需求可行性。在允许的成本、性能要求下，分析每 软件功能与客户达成一致，估计软件风险和评估项目代价，最 项需求实施的可行性，明确与每项需求实现相联系的风险，包 终形成开发计划的一个复杂过程。从广义上理解，需求分析则 括与其它需求的冲突，对外界因素的依赖和技术障碍。 包括需求的获取、分析、规格说明、变更、验证、管理的一系列需 （４）使用质量功能调配。质量功能调配是一种高级系统技 求工程。 术，它将产品特性、属性与对用户价值联系起来。该技术提供了 ３４３ 专题研究 ＴＥＣＨＮｏＬｏＧＹ ＡＮＤ ＭＡＲＫＥＴ Ｖｏ１．１８，Ｎｏ．８，２０１１ 一种分析方法以明确哪些是客户最为关注的特性。 （５）衡量需求稳定性。记录基本需求的数量或每月、每周的 那些超出可用资源规模的变更，也应有相应能力扩展资源以适 应扩大的规模。 ６．４改进系统定义 变更数量。过多的需求变更意味着问题并未真正弄清楚，项目 范围并未很好地确定下来或是变化较大。 包括两个重要的考虑事项：制定更详细的高层系统说明， （６）绘制系统上下文示意图。这种示意图是用于定义系统 与系统外部实体间的界限和接口的简单模型，同时它也明确了 通过接口的信息流和物质流。 （７）作为功能需求的补充。软件需求规格说明还应包括非 验证系统是否符合受众需要，是否按说明运行。说明通常是项 目团队的重要参考材料，在制定说明时一定要考虑受众。 ６．５管理变更的需求 能否适应变更需求是评测团队的涉众敏感度和运作灵活 功能需求，它描述了系统展现给用户的行为和执行的操作等。 ４软件工程中的需求风险 性的一个尺度。一个需求的变更对其他需求可能有影响，管理 需求变更包括这样一些活动：设立基线、追踪每个需求的历史、 确定哪些依赖关系值得追踪、在相关项之间建立可追踪关系以 在进行需求分析时存在一些很危险的做法，这些做法会对 软件产生致命的影响，具体体现在：１）无足够用户参与；２）模棱 两可的需求；３）不必要的特性；４）过于精简的规格说明；５）忽略 了用户分类；６）不准确的计划。 ５需求的标准 优秀的需求应该是明确、完整、一致、可测试的，此外还有 其他的概念，如可跟踪、可修改等。 （１）明确：对需求分析中采用的语言做某些，除了语言 的二义性之外，不要采用计算机术语，造成用户理解上的困难。 （２）完整：需求的遗漏是经常发生的事情，多发生在用户方 面。需求完整性涉及到需求分析过程的各个方面，从最初的计 划制定到最后的需求评审。 （３）一致：用户需求必须和业务需求一致，功能需求必须和 用户需求一致。严格遵守不同层次间的一致性关系，在实现过 程中，把一致性关系细化。 （４）可测试：需求分析是测试计划的输入和参照，只有系统 的所有需求是可以被测试的，才能保证软件始终围绕着用户的 需求。 ６需求管理技巧 需求管理可遵循的方案较多，下面的方案适用于每一个关 键的需求管理。 ６．１ 理解涉众需要 需求有许多来源，它们可来自于对项目结果感兴趣的任何 人，客户、合作伙伴、最终用户以及领域专家都是需求的来源， 而管理人员、项目团队成员、业务策略和管理机构是另外一些 需求源。掌握和确定需求源的类别、并获得这些需求源以及从 中获取信息是很重要的。 ６．２定义系统 解释涉众需求，并整理为对要构建系统的意义明确的说 明。在定义初期，决定需求的构成、文档格式、语言规范、需求 等级、请求优先级和预计工作量、技术和管理风险以及系统规 模等。定义活动还包括与最关键的涉众请求直接联系的初期原 型和设计模型。 ６．３管理系统规模 管理系统规模是一个持续不断的活动，需要迭代式和递增 式开发，将项目细分为更易于管理的若干个小部分。使用需求 属性作为协商应包含需求的基础，项目推介人能代表组织拒绝 及维护版本控制等，建立变更控制或批准流程也很重要。 ７评审需求以保证需求的质量 要保证需求的质量必须确认需求的标准，并对其进行评 审。需求的标准包括其正确性、一致性、无二义性、完备性、相 关性、可测试性、可跟踪性等几个方面。依据软件工程中使用 的定义技术，上面的其中一些检查能够自动化地进行。 有时，有些人错误地认为在需求上消耗多少时间就会导致 产品开发推迟多少时间，却并没有认识到需求分析中任何的含 混不清或微小的遗漏都可能会造成系统开发中的重大问题甚 至导致失败。而在软件开发的不同阶段进行修改所付出的代 价也是极其不同的。在早期引入变动，涉及的面比较小，因而 代价也比较低；在开发的中期，因为许多配置项（被标示的 作）产品已经完成，所以引入一个变动，就要对它所涉及的所有 已完成的配置项进行变更，不仅工作量大，而且逻辑上也更复 杂，因此付出的代价剧增；如果在软件“已经完成”时再引入变 更，更是要付出高得多的代价。根据美国一些软件公司的统计 资料，软件开发后期引入一个变动比在早期引入相同变动所需 付出的代价高２～３个数量级。 所以，要想做好一个软件项目，第一步，先要做好需求分析 这个阶段任务，我们知道，一个软件产品是否优秀，要看是否能 最大地满足用户的需要，对一个成功的软件 Ｉ：程项目来说， 程项目的需求提供了成功的基础。优秀的软件产品是建立在 优秀的需求之上的。而高质量的需求来源于客户与开发人员 之间有效的交流与合作。 ８结语 综上所述，对于应用软件来说，软件定义阶段的所有努力 都是为了得到一个全面的需求，当拥有了完善准确的需求分 析，那么开发出来的产品会更接近实际，可操作性会更强，这必 然会更快的被用户认可和接受，也会使软件的推广变得更容 易。 参考文献： 【１］万江平．软件工程［Ｍ】．清华大学出版社，２００６．
