吉林大学软件需求分析 Software Requirement Analysis

软件=程序+数据+文档

软件的基本特征

• Complexity(复杂性)

• Consistency(一致性)

  • 软件不能独立存在，需要依附于一定的环境（如硬件、网络以及其他软件）
  • 软件必须遵从人为的惯例并适应已有的技术和系统
  • 软件需要随接口不同而改变，随时间推移而变化，而这些变化是不同人设计的结果

• Variability(易变性)

  • 人们总是认为软件是容易修改的，但忽视了修改所带来的副作用

  • 不断的修改最终导致软件的退化，从而结束其生命周期

• Invisibility(不可见性)

  • 软件是一种“看不见、摸不着”的逻辑实体，不具有空间的形体特征
  • 开发人员可以直接看到程序代码，但是源代码并不是软件本身
  • 软件是以机器代码的形式运行，但是开发人员无法看到源代码是如何执行的

软件所具有的复杂性、一致性、可变性、不可见性等特性，使得软件开发过程变得难以控制，开发团队如同在焦油坑中挣扎的巨兽

软件开发面临的挑战

软件之道

定义:软件工程是一个技术，方法和工具的集合，帮助生产

• 一个高质量的软件系统

• 与给定的预算

• 在给定的期限

  while change occurs

软件工程是一项解决问题的活动

• 我们想要软件解决的问题是“邪恶的”

  • 没有明确的公式的问题
  • 每个问题是唯一的(没有其他问题是完全像它)
  • 每个问题可以被视为另一个问题的症状
  • 问题往往有很强的政治性，道德或专业层面
  • 解决方案没有对错之分
  • 没有对解决方案有多好进行的客观测试(需要主观判断)
  • 没有停止规则(每个解决方案都会带来新的见解)

• 现代系统的特点

  • 多变的业务环境受不断变化的影响
  • 各种复杂的系统类型
  • 复杂数据类型的使用增加
  • 复杂的用户界面
  • 对于软件组件之间关系复杂多变的大型系统的倾向

• 是什么问题?

  • 软件不能建立足够快跟上
    • H / W进步
    • 上涨预期
    • 特性爆炸
  • 越来越需要高可靠性软件
    • 手机
    • 交通系统(汽车、飞机、火车)
    • 信息系统(医疗记录、财务/银行 )
  • 软件很难维护
    • “老化软件”
  • 难以估计软件成本和进度
  • 太多的项目失败了
    • Therac-25
    • Arianne Missile
    • Denver Airport Baggage System

• 为什么需要软件工程？

  • 预测时间、精力和成本
  • 提高软件质量
  • 提高可维护性
  • 满足日益增长的需求
  • 降低软件成本
  • 成功构建大型、复杂的软件系统
  • 在软件开发过程中促进团队合作

• 什么是好的软件？

• 软件过程

  • 开发软件系统所需的一组结构化活动

• 基本活动包括：

  • 需求定义和分析

  • 设计

  • 编码（实施）

  • 测试

  • 维护

    开发包括（设计，编码，测试）

• 软件工程费用

• 软件开发生命周期（SDLC）

  • 瀑布模型

  • 瀑布模型认为，只有当前一个阶段完成并完善时，才应该进入该阶段

  • 早期花在确保需求和设计正确上的时间可以节省后期的大量时间和精力

  • 提出了许多过程模型

    • V型

    • Incremental Model增量模型

    • Iterative Model迭代模型

    • Spiral Model螺旋模型

    • Agile敏捷的

修复错误的相对成本

需求缺省的典型案例

• PROMS（演出权益协会）,11M￡,1992,未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周
• RISP（西萨克斯地区信息系统计划）,43M￡ ,1990,缺少清晰的项目范围定义
• TAURUS(伦敦股票交易), 75M￡(1.4B￡), 1993,未能协调不一致的需求
• LASDS(伦敦救护车服务派遣系统), 1992,社会服务领域糟糕的需求分析
• ATC(空中交通控制系统), 1.8B￡,1998-2001,缺乏健壮的需求规格说明

为什么需求分析很困难？

