吉林大学软件需求分析与规范(Software Requirements Analysis & Specification)

写在前面：

4w多字笔记，可能显示有问题，带图片完整pdf版暂定10r一份，需要的同学可以加wx:fanaobo，备注软件需求笔记。

chapter 0 课程简介

课程简介：

◼ 软件工程专业核心课程之一

◼ 软件工程课程体系最前端课程

◼ 主要内容：需求的基本概念，需求的分类，需求工程的基本过程，需求获取的方法、步骤、技巧，需求分析和建模技术，需求定义和验证的方法和技术，需求管理等

◼ 开设目的：提升职业素养----培养发现问题、分析问题、解决问题能力；培养沟通能力和管理能力

软件开发项目组组成

◼ Project Manager 项目经理

◼ System Architect 架构师

◼ Requirements Engineer需求工程师

◼ System Engineer 系统分析师

◼ Database Architect数据库工程师

◼ Software Developer 开发人员

◼ Tester 测试人员

◼ Deployment Engineer 实施人员

◼ Configuration M & QA 配置管理、质量保证

◼ 美术设计师

Chapter 1 软需简介

1软件与软件工程

1.1软件

1.2软件工程

1.3需求对项目成功的影响

2软件需求

2.1问题域

2.2需求

2.3需求类型

3需求工程

3.1需求工程的历史

3.2需求工程的定义

3.3需求工程活动

1 软件与软件工程

1.1 软件

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

·常见的软件：

系统软件：Window10，Unix，Linux，Oracle，Visual Studio等

应用软件：QQ，微信，知乎等

中间件：Tomcat，Websphere，Jboss等

·软件的特点：

复杂性

一致性

易变性

不可见性

1.2 软件工程

·[IEEE1990]中给出的软件工程的定义:

1）应用系统的、规范的、可量化的方法来开发、运行和维护软件，即将工程应用到软件。

2）对 1）中各种方法的研究。

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

·我们希望软件解决的问题是“邪恶的”

·现代系统特点

·软件开发面临的问题是什么?

·为什么需要软件工程?

·什么是好的软件？

·软件过程

开发软件系统所需的一组结构化的活动，基本活动包括:

项目计划

需求定义与分析

设计（属于开发）

编码（属于开发）

测试（属于开发）

维护

·软件开发生命周期

瀑布模型

V模型

增量式模型

迭代式模型

螺旋模式

敏捷开发

1.3 需求对项目成功的影响

略

2 软件需求

2.1 问题域

问题域（problem domain）

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

解系统（solution system）

待开发的软件

需求（requirements）

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

2.2 需求

需求定义

2.3 需求类型

·需求分类：

[IEEE1998]将需求分成5类：

功能需求：定义系统应该提供什么服务，系统应该如何对特殊输入做出反应，以及系统在特殊情况下应该如何表现。在某些情况下，还定义了系统不应该做什么。

质量属性（非功能需求）：系统完成工作的质量。

性能需求（非功能需求）：定义系统、组件、服务或功能的质量属性。

约束（非功能需求）：限制系统开发方式的组织或技术要求。

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

约束可能导致需求的变化，或定义新的需求。

对外接口（非功能需求）

·例：房屋信息系统的要求

R1:系统应该提供一个用户友好的界面。

R2:系统每月应该能生成一份包含所有被允许进入房屋的所有记录的报告。

R3:如果用户输入正确的PIN码(用户ID)，系统应开门并记录此访问，记录的信息包括日期、时间和用户名。

R4:该系统应该在2006年5月1日前上市。

R5:正确输入PIN码后，0.8秒内开门。

功能需求（functional requirements）的三个层次

业务需求（business requirements）

业务需求描述组织或客户的高层次目标，定义系统特性。通常来自于高层业务部门。业务需求从总体上描述了为什么要开发软件或系统（即Why），组织希望达到的目标。业务需求获取后形成的文档为项目前景和范围文档。这些文档描述了组织对将使用的软件系统所要达到的目标的预期期望。

用户需求（user requirements）

用户需求主要指用户使用产品必须要完成什么任务，怎么完成需求， 通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值，或用户要求系统必须能完成的任务。用户需求主要描述了用户使用系统能够做什么事情（即What）。通过用户需求信息形成的文档为用例说明文档。

系统需求（system requirements）

系统需求是用户对系统行为的期望，一系列的系统需求联系在一起， 帮助用户完成任务，达成用户需求，进而满足业务需求。系统需求可以直接映射为系统行为，定义系统中需要实现的功能，描述开发人员需要实现什么。它描述的是开发人员如何设计具体的解决方案来实现这些需求（即How），是业务需求和用户需求最终实现的目标。系统需求信息都记录在需求规格说明（ Soft Requirments Specification即SRS）文档中。

·例：

业务需求：B1.通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10%以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。 ​ 用户需求：U1.系统将通过短信将续保信息发给保费即将到期客户的代理人。

系统需求：S1. 系统每天检测保费即将到期(提前2周)的保单，并生成每日到期保单报表； ​ S2. 系统向到期保单报表中的每张保单的代理人发送短信；

·非功能性需求

未指定的功能需求：细化——将其定义为一个或一组功能需求，必要时还应包括相应的质量需求。

非功能性需求=未指定的功能需求（包含质量需求）

·非功能性需求的例子

R12:系统应该是安全的

1.形容词“secure”是什么意思?

2.为了“安全”，系统应该提供哪些属性?

3.如何检查所实现的系统是否“安全”?

改进后：

R12.1:每个用户在使用系统之前，必须使用用户名和密码登录系统（功能需求）

R12.2:系统每四周提醒用户修改一次密码。（功能需求）

R12.3:当用户修改密码时，系统应确认新密码至少包含8个字符长，且包含数字和字母。（功能需求）

R12.4:用户密码存储系统需要保护，防止被盗。（质量属性中的完整性）

---

·功能性需求与非功能性需求小结：

·一些例子

·该系统应保存所有图书馆资料的记录，包括书籍、连载、报纸和杂志、录象带和录音带、报告、透明资料、电脑磁盘和光盘。

·系统应允许用户按标题、作者或ISBN搜索条目。

·系统的用户界面应该使用万维网浏览器来实现。

·系统应支持每秒至少20个交易。

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

例如，以下几个例子既是一个功能性需求，又是一条安全性需求：

·防火墙管理软件的功能性需求也同样是安全性需求。

·来电过滤常常被看做是功能性特征，同时它也和通话者的隐私需求相关。

·向列车高频发送加速请求，既是功能需求，也是安全需求和性能需求。

·不切实际的期望

·需求表达的是一种期望

·不切实际的期望：

在使用系统时，收银员必须在2个小时之内完成一个销售处理的所有动作。

修改为：

如果一个销售处理任务在2个小时之内仍没有完成，系统要撤销该任务的所有已执行操作。

---

非功能需求（Non-Functional Requirements）

质量属性（quality requirements）

可用性(Availability)

指系统处于实际可用并完全正常运行的时间的百分比。

有效性(Efficiency)

对系统有效利用硬件资源 (如处理器时间、内存或通信带宽)的程度度量。

灵活性(Flexibility)

表示系统扩展新功能时所需的努力。

完整性(Integrity)

表示系统面对受未经授权的访问、破坏数据隐私、信息丢失和通过恶意软件的感染时,系统得到保护的程度。

互操作性(Interoperability)

指示系统与其他系统交换数据或服务的方便程度。

可靠性(Reliability)

是系统在特定时间段内不发生故障而执行的概率。

健壮性(Robustness)

是指当系统或组件遇到无效输入、相连接的系统或组件故障、意外操作条件时，系统或组件继续正确工作的程度。

易用性(Usability)

度量用户为准备输入、操作系统、解读系统输出所需的努力。

可维护性(Maintainability)

指修复系统缺陷、对系统进行更改的难易程度。

可移植性(Portability)

将系统或组件从一个操作环境迁移到另一个操作环境所需的努力。

可重用性(Reusability)

指组件在最初为其开发的系统之外的其他系统中使用的程度。

可测试性(Testability)

是指软件组件或集成系统能被测试以发现缺陷的难易程度。

性能需求（performance requirements）

速度：系统完成任务的时间

pr1: 所有的用户查询都必须在10秒之内完成

容量：系统所能存储的数据量

pr2: 系统应该能够存储至少100万条销售信息

吞吐量：系统在连续的时间内完成的事务数量

pr3: 解释器每分钟至少解析5000条没有错误的语句

负载：系统可以承载的并发工作量

pr4: 系统应该允许50个营业服务器同时从集中服务器上进行数据的上传和下载

实时性：严格的实时要求

pr5: 监测到病人异常后，监控器必须在0.5秒内发出警报

·关于性能需求要注意

性能需求的定义要适合运行环境，过于宽松的性能要求会带来用户的不满，过于苛刻的性能要求会给系统的设计造成不必要的负担，所以给出一个合适的量化标准非常关键，同时又非常困难。常见的方法是在限定性能目标的同时给出一定的灵活性或者给出不同层次的目标要求。

例如pr1:

（最低标准）在 200 个用户并发时，系统不能崩溃。 ​ （一般标准）在 200 个用户并发时，系统应该在 80%的时间内正常工作 ​ （最高标准）在 200 个用户并发时，系统保持正常工作

约束（constraints）

·约束:约束是限制系统开发方式的组织或技术需求。

·约束的类型：

影响系统使用的约束:

C1:根据保险公司的规定，只有安全专家才能停止系统的控制功能。

C2:消防部门要求销售终端尺寸不能超过120cm(高)x90cm(宽)x20cm(深)。

制约因素影响开发：

C3:系统开发工作量不能超过480人月。

C4:系统必须使用Rational统一过程来开发。

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

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

·示例:以下是为建筑物的安全系统定义的要求：

R-F-17:个人密码应用于每个人的身份验证。

在知道这样的建筑门禁必须符合77/12/EG标准后：

R-F-17’:指纹传感器应用于门禁系统，以验证每个人的身份。

R-Q-4:认证必须以至少60分钟的精度进行。

对外接口（interfaces）

·对外接口：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等。

·定义接口时，需说明以下内容：

(1)接口数据格式 ​ (2)接口命令格式 ​ (3)接口标准 ​ (4)接口输入输出 ​ (5)接口用途

·例如：

Android手机点餐app要求手机系统版本Android2.2及以上版本

3 需求工程

3.1 需求工程的历史

·需求工程的历史

·在20世纪80年代，需求工程成为一门独特的专业学科。

·在20世纪90年代，需求工程成为重点领域。

·需求工程国际研讨会(ISRE)自1993年起每两年举办一次。

·需求工程国际会议(ICRE)自1994年起每两年举办一次。

·《需求工程杂志》(REJ)成立于1996年。

·一些工作坊已经建立并投入使用，如RENOIR(欧洲),AWRE(澳大利亚)。

·什么是工程学?

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

工程的特征（feature）

传统工程学科具有以下特点：

纪律-系统化且具有严密性

应用科学的方法和技术

设计和制造产品

满足社会需求-实用性

安全的-安全性

反复权衡

测量

团队合作

使用工具

3.2 需求工程的定义

·定义1

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

·定义2

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

3.3 需求工程活动

需求启动（Inception）

需求获取（Elicitation）

·需求获取：是从涉众(stakeholders)、文档资料或者环境中获取需求的过程，包括收集背景资料，定义项目前景和范围，选择信息来源，选择获取方法或技巧，记录获取结果。

·涉众/干系人: 所有与项目相关的人（直接/间接）。

需求分析与建模(Analysis)

·需求分析：是指建立一个新的或改变一个现存的系统时描写新系统的目的、范围、定义和功能时所要做的所有工作。需求分析是软件工程中一个关键过程。在这个过程中要分析背景资料、确定系统范围 、细化需求、确定优先级，协商需求，确定需求。确定需求后分析和寻求新系统的解决方法，需求分析阶段的任务是确定软件系统功能。

需求规格说明(Specification)

·需求规格说明书：是指将获取的需求需要编写成文档，方便在用户、 客户或开发人员之间交流需求信息，是整个开发工作的基础。其内容包括硬件、功能、性能、输入输出、接口界面、警示信息、保密安全、数据与数据库、文档和法规的要求。

需求验证(Verification)

·需求验证是用来确保需求说明准确、完整地表达需求需要，主要包括审查需求文档，修正不合理的需求

需求管理(Management)

·需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。其活动包括：定义需求基线，建立跟踪信息，进行变更控制。

·需求开发过程

·需求的三个维度

·内容（Content）——问题的覆盖范围

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

·文档化（Documentation）——定义良好的需求

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

·一致性（Agreement）——商定的要求

达成共识了吗?

·持续需求工程

·传统系统分析

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

·需求工程作为一个跨生命周期的活动

·需求工程是跨项目和跨产品的活动

Chapter 2 需求启动（Requirements Inception）

1 需求启动的主要任务

·需求启动是需求工程过程的起点

有时也作为需求获取的一部分

·其主要任务包括

·确定业务需求

·涉众分析

