无论是PMI的PMP管理方式，还是微软的MSF管理方式，方法论虽然不同，但都认为需求分析过程是项目执行过程中的首要工作。需求的准确、边界的明晰直接决定了项目的成败。
以PMP管理为例，需求分析涉及项目范围管理和干系人管理，项目范围管理是对项目包括什么与不应该包括什么进行定义和控制的过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。
一个好的需求文档规范可以帮助我们去定义、约束需求的采集、分析及定义。
需求文档一级目录一般有前言或背景、现状或存在问题、需求或愿景目标、环境及约束条件，这些主要从大面上约束了需求范围、需求环境、约束条件，更多地是从战略层面去描述、定义目标和目的，框定边界；但更为核心是按业务场景（UML体系中也成其为用况）的具体描述；如下图中蓝框部分就是针对一具体业务场景分“业务功能概述”、“业务流程（图）”、“业务流程的详细描述”、“报表单据及接口”、“适用需求及补充说明”五部分，去详细定义该业务场景的内核及边界。
if !supportLists]图 1 [endif]需求文档目录示意
五部分可依据实际项目及具体场景情况适当略减。
业务功能概述具体描述业务场景，以简约的语言定义描述业务场景，同时附表说明业务场景所含相关主体（执行或相关部门、本场景与其他业务场景间的关系、业务控制点等）的内容，特别是业务控制点将是后续定义业务规范、编制业务管理手册的基础。
[if !supportLists]图 2 [endif]业务功能描述示意
业务流程（图）、业务流程的详细描述是以统一规范的流程图形式以及详细文字描述对应业务场景下谁（Who）、依据什么、因为什么(Why)、在何时（When）、于何地（Where）、对谁、怎么做（How）的、具体什么事情（What）。详尽清晰的业务表述可使程序逻辑、流程清晰，操作流程明晰。这些将是后续编制系统操作说明的最基础、最准确的材料。
报表单据及接口，是将需求采集过程中收集的单、账、表以及与其他系统的接口关系进行详细描述；描述其用途、样式、数据项和来源、以及其流转过程。随着业务数字化转型的推进，此部分的要求将会更高、更细化（如详细描述“人、机、料、法、环”），会弱化的可能仅仅是纸质输出时的样式定义。
下图示意了一个单据的样式，详细具体表述了样式、规格、应用场景及单据流转。
[if !supportLists]图 3 [endif]单据示意
适用需求及补充说明，表述的是该场景复用情况，对应的也就是业务功能（或者称其为业务组件）的复用场景，以便集成应用、优化业务及功能架构。
可以看出，“业务功能概述、业务流程（图）、业务流程的详细描述、报表单据及接口、适用需求及补充说明”五部分，是对同一事物从不同视角、站在不同立足点去描述，多维、形象地将一个业务场景绘制成一个丰富、立体的形象。有点像“盲人摸象”，将各个不同视角平面化后（“盲人”）的表述，去组合成一头 “大象”。这对需求分析人员的业务素质、设计能力均有较高要求；心中有“大象”后，才能按“多视图”方法清晰描述；否则各视角的表述仅能摊在平面上，难以形成立体的具象展现。
上述从五个视角去表述一个业务场景，是一种类似“三视图”的“方法论”，可以方便大家去表述业务场景；但实际在划分场景、定义业务功能时已经做好了业务架构、功能架构的设计，否则各业务场景也难形成更为宏观、立体的业务体系。
回到需求分析或者称其为项目范围管理和干系人管理，笔者认为无论项目大小，需求分析都是“将抽象的战略目标变成可操作的战术步骤”的过程；此过程中需要分析人员（或者业务架构师）与关键干系人平等互动，达成战略认知、战术认同的一致，形成一个“共同的理解”，要说清业务实体（是什么业务）、阐明服务对象（谁来用、怎么用），这样才能完成一个一致认可、内涵明确、边界清晰、内容丰富、形式规范的需求说明文档。
网友评论