吉林大学软件需求分析 Software Requirement Analysis_吉林大学软件实例分析

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

缩写/术语

• RE：Requirements Engineering 需求工程
• SRS：Software Requirements Specification 软件需求规范
• SRA：Software Requirements Analysis 软件需求分析
• SDM：Strategic Dependency Model 战略依赖模型
• SRM：Strategic Rationale Model 战略理论模型
• CIO:chief information officer 首席信息官
• SA：Structured Analysis 结构化分析
• OOA：Object Oriented Analysis 面向对象的分析
• PDA：Problem Domain Analysis 问题域分析
• ERD(Entity-Relationship Diagram)实体关系图
• DFD(Data Flow Diagram)数据流图
• DD(Data Dictionary)，数据字典
• SERU(Subject area Event Report Use case) 主题subject -> 事件event/报告report -> 用例use case
• SRS:Software Requirements Specification软件需求规范说明书
• TE:Tabular expressions
• ROI:Return on Investment(ROI)投资回报率
• CCB： Change Control Board 变更控制委员会
• SDLC：Software Development Life Cycle 软件开发生命周期

Chapter 1 Introduction

• 1软件与软件工程
• 2软件需求
• 3需求工程

1 Software and Engineering

1.1Software

• 软件=程序+数据+文档

  

• 软件的基本特征

  • Complexity(复杂性)

  • Consistency(一致性)

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

  • Variability(易变性)

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

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

      

  • Invisibility(不可见性)

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

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

• 软件开发面临的挑战

  

• 软件之道

  

1.2软件工程

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

  • 一个高质量的软件系统

  • 与给定的预算

  • 在给定的期限

    while change occurs

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

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

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

  • 现代系统的特点

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

  • 是什么问题?

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

  • 为什么需要软件工程？

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

  • 什么是好的软件？

    

  • 软件过程

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

  • 基本活动包括：

    • 需求定义和分析

    • 设计

    • 编码（实施）

    • 测试

    • 维护

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

  • 软件工程费用

    

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

    • 瀑布模型

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

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

      

    • 提出了许多过程模型

      • V型

      • Incremental Model增量模型

      • Iterative Model迭代模型

      • Spiral Model螺旋模型

      • Agile敏捷的

        

        

        

1.3需求对软件项目的影响

• 修复错误的相对成本

  

• 需求缺省的典型案例

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

• 为什么需求分析很困难？

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

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

  • 问题复杂性

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

    

2 Software Requirements

2.1问题域

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

• 解系统:待开发的软件

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

  

2.2需求

• 用户解决问题或实现目标所需的条件或能力-------IEEE标准术语表

• 需求是期望系统的外部可观察特征

• 候选要求必须通过两项测试才能被视为有效： 需求的满足必须从系统外部的角度进行观察 需求必须有助于满足潜在客户或其他利益相关者的某些需求(涉众) -------艾伦·戴维斯2005

• 需求是系统中的一个必要属性，一种声明，它标识了系统的能力、特征或质量因素，以使其对客户或用户具有价值和效用----------The RE Handbook

• IEEE 610.12-1990“要求”的标准定义：

• 用户解决问题或实现目标所需的条件或能力

• 系统或系统组件必须满足或拥有的条件或能力，以满足合同、标准、规范或其他强制文件的要求

• 如1或2所示的条件或能力的书面表示

• 2.3要求的类型

  • 三级

    

    • A Example of Business Requirements
      • B1.通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10%以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。
    • A Example of User Requirements
      • U1.系统将通过短信将续保信息发给保费即将到期客户的代理人。
    • A Example of System Requirements
      • S1.系统每天检测保费即将到期(提前2周)的保单，并生成每日到期保单报表；
      • S2.系统向到期保单报表中的每张保单的代理人发送短信

  • 一个常见的分类

    • 功能需求:

      • 定义系统应该提供的服务，系统应该如何对特定的输入做出反应，以及系统在特定情况下应该如何行为。在某些情况下，也定义系统不应该做什么

    • 质量需求:

      • 定义系统、组件、服务或功能的质量属性

    • 约束:

      • 限制系统开发方式的组织或技术要求

      非功能性需求（质量需求+约束）

    • 住房信息系统的要求

      • R1:系统应该提供用户友好的界面。
      • R2:该系统应能生成一份包含所有被允许进入房屋记录的月报。
      • R3:如果用户输入了正确的PIN码(用户ID)，系统应开门并记录这次访问，记录的信息包括日期、时间和用户名。
      • R4:该系统应在2006年5月1日前上市。
      • R5:输入正确的PIN码后，应在0.8秒内开门。

    • 质量需求

      

    • 可用性：可用性是指系统实际可用和完全运行效率的时间百分比。

    • 效率：是衡量系统利用硬件资源(如处理器时间、内存或通信带宽)的指标。

    • 灵活性：灵活性表示需要多少努力来扩展系统的新功能完整性完整性表示系统在防止未经授权访问、违反数据隐私、信息丢失方面的保护程度。

    • 互操作性：指的是系统与其他系统交换数据或服务的容易程度。

    • 可靠性：指的是系统在一段时间内不发生故障的运行概率。

    • 鲁棒性：鲁棒性是指当系统或部件面临无效输入、连接的系统或部件存在缺陷或意外运行条件时，其继续正常运行的程度。可用性衡量用户为准备输入、操作、并解释系统可维护性的输出。

    • 可维护性：表明纠正缺陷或更改系统可移植性的容易程度。

    • 可移植性：与将系统或组件从一个操作环境迁移到另一个操作环境所需要的工作有关。

    • 可重用性：可重用性指的是一个组件可以在系统中使用的程度，而不是它最初开发的那个系统。

    • 可测试性：可测试性指的是测试软件组件或集成系统以发现缺陷的容易程度。

  • 非功能性需求

    • 未详细说明的功能需求
      • 细化——将其定义为一组或一组功能需求，如有必要，还应包括相应的质量需求。
    • 质量要求

    

    • 非功能性需求的例子
      • R12:系统应安全。
        • 形容词“secure”是什么意思?
        • 为了“安全”，系统应该提供哪些属性?
        • 如何检查实现的系统是否“安全”?
      • 经过细化:
        • R12.1:每个用户使用系统前，必须使用用户名和密码登录系统-fr
        • R12.2:系统每四周提醒用户修改密码。-fr
        • R12.3:用户修改密码时，系统确认新密码至少包含8个字符，且包含数字和字母。-fr
        • R12.4:用户密码存储系统需要进行安全保护，防止用户密码被盗 -qr(integrity)

  • 约束:约束是一种组织或技术需求，它限制了开发系统的方式。

    • 约束类型

      • 约束影响系统使用:
        • C1:根据保险公司的规定，只有安全专家才能停止系统的控制功能。
        • C2:消防部门要求销售终端尺寸不能超过120cm(高)90cm(宽)20cm(深)。
      • 约束影响开发
        • C3:系统开发工作量不能超过480人月。
        • C4:系统必须使用Rational Unified Process进行开发

    • 约束限制了需求实现的范围，也限制了整个系统的范围

      

    • 约束可能导致需求的变更或新需求的定义。

      • 例如:以下是为建筑物的安全系统定义的需求
        • R-F-17：每个人的身份验证都应使用个人密码。
        • 在知道此类建筑物访问控制必须符合77/12/EG标准后
        • R-F-17 指纹传感器应用于访问控制系统，以验证每个人的身份
        • R-Q-4：必须以至少60个细节的准确度执行认证。

  • 

  • 一些例子

    • 系统应保存所有图书馆资料的记录，包括书籍、连载、报纸和杂志、录像带和录音带、报告、透明胶片收藏、计算机磁盘和CD-ROM。
    • 系统应允许用户按标题、作者或ISBN搜索项目。
    • 系统的用户界面应使用万维网浏览器实现。
    • 系统应支持每秒至少20个事务

  • 需求类型间存在一定的重叠

    • 功能性需求与非功能性需求间的划分并非绝对的，可能存在一定的重叠
    • 例如：以下几个例子既是一个功能性需求，又是一条安全性需求
      • 防火墙管理软件的功能性需求也同样是安全性需求
      • 来电过滤常常被看做是功能性特征，同时它也和通话者的隐私需求相关
      • 向列车高频发送加速请求，既是功能需求，也是安全需求和性能需求

  • 不切实际的期望

    • 需求表达的是一种期望
    • 不切实际的期望
      • 在使用系统时，收银员必须在2个小时之内完成一个销售处理的所有动作
    • 修改为：
      • 如果一个销售处理任务在2个小时之内仍没有完成，系统要撤销该任务的所有已执行操作

  • 性能需求(performance)

    • 速度：系统完成任务的时间
      • pr1:所有的用户查询都必须在10秒之内完成
    • 容量：系统所能存储的数据量
      • pr2:系统应该能够存储至少100万条销售信息
    • 吞吐量：系统在连续的时间内完成的事务数量
      • pr3:解释器每分钟至少解析5000条没有错误的语句
    • 负载：系统可以承载的并发工作量
      • pr4:系统应该允许50个营业服务器同时从集中服务器上进行数据的上传和下载
    • 实时性：严格的实时要求
      • pr5:监测到病人异常后，监控器必须在0.5秒内发出警报

3 Requirements Engineering

3.1需求工程的历史

• 在20世纪80年代，RE逐渐成为一门独特的专业学科
• 20世纪90年代，RE成为重点领域
• ISRE(需求工程国际研讨会) 自1993年以来每两年举行一次
• ICRE(需求工程国际会议)自1994年以来每两年举行一次
• 需求工程杂志（REJ）成立于1996年
• 一些讲习班已经设立并投入运行，如雷诺阿(欧洲),奥威尔(澳大利亚)

3.2需求工程的定义

• 什么是工程？

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

  

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

• 需求工程的定义

  • 定义1

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

  • 定义2

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

  • 定义3

    

  • 定义4

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

• 3.3需求工程活动

• Inception

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

• elicitation需求获取

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

• analysis and negotiation需求分析和谈判

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

• 需求规范

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

• 需求验证

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

• 需求管理

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

• 需求开发过程

  

• 需求的三个维度

  • 内容——问题的覆盖

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

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

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

  • 一致性-商定的要求

    • 是否达成了共同协议?

    

• 连续需求工程

  • 传统的系统分析

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

    

  • 持续需求工程

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

      

  • 持续需求工程

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

      

Chapter 2 Requirements Inception（启动）

• Requirements Inception的主要任务

• Requirements Inception的文档

• Context aspect 环境方面

• Goals 目标

• 问题分析

• 可行性分析和风险分析

1 Requirements Inception的主要任务

• RE过程的起点

  • 有时作为RE elicitation的一部分

• 它的主要任务包括

  • 1.确定业务需求

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

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

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

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

      

    • 了解根本原因是什么

      • 确定导致问题的因素

    • 确定导致问题的因素

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

        

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

  • 3.确定利益相关者

     谁使用这个系统？

     谁是顾客？

     谁受到产出的影响？

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

     其他外部/内部用户？

     谁维护这个系统？

     有人在乎吗？

    

  • 4.确定约束和风险

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

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

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

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

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

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

      

  • 5.进行可行性研究

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

• RE Inception的主要任务总结

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

2 Documents in 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.项目优先事项

• 项目可行性报告

• 项目计划书

  

3 Context aspect

• 上下文方面：是系统上下文的物质和非物质对象，如人、技术和非技术系统、过程、事件或物理定律。
  • 一些上下文方面与系统直接交互，从而影响系统需求的定义
    • 例：银行客户用自动提款机从他的账户里取钱。因此，在定义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
    • 开发方面的角色
      • 考虑其他三个上下文方面的相关方面及其关系，因此是与所有其他方面相关的
    • 使用刻面可以提高需求文档的质量

4 Goals

• 目标和目标分解
  • 目标:目标是与目标、属性或系统使用有关的意图
    • 愿景:系统愿景通常定义系统的最高目标
    • 因此，所有其他目标都应该细化系统愿景
  • 目标的细化也被称为“目标分解”
• 和/或目标分解
  • 目标的和-分解：
    • 将目标分解为一组子目标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 Documentation Goals

• 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
    • 代理上的目标是系统用户或组件
    • 非常类似于扩展和/或目标图
    • 五个其他补充模型，也适用于硬件组件
    • 非常适合嵌入式系统
    • 在使用前需要一些培训

