第03章需求工程讲解.ppt

复旦大学计算机科学与工程系 软件工程课程 软件工程 第3章 需求工程 软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” 。 可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者(stakeholder)都感兴趣的就是需求分析阶段。 这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。 这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础。 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动” Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理 Matthias Jarke和Klaus Pohl提出了三阶段周期的说法：获取、表示和验证 … … 本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。 需求开发和需求管理之间的区别 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 软件需求包括 功能需求 性能需求 用户或人的因素 环境需求 界面需求 文档需求 下面这些定义是需求工程领域中常见术语的定义说明。 软件需求包括三个不同的层次——业务需求、用户需求和功能需求（包括非功能需求）。 ⑴ 业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 ⑵ 用户需求（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。 ⑶ 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。 需求获取 需求获取时期的主要工作： ⑴ 归纳和整理用户提出的各种问题和要 求； ⑵ 弄清用户企图通过软件达到的目的； ⑶ 借助各种工具和方法，陈述用户提出 的实际需求，并标定软件的作用范 围。 需求获取方法 需求获取方法包括两个方面： ⑴ 指导开发小组获取用户需求的方法框架。 ⑵ 支持控制此项活动进展的过程控制机制。 需求获取方法与策略 建立顺畅的通信途径 访谈与调查 观察用户操作流程 组成联合小组 用况（Use Case） 建立顺畅的通信途径 建立分析所需要的通信途径，以保证能顺利地对问题进行分析。 访谈与调查 在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备： 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化； 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题； 提问和回答在汇总后应能够反映用户需求的全貌。 例子：“赛艇比赛成绩计算系统”的第一次面谈的准备计划 调查的方式 1. 调查提纲或调查表 2. 小型调查会议 3. 个别访问 4. 现场调查 5. 资料 6. 调查工具 调查中应注意的事项 1. 不要用计算机专业术语与用户或用户领域专家交谈 2. 不要使用“你应该…”这样的字眼 3. 始终记住自己最近一段工作中要达到的目标，引导用户说出你需要的信息 4. 要善于把用户中职位高的人和职位低的人的谈话结合起来分析 观察用户操作流程 到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。 组成联合小组 便利的应用规约技术(