·在问题定义上达成一致

·愿景，边界，范围

·识别限制和风险

·进行可行性研究

·需求启动主要任务1——确定业务需求

·商业机会/背景

描述市场机会、竞争市场、正在解决或改进的业务问题、提出的解决方案的优点、将要解决的问题……

·商业目标和成功标准

产品将以量化和可测量的方式提供重要的商业利益，如何衡量成功，对成功有重大影响的因素……

·客户或市场需求

客户目前遇到的问题将得到解决

·商业风险

与开发或不开发产品相关的主要风险(市场竞争、时机、用户接受度、实施问题……)

·例 自助餐厅点菜系统

·需求启动主要任务2——利益相关者分析

·谁在使用这个系统?

·客户是谁?

·谁受产出影响?

·谁开发/评估/批准系统?

·其他外部/内部用户?

·系统由谁维护?

·谁在乎呢?

·需求启动主要任务3——在问题定义上达成一致

产品愿景（Product Vision）

描述产品是关于什么的，以及它最终会变成什么样子

·了解根本原因是什么

确定是什么因素导致了这个问题

·决定项目的范围和边界

项目范围（Project Scope）

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

边界（boundary）

在内部和外部之间划清边界（boundary）

·例1

项目愿景

用户:对于希望在公司自助餐厅或当地餐厅网上订餐的员工，

COS:一个基于互联网的应用程序，它将接受个人或团体订餐，处理支付，并触发将准备好的饭菜送到process Impact校园的指定位置。

优点:不像现在的电话和人工点餐，不用去自助餐厅取餐，节省时间，有更多的选择。

·例2

项目特性

FE-1:从自助餐厅的菜单上点餐，让他们自己取餐或送餐

FE-2:从当地餐馆订购外卖

FE-3:创建、查看、修改和删除餐饮服务订阅

FE-4:登记膳食付款选项

FE-5:申请送餐

FE-6:创建、查看、修改和删除自助餐厅菜单

FE-7:点自助餐厅菜单上没有的定制餐

FE-8:制作自助餐厅定制餐的食谱和配料表

FE-9:通过公司内部网或授权员工通过外部Internet访问系统

·例3

项目范围

FE-1 方案1 只提供午餐菜单上的标准餐;交货订单只能通过扣除工资的方式支付

方案2 接受早餐和晚餐的订单，除了午餐;接受信用卡和借记卡付款

方案3

FE-2 方案1 没有实现

方案2 没有实现

方案3 完全实现

FE-3 方案1 在时间允许的情况下实现(中等优先级)

方案2 完全实现

方案3

FE-4 方案1 只登记工资扣除付款

方案2 注册信用卡和借记卡付款

方案3

FE-5 方案1 餐食只会送到公司的园区，而不会送到公司以外的地方

方案2 添加从自助餐厅到选定的异地配送服务

方案3

FE-6 方案1 完全实现

方案2

方案3

FE-7 方案1 没有实现

方案2 没有实现

方案3 完全实现

FE-8 方案1 没有实现

方案2 完全实现

方案3

FE-9 方案1 完全实现

方案2

方案3

·需求启动主要任务4——识别限制和风险

经济(例如，成本，许可问题)

政治(例如，内部或外部，部门间问题)

技术(例如，技术/平台的选择)

系统(例如，现有系统，兼容性问题)

环境(如法律/环境/安全/标准)

计划和资源(例如，固定计划，团队)

·例

项目约束与风险

LI-1:一些从自助餐厅提供的食物不适合外卖，所以自助餐厅点餐系统提供给顾客的菜单将是整个自助餐厅菜单的一个子集。

LI-2:自助餐厅点菜系统应使用仅适用于俄勒冈州克拉卡马斯的主要流程影响园区的自助餐厅。

商业风险

利益相关者的约束

·需求启动主要任务5——进行可行性研究

·进行可行性研究

·要了解一个软件开发项目是否可以完成:

...这可能吗？

...这合理吗？

·提出可能的替代解决方案。

·为管理层提供足够的信息以了解:

项目能否完成

最终产品是否会使其预期用户受益

备选方案是什么(以便在后续阶段进行选择)

是否有首选的替代方案

·可行性研究是一项面向管理的活动

在可行性研究之后，管理层做出“去/不去”的决定。

需要在更广泛的业务战略背景下检查问题

·可行性研究的研究内容:

·现行组织体制

用户、政策、功能、目标……

·现行制度的问题

功能、性能上的不一致、不足……

·新系统的目标和其他要求

需要解决哪些问题?

·需要改变什么?

·约束

包括系统上的非功能性需求

·可能的选择

坚持现行制度应该一直作为一种替代方案加以研究

解决问题的不同业务流程

不同层次/类型的计算机化解决方案

·备选方案的优缺点

·总结如下:

项目可行性

首选的替代方案

·需求启动主要任务总结

在问题定义上达成一致

边界、范围

利益相关者分析

识别业务需求

识别限制和风险

进行可行性研究

2 需求启动过程中的文档

·项目愿景和范围文件

·项目可行性报告（模板）

·项目计划书（模板）

项目愿景和范围文件

1.业务需求

1.1. 背景、商业机会和客户需求

1.2. 业务目标和成功标准

1.3. 商业风险

2.解决方案的愿景

2.1. 愿景声明

2.2. 主要功能

2.3. 假设和依赖关系

3.范围和限制

3.1. 初始版本和后续版本的范围

3.2. 限制和排除

4.业务上下文

4.1.涉众的概要文件

4.2. 项目优先级

项目可行性报告

软件设计国家标准 - 可行性研究报告 - 《常用文档模板》 - 书栈网 · BookStack（自己网上找的）

项目计划书（模板）

报告模板

3 系统与上下文

·系统

·系统是可以被观察到的现实的一部分

观察意味着能与其交互

·例：

物理系统:汽车、飞机、电梯

无形系统:操作系统、数据库管理系统、信息系统、银行账户

·上下文

·上下文是与定义、理解和解释系统需求相关的系统环境的一部分

每个系统都有一个上下文

系统的上下文就是一个系统

·例：

人

运行中的系统

过程(技术或物理过程、业务过程)

事件(技术或物理)

物理定律(如：牛顿定律，波义耳定律)

文档(如：法律、标准、用户手册)

·需求取决于上下文

·上下文信息需要被记录

了解上下文可以降低错误解释的风险

·独立于需求来记录上下文信息

·使用特定于项目的指南来记录上下文信息

较小的项目通常需要记录较少的上下文信息

·上下文方面:系统上下文的物质和非物质对象，如人、技术系统和非技术系统、过程、事件或物理定律。

一些上下文刻面直接与系统交互，从而影响系统需求的定义

其他上下文刻面根本不与系统交互，但仍然以某种方式影响系统的需求

·上下文方面

与系统有直接交互关系的上下文方面的例子:

银行客户用自动提款机从他的账户里取钱。因此，在定义自动取款机的需求时，必须考虑到银行不同客户的具体情况。

上下文方面与系统没有交互关系，但仍然影响系统的需求:

法律要求输入银行系统并在系统内使用的敏感数据项使用特定的加密标准进行加密。

·上下文的四个刻面

主体刻面

主体刻面：与系统相关的对象和事件

如：系统必须存储或处理其信息的元素

需求来源

·领域专家：

·医生和事故调查人员，制动系统和驱动列车控制系统专家

“汽车安全系统应当监控驾驶员的注意力，并采取相应措施来防止驾驶员在开车过程中打盹。系统必须了解驾驶员当前的注意力情况，因此这个重要属性必须在系统中进行表示。医生和事故调查员必须参与进来，而且制动系统和驱动控制系统方面的专家也要参与进来，以明确发现驾驶员在开车打盹的情况下该如何应对。”

·律师和数据隐私官

“哪类数据可以在系统中存储，数据应当如何存储(如考虑加密)、哪类数据必须隐去，特定类型数据可以或者必须保存多长时间、特定类型的数据在多久后可以后者必须被删除等”*

·文档：

域模型(定义了上下文对象，属性及其关系)

教科书和有关学科领域的法律

·现有的系统

上下文对象

汽车本身以及汽车的相关部件，如发动机、车轮、轮胎和制动器

车内人员，如驾驶员和副驾驶员

其他交通参与者，如前面行驶的汽车和行人

车外环境条件如气温、路况等。

属性和关系

·陈述的准确性(数据精度，抽象)

“系统应通过GPS定位汽车的当前位置，精度在30米以内，此外，在二维空间内进行定位即可,不需要考虑汽车所处的海拔高度(表示的抽象)

·陈述的现状

“系统应当至少每秒钟通过GPS更新一次汽车的当前位置以在城市道路或高速公路上向驾驶员提供足够的导航信息”

·代表的法律要求

“基于安全和可控的考虑，法律规定每辆车的当前位置和速度必须每隔10秒进行一次记录并且至少保存2个月。记录的位置分辨率要达到50~100米。记录的速度准确性要达到（+/-）3公里/小时。

使用刻面

使用刻面：与人或其他系统的使用有关的方面

如：用户组和使用流程

需求来源

·直接用户:

司机控制汽车，从汽车安全系统获得有关当前情况的反馈

·间接使用者:

副驾驶不主动控制车辆，但她或他可能影响驾驶员的决策

·专家:

用户界面设计及相关应用领域

·文档:

定义用户界面或允许使用的工作流程的质量方面的标准、法律和法规

“欧洲汽车人机接口设计原则目录中有这样一个条规定:系统设计应当避免分散驾驶员的注意力，同时也不允许向驾驶员提供任何形式的视觉娱乐”

·现有的系统

以相同或相似方式使用的系统

上下文对象

·用户群体:

运动型司机和安全型司机的区分很重要

·使用界面类型:

触觉、听觉、语言或视觉

·使用工作流:

使用过程、角色、活动和职责都是潜在的、相关的上下文对象

·与其他系统的交互

属性和关系

·使用工作流之间的关系

·用户组与使用工作流的关系

与系统的交互通常需要满足一些约束条件，这些约束条件与用户和特定的用户组之间的从属关系相关。

·与IT系统方面的关系

当前系统的运行状态会进一步影响使用流程。使用流程的一个重要属性就是对于不同运行模式的配置，如普通 模式，节能模式，或者故障、恢复和应急模式。这些可能的运行模式是由IT系统刻面决定的。

·与主题面的关系

“驾驶员必须能够很自然地将所提示的警告信息和现实世界中的某种具体威胁联系在一起。” 这种威胁通常与使用刻面中的上下文对象相关。例如威胁”与前车的安全距离”与上下文对象”前车”相关。

IT系统刻面

IT系统刻面：系统的IT系统环境的对象和元素

如：使用现有的硬件和软件组件

需求来源

·相关涉众:

所有处理IT系统环境的规划、设计和操作的人员:系统架构师、硬件开发人员、测试专家或首席技术官。

“对于一个汽车安全系统而言，所有相关的电子器件(如传感器、执行器、刹车控制单元和安全气囊控制单元)之间准确协作是非常重要的。因此，需求工程过程中应包括的IT系统刻面的相关涉众包括这些器件的开发人员以及汽车所用的通信协议专家。

·技术顾问及供应商

了解软硬件组件市场趋势和策略

·文档

发展中公司的IT战略文件

客户的IT战略文件

描述系统操作的基础设施和相关策略的文档

·系统的现有参考体系结构

·现有的系统

上下文对象

·系统开发过程中需要考虑的硬件和软件组件

·待开发系统的操作维护

·有关公司的资讯科技策略

属性和关系

·软硬件组件技术特性:

“因为Carsoft公司的顾客越来越频繁地要求在汽车中安装FlexRay总线系统，Carsoft的IT策略规定自2009年9月1日起Carsoft的所有产品都将支持FlexRay”性能特点或故障率;

·成本或可用性

“系统一年内最多只能停用3小时”与”系统 每天上午9点到下午5点必须处于可用状态”相比，前一个需求将会带来更多的挑战。

·操作配置文件

数据在什么时候，以何种方式进行备份

·更新政策

IT系统环境中的软硬件组件的交换和更新，更新可能会导致测试的重新执行

开发刻面

开发刻面：系统开发过程的相关方面

如：过程指南，开发工具。

需求来源

·相关干系人:

过程工程师、过程经理、过程执行者

·文档:

开发标准、开发指南、方法描述、最佳实践文档、以前项目的项目计划

“对于汽车安全系统的开发，有这样一项要求：必须应用AUTOSAR标准中定 义的指南”

上下文对象

·角色定义

·人工制品的定义

·活动定义

·工具

·资源可用性和资源限制

属性和关系

·协调发展过程

·开发过程接口

·过程质量

·四个上下文刻面之间的逻辑关系

·主体刻面与IT系统刻面的关系

关于现实世界对象的信息表示，如汽车的速度或客户的姓名

·IT系统刻面与使用刻面的关系

系统进程根据功能来表示信息

·使用刻面与主题刻面的关系

系统用户解释系统的输出，并将其与主体刻面的真实世界对象相关联

·开发刻面的作用