5 Problem Analysis

5.1确定问题

• 顾客陈述的模糊问题
  • 经理希望将教师填写的图书订单计算机化；
  • 理赔经理希望将处理保险索赔所需的平均时间从2个月缩短到2周
  • 首席信息官希望将计费系统与几家子公司的客户记录系统集成，这样就只有一个计费系统…
• 通常你只看到症状而不是原因:
  • “安大略省需要x光扫描的病人要等好几个月”
    • 漫长的等待是症状，而不是问题。问题可能是:
      • 缺少x光机；
      • 缺乏训练有素的工作人员；
      • 缺少医生处理数据，
      • 排班程序效率低下

5.2找到根本原因

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

• 问题分析工具

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

  

  • 用帕累托图

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

    

5.3定义解决方案系统的愿景和边界

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

  • 将所有利益相关者聚集在一个共同的方向上
  • 愿景陈述
    • 愿景陈述模板(根据摩尔)
      • 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.(对于需要请求化学品容器的科学家来说，化学品跟踪系统是一个信息系统，它将提供对化学品仓库和供应商的单一访问点。该系统将存储公司内每个化学品容器的位置、其中剩余的材料数量以及每个容器的位置和使用的完整历史。该系统允许公司充分利用公司内部已有的化学品，处理较少的部分使用或过期的容器，并使用单一的标准化学品采购流程，从而在使用的第一年为公司节省25%的化学品成本。与目前的手动订购流程不同，我们的产品将生成符合政府法规的所有报告，这些法规要求报告化学品的使用、储存和处置。)

• 边界:解决方案系统边界系统和参与者之间的

  • 职责边界

  • 系统边界将属于系统并因此可以在开发过程中更改的部分与系统上下文中在开发过程中不能更改的部分分开

  • 边界确定

    

    

  • 范围和边界

    • 边界：系统与参与者之间的职责边界
    • 范围：系统为满足用户需求所能做的事情，通常表示系统的功能
    • 

  • 作用域和边界的表示

    • 上下文图的表示(边界)

    

    • 系统用例图(边界和范围)

    

5.4确定对解决方案施加的限制

• 按照预想的方式对交付解决方案的能力进行限制
• 通常非功能性的需求会对系统施加主要的限制
• 限制的来源包括:
  • 经济(如预算)
  • 政治(如许可问题、部门间问题)
  • 技术(如技术/平台选择)
  • 系统(如现有系统、兼容性问题)
  • 环境(如法律/生态/安全/标准)
  • 进度和资源(如固定进度、团队)

5.5系统分解策略

• 5.5.1分解策略

  • 程序分解结构

    • 系统→子系统→模块→子模块

      

  • 业务流分解结构

    • 主题领域→业务事件与报告

    

• 5.5.2分解步骤

  • (1)划分主题域

    • 职责驱动的

      

      • 对目标的贡献

      

      • 划分结果

      

  • (2)确定主题域范围

    • 绘制每个主题域的上下文关系图

      

      

      

      

6 Feasibility Study and Risk Analysis

6.1可行性研究

• 为什么要进行可行性研究
  • 确定一个系统开发项目是否可以完成:
    • …是可能的吗?
    • ……是合理的吗?
• 提出可能的替代解决方案。
• 为了给管理层提供足够的信息:
  • 项目是否可以完成
  • 最终产品是否会使预期的用户受益
  • 有哪些替代方案(以便在后续阶段进行选择)
  • 是否有首选的替代方案
• 可行性研究内容
  • 现行组织体系
    • 利益相关者、用户、政策、功能、目标……
  • 当前系统的问题
    • 不一致，在功能，性能方面的不足，……
  • 新系统的目标和其他要求
    • 哪些问题需要解决?
    • 利益相关者希望实现什么?
  • 约束
  • 可能的替代方案
    • 解决问题的不同业务流程
    • 解决方案的不同级别/类型的计算机化
  • 替代方案的优点和缺点
• 可行性探索
  • 探索可行性-----“PIECES”框架
    • Performance 性能(当前的吞吐量和响应时间是否足够?)
    • Information 信息(终端用户和管理者是否得到及时、相关、准确和格式有用的信息?)
    • Economy 经济(现行系统提供的服务是否划算?/会降低成本和/或增加福利吗?)
    • Control 控制(是否有有效的控制措施防止欺诈，确保信息的准确性和安全性?)
    • Efficiency 效率(当前的系统是否很好地利用了人力、时间、形式流等资源?)
    • Services 服务(当前服务可靠吗?它们是否灵活和可扩展?)
• 四种可行性类型
  • 技术可行性
    • 以目前的技术，这个项目可能吗?
    • 有什么技术风险?
    • 技术可用性
  • 经济可行性
    • 在资源有限的情况下，该项目是否可行?
    • 开发和运营成本是多少?
    • 有什么好处?
    • 收益是否值得付出代价?
  • 进度可行性
    • 是否有可能及时建立解决方案?
    • 延误的后果是什么?
    • 行程有什么限制吗?
    • 这些约束条件可以满足吗?
  • 社会可行性
    • 如果开发了该系统，会被使用吗?
    • 潜在的劳工异议?
    • 经理电阻吗?
    • 组织冲突和政策?
    • 社会可接受性?
    • 法律问题和政府法规?

6.2风险分析

• 项目的主要风险

  ◼不清楚的需求
  ◼不断变化的需求
  ◼不稳定的产品或设计
  ◼紧迫的项目和不可达到的里程碑
  ◼肤浅的或不准确的工作量和影响估计
  ◼没有跟踪的项目计划
  ◼没有控制的分包

• 减轻风险的技术

  ◼组合管理（portfolio management）中评价与选择的技术
  ◼在需求分析阶段就评估变更风险
  ◼项目管理要适应不确定性和变更
  ◼开发过程适应不确定性和变更
  ◼架构和设计适应不确定性和变更
  ◼严格的和系统性的变更管理

• 风险核查清单

  ◼项目里有没用过的新技术吗？
  ◼完整定义了与其他系统或组件的接口吗？
  ◼设计依赖于不切实际或过于乐观的假设吗？
  ◼考虑了系统的行为（性能等）吗？
  ◼外部组件质量达标了吗？
  ◼使用了专利、版权或专有技术吗？其法律或间接成本确定
  了吗？
  ◼使用了什么开源软件，用的是什么协议？
  ◼有分包商（或外包，离岸外包）吗？
  ◼与供应商签订的是什么样的合同？供应商承担什么样的风
  险？
  ◼对于关键零部件是否有替代供应商？

Chapter 3 Requirements Elicitation（获取）

• 1关于需求获取
• 2需求获取技术
• 3场景

1 About Requirements Elicitation

1.1需求获取的定义

• 需求获取是“通过与客户、系统用户和其他参与系统开发的人沟通，发现系统需求的过程”
• 三个子活动:
  • 识别相关的需求来源
    • 未考虑相关需求源导致需求规范不完整
    • 识别未知相关需求源的过程
      • 第一步：识别潜在需求源
      • 第二步：评估需求源的相关性
  • 抽取现有需求
    • Eliciting existing requirements from stakeholders 引出利益相关者的现有需求
      • 访谈、问卷调查、观察
    • Eliciting existing requirements from documents 引出文档中的现有需求
      • 基于视角的阅读
    • Eliciting existing requirements from existing systems引出现有系统中的现有需求
      • 使用或观察系统
      • 采访系统的利益相关者
      • 分析系统文档
  • 开发新的创新性需求
    • 开发新的和创新的需求是一个创造性的过程，
    • 可以通过应用创造性技术(头脑风暴、奥斯本检查表)来支持
    • 将不同观点的不同利益相关者聚集在一起
• 需求来源
  • 干系人(Stakeholders)
    • 涉众是积极参与项目、受项目结果影响或能够影响项目结果的个人、团体和组织
      • 用户—关心新系统特征和功能
      • 设计师一想要构造完美的系统，尽量重用已有的代码
      • 系统分析师—想要获取正确的需求
      • 培训与用户支持人员一确保系统可用和可管理
      • 业务分析师—想确保“我们做得比竞争对手好”
      • 技术文档作者一为系统准备用户手册及其他相关文档
      • 项目经理—希望按时、按预算、按目标完成项目
      • 客户—为新系统买单的人
  • 业务流程(Business Process)
    • 对现有业务过程的分析有助于识别业务问题并加
      以改进
      • 找出并列举当前业务过程中的问题
      • 分析问题的本质（遗漏？不好用？新需求？）
      • 分析改进的机会
      • 分析改进的实质（自动化？流程改进？）
  • 组织规章与制度(Organization Provisions)
    • 分析规章制度有益于确定业务规则和约束条件
      • 业务规则：描述对业务过程的要求，如系统支撑的业务过程的结构、控制、行为效果
      • 约束:对系统开发过程的管理限制，主要涉及经济、政治、技术和环境四个方面，具体包括项目资源、时间、目标环境及系统本身。
    • 组织规章中往往还涉及过程自动化、工作流、关系、交互等内容
  • 现有系统(Existing system)
    • 分析现有系统有助于了解未来系统的工作数据
      • 数据对象
      • 数据关系
      • 数据库结构与系统结构
      • 系统报告
    • 现有系统
      • 用户手册
      • 数据样本
      • 接口描述
      • 报告样本
      • Screen-spot
  • 需求获取的常见困难—应对措施
    • 用户和开发人员的背景不同，立场不同
      • 消除默认知识
    • 普通用户缺乏概括性、综合性的表述能力
      • 专业的需求人员
    • 用户存在认知困境
      • 原型
    • 用户越俎代庖
      • 设计相关的需求要由开发人员而非用户提出
      • 协商
    • 缺乏用户参与
      • 为用户参与提供方便条件

1.2需求获取的过程

• 系统开发人员和工程师与客户和最终用户

  • 密切关系找到更多关于要解决的问题
  • 来描述系统的功能
  • 系统性能
  • 硬件的性能约束…等等

• 引出需要及时完成

• 不仅仅是一个简单的过程需求，但是一个高度复杂的过程

1.3需求获取中的需求工件

• Elicitation Notes笔记

  • 用户需求、问题领域知识和解决方案的约束
  • 可能组织不善、冗余、遗漏、不一致
  • 可能形式多样:音频、视频、文字、图表

• 正式文件

  • 用例图及用例说明

2 Elicitation Techniques 需求获取技术

2.1 Interviews 访谈

• 需求工程师或分析师与不同的涉众讨论系统，并建立对他们需求的理解
• 两种问题类型
  • 封闭式问题
    • 需求工程师寻找一组预定义问题的答案
  • 开放式问题
    • 没有预定义的议程，需求工程师以开放式的方式讨论涉众希望从系统中得到什么
      • eg.描述一种理想的汽车安全系统。系统如何识别对司机的威胁，并如何对检测到的威胁作出反应?
• 面试执行过程
  • 制备
    • 目标、参与者、时间、地点,
  • 执行
    • 开放的问题:解释的目标,引入问题
    • 工作元素:
      • 简单的模型,使用场景,休息,文档结果
    • 终结
    • 随访
• 利弊
  • 优点:
    • 简单的执行条件,减少经济成本
      • 获得各种信息,如事实、问题,观点,态度,信念等等
      • 容易与利益相关者建立友好关系,提高参与热情
  • 缺点:
    • 巨大的时间成本,限于时间和地区
    • 依赖沟通技巧
  • 使用时间：任何项目
• 关键成功因素关键
  • 沟通技巧
  • 无引导式问题
  • 明确界定沟通目标
  • 术语
  • 了解面试伙伴
  • 避免群体思维效应

2.2 Questionnaires

• 2.2.1问卷设计
  • 问卷格式
    • 目标确定格式
    • 足够的回答空间
    • 一致风格
  • 设置顺序
    • 重要问题先验
    • 相似的问题一起
    • 考虑之间的联系问题背后
    • 争议问题在非争议性问题后
