《需求和问题管理规范.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 .反馈结果上线
15、正常，修改问题状态：测试通过一已关闭。4 .如果需求存在问题，不符合实际运作，要返工，重新建立需求，并通知研发负责人。5 .内部BUG由提出的测试人员归档。4产品版本及需求管理规章4.1 实施部内部版本及需求管理制度版本：A.现场实施人员不得从别的项目上获取程序版本，所有版本必须从测试部统一发出。B.原则上现场实施人员对未正式发布过的常规产品（专家组负责的产品）不予接收，并且不参与需求过滤及管理工作。需求：C.项目中的需求均经过大区经理线下过滤后，由项目经理提交需求至需求管理人员处（专家组组长或特工六处），对于能力突出的项目经理，大区经理可以授权且不进行过滤，但是大区经理对需求质量负责：1、需
16、求描述质量；2、是否为需求。D.需求管理人员（专家组组长或特工六处），接收需求后与现场沟通并进行评审确认需求质量和评估是否有替代方案，描述质量不达标需求流程打回，如无问题则将需求流转至研发或测试处：专家组对审核过的需求质量负责：1、需求描述质量；2、是否为需求。E.现场人员拿到可更新版本后应在测试环境测试基础功能，并验证需求是否按方案修改，如有bug或者修改未按方案执行的则回退版本，分别由测试部和研发部负责，纳入部门年度考核指标中。F.若测试版本无问题，现场人员在拿到版本3天内反馈更新计划，并在更新后的15天内给予需求满意度（需求确认表）及需求使用率的反馈，然后关闭需求：由秘书处跟踪需求闭环。
17、纳入大区经理考核指标。G.秘书处利用通用报表每周通报各模块需求修改的情况至大区经理。4.2 研发部内部版本及需求管理制度版本：A.研发部不得直接发布版本至项目现场。4.3 发部内部需求由各产品线线长或制定的组长统筹管理。C.所有常规产品必须进行发布，并提供相应的产品应用说明书，基础配置文档等。需求：A.需求开发人员在3天内必须回复交付现场可更新版本的计划时间点和开发工作量。B.需求改修必须按之前约定好的方案执行，如有变动需提前与现场项目经理沟通确认。4.3 测试部内部版本及需求管理制度版本：所有发布到现场的版本均由测试部统一发出，原则上测试部不能发布不可更新的版本到项目现场。需求：测试部在接收
18、研发部提交版本后应对系统进行功能性测试，并确保程序不存在重大bug,在完成测试后将流文档及程序版本发布。4.4 其他1 .每个阶段过程的指派接收人（实施-研发测试实施）都需三天内响应反馈，反馈内容包括： 该问题是否可以修改/是否为BUG 修改计划 完成情况 测试计划 更新计划 更新情况 其它有内容的反馈1 .对于不能及时响应的问题将计入其负责人员的绩效考评结果，进行相应的扣罚。实施未在规定时间响应的，一次罚款50元。研发人员未在计划时间内发布版本，一次罚款50元。测试人员发布到现场的版本存在重大bug导致更新回退的一次罚款50元。2 .流文档及提交需求中【修改原因及目的】及【需要达到效果】是必
19、填项，所有提交需求的流文档由需求管理人员进行质量把控，如果描述不清楚，则回退需求提交者进行修改，如流转至研发的需求仍表述不清研发有权退回。流文档书写不符合规范的，一次罚款50元。3 .需求提交后，除了指派给产品联络人，还需要增加跟踪人员，主要是自己所属的项目经理和地区经理。乱填指派人和跟踪者的一次罚款50元。4 .该制度从3月15日试运行，4月1日正式启用。5.1 流文档模板Illllllllllllllllllllllllllllllllllilllllllllllllllilllllllllllllllinilllll【注】为了减少文件的容量，请使用写字板编辑本文件.【注】可以使用粗体字.
20、文字段的不同性质,以颜色区分，充分发挥了计算机文档不同于普通纸质文档的优势：.红色代表尚未完成修改；.黑色代表已经完成修改；,嫁色代表功能介绍或者新增功能；.紫色为刚刚修改过的内容；.品红色为注意要添加的文档配置内容;.蓝色为注释或者用户操作说明；.灰色为和测试部和管理咨询部的讨论的记录.【注】如果发现bug,只描述此bug是不够的，请将产生这个bug的操作步骤进行详细说明，否则，将无法跟踪，也无法改正。【注】代码人员改好以后，会将问题变成黑色字体，但如果管理咨询部认为这个问题并不能让人满意的话，可以将问题仍旧改回红色字体，提醒代码人员.【注】原则上，流文档中不保存图片。在实施人员提交流文档的
21、时候，可以包含一些图示，研发人员搞清楚问题所在之后，删除图片.流文档描述问题的格式：【编号】【提交日期】2016818【产品分类】电子病历系统【版本号】2.0【紧急程度】紧急【提出人】医院职务+姓名联系电话【现场实施】姓名联系电话住诉】【现病史】需求：现有情况是如何的，进行描述【修改原因和目的（需求）】【事现步骤（BUG）】【建议】【负责人】研发负责人*以下为解决问题的全过程记录，可以多次往复。需求提出确认表（提需求时填写）产品名称版本号提出医院提出人提出日期需求内容【问题句话简述】：【问题现状描述】：【修改原因及目的】：【需要达到的效果】：【建议】：院方负责人签字日期2、需求方案确认表（客户
22、反馈方案时填写）修改方案是否知晓修改方案是否认可若不认可方案，请说明原因：院方负责人签字日期3、需求验证确认表（需求实现后填写）是否更新三更新填“是”，未更新的需填写“否”和“计划更新日期”更新范围修改结果满意度口不能接受，口能接受，口比较满意，口很满意若不认可修改结果，请说明原因，院方负责人签字日期项目名称状态版本产品组长需求联络人护理线移动护理（mobile）维护Vl陈玉锡陈玉锡移动护理（Android）维护Vl陈玉锡陈玉锡移动医疔【备注：就是移动查房】维护Vl陈玉锡陈玉锡连线护理在研陈玉锡陈玉福移动输液（安卓版）维护Vl陈玉锡陈玉福护士管理【备注：护士长管理手册】维护Vl秦军椽秋月医德医
23、风维护Vl秦军杨秋月护理管理（B/S版）在研V2秦军畅秋月体温单和产程图维护V2谈俊琪谈俊琪新表单维护V3谈俊琪谈俊琪护理管理信息系统（CS版）在研Vl谈俊琪谈俊琪研发部行发药终端维护Vl高洁高洁临床路径维护V2高洁高洁门诊叫号维护Vl高洁高洁医嘱提交【门诊处方和住院医嘱】维护Vl高洁高洁住院医生工作站（新版医喊）在研Vl高洁高洁上报表单系统维护Vl林锦甫林毓南危急值管理维护Vl林锦甫林锦甫数据监控维护Vl林锦甫林锦甫院内平台门户维护Vl林锦甫林锦甫合理治疗监控系统在研Vl王善伟王善伟全院大交班维护Vl王善伟王善伟医院信息管理系统在研Vl纪峥峰纪峥蝶手术排班定制Vl李帅李帅预约挂号平台定制Vl
24、李帅李帅绩效管理&成本核算定制Vl纪峥蛛纪峥嵯铭文数据上报维护V2朱军朱军铭文交班维护Vl朱军朱军区域线医患通维护Vl陆文伟陆文伟区域便民服务维护Vl陆文伟陆文伟妇幼短信平台维护Vl陆文伟陆文伟无锡医管中心区域数据中心系统集成解决方案维护庄国强庄国强社区便民服务系统在研Vl陆文伟陆文伟区域疾病监控系统维护Vl王森林王森林通用报表维护Vl庄国强钱跃峰同义词字典及HIS业务数据清洗维护Vl张大江张大江永川医院HQMS病案首页上报维护张大江张大江远程医疗管理中心维护V2庄国强庄国强UHID抄录器维护V2王森林王森林文件管理系统（PDF转换）维护Vl王森林王森林双向转诊维护庄国强庄国强病历调阅维护庄国
25、强庄国强保密病历管理维护Vl王森林王森林区域数据平台集成系统（重庆、昆明、石家庄、马鞍山）维护庄国强庄国强领航者质控管理及数据集成维护V2张大江张大江医疗质量管理系统维护Vl张大江张大江医疔线Doq1.ei电子病历维护V2张勇管鑫波3管叁波院内会诊【备注：包含在电子病历里】维护Vl张勇管套波电子病历CA处理【备注：包含在电子病历里】维护Vl张勇管套波电子病历插件【备注：包含在电子病历里】维护张勇管叁波病案首页维护V2张勇管叁波病案管理维护V2张勇管叁波排班维护Vl张勇管叁波空荼罗巡检使（应用服务器监控）在研Vl卞欢卞欢铭文临床路径系统维护V3王泵王泵单病种管理维护Vl王泵王泵住院医嘱套餐维护Vl王泉王泵铭文授权管理维护Vl王泵王泵5.4需求管理人员产品名称部门需求管理人电了病历及质控系统专家组管鑫波护理病历、移动护理、护理管理专家组李晓伟临床路径及单病种专家组尤召门诊病历专家组陆凯医院平台特工六处张偲偲区域平台特工六处封鹏科研特工六处刘兵注：实施部各大区经理可直接与华东：尹晓聪、顾广才、封工相应研发对接沟通：鹏华中：张军、潘琳玲华南：李燕熊、黄炳宏华北：段永伟、张立波西南：刘兵、舒文琪、魏孝东服务部各区域服务经理可直接与相应研发对接沟通:河北：杨亚明无锡：施文君、田夫瑞苏北：顾鹏冲湖南：彭琪湖北：黄亚飞四川：刘彬云南：郭彦林江西：吴义春广东：崔超苏南：王志强
