需求分析中的项目目标与范围(项目需求业务目标产品)

reddish

项目目标和范围文档对于确保所有项目参与者对项目的共同理解与一致方向至关重要。

我的同事成在她的公司中功地实施了对软件需求文档 [1]的正式评审机制。
她注意到，在评审会议上出现的许多争议和问题都源于项目范围不清晰或参与者对项目目标理解不一致。
专家们在判断哪些功能需求应纳入软件需求规格说明时，往往由于缺乏对项目整体目标和范围的共识而难以达成一致。

正如之前所述，业务需求是需求层次结构中的顶层抽象概念，它们为软件系统设定了项目愿景、边界和预期成果。
软件功能需求应当基于用户需求制定，并确保与业务需求所设定的目标相吻合。
那些与实现项目业务目标无关甚至产生负面影响的需求应予以剔除。
尽管一个项目可能包含非软件相关的部分（如硬件采购、安装、维护或市场推广等），但在讨论中我们仅关注与软件产品直接相关的业务需求。

当一个项目缺乏明确的规划和有效的沟通渠道时，情况将变得尤为糟糕。
若参与者对项目目标和优先级有不同的认识，则可能导致意见冲突、效率低下。
如果项目风险承担者对产品需要满足的业务需求和带来的收益不能形成统一认识，那么需求就无法稳定下来。
拥有一个清晰、集中定义的项目目标和范围至关重要，特别是在地理位置分散的团队中，良好的沟通协作才能保证项目的顺利进行。

反复出现在业务需求文档中而后又被删除、再次加入的功能特性，表明该业务需求尚未得到充分定义。
在细化具体功能需求之前，必须先解决好项目的大局观和范围界定问题。
对范围和限制条件的明确陈述将极大地帮助探讨提议的特性并确保最终产品的合理发布。
同时，一份明确定义了项目目标和范围的文档还可作为评估需求变更合理性的重要参考依据。

项目目标和范围文档对于确保所有项目参与者对项目的共同理解与一致方向至关重要。
项目目标勾勒出产品在理想状态下的全貌，描述了产品涉及的所有核心领域及其最终功能特征。
而项目范围则明确指出产品所涵盖的功能特性以及那些不应包含在内的部分，并确定了项目的边界和限制条件。

业务需求作为项目目标和范围的核心内容，在项目启动前必须形成正式文档。
开发商业软件的公司通常会编写市场需求文档，这份文档不仅涵盖了项目目标与范围，还深入探讨了目标市场的需求及商业环境因素。
这些文档通常由项目发起人（sponsor）、客户、高级管理层、产品构想者（visionary）如产品经理和市场团队等关键角色共同制定，因为他们对为何开展项目以及项目能为业务和客户创造何种价值有深刻的认识。

来自不同渠道的业务需求可能产生冲突。
例如，在设计一个嵌入式售货亭管理系统的场景中，开发者、零售店业主和终端消费者都有各自不同的业务目标。
开发者可能希望通过销售售货亭系统本身、利用该软件促进商品销售、吸引顾客兴趣并重塑与客户的合作关系；而零售商关注的是通过使用售货亭软件获得收益、吸引更多客户进店消费以及节省人工成本；客户则期望得到简单易用且性能良好的系统体验。
这三方面的目标、限制和费用考虑可能导致业务需求间的矛盾，因此需要在制定售货亭管理系统软件需求规格说明书之前解决这些冲突。

此外，业务需求还能用于指导使用实例及其相关功能需求的优先级设置。
例如，从最大化售货亭软件产生的经济效益出发，可能意味着优先实现与提升销售业绩或改善客户服务直接相关的功能，而非侧重于仅吸引少数用户的次要功能。

业务需求不仅决定了应用程序所能支持的业务任务（即使用实例）的广度（应用宽度），也影响到对每个使用实例支持的程度和深度。
支持的深度可以是从简单的功能实现到具备大量辅助功能的高度自动化操作。
对于每个使用实例，都需要确定其实施的宽度和深度，并详细记录在文档中。

当业务需求引导你识别出超出当前应用范围的新使用实例时，实际上是在定义产品的应用宽度。
同时，业务需求还能帮助决策者决定哪些使用实例应具有强大且全面的功能实现，哪些只需基本或初步的实现。
通过这种方式，业务需求在整个软件开发生命周期中扮演着关键的指导角色，确保项目团队能够准确地满足各利益相关方的期待和需求。