• 沟通：客户与分析师之间的误解

  • 分析员不理解这个域
  • 客户不了解备选方案和权衡

• 问题复杂性

  • 问题陈述中的不一致
  • 问题陈述中的遗漏/不完整
  • 问题陈述中的不适当细节

问题域:问题所存在的现实世界中的那个部分,也称应用领域

解系统:待开发的软件

需求:用户期待解系统在问题域内产生的某些效果

什么是工程？

• 工程是通过应用科学知识，为实际问题开发成本效益高的解决方案

• 工程特性
  • 平衡与决策
  • 度量与验证
  • 训练有素的过程
  • 团队协作与角色分工
  • 系统地运用工具
  • 遵循工程原则、标准和实践
  • 重用设计和设计制品

需求工程的定义

• 定义1

  • 需求工程是软件工程的一个分支，涉及软件系统的实际目标、功能和约束。它还关注这些因素与软件行为的精确规范之间的关系，以及它们随时间和跨软件系列的演化

• 定义2

  • 需求工程是一组开发、获取、规范、分析和管理涉众需求的活动，这些活动将由一个新的或不断发展的系统来满足

• 定义3

• 定义4

  • 对问题域及需求作调查研究和描述，设计将满足那些需求的解系统的特性并用文档说明

3.3需求工程活动

Inception

• 开始过程(业务需求，市场机会，好主意，…)，业务案例，可行性研究，系统范围，风险，等等。

elicitation需求获取

• 需求与利益相关者协商发现

analysis and negotiation需求分析和谈判

• 需求分析和通过谈判解决冲突

需求规范

• 产生一个精确的需求文档

需求验证

• 需求文档检查为了一致性和完整性

需求管理

• 需求和环境在发展，需求也在发展!

需求开发过程

需求的三个维度

• 内容——问题的覆盖

  • 是否捕获了所有相关的需求

• 文档化-定义良好的需求

  • 所有的需求都是根据标准描述的吗?

• 一致性-商定的要求

  • 是否达成了共同协议?

连续需求工程

• 传统的系统分析

  • …包含基于对现有系统或过程的分析为新系统定义需求的不同方法。

• 持续需求工程

  • RE作为一个跨生命周期的活动

• 持续需求工程

  • RE作为一个跨项目和跨产品的活动

Requirements Inception的主要任务

Requirements Inception的文档

Context aspect 环境方面

Goals 目标

问题分析

可行性分析和风险分析

RE过程的起点

• 有时作为RE elicitation的一部分

它的主要任务包括

• 1.确定业务需求

  • 商业机会
    • 描述市场机会、竞争市场、正在解决或改进的业务问题、建议解决方案的优势、将要解决的问题…
  • 商业目标和成功标准
    • 产品将以定量和可测量的方式提供重要的商业利益，如何衡量成功，对成功有重大影响的因素…
  • 客户或市场需求
    • 客户当前遇到的问题将得到解决
  • 业务风险
    • 与开发或不开发产品相关的主要风险（市场竞争、时间安排、用户接受、实施问题…）

• 2.Gain agreement on problem definition 就问题定义达成一致

  • Gain agreement on problem definition 远景、界限、范围

  • 产品愿景：描述产品是关于什么以及它最终可能成为什么

  • 了解根本原因是什么

    • 确定导致问题的因素

  • 确定导致问题的因素

    • 项目范围：确定当前项目将解决的最终长期产品愿景的哪一部分

    • 在输入和输出之间绘制边界

• 3.确定利益相关者

   谁使用这个系统？

   谁是顾客？

   谁受到产出的影响？

   谁开发/评估/批准系统？

   其他外部/内部用户？

   谁维护这个系统？

   有人在乎吗？

• 4.确定约束和风险

  • 经济(如:成本、许可问题)

  • 政治(如:内部或外部、部门间问题)

  • 技术(如:技术/平台选择)

  • 系统(如:现有系统、兼容性问题)

  • 环境(如:法律/生态/安全/标准)

  • 时间表和资源(如:固定时间表、团队)