• 2.2.2问卷过程
  • 准备
    • 定义目标和预期结果
    • 选择利益相关者谁能回答问卷
    • 定义问题的问卷
    • 封闭式问题,定义回答选项
    • 开放式问题,定义了文档格式的答案
    • 如果必要,培训应答者使用所需的文档格式记录需求
  • 执行
    • 告知涉众的目标调查
    • 定义一个合适的时间回答问题的问卷
    • 提供联系人回答利益相关者的询问
    • 向利益相关者的贡献表达你的感激之情
  • 后续
    • 分析利益相关者的反应问题在问卷中
    • 如果有模棱两可或难以理解的答案，请与受访者核对，如果可能的话
    • 将问卷分析的结果反馈给受访者
    • 注意结果中相互矛盾的要求
• 2.2.3利弊
  • 优点
    • 不受时间、地域限制
    • 易于获得统计结果
  • 缺点
    • 难以深入联系用户
  • 使用时间
    • 作为访谈方法的补充
    • 非常适合于引出需求或需求源的初始集合
• 2.2.4关键成功因素
  • 可理解的问题
  • 明确定义的答案
  • 培训的利益相关者
  • 选择正确的文档形式

2.3 基于视角的阅读 Perspective-based Reading

• 需要阅读的文件包括：
  • 法律、标准、开发指南、用户手册、系统架构文档、需求规范、测试文档等。
• 准备
  • 观点、文件、利益相关者
• 处决
  • 阅读顺序：顺序阅读或自上而下阅读
  • 在文本段落和引出的需求之间建立可追溯性
• 随访
  • 整合启发结果
  • 发现冲突

2.4 观察 Observation

• 观察意味着观察者通过观察涉众或现有的系统来引出需求。
  • 涉众能够在执行这些活动时提供更详细的活动描述。
  • 现有的设计和架构提供了解决方案词汇表
  • 我们对现在工作的东西的理解，以及它是如何工作的，影响着我们的需求和感知需求
  • 我们对现有系统的经验的洞察力帮助我们想象什么可能工作，并使我们能够评估开发时间和成本
• 2.4.1.观察的类型
  • 两种观察方式
    • 直接观察
      • 观察者观察利益相关者
    • Ethnography observation 民族志观察
      • 观察者花很长时间与利益相关者一起积极参与工作
• 2.4.2观察过程
  • 准备
    • 观察目标、期望结果、被观察的人或系统
  • 执行
    • 观察指南
      • 不要对观察到的活动提出质疑
      • 寻求利益相关者的信任
      • 捕捉细节(用人种志观察更容易)
      • 记录观察结果
      • 做到客观
      • 检查活动的真实性
      • 通过询问支持观察
    • 文档格式
      • 文本:缺点:观察者在写问题时注意力不集中
      • 视频:录制经常被认为是不愉快的，分析很耗时
      • 音频:其他格式的替代或补充
  • 跟进
    • 处理记录(需要让没有参与观察的人能够理解)
    • 与利益相关方协调文件(降低不正确解释的风险)
  • 利弊
    • 优点
      • 非常适合引出现有需求
      • 有助于了解复杂的合作流程
    • 缺点
      • 需要大量资源
      • 分析工作取决于记录结果的方式
  • 关键成功因素
    • 利益相关者愿意合作
    • 处理结果(结果在处理后才能理解)
    • 观察者的客观性(尽可能客观地记录结果)
    • 可观察性(观察的努力，需要利益相关者做出多少解释)

2.5 原型 Prototyping

• 2.5.1什么是原型?
  • 原型是软件系统的初始版本，用于演示概念，尝试设计选项，通常，找出更多关于问题及其可能的解决方案。
    • 有助于开发人员、用户和客户更好地理解系统需求
    • 帮助澄清和完成需求
    • 提供对“我会看到（或不会看到）它”态度的早期响应
    • 有效解决“是的,但是”和“未被发现的废墟”综合症
    • 有助于找到新的功能,讨论可用性,并建立优先级
• 2.5.2原型的类型
  • 开发方法
    • 探索性:从有缺陷的需求出发，然后不断调整和修改
    • 实验性:从一个明确定义的需求和一个模糊的实现方法出发，实现效果和可行性
    • 进化性:以增量的方式转变为产品，为用户提供更快的工作系统(从更容易理解的需求开始)
  • 构建技术
    • 水平的:关注一层功能需求
    • 垂直的:真实系统的一部分
• 2.5.3优点和缺点
  • 优点
    • 探索需求和验证需求
    • 及早发现不确定性并降低风险
  • 缺点
    • 客户要求快速交付产品
    • 用户过分关注非功能性需求而忽略功能性需求
    • 用户的假设可能被覆盖
    • 巨大的开发成本

2.6 Brainstorming

• 2.6.1什么是头脑风暴?
  • 在开放的氛围中聚集或交流利益相关者的想法，没有人会因为他们的想法而被嘲笑，也没有人的想法会被拒绝或批评。
  • 使用时间:在项目早期，特别是当
    • “地形”是不确定的时候
    • 对于应用类型缺乏专业知识
    • 创新很重要(例如，新颖的系统)
    • 有太多或太少的想法
• 2.6.2头脑风暴过程
  • 风暴阶段
    • 产生尽可能多的想法(数量，而不是质量)-狂野是好的!
  • 冷静阶段
    • 从想法中过滤(结合、澄清、优先考虑、改进……)以保留最好的想法——可能需要一些投票策略
  • Osborn Checklist(对于导航系统来说)
    • 下面的问题支持关于一个确定的起点的创造力:
      • 用于其他用途?(新的使用方法?修改后的其他用途?)
        • 导航系统可用于指导用户在城市观光游览期间进行导航
      • 适应?(还有什么是这样的?这还意味着什么?)
        • 导航系统中的路线表示可以进行调整
      • 修改?(改变意义、颜色、运动、声音、气味、味道、形式、形状?其他变化?)
        • 路线可以投射到挡风玻璃上
      • 放大?(要补充的吗?更大的频率?更强的吗?更大的吗?加成分?乘?)
        • 导航系统可以控制并充当自动驾驶仪
      • 贬低?(减去什么?消除?小吗?轻吗?分手吗?更少?)
      • 替代?(还有谁呢?还有什么呢?其他地方吗?其他时间?)
      • 重新安排?(其他布局?其他序列?改变节奏?)
      • 相反?(相反?把它向后?把它颠倒过来?把它翻过来?)
        • 导航系统可以了解驾驶员首选的路线
      • 联合?(混合、搭配怎么样?结合目的?把想法?)
        • 导航系统可与交通信息系统相结合，以便在路线规划时考虑交通拥堵
• 2.6.3利弊分析
  • 优点
    • 听取大家的意见
    • 鼓励创造力
    • 有助于开发全新的系统
  • 缺点
    • 许多想法（必须进行分类和优先排序）
    • 努力营造良好的氛围
    • 很难让每个人都参与进来
    • 费时

3 Scenarios

3.1场景的基本原理

• 场景：场景描述满足或未能满足目标（或一组目标）的具体示例。因此，它提供了关于一个或多个目标的更多细节。场景通常定义为满足目标而执行的一系列交互步骤，并将这些交互步骤与系统上下文相关联
• 场景作为将需求放在上下文中的一种手段，是一种中层抽象
• 场景“自动制动操纵”中的上下文信息
  • 演员：卡尔
  • 角色：司机
  • 目标：保持安全距离
  • 前提条件：汽车行驶速度超过50英里/小时
  • 后置条件：未发生追尾事故，与前方车辆的安全距离恢复
  • 资源：到彼得的车的距离
  • 地点：在高速公路上

3.2场景类型

• 当前状态和所需状态场景

  • 当前状态情景（指示性情景）
    • 描述当前系统现实的特定方面或视角
  • 期望状态场景（可选场景）
    • 也可用于描述所需的系统使用情况
  • 指示性和选择性情景是变更定义的重要驱动因素
    

• 正面和负面情景

  • 积极情景记录了导致目标实现的一系列互动
  • 负面场景记录了未能满足目标的一系列交互
    • 负面情景可能被允许或禁止
  • 积极情景和消极情景相辅相成
  • 负面场景
    • 示例:允许的负面场景
      • 克里斯将她的银行卡插入自动柜员机的插槽。克里斯输入她的个人识别号码和取款金额。自动取款机通知克里斯，不能提取想要的金额，因为金额超过了她的余额。
    • 示例:禁止的负面场景
      • 杰克将他的银行卡插入自动取款机的插槽。杰克输入他的个人识别号码和取款金额。自动取款机从杰克的账户中收取所需金额。ATM机在发钱时，发钱机制发生故障。

• 不当使用场景

  • 恶意行动者
  • 违反利益相关者的意图使用
  • 例:滥用汽车安全系统
    • 另一辆车的司机汤姆故意插到卡尔的正前方，使卡尔的车完全刹车。在刹车过程中，卡尔受伤了

• 描述性、探索性和解释性情景

  • 描述场景
    • 描述过程或工作流程
    • 目的:了解其操作
    • eg描述性的场景“输入目的地”
      • “进入目的地”卡尔想开车去普利茅斯的联合大街。卡尔使用汽车的导航系统来寻找最短的路线。他选择“Enter Destination”(输入目的地)。导航系统显示“请通过语音输入或手动输入所需目的地”。卡尔决定通过语音输入进入目的地，并说“普利茅斯”。由于背景噪音和他糟糕的发音，系统无法清楚地识别目的地。系统显示它从语音条目中以最高概率识别出的目的地：“朴茨茅斯”。系统还显示消息“您的条目无法模糊地识别”以及下列选项：(1)接受目的地(是/否)(2)新条目(新)(3)显示相似的位置(相似)(4)手动输入(按“M”键)Carl说“Simple”，系统列出位置“朴茨茅斯”、“Plymouth”等。Carl说“Plymouth”，系统选择普利茅斯作为目的地。
    • 探索场景
      • 文件可选实现方式，允许探索一套不同实现方式
      • eg.探索性场景“进入起点”
        • 卡尔想用他车里的导航系统开车去目的地。第一个问题是，旅程的起点是否总是汽车的当前位置，或者卡尔是否可以自己定义起点。起点的自动选择避免了额外的用户交互，并支持快速导航。允许起点进入将有助于计算起点不同于当前位置的路线。有了这个设施，该系统可以作为旅行计划的一种手段。例如，卡尔可以找出从巴黎到尼斯有多远，以及到达那里需要多长时间，而不考虑他的车目前的位置。第三种可能性是允许用户在功能“导航”(使用当前位置作为起点)和在用户菜单中输入“起点”的“导航”之间进行选择。其中，功能“导航”将被指定为默认设置。
    • 解释场景
      • 提供特定交互序列的背景信息和原理
      • eg.解释场景“自动制动操纵”
        • 由于两辆车之间的距离迅速缩短，发生追尾事故的风险很高。快速改变车道可能会导致汽车打滑或旋转，因为汽车正在高速公路上以超过55英里每小时的高速行驶。因此，在换道之前，汽车的速度必须降低。因此，机载计算机启动一个自动紧急制动操纵。由于防抱死制动系统可以确保汽车在刹车时保持可操控性，卡尔可以在操纵过程中安全地换道。为了避免司机受到自动刹车的惊吓，系统会通知卡尔紧急刹车的启动。在与前面行驶的汽车恢复安全距离后，车载电脑将控制权交还给卡尔。系统通知卡尔控制权的转移，以便他准备接管控制权。

• 实例、类型化和混合场景

  • 实例场景
    • 描述具体参与者之间的具体(现有的或设想的)交互序列
    • 示例:Instance Scenario实例场景
      • 卡尔想开车去普利茅斯的联合街。卡尔使用牌照号为“E-IS-12”的大众高尔夫的导航系统。卡尔在主菜单中选择“输入目的地”，输入目的地“普利茅斯联合街”，然后按键“计算路线”
  • 类型场景
    • 从具体参与者中抽象出来，输入和输出的一个特定序列的交互
      • 示例:类型场景
        • 司机需要通过导航系统行驶到目的地。The driver 进入目的地。系统计算从汽车当前位置到输入目的地的路线
  • 混合场景
    • 重要性内容描述实例级
    • 不完全理解在实例级描述,以避免错误造成早期抽象
    • 内容清楚描述类型级别
    • 冲突或潜在的冲突在实例级描述的内容

