用实例说明需求工程的设计原则和描述方法.pptVIP

多视点分析： 例如围绕着超市收银系统 顾客希望？ 收银员希望？ 经理希望？ 系统管理员希望？ 最终的软件系统是相关方的综合体，各种期望可能存在冲突，需要进一步分析权衡 第三十页，共六十四页。 需求协商 讨论需求冲突，折衷方案 协商不是简单的逻辑或技术上的争论 要注意组织和行政方面的因素 不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异 第三十一页，共六十四页。 通常会议是解决冲突最快的方式 参加者：发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 会议应该讨论那些非正式讨论不能解决的问题 通常会议分为三个阶段： 叙述阶段 讨论阶段 决策阶段 第三十二页，共六十四页。 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 第三十三页，共六十四页。 需求规约的原则-1 从现实中分离功能，即描述要“做什么”而不是“怎样实现” 认识模型，而不是设计或实现的模型 使用面向处理的规约语言(或称系统定义语言) 第三十四页，共六十四页。 需求规约的原则-2 规约必须包括系统运行环境 规约必须是可操作的 第三十五页，共六十四页。 需求规约的原则-3 规约必须允许不完备性并允许扩充 规约必须局部化和松散耦合 第三十六页，共六十四页。 需求规约 第三十七页，共六十四页。 引言：陈述软件目标，在基于计算机的系统语境内进行描述。 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。 功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。 行为描述：描述作为外部事件和内部产生的控制特征的软件操作。 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。 附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。 第三十八页，共六十四页。 需求验证 需求验证目的是要检验需求是否能够反映用户的意愿 评审人员评审时往往需要检查以下内容： 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求； 被开发项目的数据流与数据结构是否确定且充足； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 设计的约束条件或限制条件是否符合实际； 开发的技术风险是什么； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。 第三十九页，共六十四页。 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 第四十页，共六十四页。 需求管理 需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动 需求跟踪有两种方式，正向跟踪与逆向跟踪 正向跟踪：《需求规约》 后继工作产品 逆向跟踪： 工作产品 《需求规约》 第四十一页，共六十四页。 需求变更的原因 初期的认识不足导致错误或不完整的需求 需求本身存在不一致 业务变化导致的刚性需求变更 外部经济、市场环境的变化 客户和项目组对已确认的需求理解不一致 技术制约或多目标权衡带来的需求变更 第四十二页，共六十四页。 关键实践 唯一标识每项需求并进行的系统管理 分级的需求管理 需求变更管理过程支持 需求生命周期及依赖性管理 变更影响分析及需求变更决策 第四十三页，共六十四页。 唯一地标识每一项需求 为每一项需求分配一个唯一的标识符 自动编号：如word中的章节编号 有意义的标识符：如pos-1,store-1,ETF-1…. 在他处可以明确引用该项需求 使用一套基于数据库的系统管理需求 系统地记录每项需求及其追踪关系 方便查询和统计 需求版本管理的基础 第四十四页，共六十四页。 分级的用户需求管理 五个需求等级 Urgent:必须立刻优先实现 Necessary:必须实现，但不一定马上进行 Needed:需要的，不过没有也还凑合 Better:现在似乎也可以，但可以更好一点 Useful:总会有用的 正常情况下用户需求应该相对平均地分布在这五个等级上 分级管理策略：满足核心的用户需求同时说服用户将其它需求搁置或纳入下一版本 第四十五页，共六十四页。 用实例说明需求工程的设计原则和描述方法 计算机学院 关皓文 201313273 第一页，共六十四页。 需求的定义 用户解决一个问题或