解决需求工程中的基本问题.docVIP

Amos，July，2002 解决需求工程中的基本问题 引言 当今，经济和社会生活对软件的依赖程度急剧增长，软件需求日益复杂，软件开发成为 一项跨越技能，职责范围和时间阶段的综合团队活动。实践证明，良好的需求工程对于降低 开发成本和保障项目成功至关重要。根据权威机构的统计，在全世界范围，仅有四分之一的 软件开发项目能在规定的时间和预算内达到客户的目标。纵观这些项目成功的项目，过硬的 需求工程是成功经验中少有的共通部分。 需求是系统或软件必须达到的目标和能力；开发团队的成功就是满足软件项目的需求。 软件需求工程化问题有综合的内涵：包括基于问题的需求捕获、建立简单原型、建立分析模 型、开发需求归约、相应的审核以及综合的管理。 国内的软件行业起步晚，起点高，任务急，时间短，在软件需求工程方面暴露出很多问 题。千头万绪之中，首要的着力点应该落实在基础层面，具体讲有两方面问题：捕获方法 （elicitation）和内容组织（specification）。解决基本问题不仅能够作到短期见效．．．．，而且为围绕需求问题的整体水平提升奠定坚实的基础．．．．．。 捕获方法 捕获需求就是引导客户说出他们想要的东西，并确认被记录下来的内容确实是他们想要 的东西。如果需求的捕获方法选择不当或使用不当，通常会暴露出两方面问题。 第一，软件需求不能如实反映用户的真正需要。比较常见的一种误解是需求的简单和复 杂程度决定了用户是否能够真正理解相应的内容：误认为客户只能看懂简单的需求，但是对 开发没有直接帮助；只有复杂的需求才有用，但是大多用户又不可能看得懂。事实上，造成 这类问题的主要原因是捕获的需求不能反映用户的视角，因而，用户站在自己的立场上很难 判断需求是否完备和正确，特别是在开发活动的早期。 第二，软件需求不能被开发团队的不同工种直接共用。理论上，开发团队所有成员的工 作内容都受软件需求制约；现实中，如果不采用理想的需求捕获方式，只有分析人员的工作 看起来和软件需求的内容直接关联，其它人的工作内容和软件需求的关联并不直观，形式上 的差异或转述往往不易察觉地造成了诸多歧义、冗余或者缺失。 Use Case 作为软件需求的捕获方法，在利用的当的情况下，能够很好地解决以上两方面 问题。 第一，Use Case 是软件需求的载体，也是和用户关于软件需求进行讨论的沟通方式， Use Case 方法的最大特色就是充分反映软件使用者的视角。以Use Case 方法组织的需求内 容既有一目了然的图形，又有深入细致的文字描述，从宏观到微观，无论繁简，都能反映出 用户的视角，因而能够被用户充分的理解。换言之，用户有可能判断被捕获的软件需求是否 能够满足他们的真正需要，从而加速双方在早期达成共识。参见下图。 ? 第二，基于Use Case 组织的软件需求具有显著的外向型特征，是高度可复用的劳动成 果。Use Case 支撑分析人员帮助用户理解系统能做些什么，帮助设计人员在适中的问题范围 内识别基本元素的行为，帮助项目经理预测开发任务的工作量，为测试活动和用户文档编辑 提供了直接可用的依据和蓝本。参见下图。 内容组织 需求内容的具体组织形式主要针对软件需求归约（SRS），存在两个比较突出的问题。 第一，不符合国际通行的规范。主要症状表现为需求内容的层次不清晰，往往是庞杂软 件需求细节的简单堆砌，很难从高层次上理解软件产品“为什么做和做什么?”。 第二，与软件需求归约相关的流程指导薄弱。一方面，获得高质量软件需求归约过分依 赖于分析师自身的经验，限制了并行开发需求内容的可行性；另外，面对有价值的软件需求 内容，团队成员并不能充分地利用。 Rational Unified Process 作为软件开发流程的行业事实标准，其成熟的文档体系及其相 应的流程辅导，在利用的当的情况下，能够很好地解决以上两方面的问题。 第一，Rational Unified Process 中的软件需求归约符合国际规范IEEE830-1998，内容划 分为概述、总体说明，详细说明和支持信息等几部分，各个部分内容之间层次分明、关联清 晰。以Use Case 描述的功能需求被平滑地融合在软件需求归约当中。于此同时，Rational Unified Precess 为软件需求归约的编制提供了详细的指南和检查点，能够保障协同作业的质 量。参见下图。 第二，围绕软件需求归约，Rational Unified Process 提供了丰富的流程指导。软件需求 归约的基本内容取材于“涉众请求”，确保需求内容反映使用者的要求；软件需求归约的指 导原则依据“前景”，确保具体内容和高层定位吻合；软件需求归约的文字描述严格遵守“词 汇表”，屏蔽来自微观层面的歧义。在Rational Unified Process 中，软件需求归