7-软件需求管理G-北京大学软件与微电子学院

软件需求管理周立新博士北京大学软件与微电子学院业务需求用户需求系统需求功能需求质量属性其他非功能需求约束条件项目视图与范围文档使用实例文档软件需求规格说明用户能有效的纠正文档中的拼写错误找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词。•找到并高亮度提示错词；•显示提供替换词的对话框以及实现整个文档范围的替换。需求工程需求工程需求管理需求开发编写规格说明分析问题获取验证包括软件类产品中需求收集、评价、编写文档等所有活动建立并维护在软件工程中同客户达成的契约需求开发活动确定产品所期望的用户类。获取每个用户类的需求。了解实际用户任务和目标以及这些任务所支持的业务需求。分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。需求开发活动（续）将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。了解相关质量属性的重要性。商讨实施优先级的划分。将所收集的用户需求编写成规格说明和模型。评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。需求管理活动•定义需求基线（迅速制定需求文档的主体）。•评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。•以一种可控制的方式将需求变更融入到项目中。•使当前的项目计划与需求一致。需求管理活动（续）•估计变更需求所产生影响并在此基础上协商新的承诺（约定）。•让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。•在整个项目过程中跟踪需求状态及其变更情况。基准需求说明分析编写文档评审、商议需求变更过程市场需求客户管理市场客户管理项目环境当前基线需求开发需求管理修正后基线需求变更项目变更需求开发与需求管理之间的界限需求开发与管理之间的界线1.需求管理活动CMMI中需求管理的流程图结束开始制定需求管理计划求得对需求的理解求得对需求的承诺维护对需求的双向追踪性组织的总体方针需求管理模板管理需求变更识别项目工作与需求之间的不一致性1.1版本控制需求文档的每一个版本必须被统一确定。组内每个成员必须能够得到需求的当前版本。必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。需求的属性创建需求的时间需求的版本号创建需求的作者负责认可该需求的人员需求状态需求的原因或根据（或信息的出处）需求涉及的子系统需求涉及的产品版本号使用的验证方法或接受的测试标准产品的优先级或重要程度（例如高、中、低或）需求的稳定性（在将来需求可能变更的指示器，不稳定的需求意味你应给予较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。）建议的需求状态表状态值定义已建议该需求已被有权提出需求的人建议已批准该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该项需求已实现已实现需求代码的设计、编写和单元测试已验证使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成已删除计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员已拒绝状态跟踪示例1.2需求变更管理应仔细评估已建议的变更。挑选合适的人选对变更做出决定。变更应及时通知所有涉及的人员。项目要按一定的程序来采纳需求变更。控制项目范围的扩展扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较大的影响。要是每个建议的需求都被采纳，对于项目出资者（sponsor）、参与者与客户来说项目将永远也不会完成—事实上，这是不可能的。控制项目范围的扩展对许多项目来说，一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整。在你的项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不断地采纳新的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。管理范围扩展管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部分。评估每一项建议的需求和特性，将它与项目的视图和范围相比较决定是否应该采纳它。强调客户参与的有效的需求获取方法能够减少遗漏需求的数量，只在做出提交承诺和分配资源后才采纳该需求。控制需求扩展的另一个有效的技术是原型法，这个方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确把握用户的真实需求。要敢于说“不”。变更控制策略所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。对于未获批准的变更，除可行性论证之外，不应再做其它设计和实现工作。简单请求一个变更不能保证能实现变更，要由项目变更控制委员会（CCB）决定实现哪些变更。项目风险承担者应该能够了解变更数据库的内容。绝不能从数据库中删除或修改变更请求的原始文档。每一个集成的需求变更必须能跟踪到一个经核准的变更请求。简单变更控制步骤模板1.绪论①目的②范围③定义2.角色和责任3.变更请求状态4.开始条件5.任务①产生变更请求②评估变更请求③作出决策④通知变更人员6.验证7.结束条件变更管理活动中可能的项目角色角色描述及责任变更控制委员会主席变更控制委员会的主席，在CCB意见不一致情况下可以独自做出决定CCB决定采纳或拒绝针对某项目所建议的变更请求的团体评估者应项目管理者要求分析所建议的变更带来影响的人员修改者负责实现已经被认可的请求变更，按时更新变更状态的人员建议者提交新变更请求的人项目管理者负责指定评估者和修改者的人员请求接受者接受提交变更请求的人验证者负责决定变更是否正确执行的人变更控制委员会的组成产品或计划管理部门。项目管理部门。开发部门。测试或质量保证部门。市场部或客户代表。制作用户文档的部门。技术支持部门。帮助桌面或用户支持热线部门。配置管理部门。常见变更请求数据项变更需求状态转换图测量变更活动接收、未作决定、结束处理的变更请求的数量。已实现需求变更（包括增、删、改）的合计数量（也可以用在基线上占需求总数的百分比来表示）。每个方面发出的变更请求的数量。每一个已应用的需求（是指已划过基线）建议变更和实现变更的数量。投入处理变更的人力、物力。工作量（劳动时数）任务______________更新软件需求规格说明书或需求数据库______________开发并评估原型______________创建新的设计部件______________修改已有的设计部件______________开发新的用户界面部件______________修改已有的用户界面部件______________开发新的用户文档和帮助文件______________修改已有的用户文档和帮助文件______________开发新的源代码______________修改已有的源代码______________购买和集成第三方软件______________修改构造文件______________开发新单元测试和综合测试______________进行单元测试和综合测试______________写新的系统测试实例______________修改已有的系统测试实例______________修改自动测试驱动程序______________进行回归测试______________开发新报告______________修改已有的报告______________开发新的数据库元素______________修改已有的数据库元素______________开发新的数据文件______________修改已有的数据文件______________修改各种项目计划______________更新别的文档______________更新需求跟踪能力矩阵______________检查工作产品______________根据测试和检查情况返工______________总计劳动时数影响分析报告模板变更请求ID_______________标题__________________描述__________________分析者__________________日期_______________优先权评估：相关收益_______________（1-9）相关代价_______________（1-9）相关成本_______________（1-9）相关风险_______________（1-9）最终优先级_______________预计总耗时_______________劳动时数预计损时_______________劳动时数预计对进度的影响_______________天数额外的成本影响_______________金额质量影响_________________________________________被影响的其他需求_________________________________被影响的其他任务_________________________________要更新的计划_____________________________________综合的事项_______________________________________生存期成本事项___________________________________可能的变更所需检查的其他部件_____________________1.3需求跟踪客户需要需求下游工作产品从需求回溯从需求追溯回溯到需求追溯到需求一些可能的需求跟踪能力联系链业务需求变更请求规格说明系统需求，用例，业务规则及外部接口需求软件功能需求依赖另一个系统测试项目计划任务体系结构，用户接口或功能设计被验证集成测试代码单元测试被陈述被验证连接到被实现被验证影响影响影响影响RequisiteProProjectOrganizationToolbarProjecticonPackageDocumentViewsRequirementsWorkinginaViewExistingArtifactsforRUe-stProjectUCSpecRMPlancsvfileVisionSupl.SpecIncludedonExerciseCDStakeholderRequestsGlossaryRUe-stProjectExistintheprojectCreateintheprojectImportintotheprojectCreateaRequirementintheExplorerorinaViewUserDocumentationSpecificationsDesignSpecificationsUse-CaseModelSupplementarySpecificationsFeaturesSoftwareRequirementsNeedsRequirementsandAssociatedDocumentsStakeholderRequestsVisionDocumentDesign,Test,DocumentationRequirementsDeleteaRequirementinaDocument