需求和问题管理规范.docx

《需求和问题管理规范.docx》由会员分享，可在线阅读，更多相关《需求和问题管理规范.docx（22页珍藏版）》请在第壹文秘上搜索。

1、曼荼罗Mandala，MandWa-TSoftwareCortxwafion需求和问题管理规范V1.4变更记录版本文件内容描述日期编写审核批准1.0草稿2014-4-29张菁华1.1发他2015-1-14张普华1.2草稿2016-3-10李晓伟1.3草稿2016-4-25张菁华1.4草稿2016-9-12张菁华目录概述错误床定义书签。问题管理流程定义错误味定义书签。2.1 角色定义错误!未定义书签.2.2 状态定义错误!未定义书签.2.3 状态权限控制错误!未定义书签.2.4 需求状态流程错误!未定义书签.2.5 BUG状态流程错误!未定义书签.2.6 外部协助状态流程错误!未定义书笠.问题管

2、理规范说明错误I未定义书签。3.1 登录错误!未定义书筌.3.2 新建问题过程错误!未定义书签.3.3 开发过程错误!未定义书签.3.4 测试过程错误!未定义书筌.3.5 实施过程错误!未定义书签.3.6 归档错误!未定义书签.产品版本及需求管理规章错误!未定义书签。4.1 实施部内部版本及需求管理制度错误!未定义书签.4.2 研发部内部版本及需求管理制度错误!未定义书筌.4.3 测试部内部版本及需求管理制度错误!未定义书签.4.4 其他错误!未定义书筌.附录错误I未定义书签。5.1 流文档模板错误!未定义书筌.5.2 需求跟踪表律谀!未定义书签.5.3 项目联络人错误!未定义书筌.5.4 需

3、求管理人员错谀!未定义书签.1概述为规范公司软件需求和问题的管理，提高研发、实施和测试三部门之间的沟通效率，提升软件产品需求和问题的管理能力，拟构建redmine需求管理规范。该流程规范适合于研发、测试、实施三部门。2问题管理流程定义2.1 角色定义为了便于对需求跟踪，将人员角色划分成以下几个角色： ProgramSoftManagement：产品开发负责人、联络人，负责需求分析，确认，以及实现的分配，以下简称PSM； Developer：产品开发人员，负责开发，负责已开发状态变更： Tester：测试人员，负责在评审前编写测试用例，根据测试用例对软件进行测试，负责己测试状态变更、提交bug。

4、 CM：配置管理人员，负责配置项管理； RequirementsManagement需求管理人员，负责项目现场需求及bug提交的过滤及质量评审，一下简称RM ProductImplementation：项目实施人员，负责软件发布版本的现场实施操作，记录跟踪上线情况，负责提交需求、已解决需求状态变更，以下简称P1.2.2 状态定义将需求的状态分成以下几种状态，分别为：新建：对于开发项目在需求受理后由Pl人员录入redmine系统需求库，标记为该状态；并将需求提交至相应的RM人员处进行过滤评审。 已接收：对RM评审通过的需求，由PSM确认并接受，标记为该状态； 进行中：研发人员根据提交的新需求，分

5、析需求，分解任务，安排计划,这个阶段需求定义为，进行中状态。 已提交：Devek)Per开发人员将指派给自己的需求修改完成提交测试后，定义为已提交 测试通过：Tester测试人员对研发已提交的需求测试通过后给出的标记状态； 测试不通过：TeSter测试人员对研发已提交的需求测试不能通过时给出的标记状态； 已关闭：上线获得客户认可，需求处理结束，转归档。 重新打开：存在问题，重新打开。 挂起：经过项目需求分析，以及客户确认后，延期处理，或暂不处理的，将需求状态设置为挂起状态。 终止：经过该项目定义的需求评审制度评审结果为不处理的，设置需求状态为，终止 已退回：对不符合要求的需求进行退回处理时标记

6、该状态； 非BUG：研发因不是BUG退回的，由测试人员确认，跟研发达成一致后修改状态为非BUG2.3状态权限控制 ProgramSoftManagement：己接收、进行中、已提交、挂起； Developer：已接收、进行中、已提交、挂起； Tester：新建、测试通过、测试不通过、重新打开、非BUG、已关闭； RequirementsManagement：己接收、已关闭、终止： ProductImplementation:新建、已关闭、终止； .4需求状态流程需求状态的流转周期 .5BUG状态流程说明：1、新建：测试新建问题，新建后如果研发还没接收，新建者可自己退回关2、已退回：研发接收后发

7、现描述有问题，或非BUG,可退回3、已接收：研发确认可以进行后续修改4、进行中：研发接收问题后分配任务按计划进行5、已提交：研发修改完毕，转到测试6、测试不通过：测试收到版本后进行回测，不通过打回7、测试通过：如果是内部提交BUG,测试通过后就结束如果是外部提交BUG,测试通过后反馈给提交者，由提交者关闭8、重新打开：已经测试通过或关闭的BUG,在后续版本中发现反复，即重新打开提交至研发最终的关闭状态有3种：1、非BUG：研发因不是BUG退回的，由测试人员确认，跟研发达成一致后修改状态为非BUG2、测试通过：内部提交BUG,测试通过后结束3、已关闭：外部提交BUG,测试通过后反馈给提交者，由提