考虑其他三个上下文刻面的相关刻面及其关系，因此是与所有其他刻面相关的

·facet的使用提高了需求文档的质量

4 目标

4.1 目标及目标分解

·目标:目标是关于目标、属性或系统使用的一种内涵。

愿景（Vision）

系统愿景通常定义系统的最高目标。

因此，所有其他目标都应该细化系统愿景。

·目标的细化也称为“目标分解”。

4.2 目标的AND/OR分解

目标的and分解

1.将一个目标分解为一组子目标G1，…Gn

2.n>1

3.当且仅当所有子目标都满足时，目标G才被满足

目标的or分解

1.将一个目标分解为一组子目标G1，…Gn

2.n>1

3.如果一个子目标得到满足，则目标G得到满足

·例：目标的and分解:

目标G“舒适和快速导航到目的地”被and分解为以下三个子目标:

G1:容易进入目的地

G2:根据用户参数自动路由

G3:显示堵车情况，自动改道避免堵车。

·例：目标的or分解:

目标G“定位汽车位置的能力”通过or分解分解为以下两个子目标:

G1:通过手机定位汽车

G2:通过GPS定位汽车

4.3 目标依赖性

目标之间的“需要”依赖关系

目标G1需要目标G2，如果满足G2是满足G1的先决条件。

举例:G1需要G2

G1:系统将引导司机绕过交通拥堵。

G2:系统能够接收到流量消息。

目标之间的“支持”依赖关系

目标G1支持目标G2，如果对G1的满足对G2的满足有积极的贡献。

举例:G1支持G2

G1:导航系统应能按需下载电子地图。

G2:系统应允许简单输入目的地进行导航。

目标之间的“障碍”依赖关系

如果满足G1会阻碍G2的实现，那么目标G1就会阻碍目标G2。

举例:G1干扰G2

G1:导航系统应能按需通过GSM网络下载电子地图。

G2:尽量减少导航系统导致的GSM网络数据流量。

目标之间的“冲突”依赖关系

目标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 文档目标

4.4.1 记录目标的模板

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

G:舒适快捷的导航到目的地

G1:容易进入目的地

G2:根据用户参数自动路由

G3:显示堵车情况，自动改道避免堵车

·一个记录目标的模板

·记录目标的7条规则

1.简明扼要地记录目标

例1:简明扼要地记录目标

目标G1:专家用户和没有经验的用户都能使用系统。没有经验的用户应该能够在不了解前辈系统的情况下使用系统。此外，一个没有经验的用户应该能够在没有任何培训的情况下使用系统。对于任何用户来说，如何使用系统都是不言而喻的。即使不了解类似的系统，也必须能够使用该系统。

G1的改进定义:用户无需培训和/或了解以前的系统即可使用系统。

2.使用主动语态

例2:使用主动语态来记录目标

目标G2:季度报表的生成时间比原系统缩短一半。

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

3.准确地记录涉众的意图

例3:精确地记录意图

目标G3:该系统将导致公司工作流程的改进。

G3定义的改进:系统处理订单的工作流程至少要加快20%。

4.把高层次的目标分解成更具体的子目标

例4:分解高级目标

目标G4:提高驾驶安全。

G4定义的改进:通过and分解将目标G4分解为以下子目标:

G4.1:在湿滑路面上减少20%的制动距离。

G4.2:确保车辆在制动操作时保持可转向性。

5.说明目标的附加价值

例5:明确目标的附加价值

目标G5:导航系统应该提供一种进入旅行目的地的直观方式。

改进的G5定义:导航系统应允许驾驶员在不分心的情况下进入预期目的地。

6.记录引入目标的原因

例6:记录引入目标的原因

目标G6:系统应提供直观的用户界面。

G6定义的改进:系统需要提供一个直观的用户界面，因为80%的用户一个月只使用一次或两次系统。

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

例7:在目标定义中避免不必要的限制

目标G7:优化数据传输时间，使系统响应时间减少10%。

G7定义的改进:系统响应时间减少10%。

4.4.2 AND/OR树和AND/OR图

·AND/OR树

由表示目标分解的节点组成

分层，每个节点都有一个超级目标

图形符号表示分解类型(AND/OR)

·AND/OR图

有些子目标有助于实现一个以上的超级目标

AND/OR图是无循环的

·扩展AND/OR图

“需要”的关系

“冲突”的关系

4.4.3 i* (i-star)

·i*框架是记录和分析目标和目标依赖关系的综合方法。

·基于建模语言GRL

用于记录目标分解的AND/OR树

质量方面的建模构造

·基本概念

对象

参与者

目标

任务

资源

i* 软目标（soft goal）

软目标是参与者希望达成的现实世界中的某种条件

关系

依赖关系:参与者之间的关系

链接:对象之间的关系(参与者除外)

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

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

目标依赖:参与者依赖另一个参与者来实现目标

任务依赖:参与者依赖于另一个参与者来执行任务

资源依赖:参与者依赖于另一个参与者提供的资源的可用性

软目标依赖:参与者依赖于另一个参与者来执行导致软目标实现的任务

i*中对象之间的关系

目的-手段链接（Means-end link）:记录哪些元素(软目标、任务和/或资源)有助于实现目标

贡献链接（Contribution link）:记录任务或其他软目标对软目标的积极或消极影响

任务分解链接（Task decomposition link）:记录任务的基本元素(子任务)

两种目标模型

策略依赖模型(SDM)

记录参与者之间的依赖关系

它们所依赖的任务、目标、软目标和资源的文档

·i*中的策略依赖模型示例

策略原理模型(SRM)

·通过定义参与者的内部结构来详细说明每个参与者

·提供外部依赖关系的基本原理

·i*中的策略原理模型示例

4.4.4 KAOS

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

·六个互补的视图或子模型

目标模型

障碍模型

对象模型

代理模型

操作模式

行为模式

·用于对目标建模和将目标责任分配给代理的KAOS框架的基本构造

对象（Objects）

行为目标:一组可接受的系统行为

实现目标:财产必须最终持有

维护目标:财产必须永远持有

KAOS软目标（soft goal）

记录备选系统行为之间的偏好，没有明确的满意度标准

代理（Agent）

主动的系统组件，具有满足某个目标的特定角色(例如：用户)

关系（Relationships）

AND分解

将一个超级目标与一组子目标联系起来

选择分解

给超级目标分配多个AND分解

每个选项都是一组AND分解(可能只有一个)

潜在冲突

一个目标可能会妨碍实现另一个目标

责任分配(目标与代理的关系)

意味着代理负责满足目标

只有终端目标(无法细化的目标)可以分配给代理

KAOS中的目标模型示例

KAOS中责任分配的例子

4.4.5决定使用哪种目标建模语言

扩展的AND/OR图

记录目标和依赖关系，但不记录代理

i*框架

主要针对行为者和他们的目标

主要关注点:系统环境

复杂的建模语言，使用前需要一些培训

KAOS

代理上的目标是系统用户或组件

非常类似于扩展的AND/OR目标图

其他五种补充型号，同样为硬件组件

非常适合嵌入式系统

使用前需要进行一些培训

5 问题分析

5.1 发现问题

·客户描述的模糊问题

经理想把教师填写的图书订购表格电脑化;

理赔经理希望将处理保险索赔所需的平均时间从2个月缩短到2周

CIO希望将计费系统与几个附属公司的客户记录系统集成，这样就只有一个计费系统……

·通常你只看到症状而看不到原因:

Ontario省需要x光扫描的患者必须等待数月

漫长的等待只是症状，而不是问题。问题可能是:

x光机不足;

缺乏训练有素的工作人员;

缺乏处理数据的医生

低效的调度程序

5.2 查找根本原因

问题：日内瓦湖上的山脉中建成了一条很长的汽车隧道，为了防止停电时发生灾难，必须提醒司机进入隧道之前把车灯打开。

解决方案一：“警告！前有隧道请打开车头灯”

新问题：隧道出口风景很美，返回时发现汽车没电—忘了关车头灯！！

解决方案二：出口处立标牌“关掉车灯”

新问题：夜行车也会关掉车灯？

解决方案三：建充电站

新问题：维护开支大，充电站也会出故障

解决方案四：授权私人经营充电站

新问题：风景区商业化，政府与游客均不接受

解决方案五：在隧道尽头，树立新标牌

如果是白天，并且车灯开着，请熄灭车灯；

如果天色已晚，并且车灯没开，请打开车灯；

如果是白天，并且车灯没打，就别打开它；

如果天色已晚，并且车灯开着，请别关掉它。

新问题：谁能在行驶时读完？！

终极解决方案：你的灯亮着吗？

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

问题分析工具

鱼骨图

用于定性分析

找出影响因素

帕累托（直方）图

用于定量分析

找出关键因素

5.3 确定解决方案体系的视图和边界

产品愿景（Product vision）

描述产品是关于什么的，以及它最终会变成什么样子

将所有涉众对准一个共同的方向

边界（Boundary）

解系统边界

系统和参与者之间的职责界限

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

愿景陈述(1)

愿景陈述模板(根据Moore)

For[目标客户]

Who[需要或机会的陈述]

The[产品名称]

Is[一个产品类别]

That[关键好处，购买或使用的令人信服的理由]

Unlike[主要竞争选择，当前系统或当前业务流程]

Our Product[新产品主要差异化及优势陈述]

愿景陈述(2)

对于需要化学品容器的科学家来说，化学品跟踪系统是一个信息系统，它将为化学品仓库和供应商提供一个单一的访问点。该系统将存储公司内每个化学品容器的位置、容器中剩余物质的数量以及每个容器的位置和使用的完整历史。该系统允许公司充分利用公司内部已有的化学品，处理较少的部分使用或过期的容器，并使用单一的标准化学品采购流程，在使用的第一年将为公司节省25%的化学品成本。与目前的手动订购流程不同，我们的产品将生成所有所需的报告，以符合政府法规，要求报告化学品的使用、存储和处置。

·边界确定

·然而，系统边界也可能发生迁移…

·范围和边界

边界（Boundary）

系统和参与者之间的职责边界

范围（Scope）

系统能做什么来满足用户的需要，通常表示系统的功能

范围和边界的表示

上下文图(边界)

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

5.4 识别施加在解决方案上的约束

·对交付预想的解决方案的能力设置限制

·通常是对系统施加主要限制的非功能性需求

·限制的来源包括:

经济(如预算)

政治(例如，许可证问题，部门间问题)

技术(例如，技术/平台的选择)

系统(例如，现有系统，兼容性问题)

环境(如法律/环境/安全/标准)

计划和资源(例如，固定计划，团队)

5.5 系统分解策略

5.5.1 分解策略

程序分解结构

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

业务流程分解结构

主题域→业务事件和报告

5.5.2 分解步骤

(1)学科领域划分

(2)确定学科领域范围

(3)识别业务事件和报告

划分学科领域

·职责驱动的

·对目标的贡献

·划分结果

确定学科领域范围

·为每个主题域绘制上下文图

识别业务事件和报告

·业务事件

外部事件

客户发起

员工发起

内部事件

时间

地点

·业务流程

·业务活动

·业务步骤

·医疗服务子系统的业务事件

体检者申请体检

体检者中途改单

财务部门提交团队缴费情况

客服中心查询体检情况

维护人员管理体检项

系统通知体检者取报告

·医疗服务分系统的报告 ​

6 可行性分析和风险分析

6.1 可行性研究

为什么要进行可行性研究?

·要了解一个系统开发项目是否可以完成:

...这可能吗?

...这合理吗?

·提出可能的替代解决方案。

·为管理层提供足够的信息以了解:

项目能否完成

最终产品是否会使其预期用户受益

备选方案是什么(以便在后续阶段进行选择)

是否有首选的替代方案

可行性研究内容

·现行组织体制

利益相关者、用户、政策、功能、目标……

·现行制度的问题

功能、性能上的不一致、不足……

·新系统的目标和其他要求

需要解决哪些问题?

涉众想要实现什么?

·约束

·可能的选择

解决问题的不同业务流程

不同层次/类型的计算机化解决方案

·备选方案的优缺点

探索可行性-----“PIECES”框架

性能(Performance)(当前的吞吐量和响应时间是否足够?)

信息(Information)(最终用户和管理人员是否获得及时、相关、准确和有用的格式信息?)

经济(Economy)(当前系统提供的服务是否具有成本效益?/会降低成本和/或增加收益吗?)

控制(Control)(是否有有效的控制措施防止欺诈，并保证信息的准确性和安全性?)

效率(Efficiency)(当前系统是否充分利用了人力、时间、表格流等资源?)

服务(Services)(当前服务可靠吗?它们是否灵活且可扩展?)

四种可行性

技术可行性

以目前的技术，这个项目可行吗?

有什么技术风险?

技术的可用性

经济可行性

在资源有限的情况下，这个项目可行吗?

开发和运营成本是多少?

有什么好处?

好处值得付出代价吗?

计划的可行性

有可能及时找到解决方案吗?

拖延的后果是什么?

日程安排有什么限制吗?

