0%

需求工程复习总结

需求工程复习总结

#第1章需求工程概述#

  • 软件开发失败的原因
  1. 需求不完整
  2. 缺乏用户的参与
  3. 不实际的客户期望
  4. 需求或需求文档的变更
  5. 实现不必要的功能
  6. 预算不足
  7. 缺乏沟通和透明
  8. 不能适应变化和重新定向
  • 什么是软件需求
  1. 用户解决问题或达到目标所需要的条件或能力。
  2. 系统或系统部件满足合同、规格、规范或其他需求文档所需要的条件或能力。
  3. 对1,2所描述的条件或能力的文档化表示
  • 软件需求的分类
  1. 目标需求
  2. 业务需求
  3. 功能需求
  4. 性能需求
  5. 约束与限制
  • 需求规格说明

    描述软件应该满足的全部需求文档

  • 需求规格说明的重要性

  1. 他是涉众的共识
  2. 是系统进行设计、实现、测试的基本依据
  3. 是用户验收的基本依据
  4. 是整个软件开发过程的中最重要的文档
  • 一个好的需求规格说明应该具有的特征
  1. 完整性
  2. 必要性
  3. 可行性
  4. 正确性
  5. 不二义性
  6. 划分优先级
  7. 可验证性
  • 什么是需求工程(定义)

需求工程是应用工程化的方法、技术和规格来开发和管理软件的需求。

  • 需求工程的目的

获取高质量的软件需求。

  • 需求工程的任务
  1. 确定涉众,并获取他们的需求信息(获取)
  2. 分析用户的需求信息,并按照软件需求的类型分类这些需求信息,同时也区别不是需求的信息。(分析)
  3. 根据软件需求信息建立软件系统的逻辑模型或需求模型,并确认非功能需求和约束条件及限制。(建模)
  4. 根据收集的需求信息和逻辑模型编写需求文档规格说明书(文档)
  5. 评审规格说明。和顾客确认(确认)
  6. 当需求发生变更时,对需求变更实施进行管理(变更和管理)
  • 其它一些基本概念
  • 涉众
  1. 用户
  2. 客户
  3. 软件开发人员
  4. 项目利益相关人员

#第2章软件工程与需求工程#

  • 软件是什么(定义)

软件由程序、数据结构和文档组成。

  • 软件有何特性
  1. 软件是逻辑的而非物理的系统元素;
  2. 软件是设计开发的,不是传统意义上的生产制造的;
  3. 软件不会磨损,但会因变更而退化;
  4. 软件大多为定制,构件复用才开始。
  • 软件危机

人们难以控制软件的开发和维护。

  • 软件危机的表现
  1. 软件系统大型化,复杂化,很难理解和维护;
  2. 软件开发周期过长;
  3. 大型软件系统的可靠性差;
  4. 软件费用往往超出预算。
  • 软件危机的原因
    • 客观:软件本身特点
      1. 逻辑部件
      2. 规模庞大、复杂度高
    • 主观:不正确的开发方法
      1. 忽视需求分析
      2. 个人化方式:软件开发=程序编写
      3. 轻视软件维护
  • 软件危机的解决方法

