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

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

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

为什么要进行需求管理？

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

项目目标

在期限内及预算内，开发满足客户真实需求的高品质的产品（在此所说的产品是指以软件为中心的产品，包含企业业务应用程序、嵌入式软件以及包装产品）

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

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

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

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

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

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

需求（Requirement）

应该满足系统的样态和能力

需求管理（Requirement Management）

挖掘需求、体系以及文档化的系统研究

关于能够产生变更的需求、形成客户和开发团队之间的协议，为了维护系统研究

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

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

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

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

需求管理不简单

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

◎ “很难发掘需求”

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

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

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

◎ “难以将需求文档化”

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

◎ “难以追加需求变更”

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

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