需求分析主要流程.doc

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