第一次第三章需求获取

1、-1-软件需求分析与规范 金英 博士, 教授, 博导吉林大学 计算机科学与技术学院2011.07-2-课程内容1. 软件需求的基本概念2. 需求工程概述3. 需求获取 4. 需求分析与建模5. 需求规范说明6. 需求验证 7. 需求管理-3-第三章 需求获取3.1 需求启动3.2 需求获取的任务3.3 需求获取技术-4-需求工程过程需求启动需求获取需求分析需求规范说明需求验证需求管理设计项目可行性分析报告项目计划书需求规范说明(需求分析文档)-5-第三章 需求获取3.1 需求启动3.2 需求获取的任务3.3 需求获取技术-6-3.1 需求启动需求启动的主要任务需求启动产生的文档-7-3.1 需

2、求启动需求启动是需求工程过程的起始,可以作为单独的活动,也可以作为需求获取活动的一部分;启动需求阶段, 包括:确定商业需求和市场机会，进行可行性分析，明确系统范畴，风险分析等等-8-3.1 需求启动需求启动的主要任务包括:确定项目问题定义，即确定项目的前景和范畴边界和范畴确定涉众确定商业需求确定项目相关约束条件和限定实施可行性研究-9-3.1 需求启动需求启动生成的文档项目前景和范畴文档项目可行性报告项目计划书-10-项目前景和范畴文档1.商业需求 Business Requirements 1.1.背景、商业机会和用户需求 1.2.商业目标和成功标准 1.3.商业风险前景 2.1.前景声明

3、2.2.主要特征 2.3.假设和依赖条件3.范畴和限制 3.1.初始及其之后版本的范畴 3.2.限制和排除项目4.商业上下文环境Business Context 4.1.涉众概述 4.2.项目优先级 -11-项目可行性报告ISO标准 模版-12-项目计划书1引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料 1.5 标准、条约和约定 2. 项目概述 2.1 项目目标 2.2 产品目标与范围 2.3 需求分析 2.4 项目工作范围 2.5 应交付成果(项目产出) 2.5.1 需完成的软件 2.5.2 需提交用户的文档 2.5.3 须提交内部的文档 2.5.4 应当提供的服务 2

4、.6 项目开发环境 2.7 项目验收方式与依据 -13-项目计划书3. 项目团队组织 3.1 组织结构 3.2 人员分工 3.3 协作与沟通 3.3.1 内部协作 3.3.2 外部沟通 4实施计划 4.1 风险评估及对策 4.2 工作流程 4.3 总体进度计划 4.4 项目监控 5. 预算 5.1 人员成本 5.2 设备成本 5.3合计经费预算 6. 可行性分析和方法实现-14-第三章 需求获取3.1 需求启动3.2 需求获取的任务3.3 需求获取技术-15-3.2 需求获取的任务需求获取的含义需求获取的目标（objectives）需求获取的内容（what？）需求获取的信息源（where？）需

5、求获取方法（How?）不同的需求获取方法和技术-16-3.2 需求获取的任务需求获取的含义需求获取是一个发现待开发系统的需求并且与 客户、系统使用者以及其他涉众沟通的过程。包含两个活动发现需求(收集需求)沟通(communication)-17-3.2 需求获取的任务需求获取的目标（objectives）确定获取需求的信息源，以及将采用的合适的需求获取技术获得详细的关于问题域、问题定义、过程和约束生成需求文档主要内容是用户需求和获取需求过程中的记录往往可能是不完整、无序和不一致的-18-需求获取的目标信息来源 用户原有系统文档客户需求获取（技术）“未加工”的需求、数据、约束等需求分析和建立规格

6、说明获取的信息记录-19-3.2 需求获取的任务需求获取的内容（what？）问题域（ problem domain）待开发的系统是什么？系统目标待开发系统的功能存在的问题及解决方案约束条件-20-3.2 需求获取的任务需求获取的信息源（从哪里获取需求？）各种涉众：客户、用户、经理、领域专家、开发人员、市场人员、律师、已经存在的系统已经有的文档竞争系统关于用户接口的文档相关的（行业）标准、政策、协议、法律文件等-21-如何获取需求？需求获取技术传统技术其他技术阅读已有文档分析数据面谈调研/ 调查问卷 会议头脑风暴联合应用设计 (JAD)原型系统用例-22-第三章 需求获取3.1 需求启动3.2

