需求定义的进行方式 | 需求定义和要件定义有什么区别？

需求定义和要件定义是在IT项目中至关重要的步骤，尽管它们的词汇相似，但它们在意义和作用上有显著区别。简单来说，需求定义是由委托方负责执行和创建的过程，其目标是“明确客户对系统功能和目标的需求”。

相反，要件定义是由承包方或供应商执行和创建的过程，旨在“明确实现客户期望系统所需的具体要求和相关成本”。

这两个步骤都属于系统引入的上游阶段，如果在这个阶段存在问题，将对后续的所有开发过程产生不良影响。因此，我们必须认识到这些步骤需要高度的重视和严谨处理。

系统开发的基本流程

系统开发过程

在进行业务改善、业务革新（BPR：业务流程再造）或数字化转型（DX）时，系统的引入通常按照V型模型进行。如下图所示，软件开发从“需求定义”开始，接着是“要件定义”，然后经过“设计”、“实施/开发”和“测试阶段”，最终进入市场。

与建筑房屋一样，软件开发的所有阶段都相互紧密联系，向前推进。因此，一旦到达下游阶段，纠正轨迹就变得困难。因此，如果在起点的“需求定义”阶段存在缺陷，可能导致与期望的形象大幅偏离，甚至需要重新开始。这样一来，可能导致预定的发布时间延迟，成本大幅增加，甚至在某些情况下损害品牌形象。

从需求定义到要件定义的流程

在进行系统引入时，首先需要整理对系统的需求，这与建筑建筑物一样，所有的软件开发阶段都相互紧密联系着，推进着。尽管以下是参考示例，但需求可能包括以下内容：

• 通过销售支持系统（SFA：Sales Force Automation）管理销售预算，确认每个案件的谈判进展，实现信息的统一管理。
• 通过客户关系管理系统（CRM：Customer Relationship Management），统一管理潜在客户和现有客户的信息，以便高效地进行管理。
• 引入供应链管理（SCM：Supply Chain Management），优化从生产到销售的整个过程，以最小的资源发挥最大的性能。

如果不清楚为何引入系统，希望获得什么样的好处，实际上系统可能会嵌入不必要的功能，导致额外的成本，并可能带来与预期不符的不幸结果。

发起方编写了明确系统需求的文件称为"需求定义书"，而SIer和系统供应商则根据需求定义书创建"提案请求书（RFP：Request For Proposal）"。

如果需求定义书存在错误或遗漏，系统设计将以不完整的状态进行，因此发起方的负责人必须仔细了解当前状况和系统引入后的展望。

然而，有不少企业的负责人发现很难可视化当前分析和系统引入所带来的好处。这是因为随着企业规模的扩大，业务分化越来越多，难以清晰地了解到末端的情况，又或者在引入系统时，无法具体地想象会发生什么变化。

要紧跟IT的发展趋势，了解市场上有哪些工具、竞争对手是如何进行IT化的，自己公司应该如何实现最佳的IT化，这是一项不容易的任务。如果仅仅因为品牌知名度决定引入系统，或者仅仅因为同行公司在进行IT化，就盲目效仿，最终可能导致实际使用后发现对公司来说毫无用处，这是很有可能发生的结果。

为了防止这种情况的发生，利用拥有丰富行业知识的顾问可能是一种有效的手段。

一旦需求定义确定，系统供应商将根据此创建"提案请求书（RFP：Request For Proposal）"。尽管在创建RFP时并不一定要准备需求定义书，但为了使发起方和供应商达成共识，创建它仍然是非常有益的。

一旦RFP创建完成，并得到发起方的同意，随后将创建需求定义书。供应商将仔细审查满足发起方需求所需的系统要求，包括技术上是否可行，需要什么样的功能和性能等方面，并将这些内容总结到需求定义书中。如果需求定义书没有问题，双方达成一致后，就会继续进行“基本设计”及后续阶段的工作。

需求定义中需要注意的关键点

项目目标的明确

在进行IT化和数字化转型（DX）时，首先必须明确“为什么要引入系统”的目标。在大多数情况下，系统引入是为了实现业务改善和效率提高，但必须明确改善和提高效率的标准是什么，以及在引入前后的差异。

从现状分析中推导出理想状态的"As-Is/To-Be分析"

在业务改善和效率提高的项目中，经常使用一种称为"As-Is/To-Be分析"的方法。这种方法通过绘制当前（As-Is）业务流程图，并通过确定问题（瓶颈）的部分，推导出期望的（To-Be）分析。通过这种分析，可以可视化需要保持和需要改善的方面，并识别出系统所需的要求（功能、性能）。

考虑QCD：品质（Quality）、费用（Cost）、交付（Delivery）的平衡

在推进项目时，考虑到QCD的平衡是很重要的。这个QCD（品质、费用、交付）形成了一个三角关系，例如：

• 降低成本＞提高利润率，但品质下降＞增加返工＞导致延误
• 提高品质＞提高客户满意度，但成本增加＞降低利润率

由于问题可能在某个地方发生，相互之间会相互影响，因此必须在了解各自情况的同时，找到并保持适当的平衡。

需求定义的进行方式｜明确目标和要点

创建项目宪章

在着手需求定义时，首先要创建“项目宪章”。项目宪章是在项目启动时创建的重要文件，用于确立项目的正当性，并记录基本信息，如项目的目标、范围、目标、利益相关者等。以下是关于项目宪章的一些重要要点：

◆ 目标和正当性

明确项目的目标和正当性。从业务角度来看，解释项目为何执行，表明其战略上的重要性。它还包括项目的背景、动机、问题陈述等。

