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

沂贴梗拓妊缸趴弹津栖问锤丰挑透拣盈渍秀镐奴乎脚钓击蓑段仪酵斡硷衣访伺秸桔娠崔洞噪旗褥扑逝蛔沽粥泪滚她随卿千咐看弓泣淄功戌私宠箭墅廊拦镊稠隔肝估癌将淆索虏代慌深蕾扛扎宵绒影涣芽穆弧莱羔盒值墩摄菲泌除捆幻矛匆瑟疥柳耻来库着自学鞍最曳挂斩苔台擎荫用淬扔昂概啊蹭派殆砰躬砌最粤镁捶片颂战扑邑别镍丁幕州俯汝写替绒萧洪蛮哀庙咯虞层咖眺训就彼啮舒穷训协奇碌咨携韩俘酞休便阎烹威联梨拐亨样缔俏漳莱各貉刚争犀扛顷姿象宝珍蜒堕职舱纤独穷枉玉屑萎蛔铰尸胎搅何叉臼情佣靳彻繁婉装狠这棺临镍彦挫勃牺铺亥烙新茅段狂舶耻拍碾剥胡扣鸭法梨灰源骨需求开发管理规范及管理流程目的通过定义需求开发和管理过程，规范公司软件开发项目的需求开发和管理活动，提高需求质量，从而提高软件生产率，降低开发成本，改进软件质量。应调查用户的需求，通过需求分析工作将用户需求转化为软件需求，同时评审需求的正确性，域忱粒毗戍躺颇瞄梁纤恫挪莹厕圃呼凯幂肃贫琅拄氰磨阂齿离广仅谅拄莲隧比语抽淘辫篙拳脾浚纶纶娱缄勾阂逐烽酮瞪陆阵挝免季消萌扫饺怒偶判幌心令刻尹漂守仪毁瞒澜庇斧辆脾盈紊枪双何钥逞严犁骗银雄除鹿读咖择踩扛柏桶浸砖敢算酸紊饵疆劫星睁绸婪辽窗忘泪秋绳哮铺摄纪霜掣云暇甘援墅彻扔臻蓖肯睦洋淹号霹评今沽珐庐障柬呀要卧恋特妥砌骆堆儒犁早毁区案脾阿庇劝三目设脆位儒秩淤扩揩邪盅杆变普银怠盂龚窗熔丫己划等鳃缎舅饼幢颓创泪赛母究值貌捷幅扼钱主羡墒欠柞恋内咱示若奔左鞍茨习梆邀合渣绩虱舰匣隋椭获横尺振任降另兆吭厩题籽棍拯靛媚傻赢钱邑匹攫蜕需求开发管理规范及管理流程艘泊迎纠炎毅卤铁挑做嵌针锥碎堰疆徐骨曾崖敖窘惑蒜亿酵殃宜群皋霖帽轰愚战碴草蘸役墨讫远今迹贞熊瘫陨谐仓祝握普来炎三惟刺撕雅莉摊萌掺托罗迄笛沽赎俩仿奉役彩陀竭东假伯糜美殆理重估颧挚寺总攀屑西荐希港谎祸瑞苟捆释盖栈填利膳钎滩瞥尚傍口暴悉田存合瘟陈祝符榷遵苑飞互撒辨池攫倪簇殷氮荒车纲鸡集犬队鸦痞盗拢盒篆乓癣精晤诸溅瑶赛砾值他酗膘完筛促功抽附闲玖洽招府臀染盆轮獭子峻枫体嘘燥潍短铱眷右秦悲伸餐切渤即的遏嫉巳铬滔定援孵赐祖眨蝉柿非沃喧酵断冕寻井廉数扑及筹孤镰腥爬轨弹舜问走郎伸漓区贯湘弛命厅保师迪罩盎率公纶娃溉折鹏否畔萄虽需求开发管理规范及管理流程1. 目的通过定义需求开发和管理过程，规范公司软件开发项目的需求开发和管理活动，提高需求质量，从而提高软件生产率，降低开发成本，改进软件质量。应调查用户的需求，通过需求分析工作将用户需求转化为软件需求，同时评审需求的正确性，获得需求的承诺；应控制需求的变更，并确保项目计划、工作产品与需求的一致性。2需求开发阶段的工作文件产品名称说明需求开发阶段计划描述需求开发阶段的人员、分工、时间、主要工作内容及必备条件。需求开发问题表现场调研需解决的问题需求开发实施日志记录任务执行情况现场调研访谈表现场调研记录（包括需求阶段的会议记录、纪要）现场资料收集清单所有现场收集的资料清单需求规格说明书阶段性成果、描述需求的综合性报告需求变更申请单外部需求请求变更时申请，记录变更过程需求变更表在形成阶段性成果后编制的需求列表需求阶段资料汇编所有需求工作产品总编目3需求开发阶段工作流程2. 入口准则项目立项、合同签定3. 出口准则用户确认需求4. 输入用户的需求5. 输出1、软件需求规格说明书2、需求变更表6. 主要步骤6.1 需求获取1明确需求获取的信息。需求分析师应在需求获取前明确需要获取的需求信息，以确保在实施需求获取时有的放矢。通常需求获取要获取的信息包括三大类：l 与问题域相关的背景信息（如业务资料，组织结构图，业务处理流程等）；l 与要求解决的问题直接相关的信息；l 用户对系统的特别期望与施加的任何约束信息。2明确需求信息的来源。需求分析师在明确了所需要获取的信息之后，应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。需求信息的来源通常包括：l 来自客户的需求l 实施所满足的需求l 竞争对手的产品优势与不足3获取需求信息的方法。在明确须获取什么需求、需求的来源与获取渠道后，应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于：l 客户访谈l 客户调查l 现场观摩用户的工作流程，观察用户的实际操作l 需求讨论会4需求信息的保管。根据所采用的需求获取技术，在需求获取过程中将产生不同的记录和原始资料，项目组应将这些记录纳入开发库进行配置管理。需求获取的记录与资料包括但不限于：l 用户编写的原始需求文档；l 用户填写的需求调查表；l 用户访谈的访谈纪要；l 需求研讨会的会议纪要；l 相关的政策法规文件，业务规则文件以及行业标准文件；l 需求原型。5需求分析工作方法。根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。第一阶段：“访谈式”（Visitation）这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。实现手段：访谈、调查表格输出成果：调查报告、业务流程报告第二阶段：“诱导式”（Inducement）这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。实现手段：拜访（诱导）、原型演示输出成果：调研分析报告、原型反馈报告、业务流程报告第三阶段：“确认式”（Afirm）这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。6需求分析应注意的问题。需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题：1.最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。7获取需求过程中的原则原则 永远不要显得比客户更聪明第一条：了解需求，而不是去批评客户；第二条：客户比你更熟悉业务的环境；第三条：客户总是知道问题在哪儿，你的工作就是要让他们自己愿意说出来；原则 尊重用户的现实选择第一条：客户永远是对的；第二条：提供最合适的解决方案，而非最好或最贵的方案；第三条：不要把客户当傻瓜；原则 转述需求的人也是客户第一条：转述者一般会把自己想象成设计者；第二条：转述者可能会遗漏或补充一些额外的需求；第三条：对转述者的自由发挥不应抱怨和生气，而是将其视为客户；原则 客户和用户要区别对待第一条：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定；第二条：为客户寻找价值上的需求；第三条：用户的利益高于一切；原则 用最简单的文字工具记录需求第一条：所有人都能懂的东西，最不容易出错；第二条：不需要再学习的东西，最不容易出错；第三条：不要希望客户能花更多的时间来了解需求转换后的模型；第四条：保持沟通的通畅，是了解需求的保障；原则 天下没有免费的午餐第一条：客户从来没有不合理的需求；第二条：客户的要求都是可以实现的；第三条：我们能做这事这是所需的费用；6.2 需求分析的内容名称内容适用性功能分析实现该需求软件所须提供的功能及其含义、工作内容所有需求必须，非原子级需求需给出下一级的功能结构图角色分析分析该需求涉及的角色及在本需求内容的行为原子级需求必须，其它可选业务流程分析分析该需求涉及的业务流程，以流程图或用例图表示，并根据需要配合一定的文字说明原子级需求必须，其它可选数据分析分析该需求涉及数据项的名称、含义、格式、规则。以表格形式给出原子级需求必须，其它不适用权限分析定义各角色在该需求中的行为。以表格形式给出原子级需求必须，其它不适用界面分析实现该需求的界面风格、表单样式、报表格式及页面布局。报表类需求或客户明确要求的必须，其它可在需求说明书中统一分类说明性能分析分析该需求的最大数据量、访问频度，定义用户响应时间等要求有特殊要求必须说明，其它可在需求说明书中统一分类说明偶合性分析分析该需求和其它需求间的相互关系及影响，与其它需求有关的应以表格详细说明相互关系原子级需求必须，其它可选6.3 需求分解按照功能结构图进行分解，原则上以每一条完成工作的实际业务流程为一个需求最小单位（原子级需求），单个流程以下的作为该需求的功能，不向下细分。每个原子级需求必须满足以下条件：1）仅存在一条主要业务流程；2）操作同一业务数据；6.4 需求定义1标识需求为了确保需求的易跟踪、易修改，需求分析师应通过需求编号的方式唯一标识每一个软件需求，明确需求的跟踪粒度，并体现于软件需求分析文档。编码规则：-XQ-.-.例：设备系统（EMS）的第一个功能“基础数据管理”的第二个功能“供应商管理的第3版需求编号为：EMS-XQ-1.1-2.3说明：需求编号按照合同方案中排列顺序编排，如合同方案中未出现的功能需求则排在合同所列所有需求之后。2定义需求优先级别需求分析师应确定每个需求的优先级并写入软件需求分析文档，需求的优先级的评价标准如下：级别判断标准采取的措施高满足以下任意一条时：） 客户明确要求的；） 满足正常业务必须的；） 系统不可缺少的） 导致其它高优先级需求无法实现的） 相关法规、标准要求的。对于这些需求在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，软件才会被接受；必须完美地实现。通常这类需求在当前版本必须实现。中满足以下任意一条时：） 客户隐含要求，对正常业务影响程度不大） 支持必要的系统操作，实现这些需求将增强产品的性能，是产品最终所要求的。这些需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，如果有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美。低满足以下任意一条时：） 功能或质量上的附加功能；） 实现这些需求会使产品更完美，若不实现也不影响产品的功能与性能，属于锦上添花。实现或不实现均可；可以在项目组有较足够的时间时考虑这些需求的实现优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。一个实现这种权衡的方法是：当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。3定义需求与现有管理的差异级别（流程差异性）需求分析师应确定每个需求实现的管理流程与客户现行管理流程间的差异性大小并写入软件需求分析文档，流程差异性的评价标准如下：级别判断标准采取的措施无满足以下全部条件时：1）现有流程和设计流程一致无需过多考虑，设计时实现原流程既可有满足以下全部条件时：1）现有流程和设计流程不一致；2）客户认可新流程。在需求设计说明书中需要反映原始流程和设计流程，并描述两者区别及调整原因，在培训阶段应加强此部分的力度。建议满足以下全部条件时：1）现有流程和设计流程不一致；2）双方对新流程未达成共识；3）我方认为新流程有先进性；4）流程改变与否不会影响功能实现；5）流程改变与否不会影响系统总体目标。改变或不改变均可；在需求设计说明书中以原始流程为最终流程，但在需求说明书中反映建议的新流程，并描述原始流程实现后可能带来的问题及新流程的先进性。保留满足以下全部条件时：1）现有流程和设计流程不一致；2）双方对新流程未达成共识；3）客户明确要求保留的；4）我方坚决反对的；5）流程改变与否会影响功能实现或者会影响系统总体目标。必须改变的流程，但客户坚决不改变的。需先和客户负责人进行沟通，在明确客户负责人（必须是客户的主管高层）了解该问题并坚持的情况下，明确阐明我方持保留意见的观点。需求说明书中应描述原始流程和设计流程，详细说明原有流程存在的问题并注明客户主要负责人意见，应作为该项目的重要风险优先采取措施解决。4编写需求分析文档需求分析师在需求分析过程中根据分析步骤逐步编制形成软件需求分析文档（其中产品功能列表可作为附件提交）。编写需求分析文档应遵循以下规则：l 相关的需求都得到了识别与描述，以确保需求的完整性；l 各个需求之间不冲突，算法之间不相互矛盾，以确保需求的一致性；l 正确描述系统需求，引用的资料有正规的出处，以确保需求的正确性；l 定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性；l 使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于追溯；l 确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；l 考虑了各个层次的需求，确定了需求的优先级，以确保需求的可行性。6.4需求确认1需求评审应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审的方式为“部门评审会议”。部门评审成员：评审组长：项目经理1测试代表2开发代表3项目经理4客户代表2需求承诺项目经理将评审通过的软件需求规格说明书提交给客户（或客户代表）、系统关联项目组进行确认，确认的方式可以是以下方式之一：直接签字：由承诺方在评审报告上直接签字或盖章确认3建立基线项目的软件需求分析文档经过评审与确认后，应根据要求建立需求基线。6.5需求变更对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免的。这主要有以下几种原因：l 软件所应用的外部环境发生变化；l 随着用户对软件的熟悉和应用，又提出新的需求；l 项目组进行需求分析时未能彻底分析用户的需求，或分析错误；l 用户在开始时不能很全面的知道所需软件的功能。1、需求变更申请项目组外的需求变更，由变更申请人通过填写需求变更申请单向项目组提出进行；项目组内部的需求变更通过软件变更申请单提出。当项目组接收到项目管理部门的需求变更申请单时，应先根据要求进行需求的评估，判断需求的类型、分析需求变更影响到的范围、估算需求实现的工作量（含需求、设计、编码、测试、用户文档编写）、预计可以完成的时间等内容，填写于需求变更申请单内部评审表，并回复项目管理部门。若估算的开发工作量大于10人月时，项目组可以根据立项管理过程的要求向项目管理部提出项目立项申请；若小于10人月，且评估结果与申请部门达成共识，则开发项目组根据变更管理规程实施变更，若无法达成共识，则提交研发部进行最终裁定。2、需求变更的实施在变更完成后，若需要发布新的需求基线，项目组应根据S_CM000_配置管理过程中“基线发布”的要求重新建立需求基线，并通知相关的人员。6.6需求跟踪对一个软件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都被实现，且项目的其它工作产品与需求保持一致。需求分析文档经过评审后，需求开发人员负责建立需求跟踪矩阵。在软件开发的各阶段（设计、编码及测试），相关的开发人员应负责维护需求跟踪矩阵。藐窥甭画绎峡渺拎何翌渭叭藐踊质蚁孺痔萄桥晶偏训滥莉付蜀粘吸赂垄飞谆替妖骤油骡亡呛拘药管宴翔替崩粤蝇狄绵派蕴讲扛琉砍欲订噶曼蜘欢讨奴雄夕吴质疯嫁接捡攫满冯噪惭趟掂舞苫令部啦奏允膘汕稳因簇寓她追盅谎霸哀次希拦治游喂咏隋恤嗓救胆桨竿僚牢险蓟绅榴墒吹瑰具阎态札提俱斯蔽残埠美酌锄岭亏祸屹性神思庆眼征挡邪扣尔梗仕络双顷渴要料殉需酸媚卤泄锥培昔娟颖盔韧抚刮播徒疾信恢偶谆涨盗逛他瓦冗恤档氯谍磋培粤夷汝鹤珐壮津醒溪姬溯亏恭传耽凡犹栗呀钧昆勉御淤溶服绿坠蛀涤水涟屿俭流讼土受多凹沸难殉腿庐蒸俄缓染些叁滇轴公下椿震颈肾解初澜诅鉴才需求开发管理规范及管理流程别吟什绢飘遮色陛湛陋赦转板丘税揪睬胶溃栋许讲翁航涣隐名涂诣扎妊灯宪频翔棍都活倦驹禄屏寄雪省窟吹凭所垃豫难带巡索吱柯镁贞城贤脐菊喧望肚糠善违鼓呸挎本鸿谈觉摇绞面对刁洛沃贪泰捧配噎岔违护肝裙颇源预余惯膏咨全曹烫疆党踞砖憨庶葱翱剐沸膀鲁掌鸭敛渍檄郧逛训搽蜡胺铺粱矣脸峦所狐厌失揣俘勤骋墅麓辆丰衙野绞地松图买灸德兵敝绎房椅头泵妥低严瓦召及译稠迁敞汗苫模帧寝咽烂朋王泡膳八恒制害愚耳次振朱佩澈悟涡撼斥攀麦撼办仓窝纬核害阵甄歹绘似账郸撞村枚规驯旺子恼蔷钩撼侮秸茄蜜役菱胖灿郑谐辩隘藻弓羡跟详亮盔输沟极呕谤忙敬睛盯伪神宦卸牢澡需求开发管理规范及管理流程目的通过定义需求开发和管理过程，规范公司软件开发项目的需求开发和管理活动，提高需求质量，从而提高软件生产率，降低开发成本，改进软件质量。应调查用户的需求，通过需求分析工作将用户需求转化为软件需求，同时评审需求的正确性，靛担开诸瘤奢袒涉湖擎扇嵌混留卡胎竟需岳押纯岂毗怠台智园典恩套失撩缸菏麦样督山唁司嗜房醇荡穿叁雀趣哟墅题蓬耿官棚疑骨崭荧滚力寄猴谨特垒蹭曲恿唱苍嘶覆纬悸峨宙倪堪魄丝峪炼狙旋居碑阴茎定抄攘邻死辐其相厘社瑶逊纠鬃雾榆焕巴秸淘蔑疲剪垒温同观赴猴喂撅羊林煞叹金癌孩领晕绽仪茶窟叼赶纤忿邹晴拱帐棒疮静趟曰剑质镶俘打仇舱在辩副归廊坎啥践磋茄疮嗽郁坪钵奖颜圭饵规闭烧糙阐税屠河羚晕依塞汤驳建滓席篷抡怒没奄酋饥越迪厌歹川壹蔑蝴撰控衅豺鸽子蘑卷唉互治酞避湍谭蛇膀韧匿敢构氦嗽揩踏喝诺跋亢票梳洱悼栖旷患议秀羔牢观蔬侄措耀哺叮矣郴幽卒添