《软件需求管理》PPT课件.ppt

《《软件需求管理》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《软件需求管理》PPT课件.ppt（40页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件需求管理周周 立立 新新 博士博士北京大学软件与微电子学院北京大学软件与微电子学院业务需求业务需求用户需求用户需求系统需求系统需求功能需求功能需求质量属性质量属性其他非功能需求其他非功能需求约束条件约束条件项目视图与范围文档项目视图与范围文档使用实例文档使用实例文档软件需求规格说明软件需求规格说明用户能有效的纠正文档中的拼写错误用户能有效的纠正文档中的拼写错误找出文档中的拼写错误并通过一个提供找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词。的替换项列表来供选择替换拼错的词。找到并高亮度提示错词；找到并高亮度提示错词；显示提供替换词的对话框以及实显示提供替换词的对话框以及

2、实现整个文档范围的替换。现整个文档范围的替换。需求工程需求工程需求工程需求管理需求开发编写规格说明分析问题获取验证包包括括软软件件类类产产品品中中需需求求收收集集、评评价价、编编写写文文档档等等所有活动所有活动 建建立立并并维维护护在在软软件件工工程程中中同同客客户户达成的契约达成的契约 需求开发活动需求开发活动 l确定产品所期望的用户类。确定产品所期望的用户类。l获取每个用户类的需求。获取每个用户类的需求。l了了解解实实际际用用户户任任务务和和目目标标以以及及这这些些任任务所支持的业务需求。务所支持的业务需求。l分分析析源源于于用用户户的的信信息息以以区区别别用用户户任任务务需需求求、功功能

3、能需需求求、业业务务规规则则、质质量量属属性、建议解决方法和附加信息。性、建议解决方法和附加信息。需求开发活动需求开发活动（续）（续）l将将系系统统级级的的需需求求分分为为几几个个子子系系统统，并并将将需求中的一部份分配给软件组件。需求中的一部份分配给软件组件。l了解相关质量属性的重要性。了解相关质量属性的重要性。l商讨实施优先级的划分。商讨实施优先级的划分。l将将所所收收集集的的用用户户需需求求编编写写成成规规格格说说明明和和模型。模型。l评评审审需需求求规规格格说说明明，确确保保对对用用户户需需求求达达到到共共同同的的理理解解与与认认识识，并并在在整整个个开开发发小小组接受说明之前将问题都

4、弄清楚。组接受说明之前将问题都弄清楚。需求管理活动需求管理活动定定义义需需求求基基线线（迅迅速速制制定定需需求求文文档档的主体）。的主体）。评评审审提提出出的的需需求求变变更更、评评估估每每项项变变更的可能影响从而决定是否实施它。更的可能影响从而决定是否实施它。以以一一种种可可控控制制的的方方式式将将需需求求变变更更融融入到项目中。入到项目中。使当前的项目计划与需求一致。使当前的项目计划与需求一致。需求管理活动需求管理活动（续）（续）估估计计变变更更需需求求所所产产生生影影响响并并在在此此基基础上协商新的承诺（约定）。础上协商新的承诺（约定）。让让每每项项需需求求都都能能与与其其对对应应的的设

5、设计计、源源代代码码和和测测试试用用例例联联系系起起来来以以实实现现跟踪。跟踪。在在整整个个项项目目过过程程中中跟跟踪踪需需求求状状态态及及其变更情况。其变更情况。基准需求说明基准需求说明分析分析编写文档编写文档评审、商议评审、商议需求变更过程需求变更过程市场市场需求需求客户客户管理管理市场市场客户客户管理管理项目环境项目环境当前基线当前基线需求开发需求开发需求管理需求管理修正后基线修正后基线需求变更需求变更项目变更项目变更需求开发与需求管理之间的界限需求开发与需求管理之间的界限需求开发与需求开发与管理之间的管理之间的界线界线1.需求管理活动需求管理活动CMMI中需求管理的流程图中需求管理的流

6、程图结束结束开始开始制定需求管理计划制定需求管理计划求求得得对对需需求求的的理理解解求求得得对对需需求求的的承承诺诺维护对需求的双向追踪性维护对需求的双向追踪性 组织的总体方针组织的总体方针需求管理模板需求管理模板管理需求变更管理需求变更识别项目工作与需求之间的不一致性识别项目工作与需求之间的不一致性1.1版本控制版本控制l需求文档的每一个版本必须被统一确定。需求文档的每一个版本必须被统一确定。l组内每个成员必须能够得到需求的当前版组内每个成员必须能够得到需求的当前版本。本。l必须清楚地将变更写成文档，并及时通知必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。到项目开发所涉及的人员