◆ 项目范围

通过定义项目的范围，明确项目包含和不包含的内容。这包括范围的边界、主要产出、交付期限、预算、资源限制等。

◆ 目标和产出

明确项目的目标和主要产出。记录区分成败的标准，特定产出的期望要求，质量标准等。

◆ 项目利益相关者

确定与项目有关的主要利益相关者，并清晰明确各自的角色和责任。包括发起人、客户、项目经理、团队成员等的参与。

◆ 批准和权限

项目宪章是获得项目批准者或赞助商批准的有效手段。明确同意项目范围和目标，并记录批准项目启动的人。

需求定义书的目录

正如前文所述，需求定义是整个项目的起点，因此如果在这个阶段疏忽，就像河上游的混浊流水一样，会对整个项目的成败产生重大影响。

为了防止这种情况的发生，至少在需求定义书中必须记录以下项目：

1. 利益相关者（Stakeholder）的确定
   • 确定参与项目的利益相关者，了解他们的需求和要求。使用面谈、听证会、研讨会等沟通手段收集相关方的意见和期望。
2. 业务目的和目标的明确化
   • 明确项目的业务目的和目标。定义项目为何执行以及能够获得什么样的价值和利益。
3. 需求的确定
   • 确定与项目相关的需求。梳理利益相关者的需求、期望以及业务上的要求，并进行文档化。
4. 需求的整理和整合性的确保
   • 整理已确定的需求，评估其相关性和优先级。识别重复或相互矛盾的需求，并找到解决方案。
5. 需求的文档化
   • 将已确定的需求文档化为具体的要求。要求必须清晰、独特、可测量和可验证。使用需求定义书或需求规格书等文档进行文档化。
6. 需求的审查和批准
   • 让相关方审查已文档化的需求，并收集反馈。确认需求的准确性和完整性，获得相关方的批准。
7. 变更管理
   • 随着项目的推进，需求和要求可能会发生变化。接受变更请求，并执行适当的变更管理过程。

需求定义是项目成功的重要步骤，需要与利益相关者保持良好的沟通，并清晰地文档化需求。在保持灵活性和适应性的同时，正确识别并与利益相关者分享和达成共识是至关重要的。

需求定义与要件定义的关联性

业务需求―业务要件/功能需求―功能要件｜各项目的关联

要件定义是基于需求定义进行的一个阶段。因此，双方的各项目都与明确项目需求并定义具体要件密切相关。

◆ 背景・目的

在需求定义阶段，我们明确项目的背景和目的。这有助于在需求规定阶段更容易理解需要什么样的功能和规格。

◆ 业务需求―业务规定

在需求定义阶段，我们会明确项目所涉及的业务流程和需求。在规定阶段，我们将这些业务需求具体化为系统功能和操作。从业务需求衍生出的功能规定会在规定阶段被明确定义。

为了确保相关性，特别是明确业务的过程，通常会通过绘制“业务流程”图来可视化业务并进行梳理。

◆ 功能需求―功能规定

功能规定是关于在规定阶段明确的具体系统或产品功能的要求。这是基于需求定义中明确定义的业务需求。在功能规定中，将明确系统提供的操作、数据处理、用户界面等。

◆ 非功能性需求

非功能性需求是除了功能性需求以外的要求。在需求定义中，有关系统或产品的质量要求和约束条件将被明确规定。在规定阶段，需要具体化这些非功能性需求，并明确系统的性能、安全性、可靠性等方面的要求。

尽管这是项目中涉及最多项目的阶段之一，但由于独立行政法人信息处理推进机构（IPA）规定了“非功能性需求等级”，通过与其对比，可以避免项目遗漏。IPA规定的“非功能性需求等级”主要包括以下项目。

◆ 可用性

可用性表示系统正常运行且可用的时间比例。具有高可用性的系统可以最小化对用户的中断和故障的影响。

◆ 性能和可扩展性

性能指系统在处理速度、响应时间、资源使用等方面的能力。

可扩展性是指系统能够灵活应对未来需求或规模变化的能力。

◆ 运维和可维护性

运维和可维护性表示系统运行和维护工作的便捷性和效率。具有高运维性的系统易于管理和监控，而具有高可维护性的系统在进行更改或修复时的负担较小。

◆ 迁移性

迁移性表示系统或数据迁移工作的便捷性和安全性程度。具有高迁移性的系统可以实现平稳的迁移，当需要改变系统或平台、迁移数据等时，可以更加顺利。

◆ 安全性

安全性表示系统或数据的保护程度。这包括适当的访问控制、数据机密性和应对安全漏洞等。确保安全的系统有助于保护机密信息和隐私。

◆ 环境和生态

环境和生态涉及系统对环境的影响以及可持续性。具有考虑环境的系统包括能源效率、可循环性、减少废弃物等，有助于为可持续社会做出贡献。

这些项目是非功能性需求的一部分，对于系统或软件满足需求至关重要。具体的需求水平和重要性将根据项目和利益相关者的需求详细定义。

如果在“需求定义―规定阶段”存在缺陷，将导致在后续开发阶段中遗漏问题，可能在系统发布后出现故障。当产品或服务在市场上发布后出现问题时，修复将需要巨大的成本，品牌形象受损且社会信用也将受到严重影响。

总结・需求定义的推进指南

需求定义和需求规定紧密合作，用于识别客户需求并明确项目目标和需求。基于需求定义明确的需求，需求规定将规定具体的功能需求和非功能性需求。通过相互补充，需求定义和需求规定为整理项目范围和需求做出了贡献。