这些约束条件能够满足吗?

社会可行性

如果开发了这个系统，它会被使用吗?

潜在的劳工反对意见?

管理者反对吗?

组织冲突和政策?

社会可接受性?

法律方面和政府法规?

6.2 风险分析

项目的主要风险

不清楚的需求

不断变化的需求

不稳定的产品或设计

紧迫的项目和不可达到的里程碑

肤浅的或不准确的工作量和影响估计

没有跟踪的项目计划

没有控制的分包

减轻风险的技术

组合管理（portfolio management）中评价与选择的技术

在需求分析阶段就评估变更风险

项目管理要适应不确定性和变更

开发过程适应不确定性和变更

架构和设计适应不确定性和变更

严格的和系统性的变更管理

风险核查清单

项目里有没用过的新技术吗？

完整定义了与其他系统或组件的接口吗？

设计依赖于不切实际或过于乐观的假设吗？

考虑了系统的行为（性能等）吗？

外部组件质量达标了吗？

使用了专利、版权或专有技术吗？其法律或间接成本确定了吗？

使用了什么开源软件，用的是什么协议？

有分包商（或外包，离岸外包）吗？

与供应商签订的是什么样的合同？供应商承担什么样的风险？

对于关键零部件是否有替代供应商？

Chapter 3 需求获取（Requirements Elicitation）

1 关于需求获取

1.1 需求获取的定义

·需求获取的定义

需求获取是“通过与客户、系统用户和其他与系统开发有利害关系的人交流来发现系统需求的过程”。

软件需求获取是需求工程的主体。

软件需求获取是软件开发过程中最困难、最关键、最易出错及最需要交流的阶段。

需求获取三个阶段:

阶段1——识别相关的需求来源

阶段2——抽取现有需求

阶段3——开发新的和创新的需求

阶段1——识别相关的需求来源

·不考虑相关的需求来源会导致不完整的需求规范

·识别未知相关需求来源的过程

第一步:确定潜在的需求来源

第二步:评估需求来源的相关性

阶段2——抽取现有需求

·从涉众处引出现有需求

访谈，问卷调查，观察

·从文档中引出现有的需求

基于视角阅读

·从现有系统中引出现有需求

使用或观察系统

采访系统的涉众

分析系统文档

阶段3——开发新的和创新的需求

·开发新的和创新的需求是一个创造性的过程

·可以通过运用创造性技巧(头脑风暴，奥斯本检查表)来支持

·将持有不同观点的不同利益相关者聚集在一起

需求来源

·涉众/干系人（Stakeholders）

·业务过程（Business Process）

·组织规章与制度（Organization provisions）

·现有系统（Existing System）

用户手册（User manual）

数据样本（Data samples）

接口描述（Interface description）

报告样本（Report samples）

Screen-spot

干系人/涉众(Stakeholders)

·涉众是积极参与项目、受项目结果影响或能够影响项目结果的个人、团体或组织

·举例：

用户一关心新系统特征和功能

设计师一想要构造完美的系统，尽量重用已有的代码

系统分析师一想要获取正确的需求

培训与用户支持人员一确保系统可用和可管理

业务分析师一想确保“我们做得比竞争对手好”

技术文档作者一为系统准备用户手册及其他相关文档

项目经理一希望按时、按预算、按目标完成项目

客户一为新系统买单的人

业务过程(Business Process)

·对现有业务过程的分析有助于识别业务问题并加以改进

找出并列举当前业务过程中的问题

分析问题的本质（遗漏？不好用？新需求？）

分析改进的机会

分析改进的实质 （自动化？流程改进？）

组织规章与制度(Organization Provisions)

·分析规章制度有益于确定业务规则和约束条件

业务规则：描述对业务过程的要求，如系统支撑的业务过程的结构、控制、行为效果

约束: 对系统开发过程的管理限制，主要涉及经济、政治、技术和环境四个方面，具体包括项目资源、时间、目标环境及系统本身。

·组织规章中往往还涉及过程自动化、工作流、关系、交互等内容

现有系统(Existing system)

·分析现有系统有助于了解未来系统的工作数据

数据对象

数据关系

数据库结构与系统结构

系统报告

1.2 需求获取过程

·确定需求获取的内容

·确定需求获取的来源

·确定需求获取的方法

·执行获取

·需求获取的内容：在项目范围之内，所有为客户创建解系统必需的信息。

需求本身：涉众的问题、观点、已知业务、看法、期望目标、态度等

业务描述：需求的问题域特征，现实世界的业务运行状况

环境和约束：系统部署时环境和约束

需求获取技术

·传统方法：

访谈法(interviews)

调查问卷法（questionnaires)

文档阅读法（perspective-based reading）

观察法(observation)

原型法(prototyping)

头脑风暴法（brainstorming）

·非传统方法：

基于知识的方法

基于视点的方法

评论（数据）分析法

1.3 需求获取中的需求工件

·Elicitation Notes(获取笔录)

用户需求、关于问题领域的知识和对解决方案的约束

可能组织不力、冗余、遗漏和不一致

可采用各种形式：音频、视频、文字和图解

·正式文件

用例图和用例规范

·需求获取的常见困难

1.大多数情况下，系统相关的人员无法陈述自己的需要

2.许多用户难以解释所执行的任务，更难解释为什么执行这些任务

3.相关人员经常指定解决方案而不是需求

4.不同的相关人员可能持有相互矛盾的观点

5.相关人员经常出于抵制变更而拒绝新系统

6.需求可能过多

7.需求随着时间而变化

·需求心理学常见现象

1.言过其实心理：说的流程是一种理想化流程，与实际情况严重不符

2.越俎代疱心理：对非自己处理的流程津津乐道，根据自己的理解、想像进行肯定的描述

3.非正事心理：一直忙于工作，无瑕配合需求调研

4.抗拒心理：新系统对其利益有损，故意不配合

5.推卸责任心理：装不知，说没需求

·需求获取结束的规律

如果用户不能想出更多的用例

如果用户想出的新用例可以从已有的用例获得

如果用户讨论原先已讨论过的问题

如果所提出的新需求比已确定的需求的优先级都低

如果用户提出对于将来产品的需求

2 需求获取技巧

2.1 访谈（Interviews）

2.1.1 访谈

·访谈：需求工程师或分析师与不同的涉众讨论系统，并建立对其需求的理解

·两种访谈

结构化访谈：

访谈官已经准备好了问题，不会偏离

非结构化访谈：

没有准备好问题目录

两种问题类型

封闭式问题

需求工程师寻找一组预定义问题的答案

“布尔问题”：是或否，对或错

开放式问题

没有预定义的议程，需求工程师以开放的方式讨论涉众对系统的需求

·示例：需求引出的封闭问题

汽车导航系统应能够与移动电话等其他终端设备交换数据。与这些设备交换数据应支持哪种通信方式？

串行接口

通用串行总线（USB）接口

红外接口

蓝牙技术（一种无线通信的标准）

无线局域网（LAN）

存储卡（如SD）

·示例：需求引出的开放问题

描述理想的汽车安全系统。系统如何识别驾驶员的威胁，以及如何对检测到的威胁做出反应？

2.1.2 访谈执行流程

准备

目标、参与者、时间、地点、问题

执行

开场白：解释目标，介绍问题

工作元素：

简单模型、使用场景、休息、记录结果

Finalization(总结、确认)

Follow-up(后续)

2.1.3 优点和缺点

优点:

操作条件简单，经济成本低

获取各种信息，如事实、问题、观点、态度、信念等

易于与利益相关者建立友好关系，提高参与热情

缺点:

巨大的时间成本，限于时间和地区

依赖于沟通技巧

使用时间：任何项目

2.1.4关键成功因素

沟通技巧

没有引导性问题

明确定义并传达目标

术语

了解访谈伙伴

避免群体思维效应

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 观察类型

两种类型的观察

直接观察

观察者观察利益相关者

民族志观察

观察员花很长时间与利益相关者一起积极参与他们的工作

2.4.2 观察过程

准备

观察目标、预期结果、观察对象或系统

执行

观察指南

不要质疑观察到的活动

寻求利益相关者的信心

捕捉细节（通过民族志观察更容易）

立即记录观察结果

保持客观

检查活动的真实性

通过询问支持观察

文档格式

文本：缺点：观察者在写问题时分心

视频：录制通常被认为是不愉快的，分析很耗时

音频：其他格式的替代或补充

后续

处理记录（需要使不参与观察的人员能够理解）

使文档与利益相关者保持一致（减少错误解释的风险）

2.4.3 优点和缺点

优点：

非常适合满足现有需求

有助于理解复杂的合作过程

缺点：

需要大量资源

分析工作取决于结果的记录方式

2.4.4 关键成功因素

利益相关者合作意愿

结果处理（结果在处理之前无法理解）

观察者的客观性（尽可能客观地记录结果）

可观察性（观察的努力，需要利益相关者做出多少解释）

2.5 原型（Prototyping）

2.5.1 什么是原型？

原型是一个软件系统的初始版本，用于演示概念、尝试设计选项，通常用于了解有关问题及其可能解决方案的更多信息

帮助开发人员、用户和客户更好地了解系统需求

帮助澄清和完成要求

对“当我看到（或不会看到）它时，我会知道”的态度做出早期反应

有效解决“是的，但”和“未发现的废墟”综合症

帮助发现新功能、讨论可用性并确定优先级

2.5.2 原型类型

开发方法

探索性：从有缺陷的需求开始，然后不断调整和修改

实验性：从明确定义的需求和模糊实现方法开始，实现效果和可行性

进化性：逐步转化为产品，为用户提供更快速的工作系统（从更容易理解的需求开始）

构建技术

横向：关注一层功能需求

垂直：真实系统的一部分

2.5.3 优点和缺点

优点：

探索需求和验证需求

及早发现不确定性并降低风险

缺点：

客户要求快速交付产品

分析工作取决于结果的记录方式

用户假设可能包含在内

巨大的开发成本

2.6 头脑风暴（Brainstorming）

2.6.1什么是头脑风暴？

在开放的氛围中收集或交流利益相关者的想法，没有人会因为他们的想法而受到嘲笑，也没有人会拒绝或批评他们的想法。

使用时间：在项目早期，尤其是在

“地形”不确定

这类应用的专业知识很少

创新很重要（例如，新颖的系统）

想法很少或太多

2.6.2头脑风暴过程

风暴阶段

产生尽可能多的想法（数量，而不是质量）——狂野是好的！

冷静阶段

从想法中过滤(结合、澄清、优先考虑、改进……)以保留最好的想法——可能需要一些投票策略

·奥斯本检查表（Osborn Checklist）

以下问题支持在定义的起点方面的创造性：

用于其他用途？（Put to other uses?）（按原样使用的新方法？修改后的其他用途？）

适应？（Adapt?）（还有什么是这样的？这意味着什么其他想法？）

修改？（Modify?）（改变意思、颜色、动作、声音、气味、味道、形状、形状？其他变化？）

放大？（Magnify?）（添加什么？更高的频率？更强？更大？更多成分？倍增？）

小型化？（Minify?）（减去什么？消除？更小？更轻？拆分？频率更低？）

代替？（Substitute?）（还有谁代替？还有什么代替？其他地点？其他时间？）

重新安排？（Rearrange?）（其他布局？其他顺序？更改节奏？）

颠倒？（Reverse?）（对立？将其倒转？将其倒置？将其翻转？）

结合？（Combine?）（混合、分类如何？组合目的？组合想法？）

·例：针对一个导航系统的奥斯本检查表

将导航系统用于其他用途？（Put navigation system to other uses?）

导航系统可用于在城市观光游览期间引导用户

调整导航系统？（Adapt the navigation system?）

可以调整导航系统中的路线显示

是否修改导航系统？（Modify the navigation system?）

路线可以投射到挡风玻璃上

放大导航系统？（Magnify the navigation system?）

导航系统可以控制并充当自动驾驶仪

反转导航系统？（Reverse the navigation system?）

导航系统可以学习驾驶员首选的路线

组合导航系统？（Combine the navigation system?）

导航系统可以与交通信息系统相结合，以便在路线规划时考虑交通拥堵

2.6.3优点和缺点

优点：

听取每个人的意见

鼓励创造力

有助于开发全新的系统

缺点：

许多想法（必须进行排序和排序）

难以营造良好的氛围

很难让每个人都参与进来

耗时

3 场景（Scenarios）

3.1 场景基础

·场景：场景描述了满足或未能满足目标（或一组目标）的具体示例。因此，它提供了关于一个或多个目标的更多细节。场景通常定义了为满足目标而执行的一系列交互步骤，并将这些交互步骤与系统上下文相关联。

·场景作为将需求置于上下文中的一种手段，是一种中级抽象

例：场景“自动制动操纵”中的上下文信息

演员：卡尔

角色：驾驶员

目标：保持安全距离

前提条件：汽车以超过50英里/小时的速度行驶

后置条件：未发生追尾，与前方车辆的安全距离已恢复

资源：到Peter汽车的距离

