需求开发过程.doc

需求开发过程Version 1.2Document Lending Record Name of Document：Signature of Borrower：Date of lending：Instructions of Principal of Document:Date:Date of Repayment：Signature of Document controller:需求开发过程Version 1.2文档名称：需求开发过程修订历史记录日期版本号修改说明修改人核准人目录1目的42范围43术语、缩写词44职责45过程概述55.1简要说明55.2流程图55.3规程清单56过程规范56.1需求调查准备56.2需求收集66.3需求分析76.4编写SRS76.5需求确认87输出结果和记录98裁剪指南99附录10需求开发过程1 目的需求开发是通过调查与分析活动，有效地获取用户的需求，并对需求进行准确、清晰地描述的过程。需求开发的目的是定义系统的边界，对功能、非功能需求进行清晰地描述，使涉众(客户、最终用户等)和项目组对所开发的内容达成一致。2 范围需求开发过程包括下面几个阶段：n 需求调查阶段：(1) 准备。(2) 收集需求。n 需求分析阶段：(1) 分析。n 需求定义阶段：(1) 编写SRS。n 需求确认阶段：(1) 评审SRS。(2) 获得用户最终对SRS的签字确认。(3) 编写测试用例对SRS进行验证。3 术语、缩写词需求用户所需要的并能触发一个程序或系统开发工作的说明（Jones 1994）；或从系统外部能发现系统所具有的满足于用户的特点、功能及属性等（Alan Davis 1993）。需求工程所有与需求相关的活动统称为需求工程。需求开发需求收集、评价、文档化等活动，一般分为：需求调查、需求分析、需求定义和需求验证四个阶段。需求确认指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。SRS软件需求规格说明书。4 职责系统分析员负责收集和分析需求，编写需求文档。项目经理（1） 负责安排系统分析员进行需求开发活动。（2）负责组织对需求文档如用户需求说明书和软件需求规格说明书进行评审。（3）作为开发方负责人和客户对需求文档作书面承诺，使之具有商业合同效果。软件测试人员负责根据SRS编写测试用例。负责验证软件需求规格说明书的可测试性。客户、最终用户负责向系统分析员提出需求。5 过程概述5.1 简要说明需求开发过程的任务是收集需求、分析需求，撰写需求文档（包括用户需求说明书、软件需求规格说明书）等。目的是在客户与项目组之间建立一个契约，为后续的开发活动奠定基础。在需求收集、需求分析、编写SRS几个阶段之间可能存在迭代的情况，逐步地细化需求。5.2 流程图5.3 规程清单需求管理过程包含5个规程：需求调查准备、需求收集、需求分析、编写SRS、需求确认。n 需求调查准备为进行有效的需求调查做必要的准备。n 需求收集利用各种调查手段，获取用户的需求。n 需求分析包括提炼、分析和仔细审查已经收集到的需求，进一步确认需求。n 编写SRS利用统一的风格，把调查与分析后的需求编写成SRS。n 需求确认对SRS进行验证及评审。6 过程规范6.1 需求调查准备目的：为进行有效的需求调查作必要准备。Entry Criteria1项目经理下达需求开发任务书给系统分析员。Inputs1需求开发任务书2相关资料，如合同、技术协议等3如果是增强型项目，要提供以往的需求分析文档、测试用例、用户手册等资料以及系统的缺陷列表Steps1系统分析员在开始需求调查之前要做好以下准备工作：n 阅读有关技术或业务的背景材料，接受需求调查培训。n 熟悉客户的工作方法和使用的工具。n 标识信息收集方法。n 准备获取信息的问题清单。n 标识用户组或要拜访的人。n 定义需求规范标准。n 制定需求调查计划，并请客户审核该计划。Outputs1问题清单2需求调查计划Exit Criteria1需求调查计划已经制定，并获得客户同意。6.2 需求收集目的：利用各种调查手段，获取用户的需求。Entry Criteria1需求调查计划已经制定，并获得客户同意。Inputs1需求开发任务书2问题清单3需求调查计划4所有其他相关资料Steps1系统分析员建立系统的目的和范围：n 确定用户群（即确定产品所期望的用户类）。n 获取每个用户类的需求。n 了解实际用户任务和目标以及这些任务所支持的业务目标。2系统分析员分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。3系统分析员收集功能性需求：n 识别业务活动（events）。n 识别每个业务活动的输入和输出。n 确定输入和输出之间的关系。n 确定这些活动之间的过程关系。4系统分析员收集关于外部接口的信息。5系统分析员收集操作的环境需求。6系统分析员收集性能需求。7系统分析员收集标准需求。8系统分析员收集特殊用户需求。9系统分析员收集需求约束。10系统分析员编写用户需求说明书初稿。11客户对用户需求说明书进行签字确认。Outputs1用户需求说明书Exit Criteria1用户需求说明书完成，客户已经签字确认。6.3 需求分析目的： 提炼、分析和仔细审查已收集到的需求，以确保所有的涉众都明白其含义并找出其中的错误、遗漏或其他不足的地方，从而开发出高质量和具体的需求。Entry Criteria1用户需求说明书完成，用户已经签字确认。Inputs1用户需求说明书2其他相关文档Steps1系统分析员根据输入文档，开始进行分析工作。2分析出系统的参与者汇总模型。3绘制出顶层用例图，明确系统的参与者，与系统交互的其他系统，它们之间的关联，从而定义出系统的边界。4创建用户接口原型（如果需要）。当需求不能确认时，利用一个简单的原型对改需求进行形象化的表示，以尽快取得一致。5确定需求的优先级别和重要程度，以明确那些用户最为关注的特征。6建立需求的动态模型。利用状态图、活动图、顺序图等手段对模型的动态方面进行建模。7建立需求的对象模型。利用类图对需求中的对象以及它们之间的关系进行建模。8创建数据字典。对需求中的术语进行定义。Outputs1用户需求说明书改进版2需求分析产生的相关文档Exit Criteria1系统分析员完成了各种分析工作。6.4 编写SRS目的： 系统分析员根据前期调查和分析的结果编写SRS。Entry Criteria1系统分析员完成了各种分析工作。Inputs1用户需求说明书2需求分析相关资料3其他相关资料Steps1系统分析员整理以前收集分析的各种文档,为编写SRS做准备。2系统分析员选用SRS模板。3编写SRS.n 按照模板整理以前的文档。n 指明需求的来源。使涉众明白SRS中为何提供这些功能。n 为每项需求（包括功能需求与非功能性需求）编上标号,使得需求能够被跟踪。Outputs1软件需求规格说明书Exit Criteria1软件需求规格说明书已完成6.5 需求确认目的：是开发方和客户对需求文档如用户需求说明书和软件需求规格说明书进行评审，达成一致的理解，并做出书面承诺。Entry Criteria1需求文档如用户需求说明书和软件需求规格说明书已经完成。Inputs1需求文档如用户需求说明书和软件需求规格说明书。Steps1项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。2项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。同行专家人员组成参考评审人员组成指南，其中要包括测试人员，他们负责对需求的可测试性（Testability）进行验证。在评审的时候应该使用需求评审检查表3当需求文档通过正式的评审之后，系统分析员准备需求确认表。4项目经理和客户对需求文档进行确认，填写需求确认表，并在确认意见和需求承诺上签字。5配置管理员将已经确认的用户需求说明书和软件需求规格说明书纳入配置管理；并建立软件需求基线。6、项目经理在软件需求确认后建立需求跟踪矩阵。n 正向跟踪。用于检查需求文档中的每个需求是否能在后续工作成果中找到对应点。n 逆向跟踪。用于检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处； n 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立和维护需求跟踪矩阵。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间可能存在“一对一”、“多对多”的关系。n 当一个需求矩阵表不便于使用时，可按列拆分成多个需求矩阵表。7、配置管理员将需求追踪矩阵纳入配置管理库。8、项目经理在软件需求确认后或者需求已经足够稳定之后，通知软件测试人员编写系统测试相关文档。n 软件测试人员以SRS为依据编写测试文档，要同时考虑功能性需求与非功能性需求。n 编写系统测试计划。n 编写系统测试大纲。n 编写系统测试用例。n 从测试用例追溯回功能需求以确保没有需求被疏忽。n 使用测试用例来验证需求模型的正确性。9、测试文档完成之后，项目经理组织对文档进行同行评审。评审参加人员参见评审人员组成指南。10、评审通过并修正完评审中发现的问题后，配置管理人员将测试文档纳入配置管理库。Outputs1需求评审记录2需求确认表3开发方和客户做出的书面的需求承诺4需求追踪矩阵5系统测试计划6系统测试大纲7系统测试用例8测试文档评审记录Exit Criteria1需求文档通过了正式评审，并且获得了开发方和客户的书面承诺。2需求追踪矩阵编写完成。3测试文档编写完成并通过评审。7 输出结果和记录需求开发过程中产生的主要文档有：用户需求说明书项目实施期间由项目经理保管，项目结束后由业务部门保管。软件需求规格说明书项目实施期间由项目经理保管，项目结束后由业务部门保管。需求评审记录项目实施期间由项目经理保管，项目结束后由业务部门保管。需求确认表项目实施期间由项目经理保管，项目结束后由业务部门保管。需求承诺项目实施期间由项目经理保管，项目结束后由业务部门保管。问题清单项目实施期间由项目经理保管，项目结束后由业务部门保管。需求追踪矩阵项目实施期间由项目经理保管，项目结束后由业务部门保管。系统测试计划项目实施期间由项目经理保管，项目结束后由业务部门保管。系统测试大纲项目实施期间由项目经理保管，项目结束后由业务部门保管。系统测试用例项目实施期间由项目经理保管，项目结束后由业务部门保管。测试文档评审记录项目实施期间由项目经理保管，项目结束后由业务部门保管。8 裁剪指南1. 在需求确认阶段是否编写测试用例文档，要根据项目情况，所选生命周期模型等因素，由项目经理在开发计划中指定。2. 测试文档的编写与评审可以超越需求获取阶段，也就是说，在需求文档评审之后，就可以进入下一个阶段，而测试文档的编写与评审可以与下面阶段平行进行，这样可以缩短时间，提高效率，但是也可能会使需求中的问题不能及早发现，项目经理要根据实际情况进行判断与选择。3. 对于比较简单或成熟的项目，用户需求说明书与软件需求规格说明书可以合并为一个，即软件需求规格说明书。具体处理由项目经理在开发计划中指定。4. 用户需求说明书与软件需求规格说明书等文档的模板，应尽量从公司规定的模板中选