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

 

引言

      当今，经济和社会生活对软件的依赖程度急剧增长，软件需求日益复杂，软件开发成为一项跨越技能，职责范围和时间阶段的综合团队活动。实践证明，良好的需求工程对于降低开发成本和保障项目成功至关重要。根据权威机构的统计，在全世界范围，仅有四分之一的软件开发项目能在规定的时间和预算内达到客户的目标。纵观这些项目成功的项目，过硬的需求工程是成功经验中少有的共通部分。
      需求是系统或软件必须达到的目标和能力；开发团队的成功就是满足软件项目的需求。软件需求工程化问题有综合的内涵：包括基于问题的需求捕获、建立简单原型、建立分析模型、开发需求归约、相应的审核以及综合的管理。
      国内的软件行业起步晚，起点高，任务急，时间短，在软件需求工程方面暴露出很多问题。千头万绪之中，首要的着力点应该落实在基础层面，具体讲有两方面问题：捕获方法（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中，软件需求归约的内容作为软件开发计划、软件构架文档、分析模型、设计模型和测试模型的直接依据，流程不仅描述这些关键工件之间的关联，而且对于内容的映射和转换给出了具体的建议和验证点。

 

总结

      需求的捕获方法和内容组织是需求工程中的基础问题，相应的工作内容体直接反映件需求的核心价值，也为展开和完成需求工程中其它任务建立了良好开端。在基础问题没有得以解决之前盲目强调所谓的“管理”只可能作一些表面文章，甚至适得其反。
      当然，能解决问题的办法并不唯一，本文介绍的方案具有深厚的底蕴，是基于Rational Software专注软件工程领域二十多年所积累的最佳经验，更是被行业接受的主流方向。