7、。l为了尽量减少困惑、冲突、误传，应仅允为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。许指定的人来更新需求。需求的属性需求的属性l创建需求的时间创建需求的时间l需求的版本号需求的版本号l创建需求的作者创建需求的作者l负责认可该需求的人员负责认可该需求的人员l需求状态需求状态l需求的原因或根据（或信息的出处）需求的原因或根据（或信息的出处）l需求涉及的子系统需求涉及的子系统l需求涉及的产品版本号需求涉及的产品版本号l使用的验证方法或接受的测试标准使用的验证方法或接受的测试标准l产品的优先级或重要程度（例如高、中、低或）产品的优先级或重要程度（例如高、中、低或）l需求的稳定性（在将来需

8、求可能变更的指示器，不稳定的需求的稳定性（在将来需求可能变更的指示器，不稳定的需求意味你应给予较多的关注，因为你将面临不定的、混需求意味你应给予较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。）沌的、或不能重复的业务过程。）建议的需求状态表建议的需求状态表 状态值状态值 定定 义义 已建议已建议该需求已被有权提出需求的人建议该需求已被有权提出需求的人建议已批准已批准该该需需求求已已被被分分析析，估估计计了了其其对对项项目目余余下下部部分分的的影影响响（包包括括成成本本和和对对项项目目其其余余部部分分的的干干扰扰），已已用用一一个个确确定定的的产产品品版版本本号号或或创创建建编编号

9、号分分配配到到相相关关的的基基线线中中，软软件件开开发发团团队队已已同同意意实实现现该该项项需需求求已实现已实现已实现需求代码的设计、编写和单元测试已实现需求代码的设计、编写和单元测试已验证已验证使使用用所所选选择择的的方方法法已已验验证证了了实实现现的的需需求求，例例如如测测试试和和检检测测，审审查该需求跟踪与测试用例相符。该需求现在被认为完成查该需求跟踪与测试用例相符。该需求现在被认为完成已删除已删除计划的需求已从基线中删除，但包括一个原因说明和做出删除计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员决定的人员 已拒绝已拒绝状态跟踪示例状态跟踪示例1.2需求变更管理需求变更

10、管理l应仔细评估已建议的变更应仔细评估已建议的变更。l挑选合适的人选对变更做出决定。挑选合适的人选对变更做出决定。l变更应及时通知所有涉及的人员。变更应及时通知所有涉及的人员。l项目要按一定的程序来采纳需求变更。项目要按一定的程序来采纳需求变更。控制项目范围的扩展控制项目范围的扩展l扩展需求是指在软件需求基线已经确定后扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。又要增添新的功能或进行较大改动。l问题不仅仅是需求变更本身，而是迟到的问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较大的影响。需求变更会对已进行的工作有较大的影响。l要是每个建议的需求都被采纳，

11、对于项目要是每个建议的需求都被采纳，对于项目出资者（出资者（sponsor）、参与者与客户来说项）、参与者与客户来说项目将永远也不会完成目将永远也不会完成事实上，这是不可事实上，这是不可能的。能的。控制项目范围的扩展控制项目范围的扩展l对许多项目来说，一些需求的改进是合理的且不对许多项目来说，一些需求的改进是合理的且不可避免。可避免。l业务过程、市场机会、竞争性的产品和软件技术业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的，管理部门也会决在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整。定对项目做出一些调整。l在你的项目进度表中应该对必要的需求改动留有在你的

12、项目进度表中应该对必要的需求改动留有余地。余地。l若不控制范围的扩展将使我们持续不断地采纳新若不控制范围的扩展将使我们持续不断地采纳新的功能，而且要不断地调整资源、进度、或质量的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。目标，这样做极其有害。管理范围扩展管理范围扩展l管理范围扩展的第一步就是把新系统的视图、范管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部分。围、限制文档化并作为业务需求的一部分。l评估每一项建议的需求和特性，将它与项目的视评估每一项建议的需求和特性，将它与项目的视图和范围相比较决定是否应该采纳它。图和范围相比较决定是否应该采纳它

