今日学习札记——需求工程基础（11.4）

1. 需求技术发展历程
无需求处理 ->草图分析->需求分析DFD/ERD->需求分析面向对象
机器为中心                           应用为中心                             形式化方法                                             软件膨胀
（50's)                                       (60's)                                      (70's)                                                      (90's)

2. 最近软件生产状况影响因素调查
             2010年度                                                         2012年度
1> 用户参与 20                            ------         1> 高层管理支持 19
2> 高层管理支持 15                     ------         2> 用户参与     18
3> 清晰的业务目标 15                 ------         3> 清晰的业务目标 15
4> 情感成熟度（项目氛围）11  ------         4> 情感成熟度（项目氛围）12
5> 最优化  11                                ------         5> 最优化  11


3. 应用软件的模拟特性（软件的三种类型）
- 纯工具软件（专业用户）
# 好的标准：功能的复杂性、使用的高效性、技术的先进性
# 例子：编程环境、DBMS

- 纯工具软件（普通用户）
# 好的标准：功能的有用性、使用的方便性、技术的可行性
# 例子：Office、语言翻译软件

- 应用型软件
# 好的标准：功能的“模拟性”（目的、问题领域知识）、使用的方便性、技术的可行性
# 例子：MIS、EAI

4. 结构化分析和面向对象分析具有一定的先天缺陷
需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实
 
5. 需求错误的高代价性

6. 需求的定义
- IEEE定义
1）用户为了解决问题或达到某些目标所需要的条件或能力；
2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；
3）对1）或2）的一个条件或一种能力的文档化表述。
- 一般定义
1）它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束
2）规格说明
3）时间演化

7. 需求工程的基本活动

8. 需求工程的必要特性
- 软件开发是这样一个工程问题：它利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的。
- 计算机应用于现实世界的广泛性
# 新的问题和新的解决方案
# 定义问题就是需求工程的任务

9. 需求工程的重要特性
- Frederick Brooks在人月神话中这样描述：
“开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，
 这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大
 损害的部分，并且以后再对它进行修改也极为困难。”
- 容易忽略需求工程重要性的地方
# 问题广为人知，例如：图书管理系统
# 问题小而简单

10. 需求工程师是现实世界与技术方面的桥梁（外号：涉众代理）

11. 需求工程师所需要的软技能
交流、观察、抽象分析与问题解决（抽象、整合、系统化）、写作、关系协调与团队工作
 
12. 需求工程所涉及的基本概念 <下钻1：需求工程基本概念>


13. 需求的层次性 <下钻2：需求的层次性>


14. 常见的需求类别 <下钻3：需求类别>


15. 优秀需求的特性1：完备性
- 每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息。
例1：系统应该允许扩展。
  （更好）系统的调度算法应该允许被扩展。
    
- 对功能的描述：Trigger;Pre-State;Action(Input,Output);Post_State
# 行为的触发者（Trigger），包括：数据输入、接收的请求、要处理的异常等。
# 行为的前置条件（Precondition），包括：系统的模式或状态、其他外部系统的状态、任何系统数据的值等；
# 行为（Action），在前置条件下接受到触发者时，系统必须执行的行为；
# 后置条件（Postcondition），包括：系统的模式或状态、其他外部系统的状态、任何系统数据的值等；
# 不满足前置条件（Failed preconditions）的情况，以及相应情况下的结果（Resulting failure postconditions）


- 对数据需求的描述
# 类型；
# 语义（例如在数据字典或项目术语表中描述数据的含义）；
# 组成成分（例如属性，子部分等）
# 初始值或缺省值；
# 可能的取值范围；
# 度量单位；
# 数据量；
# 更新频率；
# 可以对其施加的合理操作；
# 对外关系，例如关联、聚集、泛化等。


- 对外接口的描述
# 接口的名字；
# 接口的定义，简短的描述；
# 接口的方向声明（In，Out，或者双向）；
# 服务请求，包括：
1）语法，例如名称、参数、返回值。
2）语义，含义，协议，例如前置条件、后置条件与不变量或者状态模型等；
3）异常，语法与语义；
4）接口定义的特殊数据类型；
5）质量属性要求（例如性能、可靠性、安全性、保密性等）


- 对质量属性的描述
# 针对系统或其部件的质量标准；
# 明确了需要满足质量标准的情况与条件；
# 衡量质量标准所使用的单位；
# 质量度量的阀值；


