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

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

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

　　为什么要进行需求管理？

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

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

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

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

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

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

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

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

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

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

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

　　需求管理不简单

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