地点：高速公路上

3.2 场景类型

当前状态场景和期望状态场景

· 当前状态场景（指示性场景）

描述当前系统现实的具体方面或观点

·期望状态场景（可选场景）

也可用于描述所需的系统使用情况

·指示性和选择性场景是变更定义的重要驱动因素

指示性和选择性场景

正面场景和负面场景

·正面情景记录了实现目标的交互顺序

·负面情景记录了未能实现目标的交互顺序

可能允许或禁止负面情景

·正面场景和负面场景相辅相成

·负面场景举例

示例：允许的负面场景

克里斯将她的银行卡插入自动取款机的插槽。Chris输入她的个人身份号码和取款金额。ATM机通知Chris无法提取所需金额，因为金额超过了她的余额。

示例：禁止的负面场景

杰克把他的银行卡插入自动取款机的插槽。杰克输入他的个人身份号码和取款金额。自动取款机从杰克的账户中收取所需的金额。取款时，自动取款机的取款机制发生故障。

不当使用场景

·敌对行为者

·违背利益相关者的意图使用

示例：汽车安全系统的误用场景

另一辆车的驾驶员汤姆故意在卡尔的正前方超车，以使卡尔的车辆完全制动。在制动操作过程中，卡尔受伤。

描述性场景、探索性场景和解释性场景

·描述性场景

描述流程或工作流

目的：了解其操作

·探索性场景

记录替代实现，允许探索一系列不同的实现

·解释性场景

提供特定交互序列的背景信息和理由

例：描述性场景“输入目的地”

卡尔想开车去普利茅斯的联合街。卡尔使用汽车的导航系统找到最短的路线。他选择“输入目的地”。导航系统显示“请通过语音输入或手动输入所需目的地”。卡尔决定通过语音输入进入目的地，并说“普利茅斯”。由于背景噪音和他糟糕的发音，系统无法清晰地识别目的地。系统显示从语音输入中识别出的目的地，概率最高：“朴茨茅斯”。

系统还显示消息“您的条目无法被自动识别”以及以下选项：

（1）接受目的地（是/否）

（2）新条目（新）

（3）显示相似位置（相似）

（4）手动条目（按“M”键）

Carl说“相似”，系统列出位置“朴茨茅斯”、“普利茅斯”等。卡尔说“普利茅斯”，系统选择普利茅斯作为目的地。

例：探索性场景“进入起点”

卡尔想用汽车的导航系统开车到目的地。

第一个问题是，旅程的起点是否始终是汽车的当前位置，或者卡尔是否可以自己定义起点。自动选择起点避免了额外的用户交互，并支持快速导航。允许输入起点将有助于计算起点不是当前位置的路线。有了这个设施，该系统可以作为旅行规划的一种手段。例如，卡尔可以了解从巴黎到尼斯有多远，以及到达那里需要多长时间，而不受汽车当前位置的影响。第三种可能性是允许用户在功能“导航”（使用当前位置作为起点）和“导航”之间进行选择，并在用户菜单中输入“起点”。其中，“导航”功能将被指定为默认设置。

例：解释性场景“自动制动操纵”

由于两辆车之间的距离迅速减小，发生追尾的风险很高。快速变道可能会导致汽车打滑或旋转，因为汽车在高速公路上以超过55英里/小时的高速行驶。因此，在变道之前，必须降低车速。

因此，车载计算机启动自动紧急制动操作。由于防抱死制动系统确保汽车在制动操作期间保持可操纵性，卡尔可以在操纵过程中安全地变道。为了避免驾驶员被自动制动吓到，系统会通知卡尔紧急制动的启动。在恢复了与前面行驶的汽车的安全距离后，车载计算机将控制权交还给卡尔。系统通知卡尔控制权的移交，以便他准备接管控制权。

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

·实例场景

描述具体参与者之间的具体(现有的或设想的)交互序列

·类型场景

特定交互序列的具体参与者、输入和输出的摘要

·混合场景

实例级别描述的重要性内容

在实例级别描述未完全理解的内容，以避免早期抽象导致的错误

在类型级别描述的内容

实例级别描述的冲突或潜在冲突的内容

例：实例场景

卡尔想开车去普利茅斯的联合街。卡尔使用他的大众高尔夫的导航系统，牌照号为“E-IS-12”。卡尔在主菜单中选择“输入目的地”，输入目的地“普利茅斯联合街”，然后按下“计算路线”键

例：类型场景

驾驶员希望使用导航系统将车辆开到目的地。他进入目的地。系统计算从汽车当前位置到输入目的地的路线。

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

·系统内部（A类）场景

专注于系统内部交互

·交互（B类）场景

记录系统及其参与者（上下文中的人员和系统）之间的交互顺序

·上下文（C类）场景

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

记录与系统使用相关的其他上下文信息

·系统内部场景

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

·交互场景

交互场景记录了系统与其参与者（即系统上下文中的人员和系统）之间的交互。

“系统内部场景”示例

组件“导航控制”从“定位”组件请求GPS坐标。“定位”组件为“导航控制”提供坐标。组件“导航控制”调用组件“显示控制”并传递当前位置和目的地。

组件“屏幕输入”将路线参数传输到组件“导航控制”。然后，“导航控制”组件计算最终路线。

“交互场景”示例

参见描述性场景“输入目的地”

例：描述性场景“输入目的地”

卡尔想开车去普利茅斯的联合街。卡尔使用汽车的导航系统找到最短的路线。他选择“输入目的地”。导航系统显示“请通过语音输入或手动输入所需目的地”。卡尔决定通过语音输入进入目的地，并说“普利茅斯”。由于背景噪音和他糟糕的发音，系统无法清晰地识别目的地。系统显示从语音输入中识别出的目的地，概率最高：“朴茨茅斯”。

系统还显示消息“您的条目无法被自动识别”以及以下选项：

（1）接受目的地（是/否）

（2）新条目（新）

（3）显示相似位置（相似）

（4）手动条目（按“M”键）

Carl说“相似”，系统列出位置“朴茨茅斯”、“普利茅斯”等。卡尔说“普利茅斯”，系统选择普利茅斯作为目的地。

·上下文场景

上下文场景记录了系统与其参与者之间的直接交互以及与系统使用或系统本身相关的附加上下文信息，例如参与者之间以及系统的间接用户之间的交互。

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

·主场景

实现目标最常见的交互顺序

·可替换场景

可以执行的交互顺序，而不是主场景

实现与主要情景相关的目标

·例外场景

仅在发生特殊事件时执行交互顺序

导致无法满足与原始场景相关的一个或多个目标

·例：可替换场景

主要场景节选：

Step 11: ...

Step 12：驾驶员通过在电子地图上指示来选择目的地。

Step 13: ...

可替换场景节选：

Step 11: ...

Step 12a：驾驶员从目的地列表中选择目的地。

Step 13: ...

·例：例外场景

主要场景节选：

Step 12: ...

Step 13：系统确认成功进入目的地

Step 14：系统通知驾驶员成功计算到目的地的路线。

Step 15: ...

例外场景节选：

Step 13: ...

Step 14a：导航系统检测到其电源即将中断。

Step 15a：导航系统自动关闭。

3.3 用例

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

·用例包含：

上下文信息：

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

主场景

可替换场景

例外场景

·用例的组成

3.4 记录场景和用例

叙述性场景

·场景以自然语言记录

许多信息混杂在一起

·示例：叙述性场景节选

驾驶员辅助系统包括用于避免真实端部碰撞的（子）系统。该系统包括（1）距离传感器，该距离传感器（2）永久性地检查与前方行驶的车辆的距离（3），以避免即将发生的追尾碰撞。（4） 如果系统检测到距离低于安全距离但仍在临界范围之外，则会发出声音警告信号。（5） 或者，符号或消息可以显示在汽车驾驶舱的驾驶员显示器上。如果驾驶员在2秒后没有对警告做出反应，并且两辆车之间的距离仍然减小，（6）系统会降低车辆的速度。（7） 如果距离在任何时候低于行驶速度的四分之一，系统将启动紧急制动。

结构化场景

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

·两种结构化方法

场景步骤的枚举

交互作用序列的表格文件

每个参与者的列，列内的顺序

·场景的参考模板

提供具体和一般属性

项目特定适应

场景步骤的枚举

（1） 驾驶员启动导航系统。

（2） 导航系统确定汽车的当前位置。

（3） 导航系统询问所需的目的地。

（4） 驾驶员输入目的地。

（5） 导航系统识别地图的相关部分。

（6） 导航系统显示目的地区域的地图。

（7） ......

交互作用序列的表格文件

场景的参考模板

用例参考模板

·以与单个场景的参考模板类似的方式使用

属性

用于识别用例

出于管理目的

用于记录对上下文的引用

对于特定财产

有关更多信息

记录场景的十一条规则

1.使用现在时记录情景

2.在文档场景中使用活动语音

3.使用主谓宾句式

4.避免情态动词

5.将每个交互与其他交互明确区分开来（每个动作至少使用一个独立的句子）

6.为每个场景步骤编号

7.每个场景只有一个交互序列

8.从局外人的角度描述情景

9.明确说出所涉及的行为者

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

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

规则5：明确地将每个交互与其它交互分开

用户向在线商店提交一个搜索查询请求，从搜索结果中选择一项，并将其加入购物车。

改进定义：（规则6：为每个场景步骤加编号）

（1）用户向网上商店提交查询请求；

（2）系统显示搜索结果列表；

（3）用户从列表中选择一项商品；

（4）用户将商品加入购物车；

（5）用户重复步骤（1）~（4）直到结束购物。

规则7：每个场景只包含一个交互序列

规则8：从外部视角描述场景

规则9：明确地命名相关参与者

规则10/11：明确陈述目标并关注于说明目标是如何被满足的

序列图

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

一组角色之间的消息交换

用于分组消息的组合片段

使用“break”和“alt”组合片段的异常情况

使用“alt”组合片段的替代方案

·序列图的基本建模元素

·在序列图中记录场景

·序列图中的可替换场景和例外场景

活动图

·活动图是控制流程图

·节点表示活动的执行

·备选控制流通过决策节点表示

·活动图特别适合记录主场景、可替换场景和例外场景的相互关系和执行条件

·UML活动图的重要建模元素

·场景控制流程文件

用例图

·记录用例之间的关系

·用例图的建模元素

参与者：代表系统或系统边界之外的人

用例

系统边界：将系统与其环境分隔开

参与者和用例之间的关系：表示该参与者在用例中与系统交互

用例之间的关系：

概括、扩展、包括

参与者之间的泛化

·用例图的重要建模元素

·在示例中对用例图的元素进行建模

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

Chapter 4 需求分析及建模（Requirements Analysis）

1 需求分析和建模的基础知识

需求分析

充分理解引出的要求

查找缺陷并将其反馈给利益相关者，以通过谈判过程解决问题

不必要的要求？

要求不完整？

要求不一致？

重叠要求？

要求冲突？

需求的优先级

需求的风险

创建解决方案（需求模型）

1.1 需求分析

·如何分析？

·问题清单

·相互作用矩阵

·需求建模方法：

SA方法（Structured Analysis 面向结构的分析方法）

OOA方法（Object-Oriented Analysis 面向对象分析方法）

PDOA方法（Problem Domain Oriented Analysis 面向问题域分析方法）

1.1.1 问题清单

过早的设计

要求是否包括过早的设计或实施信息？

综合要求

需求描述描述的是单个需求还是可以细分为多个不同的需求？

不必要的要求

该要求是否是对系统的补充，而不是真正必要的？

使用非标准硬件

该要求是否意味着必须使用非标准硬件或软件？

符合业务目标

需求是否与需求文档简介中定义的业务目标一致？

需求不明确

不同的人会以不同的方式引导需求吗？该要求的可能解释是什么？

需求现实主义

考虑到将用于实施系统的技术，要求是否现实？

需求可测试性

1.1.2 交互矩阵

·需求沿矩阵的行和列列出

对于冲突的需求，请填写1

对于重叠的要求，填写1000

对于独立的要求，请填写0

·记录需求分析结果的方法

可视化，更好的记忆

抽象系统的结构和行为，降低复杂性

支持问题理解和解决

1.2 需求建模

一般建模过程

分解——抽象——消除矛盾

分解：自上而下

抽象：自下而上

消除矛盾

“资产管理人员希望资产管理流程严谨，所有采购的设备在报销前要先入库；采购人员则希望报销流程简化。”

基于业务流程的分解

基于程序结构的分解

基于场景的分解

基于数据的分解

方法论

程序=数据结构+算法（数据、算法）

结构分析（SA、数据格式、数据处理）

面向对象分析（OOA、数据、参与者、事件）

面向问题领域分析（PDOA）

工具

ERD, DFD, DD

UML（活动图、用例图、类图、对象图、序列图、状态图）

需求工程中可能用到的UML图

模型的视角

1.3 需求谈判

·冲突：如果不同利益相关者（或利益相关者群体）对系统的需求和愿望相互矛盾，或者某些需求和愿望无法考虑。