应用工程化方法进行软件开发和维护

  • 软件工程的定义
  1. 将系统化的,规范的,可量化的方法应用于软件的开发,运行和维护,即将工程化方法应用于软件开发。
  2. 在(1)中所述方法的研究。
  • 软件工程研究的内容
  1. 软件开发过程
  2. 软件开发和维护的方法和技术
  3. 软件开发和维护工具系统
  4. 质量评价和质量保证
  5. 软件管理环境等
  • 软件工程学的研究范畴
    • 软件开发技术
      1. 软件方法
      2. 软件工具
      3. 软件工程环境
    • 软件工程管理
      1. 软件管理学
      2. 软件经济学
      3. 软件度量学
  • 软件开发过程模型
  1. 瀑布式模型
  2. 快速原型模型
  3. 渐增式模型
  4. 螺旋式模型
  5. 面向对象的开发模型
  6. 其他过程模型
  • 瀑布式模型
    • 特点

      简单。80年代前是唯一广泛采用的模型,现在也还是应用得最广泛的模型。

    • 不足
      1. 要求用户一开始就提出清晰完整的需求 ;
      2. 要求用户需求比较稳定;
      3. 用户的参与程度不够;
      4. 段间移交信息时,容易产生误解。
  • 快速原型模型
    • 目的
      1. 明确并完善需求;
      2. 探索设计选择方案;
      3. 可帮助发展为最终的产品。
    • 特点
      1. 能弥补瀑布模型中用户参与不够等不足
      2. 能减少用户需求遗漏的可能性
      3. 快速
    • 不足
      1. 用户易于视原型为正式产品
      2. 对于开发环境需求较多
      3. 用户不能如期参与,将会开发不顺
  • 渐增式模型 ( 增量式 )
    • 特点
      1. 能快速提交可完成部分功能的产品
      2. 能逐步增强产品功能
      3. 用户可有较充裕的时间适应新系统
    • 不足
      1. 新增部分必须不破坏现软件系统
      2. 在设计体系结构时,必须有充分的开放性
  • 螺旋式模型
    • 特点
      1. 适用于内部开发的大规模软件项目
      2. 有利于已有软件的重用
      3. 有助于把质量作为一个重要目标
      4. 减少过多测试或测试不足的风险
  • 面向对象的开发模型
    • 特点
      1. 呈现出非线性的工作方式
      2. 把类及其结构作为系统的表达单元,渐增地进化
      3. 开发模型支持软件的复用
  • 其他模型
    • 基于构件的开发——采用预先打包的软件构件来开发系统。通过软件复用,减少开发成本,缩短开发周期。
    • 敏捷开发——推崇让顾客满意和软件的早期增量发布,最小化软件工程工作产品。
    • 统一过程(RUP )——一种“用例驱动,以架构为核心,迭代并且增量”的软件过程,与统一建模语言的紧密结合
    • 形式化方法——强调需求的数学规范说明
  • 软件过程模型的特点汇总

  • 需求工程对软件开发的影响如下
  1. 需求是制定项目计划的基础
  2. 需求规格说明是软件设计和实现的基础
  3. 需求规格说明是测试和用户验收的依据
  4. 需求规格说明也是软件维护工作的依据
  • 需求获取与需求分析的困难性
  1. 有些需求可能用户也不是很清楚
  2. 需要用户与开发人间进行充分的沟通
  3. 需求间的冲突和矛盾的检查以及解决
  4. 需求是否完整的确定
  5. 合适的需求建模的方法和技术
  • 需求描述语言和规范化的困难性
  1. 怎样规范化用户需求
  2. 规范化哪些用户需求
  3. 非形式化和形式化描述语言的使用
  • 需求验证的困难性
  1. 需求规格说明正确性的确认和验证
  2. 验证的方法和技术
  3. 如何进行自动验证
  • 需求管理的困难性
  1. 需求规格说明书的质量保证
  2. 需求规格说明书的版本管理
  3. 需求变更的控制
  • 需求开发过程的主要任务
  1. 需求获取
  2. 需求分析
  3. 需求定义
  4. 需求验证
  • 需求管理的任务
  1. 有效地管理软件系统的需求规格说明
  2. 评估需求变更带来的潜在影响及成本
  3. 跟踪软件需求的状态
  4. 管理需求规格说明的版本等