8、交者关闭 .6外部协助状态流程说明：如果现场实施和服务部同事，有不明确的需求和问题或很难重现的BUG,需要研发和测试进行协助确认或重现，可以提交跨部门协助中请。1、新建：新建外部协助，新建后如果还没接收，提交者可自己退回关闭。2、已退回：接收后发现描述不明确有问题，或不在协助范围内，可退回。3、已接收：确认可以进行后续协助支持。4、进行中：接收问题后分配任务按计划进行。5、已解决：协助现场问题解决完毕，转到现场。最终的关闭状态有2种：U已终止：退回不属于协助范围的问题，终止。2、已关闭：解决问题后反馈给提交者，由提交者关闭。3问题管理规范说明3.1 登录地址：选择维护项目；3.2 新建问题过程

9、执行角色：实施人员或测试人员。执行输入：需求或bug场景描述：外部需求:实施人员提交新建，并指派给该产品的需求管理指定的联络人（实施部专家组组长或特工六处成员）进行评审确认，如确认无效不需修改或需求不合理则退回终止。外部bug：实施人员提交，指派给该产品的需求管理指定的联络人（实施部专家组组长或特工六处成员）进行BUG验证后与测试确认BUG情况并指派研发人员修改。外部协助：实施或服务部人员提交，指派给该产品的需求管理指定的联络人（实施部专家组组长或特工六处成员）进行外部协助的过滤和确认，确认后指派给相应测试或研发人员，如非协助范围则退回终止。提出协助申请方必须明确外部协助的内容（跟需求一样，把

10、问题描述清楚，说清楚问题发生和处理经过，并形成流文档）。内部bug：测试人员提交，登记后，指派给相关研发组长执行。执行步骤：1 .在redmine上增加一条问题记录2 .填写以下字段的信息：ra”“才”f 2wM w*0M*M1ftImandalatl: 2016-9-12 修改增加现场实施和售后人员提交readmine时，不需要再上传流文档附件，宜接把该需求及BUG流文档按照以下格式贴在描述框中，如下图所示,研发人员整理产品流文档时，直接把描述框中内容拷贝出来即可。I跟踪需求ifi痂述B/UCIUIBIO三三亲于Pret编号】20160618提交日期】2016-8-18【产品分类】电子病历系

11、统【版本号】2.0【紧急程度】紧急提出人】医院职芳琬名联系电话【现场实施】姓名联系电话1主诉】【现羯史】需乎：.双亘一罡如9的,进行描述院颖建优耀普通，指潦给I流文档格式：【提交日期】2016-8-18【产品分类】电子病历系统【版本号】2.0【紧急程度】紧急【提出人】医院职务+姓名联系电话【现场实施】姓名联系电话【主诉】【现病史】需求：现有情况是如何的，进行描述【修改原因和目的(需求)】【重现步骤(BUG)【建议】3 .流文档作为附件提交U其中【修改原因及目的】及【需要达到效果】是必填项，如果描述不清楚，研发有权退回T体样式见附件品24 .实施提交需求，设置“指派给”字段的值为产品的需求管理人

12、员（具体见附件5.4）进行需求评审，如需求确认则由需求管理人员“指派给”具体的项目项目联络人（具体见附件5.3）。5 .选中其它希望抄送邮件的相关人员作为跟踪者；6 .需求跟踪表仍按照原制度执行，具体样式见附件5.3。7 .紧急需求仍按照原流程执行，由叶总，谢总确认后执行，其他需求研发按医院进行需求修改，实施部可提供需求紧急程度排名，确认后由实施部专家组或特工六处与研发对接。8 .3开发过程执行角色：研发负责人，开发组成员执行输入：研发负责人指派开发任务的开发人员，并确认可交付项目现场版本更新的计划时间及修改此需求需要花费的工作量，以便统计是否需要和林公盗匪。执行步骤：1 .在“指派给我的问题

13、”中上找到对应记录，修改问题状态为“已接收”，指派具体开发人员。2 .开发人员对需求进行设计、修改，修改问题状态为，进行中3 .开发人员开发和自测完毕，将已修改或新增的配置项提交配置库。4、研发组长启动自动编译，自动编译成功后，提交测试邮件。找到redmine记录，修改问题状态为“已提交”。5 .如果有遗留问题，在更新回复中说明。6 .修改当前责任人“指派给”字段值为测试负责人。7 .保存更新问题。3.4测试过程执行角色：测试人员执行输入：测试确认研发修改是否符合需求要求。执行步骤：1 .检查开发输出；2 .锁定测试内容；3 .编写测试用例；4,进行测试：5 .若测试不通过：在更新回复中填写发

14、现的问题，更新问题状态为测试不通过；6 .若测试通过：更新问题状态为“测试通过”，并将指派人员改为需求提交者，邮件发布版本；7 .保存更新问题。8 .5实施过程执行角色：实施人员执行输入：接收到版本发布的通知及计划更新的时间执行步骤：1.进行现场基本功能测试及需求测试工作，如需求修改未按原始方案进行修改则进行回退，如测试无问题则确认更新时间计划，按计划进行版本升级；2 .更新完成后，对需求质量进行反馈。3 .以上信息记录，实施可以将文档作为附件提交。3.6归档执行角色：实施人员、测试人员执行输入：确认需求是否满足客户要求：执行步骤：1.指定人员进行现场上线跟踪2 .反馈结果。3 .反馈结果上线正常，修改问题状态：测试通过一已关闭。4 .如果需求存在问题，不符合实际运作，要返工，重新建立需求，并通知研发负责人。5 .内部BUG由提出的测试人员归档。4产品版本及需求管理规章4.1 实施部内部版本及需求管理制度版本：A.现场实施人员不得从别的项目上获取程序版本，所有版本必须从测试部统一发出。