• 系统内部、交互和上下文场景

  • 系统内部(A型)场景

    • 只关注系统内部交互

    • 一个系统内部的场景只记录系统内部的交互，即系统不同部分之间的交互序列。

    • eg.组件“导航控制”向“本地化”组件请求GPS坐标。“本地化”组件为“导航控件”提供坐标。组件“导航控件”调用组件“显示控件”，并传递当前位置和目标。组件“屏幕输入”将路由参数传递给组件“导航控制”。因此，“导航控制”组件计算最终的路线。

      

  • 交互(B型)场景

    • 记录系统与其参与者(上下文中的人和系统)之间的交互序列

    • eg.参见描述场景“enter destination”

      • “进入目的地”卡尔想开车去普利茅斯的联合大街。卡尔使用汽车的导航系统来寻找最短的路线。他选择“Enter Destination”(输入目的地)。导航系统显示“请通过语音输入或手动输入所需目的地”。卡尔决定通过语音输入进入目的地，并说“普利茅斯”。由于背景噪音和他糟糕的发音，系统无法清楚地识别目的地。系统显示它从语音条目中以最高概率识别出的目的地：“朴茨茅斯”。系统还显示消息“您的条目无法模糊地识别”以及下列选项：(1)接受目的地(是/否)(2)新条目(新)(3)显示相似的位置(相似)(4)手动输入(按“M”键)Carl说“Simple”，系统列出位置“朴茨茅斯”、“Plymouth”等。Carl说“Plymouth”，系统选择普利茅斯作为目的地。

      

  • 上下文(C型)场景

    • 记录系统与其参与者之间的直接交互

    • 记录与系统使用或系统本身相关的附加上下文信息(例如参与者以及系统的间接用户之间的交互)

      

  • 主场景、可替换场景和例外场景

    • 主场景
      • 满足目标的最常见交互顺序
    • 可替代场景
      • 可以代替主场景执行的交互序列
      • 实现与主要场景相关的目标
        • eg.主要场景摘录:
          • 步骤11:
          • 步骤12:司机在电子地图上选择目的地。
          • 步骤13:…
          • 备选方案的摘录:
          • 步骤11:…
          • 步骤12a:驱动程序从目的地列表中选择一个目的地。
          • 步骤13:…
    • 例外场景
      • 仅在特殊事件发生时执行的交互序列
      • 导致无法满足与原始场景相关的一个或多个目标
        • 除主场景外:
          • step12:…
          • 步骤13:系统确认目标成功输入。
          • 步骤14:系统提示司机到目的地的路由计算成功。
          • 步骤15:…
          • 例外情况除外：
          • 步骤13:…
          • 步骤14a:导航系统检测到电源即将故障。
          • 步骤15a:导航系统自动关闭。

3.3用例

• 用例：一个系统、子系统或类可以通过与外部对象交互来执行的动作序列（包括变量序列和错误序列）的规范，以提供有价值的服务。

• 用例包含：

  • 上下文信息：

    • 目标、先决条件、后决条件

  • 主要情景

  • 备选方案

  • 例外情况

• 用例的组成部分

3.4记录场景和用例

• 叙事情景

  • 场景以自然语言记录
    • 许多信息混合在一起
  • 例:摘自一个叙述场景。驾驶员辅助系统包括一个(子)系统，以避免真实端碰撞。该系统包括(1)距离传感器(2)永久检查与前方行驶车辆的距离(3)，以避免即将发生的追尾事故。(4)如果系统检测到距离低于安全距离，但仍在临界范围之外，则会发出声音警告信号。(5)或者，可以在汽车驾驶舱内的驾驶员显示器上显示符号或信息。如果2秒后司机没有对警告做出反应，两辆车之间的距离仍在减小，系统就会降低汽车的速度。(7)任何时候距离低于行驶速度的四分之一时，系统启动紧急制动。

• 结构化场景

  • 通过结构提高自然语言场景的可理解性和可读性

  • 两种构造方法

    • 场景步骤的枚举

      • （1） 驾驶员启动导航系统。
      • （2） 导航系统确定汽车的当前位置。
      • （3） 导航系统询问所需的目的地。
      • （4） 司机进入目的地。
      • （5） 导航系统识别地图的相关部分。
      • （6） 导航系统显示目的地区域的地图。
      • (7) …

    • 交互序列的表格文档

      • 每个参与者的列，列中的顺序

      

  • 场景参考模板

    • 提供特定和一般属性
    • 特定于项目的改编

    

• 用例的参考模板

  • 以类似的方式用作各个场景的参考模板

  • 属性

    • 用于识别用例
    • 为管理目的
    • 用于记录对上下文的引用
    • 对于特定属性
    • 更多信息

    

• 记录场景的十一条规则

  • 1.用现在时态记录情景
  • 2.将主动语音用于文档场景
  • 3.使用主谓宾句型
  • 4.避免情态动词
  • 5.将每个互动与其他互动明确分开(每个动作至少使用一个独立的句子)
    • 用户向在线商店提交一个搜索查询请求，从搜索结果中选择一项，并将其加入购物车。
    • 改进定义：（规则6：为每个场景步骤加编号）
      • （1）用户向网上商店提交查询请求；
      • （2）系统显示搜索结果列表；
      • （3）用户从列表中选择一项商品；
      • （4）用户将商品加入购物车；
      • （5）用户重复步骤（1）~（4）直到结束购物
  • 6.给每个场景编号
  • 7.每个场景只有一个交互序列

  

  • 8.从外部视角描述场景

  

  • 9.明确地命名相关参与者

  

  • 10.明确记录场景所满足的目标

  

  • 11关注目标是如何实现的，避免不必要的信息

• 序列图

  • UML支持通过序列图记录交互

    • 一组角色之间的消息交换
    • 组合片段用于分组消息
    • 异常场景使用“break”和“alt”组合片段
    • 替代场景使用“alt”组合片段

  • 序列图的基本建模元素

    

  • 序列图中场景的文档

    

  • 序列图中的替代方案和异常方案

    

• 活动图

  • 活动图是控制流程图
  • 节点表示活动的执行
  • 备选控制流程通过决策节点表示
  • 活动图特别适用于记录主要、备选和异常场景的相互关系和执行条件
  • UML活动图的重要建模元素

  

  • 场景控制流的文档

  

• 用例图

  • 记录用例之间的关系

  • 用例图的建模元素

    • 参与者:表示系统边界之外的系统或个人
    • 用例
    • 系统边界:将系统与其环境分开
    • 参与者和用例之间的关系:表示该参与者在用例中与系统交互
    • 用例之间的关系:
      • generalisation, extend, include 泛化、拓展、包括
    • 参与者之间也有泛化

  • 用例图的重要建模元素

    

  • 示例：用例图的建模元素

  

  • 改进的驾驶员辅助系统用例图

  

Chapter 4 Requirements Analysis and Modelling

• 需求分析与建模基础
• 结构化分析与建模
• 面向对象分析与建模
• SERU框架中的需求分析与建模
• 其它需求建模
• 面向问题域分析

1 Fundamentals of Requirements Analysis and Modelling

• 需求分析

  • 充分了解所发现的需求

  • 发现缺陷并将其反馈给涉众，通过协商过程来解决它们

  • 创建一个解决方案

  • 方法:结构化分析(SA)，面向对象分析(OOA)，问题域分析(PDA)

  • 分析什么?

    • 不必要的需求?
    • 不完整的需求吗?
    • 不一致的需求?
    • 重叠需求?
    • 相互矛盾的要求?
    • 需求“优先级”
    • 需求“风险

  • 如何分析?

    • Problem Checklists分析清单检查表

      • 过早的设计
        • 需求是否包括过早的设计或实现信息?
      • 组合需求
        • 需求的描述是描述一个单独的需求还是可以分解成几个不同的需求?
      • 不必要的需求
        • 这个需求是对系统的修饰性的添加，实际上是不必要的吗?
      • 非标准硬件的使用
        • 该要求是否意味着必须使用非标准的硬件或软件?
      • 与业务目标的一致性
        • 需求是否与需求文档介绍中定义的业务目标一致?
      • 需求歧义
        • 需求可以由不同的人以不同的方式领导?需求的可能解释是什么?
      • 需求真实性
        • 给定将用于实现系统的技术，需求是现实的吗?
      • 需求的可测试性

    • Interaction Matrix分析需求交互矩阵

      • 需求沿着矩阵的行和列列出

        • 对于冲突的需求，填写1
        • 对于重叠的需求，填写1000
        • 对于独立的需求，填写0

        

    • SA 结构化分析

    • OOA 面向对象分析

• 需求建模

  • 需求分析结果记录方法
  • 方法:结构化，面向对象
  • 好处
    • 更好记忆
    • 抽象降低复杂性
    • 支持问题的理解和解决
  • 模型的视角
    • 功能角度
    • 数据透视图
    • 行为视角
  • 一般造型流程
    • 分解-抽象-消除 矛盾
  • 方法
    • 程序=数据结构+算法(数据、算法)
    • 结构分析和设计(数据格式、数据流程)
    • 面向对象的分析和设计(数据、演员、事件)
  • 工具
    • ERD(Entity-Relationship Diagram), DFD(Data Flow Diagram), DD
    • UML(活动图、用例图、类图、对象图、序列图、状态图)

• 需求协商

  • 冲突:如果不同的涉众(或一组涉众)关于系统的需求和愿望相互矛盾，或者如果一些需求和愿望不能被考虑在内。
  • 示例:
    • 一组利益相关者要求使用雷达传感器进行距离测量。另一组利益相关者则要求使用超声波传感器。
    • 利益相关者要求驾驶员的安全相关信息显示在平视显示器上。其他涉众认为这会降低驱动力，因此拒绝了这一要求。
  • 未解决的冲突可能会阻碍涉众接受系统，或者冲突甚至可能导致开发项目的失败。
  • 冲突可以作为新想法和创新需求发展的源泉。
  • 需求谈判的目标是通过识别冲突、分析冲突和解决识别的冲突来实现协议层面的进展。

2 Structured Analysis and Modelling

2.1 Idea

• 1970年代，Yourdon, Constantine和De Marco
• 结构化分析(SA)将系统视为过程的集合。流程可以分解为子流程。最终的子流程可以映射到一个函数中。所有的系统都可以由函数来构造。
• 这是一个用不同符号模拟数据流的过程。
  • 功能模型—数据流图
  • 数据模型—实体关系图
  • 行为模型—状态转换图

2.2 功能模型—数据流图 Functional Modelling–Data Flow Diagram

• 元素

  • 外部实体

  • 流程

  • 数据流

  • 数据存储

  

• 分级数据流图

• Context Diagram背景信息图

• 0级图

• 1级图

• DFD的绘图过程

  • 绘制上下文图

  

  • 根据业务事件绘制每个事件的DFD片段

  

  • 合并片段

  

  • 分步细化功能

2.3 数据模型—实体关系图 Data Modelling—Entity-Relationship Diagram(ERD)

• 实体

• 关系

• 属性（实体/关系的属性)

• 基数约束

• 不同关系类型的泛化/规范

  • Disjoint vs. overlapping 不相交vs重叠

  • Total vs. partial全部vs部分

  

  

2.4 行为模型—状态转换图 Behavioral Modelling—Statechart

• 行为模型用于记录系统的反应行为。

• 状态图是一种常用的基于有限自动机的行为建模语言

• 有限自动机是一个五元组
  $$(Q,\sum ,\delta ,q0,F)$$
  

• DFA & NFA

  • DFA确定有限状态自动机

    

  • NFA非确定有限自动机

  

• Mealy和Moore自动机

  • 有限状态传感器（FST）通过输出字母 和一个输出函数增强FA
  • Mealy自动机：自动机的输出取决于当前状态和输入符号
  • 摩尔自动机：自动机的输出仅取决于当前状态

  

  

• 状态图

  • 状态图通过以下功能增强有限自动机：
    • 定义状态和转换的操作
    • 定义条件事务
    • 状态的层次细化
    • 并发行为建模

  

  • 行动

  

  • 条件

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nR4rBhoA-1643256503700)(C:\Users\dell\AppData\Roaming\Typora\typora-user-images\image-20211220192848598.png)]

  • Sub-state

  

  • Default state

    

  • ◼ 同时发生的◼ ti：事件

    

