需求开发管理规范及管理流程

《需求开发管理规范及管理流程》由会员分享，可在线阅读，更多相关《需求开发管理规范及管理流程（7页珍藏版）》请在金锄头文库上搜索。

1、需求开发管理规范及管理流程需求开发管理规范及管理流程1.1. 目的目的通过定义需求开发和管理过程，规范公司软件开发项目的需求开发和管理活动，提高 需求质量，从而提高软件生产率，降低开发成本，改进软件质量。 应调查用户的需求，通过需求分析工作将用户需求转化为软件需求，同时评审需求的 正确性，获得需求的承诺；应控制需求的变更，并确保项目计划、工作产品与需求的一致 性。2 2需求开发阶段的工作文件需求开发阶段的工作文件产品名称产品名称说明说明需求开发阶段计划描述需求开发阶段的人员、分工、时间、主要工作内容及必备条件。需求开发问题表现场调研需解决的问题需求开发实施日志记录任务执行情况现场调研访谈表现场

2、调研记录（包括需求阶段的会议记录、纪要）现场资料收集清单所有现场收集的资料清单需求规格说明书阶段性成果、描述需求的综合性报告需求变更申请单外部需求请求变更时申请，记录变更过程需求变更表在形成阶段性成果后编制的需求列表需求阶段资料汇编所有需求工作产品总编目3 3需求开发阶段工作流程需求开发阶段工作流程项目启动制定初步需求说明书形成需求调研问题表制订现场调研计划根据合同制定需求 开发阶段计划现场调研形成需求说明书N形成正式需求说明书Y确认YN确认NY完成需求调研问 题表完成Y形成新的问题表N形成原型系统确认维护需求变更表总结、资料汇编2.2. 入口准则入口准则项目立项、合同签定3.3. 出口准则出

3、口准则用户确认需求4.4. 输入输入用户的需求5.5. 输出输出1、软件需求规格说明书 2、需求变更表6.6. 主要步骤主要步骤6.1 需求获取需求获取1明确需求获取的信息。明确需求获取的信息。需求分析师应在需求获取前明确需要获取的需求信息，以确保在实施需求获取时有的 放矢。通常需求获取要获取的信息包括三大类： 与问题域相关的背景信息（如业务资料，组织结构图，业务处理流程等） ；与要求解决的问题直接相关的信息； 用户对系统的特别期望与施加的任何约束信息。 2明确需求信息的来源。明确需求信息的来源。 需求分析师在明确了所需要获取的信息之后，应确定获取需求信息的来源与渠道，以 提高需求分析师在需求

4、获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。 需求信息的来源通常包括： 来自客户的需求 实施所满足的需求 竞争对手的产品优势与不足 3获取需求信息的方法。获取需求信息的方法。 在明确须获取什么需求、需求的来源与获取渠道后，应选择至少一种需求获取技术获 取相关的需求，作为需求分析的依据。需求获取技术包括但不限于： 客户访谈 客户调查 现场观摩用户的工作流程，观察用户的实际操作 需求讨论会 4需求信息的保管。需求信息的保管。 根据所采用的需求获取技术，在需求获取过程中将产生不同的记录和原始资料，项目 组应将这些记录纳入开发库进行配置管理。需求获取的记录与资料包括但不限于： 用户编写的

5、原始需求文档； 用户填写的需求调查表； 用户访谈的访谈纪要； 需求研讨会的会议纪要； 相关的政策法规文件，业务规则文件以及行业标准文件； 需求原型。 5需求分析工作方法。需求分析工作方法。 根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段” （也称“三步法” ） 。第一阶段：第一阶段：“访谈式访谈式” （Visitation） 这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上 把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、 现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的 职能部门以及各委办局，

6、最好能指定本次项目的接口人。 实现手段实现手段：访谈、调查表格 输出成果输出成果：调查报告、业务流程报告 第二阶段：第二阶段：“诱导式诱导式” （Inducement） 这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件 环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方 案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调 研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的 DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题， 及时地提出改进意见和方法。 实现

7、手段实现手段：拜访（诱导） 、原型演示 输出成果输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：第三阶段：“确认式确认式” （Afirm） 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段， 这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户 描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建 方提供的 DEMO 系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段实现手段：拜访（回顾、确认） ，提交业务流程报告、数据项表；原型演示系统 输出成果：输出成果：需求分析报告、数据项、业务

8、流程报告、原型系统反馈意见（后三者 可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档） 需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法 的实施和采用，对用户和承建方都同样提供了项目成功的保证。当然在系统建设的过程中， 特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进 中，工作则基本集中在后两个阶段中。 6需求分析应注意的问题。需求分析应注意的问题。 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。 在写需求说明书时应该注意两个问题： 1.最好为每个需求注释“为什么” ，这样可让程序员了解需求的本质

9、，以便选用最合适 的技术来实现此需求。 2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重 新分析此需求。 7获取需求过程中的原则获取需求过程中的原则 原则 永远不要显得比客户更聪明 第一条：了解需求，而不是去批评客户； 第二条：客户比你更熟悉业务的环境； 第三条：客户总是知道问题在哪儿，你的工作就是要让他们自己愿意说出来；原则 尊重用户的现实选择 第一条：客户永远是对的； 第二条：提供最合适的解决方案，而非最好或最贵的方案； 第三条：不要把客户当傻瓜； 原则 转述需求的人也是客户 第一条：转述者一般会把自己想象成设计者； 第二条：转述者可能会遗漏或补充一些额外的需求

