需求分析主要流程.pdf

。 1.1 主要流程 需求分析阶段的主要活动围绕需求开发进行， 包括制定及修改需求开发计划、 开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。 1.1.1 制 定及修改需求开发计划 包括建立需求团队的组织并授权、 对需求分析阶段的 WBS进行分解、 协商并 制定调查分析以及评审计划、 评估工作量等等方面的内容， 其目的是保证各项活 动有序、可控的进行。 1.1.2 需求调查以及分析的过程 主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。 需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调 查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并 识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。 1.1.3 需求验证环节 主要通过原型（ Prototype ）、POC（ProofofConcept ）、用例（ UseCase）或 简单的功能列表的方式同客户、 用户沟通逐步将业务需求、 用户需求等转化为软 件系统需求。 （1）原型（Prototype ）模拟最终软件的屏幕显示，这样用户可以看到最终 软件将是什么样， 有些原型可以模拟实际的操作， 对关键的输入输出数据也可以 一定程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 （2 ）POC（ProofOfConcept ）原意是“为观点提供证据” 。对于关键的技术 或者业务模型，论证需求、设计的可实施性 , 评估和确认概念设计方案， POC的 评价可能引起需求和设计的调整。 一般来说， 进行 POC的条件： 1. 论证业务中涉 及到的模型或者算法的可行性。 2. 论证技术模型实现的可行性、成本等。 （3 ）用例（ UseCase）：对（软件）系统如何反应外界请求的描述，是一种 通过用户的使用场景来获取需求的技术。 每个用例提供了一个或多个场景， 该场 。 1 。 景说明了系统是如何同最终用户或其它系统交互 (interact) 的，也就是谁可以用 系统做什么，从而获得一个明确的业务目标。 1.1.4 需求规则说明 (SRS)制作 通过需求调查和初步的需求验证后， 可以建立需求制作的准则， 包括确认需 求规则说明 (SRS)的内容、制作方法、制作工具、质量标准等等。根据需求制作 的准则制作需求规格说明（ SRS）, 好的需求规格说明（ SRS）应该遵循正确、无 歧义、完备、 一致、分级 （重要性或稳定性）、可验证、 可修改、可追踪的原则。 1.1.5 需求确认 通过组织各级评审对需求分析阶段的产物， 尤其最重要的结果产物需求规格 说明（ SRS）进行确认，以确保相关人员理解一致。从评审方法来说，可以根据 情况分为需求开发组组内评审、客户外部评审、关键关系人评审等等。 需求分析的流程往往因项目规模、 作业人员、 系统类型差异很大， 因此必须 根据实际的情况合理的裁减，以下举例几种不同情况下的具体流程： 案例一：简明的需求开发的流程 第 1 步: 确定实现的目的、 目标，基本业务需求、 业务定义以及相关的评审。 从达到目的、目标的角度，重新评审业务定义，总结业务需求。 （确认客户 实施的