• DD 数据字典

  • DD是对数据元素、数据流、数据流程、数据存储的详细定义。

    • 数据元素:名称、别名、类型、长度、来源、…
    • 数据流:名称、别名、来源、sink、别名、描述、数量、频率、…
    • 数据过程:名称、别名、输入、输出、级别、目的、用途、描述、…
    • 数据存储:输入/输出数据流、数量、频率、描述、…

  • DD示例

    

2.5 Integration of the Three Perspectives 三个视角的整合

• 导航系统示例

  • 示例:导航系统要求
    • 位置方向计算:
      • R1系统根据GPS数据、车轮转动、偏航速率确定车辆当前的位置和方向。
    • Entry of destination: 目的地条目:
      • R2系统应允许输入一个地址来指定行程的目的
      • R3系统应允许从存储目的地列表中选择目的地。
    • 路线计算:
      • R4系统计算从车辆当前位置到所选目的地的最快路线。
      • R5如果司机偏离了计算的路径，系统需要重新计算到达目的地的路径。
    • 至目的地导航:
      • R6在行车过程中，系统应提供声、视行车方向。

• 数据视角

  • 实体关系图

    

• 功能视角

  • 数据流图

    

    ​

• 行为视角

  • 状态图

    

• 三个视角之间的关系示例

  \

3 Object Oriented Analysis and modelling

3.1Idea创意

• 面向对象分析将系统视为一组对象，这些对象通过相互协作来完成所需系统的任务
• 面向对象建模根据对象及其提供的服务对系统需求进行建模
  • 领域建模-类图
  • 功能建模-用例图
  • 动态建模-序列图、状态图

3.2 Domain modelling 领域建模

• 类:

  • 集合的相似对象
  • 一个表是一个对象，表是一个类
  • 类的意思是“类型”

  

• 属性:

  • 用来说明类的特征

    

  • 关联(类之间的关系):

    • 角色名，多重性，属性字符串

      

      

  • 聚合和组合:整体-部分关系

  • 组合:强整体-部分关系(部分只有一个所有者，不能独立存在)

    

  • 泛化关系(将子类与超类相关联)子类的

    • 实例是超类的实例

    • 子类必须可替代其超类

    • 子类定义了附加属性和操作

      

  • 辅助元素

    • 导航箭头

    • 派生属性

    • 限定词

    • 约束

      

3.3Functional Model功能模型–用例图+用例规范

• 用例图

  • 参与者:系统之外的任何人或系统，并与系统交互

  • 用例:在系统中执行的一系列动作，这些动作将为特定的执行者生成可见且有价值的结果。

  • 关系:

    • 参与者之间的:用例之间的一般化
    • 用例之间:Include, extend, generalization包含、扩展、概括
    • 参与者和用例之间:关联

  • 用例图示例

    

3.4Dynamic modelling动态建模—序列图+状态图

4 Requirements Analysis and Modeling in SERU(Subject area Event Report Use case) Framework

4.1Cycle 1: Clarify the framework and branches周期1:明确框架和分支机构

• 任务：理清需求的结构框架(领域类图)和行为脉络(流程图和用例图)

• 输入：需求定义阶段产生的业务事件列表和报表列表

• 输出：领域模型和用例模型

• 过程：

  • 业务流程分析
  • 业务实体分析
  • 角色与使用场景分析

  

• 4.1.1Business flow analysis业务流程分析

  • 业务流程分析的要点与产物

    • 输入条件：业务事件列表
    • 信息来源：负责业务事件的中层管理人员
    • 描述要素：
      • 针对清单上的每一流程，分析并识别现有业务活动、活动之间的关系、活动需要接受哪些信息、产生哪些数据、数据传送的路线、活动涉及哪些岗位等。
      • 重要抓住核心业务和主要活动点，部门内/外衔接、工作繁琐/反复环节、成本高/效率低/时间长的环节、任务转手次数多的环节
    • 产物：跨职能流程图、带泳道的活动图、DFD

  • 跨职责流程图应用基础与要点

    

    

  • 活动图应用基础与要点

    • 活动图基础见Chapter 3

      

  • 数据流图应用基础与要点(see 2.2)

• 4.1.2Business entities analysis业务实体分析

• 领域建模/概念建模

• 分析过程：

  • 自底向上
  • 针对每一事件、每一类报表创建局部的领域类图片段
    • 业务实体、实体之间的关系、实体的关键属性
  • 片段建模完成后，再抽象、提炼形成全局的领域模型

• 产物：

  • 类图(see 3.2)
  • ER图(see 2.3)

• 4.1.3Roles and Use Case Analysis角色和用例分析(参见3.3、3.4)

4.2Cycle 2: Supplement requirements details周期2:补充要求详情

• 细化领域类的数据窗口、字段、格式、派生数据的计算方法等

  • 数据字典
  • 决策树、决策表

• 细化用例

  • 书写用例规格说明
  • 用例中的事件流分析
    • 前后置条件
    • 事件流的类型：基本事件流、扩展事件流、子事件流
    • 业务用例与系统用例

• 决策图表

  

• 决策表

  

5 modelling for Other Requirements

5.1接口要求

• 有分解的地方就有接口

• 说明要点：

• 用户：名称、业务目标、使用时间、使用频率

• 内容和格式：交互过程描述、数据包描述

• 设计约束：

• 数据包必须是TCP格式，数据交换必须由库交换实现

• “接口调用必须在3秒内应答”

• “用户可以通过Internet访问该界面”

5.2全局设计约束

• 设计约束是对设计的限制，通常来自非功能需求。

  • 开发者无法控制的强加的限制

  • 开发者自己强加的，作为改进设计的一种方式。

    • 用户界面和人为因素考虑

    • 硬件方面的考虑

      • 建议的系统将在什么硬件上使用?

      • 目标硬件的特点是什么，包括内存大小和辅助存储空间?

        

    • 错误处理和极端条件下

    • 系统接口

    • 质量问题

    • 系统开发和修改

    • 物理环境

    • 资源和管理问题

5.3全局非功能性要求

• 定量方法
  • 寻找质量属性的可度量尺度
  • 计算设计满足质量目标的程度
• 定性方法
  • 研究质量目标之间的各种关系
  • 权衡的原因等
• 性能度量
  • 指标:响应时间、某个时间间隔内处理/拒绝的事件数、吞吐量、容量、利用率、信息丢失、延迟、计算精度
  • 示例:
    • 系统应能够处理每秒100付款交易在峰值负载
    • 在标准工作负载,CPU使用率应小于50%,50%为背景工作
    • 生产一个简单的报告应当采取不到20秒的95%情况下
    • 精密的计算应当至少10-6
• 可靠性测量
  • 指标:平均故障时间(MTF)，不良率
  • 举例:
    • 系统不良率应小于1故障每1000小时运行
    • 不超过1个故障每1000000个事务应导致需要系统重启
• 可用性度量
  • 指标:
    • MTBF/(MTBF+MTTR)MTBF:故障间隔时间
    • MTTR:故障后恢复运行所需的时间
    • 示例:
      • 系统应达到或超过99.99%的正常运行时间
      • 系统每运行1000小时不应超过1小时不可用
      • 系统故障后95%的时间需要在20秒内重新启动
• 安全措施
  • 两个措施:
    • 抵抗未经授权的使用企图的能力
    • 在拒绝服务攻击下继续为合法用户提供服务(抵抗DoS攻击)
  • 指标:
    • 验证成功率
    • 抵抗已知的攻击(枚举)
    • 找到key所需要的概率/时间/努力/资源
    • 检测攻击的概率/时间/资源
    • 在攻击期间仍然可用的有用服务百分比
    • 成功攻击的百分比
    • 密码的寿命，会话的寿命
    • 加密级别
  • 示例
    • 应用程序应确定所有的客户端应用程序之前,允许他们使用其功能
    • 应用程序应确保员工的名字在官方人力资源和工资数据库完全匹配的名字印在员工的社会保障卡
    • 至少99%的入侵10秒内检测到
• 可用性测量
  • 指标：使用率、每类用户满意度
  • 示例:
    • 在对系统进行2小时的介绍后，五分之四的用户将能够在5分钟内预订到客人
    • 在3个月的使用周期后，至少80%的客户对该系统的满意度为7分以上(从1到10分)
• 稳健性测量
  • 指标：无效输入的故障百分比、极端负载下的最低性能、服务降级程度
  • 示例：
    • 磁盘崩溃时的估计数据损失应小于0.01%
    • 在满足用户所有要求的情况下，系统应能处理多达10000个并发用户，并能处理多达25000个具有浏览功能的并发用户
• 可维护性测量
  • 指标：耦合/内聚度量、圈复杂度、修复缺陷的平均时间、添加新功能的平均时间
  • 示例：
  • 代码的圈复杂度不得超过7
  • 任何对象中的任何方法都不能超过200行代码
  • 新版本的安装应保持所有数据库内容和所有个人设置不变

6 Problem Domain Oriented Analysis

• 一种较新的技术，强调描述，较少强调建模

• 组成：

  • 关于问题域：用一个文档罗列出问题区域以及问题区域下的所有问题，针对问题进行详细描述；文档在需求定义时产生
  • 关于解系统：用一个文档罗列出系统实现相关要求的技术点、难
    点问题；文档在需求分析时产生

• 分析步骤：

  • 收集基本问题并整理问题域类型(问题框架)
  • 针对问题域进一步进行信息收集，对问题域给出一个更加详细的特征描述
  • 用文档描述对新系统的需求

• 核心：问题域

• 问题域的类型

  • 系统软件/应用软件

  • 批处理系统（脱机系统）/交互系统/实时系统

  • 数据为主系统/交互为主系统/算法为主系统

    

• Jackson问题域分类

  Jackson基于不同问题子域的本质及存在于问题子域间的关系，将问题域分为：

  • 工件系统(workpiece system)----系统必须执行针对仅存在于解系统之内的对象的直接操作。例如文字处理程序。
  • 控制系统(control system)----系统将控制问题域的部分行为。例如电梯控制系统。
  • 信息系统(information system)----系统必将处理有关问题域的信息请求。例如学生档案系统。
  • 转换系统(transformation system)----系统必须把某种特定格式的输入数据转换为相应特定格式的输出数据。例如把交易清单汇编成银行结算报表的程序。
  • 连接系统(connection system)----系统必须在未直接相连的子域之间维持通信。例如视频会议系统。

• 域的特征

  

  

• 工件框架：系统必须完成针对只存在于系统中的对象的直接操作

  • 绘图工具

  • CASE工具

  • Word，Excel

  • 网站开发工具

    

  • 例如：有限自动机工具

    • 上下文图

      

    • 问题框架

      

      

• 控制框架：系统控制部分问题域的行为，包括待求行为框架（待求行为完全由规则预先确定）和受控行为框架（行为的控制取决于操作员发出的命令）

  • 电梯控制系统 现代汽车工业的引擎管理系统温室环境控制系统

    

    

• 信息框架：

  • 系统将提供有关问题域的信息，包括信息是自动提供的（通常是持续的）和信息只在响应具体的请求时提供

  

  • 系统将提供有关问题域的信息，包括信息是自动提供的和信息只在响应具体的请求时提供

    • 学生档案管理系统

    • 财务管理系统

    • 航空交通控制系统

      

      

• 转换框架：系统必须将某种特定格式的输入书转换成相应的、另一种特定格式的输出

  • 文件格式转换

  • 根据人体扫描数据自动生成图片这类应用

    

    

• 连接框架：系统必须维持那些相互没有直接连接的子域间的通信

  

  

  

• 各种问题域的特征

  

Chapter 5 Requirements Specification

1需求规范基础

• 域属性：

  • 无论我们是否构建了提议的系统，应用领域中的事情都是真实的

• 要求：

  • 在应用领域中，我们希望通过交付建议的系统来实现的事情

• 规格：

  • 是对程序必须具备的行为的描述，以满足要求

1.1动机和目标

• 文档的重要性
  • 坚持不懈
  • 共同参考
  • 促进交流
  • 支持培训新员工
  • 促进客观性
  • 保留专家知识
  • 有助于反思问题
• 需要记录的信息
  • 就要求达成协议
  • 冲突的替代解决办法
  • 头脑风暴结果
  • 更改请求
  • 决策依据
  • 关于变更请求的决定
  • 关于冲突的决定
  • 与文件规则/指南的偏差
  • 不同的利益相关者观点
  • 人工制品的演变
  • 确定的矛盾
  • 识别错误
  • 关于上下文的信息
  • 检查结果
  • 访谈结果
  • 优先事项
  • 活动负责人
  • …