• 5.进行可行性研究

  • 要确定一个软件开发项目是否可以完成:
    • …是可能的吗?
    • ……是合理的吗?
  • 提出可能的替代解决方案。
  • 为管理层提供足够的信息，以了解:
    • 项目是否可以做
    • 最终产品是否有利于其预期用户
    • 替代品是什么(这样选择可以在后续阶段)
    • 是否有优先选择
  • 可行性研究是面向管理活动
    • 可行性研究之后,管理使得一个“通过/不通过”的决定。
    • 需要在更广泛的业务战略背景下研究这个问题
  • 可行性研究中要研究的事项：
    • 现有组织系统
      • 用户、政策、功能、目标……
    • 现有系统存在的问题
      • 不一致、功能、性能、…不足等问题。
    • 新系统的目标和其他要求
      • 需要解决哪些问题？
    • 需要更改什么？
    • 约束
      • 包括对系统的非功能要求(初步通过)
    • 可能的替代方案
      • 坚持当前的系统应该始终作为一种替代方案来研究
      • 不同的业务流程来解决问题
      • 不同级别/类型的计算机化的解决方案
    • 备选方案的优缺点
  • 结论：
    • 项目的可行性
    • 首选替代方案。

RE Inception的主要任务总结

• 就问题定义达成一致
• 边界，范围
• 识别利益相关者
• 识别业务需求
• 识别约束和风险
• 进行可行性研究

Project Vision & Scope Document

• 项目愿景和范围文件
  • 1.Business Requirements业务要求
    • 1.1.Background, Business Opportunity, and Customer Needs背景、业务机会和客户需求
    • 1.2.Business Objectives and Success Criteria业务目标和成功标准
    • 1.3.Business Risks业务风险
  • 2.Vision of the Solution 解决方案愿景
    • 2.1.Vision Statement前景概述
    • 2.2.Major Features主要特性
    • 2.3.Assumptions and Dependencies假设和依赖性
  • 3.Scope and Limitations范围和限制
    • 3.1.Scope of Initial and Subsequent Releases初始和后续版本范围
    • 3.2Limitations and Exclusions限制和排除
  • 4.商业背景
    • 4.1.利益相关者简介
    • 4.2.项目优先事项

项目可行性报告

项目计划书

• 一些上下文方面与系统直接交互，从而影响系统需求的定义
  • 例：银行客户用自动提款机从他的账户里取钱。因此，在定义ATM的需求时，必须考虑到银行不同客户的具体情况
• 其他上下文方面不直接与系统交互，但仍以某种方式影响系统的需求
  • 法律要求进入银行系统并在系统内使用的敏感数据项使用某种加密标准进行加密。

• 主体刻面
  • 系统相关的对象和事件
    • Eg.系统必须存储或处理信息的元素
  • 需求来源
    • 领域专家
      • 医生和事故调查员，制动系统和驱动-列车控制系统专家
      • 律师和数据隐私官员
    • 文档:领域模型、教科书以及关于主题领域的法律
    • 现有系统
  • 上下文对象
    • 汽车本身以及相关汽车零部件如发动机、车轮、轮胎和刹车
    • 等车的乘客司机和co-driver
    • 汽车驾驶,行人等其他交通参与者
    • 车外环境条件如温度、道路状况等
  • 属性和关系
    • 陈述的准确性与现实性
    • 陈述的法律要求
• 使用刻面
  • 关于人或其他系统使用的方面
    • Eg.用户组和使用流程
  • 需求来源
    • 直接用户:司机控制汽车,汽车安全系统的反馈关于当前形势
    • 间接用户:co-driver不积极控制汽车,但他或她可能会影响驾驶员的决策
    • 专家:用户界面设计及相关应用领域
    • 文档:定义用户界面或允许使用工作流的质量方面的标准、法律和法规
    • 现有系统
  • 上下文对象
    • 用户群体:运动驾驶和安全驾驶之间的区别很重要
    • 使用界面类型:触觉、声学、语言或视觉
    • 使用工作流:使用过程、角色、活动和责任是潜在的、相关的上下文对象
    • 与其他系统的交互
  • 属性和关系
    • 使用工作流的关系
    • 用户组与使用工作流的关系
    • 与IT系统方面的关系