例：

一组利益相关者要求使用雷达传感器进行距离测量。另一组利益相关者则要求提供超声波传感器。

利益相关者要求在平视显示器上显示驾驶员的安全相关信息。其他利益相关者认为这会降低驱动力，因此拒绝这一要求。

·未解决的冲突可能阻碍利益相关者对系统的接受，或者冲突甚至可能导致开发项目失败。

·冲突可以成为新思想的来源和创新需求的发展。

·需求谈判的目标是通过识别冲突、分析冲突和解决已识别的冲突，在协议维度上取得进展。

2 结构化分析和建模

2.1 Idea

·模块化：将一个大的程序按功能分拆成一系列小模块

降低程序设计的复杂性

提高模块的可靠性和复用性

缩短产品的开发周期

易于维护和扩展

·成功的关键：

基于易变和稳定

单一职责

类或者函数应该只做一件事，并且做好这件事

·结构建模是用不同符号对数据流进行建模的过程。

数据建模——实体关系图

功能建模——数据流图

行为建模——状态图

2.2 数据建模——实体关系图（ERD）（Entity-Relationship Diagram）

实体

关系

属性（实体/关系的属性）

ERD中属性的图形表示法

基数约束

ERD中基数约束的图形表示法

ERD建模步骤

步骤1：从给定信息中识别实体

步骤2：决定实体的标识符

步骤3：建立实体之间的关系

步骤4：添加详细信息，如属性、基数等

ERD建模举例

例如：大学实行学分制，学生可根据自己的情况选课。每名学生可同时选修多门课程，每门课程可由多位教师主讲；每位教师可讲授多门课程。

2.3 功能建模——数据流图（DFD）（Data Flow Diagram）

元素

外部实体

流程

数据流

数据流

分层数据流图

上下文关系图

0级图

一级图

......

DFD的绘制过程

绘制上下文图(顶层图)

根据业务事件为每个事件绘制DFD片段(0层图)

合并碎片(0层图)

逐步细化到函数(1层，2层，……)

数据字典

数据字典是一个储存库，包含软件使用和产生的所有数据对象的描述，其中也包括DFD当中数据流和数据存储的定义。

数据字典的任务是对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。

·数据字典的例子

2.4 行为建模——状态图

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

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

·有限自动机是五元组(Q,∑ , δ, q0, F)

DFA & NFA

DFA确定有限状态自动机

NFA非确定有限自动机

Mealy和Moore自动机

有限状态传感器（FST）通过输出字母Γ增强FA和一个输出函数Χ.

Mealy自动机：自动机的输出取决于当前状态和输入符号

Moore自动机：自动机的输出仅取决于当前状态

Mealy自动机和Moore自动机

状态图

状态图增强了有限自动机：

定义状态和转换的操作

定义条件交易

状态的分层细化

建模并发行为

行为

条件

子状态

默认状态

并发

ti：事件

2.5 小结

导航系统示例

数据透视图

实体关系图

功能透视图

数据流图

行为视角

状态图

例：导航系统要求

位置和方向的计算：

R1系统应根据GPS数据、车轮旋转和横摆率确定车辆的当前位置和方向。

目的地输入：

R2系统应允许输入地址以指定行程目的地。

R3系统应允许从存储的目的地列表中选择目的地。

路线计算：

R4系统应计算从车辆当前位置到选定目的地的最快路线。

R5如果驾驶员偏离计算的路线，系统应重新计算到达目的地的路线。

导航到目的地：

R6在行车过程中，系统应提供声音和视觉驾驶指示。

·数据透视图

·功能透视图

·行为视角

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

3 面向对象的分析和建模

3.1 Idea

·面向对象分析将系统视为一组对象，这些对象通过相互协作来完成所需系统的任务

·面向对象建模根据对象及其提供的服务对系统需求进行建模

领域建模——类图

功能建模——用例图

动态建模——序列图、状态图

3.2 领域建模——类图（Class Diagram）

·类（Class）

类似对象集

表是对象，表是类

Class means "Type"

·属性（Attributes）

用于说明类的特性

·关联（Association）（类之间的关系）

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

·聚合和合成（Aggregation and Composition）

整体-部分关系

·组成（Composition）

强大的整体-部分关系（部分只有一个所有者，不能独立存在）

·泛化关系（Generalization relationships）（将子类与超级类关联）

子类的实例是超级类的实例

子类必须可以替代其超级类

子类定义其他属性和操作

·辅助元件（Auxiliary elements）

导航箭头

派生属性

限定

约束

3.3 功能模型——用例图+用例规范

·用例图

参与者

系统之外的任何人或系统，并与系统交互

用例

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

关系

参与者之间：概括（generalization）

用例之间：包括（Include）、扩展（ extend）、概括（generalization）

参与者和用例之间：关联（association）

用例图示例：

3.4 动态建模——序列图、状态图

4 SERU（Subject Event Report UseCase主题活动报告用例）框架下的需求分析与建模

4.1 周期1：明确框架和分支

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

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

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

过程：

业务流程分析

业务实体分析

角色与使用场景分析

4.2 周期2：补充要求详情

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

数据字典

决策树、决策表

细化用例

书写用例规格说明

用例中的事件流分析

前后置条件

事件流的类型：基本事件流、扩展事件流、子事件流

业务用例与系统用例

·决策树

·决策表

5 其他需求的建模

5.1 接口要求

“哪里有分解，哪里就有接口”

描述要点：

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

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

设计约束：

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

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

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

5.2 全局设计约束

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

开发人员无法控制的强加限制

作为改进设计的一种方式，开发人员强加给自己。

用户界面和人为因素

硬件注意事项

拟用系统的硬件是什么？

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

性能特点

错误处理和极端条件

系统接口

质量问题

系统开发和修改

物理环境

资源和管理问题

5.3 全局非功能需求

定量方法

找到质量属性的可测量尺度

计算设计满足质量目标的程度

定性方法

研究质量目标之间的各种关系

权衡的原因等

性能度量（ Performance Measurement）

指标：响应时间、在一定时间间隔内处理/拒绝的事件数、吞吐量、容量、使用率、信息丢失、延迟、计算精度

例：

系统应能在峰值负载下每秒处理100笔付款交易

在标准工作负载中，CPU使用率应低于50%，后台作业的CPU使用率为50%

在95%的情况下，生成简单报告的时间应少于20秒

计算精度应至少为10-6

可靠性度量（Reliability Measurement）

指标：平均故障时间（MTF）、缺陷率

例：

系统故障率应小于每1000小时运行1次故障

每1000000个事务中不超过1个会导致需要重新启动系统的故障

可用性度量（Availability Measurement）

指标：MTBF/（MTBF+MTTR）

MTBF：故障间隔时间

MTTR：故障后恢复操作所需的时间长度

例：

系统应满足或超过99.99%的正常运行时间

每运行1000小时，系统不可用时间不得超过1小时

95%的时间发生故障后，需要不到20秒的时间重新启动系统

安全性度量（Security Measurement）

两项措施：

抵御未经授权的使用尝试的能力

在遭受拒绝服务攻击（抵抗DoS攻击）时，继续向合法用户提供服务

指标：

身份验证成功率

抵抗已知攻击（待列举）

找到钥匙所需的概率/时间/努力/资源

检测攻击的概率/时间/资源

攻击期间仍可用的可用服务百分比

成功攻击的百分比

密码和会话的寿命

加密级别

例：

应用程序应在允许其使用其功能之前识别其所有客户端应用程序

应用程序应确保官方人力资源和工资数据库中员工的姓名与员工社保卡上打印的姓名完全匹配

应在10秒内检测到至少99%的入侵

可用性度量（Usability Measurement）

指标：使用率、每个用户类别的满意度

例：

五分之四的用户应能在系统介绍2小时后的5分钟内预订客人

在使用3个月后，至少80%的受访客户对系统的满意度应为7或更高，评分为1-10

稳定性度量（Robustness Measurement）

指标：无效输入故障百分比、极端负载下的最低性能、服务降级程度

例：

磁盘崩溃时估计的数据丢失率应小于0.01%

当满足所有要求时，系统应能处理多达10000个并发用户，并能处理多达25000个具有浏览功能的并发用户

可维护性度量（Maitainability Measurement）

指标：耦合/内聚度量、圈复杂度、修复缺陷的平均时间、添加新功能的平均时间

例：

代码的圈复杂度不得超过7

任何对象中的任何方法都不能超过200行代码

新版本的安装应保持所有数据库内容和所有个人设置不变

Chapter 5 需求规范（Requirements Specification）

1 需求规范的基本原理

要求与规范

域属性：

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

需求：

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

规格：

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

1.1 动机和目标

文件的重要性

持续

共同参考

促进沟通

支持新员工的培训

促进客观性

保留专家知识

有助于反思问题

需记录的信息

就要求达成一致

冲突的替代解决方案

头脑风暴结果

头脑风暴结果

决策依据

关于变更请求的决定

关于冲突的决定

与文件规则/指南的偏差

不同的利益相关者观点

人工制品的演变

已确定的矛盾

已识别的错误

有关上下文的信息

检查结果

访谈结果

优先事项

活动负责人

…

1.2 文件与规范

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

需求规范是一种特定的文件。只有当需求文件符合为项目定义的规范规则和指南时，指定需求才是指定需求。

软件需求规范（SRS）

是具有一定法律效力的合同文档

清楚地描述软件在什么情况下，需要做什么，以及不能做什么

以输入/输出、输入到输出之间的转换方式来描述功能性需求

描述经过干系人磋商达成共识的非功能性需求

一般参考需求定义模板，覆盖标准模板中定义的所有条目

作为后续的软件评估依据和变更的基准

1.3 要求的质量标准

完整：无遗漏信息

可追溯：来源、演变、影响和使用

正确：由利益相关者确认

明确：单一有效解释

可理解：相关利益相关者易于理解

一致：无矛盾

可验证：明确客观的验收标准

评级：已知相关性和稳定性

最新：反映系统的当前状态及其上下文

原子：单一的相干事实

例：不明确的要求

为了验证自己，驾驶员输入电子卡和PIN。如果无效，则发动机无法启动。

歧义：“如果无效”是指卡、PIN还是两者？

例：未规定要求的可验证性

可验证：R1：对于约束C14（系统负载曲线）规定的最大负载的80%至90%之间的系统负载，系统必须在2s内至少80%的情况下响应事件ES-2，并且在所有情况下最迟在3s内响应。

不可验证：R2：系统正常响应时间应小于2s。

?: “正常响应时间”是指什么？什么类型的回应？哪个系统负载以及在什么条件下响应时间可能高于2s？

例：非原子要求

用户必须登录到系统，才能通过订单ID或客户数据库中的全文搜索来搜索特定订单。

非原子性：需求不是原子性的，因为它描述了用户身份验证以及搜索订单的不同方式。

1.4 要求集的质量标准

一组需求人工制品的质量取决于单个需求人工制品质量以及满足为该组需求人工品定义的质量标准。

完整性：无遗漏要求，所有要求均完整记录

一致性：

没有不一致的描述/术语

真实世界方面没有不一致的财产

没有不一致的行动规范（逻辑或时间冲突）

可修改性和可读性：

文档样式和结构

存在问题的需求描述实例

含糊的需求描述：

“工资总额由上一条记录获得“

“所有客户都具有同一控制域”

错误的需求描述:

“所有系统将九月作为财政年度的起始时间”

不完整的需求描述：

出错信息显示在屏幕的第24行

矛盾或不一致的需求描述:

“C=A+B’; “C=A-B”

无法测试的需求：

“系统应具有友好的界面”

1.5 规定要求的不同方式

非正式的

使用自然语言（如英语、汉语、法语、德语等）的文件要求

使用参考模板记录要求

半正式的

使用图（如DFD、ERD、类图、序列图等）记录需求。

正式的

使用数学语言（如Z、VDM、表格表达式等）编制文件要求。

2 非正式规范（Informal Specification）（自然语言规范）

自然语言

文本描述

需要写作技巧

应该组织良好

优点：

通用、灵活、易懂

缺点：

功能需求的三个视角（数据、功能和行为）常常混杂在一起

功能和质量属性常常混杂在一起

有歧义

术语的模糊性：定义模糊，同一件事在规范中可以用多种不同的方式表达

缺乏模块化

例1：自然语言中的功能需求

R2：如果窗户上的玻璃破裂探测器检测到窗格玻璃已损坏，系统应通知安全服务部门。

结构：玻璃破裂探测器、窗户、窗格、系统、安全服务

功能：检测、通知安全服务

行为：如果[…]损坏，则通知[…]

例2：功能与质量的结合

R2.1如果窗户上的玻璃破裂探测器检测到窗格玻璃已损坏，系统应最迟在2秒内通知安全服务部门。

功能和质量要求分离后

R-F-17：窗户处的玻璃破裂检测器应检测玻璃窗格是否损坏

R-F-18：如果探测器检测到窗格玻璃损坏（参见R-F-17），系统应通知安全部门