1.2Documentation vs. Specification 文档与规范

• 根据文件编制的不同目的，不同RE活动产生的信息采用不同的表示格式、不同的详细程度、不同的指南和文件编制规则进行记录。

• 需求说明是一种特定的文档。只有当要求文件符合为项目定义的specification rules and guidelines规范规则和指南时，指定要求才是指定要求

  

• Software Requirements Specification(SRS)

  • 是具有一定法律效力的合同文档
  • 清楚地描述软件在什么情况下，需要做什么，以及不能做什么
  • 以输入/输出、输入到输出之间的转换方式来描述功能性需求
  • 描述经过干系人磋商达成共识的非功能性需求
  • 一般参考需求定义模板，覆盖标准模板中定义的所有条目
  • 作为后续的软件评估依据和变更的基准

1.3需求人工制品的质量标准

• 完整：无遗漏信息
• 可追溯：来源、演变、影响和使用
• 正确：由利益相关者确认
• 明确：单一有效解释
• 易于理解：相关利益相关者易于理解
• 一致：没有矛盾
• 可验证：明确客观的验收标准
• 评级：已知相关性和稳定性
• 最新：反映系统的当前状态及其上下文
• 原子：单一相干事实
• eg
  • 模棱两可的需求，驾驶员需要输入一张电子卡和一个PIN码。如果无效，引擎不会启动。
    • 歧义:“如果无效”是指卡，密码，还是两者都有?
  • 未详细说明的需求的可验证性:
    • 可验证的:R1:系统必须在至少80%的情况下在2秒内响应ES-2事件，并且在所有情况下，当系统负载在约束C14(系统负载概要)规定的最大负载的80%到90%之间时，最迟在3秒内响应
    • 不可验证:R2:系统正常响应时间小于2s。:“正常响应时间”指的是什么?什么样的回应?哪个系统负载和在什么条件下响应时间可能高于2秒?
  • 非原子需求用户必须登录到系统，以便能够根据订单ID或通过客户数据库中的全文搜索特定的订单。
    • 非原子性:该需求不是原子性的，因为它描述了用户身份验证以及搜索订单的不同方式

1.4一套需求人工制品的质量标准

• 一组需求工件的质量取决于单个需求工件的质量以及为该组需求工件定义的质量标准的满足情况
• 完整性:没有遗漏的需求，所有的需求都被完整地记录下来
• 一致性:
  • 没有不一致的描述/术语
  • 没有不一致的真实世界方面的属性
  • 没有不一致的行为规范(逻辑或时间冲突)
• 可修改性和可读性:
  • 文档风格和结构
• 存在问题的需求描述实例
  • 含糊的需求描述:
    • “工资总额由上一条记录获得”。“所有客户都具有同一控制域”·
  • 错误的需求描述:
    • ·“所有系统将九月作为财政年度的起始时间”·
  • 不完整的需求描述:
    • .“出错信息显示在屏幕的第24行”·
  • 矛盾或不一致的需求描述:
    • “C=A+B”;“C=A-B”·
  • 无法测试的需求:
    • “系统应具有友好的界面”

1.5规定要求的不同方式

2 Informal Specification非正式规范

• 文档需求使用自然语言，如英语、汉语、法语、德语或类似语言

• 文档需求，使用参考模板

• 非正式规范

  • 自然语言
  • 文本描述
  • 需要写作技能
  • 应该组织得很好

• 优势

  • 普遍的、灵活的、可理解的

• 缺点

  • 功能需求的三个视角（数据、功能和行为）通常是混合的
  • 功能和质量属性经常混合在一起
  • 模棱两可的
  • 术语的模糊性：定义模糊，同一件事在说明书中可能以多种不同的方式表述
  • 缺乏模块化：

• eg.

  • 示例1：自然语言中的功能需求
    • R2：如果窗户处的玻璃破裂检测器检测到窗格玻璃已损坏，系统应通知安全服务部门
    • 结构：玻璃破裂探测器、窗户、窗格、系统、安全服务
    • 功能：检测、通知安全服务
    • 行为：如果[…]损坏，然后通知[…]
  • 示例2:功能与质量相结合
    • R2.1如果窗口玻璃破碎探测器检测到玻璃已经损坏，系统最迟应在2秒内通知安全服务。
    • 功能与质量要求分离后
      • R-F-17:窗口玻璃破碎探测器检测玻璃是否损坏
      • R-F-18:如果检测到玻璃损坏(见R-F-17)，系统通知保安服务
      • R-Q-2:系统检测到损坏后，应在2秒内通知保安服务(见R-F-18)

• 歧义

  • 词法歧义

  • 语法歧义

    • 用户用门禁卡输入门禁码
    • interpreation1:输入门禁码和门禁卡
    • interpreation2:进入访问代码使用访问卡

  • 语义歧义

    • 如果(1)一个窗口的车受损,(2)汽车的内部监测检测instruder或(3)打开汽车的门没有车钥匙,安全系统应发出警报
    • Interpretation1:（(1)和(2)）或(3)
    • Interpretation2:(1)和((2)或(3))

  • 参考模糊

    • 客户将门禁卡插入读卡器，在键盘上输入个人识别码(PIN)。如果是无效的，系统将拒绝访问。

  • 术语模糊

    • 所有中型车辆应配备导航系统

  • 避免歧义的技巧1

    • 词汇表

      • 词汇歧义是由同音词（具有不同含义的单词）和/或同义词（具有相同含义的不同单词）引起的。
      • 通过在术语表中明确定义规范中使用的不同术语的含义，可以减少甚至完全避免这种歧义。

    • 词汇表的结构

      

  • 避免歧义的技巧2

    • 句法需求模式

    

    • R14：如果玻璃破裂探测器检测到窗户损坏，系统应通知安保服务总部

  • 避免歧义的技巧3

  • 受控语言

    • 受控语言为特定域定义了一个受限自然语言语法和一组术语（包括术语的语义），这些术语将在受限语法中使用，以记录关于该域的语句。

    • 可以看作是语法需求模式的扩展。

      

      

• Guidelines for specifying

  • 记录是艺术
    • 没有简单固定的规则
      • 每一份文件都可能有很大的影响
        • 句子结构，词语的选择，图片的选择……
      • 各种细节都必须处理好
    • 多练习，指定更好的
      • 在练习中，你会学到:
        • 如何组织SRS如何处理常见情况如何避免常见错误阅读是有帮助的没有人能在阅读大量之前获得完美的艺术品
    • 阅读是有帮助的
      • 没有人能在阅读大量作品之前得到一件完美的艺术品
  • 为人们写作
    • 可理解性和易于沟通是首选
      • 以可理解的方式表达
        • 在标准和全面之间的权衡
      • 组织内容和指导用户
        • 根据用例图或上下文图组织系统功能和要求
      • 不要把无关紧要的事情放在
    • 与SRS用户一起工作
      • 作为用户，你会知道真正重要的事情
  • 没有固定的规则
    • 机械地遵守任何指导方针
      • 使用主动句
      • 使用标准格式所有要求
      • 使用语言一致。
      • 用“应该”表示强制性要求
        • 用“应该”表示合意性要求*
      • 避免使用计算机行话
      • …
    • 在清晰、简洁和指导方针之间进行权衡
  • 人更喜欢列表
    • 系统模式
    • 列表，网格，图形，数字
    • 表格根据内容
      • 不指定在一些统一的盲目
    • 所有细节在他们的地方
      • 文件应该组织良好，没有复制细节
    • 强化
      • 引用或链接，而不是复制和粘贴
      • 有些复制是必要的，例如强化

• 结构化的语言规范

  • 需求编写者的自由受到预定义的需求模板的限制。
  • 所有的需求都是以标准的方式编写的。
  • 描述中使用的术语可能是有限的。
  • 这样做的好处是，虽然保留了自然语言的大部分表达性，但规范中却有一定程度的一致性。

• Form-based specifications 基于表单的规范

  • 功能或实体的定义。
  • 输入的描述及其来源。
  • 输出的描述和输出到哪里。
  • 所需的其他实体的说明。
  • 前期和后期条件(如果合适)。
  • 函数的副作用(如果有的话)。

  

3 Semi-formal Specification---- Graphical models 半正式----------图形模型

• 文档需求，使用图表，如DFD、ERD、类图、序列图等。

• 当您需要显示状态如何变化或需要在何处描述一系列操作时，图形模型最为有用。

• UML：统一建模语言（UML）是一种用于指定、可视化、构造和记录软件系统工件的语言。

• UML2中的十三种图表类型。

  • 用例图

  • 类图

  • 行为图

  • 状态图

  • 活动图

  • 交互图

    • 序列图
    • 协作图

  • 实现图

  • 组件图

  • 部署图

  • 对象图

  • 时序图

  • 复合结构

  • 包装图

  • 交互概述图

    部署图方法=建模语言+方法/流程

• RE related diagrams

  

  

  

  

  

  

4 正式规范 Formal Specification

• 文档需求，使用基于数学的语言，如Z、vdm、表格表达式等。

4.1形式规范基础

• 形式规范的目标

  • 完整、一致、简洁、明确的规范
  • 有效的规范-明确用户的需求基于形式化语义模型的规范
  • 形式化语义允许各方进行可靠的沟通
  • 允许形式化验证
  • 案例研究具有多种优势

• 使用正式规范

  • 正式规范涉及在软件开发的早期阶段投入更多的精力
    • 这减少了需求错误，因为它迫使对需求进行详细的分析
  • 可以发现和解决不完全性和不一致性!!
    • 因此，由于需求问题而进行的返工的数量减少了

• 形式规范基础

  

• 正式的方法

  • 正式规范是一个更一般的一部分的技术集合被称为‘正式的方法’

  • 这些方法都是基于数学表示和分析软件

  • 正式方法包括

    • 正式规范
    • 规范分析和证明
    • 转型发展
    • 程序验证

  • 接受正式的方法

    • 正式的方法没有成为主流的软件开发技术，正如曾经预测的那样
      • 其他软件工程技术已经成功地提高了系统质量。因此，对正式方法的需求已经减少;
      • 市场的变化使上市时间而不是低错误的软件计数成为关键因素。正式方法不会缩短上市时间
      • 正式方法的范围是有限的。它们不太适合指定和分析用户界面和用户交互
      • 形式化的方法很难扩展到大型系统

  • 形式化方法的使用

    • 形式化方法的实际适用性有限
    • 它们的主要好处是减少系统中的错误数量，因此它们的主要适用性领域是关键系统
      • 在这一领域中，使用形式化方法最有可能是具有成本效益的

  • 形式化规范工具概述

    

  • 形式化规格说明语言的组成

    • 语法
      • 定义特定表示法用于表达需求规格说明
      • 一般以标准集合论和谓词演算等数学表示法为基础
    • 语义
      • 定义将用于描述系统的元素和/或对象
      • 语义指明如何用这个语言来表示系统需求
    • 关系
      • 定义一组规则
      • 指明哪个对象恰好满足什么样的系统规格说明

  • 形式化规格说明语言的分类

    • 基于模型的表示法
    • 以进程代数为基础
    • 基于代数的方法

    

  • 形式化规格说明的优势与不足

    • 优势
      • 以数学理论为基础，能够对规格说明的正确性、完整
        性和一致性进行形式化检查，还能够排除规格说明中
        的二义性
    • 不足
      • 有一些需求是很主观的，很难用形式化方法建模
      • 形式化方法虽然提升了系统需求的可信度，但并没有解决需求如何获得以及需求模型如何构造等问题
      • 虽然已有一些形式化建模工具，但应用面还不是很广泛，主要应用在嵌入式等安全攸关领域
      • 使用代价高

4.2 Z规范

• 理论基础：基于集合论和一阶谓词逻辑

• 使用称为”模式(schema)”的图形结构进行形式说明

• Z形式说明由一组”模式”构成

• 状态模式

  • 每个系统只有一个状态
  • 说明：若干个状态变量
  • 谓词：定义在状态变量上的约束

• 操作模式

  • 每个系统可有若干个定义在状态上的操作
  • 说明：是否改变了状态？有哪些输入变量？有哪些输出变量？
  • 谓词：输出变量的定义

  

