软件需求管理

第7讲 软件需求管理,毛新军/xjmao 计算机科学与技术系602教研室 0731-(45)73649,软件项目管理课程 之,Copyright Xinjun Mao 2005,第7讲 软件需求管理,2,讲授内容,项目案例什么是软件需求如何进行软件需求分析软件需求管理CMM对需求管理的要求本讲小结,Copyright Xinjun Mao 2005,第7讲 软件需求管理,3,项目案例,案例角色和人物,小王：软件项目负责人,老王：公司技术老总,开发小组：小李，老赵，小田，小谢,Copyright Xinjun Mao 2005,第7讲 软件需求管理,4,要对软件需求进行管理(1/2),按照初步的项目计划，老赵带领项目组的部分成员(需求分析小组)开始进驻用户场地，开展需求调查工作，但在需求分析和后续开发过程中陆续出现了许多与用户需求有关的一系列问题，影响软件项目的实施整个项目规模比较庞大，需求分析小组不知如何开展工作？从何处下手？对需求分析的复杂性和难度估计不足。需求分析小组不能有效工作：不知哪些属于用户需求，哪些不是？不知怎样才能获取用户需求？如何把它分析清楚？不知应该按照怎样的规范书写软件需求规格说明书?得到的软件需求质量不高：说不清，遗漏，矛度，罗嗦.需求评审不严格，导致遗漏了许多需求，获取的用户需求不一致、描述的不清晰和准确,Copyright Xinjun Mao 2005,第7讲 软件需求管理,5,要对软件需求进行管理(2/2),更为糟糕的是，由于用户没有参加需求评审，使得许多软件需求没有得到用户的认可，最终所开发出的软件不能满足用户的要求，用户拒绝接收软件，并拒绝付款由于软件需求的不准确性、不一致性和二义性，在软件开发阶段，软件设计人员不得不通过用户再次确认需求在开发过程中，用户的需求仍然在改变，需求分析小组负责获取改变了的用户需求，然而这些改变了的需求没有得到有效的管理和控制，没能将变化的需求及时反馈给软件开发小组，导致这些需求未能在待开发的软件中得到体现由于需求未能得到有效管理，在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期,Copyright Xinjun Mao 2005,第7讲 软件需求管理,6,案例提示我们,需求分析是极为重要的需求分析是困难和复杂的用户需求经常性的变更是正常的为了保证软件需求的质量，必须对需求分析的人、过程和产品进行有效管理需求管理的不善将会导致严重后果,Copyright Xinjun Mao 2005,第7讲 软件需求管理,7,项目项目管理问题,什么是软件需求？如何进行软件需求分析？软件需求管理的内容?如何对软件需求进行管理?,Copyright Xinjun Mao 2005,第7讲 软件需求管理,8,讲授内容,项目案例什么是软件需求如何进行软件需求分析软件需求管理CMM对需求管理的要求小结,Copyright Xinjun Mao 2005,第7讲 软件需求管理,9,软件需求,什么是软件需求？获取软件需求的重要性获取软件需求的复杂性和面临的问题解决的方法和手段,Copyright Xinjun Mao 2005,第7讲 软件需求管理,10,什么是软件需求(1/4),什么是软件需求？待开发软件产品的目标用户对该软件产品的功能、性能、设计约束和其它方面的期望和要求说明目标用户实际操作该软件的用户(图书管理员)用户方的负责人用户代表(市场经理)，必须是用户所需的例如，网上图书借阅(想法很好，用户不需要，也不现实),Copyright Xinjun Mao 2005,第7讲 软件需求管理,11,什么是软件需求(2/4),关于软件需求的注意事项软件需求关注用户的期望、要求和需要，不是解决方案要区分what和How例如，要采用什么算法，不是用户需求并不是所有方面的要求都是软件需求功能、性能、设计约束、时间进度等例如，重量、软件大小等不是用户需求并不是所有用户的期望和要求都是软件需求用户需求必须中肯，有意义例如，记录图书的厚度等不是用户需求,Copyright Xinjun Mao 2005,第7讲 软件需求管理,12,什么是软件需求(3/4),软件需求的表现形式功能需求性能需求易用性、质量、性能、安全性，移植性、可重用性等设计约束运行环境开发环境其它要求：如开发周期,Copyright Xinjun Mao 2005,第7讲 软件需求管理,13,什么是软件需求(4/4),软件需求例子图书馆管理系统功能需求办理读者借书证, 借阅图书，性能需求查询操作延迟时间不超过1秒钟, 设计约束前台运行在windows OS下，其它要求开发时间6个月, ,Copyright Xinjun Mao 2005,第7讲 软件需求管理,14,获取软件需求的重要性,软件开发的基础和前提只有在明确了软件需求之后才能开展有针对性的软件开发工作没有需求无法进行设计和编码制定软件开发计划的基础只有知道你想做什么，才能知道做这些东西需要多少工作量？不知道软件需求也就不知道工作量的大小，因而不能制定计划最终目标软件系统验收的标准只有知道你想做什么，才能知道你最终是否做好了没有定义明确的需求，就不知道最终基于什么进行验收,Copyright Xinjun Mao 2005,第7讲 软件需求管理,15,获取软件需求的复杂性(1/2),系统复杂和庞大如何将软件需求得到？描述清楚？片面, 不完全如何保证得到了所有的软件需求？模糊, 不准确如何保证把需求说清楚和准确？不一致, 歧义如何保证所描述的需求是不矛盾的？及时性当需求变更时，如何让相关人员都知道需求已经变更？,Copyright Xinjun Mao 2005,第7讲 软件需求管理,16,获取软件需求的复杂性(2/2),软件需求变动带来的问题波动性放大性,Copyright Xinjun Mao 2005,第7讲 软件需求管理,17,解决的方法和手段,技术层面需求分析方法、技术和工具方法：数据流、面向对象技术：抽象、建模、多视点、原型、工具：UML，Rose，Word，Excel，RequisitePro管理层面对需求分析中的人、活动和产品进行管理形成新的研究领域：需求工程,Copyright Xinjun Mao 2005,第7讲 软件需求管理,18,讲授内容,项目案例什么是软件需求如何进行软件需求分析软件需求管理CMM对需求管理的要求小结,Copyright Xinjun Mao 2005,第7讲 软件需求管理,19,软件需求分析,什么是软件需求分析软件需求分析的任务软件需求分析的目标软件需求分析的过程,Copyright Xinjun Mao 2005,第7讲 软件需求管理,20,什么是软件需求分析,什么是软件需求分析？需求分析是指从用户处获得需求、形成与用户需求相一致的、可供阅读的软件需求规格说明书的过程,Copyright Xinjun Mao 2005,第7讲 软件需求管理,21,软件需求分析的任务,通过对应用问题及其环境的理解和分析，准确、一致和完全地刻划用户需求，并达成一致，形成软件需求规格说明书SRS,Copyright Xinjun Mao 2005,第7讲 软件需求管理,22,软件需求分析的目标,全面性没有遗漏一致性没有矛盾准确性说清楚认同共同、相互认可文档化书面文档,Copyright Xinjun Mao 2005,第7讲 软件需求管理,23,软件需求分析的过程,软件需求建模,收集软件需求,评审软件需求,文档化软件需求,Copyright Xinjun Mao 2005,第7讲 软件需求管理,24,步骤1:收集和获取软件需求(1/2),任务从用户处收集、获取软件需求, 帮助用户发现潜在的软件需求来源软件用户成果初步需求描述,Copyright Xinjun Mao 2005,第7讲 软件需求管理,25,步骤1:收集和获取软件需求(2/2),技术手段访谈会议参观实践,Copyright Xinjun Mao 2005,第7讲 软件需求管理,26,步骤2:软件需求建模(1/2),任务对收集的用户软件需求进行建模，发现并纠正不一致、不准确和不全面的软件需求，形成准确的需求描述来源初步的软件需求描述,Copyright Xinjun Mao 2005,第7讲 软件需求管理,27,步骤2:软件需求建模(2/2),技术手段面向数据流和面向对象的建模方法多视点原型成果软件需求模型,Copyright Xinjun Mao 2005,第7讲 软件需求管理,28,步骤3:文档化软件需求(1/2),任务根据软件需求初步描述和软件需求模型，撰写软件需求规格说明书来源软件需求初步描述软件需求模型,Copyright Xinjun Mao 2005,第7讲 软件需求管理,29,步骤3:文档化软件需求(2/2),技术手段软件需求规格说明书编写规范成果软件需求规格说明书,Copyright Xinjun Mao 2005,第7讲 软件需求管理,30,步骤4:评审软件需求(1/2),任务由多方对软件需求规格说明书进行评审，发现其中的问题，并就其中的软件需求达成一致来源软件需求规格说明书,Copyright Xinjun Mao 2005,第7讲 软件需求管理,31,步骤4:评审软件需求(2/2),技术手段需求评审原则成果可纳入配置的软件需求规格说明书,Copyright Xinjun Mao 2005,第7讲 软件需求管理,32,讲授内容,项目案例什么是软件需求如何进行软件需求分析软件需求管理CMM对需求管理的要求小结,Copyright Xinjun Mao 2005,第7讲 软件需求管理,33,需求管理,为什么需要对软件需求进行管理需求管理的内容收集软件需求软件需求建模撰写软件需求规格说明书(SRS)评审软件需求控制软件需求的变更,Copyright Xinjun Mao 2005,第7讲 软件需求管理,34,为什么需要对软件需求进行管理,软件需求非常重要获取软件需求非常复杂和困难在需求获取过程中涉及到人、活动和过程，只有对它们进行管理才能确保有效地进行需求分析，确保软件需求的质量软件需求经常变更，为了确保软件需求处于受控状态,Copyright Xinjun Mao 2005,第7讲 软件需求管理,35,需求管理的内容,参与需求分析和评审的人员软件需求文档需求分析过程需求变更,Copyright Xinjun Mao 2005,第7讲 软件需求管理,36,收集软件需求,如何收集软件需求？文档化所收集的软件需求软件需求收集的注意事项,Copyright Xinjun Mao 2005,第7讲 软件需求管理,37,如何收集需求？,确定哪些用户角色会对软件提出需求例如图书馆的馆长，图书管理员，书库管理员，读者管理员，系统管理员；而不是图书馆的清理工用户方要成立相应的需求分析小组和相关角色的人员进行交流会议、探讨、观察、实践、听取意见在交流的过程中要有记录，要对记录进行整理文字，录音，整理，写成文档,Copyright Xinjun Mao 2005,第7讲 软件需求管理,38,文档化所收集的软件需求(1/3),描述需求内容例如，查询图书按照图书名字查询定义软件需求编号(结构化)例如，10(查询图书)10.1(按照图书名字查询)10.2(按照图书的书号查询)10.3 (按照作者查询),Copyright Xinjun Mao 2005,第7讲 软件需求管理,39,文档化所收集的软件需求(2/3),描述软件需求特性例如，查询图书软件需求重要性(高、中、低)，用于制定计划紧迫性(短期、中期、长期)，用于制定计划工作量(10个人月)，用于估算工作量、制定计划,Copyright Xinjun Mao 2005,第7讲 软件需求管理,40,文档化所收集的软件需求(3/3),工具：word, excel, RequisitPro(Rational)初步需求描述编写规范,Copyright Xinjun Mao 2005,第7讲 软件需求管理,41,软件需求收集的注意事项(1/2),如果应用规模较大，可分成几个需求调查小组同时进行，最后对结果进行汇总一定要和用户进行充分的交流，尽可能获取足够多的信息和资料，发现问题要及时沟通在该阶段要和用户打成一片，进行充分的合作，建立起良好的合作关系如果发现多个软件需求相互矛盾，要能找到仲裁人，或者决策人,Copyright Xinjun Mao 2005,第7讲 软件需求管理,42,软件需求收集的注意事项(2/2),需求调查应遵循先整体后部分、先抽象后具体的原则帮助用户发现潜在的需求,Copyright Xinjun Mao 2005,第7讲 软件需求管理,43,软件需求建模,为什么需要对软件需求进行建模？如何对软件需求进行建模？,Copyright Xinjun Mao 2005,第7讲 软件需求管理,44,为什么需要对软件需求进行建模,需求调查所获取和文档化(文字)的软件需求不能有效地描述软件需求文字描述的局限性(不准确、二义、歧义、不能直观揭示关联)不准确不一致不全面.,Copyright Xinjun Mao 2005,第7讲 软件需求管理,45,如何对软件需求进行建模(1/2),需求建模技术面向数据流的需求建模技术面向对象的需求建模技术UMLUse case 图交互图(顺序图，协作图)类图状态图活动图,Copyright Xinjun Mao 2005,第7讲 软件需求管理,46,如何对软件需求进行建模(2/2),案例分析需求建模的例子(图书管理系统，UML，Rose),Copyright Xinjun Mao 2005,第7讲 软件需求管理,47,撰写SRS(1/2),为什么要撰写成SRS记录软件需求便于交流便于管理便于控制便于验证,Copyright Xinjun Mao 2005,第7讲 软件需求管理,48,撰写SRS(2/2),SRS应该作为一种规范和标准企业和组织要明确说明如何撰写软件需求规格说明书一个SRS的编写规范,Copyright Xinjun Mao 2005,第7讲 软件需求管理,49,评审软件需求,为什么需要对软件需求进行评审？如何进行评审？评审结果,Copyright Xinjun Mao 2005,第7讲 软件需求管理,50,为什么需要对软件需求进行评审？,发现软件需求规格说明书中的问题不全面不一致不准确不可验证书写不规范共同认可软件需求,Copyright Xinjun Mao 2005,第7讲 软件需求管理,51,如何进行评审(1/3),参与评审人员项目经理用户方(代表)需求分析小组软件设计小组软件测试小组软件质量保证小组应该提前将SRS送给参与评审人员,Copyright Xinjun Mao 2005,第7讲 软件需求管理,52,如何进行评审(2/3),需求评审原则多方对软件需求达成一致正确性软件需求是否是用户所需要的例如，一个读者最多能借10本书准确是否把软件需求描述清楚了例如，一个读者包括诸多信息如名字，单位等等无歧义性软件需求描述是否会引起不必要的误解和认识上的偏差例如，用户和客户,Copyright Xinjun Mao 2005,第7讲 软件需求管理,53,如何进行评审(3/3),完全性是否所有的需求都已经包含了可验证性是否有手段来验证需求已经实现了例如，查询结果应该很快得到一致性软件需求是否会相互矛度可理解和可修改性软件需求描述是否简洁、直观，易于修改和维护可追踪性软件需求是否易于追踪,Copyright Xinjun Mao 2005,第7讲 软件需求管理,54,软件需求评审结果,软件需求评审应该要有记录，并形成软件需求评审报告软家需求评审报告样板软件需求评审应该要有结论根据意见进一步改进，下次再次进行评审根据意见进一步改进，无需再次进行评审评审通过,Copyright Xinjun Mao 2005,第7讲 软件需求管理,55,控制软件需求的变更,控制SRS控制需求的变更,Copyright Xinjun Mao 2005,第7讲 软件需求管理,56,控制SRS,作为一个基本的软件配置项纳入配置任何对软件需求的变更必须进行仔细审查，征得同意后才能进行变更,Copyright Xinjun Mao 2005,第7讲 软件需求管理,57,控制需求的变更(1/3),需求变更不可避免软件需求本身是变化的在需求分析阶段对软件需求的描述和分析不全面、不准确等需求变更对软件项目的开发会产生巨大的影响产品功能开发成本开发进度产品质量,Copyright Xinjun Mao 2005,第7讲 软件需求管理,58,控制需求的变更(2/3),需求变更的权衡，需要和用户协商，并对计划进行变更,Copyright Xinjun Mao 2005,第7讲 软件需求管理,59,控制需求的变更(3/3),如何控制需求的变更提出软件需求变更请求对软件需求变更进行评审变更SRS将变更后的SRS纳入配置通知受影响小组和人员变更其他产品(软件设计文档、测试文档)和计划(软件开发计划),Copyright Xinjun Mao 2005,第7讲 软件需求管理,60,讲授内容,项目案例什么是软件需求如何进行软件需求分析软件需求管理CMM对需求管理的要求小结,Copyright Xinjun Mao 2005,第7讲 软件需求管理,61,CMM对需求管理的要求(1/3),需求管理是CMM 2级的一个关键过程域CMM对需求管理的理解和定义需求管理是指在用户和将处理“分配给软件的系统需求”的软件项目组之间建立对“分配给软件的系统需求”的共同理解，由软件工程组对“分配给软件的系统需求”进行分析、精化，按照规范详细描述“分配给软件的系统需求”，形成“软件需求规格说明”文档，并对该文档进行评审 “分配给软件的系统需求” 是指系统总体分配给软件的需求，也称软件需求 “用户”可解释为系统工程组或外部顾客等,Copyright Xinjun Mao 2005,第7讲 软件需求管理,62,CMM对需求管理的要求(2/3),“软件工程组” ：实施软件工程化开发的小组软件需求既包括技术需求、又包括非技术需求软件需求构成项目规模和工作量估算、制定项目计划和跟踪软件项目活动的基础每当软件需求改变时，都应调整受到影响的软件计划、工作产品和活动，使其与更新后的软件需求保持一致对已通过评审的软件需求的任何更改都应受到管理和控制,Copyright Xinjun Mao 2005,第7讲 软件需求管理,63,CMM对需求管理的要求(3/3),共12个关键实践,Copyright Xinjun Mao 2005,第7讲 软件需求管理,64,目标,使软件需求受控，建立供软件工程和管理使用的基线受控：在给定时间(过去或现在)使用的工作产品的版本是已知的(即受版本控制的)，并以受控的方式进行更动(即更动控制) “软件工程”是指软件设计、编码、测试等“软件管理”是指项目计划制定、项目跟踪、风险等软件计划、产品和活动与软件需求保持一致所谓“保持一致”是指相吻合,Copyright Xinjun Mao 2005,第7讲 软件需求管理,65,制定方针政策,项目遵循一个书面的、由组织制定的方针用来管理软件需求将软件需求写成规范化的文档拟定参加需求评审的人员, 包括项目软件负责人，其它受影响的小组，包括系统测试组，软件工程组(如软件设计小组),软件质量保证组，软件配置管理组，文档支持组等当软件需求发生改变时，更动软件计划、工作产品和活动，使其与软件需求的改变保持一致,Copyright Xinjun Mao 2005,第7讲 软件需求管理,66,确保必备条件(1/4),建立和明确系统需求分析和分配的人员及其职责 ，明确在整个项目生存期内，管理和分配系统需求，并将它们写成文档实施对系统需求及其分配的更动，当系统需求发生更动时，应及时更动软件需求,Copyright Xinjun Mao 2005,第7讲 软件需求管理,67,确保必备条件(2/4),将软件需求写成规范化的文档技术需求，如软件功能、性能、设计约束、编程语言、界面需求非技术性需求(即协议、条件、和(或)合同条款),包括：要交付的产品、交付日期、里程碑等用于确认软件产品满足软件需求的验收准则,Copyright Xinjun Mao 2005,第7讲 软件需求管理,68,确保必备条件(3/4),提供足够的用以管理分配需求的资源和经费 指派在应用领域和软件工程方面有经验和技能的个人去管理软件需求 提供可用的、能支持软件需求管理活动的工具电子表格程序配置管理工具跟踪工具测试管理工具,Copyright Xinjun Mao 2005,第7讲 软件需求管理,69,确保必备条件(4/4),软件工程组和其它受影响组的人员接受需求管理方面的培训，如项目所使用的方法、标准和规程应用领域知识,Copyright Xinjun Mao 2005,第7讲 软件需求管理,70,实施软件过程(1/3),软件工程组识别、分析和细化软件需求，对它进行评审 鉴别出不完整的和遗漏的软件需求评审软件需求，确定它们是否用软件来实现是可行的和恰当的已被清晰和准确地阐述相互一致、无矛盾可验证、可测试对任何被识别出有潜在问题的软件需求进行评审，并作出必要的更动 和受影响组一起协商解决由软件需求引出的承诺,Copyright Xinjun Mao 2005,第7讲 软件需求管理,71,实施软件过程(2/3),将软件需求作为软件开发计划、工作产品和过程活动的基础，软件需求： 是受管理和控制的 是软件开发计划的基础,Copyright Xinjun Mao 2005,第7讲 软件需求管理,72,实施软件过程(3/3),对软件需求的更动进行评审，并将其纳入软件项目评估软件需求更动对现有承诺的影响，通过协商对承诺进行适当的更改 对组织外的个人和组所作承诺的更改由高级管理者参与评审 和受影响组协商组织内部承诺的更改 对由于软件需求的更动所造成的对软件计划、工作产品和活动必须作的更动要进行识别、评价、风险评估、写成文档、做出计划、传达到受影响组和个人、跟踪直