16. 优秀需求的特性2：正确性
- 真实地反映用户的意图
- 必须请需求的提出者予以确认
1）多问用户“为什么”，将需求描述从具体情景、技术环境等约束中抽离出来
2）从业务方面描述需求，而不是从技术方面描述需求。
3）关注涉众的想法。包括关注涉众对需求的效益评价，关注涉众对需求的优先级划分，真正理解需求对于涉众的意义。
4）在演化中理解需求。将最初始的需求展示给涉众，并利用涉众的反馈发现真正的需求。
   5）通过量化手段准确理解需求。对验证标准的反复推敲可以更准确地理解涉众的需求含义。


17. 优秀需求的特性3：可行性
- 由开发人员进行检查 
- 需要进行一定的分析和研究，而不是单纯的凭借经验和直觉 
- 必要的时候要通过开发原型来加以验证 


18. 优秀需求的特性4：必要性
- 满足用户的业务需求所必需的 


19. 优秀需求的特性5：无歧义
- 每一项需求都应该有而且只能有一种解释 
- 定义一个可以共同理解的词汇表（Glossary）


20. 优秀需求的特性6：可验证
- 通过分析、检查、模拟或者测试等方法能够判断需求是否被满足 
- 不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要
# 让需求具体化
# 小心形容词和副词的使用
# 避免程度词的使用

-------<下钻1：需求工程的基本概念>---

1. 问题域
- 问题：当现实的状况与人们期望的状况产生差距时，就产生了问题。
- 问题域：要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。
 这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（Problem Domain）
- 问题域是需求的背景
例1：R1：提高3%利润率
    问题域：利润的构成
例2：R2：提高工作效率
    问题域：工作分工及其效率瓶颈
- 问题域自治的规律性称为问题域特性

2. 解系统：软件系统通过影响问题域，能够帮助人们解决问题，称为解系统。
- 软件系统只是解决需求的手段之一
- 用户要关注问题
- 开发者主要关注软件系统，但要以问题为中心思考

3. 需求：需求是用户对问题域当中的实体状态或事件的期望描述
例1：一旦书被借出，则在归还之前，它不能被再次借阅。
例2：当归还的书超过30天的归还期限时，归还后应该进行超期处罚。
 
4. 规格说明：
- 规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。
- 它主要包括2部分：
1）对共享现象（模型）的描述；
2）系统对共享现象所施加的操作的描述

5. 共享现象
- 软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分具有模拟性。
- 换句话说，软件系统中应含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。
- 问题域中的某些信息和模型中的信息建立映射关系，通过这些映射建立的共同知识，就是问题域和解系统之间的共享现象。

6. 问题的需求分三种
- 直接需求
- 间接需求
- 不切实际的期望

7. 需求规格说明书应包含2个部分
- 数据：模拟现象的模型
- 功能：操纵模拟现象，解决问题


8. 需求开发的本质
- 描述明确的问题域特性Z；定义良好的系统行为S；预期的需求R
- 需求工程的目的就是根据E，构建S，使得E,S |->R
- 需求工程的主要工作：
1）需求开发，确定R；
2）研究问题背景，描述问题域特性E；
3）构建解系统，描述解系统行为S，使得E,S |->R
-------end <下钻1：需求工程的基本概念>---


-------<下钻2：需求的层次性>---

1. 目标是商业目标；任务是用户任务；系统行为是用户与系统的交互


2. 业务需求（目标）
- 系统建立的战略出发点，表现为高层次的目标（Object），它描述了组织为什么要开发系统。
- 未来满足业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）
- 特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope）
- 参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision）
例子：
BR1：在系统使用6个月后，商品积压、缺货和报废的现象要减少50%
BR2：在系统使用3个月后，销售人员工作效率提高50%
BR3：在系统使用6个月后，店铺运营成本要降低15%
范围：人力成本和库存成本
度量：检查平均每个店铺的员工数量和平均每10,000元销售额的库存成本
BR4：在系统使用6个月后，销售额度要提高20%
最好情况：40%
最可能情况：20%
最坏情况：10%

3. 用户需求（任务）
- 执行实际工作的用户
- 实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做什么（直接用户、间接用户）
- 对所有的用户需求，都应该有充分的问题域知识作为背景支持
- 特性
# 模糊、不清晰
# 多特性混杂
# 多逻辑混杂
例子：
UR1：收银员可以使用系统逐一记录销售的商品
UR2：收银员可以使用系统计算商品账单并处理付款情况，账单计算需要使用促销策略
UR3：收银员可以使用系统为顾客打印收据
UR4：收银员可以使用系统退回顾客已经购买的商品

4. 系统级需求（系统行为）
- 用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求。
- 系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。
- 将用户需求转化为系统需求的过程是一个复杂的过程
1）首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；
   2）然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
3）该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。 
例子：P27
 