• Z说明例1—停车场管理系统

  • 全局量的声明：

    • 给定的集合：[ ]
    • 数据类型定义：
      停车提示 =停好 |停车场满
    • 常量声明：
      • C停车场容量：Z /Z:整数集合/
      • C停车场容量>=0： /常量约束/
    • 全局变量声明：无

  • 状态模式定义：

    

• Z说明例1—停车场管理系统

  • 状态变量初始化：
    SV停车数量= 0

  • 操作模式定义

    

• Z说明例2—电梯控制系统

  • 全局量的声明：

    • 给定的集合：[Button]
    • 数据类型定义：
    • 常量声明：
    • 全局变量声明：

  • 状态模式定义：

    

• Z说明例2—电梯控制系统

  • 状态变量初始化：
    

  • 操作模式定义

    

• 4.3四变量模型

  

  • 四变量
    • 输入变量
    • 输出变量
    • 监视变量
    • 控制变量
  • 整个**系统(硬件&软件)**是监视变量和控制变量之间的关系(REQ和NAT)
  • 输入设备是监视变量和输入变量之间的关系IN
  • 输出设备是输出变量和控制变量之间的关系OUT
  • 软件系统是输入变量和输出变量之间的关系SOF
  • REQ和NAT对应的是系统需求文档的主要内容
  • IN和OUT合起来是系统设计文档的主要内容
  • 输入变量和输出变量之间的关系对应的就是软件需求文档的主要内容

• 4.4表格式(Parnas表)

  • Parnas Tables使用表格结构来组织数学表达式，其中

    • 行和列将表达式分隔成case
    • 每个表项指定某个case的结果值或部分标识某个case的条件

  • 有十多种表类型。

  • 一个表达式通常可以用几种表类型表示。文档编写者的目标是选择(或创建)一种表格式，为该表达式生成一个简单、紧凑的表示。

  • 什么是Tabular Expression? 列表表达式?

    • 不同的名称:

      • 表格表达式或表或Parnas表

      • 本质上:

        • 表示一个数学表达式的表格形式;

      • 内容:

        • 定义一个关系或函数;

      • 应用:

        • 可用于记录软件系统简明;

      • 优点:

        • 可读的;简洁的;明确的;方便检查

      • 例子

        

      • 规范和描述

        

      • TE的发展

        • 首次介绍:
          • 1977年，美国NRL赞助的项目，David Parnas引入了表来指定A-7E要求;
        • 广泛使用:
          • 许多项目使用表格作为软件系统文档化的正式方式;
          • 1个成功案例:达灵顿核电站
          • SCR法——3个表类型用于指定需求
          • 特别是实时系统;
        • 形式定义
          • 直观=>10形式定义表型=>其他形式模型=>新的数学模式

      • Summary of TE

        • Tabular expressions (table/Parnas table)是一种实用的形式化定义方式;

        • 提供了如何采用表格化结构来组织（定义关系或函数的）数学表达式的方式;

        • Tabular expressions遵循“分而治之（divide and conquer）”的原则，对复杂的数学表达式进行分解和简化，在保持了定义的严格性同时，还提高了可读性;

        • Tabular expressions不仅可以定义需求文档，还可以用来定义软件开发中其他技术文档。

        • Tabular expressions具备了如下特点：

          • 基于良好的数学模型；
          • 支持“分离关注点”和对问题抽象化；
          • 可以对数学关系给出图表化结构；
          • 支持对文档进行完整性和一致性分析检查；

        • Tabular expressions为文档驱动软件开发方法提供了很好的支持。

        • 10表列表达式类型

          • 一些概念

            • Scalar Expression(标量表达式):
            • 由各种运算、函数调用、以及谓词表达式构成的表达式；
            • 
            • 网格（grid）：索引化集合G
              • 索引集合：{1,…,m1} ×……× {1,…,mn}
              • 维数：dim(G)=n
              • 长度：leni (G) = mi
              • 形状：shape(G) = (m1 ,… , mn)
              • 元素（cell）：是一个表达式，Gi表示索引为i对应的表达式；
            • 表格（table）T
              • 构成：一个主网格(main grid)G和n个标题网格(header grid) {H1,……, Hn},满足：n=dim(G), shape(Hi)= leni (G);
              • 维数： dim(T)= dim(G)
              • 形状： shape(T) = shape(G)
              • 索引集合： indexset(T) = indexset(G)
              • 一些记号：Ti,m指的是Hm中索引（i|m）的表达式
            • 表达式
              • Scalar表达式
              • Tabular表达式

          • Examples of TenTable Types

            • Normal Function Table

              

            • Inverted Function Tables

              

            • Vector Function Table

              

            • Normal Relation Table

              

            • Inverted Relation Table

              

            • Vector Relation Table

              

            • Mixed Vector Table

              

            • Predicate Expression Table

              

            • Characteristic Predicate Table

              

            • Generalized Decision Table

              

              

              

              

              

5 SRS Standards Templates

• International Standard

• IEEE Std 830-1998

• 组织

• 附样本说明

  • Atlee, Berry, Day, Godfrey

  • U Waterloo

  • CS445 (Winter 2011)

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

• National Standard

• 国家标准

  • GBT 9385-2008计算机软件需求规格说明书规范

  

  

  

  

  

• 军队标准

Chapter 6 Requirements Verification

• Fundamentals of Requirements Verification需求验证基础
• Requirements Verification Techniques需求验证技术
• Problem Revision问题修正

1 Fundamentals of Requirements Verification

1.1动机和目标

• 动机

  • 为实现质量保证目标
  • 避免错误传播
  • 避免因需求缺陷引起的法律问题

• 质量保证(QA)

  • 建设性的:在创建这些开发构件时，使用一些技术来防止构件中的缺陷。
  • 分析性的:使用一些技术来检查创建后的开发工件的质量

• 目标

  • 检查活动的输出是否符合规定的质量标准
  • 检查活动的输入是否符合规定的质量标准
  • 检查活动的执行是否符合过程定义和活动指南

• 验证不足成本

  

1.2Verification验证和 Validation确认(V&V)

• Validation 和 Verification的定义
  • 都是分析性质量保证手段
  • 需求确认(Validation)：
    • 我是否建立了正确的系统？
    • 适当、不恰当
  • 需求验证(Verification)：
    • 我是否正确建立系统？
    • 正确、错误

1.3需求工程中的V&V

• Validation
• RE中的验证表示检查需求工程核心活动的输入（上下文）、执行的活动和创建的输出（需求人工制品）是否满足定义的质量标准。
• 三个次级活动：
• Validating 确认对上下文的考虑
  • 上下文考虑中的错误会导致需求中的错误
    • 不完整的需求源
    • 缺少、不正确、不充分的上下文信息
  • 从四个方面进行验证
    • 主体、使用、IT系统、开发
• Validating 验证活动的执行
  • 检查是否已执行每项要求的需求工程活动
  • 检查每项活动是否已正确执行
• Validating验证创建的需求人工制品
• 关于内容维度的验证 content
  • 检查所有相关要求是否已知并理解到所需的详细程度
• 关于文档维度的验证 documentation
• 检查是否根据定义的文件和规范规则记录了要求
• 关于协议维度的验证 agreement
• 检查利益相关者是否就文件化要求达成一致
• 检查每个已知冲突是否已解决
• 检查是否存在尚未识别的冲突

1.4 V&V过程

2 Requirements Verification Techniques 需求验证技术

2.1 Inspections需求评审

• 书面材料的质量改进过程
• 检查什么？
  • 软件需求规范
    • Comprehensibility, Reduncy, Completeness, Ambiguity,Consistency, Organization, Standard Compliant, Traceability
    • 可理解性、冗余性、完整性、模糊性、一致性、组织性、符合标准、可追溯性
  • 如何检查？
    • Ad hoc没有预先规划的软件测试方法
    • 基于检查
    • 基于缺陷的
    • 基于功能点的
    • 基于透视图
    • 基于场景的
  • 非正式检查和正式检查
    • 正式检查程序
      • （1） 参与者
        • 开发人员、预开发人员、编写人员、测试人员、项目经理
      • （2） 角色
      • （3） 过程
        • 计划
        • 概览会议
        • 准备
        • 检查会议
        • 返工
        • 后续处理
      • Criteria for Entrance and Exit Inspection
        • Entrance:
          • 文档符合标准模板；文档已经做过拼写检查和语法检查；作者已
            经检查了文档在版面安排上所存在的错误，已经获得审查员所需
            要的先前或参考文档；在文档中打印了行序号以方便在审查中对
            特定位置的查阅，所有未解决的问题都被标记为TBD，包括文档
            中使用到的术语词汇表。
        • Exit:
        • 已明确阐述审查员提出的所有问题；已正确修改文档；修订过的
          文档已进行了拼写检查和语法检查，所有TBD问题已全部解决，
          或者已经记录下每个待确定问题的解决过程、目标、日期和提出
          问题的人；文档已登记入项目的配置管理系统，已将审查过的资
          料送到有关收集处。
  • 好处:
    • 工件的详细检查
    • 检查达成的理解
  • 努力:需要中等到高度的努力
  • 关键成功因素
    • 过程和组织:严格定义
    • 工件:尺寸、复杂性、质量
    • 检查团队成员的选择:数量、覆盖范围、经验

2.2Prototyping and Simulation 原型和模拟

• 好处:
  • 原型开发期间的缺陷检测
  • 证明了可行性
• 努力:
  • 原型可以自动生成:低或很低
  • 开发期间的工具支持:中或低
  • 手动开发的原型:很高或很高
• 关键成功因素:
  • 努力
  • 文件质量
  • 原型的细节级别

2.3Functional Test Design 功能测试设计（开发测试用例）

• 软件测试:

  • 软件测试是指以检测故障为目标的软件单元的系统执行。

  • 关注锻炼和观察产品行为或质量属性

    

• 测试用例

  • 一个测试用例包括测试执行所需的先决条件，输入和预期输出的集合，测试指令(如何从测试对象读取输入)以及预期的后置条件。

• 当观察到的输出与指定的输出相对应，且后置条件为真时，就认为测试通过。如果不是这样，则认为测试失败。

• 失败表示预期输出(在测试用例定义期间定义)与测试执行期间观察到的输出之间的偏差

• 测试用例定义

  • 基于代码的测试(白盒测试)
  • 基于规范测试(黑盒测试)

• 优点/缺点

  • 适用性测试级别:
    • 基于代码的测试适合组件测试和集成测试在某种程度上
    • 基于规范测试适用于所有测试水平。
  • 测试期间测试对象的覆盖范围:
    • 使用基于代码的测试可以检测整个源代码中的错误
    • 基于规范的测试可以发现需求的缺失实现。

• 好处:

  • 非常适合对功能要求和具体质量要求进行可验证性检查
  • 对可理解性、无歧义性和完整性进行检查
  • 对测试用例的进一步使用

• 努力:中等

• 关键成功因素:

  • 测试用例开发人员的知识和经验
  • 高质量的工件

2.4Users Manual Development 用户手册开发

• • 1.开始
  • 2.用户界面
  • 3.使用场景.
    • 3.1场景1
    • 3.2场景2
    • 3.3…
  • 4.功能
    • 4.1功能1
    • 4.2功能2
    • 4.3…
  • 5.故障处理
    • 5.1问题1
    • …
  • 6.术语表
  • 7索引
• 好处:
  • 检测的缺陷在手工编写
  • 进一步使用手动的方式
• 努力:高
• 关键成功因素:
  • 完整和稳定的涉众需求
  • 涉众的支持
  • 可读性和可理解性

2.5Requirements Traceability 需求可追溯性（利用跟踪关系）

• 验证完整性:自上而下

• 验证不必要需求:自下而上

  

2.6Automation Tools自动化工具

• 正确性已证明

  • 程序满足需求规
  • 需求规范满足域属性

• 完整性已证明

  • 所有必要条件已发现
  • 所有必要的域属性已发现

  

3 Revise the Problems

• 需求澄清
  • 误解：重新分析
  • 遗漏：重新分析并记录此部分
  • 表达不正确：重新记录或重新指定
• 不完整的要求
  • 重新激发和其他连续活动
• 相互冲突或不一致的要求
  • 谈判
• 不切实际的期望
  • 项目调整与谈判