#需求获取#

  • 获取需求的过程
  1. 确定需求开发计划
  2. 建立项目范围和目标
  3. 确定调查对象
  4. 实地收集用户需求信息
  5. 确定非功能需求和约束条件
  • 需求获取的主要技术
  1. 涉众分析
  2. 目标分析
  3. 企业分析
  4. 场景分析
  • 确定需求开发计划应注意
  1. 只考虑与需求开发相关的工作
  2. 应考虑困难性和灵活性
  3. 涉众的状况
  4. 应考虑整理需求规格说明的时间
  • 识别涉众
  1. 识别涉众
  2. 评价涉众对需求的影响度
  3. 评价各需求对于涉众的重要性
  • 应根据需求的层次来区分不同的涉众
  1. 提出目标需求的涉众:用户领导,买单者,业务运行管理人员,开发方领导,顾问等
  2. 提出业务需求的涉众:部门主管,产品管理人员,销售人员,最终用户等
  3. 提出功能需求层的涉众:开发人员(产品工程师,软件工程师,支持和维护工程师等),用户
  • 典型的软件需求来源
  1. 涉众
  2. 现存或类似系统需求规格说明
  3. 市场调查和用户问卷调查
  4. 现行系统中存在问题的报告和增强要求
  5. 观察正在工作的用户
  6. 用户工作内容的分析
  • 实地收集需求信息可能面临的困难
  1. 用户没有充分的时间 ;
  2. 有时用户认为简单说明就行;
  3. 用户和开发人员都只考虑自己的利益;
  4. 用户本身不能提出明确的需求 ;
  5. 双方缺乏对方的知识,交流困难。
  • 实地调查的步骤
  1. 向掌握“全局”的负责人调查;
  2. 向各部门负责人调查;
  3. 向业务人员调查。
  4. 向开发人员调查。
  • 实地收集需求信息的方式
  1. 以座谈会的方式;
  2. 以书面咨询的方式;
  3. 利用用例表示方法
  • 需求信息可大致分类
  1. 目标需求;
  2. 用例说明;
  3. 业务规则;
  4. 功能需求;
  5. 质量需求;
  6. 外部接口需求;
  7. 限制;
  8. 数据定义;
  9. 用户提案。
  • 确定非功能需求

非功能需求是衡量软件能良好运行的定性指标。由于缺乏定量指标,容易成为日后的争点。

  • 用户关心非功能性需求
  1. 易使用性;
  2. 可靠性;
  3. 安全性;
  4. 互操作性;
  5. 健壮性;
  • 开发人员关心非功能性需求
  1. 可维护性;
  2. 可扩充性;
  3. 可移植性;
  4. 可重用性。
  • 收集非功能需求信息时常用的方法
  1. 将不同涉众类代表提出的非功能需求进行综合,并根据其中的每个需求设计出对应方法,协商后使这些需求更明确化
  2. 与涉众一起对每一个非功能需求制定可测试和可验证的具体标准
  3. 设计与非功能需求相冲突的假设示例,利用反例来提示用户
  • 在收集需求信息中应注意的问题
  1. 应能适当的调整收集范围;
  2. 尽量把用户所持的假设弄清楚,特别是发生冲突的部分;
  3. 尽量理解用户的思维过程,尽量熟悉用户的一些专业知识和术语;
  4. 在收集需求信息时,应尽量避免受不熟悉细节的影响;
  5. 应尽量避免讨论一些具体的解决方案;
  6. 需求信息收集工作的结束。
  • 场景分析目的

场景分析目的是通过用户视点明确需求

  • 场景(scenarios)的定义

所谓场景是指用户与软件系统实现某个目标而进行交互活动过程的描述。

  • 场景的构成
  1. 执行者(用户)
  2. 进入场景前系统状态的描述
  3. 执行者的目的
  4. 动作和事件系列(包括正常或非正常事件)
  • 场景应具有的特征
  1. 场景代表某些用户可见的功能,实现一个具体的系统需求;
  2. 场景总是被参与者启动的,并向参与者提供可识别的信息;
  3. 场景必须是完整的。