5. 比较用户需求和系统级需求
- 用户需求和系统级需求在实践中经常是混淆的
# 用户习惯于用户需求
#开发者需要系统级需求，但得到的往往是用户需求
1）未能得到足够信息以准确地完成设计与实现工作
2）需要开发者以各种方式进行假设
- 明确其不同点
# 用户需求 —— 任务； 系统级需求 —— 交互
# 文本方式描述系统级需求；图形方式描述用户级需求
- 明确建立和维护用户需求与系统级需求的关系
- 系统级需求的建立需要需求人员的创造性（建模）

6. 不同需求层次之间的关系
业务需求 —>业务需求指导需求获取—>用户需求 —> 转化用户需求为系统需求—> 系统需求
-------end<下钻2：需求的层次性>---


-------<下钻3：需求的常见类型>---

1. 软件需求的所在位置

2. 软件需求的IEEE分类
- 功能需求（Functional Requirement)：用户希望系统所能执行的活动，这些活动可以帮助用户完成任务，功能需求主要表现为系统和环境之间的行为交互。
- 性能需求（Performance Requirement)：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
- 质量属性（Quality Attribute)：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。
- 对外接口（External Interface)：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等。
- 约束：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等。
- 其他：数据需求等。

3. 功能需求
- 是软件产生价值的基础
- 最为复杂，在所有需求中占比可达90%甚至更高（绝大部分）

4. 性能需求（五个维度）
- 速度（Speed），系统的响应时间
PR1：所有的用户查询都必须在10秒内完成。
- 容量（Capacity），系统所能存储的数据量。
PR2：系统应该能够存储至少10万条销售记录。
- 吞吐量（Throughput），系统在连续的时间内完成的事务数量。
PR3：解释器每分钟应该至少解析5000条没有错误的语句。
- 负载（Load），系统可以承载的并发工作量。
PR4：系统应该允许200个用户同时进行正常的工作。
- 实时性（Time-Critical），严格的实时要求。
PR5：检测到病人异常后，监控器必须在0.5秒内发出警报。

5. 质量属性
- 系统为了满足所规定的以及隐含的所有需求而需要具备的要素称为质量。
- 质量属性的重要性
# 对设计的影响很大
# 对越复杂的系统越为重要
- 用户不能明确地提出他们对产生质量的期望
- 需求工程师：质量属性大都是和功能需求联系在一起的，因此需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性(
 形容词和副词通常意味着质量属性的存在）


6. 常见的质量属性示例（也5个维度）
- 可靠性（Reliability）：在规格时间间隔内和规定条件下，系统或部件执行所要求能力的能力。
例子：Reliability6：在进行数据的下载和上传中，如果网络故障，系统不能出现故障。
- 可用性（Availability）：软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率
例子：QA2：系统的可用性要达到98%。
- 安全性（Security）：软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意，也可能是无意的
例子：QA3：VIP顾客只能查看自己的个人信息和购买记录；收银员只能查看，不能修改、删除VIP顾客的信息。
- 可维护性（Maintainability）：软件系统或部件能修改以排除故障、改进性能或其他属性或适应变更了的环境的容易程度，包括可修改性（Modifiability）和可扩展性（Extensibility）
例子：QA4：如果系统要增加新的特价类型，要能够在2个人月内完成。
- 易用性（Usability）：与用户使用软件所花费的努力及其对使用的评价相关的特性。
例子：QA6：使用系统1个月的收银员进行销售处理的效率要达到10件商品/分钟


7. 对外接口
- 解系统和其他系统之间的软硬件接口
1）接口的用途
2）接口的输入输出
3）数据格式
4）命令格式
5）异常处理要求
- 用户界面
# 可以作为需求，写在SRS中
# 也可以利用专门的人机交互设计文档记录
# 简单需求：给出一个界面示意图
# 复杂需求：
1）一个界面示意图
2）在操作界面时的注意事项，例如：按钮使用规则、数据填写规则等。
- 通信接口
# 通信协议、寻址、数据及其格式

8. 约束：总体上限制了开发人员设计和构建系统时的选择范围
- 系统开发及运行的环境
# 包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。
- 问题域内的相关标准。
# 包括法律法规、行业协定、企业规章等。
- 商业规则。
# 用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围 
- 法规、社会性因素等。

9. 其他需求：安装需求、培训需求、数据需求等。
例子：
OR1：在安装系统时，要初始化用户、商品库存等重要数据。
OR2：系统投入使用时，需要对用户进行1个星期的集中培训。
SR3：在收银员输入商品标识时，系统显示商品信息，商品信息参见DR1、DR2；
DR1：ID是规则为…的商品条形码；
DR2：商品信息包括：ID、名称、描述、价格、特价、数量、总价
-------end<下钻3：需求的常见类型>---