Chapter 7 Requirements Management

• 1需求管理基础
• 2需求可追溯性
• 3确定需求的优先级
• 4需求变更管理
• 5需求管理工具

1 Fundamentals of Requirements Management

• 软件需求管理是一种发现、记录、组织和跟踪需求变化的系统方法。它可用于获取、组织和记录系统需求，并使客户和项目团队就系统变更达成一致。

• 需求工程中需求管理的目标是：

  • 观察系统上下文以检测上下文更改
  • 管理需求工程活动的执行
  • 管理需求人工制品

• 需求在整个系统生命周期中都会发生变化。

• 需求变更是不可避免的。

• 系统运行期间遇到的问题可能导致需求变更：

  • 不一致、系统错误或不令人满意的系统质量。

• 更多的需求变更源于系统上下文。

• 主体、使用、IT系统、开发

• 可能的环境变化

  • 新技术或新的竞争产品出现了
  • 法律或标准的改变
  • 利益相关者目标的演变
  • 其他利益相关者的参与
  • 改变组织政策
  • 外部参与者（利益相关者或系统）使用系统方式的变化

• 管理需求工程活动

  

• 需求管理的内容

  • 需求属性方案的定义
  • 标识符、名称、需求类型、版本、作者、状态、优先级等。
  • 必须为不同的人工制品类型定义适当的属性方案
  • 需求可追溯性
    • 需求应追溯到其起源、完善或实现
  • 需求变更管理
  • 需求配置管理
  • 需求优先级

2 Requirements Traceability

2.1需求可追溯性的基本原理

• 需求可追溯性是一种重要的质量保证手段。
• 可追溯性表示不同开发人工制品之间建立关系的程度，尤其是相互之间具有先人-继承人-或主从-关系的人工制品
• 记录的需求可追溯性信息支持各种系统开发活动
  • 可验证性和验收、变更管理、质量保证、维护和维修、重新设计、重用、风险管理、过程改进

2.2可追溯性的分类

• 时间：前可追溯性与后可追溯性

  • 需求人工制品与其来源或来源之间的可追溯性
  • 需求工件及其后续工件之间的可追溯性

• 方向：向前与向后跟踪

  

• 扩展的前后可追溯性

  • 需求工件和前身/后继工件之间的可追溯性
  • 不同类型需求工件之间的可追溯性，例如目标、场景和 solution-oriented requirements面向解决方案的需求

  

2.3可追溯性信息的呈现

• 文本参考

• 超链接

• 跟踪矩阵

  

  

  

3 Prioritizing Requirements

3.1需求优先级划分的基础

• 需求的优先级记录了需求对于一个或几个优先级标准的重要性。
• 需求工程中的优先级
  • 启发，文档，协商，验证，管理
• 为什么需要区分优先级?——权衡
• 需要选择什么来实现
  • 客户(通常)要求太多
  • 平衡上市时间和数量的功能
  • 决定哪些特性进入下一个版本
• 执行分类
  • 一些要求“必须”被包括
  • 一些需求应该被排除在外
  • 这就留下了一个“值得拥有的东西”池，我们必须从中选择
• 一个需求的优先级可以单独为每个需求确定，也可以通过需求的两两比较来确定。
• 对于每个需求或特性，问:
  • 这对客户有多重要?
  • 实现它需要多少成本?
  • 尝试建造它的风险有多大?

3.2需求优先级划分的四个步骤

• 确定利益相关者
  • 基于目标和标准的利益相关者选择
• 确定工件的优先级
  • 在一个优先级活动中，只对相同的工件类型的工件进行优先级划分
  • 首先，确定高级需求的优先级
• 选择优先级标准
  • 重要性，成本，损害，持续时间，风险，波动性
• 选择优先级技术
  • 一标准分类，卡诺分类，两标准分类，韦格斯优先级矩阵，成本-价值法

3.3需求优先级划分技术

• 3.3.1One-Criteria Classification单准则分类

  • 基于单一标准对需求工件进行优先级划分
  • 单一标准分类的一个常见标准是需求工件的必要性程度
    • Essential必要的:意味着除非这些需求以一种一致同意的方式得到满足，否则系统是不可接受的。
    • Conditional有条件的:暗示这些需求工件将增强系统，但如果它们不存在，则不会使其不可接受。
    • Optional可选:暗示一类可能值得也可能不值得的需求工件。

• 3.3.2 Kano分类

  • 根据系统特性(或顾客要求)对顾客满意的影响进行分类

    • Dissatisfier不满足者:(必须要求)系统必须实现这一要求才能进入市场
    • Satisfier满足者:(一维顾客要求)
    • Delighter更满意者:(吸引人的要求)

    

    

• 3.3.3Two-Criteria Classification双准则分类

  

• 3.3.4 Wiegers的优先级矩阵

  • 优先化过程考虑四个优先化标准:

    • 收益、惩罚、成本和风险。

  • 需求优先级的执行是基于这样一个假设:需求的优先级与它的收益(如果实现了)和惩罚(如果没有实现)成正比，与需求的成本和风险成反比

    

• 3.3.5Cost-Value Approach 成本-价值法

  • 计算投资回报(ROI)

    • 评估每个需求对整个项目的重要性
    • 评估每个需求的相对成本
    • 计算成本价值权衡

    

  • 估算成本和价值

    • 两种方法：

      • 绝对刻度：（例如美元值）
        • 需要很多领域经验
      • 相对值：（例如，更少/更多；一点、多少、非常）
        • 容易得多
        • 优先成为一个排序问题

    • 比较过程-选项

      • 基本排序-对于每一对需求（i，j），询问i>j？

        需要n*（n-1）/2个比较

      • 构造二叉排序树需要O（n logn）比较

      • 构造最小生成树需要（n-1）比较

    • 一些复杂的情况:

      • 很难量化差异
        • 说“x比y重要”……
        • ……比估计重要多少要容易。
      • 不是所有要求可比
        • 如不同抽象层次
        • 如核心功能与客户增强
      • 要求可能不是独立
        • X和Y之间没有点选择,如果他们是相互依赖
      • 如利益相关者可能不是一致的
        • 如果X > Y, Y > Z,然后大概X > Z?
      • 利益相关者可能不同意
        • 不同类型的利益相关者有不同的成本/价值评估

  • 层次优先级

    • 将需求分组到一个层次结构

      • 例如目标树
      • 例如NFR树

    • 只对单个节点的分支进行比较:

      reciprocal 倒数的

      

      

      

      

  • 绘制ROI图

    • 做AHP进度两次:

      • 一次估算相对价值
      • 一次估算相对成本

    • 使用结果计算ROI率

      

4 Requirements Change Managemen

4.1变更管理基础

• 目标
  • 控制变更，而不是避免变更
  • 需求工程中变更管理的任务是管理需求变更，并确保每个变更都正确实施和可跟踪。
• 内容
  • 组织变更管理活动
    • 提交变更请求、影响分析、决策、实施和验证
  • 记录变更管理结果

4.2需求配置与需求基线

• 需求配置：需求工件的配置包含一组相关的需求工件，或者更准确地说，需求工件的版本。
  • 需求工件的配置具有以下属性:
    • 一致性，唯一标识，不可更改，Basis for roll-back 回滚的基础
• 需求基线:一个需求基线是一个选择的需求工件的配置。
  • 一个基线具有需求配置的所有上述属性。此外，基线还具有以下属性:
    • 系统发布定义的基础
    • 对客户的可见性
    • 易受变更管理
    • 系统发布规划的基础
    • 实现成果的评估
    • 与竞争对手产品的比较
• 需求配置与需求基线

4.3变更管理流程

• 变更控制委员会(CCB)

• 职责:对变更进行评估(控制范围扩大和影响分析)，做出决策，并确保已批准变更的实施

• 成员:

  

• 控制范围扩展

  • 根据业务目标、愿景和范围对每一个新增的需求或特性进行评估

• 影响分析

  • 对需求工件的影响分析

  • 对后续工件的影响分析

    

5 Requirements Management Tools

5.1为什么我们需要工具?

• 提高效率
• 工具帮助我们:
  • 保存需求属性
  • 管理需求的更改
  • 跟踪需求状态
  • 帮助影响分析
  • 访问控制
  • 与利益相关者沟通
  • 重用的需求
• 集中在数据库
  • 存储需求,属性,跟踪信息在数据库
    • Caliber-RM
    • DOORS
    • RTM Workshop
  • 集中在文档
    • 将需求保存为文档
      • QSSrequireit:单词+属性表
      • RequisitePro:文档+数据库
      • RTM Workshop:文档/数据库

5.2如何选择工具?

• 1)为需求管理工具定义项目需求。确定下列事项:

• 最重要的功能是什么？

• 是否要与其它使用的工具连接以及通过Web远程数据处理是否重要?

• 决定是使用数据库存储全部数据还是只存储一部分。

• 2)列出影响决策的10~15个因素。既要有主观的也要有客观的因素(如裁剪能力、有效性及GUI的效率)

• 3)对步骤2中列出的因素打分(总计100分),对更重要的因素可以打更高的分。

• 4)获得有关可用的需求管理工具的最新信息，根据影响决策的因素对候选工具排序。对客观因素的评分只有在使用每个工具后才能进行。开发商的展示可能会增加一些感性认识。但展示往往不全面，所以最好还是亲自使用一个(几个小时).

• 5)根据给每个因素的加权值来计算每个候选工具的得分，从而确定最合适的产品。

• 6)从候选工具的其他用户那里获得一些体会，可以通过在线论坛获得经验，对自己的判断和开发商的投标进行补充。

• 7)从候选工具中前三名的开发商处得到评估拷贝。确定候选工具前先定义一个评估处理过程，确保获得足够的信息做出好的决策。

• 8)最好用一个实际的项目来评估工具，不要仅用工具所带的示教项目进行评估。完成评估后，如有必要调整排名分数。找出得分最多的工具。

• 9)经过对排名、许可权费、开发商后续支持费、当前用户的输入、工作小组主观印象等的考虑之后做出决定

• 需求管理工具选型要素

  • 需求文档
    • 模块化、结构化
    • 可以根据需求文档的不同类型划分为如下的模板或结构：
      • Vision：整体需求
      • Glossary：名词术语、缩略语等
      • Feature：需求功能点
      • Use Case：用例
      • Test Case：测试用例
    • 细分
      • 按功能点进行尽可能的细分，如果需要，可以建立多个文档
    • 格式化
      • 版式(字体、段落、颜色等)、表格、插图、超链
    • 可带附件
  • 文档管理
    • 分类：提供详尽而合理的分类及层次关系
    • 全文检索
    • 文档信息
    • 文档内容
    • 文档链接：文档之间可以建立链接关系
    • 协同工作：支持多人同时登录，对需求进行查看、维护、管理等
    • 权限控制：只有授权用户才可以访问并完成相应的操作
    • 流程控制：工作流
    • 版本控制：文档历史版本控制
    • 视图：提供可定义的文档状态视图，可以从不同角度查看文档的状态
    • 输出合并文档：生成完整的需求文档（也可只指定生成某个子需求的文档）
  • 需求跟踪
    • 基线管理
    • 需求关联：某个需求的修改，可能会导致其他需求变为Suspect
    • 代码关联：能够与代码进行关联
    • Bug关联：能够与Bug库中的Bug进行管理
    • 讨论管理：能够对需求点进行讨论，记录讨论过程
    • 输出报表：能够输出一定格式的报表、度量图等
  • 其他因素
    • 可扩展性：插件机制、SDK等
    • 提供Web访问方式
      • 提供web方式访问，简化了客户端的部署和维护
    • 易用性：易于使用及维护
    • 是否有中文版：最好有中文版
    • 与其他应用系统协作：如office、visual studio等
    • 通知：当某个需求文档发生改变时，可以通知相关人员
    • 获取方式：是否需要购买，License方式等

• 商业需求管理工具示例

  

5.3Introduction to IBM RequisitePro

• 一个强大、易用、可集成的需求管理产品
• 一个RequisitePro项目包含若干Microsoft Word文档和一个后台数据库
• 使用Word文档和数据库两种方式来存储并管理需求，使得RequisitePro兼有数据库的强大功能和Word的易用性
• 可定制各种视图和过滤器，可进行优先级划分、链接需求并跟踪需求变更