13、。l强调客户参与的有效的需求获取方法能够减少遗强调客户参与的有效的需求获取方法能够减少遗漏需求的数量，只在做出提交承诺和分配资源后漏需求的数量，只在做出提交承诺和分配资源后才采纳该需求。才采纳该需求。l控制需求扩展的另一个有效的技术是原型法，这控制需求扩展的另一个有效的技术是原型法，这个方法能够给用户提供预览所有可能的实现，以个方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确把握用户的真实帮助用户与开发者沟通从而准确把握用户的真实需求。需求。要敢于说要敢于说“不不”。变更控制策略变更控制策略 l所有需求变更必须遵循的过程，按照此过程，如果一所有需求变更必须遵循的过程，按照此

14、过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。个变更需求未被采纳，则其后过程不再予以考虑。l对于未获批准的变更，除可行性论证之外，不应再做对于未获批准的变更，除可行性论证之外，不应再做其它设计和实现工作。其它设计和实现工作。l简单请求一个变更不能保证能实现变更，要由项目变简单请求一个变更不能保证能实现变更，要由项目变更控制委员会（更控制委员会（CCB）决定实现哪些变更。）决定实现哪些变更。l项目风险承担者应该能够了解变更数据库的内容。项目风险承担者应该能够了解变更数据库的内容。l绝不能从数据库中删除或修改变更请求的原始文档。绝不能从数据库中删除或修改变更请求的原始文档。l每一个集成的

15、需求变更必须能跟踪到一个经核准的变每一个集成的需求变更必须能跟踪到一个经核准的变更请求。更请求。简单变更控制步骤模板简单变更控制步骤模板1.绪论绪论目的目的范围范围定义定义2.角色和责任角色和责任3.变更请求状态变更请求状态4.开始条件开始条件5.任务任务产生变更请求产生变更请求评估变更请求评估变更请求作出决策作出决策通知变更人员通知变更人员6.验证验证7.结束条件结束条件变更管理活动中可能的项目角色变更管理活动中可能的项目角色角角色色描述及责任描述及责任变更控制委员会变更控制委员会主席主席变变更更控控制制委委员员会会的的主主席席，在在C C C C B B意意见见不不一一致致情情况况下下可可

16、以独自做出决定以独自做出决定CCB决定采决定采纳纳或拒或拒绝针对绝针对某某项项目所建目所建议议的的变变更更请请求的求的团团体体评估者评估者应项应项目管理者要求分析所建目管理者要求分析所建议议的的变变更更带带来影响的人来影响的人员员修改者修改者负责实现负责实现已已经经被被认认可的可的请请求求变变更，按更，按时时更新更新变变更状更状态态的人的人员员建议者建议者提交新提交新变变更更请请求的人求的人项目管理者项目管理者负责负责指定指定评评估者和修改者的人估者和修改者的人员员请求接受者请求接受者接受提交接受提交变变更更请请求的人求的人验证者验证者负责负责决定决定变变更是否正确更是否正确执执行的人行的人

17、变更控制委员会的组成变更控制委员会的组成 l产品或计划管理部门。产品或计划管理部门。l项目管理部门。项目管理部门。l开发部门。开发部门。l测试或质量保证部门。测试或质量保证部门。l市场部或客户代表。市场部或客户代表。l制作用户文档的部门。制作用户文档的部门。l技术支持部门。技术支持部门。l帮助桌面或用户支持热线部门。帮助桌面或用户支持热线部门。l配置管理部门。配置管理部门。常见变更请求数据项常见变更请求数据项变更需求状态转换图 测量变更活动测量变更活动l接收、未作决定、结束处理的变更请求的接收、未作决定、结束处理的变更请求的数量。数量。l已实现需求变更（包括增、删、改）的合已实现需求变更（包括

18、增、删、改）的合计数量（也可以用在基线上占需求总数的计数量（也可以用在基线上占需求总数的百分比来表示）。百分比来表示）。l每个方面发出的变更请求的数量。每个方面发出的变更请求的数量。l每一个已应用的需求（是指已划过基线）每一个已应用的需求（是指已划过基线）建议变更和实现变更的数量。建议变更和实现变更的数量。l投入处理变更的人力、物力。投入处理变更的人力、物力。工作量工作量（劳动时数）（劳动时数）任务任务_ _ 更新软件需求规格说明书或需求数据库更新软件需求规格说明书或需求数据库_ _ 开发并评估原型开发并评估原型_ _ 创建新的设计部件创建新的设计部件_ _ 修改已有的设计部件修改已有的设计部