场景的结构化语言描述:
执行者(用户):王某;
进入场景前系统状态的描述:使用PC机的经验是1年。几乎每天使用。另外,今日发送电子邮件的工作已结束;
执行者的目的:退出Windows98,并切断PC机的电源;
动作和事件系列:第2段文字,从按下“开始”按钮的动作开始到切断PC机电源的事件完成为止。

  • 场景的表示
    • 非形式化的表示
      1. 自然语言
      2. 结构化语言
      3. 图形
      4. 动漫画等
    • (半)形式化的表示
      1. 状态图
      2. 活动图
      3. 流程图
      4. 时序图
      5. 代数描述图等
  • 场景的种类
  1. 按执行者的目标能否实现分:正常场景和失败场景;
  2. 按场景描述的内容分:正向场景和逆向场景 ;
  3. 场景之间亦可以建立关系以及精化处理。
  • 场景需要注意的问题
  1. 场景数量不宜过大。
  2. 场景应尽量避免冗余。
  3. 应防止场景描述内容的冗长。
  • 场景技术的特点
  1. 把软件系统的需求信息文本化,有助于在实现软件系统前明确用户与软件系统的相互作用;
  2. 可以把当前系统存在的问题作为实例记录下来;
  3. 可以成为项目相关人员间的共同语言;
  4. 由于场景描述了软件系统的操作,比较具体,其易理解性较好;
  5. 通过场景使得提出和获得需求的双方之间能建立起相应的理解。
  • 沟通原则
  1. : 倾听 。一定要仔细倾听讲话者的每一句话,而不是急于叙述你对这些话的看法。
  2. : 有准备 的沟通。在与其他人碰面之前花点时间去理解问题。
  3. :沟通活动需要 有人推动 。每个沟通会议都应该有一个主持人(推动者),其作用是:(1)保持会议向着有效的方向进行;(2)能调解会议中所发生的冲突;(3)能确保遵循我们所说的沟通原则。
  4. :最好 当面 沟通。但是,当能把一些相关信息呈现出来时,通常可以工作得更好。
  5. :记笔记并且 记录。 所有决定。 参与交流的人应充当“录音机”,并 记录所有要点和决定。
  6. :力求 协作 。当团队成员的想法需要汇集在一起用以阐述一个产品或者某个系统的功能或特征的时候,就产生了协作和协调的问题。
  7. :把讨论集中在 限定范围 内。在任何交流中,参与的人越多,话题转移到其他地方的可能性就越大。
  8. :如果某些东西很难表述清楚,采用 图形 表示。
  9. :(a a )一旦认可某件事情,转移话题;(b b )如果不认可某件事情,转移话题;(c c )如果某项特性或者功能不清晰,当时无法澄清, 转移话题 。
  10. :协商不是一场竞赛或者一个游戏,协商 双赢 时才发挥了协商的最大价值。

#需求分析#

  • 需求分析的任务

分析和综合需求信息

  • 需求分析步骤
  1. 整理 整理 产品前景与项目范围
  2. 建立系统关联图 建立系统关联图
  3. 分析需求的可行性 分析需求的可行性
  4. 构建用户接口原型 构建用户接口原型
  5. 确定需求的优先级别 确定需求的优先级别
  6. 协调不一致的需求 协调不一致的需求
  7. 需求建模 需求建模
  8. 建立数据词典
  • 建立系统关联图目的

用图形表示系统与外部实体间的关联。

  • 分析需求的可行性任务
  1. 在预算和交付期的限制下、以及系统的已知条件的范围内,分析每项需求得以实施的可能性。
  2. 发现需求与其他方面的冲突,对外部环境的依赖和技术障碍。
  • 在实际需求分析中应考虑的风险类型
  1. 性能风险
  2. 安全风险
  3. 过程风险
  4. 实现技术风险
  5. 数据库风险
  6. 日程风险
  7. 外部接口风险
  8. 稳定风险
  • 构建用户接口原型任务

对于不明确的需求,通过建立用户接口原型并评估该原型,便于理解问题在哪。

  • 构建用户接口原型目的

可使概念和可能发生的事更明了。

  • 抛弃型原型