项目目标和范围文档作为项目的基石，将纷繁复杂的业务需求整合成一份精炼、全面的指导文件。
这份文档不仅阐述了项目的来龙去脉、核心目标和愿景，还明确了产品的功能边界、客户需求特性以及项目成功的关键要素等。
虽然篇幅通常控制在3-8页，但其内容详实度与完整性需根据具体项目特性和规模进行调整。

以下是一个示例性的项目目标和范围文档模板：

A. 业务需求

B. 项目视角与解决方案概述

C. 范围与局限性

D. 业务环境分析

E. 产品成功衡量标准

请注意，此模板仅供参考，实际应用时应依据项目实际情况灵活调整和完善文档内容，以确保其准确反映项目目标与业务需求。
同时，在编写过程中需与所有利益相关者密切沟通，确保各方对项目目标和范围有共同的理解和认同。

本模板的每个部分详细说明如下：

a. 业务需求 这部分概述了新产品对客户和产品开发商带来的核心价值。
根据不同的产品类型（如信息管理系统、商业软件包或系统捆绑软件），重点可能有所不同，但关键在于通过新产品的开发实现世界改进的信念。

a.1 背景 简述新产品的理论基础以及产品开发的历史背景和当前形势。

a.2 业务机遇 描述现有的市场机会、解决的业务问题及产品应用环境，对比分析现有解决方案并阐述建议产品如何具备竞争优势，明确只有该产品才能解决的问题，并展示其如何符合市场趋势和战略目标。

a.3 业务目标 量化并以可测量的方式总结产品预期带来的主要商业收益，侧重于给业务层面的价值。
这些目标涉及收入增长、成本节省等，并影响投资分析和交付日期。

a.4 客户或市场需求 列举典型客户需求，包括市场上现有产品无法满足的需求，并提供具体案例说明客户将如何使用产品。
确定产品运行所需的软硬件平台和高层次接口要求，列出需求列表以便进一步细化用户和功能需求。

a.5 提供给客户的价值 明确产品为客户带来的具体价值，如提高生产效率、节省成本、流程自动化、合规性增强、提升可用性和降低故障率等。

a.6 业务风险 评估与开发（或不开发）该产品相关的重大业务风险，如市场竞争、时间安排、用户接受度、实施难题或可能对业务产生的负面影响，并预测风险严重程度以及缓解措施。

b. 项目目标的解决方案 这一部分为系统提供长期视角，为软件开发生命周期中的决策提供上下文环境。
不应包含详细的职能需求和项目计划。

b.1 项目目标陈述 撰写一个简洁的项目目标声明，概括长远目标和开发新产品的原因。
声明应平衡不同客户群体的需求，并基于现实或预期的市场状况、企业框架、战略方向和资源限制。

b.2 主要特性 列出新产品的主要特性和用户性能指标，强调与现有产品和竞争对手产品的区别，来源于用户需求和功能需求。

b.3 假设和依赖环境 记录在构思项目和编写文档过程中所做的所有假设，并加以解释，确保各方就基本假设达成共识。
同时，记录项目所依赖的关键技术、第三方供应商、合作伙伴和其他业务关系。

c. 范围和局限性 明确项目的范围和局限性，有助于设定各利益相关方的期望。
范围定义了解决方案的概念和适用领域，而局限性则指出了产品不包括的某些性能。
当客户提出超出项目范围的需求时，需要拒绝或重新考虑预算、计划和人力资源的分配。

c.1 首次发行的范围 概述首次发布的产品所具备的功能，关注那些能为不同客户群体带来最大价值、性价比高且易于普及的特性。

c.2 随后发行的范围 规划后续版本中将延期开发的主要特性及其预计发布时间。

c.3 局限性和专用性 明确定义哪些特性包含在内，哪些不在产品范围内，以此来管理范围设定和客户期望。

d. 业务环境 此部分概述项目的业务背景，包括主要客户分类概览和项目管理优先级。

d.1 客户概貌 描述不同类型的客户特点、目标市场部门特征，以及每种客户类型从产品中获得的主要利益、态度、关注的关键特性、成功使用的可能性以及适应客户的任何限制。

d.2 项目的优先级 确立项目的优先级，使所有参与者聚焦于共同目标。
可以考虑软件项目的五个方面（性能、质量、计划、成本和人员），并将其对应到驱动因素、约束条件或自由度。