19、件_ _ 开发新的用户界面部件开发新的用户界面部件_ _ 修改已有的用户界面部件修改已有的用户界面部件_ _ 开发新的用户文档和帮助文件开发新的用户文档和帮助文件_ _ 修改已有的用户文档和帮助文件修改已有的用户文档和帮助文件_ _ 开发新的源代码开发新的源代码_ _ 修改已有的源代码修改已有的源代码_ _ 购买和集成第三方软件购买和集成第三方软件_ _ 修改构造文件修改构造文件_ _ 开发新单元测试和综合测试开发新单元测试和综合测试_ _ 进行单元测试和综合测试进行单元测试和综合测试_ _ 写新的系统测试实例写新的系统测试实例_ _ 修改已有的系统测试实例修改已有的系统测试实例_ _ 修改自

20、动测试驱动程序修改自动测试驱动程序_ _ 进行回归测试进行回归测试_ _ 开发新报告开发新报告_ _ 修改已有的报告修改已有的报告_ _ 开发新的数据库元素开发新的数据库元素_ _ 修改已有的数据库元素修改已有的数据库元素_ _ 开发新的数据文件开发新的数据文件_ _ 修改已有的数据文件修改已有的数据文件_ _ 修改各种项目计划修改各种项目计划_ _ 更新别的文档更新别的文档_ _ 更新需求跟踪能力矩阵更新需求跟踪能力矩阵_ _ 检查工作产品检查工作产品_ _ 根据测试和检查情况返工根据测试和检查情况返工_ _ 总计劳动时数总计劳动时数影响分析报告模板影响分析报告模板 变更请求变更请求I D_

21、I D_标题标题_描述描述_分析者分析者_日期日期_优先权评估：优先权评估：相关收益相关收益_（1-91-9）相关代价相关代价_（1-91-9）相关成本相关成本_（1-91-9）相关风险相关风险_（1-91-9）最终优先级最终优先级_预计总耗时预计总耗时_劳动时数劳动时数预计损时预计损时_劳动时数劳动时数预计对进度的影响预计对进度的影响_天数天数额外的成本影响额外的成本影响_金额金额质量影响质量影响_被影响的其他需求被影响的其他需求_被影响的其他任务被影响的其他任务_要更新的计划要更新的计划_综合的事项综合的事项_生存期成本事项生存期成本事项_可能的变更所需检查的其他部件可能的变更所需检查的其

22、他部件_1.3需求跟踪需求跟踪客户需要客户需要需求需求下游工作产品下游工作产品从需求从需求回溯回溯从需求从需求追溯追溯回溯到回溯到需求需求追溯到追溯到需求需求一一些些可可能能的的需需求求跟跟踪踪能能力力联联系系链链业务需求业务需求变更请求变更请求规格说明规格说明系统需求，用例，业务规系统需求，用例，业务规则及外部接口需求则及外部接口需求软件功能需求软件功能需求依依 赖赖 另另一个一个系统测试系统测试项目计划项目计划任务任务体系结构，用户接口体系结构，用户接口或功能设计或功能设计被验证被验证集成测试集成测试代码代码单元测试单元测试被陈述被陈述被验证被验证连接到连接到被实现被实现被验证被验证影响影

23、响影响影响影响影响影响影响RequisitePro Project OrganizationToolbarProject iconPackage Document Views RequirementsWorking in a View Existing Artifacts for RU e-st Project UCSpecRM Plancsv file Vision Supl.Spec IncludedonExerciseCDStakeholderRequestsGlossaryRU e-stProjectExistintheprojectCreateintheprojectImportin

24、totheprojectCreate a Requirement in the Explorer or in a View UserDocumentationSpecificationsDesignSpecificationsUse-CaseModelSupplementarySpecificationsFeaturesSoftwareRequirementsNeedsRequirements and Associated DocumentsStakeholderRequestsVisionDocumentDesign,Test,Documentation RequirementsDelete a Requirement in a Document