• IT系统刻面
  • 系统的IT系统环境的对象和要素
    • Eg。使用现有的硬件和软件组件
  • 需求来源
    • 相关利益相关者:所有处理IT系统环境的规划、设计和操作的人:系统架构师、硬件开发人员、测试专家或首席技术官。
    • 技术顾问和供应商。
    • 文档:开发公司的IT战略文档、客户的IT战略文档或描述系统运行的基础架构和相关策略的文档
    • 系统现有的参考架构
    • 现有系统
  • 上下文对象
    • 系统开发过程中需要考虑的硬件和软件组件
    • 系统的运行和维护需要开发
    • 相关公司的IT策略
  • 属性和关系
    • 硬件和软件部件的技术特性:性能特点或故障率;成本或对承包商和供应商的可用性和义务
    • 操作配置文件
    • 更新政策
• 开发刻面
  • 系统开发过程中涉及的方面
    • Eg.过程指南，开发工具
  • 需求来源
    • 相关利益相关者:过程工程师、过程管理者、过程执行者。
    • 文档:开发标准、开发指南、方法说明、最佳实践文档、以前项目的项目计划
  • 上下文对象
    • 角色定义
    • 工件定义
    • 活动定义
    • 工具
    • 资源可用性和资源限制
  • 属性和关系
    • 开发过程协调
    • 开发过程接口
    • 过程质量
• 主题和IT系统之间的关系方面
  • 表示关于真实世界的对象的信息,如汽车的速度或一个客户的名字
• IT系统之间的关系和使用方面系统流程代表信息根据功能
  • 主体与IT系统刻面的关系
    • 关于真实世界对象的信息的表示，例如汽车的速度或客户的姓名
    • Representation of information about real-world objects such as the speed of a car or the name of a customer
  • IT系统与使用刻面的关系
    • 系统进程根据功能表示信息
    • System processes represent information according to the functionality
  • 使用和主体刻面的关系
    • 系统用户解释系统的输出，并将其与主题方面的现实世界对象关联起来
    • System user interprets output of the system and associates it with the real world objects of the subject facet
  • 开发方面的角色
    • 考虑其他三个上下文方面的相关方面及其关系，因此是与所有其他方面相关的
  • 使用刻面可以提高需求文档的质量

• 目标:目标是与目标、属性或系统使用有关的意图
  • 愿景:系统愿景通常定义系统的最高目标
  • 因此，所有其他目标都应该细化系统愿景
• 目标的细化也被称为“目标分解”

• 目标的和-分解：
  • 将目标分解为一组子目标G1、…。Gn
  • n>1
  • 当且仅当满足所有子目标时，目标G才满足
    • 例：目标G“舒适、快速地导航到目的地”由A分解为以下三个子目标：
      • G1：轻松进入目的地
      • G2：根据用户特定参数自动布线
      • G3：显示交通堵塞和自动改道以避免交通堵塞。
• 目标的或-分解
  • 目标分解为一组子目标G1…Gn
  • n>1
  • 如果满足其中一个子目标，则目标G满足
    • 例目标G“定位汽车位置的能力”通过OR分解为以下两个子目标：
      • G1：通过手机定位汽车
      • G2：通过GPS定位汽车

• "Requires"“需要”目标之间的依赖关系
  • 如果满足G2是满足G1的先决条件，那么目标G1需要目标G2
  • 示例：G1需要G2
    • G1：系统应引导驾驶员绕过交通拥堵。
    • G2：系统应能接收交通信息。
• "Support" 目标之间的“支持”依赖关系
  • 如果对G1的对满足G2有积极贡献，则目标G1支持目标G2。
  • 示例：G1支持G2
    • G1：导航系统应能按需下载电子地图。
    • G2：系统应允许简单输入导航目的地。
• **“Obstruction”**目标之间的“阻碍”依赖
  • 如果满足G1阻碍了G2的满足，则目标G1阻碍了目标G2
  • 示例：G1干扰G2
    • G1：导航系统应能按需通过GSM网络下载电子地图。
    • G2：导航系统在GSM网络上产生的数据流量应尽可能低。
