20需求获取技术.pptVIP

二、需求获取技术 需求开发技术 建立负责需求的团队 需求调研(获取) 问题分析 需求启发、导出 需求分析 用例分析技术 有效的用例实践如何编写有效的用例 有效的用例模式 结构化需求分析 需求开发要解决的二个问题 如何获取正确的需求？ 如何表达需求？ 2、1 建立负责需求的联合团队 2.1建立并利用负责需求的联合团队 团队组成 具有编程背景的人,以获得描述所要求的准确性和精度 熟悉系统业务规则的人 了解系统如何应用的人（熟知在实际中如何使用系统的人） 具有决策权的人（能够决定放弃和保留） 人员素质 知识丰富 尽职尽责，坚定不移，态度积极 出色的沟通能力 尊生他人的观点 丰富的判断力和一个实用可行的方法 2.1建立并利用负责需求的联合团队 团队职责 就系统目标综合描述达成一致 需求调研、导出需求 分析需求 检查客户提供的需求描述，选出： 不良的需求、不真实的需求 修改或删除不良或不真实的需求 确定需求优先级 管理需求变更 2.1建立并利用负责需求的联合团队 团队聚会 经常性 到少每周一次 成员素质要求 1.思维方式 2.写作策略 2.建立并利用负责需求的联合团队 强调客户和供应商的作用 2.建立并利用负责需求的联合团队 强调客户和供应商的作用 要求客户： 建立项目领导小组 指定一名客户代表 指定一名需求确认人 指定一种需求沟通机制 …… 建议的需求开发过程 1. 定义项目的前景和范围 2. 确定用户类 3. 在每个用户类中确定适当的代表 4. 确定需求决策者和他们的决策过程 5. 选择你所用的需求获取技术 6. 运用需求获取技术对作为系统一部分的用例进行开发并设置优先级 7. 从用户那里收集质量属性的信息和其它非功能需求 建议的需求开发过程 8. 详细拟订用例使其融合到必要的功能需求中 9. 评审用例的描述和功能需求 10. 如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解 11. 开发并评估用户界面原型以助想像还未理解的需求 12. 从用例中开发出概念测试用例 13. 用测试用例来论证用例、功能需求、分析模型和原型 14. 在继续进行设计和构造系统每一部分之前，重复6 ~ 1 3步 需求获取的过程 定义需求开发过程 定义项目愿景与范围 将用户群分类并归纳各自特点 选择产品代表 建立核心队伍 确定用例 确定系统事件和响应 举行进一步需求获取的讨论 观察用户如何工作 检查问题报告 重用需求 确定产品愿景与范围 业务需求位于需求链中的最顶层，定义了软件系统的愿景与范围。用户需求和软件功能需求都必须符合业务需求设定的前景和目标。无助于系统达到业务目标的需求都不应包含在SRS中 产品愿景将所有涉众统一到一个方向上。愿景描述了产品用来干什么，它最终会是什么样子 项目范围确定当前项目要解决产品长远规划中的哪一部分。范围描述了产品应包括的部分和不应包括的部分。范围的说明在包括与不包括之间划清了界线。也就是说，范围同时定义了项目的限制。项目范围的细节体现于开发团队为项目定义的需求基线 愿景关系到整个产品。当产品战略定位或者信息系统的业务目标随时间发生改变时，愿景也会随之变化，但这种变化相对缓慢 范围则只与一个特定的项目或实现产品功能的下一增量某次迭代相关。与愿景相比，范围更为动态，因为项目经理可以在项目进度、预算、资源和质量的约束内对每个版本的内容进行调整 项目愿景和范围的文档 a. 业务需求 a.1 背景 a.2 业务机会 a.3 业务目标与成功标准 a.4 客户与市场需求 a.5 业务风险 b. 解决方案的愿景 b.1 愿景陈述 b.2 主要特征 b.3 假设和依赖 c. 范围和限制 c.1 第一个版本的范围 c.2 各后续版本的范围 c.3 限制和专用性 d. 业务背景 d.1 涉众简介 d.2 项目优先级 d.3 操作环境 关联图 对范围的描述确立了正在开发的系统与周围所有事物之间的界线和联系 关联图（context diagram）用图形方式说明了这一界线。图中标出了处于系统之外并与系统有某种接口的端点（terminator），以及端点与系统间的数据流和物流（material flow） 按结构化分析原理，并联图是数据流图中最顶层的抽象 关联图可以放在项目愿景与范围文档中，或者在SRS正文或附录中，也可以作为系统的数据流模型的一部分 示例 右图是化学制品跟踪管理系统的关联图的一部分。整个系统在图中表示为一个圆，关联图隐藏系统的内部对象、过程和数据 图中的箭头代表系统与端点之间传达室递的数据流（“化学制品请求”）或物品（“化学制品仓库”） 以矩形表示的端点则分别表示了用户类（“药剂师” ）、组织（“采购部门”）或硬件设备（“培训用数据库”） 需求的来源 与潜在用户进行交谈和讨论 描述现有产品或竞争产品的文档