软件需求管理

　至今所不为熟悉的需求管理的基础

　　这则报道是以年轻IT工程师为对象（参加工作2-4年左右），以能够使其理解软件需求管理的基础为目标。为了描述更具体的内容，在本报道中提出了关于RUP（注）的需求管理成果物和作业流程，为了尽量使需求管理的基础更明了易懂，而要对其进行讲解。

　　（注：Rational Unified Process：是 IBM Rational的软件开发方法论，作为面向对象开发方法论而闻名）

　　为什么要进行需求管理？

　　为什么要进行需求管理？用一句话来概述就是因为管理需求可以很大程度地来左右项目的成功。首先，来考虑一般的项目目标吧。请看下面的定义。

　　出现了“满足顾客真实需求”“高品质”“期限内”“预算内”这4个关键字，但是无论哪个都与需求管理息息相关。首先、为了制造“高品质的产品”，在需求管理方面要准确地把握所谓的系统可靠性、可扩展性等非功能需求也是非常重要的。另外、对于在“期限内”“预算内”开发产品存在问题吗？项目必须在限定时间、预算以及资源的状态下开发。考虑利用所给予的时间、预算以及资源能够完成多少作业，必须把产品要求式样的范围控制在作业可能的范围内。

　　由于QCD（Quality：质量、Cost：价格、Delivery：缴纳期）这一关键字经常被使用，所以大家也就对“在期限内及预算内开发高品质的产品”更加耳熟了。在此想要让大家关注的是“满足客户真实需求”的部分。无论在期限及预算内制造了多少高品质的产品，如果不能满足顾客真实需求的话，那些产品也是没有意义的。

　　例如，开发为提高营业员业务处理效率的应用程序。在该项目中拥有高超技能的开发者进行了极优秀的设计，也充分考虑了其扩展性。但是，由于应用程序对于用户（营业员）来说非常难以使用，所以很多营业员都对其敬而远之。不久，该系统就会自然消失了。该产品没能反映所谓“提高业务处理效率”的顾客的真实需求。也就是说、缺少了满足该需求的部分（例如：使用 GUI的容易度）。遗憾的是这种事例经常发生。在此，我想在实现“满足顾客真实需求”之后来强调项目的成功挖掘。

　　另一方面、从数据中也能说明需求管理对项目的成功有很大的贡献。作为软件开发现场的调查报告，根据著名的（Standish Group的）CHAOS（2001年）报告，在对项目的成功完成贡献的原因一览里“用户的输入”“明确商务目标”“将开发范围最小化”“稳定的需求项目”等与需求管理相关的事项连接在上面。从此也能看出需求管理的重要性。

　　何为需求？何为需求管理？

　　在接触需求管理的具体内容之前，首先来看一下要求和需求管理的定义。在RUP中将需求和需求管理如下定义。

　　“需求”的定义非常简单。所谓定义需求就是定义“应该满足系统的样态和能力”。换句话说，可以说成定义“做什么好呢？”，这也可以说是定义了项目成功的基准。即使用一句话来概述需求、在需求里也存在着各种各样的种类和水平。但是我想在以后将对需求的详细定义进行说明。

　　在RUP中“需求管理”的定义中需要注意的是操纵需求管理的范围的宽度。所谓需求管理，首先包含“挖掘需求”。所谓“挖掘需求”就是从顾客和终端用户提出对系统的需求。通常、不会轻易提出需求，所以就变为使用各种手法来竭力发掘。

　　其次、所谓需求管理包含“整理需求”。如果是复杂的系统，存在几百件需求也是正常的，所以需要对其进行整理。并且，需求管理也包含“将需求文档化”。一般人都不能记住那么多的需求，并且也为了在客户和开发团队之间共享需求所以文档化是必要的。

　　另外，所谓需求管理也包含“形成并维护客户与开发团队之间的协议”。如上所述、如果能够“发掘、整理要求，并将其文档化”，接下来关于其要求，为了在期限内、预算内完成开发，需要在顾客和开发团队之间对项目中涉及的要求范围进行协定。另外、随着开发的进入而发生需求变更时要分析其影响范围，对于被采纳的以及与之相反的事项与客户形成协议也是非常重要的。

　　需求管理不简单

　　如果是2～3人规模的小项目，不会为需求而烦恼。但是小规模软件包开发中有几千件需求、大规模项目中有几万件以上的要求，随着规模的变大，在需求管理中要面对各种问题。如下所示：列举了项目中容易引发的典型问题。

　　---“很难发掘需求”

　　在很多情况下，如果开发团队不能充分理解应该解决的问题，就会提供给倾向技术的解决对策，从而制作成没有满足顾客需求的系统。为了不出现上述情况，挖掘客户的需求就显得尤为重要。但是由于客户与开发者之间持有不同的术语、背景、动机以及目的，因而存在着沟通上的分歧。

　　---“难以将需求体系化并整理”

　　由于在大规模项目中单纯地需求的数目非常多，所以涉及的事物本身很困难。另外、这些需求的出处也不仅仅是用户，也复杂地涉及到受系统影响的利害关系者（Stakeholder）。更进一步地说、在需求方面存在着多种种类和级别。关系到各种各样的成果物，所以体系化非常困难。