7、需求获取的任务3.3 需求获取技术-23-3.3 需求获取技术分析已有系统面谈头脑风暴原型系统用例-24-分析已有系统适用：当开发一个已有系统的升级版需要了解:哪些保留、哪些放弃、哪些缺失需要增加哪些运行很好、哪些有待改进系统是如何被使用的，希望如何使用-25-需求获取技术 (2)Interviews（面谈）-26-面谈需要做好准备工作以及良好的沟通管理能力能够达到面谈的目的, 有助于挖掘潜在的信息和尽可能多的涉众面谈不仅仅是用户和客户通过问题来引导面谈询问细节, 但同时.不要因为细节问题而忽视用户真正的需求-27-面谈3个主要目标:记录获取的需求信息，把它们作为需求分析和建模的输入从面谈对象

8、中准确和有效地发现需求信息和面谈对象再次确认对获得的需求信息的理解面谈过程包含4个步骤:作计划和准备面谈阶段明确信息后续跟进-28-面谈最常用的需求获取技术适用：所有的软件开发项目，种类结构化的 对面谈问题和过程有明确的议程安排开放式的 没有提前设定议程-29-面谈优势可以收集较丰富的信息对于发现观点、情感、目标和真实情况很有帮助可以深入挖掘信息，通过反馈信息调整后面的提问不足获得大量数据，难于分析面谈需要技巧，难于掌握-30-需求获取技术 (3)Brainstorming（头脑风暴）-31-头脑风暴适用：当需要发明新的做事方式或者没有更多可参考信息时采用的方法，通常如下情形下：当idea太少

9、或者太多时在项目早期的如下情形下:领域不确定没有经验可借鉴需要创新-32-头脑风暴主要活动:风暴: 产生尽可能多的idea (强调数量而不是质量) !平静: 过滤 (结合, 澄清, 优先级, 提升) 后保留最好的，可能需要投票机制删除投票工具支持参与角色: 记录员, 协调员，参加人员-33-头脑风暴优势可以听到每个人的想法;鼓励创新;对于开发全新铲平很有好处；不足难于过滤难于设定一个接受标准-34-需求获取技术 (4)Prototyping （原型）-35-建立原型系统一个软件原型系统是实际软件系统的实体模型或者部分实现，可以帮助开发人员、用户和客户更好地理解系统需求帮助弄清和完善需求可能帮助

10、发现新功能，讨论可用性，并建立优先级便于和有关人员沟通“先看到系统才知道需求”-36-建立原型系统适用：原型系统对于在项目早期解决不确定需求非常有效将原型系统的开发专注于不确定的部分鼓励用户的参与，并达成共识-37-原型系统的形式:纸质原型Paper prototypes索引卡片Prototype on index card故事板Storyboard屏幕模型Screen mock-ups交互原型系统Interactive prototypes用高级语言开发 (e.g., Visual Basic, Delphi, Prolog)用脚本语言开发 (e.g., Perl, Python)用动画工具

11、 (e.g., Flash/Shockwave)模型 (executables)导航系统-38-原型系统分类横向型: 关注于系统的某一个层面，通常是用户界面纵向型: 关注于实际系统的一个片断演化型: 增量式地形成最终产品，让用户可以看到可工作的系统，从理解的最好的需求开始；抛弃型:专注于理解的不好的部分，不够精确，将被抛弃；-39-需求获取技术 (5)Use Cases（用例）-40-用例什么是 “用例”?场景 什么是“场景”?用例 vs. 场景场景类型场景的表示方法用例驱动的软件开发方法开发用例用例模板-41-用例什么是 “用例”?场景 什么是“场景”?用例 vs. 场景场景类型场景的表示方

12、法用例驱动的软件开发方法开发用例用例模板-42-什么是 “用例”?一个用例应描述的是用户和系统的交互 .不是系统如何进行计算过程通常，一个用例应覆盖一个任务从开始到结束的所有步骤序列一个用例应只包含某个角色和系统交互的活动适用：描述和交流系统的功能和交互行为；-43-举例：“用户登录”用例用户登录用例名称用户登录实现名称Logon用例描述用户通过输入用户名和密码并被系统认可后可登录系统前置条件1、用户所使用计算机可以访问系统2、用户已经拥有登录系统的用户名和密码后置条件1、用户进入系统；2、系统启动用户权限对应的用例基本流1、用户进入系统登录界面2、用户输入用户名和密码，选择登录系统3、系统检