• **“Conflicts”**目标之间的“冲突”依赖关系
  • 目标G1和目标G2之间存在冲突，如果
    • （1） 满足G1不包括满足G2，且
    • （2） 满足G2排除了G1的满足。
  • 示例：G1和G2相互冲突。
    • G1：应能通过GPS定位车辆。
    • G2：应遵守特定国家的隐私法。
• 目标等价
  • 如果满足以下条件，两个目标G1和G2是等效的（关于目标满意度）：
    • （1） 满足G1导致满足G2，并且
    • （2） 满足G2导致满足G1。
  • 示例：G1和G2是等效的。
    • G1：系统应符合A国的车辆安全规定。
    • G2：系统应符合B国的安全规定。

4.4.1 A Template for Documenting Goals

• 使用非结构化自然语言的目标文档

  • G:舒适、快速地导航到目的地
    • G1:轻松进入目的地
    • G2:根据用户特定参数自动选择路线
    • G3:显示交通堵塞和自动改变路线以避免交通堵塞

• 记录目标的七条规则

  • 1.简明扼要地记录目标

    • G1:专家用户以及没有经验的用户应该能够使用该系统。没有经验的用户应该能够在不了解先前系统的情况下使用该系统。此外，没有经验的用户无需任何培训即可使用该系统。对于任何用户来说，如何使用系统肯定是不言而喻的。即使不了解类似的系统，也必须能够使用该系统
    • G1的改进定义:用户无需培训和/或了解以前的系统即可使用该系统。

  • 2.使用主动语态

    • G2:与以前的系统相比，季度报告的创建时间将缩短一半

      The duration of creating the quarterly reports shall be cut down by half compared with the predecessor system.

    • G2的改进定义:用户应能够在使用当前系统所需的一半时间内创建季度报告。

      The duration of creating the quarterly reports shall be cut down by half compared with the predecessor system.

  • 3.准确记录利益相关方的意图

    • G3:该系统将改善公司的工作流程。
    • G3定义的改进:系统应至少将订单处理的工作流程加快20%。

  • 4.将高级目标分解成更具体的子目标

    • G4:增加行车安全。
    • G4的改进定义:目标G4通过“与”分解分解为以下子目标:
      • G4.1:在湿滑路面上减少20%的制动距离。
      • G4.2:确保车辆在制动操作过程中保持可控。

  • 5.陈述目标的附加价值

    • G5:导航系统应提供一种进入旅行目的地的直观方式
    • G5的改进定义:导航系统应允许驾驶员在不分心驾驶的情况下进入期望的目的地

  • 6.记录引入目标的原因

    • G6:系统应提供直观的用户界面。
    • G6的改进定义:系统应提供直观的用户界面，因为其80%的用户每月仅使用系统一次或两次。

  • 7.避免定义不必要的限制

    • G7:通过优化数据传输时间，系统响应时间减少10%。
    • G7的改进定义:系统响应时间减少10%。

4.4.2 AND/OR Trees and AND/OR Graphs

• 和/或树:

  • 由表示目标分解的节点组成
  • 分层，每个节点正好有一个超级目标
  • 图形符号表示分解的类型(和/或)

• 和/或图:

  • 一些子目标有助于满足一个以上的超级目标
  • 和/或图是非循环的

• 扩展和/或图:

  • “需要”关系“
  • ”冲突”关系

4.4.3 i*(i-star)

• I *框架是一个记录和分析目标和目标依赖关系的综合方法。

• 基于GRL的建模语言

  • 用于记录目标分解的AND/OR树
  • 质量方面的建模构造

• 基本概念

  • 对象：参与者、目标、任务、资源、软目标

  • 关系

    • 依赖关系：参与者之间的关系
    • 链接：对象之间的关系（参与者除外）

  • i*框架中建模构造的符号

• i*中参与者之间的依赖关系

  • 目标依赖性：参与者依赖另一个参与者来实现目标
  • 任务依赖性：参与者依赖于另一个参与者来执行任务
  • 资源依赖性：参与者取决于另一参与者提供的资源的可用性
  • 软目标依赖性：参与者依赖另一个参与者来执行导致实现软目标的任务

