《软件需求管理.ppt》由会员分享，可在线阅读，更多相关《软件需求管理.ppt（40页珍藏版）》请在三一办公上搜索。
1、软件需求管理,业务需求,用户需求,系统需求,功能需求,质量属性,其他非功能需求,约束条件,项目视图与范围文档,使用实例文档,软件需求规格说明,用户能有效的纠正文档中的拼写错误,找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词。,找到并高亮度提示错词；显示提供替换词的对话框以及实现整个文档范围的替换。,需求工程,需求工程,需求管理,需求开发,编写规格说明,分析,问题获取,验证,包括软件类产品中需求收集、评价、编写文档等所有活动,建立并维护在软件工程中同客户达成的契约,需求开发活动,确定产品所期望的用户类。获取每个用户类的需求。了解实际用户任务和目标以及这些任务所支持的业务需求。
2、分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。,需求开发活动（续）,将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。了解相关质量属性的重要性。商讨实施优先级的划分。将所收集的用户需求编写成规格说明和模型。评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。,需求管理活动,定义需求基线（迅速制定需求文档的主体）。评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目中。使当前的项目计划与需求一致。,需求管理活动（续）,估计变更需求所产生影响并在
3、此基础上协商新的承诺（约定）。让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。在整个项目过程中跟踪需求状态及其变更情况。,基准需求说明,分析编写文档评审、商议,需求变更过程,市场,需求,客户,管理,市场客户管理,项目环境,当前基线,需求开发,需求管理,修正后基线,需求变更,项目变更,需求开发与需求管理之间的界限,需求开发与管理之间的界线,1.需求管理活动,CMMI中需求管理的流程图,1.1 版本控制,需求文档的每一个版本必须被统一确定。组内每个成员必须能够得到需求的当前版本。必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指定
4、的人来更新需求。,需求的属性,创建需求的时间需求的版本号创建需求的作者负责认可该需求的人员需求状态需求的原因或根据（或信息的出处）需求涉及的子系统需求涉及的产品版本号使用的验证方法或接受的测试标准产品的优先级或重要程度（例如高、中、低或）需求的稳定性（在将来需求可能变更的指示器，不稳定的需求意味你应给予较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。）,建议的需求状态表,状态跟踪示例,1.2 需求变更管理,应仔细评估已建议的变更。挑选合适的人选对变更做出决定。变更应及时通知所有涉及的人员。项目要按一定的程序来采纳需求变更。,控制项目范围的扩展,扩展需求是指在软件需求基线已经确定后
5、又要增添新的功能或进行较大改动。问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较大的影响。要是每个建议的需求都被采纳，对于项目出资者（sponsor）、参与者与客户来说项目将永远也不会完成事实上，这是不可能的。,控制项目范围的扩展,对许多项目来说，一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整。在你的项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不断地采纳新的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。,管理范围扩展,管理范围扩展的第一步就是把
6、新系统的视图、范围、限制文档化并作为业务需求的一部分。评估每一项建议的需求和特性，将它与项目的视图和范围相比较决定是否应该采纳它。强调客户参与的有效的需求获取方法能够减少遗漏需求的数量，只在做出提交承诺和分配资源后才采纳该需求。控制需求扩展的另一个有效的技术是原型法，这个方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确把握用户的真实需求。要敢于说“不”。,变更控制策略,所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。对于未获批准的变更，除可行性论证之外，不应再做其它设计和实现工作。简单请求一个变更不能保证能实现变更，要由项目变更控制
7、委员会（C C B）决定实现哪些变更。项目风险承担者应该能够了解变更数据库的内容。绝不能从数据库中删除或修改变更请求的原始文档。每一个集成的需求变更必须能跟踪到一个经核准的变更请求。,简单变更控制步骤模板,绪论目的范围定义角色和责任变更请求状态开始条件,任务产生变更请求评估变更请求作出决策通知变更人员验证结束条件,变更管理活动中可能的项目角色,变更控制委员会的组成,产品或计划管理部门。项目管理部门。开发部门。测试或质量保证部门。市场部或客户代表。制作用户文档的部门。技术支持部门。帮助桌面或用户支持热线部门。配置管理部门。,常见变更请求数据项,变更需求状态转换图,测量变更活动,接收、未作决定、结
8、束处理的变更请求的数量。已实现需求变更（包括增、删、改）的合计数量（也可以用在基线上占需求总数的百分比来表示）。每个方面发出的变更请求的数量。每一个已应用的需求（是指已划过基线）建议变更和实现变更的数量。投入处理变更的人力、物力。,工作量（劳动时数）任务_ 更新软件需求规格说明书或需求数据库_ 开发并评估原型_ 创建新的设计部件_ 修改已有的设计部件_ 开发新的用户界面部件_ 修改已有的用户界面部件_ 开发新的用户文档和帮助文件_ 修改已有的用户文档和帮助文件_ 开发新的源代码_ 修改已有的源代码_ 购买和集成第三方软件_ 修改构造文件_ 开发新单元测试和综合测试_ 进行单元测试和综合测试_
9、写新的系统测试实例_ 修改已有的系统测试实例_ 修改自动测试驱动程序_ 进行回归测试_ 开发新报告_ 修改已有的报告_ 开发新的数据库元素_ 修改已有的数据库元素_ 开发新的数据文件_ 修改已有的数据文件_ 修改各种项目计划_ 更新别的文档_ 更新需求跟踪能力矩阵_ 检查工作产品_ 根据测试和检查情况返工_ 总计劳动时数,影响分析报告模板,变更请求I D_标题_描述_分析者_日期_优先权评估：相关收益_（1-9）相关代价_（1-9）相关成本_（1-9）相关风险_（1-9）最终优先级_预计总耗时_劳动时数预计损时_劳动时数预计对进度的影响_天数额外的成本影响_金额质量影响_被影响的其他需求_被影
10、响的其他任务_要更新的计划_综合的事项_生存期成本事项_可能的变更所需检查的其他部件_,1.3 需求跟踪,一些可能的需求跟踪能力联系链,RequisitePro Project Organization,Toolbar,Project icon,Package,Document,Views,Requirements,Working in a View,Existing Artifacts for RU e-st Project,RM Plan,Included on Exercise CD,RU e-stProject,Exist in the project,Create in the pr
11、oject,Import into the project,Create a Requirement in the Explorer or in a View,User Documentation Specifications,Design Specifications,Use-Case Model,Supplementary Specifications,Features,SoftwareRequirements,Needs,Requirements and Associated Documents,Design,Test,Documentation Requirements,Delete a Requirement in a Document,