需求分析时遇到具有不确定性、二义性、不完整或含糊特征的需求时,最适合建立抛弃模型

  • 进化型原型

需求清楚定义的情况下,以渐增的方式构建原型。

  • 构建用户接口原型的方法
  1. 纸上原型化方法
  2. 人工模拟原型化方法
  3. 自动原型化方法
  • 确定需求优先级好处
  1. 帮助涉众判断系统的核心需求,便于集中于重点问题的交流和协商;
  2. 可帮助决定软件体系结构,及解决可能发生的设计冲突;
  3. 依此权衡合理的项目范围和进度安排、预算、人力资源以及质量目标的要求。
  • 导致需求不一致的原因
  1. 开发者希望提供高科技新方向。
  2. 而零售商只要简单实用的系统。
  3. 经营者希望能降低成本,增加收入。
  4. 各用户则注重自身方便性和功能。
  5. 不同的目标、约束和成本因素导致不一致的业务需求。
  • 解决利益相关者需求冲突的方法
  1. 通过协商,找到解决冲突的妥协方案
  2. 通过需求排优先序解决冲突
  3. 通过创造性解决方案解决冲突
  4. 通过上司决定解决冲突
  • 需求建模的目的

增强对用自然语言描述的需求规格说明的理解,而不是要替换它。

  • 目前主流的需求分析方法
  1. 结构化分析方法( 结构化分析方法( SA) )
  2. 面向对象的分析方法 面向对象的分析方法 (OOM) )
  • 其他需求分析方法
  1. 形式化方法 形式化方法(Formal Method )
  2. 面向问题域的分析方法( 面向问题域的分析方法(PDOA) )
  3. 面向多视点的需求工程 面向多视点的需求工程(MVORE)
  • 需求字典作用
  1. 确保软件开发人员使用统一的数据定义,并可提高需求分析,设计、实现和维护过程中的可跟踪性。
  2. 确保项目涉众交流时概念的含义一致。

1.从结构视点(静态模型)
ER图,类图等
2. 行为视点(动态模型)
状态图,时序图,通讯图等
3.功能模型
DFD图,用例图等

  • 需求决策人
  1. 个别用户与大多数同类用户不能达成统一意见,决策者位用户代表
  2. 用户类之间不一致需求,决策者为领导层
  3. 不同部门需求不同,开发人员根据需求,决定哪些重要的最关心客户的。
  4. 用户部门经理提出需需求和部门真正用户不一致时,在满足用户需求符合目标需求前提下,决策者为部门用户代表
  5. 开发人员与用户需求不一致时,决策者为用户
  6. 市场部门需求与开发部门的需求人员冲突时,决策为市场部门

#需求建模方法与技术#

#需求定义#

  • 需求规格说明的作用
  1. 是用户与软件开发方对将要开发的软件达成的一致 协议。(基线需求)
  2. 是软件 设计和实现的基础;
  3. 是 测试和用户验收软件系统的重要 依据;
  4. 能为软件 维护提供重要的 信息。

#需求验证#

  • 需求验证的目的

确保需求规格说明具有良好的特性。

  • 需求验证包含
  1. 软件需求规格说明是否正确描述了目标系统的行为和特征?
  2. 所有的需求都在相应的抽象层上说明了吗?
  3. 每项需求都有界定且无歧义的吗?
  4. 有需求和其他需求冲突吗?
  5. 所处的技术环境下每个需求都能够实现吗?
  6. 每项需求都有归属吗?(标记需求来源)
  7. 每项需求都和涉众取得一致了吗?
  8. 需求为进一步的软件开发和测试提供了足够的基础吗?
  • 需求验证重要性

发现和修复需求规格说明书存在的问题,进而避免在软件系统设计和实现时出现返工。

  • 需求验证任务

要求各方人员从不同的技术角度对需求规格说明文档做出综合性评价。

  • 方法