e. 产品成功的因素 明确产品成功的定义和衡量标准，并指出对产品成功有显著影响的因素，包括组织内部可控因素和外部因素。
如果可行，建立量化的评价标准，如市场份额、销售额、客户满意度、交易处理量和准确性等，用于评估是否达到业务目标。

软件项目范围的描述为我们正在开发的物流信息系统与外部环境之间建立了明确的边界，关联图通过描绘系统与外界之间的交互来界定这一边界。
关联图标识了与系统相互作用的外部实体及其间的数据流和实物物流关系。
我们将关联图视为从结构化分析中提炼出的数据流图的顶层抽象，并将其纳入项目目标与范围文档或软件需求规范文档中。

以“物流货物追踪系统”为例，整个系统可以简化为一个宏观的业务流程闭环，在此背景下，关联图并不详细展示系统的内部处理逻辑和具体数据细节。
关联图中的流可以用信息（如“货物配送请求”）或物理对象（如“货物包裹”）来体现。
矩形图形所代表的端点可能包括用户角色（如“仓库管理员”）、组织机构（如“运输部门”）或其他相关的信息系统（如“库存管理系统”）。

在该物流货物追踪系统的关联图中，可能会将货物供应商作为一个关键的端点进行描述。
值得注意的是，公司通常会向供应商发送货物采购订单，随后接收来自供应商的包含货物及发票的运输包裹，而供应商则会接收到公司的支付款项——支票。
然而，这些采购、收货以及付款的过程虽然与物流货物追踪系统紧密相关，但它们实际发生于系统功能范围之外，是采购部门和入库管理日常工作的组成部分。
关联图清晰地显示，该系统并不直接参与与供应商订货、收货验收或支付结算的操作。

尽管某些端点在技术层面并未与规划中的物流信息系统直接集成，关联图仍能揭示与项目问题域息息相关的各端点间的关系。
因此，运用关联图旨在明确项目风险承担者之间的清晰、精确关系，而非追求构建绝对“正确”的关联模型。

在项目目标和范围文档中记录业务需求可以防止开发过程中范围的扩展，为项目提供有益的支持。
这些文档可以帮助你判断某个特性或需求是否适合放入项目中。
当有人提出新的需求或改变现有需求时，你需要先问自己一个问题：“这个需求是否包含在项目范围之内？”

有些建议可能完全超出了项目的范围，它们可能是好的方案，但只适用于其他项目或未来要发布的产品。
而另一些建议则明确地属于项目范围内。
如果这些建议与已经为特定产品制定的需求相比具有更高的优先级，那么这些新的且符合要求的需求就可以加入到项目中。
然而，在这种情况下，你需要权衡是否要推迟或取消其他已确定的需求或特性。

还有一种可能性是提出的新需求超出了项目范围，但这是一个非常有价值的方案。
此时，可以考虑修改项目范围以适应这一需求。
但需要注意的是，这可能需要修改项目目标和范围文档。
当调整项目范围时，需要重新商议计划预算、资源和进度安排，甚至可能需要更改开发人员（特别是在需要新的技术和技巧的情况下）。
理想情况下，原先的安排和资源能够合理地适应需求变更。
然而，在需求变更得到批准之前，你需要重新制定计划安排，除非你事先为需求变更留有余地。

范围扩展存在两个主要问题： 1) 所有工作都必须重新开始以适应变化。
2) 当项目范围扩大时，如果没有调整原先分配的资源和时间，项目进度可能会受到影响。

通过记录明确的业务需求，可以使项目按照计划顺利进行。
在市场或业务需求发生变化时，可以合理地调整项目范围的大小；当一些有影响力的人试图向受到诸多限制的项目添加更多特性时，可以合理地拒绝这些要求。

无论你的团队是正准备启动一个新项目，还是正在执行中，都请使用本文所提供的模板来编写详尽的项目目标与范围文档。
若开发团队成员对项目的边界和范围存在多种观点，则编制这份文档可能会面临挑战。
然而，务必从现在开始着手解决这一问题，确保项目范围清晰明确，而不是任由其模糊不清；否则，随着项目的推进，这个问题将会愈发棘手，增加不必要的复杂性。

同时，你还可以根据实际情况调整和完善此模板，使其更好地适应你们公司组织内部具体项目的独特需求和特点，从而有效指导项目进程，确保所有参与者在项目目标、目标和范围上达成共识。

本文同步发表在 软件需求探索的http://www.srs.pub/theory/xiang-mu-shi-tu-yu-fan-wei.html