• i中对象之间的关系*

  • 目的-手段链接:记录哪些要素(软目标、任务或资源)有助于实现目标
  • 贡献链接:记录任务或其他软目标对软目标的积极或消极影响
  • 任务分解链接:记录任务的基本要素(子任务)

• 两种目标模型

  • 策略依赖模型(SDM)

    • 记录了参与者之间的依赖关系
    • 记录了他们所依赖的任务、目标、软目标和资源

  • 策略原理模型(SRM)

    • 通过定义参与者的内部结构详细说明了每个参与者
    • 为外部依赖关系提供了基本原理

4.4.4 KAOS

• KAOS建模语言是KAOS框架的一部分，用于引出、指定和分析目标、需求、场景和责任分配。

• 六个补充视图或子模型

  • 目标模型
  • 障碍模型
  • 对象模型
  • 主体模型
  • 操作模式
  • 行为模型

• KAOS框架的基本结构，用于为目标建模并将目标责任分配给代理

• 目标

  • 行为目标:可接受的系统行为集合
    • 实现目标:属性必须最终持有
    • 保持目标:属性必须始终持有
  • 软目标:记录不同系统行为之间的偏好，没有明确的满意度标准
  • 代理:具有满足目标的特定角色的主动系统组件(例如:用户)
  • 关系
    • 和-分解:将一个超级目标关联到一组子目标
    • 替代分解:
      • 将多个和-分解分配给超级目标
      • 每个替代是一组和-分解(可能只有一个)
    • 潜在冲突:一个目标可能会阻止满足另一个目标
    • 责任分配(目标与代理的关系)
      • 表示代理负责满足目标
      • 只有最终目标(无法细化的目标)可以分配给代理

• 扩展和/或图表
  • 记录了目标和依赖关系，但没有代理
• i*框架
  • 主要针对参与者及其目标
  • 主要关注点:系统环境
  • 复杂的建模语言，在使用之前需要一些培训
• KAOS
  • 代理上的目标是系统用户或组件
  • 非常类似于扩展和/或目标图
  • 五个其他补充模型，也适用于硬件组件
  • 非常适合嵌入式系统
  • 在使用前需要一些培训

• 经理希望将教师填写的图书订单计算机化；
• 理赔经理希望将处理保险索赔所需的平均时间从2个月缩短到2周
• 首席信息官希望将计费系统与几家子公司的客户记录系统集成，这样就只有一个计费系统…

• “安大略省需要x光扫描的病人要等好几个月”
  • 漫长的等待是症状，而不是问题。问题可能是:
    • 缺少x光机；
    • 缺乏训练有素的工作人员；
    • 缺少医生处理数据，
    • 排班程序效率低下

将未知问题转化为已知问题

问题分析工具

• 用鱼骨图
  • 进行定性分析
  • 找出影响因素

• 用帕累托图

  • 进行定量分析
  • 找出关键因素

产品愿景:描述产品是关于什么的，以及它最终可能成为什么

• 将所有利益相关者聚集在一个共同的方向上
• 愿景陈述
  • 愿景陈述模板(根据摩尔)
    • For[目标客户]
    • Who[需求或机会陈述]
    • The[产品名称]
    • Is[产品类别]
    • That[主要优势，购买或使用的令人信服的理由]
    • Unlike[主要竞争对手、当前系统或当前业务流程]
    • Our product[主要差异化和新产品优势陈述]
  • For scientists who need to request containers of chemicals, the Chemical Tracking System is an information system that will provide a single point of access to the chemical stockroom and vendors. The system will store the location of every chemical container within the company, the quantity of material remaining in it and the complete history of each container’s location and usage. This system will save the company 25% on chemical costs in the first year of use by allowing the company to fully exploit chemicals that are already available within the company, dispose of fewer partially used or expired containers and use a single standard chemical purchasing process. Unlike the current manual ordering processes, our product will generate all reports required to comply with government regulations that require the reporting of chemical usage, storage, and disposal.(对于需要请求化学品容器的科学家来说，化学品跟踪系统是一个信息系统，它将提供对化学品仓库和供应商的单一访问点。