需求开发及管理.ppt

* CCB:全称是Change Control Board——变更控制委员会 需求获取流程图 合同类项目 采取与用户会谈、现场调查等方法详细记录用户给定需求，形成《需求调研单》，然后进行需求风险识别、分类、筛选、优先排序，整理形成《用户需求列表》，并在此基础之上形成《用户需求说明书》； 研发部经理/项目经理组织会议讨论确认需求项，需要与用户方（/产品研发提出部门）就《用户需求说明书》的需求项达成一致意见，由用户或总工程师签字确认。 需求获取方法 新产品研发项目 对市场上已存在的同类产品/或超前产品进行调研，或从行业标准、规则中提取需求信息 ，形成《需求调研单》，然后进行需求风险识别、分类、筛选、优先排序，整理形成《用户需求列表》 ，并在此基础之上形成《用户需求说明书》； 研发部经理/项目经理组织会议讨论确认需求项，需要与用户方就《用户需求说明书》的需求项达成一致意见，由用户或总工程师签字确认。 需求获取方法（续） 产品升级类项目 分析从技术支持部或实施服务人员处反馈的用户新需求、系统缺陷，进行需求分类、评估、识别优先级，并考虑系统升级问题，形成《用户需求列表》 ，并在此基础之上形成《用户需求说明书》。 研发部经理/项目经理组织、讨论确定《用户需求说明书》，由研发部经理审核签字。 需求获取方法（续） 基于用例的需求获取步骤 定义项目的视图和范围（用户需求列表）； 确定用户类； 在每个用户类中确定适当的代表； 确定需求决策者和他们的决策过程； 选择你所用的需求获取技术； 运用需求获取技术对作为系统一部分的用例进行开发并设置优先级； 从用户那里收集质量属性和其他非功能需求； 详细拟订用例使其融合到必要的功能需求中； 评审用例的描述和功能需求； 如果有必要，开发分析模型用以澄清需求获取的参与者对需求的理解 开发并评估用户界面原型以帮助想象还未理解的需求； 从用户中开发概念测试用例； 用测试用例来论证用例、功能需求、分析模型和原型； 在继续进行设计和构造系统每一部分之前，重复6－13步骤。 谁是主要参与者，次要参与者？ 参与者的目标是什么？ 做事开始前有什么前提条件？ 参与者完成的主要工作或功能是什么？ 按照故事/业务场景所描述的还可能需要考虑什么异常？ 参与者的交互中有什么可能的变化？ 参与者将获得、产生或改变哪些信息？ 参与者必须通知系统外部环境的改变吗？ 参与者希望从系统获取什么信息？ 参与者希望得知意料之外的变更吗？ 用例检查点 太多的用例，注意合适的抽象级别。 用例冗余，使用“包含”关系，将公共部分分离出来写到一个单独的用例中。 用例中的用户界面设计，用例的重点就是用户使用系统做什么，而不是关心屏幕上是怎么显示的。 用例中包含数据定义，比如数据类型、长度、格式和合法值等，这些应当放到数据字典里。 试图把每一个需求与一个用例相联系，这是不可能的，需要使用规格说明书编写非功能需求、外部接口需求以及一些不能由用例得到的功能需求。 常见用例陷井 第六章 需求开发及管理 CMMI对应实践 需求开发及管理简述 需求开发及管理流程 需求获取 需求分析 需求评审 需求管理 需求分析 提炼、分析和仔细审查已收集到的需求 目的在于开发出高质量和具体的需求，以便作出实用的项目估算并进行设计、构造和测试 需要从不同的视角检验需求，增加查明错误、消除不一致性、发现遗漏的机率 创建分析模型之后，要不断改进，并分析评估其清晰性、完整性和一致性。 需求分析（续） 在用户需求描述(用户需求说明书)和软件设计之间建立桥梁 目标 详细描述客户需要什么 为软件设计奠定基础 定义在软件完成后可以被确认的需求 内容 详细的用例文本、用例图、活动图 类图、状态图、顺序图 数据流程、控制流程、处理说明 需求分析流程图 * 需求分析方法 面向结构分析法，结合获取的《用户需求说明书》，可采用数据流图等分析模型，把系统功能需求、非功能需求按事件流、数据流分析方式，逐层细化到系统操作及操作数据的存储方式，如数据的输入、输出，并考虑外部接口。结合数据流图和数据字典,详细说明系统功能间的输入、输出、系统活动及约束条件 ,编制需求规格说明书。 面向对象分析法，使用UML辅助类图或其他分析方式来分析已获取的系统需求、用例模型、类图、数据字典等。结合图形化分析模型、类图、顺序图、关联图等进行说明，准确描述用户及系统的交互活动 ，编制需求规格说明书。 快速原型分析法，分析已获取的用户需求，增量、迭代地明确用户工作流程、约束条件等，设定需求的优先级排序，在风险较小的基础上分析、设计和实现系统构架结构或用户界面架构。结合立项时所选用生命周期，迭代进行分析活动 ，编制需求规格说明书。 需求分析包含的元素 基于场景的元素——用户角度表现系统 用例文本 用例图 活动图 泳道图——带角色的