R-Q-2：系统应在检测到损坏后2秒内通知安全服务部门（见R-F-18）

歧义

词法歧义

词汇歧义是由同音异义词（具有不同含义的单词）和/或同义词（具有相同含义的不同单词）引起的。

如：Trunk

Journey/tour/trip

语法歧义

可以为一个句子分配不同的语法树

用户使用访问卡输入访问代码

解释（Interpretation）1：输入访问代码和访问卡

解释（Interpretation）2：使用访问卡进入访问代码

语义歧义

多个允许的解释

如果（1）汽车的窗户损坏，（2）汽车的内部监控系统检测到仪表，或（3）汽车的门在没有汽车钥匙的情况下打开，安全系统应发出警报

解释（Interpretation）1:[（1）和（2）]或（3）

解释（Interpretation）2:（1）和[（2）或（3）]

语法歧义与语义歧义的关系

参考歧义

对具有多重解释的对象的引用此对象是什么

如：客户将门禁卡插入读卡器，并在键盘上输入个人识别码（PIN）。如果无效，系统应拒绝访问。

术语的模糊性

模糊的定义

如：所有中型车辆应配备导航系统。

避免歧义的技术1

词汇表

词汇歧义是由同音异义词（具有不同含义的单词）和/或同义词（具有相同含义的不同单词）引起的。

通过在术语表中明确定义规范中使用的不同术语的含义，可以减少甚至完全避免这种歧义。

词汇表的结构

避免歧义的技术2

句法需求模式

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

制定指南（Guidelines for specifying）

记录是艺术

没有简单固定的规则

每一份文件都可能产生巨大影响

句子结构、单词选择、图片选择…

各种细节必须处理好

多练习，多指定

在实践中，您将学到：

如何组织SRS

如何处理常见情况

如何避免常见错误

......

阅读很有帮助

没有人能够在阅读大量的艺术作品之前得到一个完美的作品。

为人们写作

·易于理解和沟通是首选

以可理解的方式表达

--标准和全面之间的权衡

组织内容和指导用户

--根据用例图或上下文图组织系统特性和需求

不要把无关紧要的东西放进去

·与SRS用户合作

作为一个用户，你会知道真正重要的事情

·没有固定规则

机械地遵守任何指南

--使用主动句

--对所有要求使用标准格式

--坚持使用语言

强制要求使用“shall”，期望要求使用“should”

--避免使用计算机术语

......

在清晰、简洁和指导原则之间进行权衡

·人们更喜欢列表

系统模式

列表、网格、图形、数字

·根据内容填写表格

不要盲目地穿着制服

·所有细节都在他们的位置

文件应组织良好，不得复制细节

·强化，无复制

引用或链接，而不是复制和粘贴

一些复制是必要的，例如强化

结构化语言规范

需求编写者的自由受到预定义的需求模板的限制。

所有要求都以标准方式编写。

描述中使用的术语可能受到限制。

其优点是保持了自然语言的大部分表现力，但对规范施加了一定程度的一致性。

基于表单的规范

功能或实体的定义。

输入的描述及其来源。

输出说明及其去向。

需要其他实体的指示。

前后条件（如适用）。

功能的副作用（如果有）。

例：胰岛素泵/控制软件/SRS/3.3.2

功能 计算胰岛素剂量：安全血糖水平

描述 计算当前测得的血糖水平在3到7单位之间的安全区域时要输送的胰岛素剂量。

输入 当前糖读数（r2），前两个读数（r0，r1）传感器的源电流糖读数。其他来自内存。

输出 CompDose–要输送的胰岛素剂量

目的地 主控制回路

动作： 如果血糖水平稳定或下降，或者如果血糖水平在增加但增加率在降低，CompDose为零。如果糖水平在增加，并且增加的速度在增加，那么CompDose的计算方法是将当前糖水平与之前的糖水平之差除以4，然后四舍五入。如果结果四舍五入为零，则CompDose设置为可输送的最小剂量。

需要 两个先前的读数，以便计算糖水平的变化率。

前提条件 胰岛素贮存器至少含有允许的最大单剂量胰岛素。。

后置条件 r0替换为r1，然后r1替换为r2

副作用 无

3 半形式化规范--图形模型

当您需要显示状态如何变化或需要描述一系列动作的位置时，图形模型非常有用

UML

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

UML 2.x中的十三种图类型

用例图

类图

行为图

状态图

活动图

交互图

序列图

协作图

实施图

组件图

部署图

对象关系图

时序图

复合结构

包装示意图

交互图

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

需求工程RE相关图

用例图

类图

活动图

顺序图

状态图

4 形式规范（Formal Specification）

4.1 形式规范基础

形式规范

软件明确规范技术

将非数学描述（图表、表格、自然语言）翻译成形式规范语言

它代表了对系统高级行为和财产的简明描述

定义良好的语言语义支持规范的形式推导

形式规范的目标

完整、一致、简洁、明确的规范

有效的规范准确地说明了用户想要什么

形式语义允许各方之间可靠的通信

允许正式验证

案例研究显示了多种优势

使用形式规范

形式规范涉及在软件开发的早期阶段投入更多的精力

这减少了需求错误，因为

强制对需求进行详细分析

不完整和不一致可以被发现和解决！！！

因此，节省的金额为

减少了因需求问题导致的返工

形式规范的开发成本

形式化方法

形式化规范是被称为“形式化方法”的更一般的技术集合的一部分

这些都是基于软件的数学表示和分析

形式化方法包括

形式规范

规范分析和证明

转型发展

程序验证

接受形式化方法

形式化方法并没有像以前预测的那样成为主流软件开发技术

其他软件工程技术已经成功地提高了系统质量。因此，减少了对正式方法的需要；

市场变化使上市时间成为关键因素，而不是错误计数低的软件。正式方法不会缩短上市时间

形式方法的范围是有限的。它们不太适合指定和分析用户界面和用户交互

形式化方法很难扩展到大型系统

形式化方法的使用

形式化方法的实用性有限

它们的主要好处是减少系统中的错误数量，因此它们的主要适用领域是关键系统

在这一领域，使用正式方法最可能具有成本效益

形式规范工具概述

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

语法

定义特定表示法用于表达需求规格说明

一般以标准集合论和谓词演算等数学表示法为基础

语义

定义将用于描述系统的元素和/或对象

语义指明如何用这个语言来表示系统需求

关系

定义一组规则

指明哪个对象恰好满足什么样的系统规格说明

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

基于模型的表示法

以进程代数为基础

基于代数的方法

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

优势

以数学理论为基础，能够对规格说明的正确性、完整性和一致性进行形式化检查，还能够排除规格说明中的二义性

不足

有一些需求是很主观的，很难用形式化方法建模

形式化方法虽然提升了系统需求的可信度，但并没有解决需求如何获得以及需求模型如何构造等问题

虽然已有一些形式化建模工具，但应用面还不是很广泛，主要应用在嵌入式等安全攸关领域

使用代价高

4.2 Z规范

Z语言,是在20世纪70年代初由牛津大学的一个计算机程序研究组提出并根据两位数学家泽梅罗和弗兰科尔(Zermelo-Fraenkel)的姓名首字母ZF命名的一种书写软件规格说明的方法。

Z语言的理论基础是集合论和一阶逻辑，它将事物的状态和行为用数学符号进行形式化表达，从而为编写正确的计算机程序和验证可靠计算机软件系统提供严格的数学模型和理论依据。

20世纪80年代末，ISO开始对Z语言制定相关规范。

2002年，ISO正式颁布了ISO/IEC 13568：2002(Information technology---Z formal specification notation---syntax,type system and semantics)标准

2007年，ISO对该标准进行了修订，并形成了ISO/IEC 13568：2002/Cor.1:2007标准

2013年，ISO对这个标准又进行了技术审核。

《Z 规范及其使用方法》 赵正旭

航天测控实时三维可视化平台---太空电子沙盘系统TDS

在载人航天工程、探月工程、深空探测工程的实时可视化飞行控制过程中发挥了举世瞩目的重要作用

2009 火星探测可视化

2010 火星他测飞行控制指挥任务

2011 天宫一号发射飞行控制指挥任务

2013 神州十号载人航天可视化

......

Z规范

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

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

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

状态模式

每个系统只有一个状态

说明：若干个状态变量

谓词：定义在状态变量上的约束

操作模式

每个系统可有若干个定义在状态上的操作

说明：是否改变了状态？有哪些输入变量？有哪些输出变量？

谓词：输出变量的定义

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

全局量的声明：

给定的集合：[ ]

数据类型定义：

停车提示 = 可停 | 停车场满

常量声明：

C停车场容量：Z /Z:整数集合/

C停车场容量>=0： /常量约束/

全局变量声明：无

状态模式定义：

状态变量初始化：

SV停车数量= 0

操作模式定义：

Z说明例2---电梯控制系统

全局量的声明：

给定的集合：[Button]

数据类型定义：

常量声明：

全局变量声明：

状态模式定义：

状态变量初始化：pushed = Φ

操作模式定义：

4.3 四变量模型

输入变量

输出变量

控制变量

监视变量

整个系统(硬件&软件)是监视变量和控制变量之间的关系(REQ和NAT)

输入设备是监视变量和输入变量之间的关系IN

输出设备是输出变量和控制变量之间的关系OUT

软件系统是输入变量和输出变量之间的关系SOF

REQ和NAT对应的是系统需求文档的主要内容

IN和OUT合起来是系统设计文档的主要内容

输入变量和输出变量之间的关系对应的就是软件需求文档的主要内容。

4.4 表格表达式（Parnas表）

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

行和列将表达式分隔为大小写

每个表条目指定某些情况的结果值或部分标识某些情况的条件

有十多种表类型。

一个表达式通常可以用几种表类型表示。文档管理员的目标是选择（或创建）一种表格式，为该表达式生成一种简单、紧凑的表示。

什么是表格表达式（Tabular Expression）？

不同的名称：

表格表达式或表格或Parnas表格

本质上：

以表格形式表示数学表达式；

内容：

定义关系或函数；

应用：

可用于简明地记录软件系统；

优势：

可读；简明的毫不含糊的便于检查

例：

TE（表格表达式Tabular Expression）的发展

第一次介绍：

1977年，美国NRL赞助的项目，David Parnas介绍了表格来规定A-7E要求；

广泛使用：

许多项目将表格作为记录软件系统的正式方式；

1个成功案例：达林顿核电站

SCR方法——规定要求的3种表格类型；

特别是对于实时系统；

正式定义：

直观地→10正式定义的表类型→其他正式模型→新的数学模型

正向表

反向表

决策表

决策表对于表示一个域是一个元组（可能是不同的类型）的函数或关系很有用。该表的一个维度将领域元组的元素逐一列出。

向量表

矢量表对于表示一个范围为元组（可能是不同的类型）的函数或关系很有用。表的一个维度将范围元组的元素逐一列出。 ​

5 SRS标准模板

国际标准

IEEE Std 830-1998

国家标准

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

军队标准

国际标准

IEEE Std 830-1998

组织/机构

示例说明

Atlee, Berry, Day, Godfrey

U Waterloo

CS445 (Winter 2011)

IEEE 830-1998 Standard - Section 1 of SRS

IEEE 830-1998 Standard - Section 2 of SRS

IEEE 830-1998 Standard - Section 3 of SRS

IEEE 830-1998 Standard - Templates

示例说明

国家标准

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

Chapter 6 需求验证（Requirements Verification）

1 需求验证（Requirements Verification）的基本原理

1.1 动机和目标

动机

质量保证目标

避免错误传播

避免因需求缺陷引起的法律问题

质量保证（QA）

建设性：在创建这些工件的过程中，使用一些技术来防止开发工件中的缺陷。

分析：使用一些技术来检查开发工件创建后的质量

目标

检查活动的输出是否符合规定的质量标准

检查活动的输入是否符合规定的质量标准

检查活动的执行是否符合流程定义和活动指南

验证不足的成本

1.2 验证（Verification）与确认（Validation）（V&V）

验证（Verification）和确认（Validation）的定义区别

验证（Verification）：我构建的系统正确吗？（Am I buiding the system right?）

确认（Validation）：我构建了正确的系统吗？（Am I buiding the right system?）

验证（Verification）和确认（Validation）的结果和答案

验证（Verification）：正确和不正确（correct and incorrect）

确认（Validation）：适当和不适当（appropriate and inappropriate）

1.3 需求工程中的V&V

需求工程（RE）中的确认（Validation）表示检查需求工程核心活动的输入（上下文）、执行的活动和创建的输出（需求人工制品）是否符合定义的质量标准。

三个子活动

·确认（Validating）上下文的考虑

上下文考虑中的错误导致需求中的错误

需求源不完整

缺少、不正确或考虑上下文信息不足

从四个方面进行确认（Validating）

主题、用途、IT系统、开发

·确认（Validating）活动的执行

检查是否已执行每个所需的需求工程活动

检查每个活动是否已正确执行

·确认（Validating）创建的需求工件

关于内容维度的确认（Validation）

检查所有相关要求是否已知并理解到所需的详细程度