目前验证需求的方法除形式化方法外,主要靠人工技术审查和验证软件需求规格说明。

  • 评审是什么?
  1. 是由技术人员主导为技术人员进行的会议
  2. 是对在软件工程过程中产生的工作产品的技术评估
  3. 是软件质量保证机制
  4. 是训练场地
  • 评审不是什么
  1. 不是项目总结或进展评估
  2. 不是一个仅传递信息的会议
  3. 不是政治或个人报复的机制
  • 评审的目标
  1. 发现软件的任何一种表示形式中的功能、逻辑或实现上的错误
  2. 验证评审中的软件是否满足其需求
  3. 保证软件的表现符合预先指定的标准
  4. 获得以统一的方式开发的软件
  5. 使项目更易于管理
  • 评审方法:
  1. 非正式评审方法包括:
  2. 同级桌面检查,结对检查(peer deskcheck)
  3. 轮查(passaround)
  4. 正式评审会生成一份报告,指明具体材料、评审人员以及评审团队认为产品是否可以接受,主要提交对发现的错误和提出的问题的总结。
  5. 走查(walkthrough)
  6. 审查(inspection)
  • 审查的内容

需求评审的工作就是评审需求规格说明的内容。

  • 审查清单列举的问题
  1. 需求是否完整?
  2. 需求是否一致?
  3. 需求是否可理解?
  4. 需求是否明确?
  5. 需求是否可实现?
  6. 需求是否可跟踪?
  7. 需求是否易于修改?
  8. 需求文档是否完整?

#需求的形式化描述#

  • 需求的形式化方法的优点
  1. 形式化规约可以用数学方法研究。
  2. 某些不完整性和不一致性可被自动检知 。
  3. 形式化方法所生成的分析模型比用其他方法生成的模型更完整、一致和无二义。
  4. 使从需求逐步推导出程序成为可能。
  5. 利于构造出可信度高,非常健壮的软件
  • 需求的形式化方法的缺点
  1. 使用形式化方法来建立规约比其他方法更难于学习 。
  2. 难以使用该模型与用户进行交流沟通,因为几乎所有的用户对其一无所知。
  3. 形式化模型的开发很费时和昂贵,因为懂形式化方法的软件开发者很少。
  4. 对创建一个形式化描述的花费很易量化,但评估因用它所带来的成本节余就困难得多。
  5. 很难将现有方法扩展到很大的系统中。通常只对要求极高的核心部分进行形式化描述。
  6. 不适用于敏捷开发。
  • 形式化主要使用的数学方法
  1. 集合论;
  2. 逻辑学;
  3. 代数学。
  • 形式化主要用途

系统行为的建模,特别是为功能性和并发的行为

  • 形式化需求规格说明应用于软件开发工作中的两种形式
  1. 规格说明变换 (狭义的形式化方法)
  2. 规格说明执行( 净室开发方法)
  • 设计验证的优点
  1. 它将验证降低为一个有限过程。
  2. 它让净室团队验证设计和代码的每一行。
  3. 它使设计达到一个接近于零缺陷级别。
  4. 它的使用范围逐渐扩大。
  5. 它产生的代码比单元测试的好。

#第9章需求管理#

  • 需求管理的内容
  1. 控制对基准需求规格说明的变动
  2. 保持项目计划的需求一致
  3. 控制单个需求的更改和需求规格说明文档的更改
  4. 管理需求和需求间的联系,以及需求与设计和实现等方面的依赖关系
  5. 跟踪需求更改的状态,控制多个需求同时更改的复杂性
  • 有效管理需求变更需要考虑以下几方面的工作
  1. 控制项目范围的扩展
  2. 变更控制策略
  3. 变更控制步骤
  • 版本控制策略
  1. 为减少困惑,冲突和不一致,只能允许指定的专人来更新和修改需求规格说明文档
  2. 每一个公布的需求规格说明文档的版本应该包括求该版本的历史情况
  3. 根据修改工作量的大小,手工标记需求规格说明版本的每一次修改
  4. 每个版本的需求规格说明必须是独立说明的