软件工程——4需求分析基础.ppt

软件工程 SoftwareEngineering AnIntroduction 第四章需求分析基础 Chapter4FoundationofSRA SoftwareRequirementsAnalysis 相关概念需求分析基础需求分析的任务需求分析的一般性技术需求规格说明与评审SRA的实施 人的生命周期 婴儿 幼儿 儿童 少年 青年 中年 老年 死亡 软件的生命周期 软件定义 软件开发 软件支持 问题定义 可行性分析 需求分析 概要设计 详细设计 编码 测试 软件发布 软件运行 维护或退役 回顾 相关概念 回顾 相关概念 GB8566 88 计算机软件开发规范 生命周期阶段划分可引性研究与计划需求分析概要设计详细设计实现及单元测试 常简称为实现 集成测试确认测试使用和维护 回顾 相关概念 关于阶段的划分Softwarelifecycle 根据软件状态 特征 开发活动的目的 可以分为不同阶段 各阶段划分尚未统一 但其划分也不是任意的 典型划分 一 推荐典型划分 二 其它划分 回顾 相关概念 计划时期问题定义可行性分析开发时期需求分析软件设计编码测试运行时期软件维护 典型划分 一 推荐 关于阶段的划分 回顾 相关概念 需求分析 问题定义 可性行研究 计划时期 概要设计 详细设计 编码 测试 开发时期 运行与维护 运行时期 回顾 相关概念 关于阶段的划分 典型划分 一 推荐 回顾 相关概念 典型划分 二 回顾 相关概念 相关概念 问题定义 可行性研究 系统工程问题定义阶段需要解决的问题是 该软件项目要解决的问题是什么 可行性研究 分析是要决定 做还是不做 需求分析是要决定 目标系统必须做什么 不做什么 回顾 相关概念 Aftersystemengineeringiscompleted softwareengineersneedtolookattheroleofsoftwareintheproposedsystem Softwarerequirementsanalysisisnecessarytoavoidcreatingasoftwareproductthatfailstomeetthecustomer sneeds Data functional andbehavioralrequirementsareelicitedfromthecustomerandrefinedtocreateaspecificationthatcanbeusedtodesignthesystem Softwarerequirementsworkproductsmustbereviewedforclarity completeness andconsistency 需求分析 的主要内容 需求分析基础 面向数据流的分析方法 结构化分析 面向对象的需求分析 面向数据的分析 1需求分析的重要性 2需求分析的任务与原则 3需求分析的获取方法与建模 数据字典 数据流图 ER图 基于数据流的分析方法 面向对象的概念 面向对象方法简介 面向对象分析过程 面向数据结构的系统开发方法 Jackson系统开发方法 形式化方法 4 0需求分析概述 What sSRA TheImportanceofSRA需求分析的复杂性和困难性需求工程概念 SRA的工作过程 4 0需求分析概述 软件需求是指用户对目标软件系统在功能 性能 行为 设计约束等方面的期望 需求分析就是通过对应用问题及其环境的分析与理解 采用一系列的分析方法和技术 将用户的需求逐步精确化 完全化 一致化 最终形成需求规格说明文档的过程 系统分析阶段产生的系统规格说明和项目规划是软件需求分析的基础 分析人员需从软件的角度对其进行检查和调整 并在此基础上展开需求分析 需求分析概述 What sSRA SRA 获取 理解分析 并用书面形式完整 精确一致地表述出用户对目标系统的各种功能方面和各种非功能方面的需求 SE规范国家标准 一个软件需求是对拟开发的软件产品的某项基本功能或性能的一个陈述 软件需求的概念涵盖了用户角度 系统的外部行为 和开发人员角度 系统的内部特性 两个方面 其中的关键在于需求一定要文档化 4 0需求分析概述 相关概念 问题定义 可行性研究 系统工程需求分析阶段的任务 在可行性分析的基础上 进一步了解确定用户需求 将项目计划阶段确定的软件范围逐步细化到可详细定义的程度 并分析出各种不同的软件元素 准确地回答 系统必须做什么 的问题 写出需求规格说明书 需求分析概述 TheImportanceofSRA 试想当你完成软件开发后 用户认为该软件不是他所期望的而拒绝接收时 你怎么办 你的处境 SRA是软件开发的前提和基础 SRA过程中产生的文档资料 软件需求规格说明书SRS是软件开发依据 也是软件开发者与用户评估 验收软件产品的依据 软件错误源于分析阶段的比例高达50 60 一个错误发现得越晚 修复错误的费用越高 高2 3个数量级 随时间呈指数级增长 需求分析概述 TheImportanceofSRA 需求分析概述 TheImportanceofSRA 引入同一变动付出的代价随时间变化的趋势 TheCostofChange 需求分析概述 TheImportanceofSRA TheCostofChange 软件错误的积累和放大效应 需求分析软件设计编码软件测试 需求分析概述 TheImportanceofSRA 从Analyst的角色和要求看 需求工程 SE中最受重视和最活跃的研究领域之一 软件质量 系统所实现的需求 客户所期望的需求 需求分析概述 TheImportanceofSRA TherequirementsdocumentistheofficialstatementofwhatisrequiredofthesystemdevelopersAsoftwarerequirementsdocumentisanagreedstatementofthesystemrequirementsEstablishandmaintainagreementwiththecustomersandotherstakeholdersonwhatthesystemshoulddo Toserveasabasisforadesignorimplementation 需求分析概述 复杂性和困难性 1 用户对需求描述的零乱 模糊问题 2 用户与分析员之间的交流障碍问题 由于教育背景 专业领域不同或利益关系等 而造成误解或无法沟通 3 完整性问题 无法判断用户是否把他 们 所想要的已全部告诉你 也无法期望用户在短时间内把他 们 想要的一件不漏地告诉你 4 用户往往是一个群体 不同层面 不同部门的意见不一定完全相同 甚至有冲突 5 用户不一定能预见到计算机化能给他们带来的有价值的潜在需求 而你预见到的也许并非他们所想要的 6 需求永远不会稳定 7 编 审SRS的困难 8 需求的本质问题 复杂和庞大 模糊 不准确 难以检查和排除不一致 歧义 片面 不完全等 软件需求分析的困难 4 0需求分析概述 需求分析阶段的成果主要是需求规格说明 该成果又是软件设计 编码 测试直至维护的主要基础 需求分析是系统分析和软件设计的重要桥梁 是软件生存周期的关键性阶段 良好的分析活动能够减少错误和遗漏 从而可提高软件生产率和产品质量 降低开发与维护成本 需求分析概述 SRA的过程 需求工程概念 需求分析工作本身是一项工程 需求工程 需求工程是应用已证实有效的原理和方法 并通过合适的工具和符号 系统地描述出待开发系统及其行为特征和相关约束 需求 工程 过程 SRA工作过程可分为需求获取 需求分析 需求描述 需求规格说明 和需求评审 或称验证 等几个阶段 获取 分析 编写规格说明和验证等活动不是 也不应该是独立的 一次性地完成 而是交叉的 递增的和反复的 需求获取 与用户交流 获取第一手需求信息 需求分析 分析和整理所收集的用户需求 需求规格说明 编写需求文档 需求验证 用评审和商议等手段对需求进行确认 需求分析概述 分析活动的交叉 递增和反复 需求分析过程及相应文档 需求分析概述 SRA的过程 需求工程概念 需求分析 需求分析概述 需求工程的阶段 需求获取 通过与用户的交流 对现有系统的观察及对任务进行分析 从而开发 捕获和修订用户的需求 需求建模 为最终用户所看到的系统建立一个概念模型 作为对需求的抽象描述 并尽可能多的捕获现实世界的语义 形成需求规格 生成需求模型构件的精确的形式化的描述 作为用户和开发者之间的一个协约 需求验证 以需求规格说明为输入 通过符号执行 模拟或快速原型等途径 分析需求规格的正确性和可行性 需求管理 支持系统的需求演进 如需求变化和可跟踪性问题 需求分析概述 需求工程的阶段 SoftwareRequirementsAnalysisPhasesProblemrecognitionEvaluationandsynthesis focusisonwhatnothow ModelingSpecificationReview 需求分析的任务可通过需求获取 需求分析 需求描述和需求评审四个步骤来完成 本章后续内容主要介绍 需求分析的四个主要步骤及各个步骤的主要任务 进行需求分析的一般技术和方法简介 包括初步需求获取技术 需求建模技术 快速原型技术 多视点分析方法等 需求规格说明的作用和内容及需求评审的标准和评审过程等 4 0需求分析概述 1 需求获取 范围 环境 系统分析人员通过与用户的交流 了解业务现状以及对待开发系统的期望 确定系统或产品范围的限制性描述与系统或产品有关的人员及特征列表系统的技术环境的描述系统功能的列表及应用于每个需求的领域限制一组描述不同运行条件下的应用场景以及为更好地定义需求而开发的系统原型需求获取收集的 原始材料 为进行需求分析提供了基础 1 需求获取 范围 环境 需求的来源客户或用户 例如学院的高层管理者 项目投资人系统管理员教师 学生 图书管理员标准 例如图书资料的标准政策或法律 例如图书资料管理规程 知识产权和版权保护等系统或过程文档 例如当前手工管理的文件 表格 记录等相关领域的专家 1 需求获取 范围 环境 需求获取 搜集 理解 获取详细的 充分的用户对目标软件的需求信息 该信息应足以使得开发者能开发出一个使客户方和使用者都满意的产品 eliciting 1 需求获取 需求信息 资料收集与理解 功能性需求系统需要提供的服务或功能 如图书检索系统对特定输入的处理方式 如对非法输入的提示系统在特定环境下的行为 如长时间无操作时的屏保非功能性需求对系统功能或服务附加的质量约束 例如响应时间 容错性 安全性等 客户所关心的 外部质量 从系统开发和维护角度出发的质量属性 例如可理解性 可扩展性 可配置性等 软件开发或维护者所关心的 内部质量 软件所特有 数据需求 系统涉及的各种数据 它们的名称 内容 类型 数量 限制 约束条件 结构 等等 1 需求获取 需求信息 资料收集与理解 软件需求 功能需求性能需求环境需求可靠性需求安全保密要求 用户界面需求资源使用需求成本消耗需求开发进度需求预先估计以后系统可能达到的目标 案例 小型图书资料管理系统 问题描述某学院打算开发一个小型图书资料管理系统MiniLibrary 该系统基于Internet实现教师和学生对各种图书资料的借阅 查询和管理 图书管理员负责管理各种图书资料 查询图书资料信息 并进行图书的借阅管理 注册用户可以通过Internet随时查询图书资料信息和个人借阅情况 预订目前借不到的图书资料 并可以快捷地查找和浏览所需要的电子资料 提供适当的浏览器供用户阅读电子文献资料 要求用户界面友好 响应速度快 具有良好的可扩展性 1 需求获取 FunctionalRequirements 功能性需求 即拟开发的软件在职能上应做什么 通常包括系统的输入 系统必须完成的功能 系统的输出以及其它反应 通常包括 功能的划分和各项功能的详细描述例如MiniLibrary 用户可以从图书资料库中查询或者选择其中的一个子集 系统可以提供适当的浏览器供用户阅读电子文献 用户每次借阅图书应该对应一个唯一的标识号 它被记录到用户的帐户上 1 需求获取 FunctionalRequirements FunctionalRequirementsWhatinputsthesystemshouldacceptWhatoutputsthesystemshouldproduceWhatdatathesystemshouldstorethatothersystemsmightuseWhatcomputationsthesystemshouldperformThetimingandsynchronizationoftheabove系统做什么 系统何时做什么 系统何时及如何修改或升级 1 需求获取 Non functionalRequirements 1 需求获取 Non functionalRequirements 例如MiniLibrary 系统应在20秒之内响应所有的请求 系统每周7天 每天24小时都可以使用 对于一个没有经验的用户而言 经过两个小时的培训就可以使用系统的所有功能 1 需求获取 Non functionalRequirements 1 运行环境 或外部界面 需求 2 性能需求 3 过程需求 设计约束 4 其它 软件 产品质量属性需求 1 需求获取 Non functionalRequirements 1 运行环境 或外部界面 需求用户界面 如屏幕格式 报表格式 菜单格式等 硬件接口 机型 特性 内外存 外设 数据通信接口 等等 软件接口 支撑软件 如OS DBMS 网络软件等 控制方式 如本地或远程 操作与使用 制度 素质 技术水平 培训等要求 故障处理要求 1 需求获取 Non functionalRequirements 2 性能需求时间特性 如响应时间 数据转换与传输时间 运行时间等 通常还必须给出系统满负荷或超负荷运行时的能力和表现要求 适应性 灵活性 在操作方式 运行环境 与其它软件接口等发生变化时应具有的适应能力 资源有效性 机时 内外存 通讯端口 缓冲区的大小和数目等 数据精度系统规模 容量 用户量 终端数目 对每一可能的输入能够接收多少数据量 一次能处理多少个事件 等等 通常必须给出最大 最小和平均数目 1 需求获取 Non functionalRequirements 3 过程需求 设计约束标准化的约束实现方法约束交付约束 即 强加于设计与实现的限制 如受强制的标准 实现的工具 语言 数据库 资源限制 操作环境等的约束 1 需求获取 Non functionalRequirements 4 其它 软件 产品质量属性需求可用性可靠性可移植性安全保密性可维护性可重用性 例 数据需求 数据需求通常可归入功能性需求 但是由于它的重要性和独特性 特别是在数据密集型的应用问题 或称以数据库为中心的应用 中 常需对数据进行独立分析 称为数据分析 对数据的描述也常常独立成为需求Specification中的一部分或另外形成一份独立的说明书 数据需求说明书 例如 GB8567 88 数据需求 数据需求静态数据动态输入数据 动态输出数据内部生成数据数据定义 名称 内容 类型 数量 限制 约束条件 结构 等数据采集 要求和范围 输入的承担者 预处理 影响等 数据需求 数据需求分析与描述数据字典E R方法 E R模型类 对象模型语义数据模型JSD方法的数据结构图其它 Warnier图 IPO HIPO等 案例 小型图书资料管理系统 问题描述某学院打算开发一个小型图书资料管理系统MiniLibrary 该系统基于Internet实现教师和学生对各种图书资料的借阅 查询和管理 图书管理员负责管理各种图书资料 查询图书资料信息 并进行图书的借阅管理 注册用户可以通过Internet随时查询图书资料信息和个人借阅情况 预订目前借不到的图书资料 并可以快捷地查找和浏览所需要的电子资料 提供适当的浏览器供用户阅读电子文献资料 要求用户界面友好 响应速度快 具有良好的可扩展性 思考问题 分析以下描述 它们是否属于需求 普通读者必须注册成合法用户才可以使用该系统 用户可以预订目前借不到的图书资料 用户不希望自己的借阅记录被他人查阅 系统通过ADO与图书资料数据库连接 并从图书资料数据表中获得图书资料的基本信息 系统应该具有良好的可扩展性 思考 如果所开发的软件系统只是简单地替代现行的手工操作方式 是否可行 为什么 4 1需求分析的任务 2 需求分析 问题分析软件系统分析人员在这一步骤中的任务是根据对问题及其环境的理解与软件开发经验 改正用户需求的模糊性 歧义性和不一致性 排除由于用户的片面性和短期行为所导致的不合理要求 挖掘用户尚未提出但具有价值的潜在需求 并在用户的帮助下对相互冲突的要求进行折衷 使用户需求逐步精确化 一致化和完全化 4 1需求分析的任务 2 需求分析 问题分析用某种方法为原始问题及其软件解建立模型 以便精确地记录用户从各个视点 在不同抽象级别上对原始问题的描述 并包含了问题及其环境所涉及的信息流 处理功能 用户界面 行为及设计约束等各方面内容 于是可通过对模型的精确化来达到需求分析的目标 比如 可以采用面向数据流的分析方法 利用数据流图和数据字典等工具来建立模型 该模型是形成需求规格说明 进行软件设计的基础 4 1需求分析的任务 需求分析 问题分析 建模模型应帮助用户和分析人员发现 排除用户需求不一致 不合理的部分 挖掘潜在的用户需求 模型是分析人员根据问题创建的软件系统结构 包括与问题和环境相关的信息流 处理功能 用户界面 行为及设计约束 Requirementsengineeringprocesses 需求获取 导出 收集 抽取 调查 问题识别Requirementselicitation RequirementsGathering Problemrecognition需求分析 分析与综合 分析与协商 建模Requirementsanalysis Evaluationandsynthesis requirementsanalysisandnegotiation Modeling需求描述 需求规格说明Specification documenting需求验证 评审 确认Requirementsvalidation verification review checking需求管理Requirementsmanagement 在实际的开发过程中 获取 分析 建模 编写规约和验证这些需求开发活动不会是 也不应该是线性地 顺序地完成 实际上 这些活动是交叉的 递增的和反复的 分析活动的交叉 重叠 迭代反复和递增 2 需求分析与协商 对需求进行分类组织 分析需求之间的关系 检查需求的一致性 重叠和遗漏的情况根据用户的需要对需求进行排序 在需求获取阶段 经常出现以下问题 提出的要求超出软件系统可以实现的范围或实现能力不同的用户提出了相互冲突的需求含义模糊不清的需求 2 需求分析与协商 协商的过程就是讨论需求冲突 找出每个人都满意的折衷方案协商不是简单的逻辑或技术上的争论要注意组织和行政方面的因素不一致的目标责任的丧失或转移组织文化组织管理态度和士气部门差异 2 需求分析与协商 通常会议是解决冲突最快的方式参加者应该包括发现冲突 遗漏或重叠的分析员 以及可以解决发现的问题的项目相关人员会议应该讨论那些非正式讨论不能解决的问题通常会议分为三个阶段 叙述阶段讨论阶段决策阶段 是开发人员和用户一起调查和理解系统应用领域需求的活动 是一个有持续的反馈和重复的过程 需求分析 需求导出和分析 2 需求分析 分析过程 需求分析的过程定义系统的边界建立系统与其外部实体间的界限 明确接口处的信息流 分析需求可行性分析每一个需求实现的可行性 确定与实现相关的开发风险 确定需求优先级需求优先级有助于开发组织和版本规划 建立需求分析模型通过建立需求的多种视图 揭示出需求的不正确 不一致 遗漏和冗余等更深的问题创建数据字典确保客户和开发人员使用一致的定义和术语 2 需求分析 分析的任务 1 充分理解 分析每一项用户提出来的需求 2 澄清需求的模糊性 歧义性和不一致性 3 对有冲突的需求进行折衷 4 发现由于用户的片面性或短期行为所导致的不合理要求 5 挖掘用户尚未提出的但具有真正价值的潜在需求 6 为原始问题及其软件解建立模型 分析活动的焦点 需求分析的核心 建模 需求分析的核心 建模 建立软件模型是分析活动的焦点 建立软件模型是分析活动的关键 需求分析的核心在于建立分析模型 软件工程中 软件整个开发过程需要建模 软件开发过程的各个阶段也需要建模 不同的软件开发方法 即软件开发范型 最集中表现在它们模型的区别 所以 软件开发过程的一系列模型的建立标准 描述形式 应用规范等 是一种软件开发方法 范型 最核心的研究内容 建模方法 常用的分析 建模方法面向数据流的结构化分析方法 SA 面向数据结构的Jackson方法 JSD 面向数据结构的结构化数据系统开发方法 DSSD 面向对象的分析方法 OOA 建立动态模型的状态迁移图或Petri网等形式化方法面向构件的其它E R方法 需求分析模型 使用的方法不同 建立的模型也不相同 但是 一般必须建立以下几类模型 数据模型 功能模型 行为模型静态模型 动态模型所建立的模型必须是从抽象到精化的一个逐层分解在需求分析阶段 创建的模型 要着重于描述系统要做什么 而不是如何去做 不应涉及软件实现细节 Elementsoftheanalysismodel 需求分析模型 数据对加工象说明说明控制说明 E R图DFD图STD图 DD 数据模型 功能模型 行为模型 结构化分析模型的组成结构 面向对象分析模型的组成结构 对象 关系模型 类 对象模型 对象 行为模型 使用实例 UseCase 操作 属性 协作者 CRC索引卡片 4 1需求分析的任务 3 需求描述该步骤的主要任务是以需求模型为基础 生成需求规格说明和初步的用户手册 并制定软件产品验收测试计划 需求规格说明是软件项目的一个关键性文档 其中应包含对目标软件系统的功能 外部行为 性能 质量 可靠性 可维护性 约束条件和需求验证标准等的完整的描述 初步用户手册应包括目标软件系统的用户界面的描述和使用方法的初步构想 验收测试计划是进行软件产品验收测试的依据 4 1需求分析的任务 3 需求描述 文档遵循规范 内容全面 结构清晰 措辞准确 格式严谨 将初步用户手册作为分析文档 有助于分析人员从用户角度考虑软件需求 并鼓励用户尽早参予软件开发活动 可促使用户从人一机工程的观点去评审软件 用户手册通常能引发用户的各种评论 在SE过程中 早一些揭示这样的评论是十分有用的 4 1需求分析的任务 4 需求评审需求评审是软件开发过程中的一个重要的里程碑 需求评审的主要任务是分析人员在用户 客户 和软件设计人员的配合下对需求规格说明和初步用户手册进行审核 检验软件需求的精确性 完全性和一致性 并使用户 客户 和软件设计人员对规格说明和用户手册达成一致的理解 经过评审确认的需求规格说明将成为客户方与开发方的合同 如果评审未通过 比如发现了遗漏或错误 则必须进行迭代 直至通过评审为止 4 1需求分析的任务 分析活动对于大型软件项目 分析人员可以先对问题的某些子系统进行需求分析 描述与评审 子系统完成后 再对其它子系统进行分析 进而构筑整个系统的需求模型 4 1需求分析的任务 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型 解决目标系统的 做什么 的问题 4 1需求分析的任务 相关概念 问题定义 可行性研究 系统工程 过程及相应文档 4 2需求分析的一般性技术 为了克服困难 更有效地开展需求分析工作 软件系统分析人员必须掌握一些基本的需求分析技术 主要包括 初步需求获取技术 需求建模技术 快速原型技术 问题的分解与抽象 多视点分析技术等 4 2 1初步需求获取技术 原因 在分析阶段的初期 由于分析人员和用户的共同知识领域可能不多 致使分析人员对问题往往知之不多 而用户对目标软件的要求及对要求的描述常常是零乱而模糊的 从而会造成相互交流和相互理解上的困难 为了克服困难 获取初步需求 可以采用如下的技术手段 访谈与会议 观察用户工作流程 分析人员和用户组成联合小组 1 访谈与会议 分析人员采用个别访谈或小组会议的形式与用户进行初步交流 在访谈和会议之前 分析人员根据对问题的初步描述精心准备一系列问题 通过用户对问题的回答或互相商讨来逐步理解用户的需求 准备问题的原则有 首先应搞清一般性 整体性问题 然后再涉及细节问题 在组织问题时要尽量做到客观 公证 不应限制用户的自由发挥 所提问题汇总后应能反映应用问题及其子问题的全貌 并且不要过分详细 1访谈与会议 个别访谈或小组会议分析人员应精心准备问题 通过用户对问题的回答 逐步理解用户对目标软件的要求 1 循序渐进首先关心一般性 整体性问题 再讨论细节问题 2 客观 公正不应限制用户在回答问题过程中自由发挥 3 总结问题汇总后应能反映软件或其子系统的全貌 能覆盖用户对目标软件或其子系统在功能 行为 性能诸方面的要求 细节问题留待以后解决 2 观察用户工作流程 如果可能 可通过实际观察用户的手工操作过程来提取新系统的初步用户需求 观察手工操作过程不是为了模拟手工操作过程 而是为了获取第一手资料 并从中提取出有价值的需求 分析人员有了第一手资料 再结合自己的软件开发和应用的经验 就能够发现不合理的用户需求 提出用户还没有意识到的潜在的但却很有价值的用户需求 并能够从软件的角度改进操作流程和操作规范 从而可获得用户满意的分析结果 2 观察用户工作流程 通过实际观察用户的手工操作过程来提取新系统的初步用户需求 第一手资料软件开发和应用的经验 发现不合理的用户需求 提出用户还没有意识到的潜在的但却很有价值的用户需求 获得用户满意的分析结果 观察手工操作过程 3 用户和开发人员共同组成联合小组 目的 为加强信息沟通 减少误解和避免产生遗漏 充分调动用户的积极性 方法 建立由开发方和用户方共同组成的联合小组 联合小组成员 双方的分析人员专门的记录员负责会议议程的人员资料员另外 制定小组的规章制度和计划 选定一种易于理解 简洁 精确的表示机制作为双方的共同语言 比如采用带文字说明的流程图等 4 间接调查研究 市场调研调查提纲 调查表查阅资料学习用户的有关业务知识 在用户帮助下了解用户的软件或子系统业务流程 结合软件开发和应用的经验提出新的用户需求 4 间接调查研究 调研问卷 部门的名称 人员数量和结构部门发展或变化简单介绍部门的主要任务业务处理流程业务处理过程中涉及哪些专业领域的知识工作需要的审批流程是什么 主要算法描述哪些业务需要实时处理 哪些业务需要交互操作 4 间接调查研究 调研问卷 部门各岗位的职责部门接受哪些部门或外界的信息 信息的内容和格式是什么 部门产生哪些信息 部门产生的信息送到哪些其他部门 格式要求是什么 对信息的输入和输出方式有要求吗 输入输出设备是什么 数据要求实时备份吗 备份的设备是什么 时间策略 业务处理有高峰期吗 高峰时间是什么 时间策略 现有的哪些设备要继续使用 4 间接调查研究 调研问卷 对产品的运行环境有要求吗 对界面风格和操作方式有要求吗 在系统运行过程中允许停机吗 操作方式要根据操作环境和使用人员素质分类吗 需要的操作权限有哪些 需要记录系统操作运行日志吗 用户有能力进行系统维护吗 需要分布式处理吗 需要什么方式的用户操作培训 需要制作联机帮助吗 5 问题分析与确认 不能期望用户在一两次交谈中 就会对目标软件的要求阐述清楚 也不能限制用户在回答问题过程中的自由发挥 在每次访谈之后 要及时进行整理 分析用户提供的信息 去掉错误的 无关的部分 整理有用的内容 以便在下一次与用户见面时由用户确认 同时 准备下一次访谈时的进一步更细节的问题 如此循环 一般需要2 5个来回 4 2 1初步需求获取技术 通过各种可能的渠道与各种不同的用户群和各种不同层次的用户进行交流 访谈与会议 观察用户工作流程 分析人员和用户组成联合小组 市场调研调查提纲 调查表查阅资料 例4 1 这里以 家庭保安系统 为例 简要说明初步需求的获取过程 假设用户的原始需求描述如下 根据家庭保安市场的增长趋势 我们希望建立一种基于微处理器的家庭保安系统 它能够识别异常事件并采取相应的报警措施 这些异常事件有 非法进入 火灾 水淹 等等 当传感器一旦探测出相应的异常事件时 系统应自动用电话向监控中心报警 此外 系统应允许户主对其行为实施程序式控制 例4 1 为进行初步的需求分析 这里采用开发方和用户方组成联合小组的方法 为此 联合小组应制定工作制度 每次会议开始前必须有确定的议程 小组成员必须针对议程进行充分准备并应形成文字 联合小组会议首先应明确问题的范围 问题与环境的关系 并就开发软件产品的必要性达成共识 小组负责人要求每位参加者根据负责的范围列出应用问题及环境中有关的对象 对象的操作及对象间的关系 如 市场营销人员列出控制面板 电话机 监控中心等对象和用户编程控制 电话拨号 报警等操作 负责传感器的用户可能列举烟雾传感器 门窗监视器 警报器等对象 例4 1 将对这些列举的对象和操作进行更详细的讨论和描述 比如 详细地描述接收传感器事件 用户编程控制 电话报警等操作等 用户可能提出一些约束条件 比如 造价不应超过3000元 对传感器事件的响应时间不得超过1秒 事件必须按优先级顺序进行处理等等 小组负责人应对这些信息加以整理并形成文档 该文档应能反映 家庭保安系统 的全貌 例4 1 根据 家庭保安系统 的特点 将联合小组分成两个小组 并行处理用户编程控制和传感器检测两个子系统 以便使子问题的软件需求进一步细化 这时可能又会增加新对象 新操作 新约束条件 在子系统的需求基本明确并形成文档后 还应就子系统的整合及需求验证标准等进行初步的讨论 初步需求分析应形成结论性文档 比如 经过初步的需求分析 家庭保安系统 的部分初步需求文档如下 例4 1 家庭保安系统 的软件允许用户在安装时进行系统配置 实施对传感器的监控并通过控制面板与户主进行信息交互 系统开机后 软件系统负责显示系统当前的工作状态 接收并处理户主的命令 当系统处于配置状态 软件系统允许户主进行配置操作 配置操作包括 指定每一传感器的种类和编号 设置开 关机密码 指定报警电话号码 指定报警延迟和电话重拨延迟时间 以秒为单位 当系统处于监视状态时 软件系统即开始对所有传感器实施监控 当软件系统接收到传感器发出的数据后 判别是否出现异常事件 如果是 则经过指定的延迟时间即开始拨报警电话号码 拨号操作将按照重拨延迟反复进行 直至电话接通 此时软件系统负责向监控中心报告异常事件发生的地点 时间和性质 例4 1 以上文档没有包括约束条件 测试标准等方面的内容 初步需求文档将是后续详细需求分析的基础 在此基础上 就可以采用某种需求分析方法进行详细的需求分析 初步需求获取建立的初步需求文档将是后续详细需求分析的基础 在以后几章中 将分别介绍几种详细的需求分析方法和其中最重要的需求建模技术 它们是 面向数据流的需求分析方法 面向数据的需求分析方法 面向对象的需求分析方法 4 2 1初步需求获取技术 4 2 2需求建模技术 概念 为了使用户需求逐步精细化 完全化 一致化 通常采用需求建模技术 即用建立目标软件系统模型的方法来刻画软件系统中的信息 处理功能和外部行为 通常 分析人员选定一种分析方法 并用该方法中的一些图形记号分别表示信息流 处理功能和系统行为 并利用受限制的自然语言给出用户需求的描述 这种模型的表示机制还应具有良好的结构化能力 以便处理大型问题的按层次分解的问题 软件需求分析的过程 实际上是软件模型的建造和不断完善的过程 4 2 2需求建模技术 概念 在分析的初期 分析人员通过访谈 会议 实际观察 分析现有系统等方法获取初步的用户需求 分析人员根据选定的一种分析方法 在初步用户需求的基础上构筑初步的模型作为开发方和用户相互沟通的表示机制 分析人员在用户的密切配合下 利用选定的分析方法不断地对模型进行精细化 一致化 完全化 直至获得满意的用户需求为止 在分析阶段构筑的模型不应涉及软件实现的细节 以免分散分析人员的注意力 限制软件设计人员为提高软件质量和效率而选择实现方法的自由度 需求分析结束时确立的软件模型是生成需求规格说明的依据 也是软件设计和实现的基础 4 2 2需求建模技术 概念 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型 解决目标系统的 做什么 的问题 4 2 2需求建模技术 概念 相关概念 问题定义 可行性研究 系统工程 需求分析的核心 建模 建立软件模型是分析活动的焦点 建立软件模型是分析活动的关键 需求分析的核心在于建立分析模型 软件工程中 软件整个开发过程需要建模 软件开发过程的各个阶段也需要建模 不同的软件开发方法 即软件开发范型 最集中表现在它们模型的区别 所以 软件开发过程的一系列模型的建立标准 描述形式 应用规范等 是一种软件开发方法 范型 最核心的研究内容 用户调查 具体模型 建立系统模型的工作流程 逻辑抽象 当前系统 逻辑模型 当前系统 计算机化 评审修改 正式模型 完善细节 目标系统 目标系统初始模型 经认可的 问题需求 系统模型 用户 需求建模的步骤 需求建模的步骤 首先根据用户需求建立系统用户模型 它从概念上全方位表达系统需求及系统与用户的相互关系 在用户模型的基础上 通过系统分析建立适应性强的独立于系统实现环境的逻辑结构 分析阶段独立于系统实现环境 可以保证建立起来的系统结构具有相对的稳定性 便于系统维护 移植或扩充 建模方法 常用的分析 建模方法面向数据流的结构化分析方法 SA 面向数据结构的Jackson方法 JSD 面向数据结构的结构化数据系统开发方法 DSSD 面向对象的分析方法 OOA 建立动态模型的状态迁移图或Petri网等形式化方法面向构件的其它E R方法 需求分析模型 使用的方法不同 建立的模型也不相同 但是 一般必须建立以下几类模型 数据模型 功能模型 行为模型静态模型 动态模型所建立的模型必须是从抽象到精化的一个逐层分解在需求分析阶段 创建的模型 要着重于描述系统要做什么 而不是如何去做 不应涉及软件实现细节 结构化分析模型的组成结构 数据流图 DFD E R图 状态变迁图 STD图 加 工 说 明 控制说明 数 据 对象 说明 数据字典 DD 面向对象分析模型的组成结构 对象 关系模型 类 对象模型 对象 行为模型 使用实例 UseCase 操作 属性 协作者 需求分析模型 分析阶段中常用的模型 逻辑模型 实体关系图数据流图 数据流定义 数据字典 结构化英语 事件列表 状态转换图 用例图 时序图 协作图 类图 状态图 Jackson实体结构图 SSD图 Jackson进程模型 层次方框图 Warnier图 IPO HIPO 等 AnalysismodelingandModel DataModel BehavioralModel FunctionalModel 4 2 3快速原型技术 如果按照传统的软件开发方法 需要经过漫长的开发时间之后用户才能看到目标软件的最初版本 此时用户常常会提出许多修改意见 有时甚至全盘否定 导致开发失败 为了降低开发风险 在需求分析阶段常常采用快速原型技术 1 快速原型技术的基本思想在软件开发的早期 快速开发一个目标软件系统的原型 让用户对其进行评价并提出修改意见 然后开发人员根据用户的意见对原型进行改进 当原型几经改进最终确认后 它将直接进化成软件产品 或者由软件设计 编码人员按照模型所确立的外部特征去实现软件产品 2 采用快速原型技术的具体步骤 采用一种分析方法生成一个软件系统或其中所关心部分的简化需求规格说明 对该规格说明进行评审通过后 立即生成设计规格说明 为了快速生成原型 这种设计仅注重所关心的问题 如软件的总体结构 用户界面和数据设计 或者某个复杂的算法等等 不注重过程内部的控制流设计 使用可重用软部件 用户界面自动生成器等工具快速生成可运行的软件原型并通过测试 将原型提交给用户进行评价 以便征求改进意见 上述过程反复迭代 直至用户完全满意 此时的原型已完全 准确地反映了目标软件在所关心方面的需求 可作为需求规格说明的一部分而成为软件设计的基础 3 快速原型技术的适用场合 该技术特别适合于软件产品要求大量的用户交互 或产生大量的可视输出 或设计一些复杂的算法等场合 目前的绝大多数软件都适合于快速原型技术 除非由于问题相当复杂 致使开发快速原型可以获得的支持太少 所冒的风险太大时 就不易采用 但对于其中的某些子问题 尤其是用户界面 还可采用快速原型技术进行部分分析 分析阶段使用快速原型技术与问题本身的复杂度以及可用的开发工具 环境有关 如果问题非常复杂 在当前工具 环境的支持下开发可运行的原型需要投入太多人力或占用太多时间 那么可对某些子问题 尤其是用户界面 使用快速原型技术进行部分分析 某些软件项目 虽不能构造实际可运行的快速原型 但可以采用幻灯片演示等方法 向用户直观描述目标软件系统的外部行为 4 2 3快速原型技术 4 2 4问题分解与抽象 多视点分析技术 问题分解技术分析人员常常采用一种问题分解的技术 即将一个大型复杂的问题分解为若干个子问题 然后对每一个子问题逐个进行分析 再自底向上综合成整个问题的分析结果 这种分解可以逐级进行 直至子问题的规模降到合适的程度 问题抽象技术分析人员在分析过程中要善于从诸多的特殊问题中抽象出一般的问题 首先关注一般问题的解决途径 再用其指导特殊问题的求解 在抽象的过程中 还要注意用户的描述所处的抽象级别的不同 以便建立清晰的思路 4 2 4问题分解与抽象 多视点分析技术 比如 在 家庭保安系统 中 用户可能提出 系统状态显示 用户编制程序时的系统外部行为 等的需求 分析人员则应在 用户界面 这一抽象级别上统一地规划软件系统与用户的交互行为 可见 在不同的抽象级别上去分析不同层次的问题 也是解决复杂问题的一个重要方法 它可以避免不一致性 减少分析的工作量 4 2 4问题分解与抽象 多视点分析技术 多视点分析技术 为了获得全面的需求分析结果 防止遗漏 有必要从各个视点分别对问题进行理解与分析 然后综合成全面的理解 分析人员可以就系统视点与用户视点 信息视点 功能视点与行为视点等多个视点分别进行分析 以确保需求分析的完全性 4 2 4问题分解与抽象 多视点分析技术 抽象与分解1 抽象 把握全局 整体观 抓住问题的本质和最主要的方面 2 分解 把大的复杂的系统分解成若干个较小的容易理解的部分 确定各部分之间的接口 补充原来未考虑到的细节 1 横向与纵向分解2 松耦合原则 4 2 4问题分解与抽象 多视点分析技术 分解通常 软件要处理的问题若作为一个整体来看 显得太大太复杂而很难理解 如果把它以某种方式分解成几个较易理解的部分 并确定各部空间的接口 从而实现整体功能 则问题的解决就会显得容易些 分解可从两个方向进行 1 横向分解 2 多层次的纵向分解 4 2 4问题分解与抽象 多视点分析技术 分解 4 2 4问题分解与抽象 多视点分析技术 视点分解法在分析的初期 整体地把握一个大型问题的软件需求是困难的 需要从各个角度分别对问题进行理解和分析 然后再综合 达到全面理解的目需求分析视点系统观点用户观点信息观点功能观点行为观点等 整理 综合用户描述 应注意用户视点的变化 避免遗漏 4 3需求规格说明与评审 需求分析的主要阶段性产品是需求规格说明书 它必须通过需求评审后才能生效 这是一个重要的里程碑 4 3 1需求规格说明书的作用与内容1 需求规格说明书的作用主要有 1 它是软件设计人员进行设计和编码的出发点和基础 2 它是对目标软件产品进行验收测试的依据 这就要求需求规格说明书中的各项需求都应该是可测试的 3 它起到软件开发方和客户 或用户 方之间的一份合同的作用 SRS SRS的极端重要性 ExtremelyImportant SRS一定要写而且要写好 回顾 SRA的极端重要性需求分析的最终产品 SRS 初步的用户手册 完善的软件开发计划 SRS具有 蓝图 的作用 它是 1 后续阶段 设计 编码 测试 维护 的依据 2 开发者和客户的合同 3 软件管理的依据 如 编制计划和进度 成本估算 确认和验证等 SRS SRS的极端重要性 SRA是软件开发的前提和基础 SRA过程中产生的文档资料 软件需求规格说明书SRS是软件开发依据 也是软件开发者与用户评估 验收软件产品的依据 SRS作为用户和开发者之间的一个协议 在之后的软件工程各个阶段发挥重要作用软件项目投标及签订合同的基础软件系统实现的基础系统确认移交的基础 4 3 1需求规格说明书的作用与内容 2 需求规格说明书中的内容应主要包括功能与行为的需求描述和非行为需求描述 功能与行为需求的分析与描述方法将在以后几章中根据不同的需求建模方法分别介绍 非行为需求是指目标软件系统在工作时应具备的属性 主要有运行效率 可靠性 安全性 可维护性 可移植性等等 在需求规格说明书中不应包括如人员需求 成本预算 进度计划 质量保证计划等内容 以便使其简洁 目标明确 SRS 不应该包含和必须包含的内容 beginbyfocusingontheessenceoftheproblemwithoutregardtoimplementationdetails Theanalysisprocessshouldmovefromtheessentialinformationtowardimplementationdetail Essence SRS 不应该包含和必须包含的内容 需求就是确定系统 做什么 它并不涉及系统 怎么做 即如何实现 的问题 需求分析的主要焦点是 做什么 what 不是 怎样做 how 在软件需求分析阶段 所创建的模型 要着重于描述系统要做什么 而不是如何去做 不应涉及软件实现细节 designindependencetherequirementspecificationdoesnotimplyaspecificsoftwarearchitectureanddoesnotrequirespecificalgorithmicimplementations SRS 不应该包含和必须包含的内容 SpecificationPrinciples Separatefunctionalityfromimplementation Createacognitivemodelratherthananimplementationmodel 需求规约的原则 1 从实现中分离功能 即描述要 做什么 而不是 怎样实现 规约必须是一个认识模型 而不是设计或实现的模型ItisNOTadesigndocument Asfaraspossible itshouldsetofWHATthesystemshoulddoratherthanHOWitshoulddoit SRS 不应该包含和必须包含的内容 不应该包括在SRS中的内容项目开发计划