关于文档维度的确认（Validation）

检查是否根据定义的文件和规范规则记录了需求

关于协议维度的确认（Validation）

检查利益相关者是否已就文件化要求达成一致

检查每个已知冲突是否已解决

检查是否存在尚未识别的冲突

1.4 V&V过程

2 需求验证（Requirements Verification）技术

2.1 需求评审（Inspections）

书面材料的质量改进流程

过程

准备

检查会议

修订

后续处理

检查什么？

软件需求规范（SRS）

可理解性（Comprehensibility）

冗余性（Reduncy）

完整性（ Completeness）

歧义性（Ambiguity）

一致性（Consistency）

组织性（ Organization）

符合标准性（Standard Compliant）

可追溯性（Traceability）

如何检查？

Ad hoc（没有预先规划的软件测试方法）

基于检查表

基于缺陷

基于功能点

基于透视图

基于场景

好处（Benefit）：

工件的详细检查

检查已达成的理解

努力（Effort）：

需要中等到高的努力

关键成功因素（Critical Success Factors）：

过程和组织：严格定义

工件：尺寸、复杂性、质量

检查组成员的选择：数量、覆盖范围、经验

需求文档进入审查的标准：

文档符合标准模板；

文档已经做过拼写检查和语法检查；

作者已经检查了文档在版面安排上所存在的错误，已经获得审查员所需要的先前或参考文档，例如系统需求规格说明；

在文档中打印了行序号以方便在审查中对特定位置的查阅；

所有未解决的问题都被标记为TBD待确定，包括文档中使用到的术语词汇表。

需求文档退出审查的标准：

已明确阐述审查员提出的所有问题；

已正确修改文档；

修订过的文档已进行了拼写检查和语法检查，所有TBD问题已全部解决，或者已经记录下每个待确定问题的解决过程、目标、日期和提出问题的人；

文档已登记入项目的配置管理系统；

已将审查过的资料送到有关收集处

2.2 原型和模拟（Prototyping and Simulation）

好处（Benefit）：

原型开发期间的缺陷检测

可行性证明

努力（Effort）：

原型可以自动生成：低或非常低

开发期间的工具支持：中等或低

手动开发的原型：非常高或很高

关键成功因素（Critical Success Factors）：

努力（Effort）

文件的质量

原型的详细程度

2.3 编写测试用例（Writing Test Case）

软件测试：

软件测试表示以检测故障为目的的软件单元的系统执行。

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

测试用例

测试用例包括测试执行所需的前提条件、输入和预期输出的集合、测试指令（如何从测试对象中读取输入）以及预期的后置条件。

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

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

测试用例定义

基于代码的测试（白盒测试）

基于规范的测试（黑盒测试）

优点/缺点（Advantages/disadvantages）：

测试水平的适用性：

基于代码的测试适用于组件测试，并在一定程度上适用于集成测试

基于规范的测试适用于所有测试级别。

测试期间测试对象的覆盖范围：

可以使用基于代码的测试来检测整个源代码中的错误

基于规范的测试可以找到缺少的需求实现。

好处（Benefit）：

非常适合检查功能需求和可验证性的特定质量要求

检查可理解性、明确性和完整性

测试用例的进一步使用

努力（Effort）：

中等

关键成功因素（Critical Success Factors）：

与测试用例开发人员的知识和经验的关系

与测试用例开发人员的知识和经验的关系

2.4 用户手册开发（Users Manual Development）

一般情况下，用户手册是在系统完成准备交付用户使用前编写，是为了帮助用户更好地使用系统，解决可能由于系统环境、配置、安装、功能操作不熟悉等原因带来的问题。但是如果采用编制用户手册的方法来验证需求，则用户手册编制的工作可以在需求工程阶段就开始。

用户手册的内容包括系统的运行环境、硬件要求、环境配置以及安装过程介绍等，也包括系统功能的详细操作过程，与其他系统的交互过程介绍和问题与故障的解决办法。

用户手册的编写依据主要是SRS。在编写过程中，可以同步检查SRS的问题，也就对软件需求进行了验证。

编写用户手册有助于进行环境和约束的验证、进行功能需求的验证和项目范围的验证，以及进行异常处理流程需求的验证。

1.开始

2.用户界面

3.使用场景

3.1场景1

3.2场景2

3.3......

4.功能

4.1功能1

4.2功能2

4.3......

5.故障排除

5.1问题1

5.2......

6.词汇表

7.索引

好处（Benefit）：

手动编写过程中的缺陷检测

使用手册的其他方式

努力（Effort）：

高

关键成功因素（Critical Success Factors）：

完整和稳定的要求

利益相关者的支持

可读性和可理解性

2.5 需求可追溯性（Requirements Traceability）

验证完整性：自上而下

验证不必要的需求：自下而上

2.6 自动化工具（Automation Tools）

正确性已验证

程序满足需求规范

需求规范满足领域财产

完整性已验证

找到所有必要的要求

找到所有必需的域财产

3 问题修正（Revise the Problems）

需求澄清

误解：重新分析

错过：重新分析并记录此部分

不正确的表达式：重新记录或重新指定

不完整的要求

重新激发和其他后续活动

冲突或不一致的要求

协商

不切实际的期望

项目调整与谈判

Chapter 7 需求管理（Requirements Management）

1 需求管理的基本原理

需求管理是两个横截面需求工程活动之一。

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

观察系统上下文以检测上下文更改

管理需求工程活动的执行

管理需求工件

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

需求变更无法避免。

系统运行过程中遇到的问题可能导致需求变更：

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

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

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

可能的上下文更改

新技术或新的竞争产品出现

法律或标准变更

利益相关者目标的演变

其他利益相关者的参与

组织政策的变更

外部行为者（利益相关者或系统）使用系统的方式变化

管理需求工程活动

管理需求工件

需求属性方案的定义

标识符、名称、需求类型、版本、作者、状态、优先级等。

必须为不同的人工制品类型定义适当的属性方案

需求可追溯性

需求应追溯到其起源、细化或实现

需求变更管理

需求配置管理

需求优先级

2 需求追溯

2.1 需求可追溯性基础

需求可追溯性是一种重要的质量保证手段。

可追溯性是指不同开发产品之间建立关系的程度，尤其是相互之间具有前后关系或主从关系的产品

记录的需求可追溯性信息支持各种系统开发活动。

可验证性和可接受性、变更管理、质量保证、维护、维修、重新设计、重用、风险管理和流程改进

2.2 可追溯性分类

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

需求人工制品及其来源或来源之间的可追溯性

需求工件及其后续工件之间的可追溯性

方向：向前与向后可追溯性

扩展的前后可追溯性

需求工件和前任/后继工件之间的可追溯性

不同类型需求工件之间的可追溯性，如目标、场景和面向解决方案的需求

2.3 可追溯性信息的展示

文本参考

超链接

可追溯性矩阵

3 需求优先级

3.1 需求优先化的基础

为什么需要优先排序---权衡

需要选择要实施的内容

客户（通常）要求太多

平衡上市时间与功能量

决定下一版本的功能

执行分类

必须包括一些要求

一定要排除某些要求

这就留下了一堆“好东西”，我们必须从中选择

对于每个需求或功能，询问：

这对客户有多重要？

实施成本是多少？

尝试建造它的风险有多大？

3.2 需求优先化的四个步骤

确定利益相关者

基于目标和标准的利益相关者选择

确定要优先考虑的工件事实

在一个优先级排序活动中，仅对相同工件类型的工件进行优先级排序

优先考虑高级需求，首先

选择优先级标准

重要性（Importance）

成本（Cost）

损害（Damage）

持续时间（Duration）

风险（Risk）

波动性（Volatility）

选择优先级排序技术

单标准分类、卡诺分类、双标准分类、威格斯优先矩阵、成本价值法

3.3 需求优先化技术

3.3.1 一个标准分类

基于单个标准确定需求工件的优先级

单一标准分类的一个常见标准是需求工件的必要性程度

必要的（Essential）：意味着除非以商定的方式满足这些要求，否则系统将不可接受。

有条件的（Conditional）：意味着这些需求工件将增强系统，但如果它们不存在，则不会使系统不可接受。

可选（Optional）：暗示一类可能有价值或可能没有价值的需求工件。

3.3.2 卡诺（Kano）分类

根据系统特征（或客户需求）对客户满意度的影响对其进行分类

不满意者（Dissatisfier）：（必须要求）系统必须实现这一要求才能进入市场

满意者（Satisfier）：（一维客户需求）

更满意者（Delighter）：（吸引人的要求）

3.3.3 两个标准分类

3.3.4 威格斯（Wiegers）优先矩阵

优先排序过程考虑四个优先排序标准：

利益（benefit）

惩罚（penalty）

成本（cost）

风险（risk）

需求优先级是基于以下假设进行的：需求的优先级与其收益（如果实现）和惩罚（如果未实现）成正比，与需求的成本和风险成反比。

Wiegers排序矩阵计算需求优先级：

1.确定收益、损失、成本与风险4个计算参数的权重。若不考虑风险，其权重置为0。

2.在优先级排序矩阵中列出所有的待排序需求。

3.估算每一个需求关于客户满意度或业务目标的实现的相对收益。这个值被记录在1~9内。

4.对于每个需求而言，如果该需求未被发现，那估算其发生所带来的相对损失，也在1~9内。

5.基于相对收益，相对损失及权重，计算每个需求的值，随后可确定每个值相对于总数值的百分比。

6.估算相对成本，1~9内，随后，确定其成本相对于计算出的总成本的百分比

7.估算相对风险，1~9内，随后，确定其风险相对于计算出的总风险的百分比

8.计算单个需求的优先级：

9.基于计算出的优先级值对需求进行降序排列

3.3.5 成本价值法（cost-value图）

计算投资回报率（ROI）

评估每个需求对整个项目的重要性

评估每个需求的相对成本

计算成本价值权衡

绘制ROI图

AHP进行两次：

一次估算相对价值

一次估算相对成本

使用结果计算ROI率：

估算成本和价值

两种方法：

绝对比例：（例如美元价值）

需要丰富的领域经验

相对值：（例如少/多；有点、有点、非常）

更容易引出

优先排序成为排序问题

比较过程-选项

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

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

构造二进制排序树需要O（n log n）个比较

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

一些复杂的情况:

难以量化的差异

更容易说“x比y更重要”…

…而不是用多少来估计。

并非所有要求都具有可比性

例如，不同的抽象级别

例如，核心功能与客户增强

要求可能不是独立的

如果X和Y相互依赖，则在X和Y之间没有点选择

利益相关者可能不一致

例如，如果X>Y，且Y>Z，则推测X>Z？

利益相关者可能不同意

针对不同类型利益相关者的不同成本/价值评估

分级优先级

将需求分组到层次结构中

例如，目标树

例如，NFR树

仅在单个节点的分支之间进行比较

4 需求变更管理

4.1 变更管理基础

目标

控制变化，而不是避免变化

需求工程中变更管理的任务是管理需求的变更，并确保每个变更都得到正确实施和可追溯。

任务

组织变更管理活动

提交变更请求、影响分析、决策、实施和验证

记录变更管理结果

4.2 需求配置与需求基线（Change Management Process）

需求配置（Requirements Configuration）

需求工件的配置包括一组相关的需求工件，或者更准确地说，需求工件的版本。

需求工件的配置具有以下属性：

一致性（Consistency）

唯一标识（Unique identification）

不可更改（Not changeable）

回滚基础（Basis for roll-back）

需求基线（Requirements Baseline）

需求基线是需求工件的选定配置。

基线具有需求配置的所有上述属性。此外，基线具有以下属性：

定义系统版本的依据

对客户的可见性

服从变更管理

计划系统发布依据

实现努力的估计

与竞争对手产品的比较

4.3 变更管理流程（Change Management Process）

变更控制委员会（Change Control Board）（CCB）

职责：评估变更（控制范围扩展和影响分析），做出决策并确保实施批准的变更

成员：

控制范围扩展

根据业务目标、愿景和范围评估每个新增需求或功能

影响分析

分析对需求工件的影响

分析对后续工件的影响

5 需求管理工具

5.1 为什么我们需要工具？

提高效率

工具帮助我们：

保存需求属性

管理需求更改

跟踪需求状态

帮助影响分析

访问控制

与利益相关者沟通

重用要求

需求管理工具

以数据库为中心

在数据库中存储需求、属性和跟踪信息

Caliber-RM

DOORS

RTM Workshop

以文档为中心

将需求另存为文档

QSSrequit：单词+属性表

RequisitePro：文档+数据库

RTM研讨会：文档/数据库

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.3 Requisite Pro简介

一个强大、易用、可集成的需求管理产品

一个RequisitePro项目包含若干Microsoft Word文档和一个后台数据库

使用Word文档和数据库两种方式来存储并管理需求，使得RequisitePro兼有数据库的强大功能和Word的易用性

使用Word文档和数据库两种方式来存储并管理需求，使得RequisitePro兼有数据库的强大功能和Word的易用性