需求分析师培训教材.ppt

需求分析师 需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道 典型活动：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求 必备技能：倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力 需求分析师 必备知识：现代需求管理技术、各种软件开发生命周期、领域知识 需求分析员的来源：用户转为分析员（软件工程知识欠缺）、开发人员转为分析员（领域知识、沟通能力）、主题专家（易按自己的偏好来构建系统） 需求过程 需求过程 需求大纲--SERU模型 Subject：主题域，将一个复杂的大系统分解成由确定接口相互连接的多个子系统—构件图 /System?（上下文关系图、事件列表、Report列表）/Subject Event：业务事件，信息系统行为主线条—（业务流程图、领域类图[E/R图]、用例图[opt]）/Event Report：查询、分析、统计等管理动作—（目的、数据、虚拟屏幕） /Report Use case：需求管理的分子！ 用户需求 用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。 用户有不同类型： 管理型、事务型 信息系统、人 决策层、使用层 常用者、偶用者 组织方法：用例、用户故事、特性 例子：对快到期的客户，系统将通过短信将续保信息发给该客户的代理人 软件需求 从系统实现的角度描述的需求。 开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。 有时还需要考虑相关联的硬件、环境方面的需求 功能需求 功能需求是需求的主体，是需求的本质 功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作 零散（需求项）?整理（特性、用例） 敏捷方法：用户故事 质量属性 产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间特性、资源特性 可维护性：易分析性、易更改性、稳定性、易测试性 可移植性：适应性、易安装性、一致性、易替换性 McCall体系：运行(正确性、可靠性、效率、完整性、使用性)、修正(维护性、测试性、灵活性)、转移(移植性、复用性、共运行性) 设计约束 也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。 例如：必须采用国有自主知识版权的数据库系统… 再如：必须运行在UNIX操作系统之下 三如：用户将在户外完成作业 优秀的需求 完整性：完整描述即将交付使用的功能，发现缺少某项信息，可以采用TBD来标注 正确性：经过用户或用户信任的代理人审阅 无歧义：对所有读者只有一种一致的解释 必要性：每项需求记录的功能都应是用户真正需要的 有优先次序：提供了实现优先级 可行性：在已知能力和约束条件中实现 可验证性：可以设计测试方法来检查 Agenda 不同软件项目的需求视图 软件需求误区与应对之道 需求工程组织与实作要点 需求错误的代价 需求开发与管理 需求开发活动 需求获取 应收集什么信息： 问题域的描述--业务模型 要求解决的问题列表（需求） 用户对解系统的行为或结构施加的任何约束 信息来源： 客户（实际的和潜在的） 任何原有解系统（已有系统）及其文档 原有系统用户 / 新系统的潜在用户 应用（问题）领域专家 定义了任何接口系统的特片和行为的文档 相关的技术标准和法规 需求获取技术 阅读背景资料 头脑风暴 讨论分析 文档考古 面谈（用户访谈） 联合应用设计 用户调查 需求剥离 现场观摩 任务观察 用例和场景 需求获取的误区 缺乏计划性：随意、走过场，预先没计划 缺乏科学性：未从本质入手 捕获对象不明确，甚至造成岐义 过于迷信现有文档 过于迷信“听”到的东西 需求分析 所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明 分析方法：结构化分析法、面向对象分析法、面向问题域分析法 任何分析法，均需描述以下几个方面: 问题域的结构 问题子域的固有属性及行为 问题域中的重要事件及现象 需求：应产生的效果 需求分析方法--结构化分析 从基于文本分析和规格文档?图形建模表示法 结构化分析初期的模型：数据流图+E-R图 数据流图：体现了流程，但是以数据为中心的流程 E-R图：体现了要存储的信息 数据字典：对数据、数据流的描述 对问题域的研究力度不够大 分析和设计之间缺乏清晰的界限