　　---“难以将需求文档化”

　　这既有没有明确需求的情况，也有难以把单纯的需求用语言来表达的情况。文档化是不仅困难、而且对记述高品质的需求文档缺乏评审，同时在需求变更时更新文档也需要花费大量的作业时间。

　　---“难以追加需求变更”

　　随着项目的展开、需求会进化并增加，有时计划会超出项目的日程安排和预算。最初的原因是客户频繁的需求变更，但是在开发团队的对应方法上也存在着问题。有时候不能分析需求变更的影响，不能与客户取得很好的协议。另外、把需求变更在开发团队的全体成员中共享也不是简单的事情。

　　如上、发现了很多问题，但是为了妥当地处理这些问题，要求对需求管理进行体系化的程序。下回、在开始需求管理具体的程序之前，先要了解一下要求的各个种类和级别。

　　第2回：软件需求的详细分类

　　在上回的 “至今所不为熟悉的需求管理的基础”中只接触了关于需求的非常模糊的定义。在这回我们来了解一下更详细的需求吧。首先看一看如何描述才能把系统需求完整记录，然后再逐步深入。

　　需求可以描述系统的什么内容？

　　定义系统的详细需求在RUP中称为“软件需求（Software Requirements）”。也就是说，如果完整的描述了软件需求的话，系统需求也就完整描述了。

　　软件需求定义是从把系统作为黑匣子的观点出发，描述系统为用户、设备或者其他系统提供的执行能力/状态的内容。也就是说，要描述软件需求的话，需要考虑从系统外部来了解的状态下（不知道系统中会变成什么什么状态），完整地描述其要执行什么。为了完整地描述系统，需要着眼于图1的5个范畴。根据定义图中的项目能够决定软件的全套需求。

　　不属于软件需求的事项

　　至此所说的软件需求就是将“从外部观点来看系统必须要做什么”传达给开发者的事项。说明了从系统的输入、输出、功能、非功能特性以及设计方面限制等的侧面来定义的事项。决定“系统会执行什么（What）”，但是重要的是不能决定“系统怎样将其实现（How）”。

　　另外，必须注意软件需求中不应该包含的信息。在软件需求中不包含关于设计和实现的信息、系统测试方法的信息以及与项目管理相关的信息等（图2）。

特别是关于设计和实现的信息，稍不注意就会介入，所以需要特别注意。如果需求中包含关于设计和体系结构的信息，则会被其信息所限制，对于应用程序来说就不能选择最合适的设计方法。但是，有时系统内部已经确定的场合也有。例如，因为组织许可方面的因素，明确了数据库必须使用DB2，这种情况下作为“设计限制（Design Constraints）”进行描述。

　　重要的是尽量减少设计上的限制。那样，开发者只在最小限度的限制下能够实现必要的功能、设计出满足性能和可靠性的系统。

　　需求的详细分类

　　关于软件需求之前了解的情况，使用一句话来概括也会有多种。特别是可以按如下所示分为3种。

　　1)功能需求

　　2)非功能需求

　　3)设计限制

　　另外，如图3所示通常取出Functionality（功能性）、Usability（易用性）、Reliability（可靠性）、Performance（性能）、Supportability（易支持性）的开头字母以FURPS+形式来分类。FURPS+中最后的+表示不包含在FURPS中的设计方面的限制。该FURPS+用上述3种分类来说的话，各自相当于F是功能需求、URPS是非功能需求、+是设计限制。

　　根据上述形式进行分类，形成识别需求时和评价对需求的理解时的检验一览表，可以防止遗漏和不完整性。

　　软件非功能需求

　　到前一节为止我们了解了所说的“软件需求”就是把系统在详细基准下定义的需求，从黑匣子的观点来描述系统能力的需求。另外软件需求可以用FURPS+方式分类。但是对于开发能够让客户满意的系统不仅仅是软件需求，掌握利害关系者的需求也是非常重要的。（利害关系者：拥有与项目有相关利害关系的人、特别是系统的用户被列举为重要的利害关系者）

　　众所周知，为了有效地执行需求管理，作为详细标准需求的“软件需求”以外也作为需求来掌握，这一事项在经验上是很有效的。也就是说，把需求的语言对象不仅仅是系统详细定义的“软件需求”，也扩大到了利害关系者的“原始需求(Needs)”。并且另外一点，作为比软件需求抽象标准更高的需求，把“功能特性(Features)”也作为需求来掌握。有点麻烦但是倒入“需求类型”这一概念，其类型之一包括“原始需求”、“功能特性”，“软件需求”。由于功能特性比软件需求的抽象度要高，所以如果利用功能特性的话，就能很容易地把握系统整体，也就能轻松地管理开发范围。

　　软件非功能需求

　　那样的话，如图4所示可以把原始需求、功能特性和软件需求在3段的金字塔状中按照每个需求类型进行体系化描述。以订单管理业务的应用程序为例，如图5所示按照各自的需求类型分别描述需求样本。