软件需求捕获与管理.pptVIP

软件需求捕获与管理 田雪松 基本概念 需求捕获?《用户需求规格说明书》 《业务用例规约》 《风险评估报告》 《名词表》 需求分析?《软件需求规格说明书》 《系统用例规约》 系统分析?《概要设计》 《系统架构设计》 系统设计?《详细设计》 给出接口中方法、属性的详细说明 基本概念 需求概念（IEEE，1997） 用户解决问题或达到目标所需的条件或功能。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或功能。 一种反映上面（1）或（2）所描述的条件或功能的文档说明。 需求特性 难于捕获，却易于变化 需求工作 需求捕获 需求管理 需求捕获步骤 需求捕获步骤 项目愿景 涉众分析 业务边界 业务主角 业务用例 业务建模 需求确认 需求捕获步骤 开始前…… 需求捕获是项目组与客户在业务层面上达成一致的过程。 业务在你出现之前就已经有了 用户往往不知道自己想要什么 多数客户不会意识到需求的重要性 多数客户不认为在需求捕获中要承担责任 开始前…… 由粗而细，不要一头扎进去，不要过早涉及细节，细节是最易变的内容。 业务架构 业务流程 业务规则 典型问题 “这地方用红色好还是蓝色好？” “你喜欢用单选框还是下拉菜单？” …… 开始前…… 最好是在半年时间内完成一个项目 大多数超过半年的项目将毫无悬念地成为无底洞（为什么？） 如果的确是很大的项目，最好说服客户拆分成多个合同，并对每个合同定义明确的基线 明确需求是减少需求变更的最有效办法！ 第一步，项目愿景 项目愿景是客户建设系统的最终愿望 为什么要建设这个系统？ 建设这个系统要达到什么目的？ 了解以下内容，辅助明确愿景 业务概况 业务目标 人员情况 预算要求 工时要求 愿景特性：易于捕获，而极少变化 第一步，项目愿景 以文档形式固化项目愿景。 项目愿景的最佳格式是通过新建系统“为谁提供什么样的服务”或者是“满足谁什么样的愿望” 但我们往往是从项目招标书中，将项目建设目标直接摘出，作为项目愿景。 第一步，项目愿景 CRVM的项目愿景是什么？ 对客户关系价值进行统计分析，为公司进一步挖掘客户价值提供数据支持 对公司运营数据进行统计分析，为公司的战略决策提供数据支持 规范公司在销售、财务、采购、项目等各方面的管理，为各部门工作提供信息化支持 第二步，涉众分析 涉众是与要建设的项目相关的一切人和事，这些人或事应该是关注项目愿景，并对项目有明确的期望，项目愿景是否能达成会影响到其利益。 税务局是不是涉众？ 一般从以下几个方面去查找涉众： 项目投资方 项目使用者 项目规划者 项目管理者 两个原则：一是涉众是有明确期望的，二是涉众期望是独特的。 第二步，涉众分析 由项目愿景做进一步的访谈也可得到涉众 对客户关系价值进行统计分析，为公司进一步挖掘客户价值提供数据支持 第二步，涉众分析 涉众分析最重要的是找出涉众的期望，期望一定是与项目愿景一致 供货商期望多付款？ 员工期望任意采购？ 领导期望收入增加？ 客户期望不付款？ 第二步，涉众分析 涉众分析报告可以包括涉众概要、涉众简档等内容 涉众概要包括涉众名称、涉众说明、涉众期望等 涉众简档包括涉众名称、涉众代表、特点、职责、成功标准、意见等 验证： 每一个项目愿景至少由一个涉众去体现 每一个涉众至少属于一个项目愿景 第二步，涉众分析 第二步，涉众分析 划分优先级： 业务愿景优先级 涉众优先级 涉众期望优先级 根据优先级制订需求调研计划 第三步，业务边界 依据现有业务模块进行划分 依据业务愿景划分业务边界 第四步，业务主角 业务主角一定是一项完整业务的主动发起者 业务要处理的事务创建时为业务起始，处理完事务为业务结束。 业务主角来源于涉众，从中找出满足上述条件的涉众，升级为业务主角，这个涉众应该是系统的预期使用者。 很多情况下业务的内容就决定了谁是业务主角。 被动参与的涉众只能做为业务工人出现。 需求捕获阶段不区别人与系统之间的职责，只完整描述业务，由需求分析阶段划分哪些是人的职责、哪些是系统的职责 第四步，业务主角 验证： 一个业务主角至少代为行使一个涉众的期望； 一个涉众的期望至少有一个业务主角代为行使； 第五步，业务用例 业务用例一定是一个完整的业务过程 起始于业务要处理的事务创建时 结束于业务要处理的事务完成时 第五步，业务用例 EBP原则 基本业务过程，即 Elementary Business Process 含义：由一个人在某个时间某个地点执行一项任务，这项任务是对某一业务事件的反应，而且可以增加可度量的业务价值，并且能够保持数据状态的一致 第五步，业务用例 业务用例命名 用例命名不是越简单越好，以能够完整说明业务目标为准则 动词+宾语 检验标准： 业务主角+业务用例，能够形成一句完整的自然语言 系统用例的检验标准是什么？ 第五步，