13、验用户名和密码4、系统确认登录成功-44-用例什么是 “用例”?场景 什么是“场景”?用例 vs. 场景场景类型场景的表示方法用例驱动的软件开发方法开发用例用例模板-45-什么是 “场景”一个场景 是一个用例的一个实例它表达的是一个用例特定的一个路径在特定时间 .特定数据下 从一个用例中可以得到很多场景每个场景需要很多的测试用例-46-用例 vs. 场景 （比较）一个用例包含主场景和附属场景1 个主场景正常的事件过程0或多个附属场景可选/异常 事件过程, 例子：达成共识主场景: 会议投票可选场景: 在多个会议中投票异常场景: 如果没有一个注册人愿意投票怎么办？-47-举例：“用户登录”用例用户

14、登录用例名称用户登录实现名称Logon用例描述用户通过输入用户名和密码并被系统认可后可登录系统前置条件1、用户所使用计算机可以访问系统2、用户已经拥有登录系统的用户名和密码后置条件1、用户进入系统；2、系统启动用户权限对应的用例基本流1、用户进入系统登录界面2、用户输入用户名和密码，选择登录系统3、系统检验用户名和密码4、系统确认登录成功异常场景 1：用户在登录界面没有选择登录，而是取消登录；异常场景 2：系统不认可用户输入的用户名和密码，登录失败-48-场景的不同类型As-is 场景Used in describing a current situation, usually used in

15、 re-engineering projects, the user describes the systemVisionary 场景Used to describe a future system, usually used in greenfield engineering and reengineering projectsCan often not be done by the user or developer aloneEvaluation 场景User tasks against which the system is to be evaluatedTraining 场景Step

16、 by step instructions that guide a novice user through a system-49-场景的表示方式不同的方法文本 (informal, formal), 图 (state, sequence .), 视频, 动画, 漫画, 故事板, -50-场景的表示方式特定的记号系统 UML (sequence, activity, use case, interaction, and collaboration diagrams), Message Sequence Charts (MSC), Live Sequence Charts, Use Case

17、Maps (UCM)-51-用例什么是 “用例”?场景 什么是“场景”?用例 vs. 场景场景类型场景的表示方法用例驱动的软件开发方法开发用例用例模板-52-用例驱动的软件开发生命周期-53-用例什么是 “用例”?场景 什么是“场景”?用例 vs. 场景场景类型场景的表示方法用例驱动的软件开发方法开发用例用例模板-54-用例的开发1. 确定待开发系统的范畴和边界确定涉众确定问题 使用面谈或者其他技术-55-用例的开发2. 确定角色谁和系统交互?谁使用系统?使用系统目的?充当的角色?谁安装系统?谁启动或者关闭系统?谁维护系统?谁向系统获取/提供信息?可以对角色进行通用化-56-用例的开发3. 确

18、定用例确定角色的目标为什么该角色使用系统?确定角色为了达到目标要做的任务什么样的交互可以满足角色的目标?选择合适的用例名称动-名结构不用包含特定情形的数据不与组织结构、格式、实现相关联生成简单描述（依据叙述格式）-57-用例的开发4. 确定前提条件 启动本用例应满足的条件5. 确定后置条件 完成本用例后所满足的条件-58-用例的开发5. 定义主场景当系统正常运行时的情形6. 定义辅助场景 (可选/异常)可选场景：其他可能的路径异常场景：出错情形-59-用例图（用例之间关系）7. Structure use case diagramIdentify commonalities and speci

19、fy included use casesIdentify variants and specify extended use cases-60-用例什么是 “用例”?场景 什么是“场景”?用例 vs. 场景场景类型场景的表示方法用例驱动的软件开发方法开发用例用例模板-61-用例模板有不同形式的用例模板，通常包含如下内容:标识: 可以在其他地方应用的唯一标识名字: 清晰表述用户任务作者: 发现用例的人目标: 简单描述从用户角度期望的输出前提条件: 在启动本用例前应满足的条件后置条件: 完成此用例后的状态-62-用例模板主角色: 初始化用例参加人(辅助角色): 用例中涉及到的其他角色相关联的需求: 与本用例向关联的功能性和非功能性需求标识相关联的用例，并指明相互之间的关系事件描述 (场景)不同的用例描述方式叙述式, 单栏式, 多栏式-63-用例模板：叙述式-64