10、； 第三条：对转述者的自由发挥不应抱怨和生气，而是将其视为客户； 原则 客户和用户要区别对待 第一条：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确 定； 第二条：为客户寻找价值上的需求； 第三条：用户的利益高于一切； 原则 用最简单的文字工具记录需求 第一条：所有人都能懂的东西，最不容易出错；第二条：不需要再学习的东西，最不容易出错； 第三条：不要希望客户能花更多的时间来了解需求转换后的模型； 第四条：保持沟通的通畅，是了解需求的保障； 原则 天下没有免费的午餐 第一条：客户从来没有不合理的需求； 第二条：客户的要求都是可以实现的； 第三条：我们能做这事这是所需的费用；6.2 需

11、求分析需求分析的内容的内容名称名称内容内容适用性适用性功能分析实现该需求软件所须提供的 功能及其含义、工作内容所有需求必须，非原子级需 求需给出下一级的功能结构 图角色分析分析该需求涉及的角色及在 本需求内容的行为原子级需求必须，其它可选业务流程分析分析该需求涉及的业务流程， 以流程图或用例图表示，并 根据需要配合一定的文字说 明原子级需求必须，其它可选数据分析分析该需求涉及数据项的名 称、含义、格式、规则。以 表格形式给出原子级需求必须，其它不适 用权限分析定义各角色在该需求中的行 为。以表格形式给出原子级需求必须，其它不适 用界面分析实现该需求的界面风格、表 单样式、报表格式及页面布 局。

12、报表类需求或客户明确要求 的必须，其它可在需求说明 书中统一分类说明性能分析分析该需求的最大数据量、 访问频度，定义用户响应时 间等要求有特殊要求必须说明，其它 可在需求说明书中统一分类 说明偶合性分析分析该需求和其它需求间的 相互关系及影响，与其它需 求有关的应以表格详细说明 相互关系原子级需求必须，其它可选6.3 需求分解需求分解按照功能结构图进行分解，原则上以每一条完成工作的实际业务流程为一个需求最小 单位（原子级需求） ，单个流程以下的作为该需求的功能，不向下细分。每个原子级需求必 须满足以下条件： 1）仅存在一条主要业务流程； 2）操作同一业务数据；6.4 需求定义需求定义1标识需求

13、标识需求 为了确保需求的易跟踪、易修改，需求分析师应通过需求编号的方式唯一标识每一个软件需求，明确需求的跟踪粒度，并体现于软件需求分析文档。 编码规则：编码规则：-XQ-.-. 例：例：设备系统（EMS）的第一个功能“基础数据管理”的第二个功能“供应商管理的 第 3 版需求编号为：EMS-XQ-1.1-2.3 说明：说明：需求编号按照合同方案中排列顺序编排，如合同方案中未出现的功能需求则排 在合同所列所有需求之后。 2定义需求优先级别定义需求优先级别 需求分析师应确定每个需求的优先级并写入软件需求分析文档，需求的优先级的评价 标准如下：级别判断标准采取的措施高满足以下任意一条时： ）客户明确要

14、求的； ）满足正常业务必须的； ）系统不可缺少的 ）导致其它高优先级需求无法实现的 ）相关法规、标准要求的。对于这些需求在项目实施过程中 需重点投入资源，优先实现，只 有在这些需求上达成一致意见， 软件才会被接受；必须完美地实 现。通常这类需求在当前版本必 须实现。中满足以下任意一条时： ）客户隐含要求，对正常业务影响程度不 大 ）支持必要的系统操作，实现这些需求将 增强产品的性能，是产品最终所要求的。这些需求必须被实现，但如果项 目实施中出现进度、资源等方面 的冲突时，如果有必要，可以延 迟到下一版本；需要付出努力， 但不必做得太完美。低满足以下任意一条时： ）功能或质量上的附加功能； ）实

15、现这些需求会使产品更完美，若不实 现也不影响产品的功能与性能，属于锦 上添花。实现或不实现均可；可以在项目 组有较足够的时间时考虑这些需 求的实现优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之 间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种 权衡的方法是：当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级 的需求，或者把它们推迟到下一版本中去实现。 3定义需求与现有管理的差异级别（流程差异性）定义需求与现有管理的差异级别（流程差异性） 需求分析师应确定每个需求实现的管理流程与客户现行管理流程间的差异性大小并写 入软件需求

16、分析文档，流程差异性的评价标准如下：级别判断标准采取的措施无满足以下全部条件时： 1）现有流程和设计流程一致无需过多考虑，设计时实现原流 程既可有满足以下全部条件时： 1）现有流程和设计流程不一致； 2）客户认可新流程。在需求设计说明书中需要反映原 始流程和设计流程，并描述两者 区别及调整原因，在培训阶段应 加强此部分的力度。建议满足以下全部条件时： 1）现有流程和设计流程不一致；改变或不改变均可；在需求设计 说明书中以原始流程为最终流程，2）双方对新流程未达成共识； 3）我方认为新流程有先进性； 4）流程改变与否不会影响功能实现； 5）流程改变与否不会影响系统总体目标。但在需求说明书中反映建议的新 流程，并描述原始流程实现后可 能带来的问题及新流程的先进性。保留满足以下全部条件时： 1）现有流程和设计流程不一致； 2）双方对新流程未达成共识； 3）客户明确要求保留的； 4）我方坚决反对的； 5）流程改变与否会影响功能实现或者会影 响系统总体目标