软件工程与计算II-05-需求基础

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

软件需求是一个连接现实世界与计算机世界的活动:它既需要从问题出发，分析问题域，研究解决问题所需要的互动效应。

一个产品的开发过程

1. 客户想要什么
2. 产品经理理解
3. 设计师分析
4. 程序员进行编写
5. 交给测试人员测试
6. 商业人员描述这个产品
7. 项目的文档
8. 如何进行部署
9. 价格像过山车一样变化
10. 如何进行支持运维
11. 进行广告宣传
12. 最后使用用户需要什么

需求工程的内容

软件建立的依据

单纯的软件系统是不能解决问题的，它只有和现实世界之间形成有效互动才能实现问题的解决

需求工程

需求工程的概念：所有需求处理活动的总和。它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终描述出软件被应用后与其环境互动形成的期望效应。

三个主要任务：

1. 需求工程必须说明软件系统将被应用的应用环境及其目标，说明用来达成这些目标的软件功能，也即要同时说明软件“需要做什么”和“为什么需要做”。
2. 需求工程必须将目标和功能反映到软件系统当中，映射为可行的软件行为，并对软件行为进行准确的规格说明。
3. 现实世界是不断变化的世界，因此需求工程还需要妥善处理目标和功能随着时间演化的变动情况。

需求工程的具体活动

1. 需求要逐步进行验证，越早发现 bug 所付出的代价越少。
2. 需求工程活动包括需求开发和需求管理两部分。

需求开发过程模型

1. 需求获取是从利益相关人的问题域中提取出来的。
2. 需求应该是面向很多人的，这样子才能体现出来需求的有用性。

需求获取

1. 从人、文档或者环境当中获取需求的过程
2. 要利用各种方法和技术来发现需求
   • 需求是客观存在的，但是一定是由需求开发人员提出的

目标分析

1. 根据问题确定目标：发现用户的期望和现实之间的差距
2. 通过分析利害关系人确定目标：一个软件系统可能会有很多的厉害关系人，他们需要从各自立场出发，具有不同的目标要求

需求获取的常见困难

1. 用户和开发人员的背景不同，立场不同：“床边 B 超，肝胆胰脾”：很难以保证开发人员懂得这句话的含义
2. 普通用户缺乏概括性、综合性的表述能力：不聪明的记者：请别人进行一句话描述
3. 用户存在认知困境：平板电脑,在 ipad 还没有出现的时候
4. 用户越俎代庖：双机热备：如果甲方有一定的经验，我们就是要求系统能够...，至于怎么实现是你开发者的事
5. 缺乏用户参与：不愿参与的医生：有一些情况下用户并不愿意参与开发

用户需求获取的方法

1. 面谈：面对面的会见；问答格式
2. 问卷：集体获取方法之一
3. 文档分析
4. 头脑风暴：特殊的群体面谈方法，目的是发现潜在需求
5. 专题讨论
6. 原型：建立一个有形的制品来方便沟通和交流

以 Story board 作为原型

重新认识需求获取

1. 用户和开发人员的背景不同，立场不同："床边 B 超,肝胆胰脾"：消除默认知识
2. 普通用户缺乏概括性、综合性的表述能力：不聪明的记者：专业的需求人员
3. 用户存在认知困境：平板电脑：原型（做一个原型帮助用户理解的草图模型）
4. 用户越俎代庖
   • 双机热备：需求是开发人员开发出来的，不是用户提出来的
   • 我们就是要求系统能够....，至于怎么实现是你开发者的事：协商
5. 缺乏用户参与：不愿参与的医生：为用户参与提供方便

需求分析

1. 通过建模来整合各种信息，以使得人们更好的理解问题。
2. 为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案。
3. 检查需求当中存在的错误、遗漏、不一致等各种缺陷，并加以修正。

边界分析

1. 定义项目的范围。系统边界之内定义的是系统需要对外提供的功能。
2. 系统边界的定义要保证系统能够和周围环境形成有效的互动
3. 系统用例图、上下文图通常被用来定义系统的边界。

需求建模

1. 建模是为展现和解释信息而进行的抽象描述活动
2. 常用的技术包括类图、顺序图、状态图等建模技术
3. 在为需求建模时，常用的技术包括数据流图、实体关系图、状态转换图、类图等半形式化建模技术。

需求规格说明

1. 在系统用户之间交流需求信息
2. 要简洁、精确、一致和易于理解
3. 需求工程师在这个阶段的重要工作包括：
   1. 定制文档模版，提高效率
   2. 编写文档（模型预言和自然语言两种）

需求验证

1. 需求规格说明文档至少要满足下面几个标准：
   1. 文档内每条需求都正确、准确的反映了用户的意图；
   2. 文档记录的需求集在整体上具有完整性和一致性；
   3. 文档的组织方式和需求的书写方式具有可读性和可修改性（方便保证版本简化）。
2. 需求验证的方法：包括同级评审、原型、模拟等。

需求管理

1. 保证需求作用的持续、稳定和有效发挥：在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要以围绕需求开展工作
2. 进行变更控制：纳入和实现合理的变更请求，拒绝不合理的变更请求，控制变更的成本和影响范围

需求基础

需求重要

1. IEEE 对需求的定义为[IEEE610.12-1990]：
   1. 用户为了解决问题或达到某些目标所需要的条件或能力；
   2. 系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；
   3. 对 1 或 2 中的一个条件或一种能力的一种文档化表述。
2. 需求是一种期望：源自现实又高于现实，需求是多变和可调整的，项目可以依据实际情况调整需求的实现程度。

需求的表述方式

1. 作为一种期望，需求通常被表述为"系统应该…"、"在…时，系统应该…"、 "用户可以通过系统…"等，例如 R1。
2. R1：系统应该允许顾客退回已经购买的产品。

软件解决方案

1. 需求是一种解决问题后所能达到的期望
2. 一件事情的两面
   • 问题是糟糕的一面
   • 需求是理想的一面

需求开发的目标

问题域

1. 现实世界运行规律的一种反映
2. 需求的产生域，也是需求的解决地。
3. 最终的软件产品要在现实中部署，它能够部分影响问题域，但不能任意改变现实
   • 软件开发必须尊重问题域，不能因为技术原因妄自修改现实世界的实际情况。

问题的解决

1. 基础：模拟与共享现象
2. 方法：直接与间接
3. 解决方案：需求规格说明

区分需求、问题域和规格说明

问题域

1. 现实世界运行规律的一种反映
2. 需求的产生域，也是需求的解决地。
3. 最终的软件产品要在现实中部署，它能够部分影响问题域，但不能任意改变现实
   • 软件开发必须尊重问题域，不能因为技术原因妄自修改现实世界的实际情况。

规格说明

1. 软件产品的方案描述，它以软件产品的运行机制为主要内容。
2. 它不是需求但实现需求，不是问题域但需要与问题域互动。
3. 规格说明要以关注对外交互的方式描述软件解决方案，它既需要从软件产品的角度而不是用户的角度进行描述，又不能太多地涉及软件产品的内部构造机制。
4. 为什么描述的是交互?
   • 因为交互对我们而言是一个对外的重要展示。

超市销售系统

1. 问题：超市的成本太高
2. 需求：超市的成本应该降低：比较笼统
3. 问题域：超市的成本主要由人力成本和库存成本组成
4. 规格说明
   • 库存预测：大致进行推测
   • 库存报警

三种需求层次：业务需求、用户需求、系统级需求（需求的层次性）

题型：给出一个实例，给出三个层次的例子，对给定的需求实例，判断其层次

业务需求（目标，解决方案与系统特性）

1. 业务需求是高层次的解决方案和系统特性、系统开发的战略出发点、高层次的需求，描述为什么要开发系统。
2. 为什么是系统特性？因为还没有到细节的部分
3. 特性说明了系统为用户提供的各项功能，它限定了系统的范围(Scope)

[示例]
1. R2：在系统使用 3 个月后，销售额度应该提高 20%（期望，没有从软件角度进行描述，业务需求）
2. 可以建立高层次的解决方案，其系统特性如 SF1~SF4 所示。(Feature)，如下是系统需求
    SF1：管理 VIP 顾客信息。
    SF2：提供 VIP 顾客服务，增加回头率。
    SF3：使用多样化的特价方案，吸引顾客购买，增加销售额。
    SF4：使用多样化的赠送方案，吸引顾客购买，增加销售额。

用户需求（任务，问题域知识）

1. 问题域知识：执行具体任务的用户对系统所能完成任务的期望，描述了系统能帮用户做什么
   1. 直接用户
   2. 间接用户（通用软件的销售人员和售后支持人员）
2. 问题域知识：是需要了解到期望所来源的背景知识。
3. 特性
   • 模糊、不清晰（允许适度的用形容词和副词）
   • 多特性混杂（功能和非功能的混杂）
   • 多逻辑混杂（一个任务需要多次系统交互才能完成）

[示例]
1. R3：系统要帮助收银员完成销售处理（期望，用户需求）
2. SF1：管理 VIP 顾客信息针对系统需求
3. 针对每一个系统特性，都可以建立一组用户需求。例如对 SF1，可以建立用户需求组如 UR1.1~UR1.7，它们中每一条都是用户完成具体任务所需要的功能：
    UR1.1：系统应该允许客户经理添加、修改或者删除会员个人信息。（问题域）
    UR1.2：系统应该记录会员的购买信息。
    UR1.3：系统应该允许客户经理查看会员的个人信息和购买信息。
    UR1.4：系统应该允许客户经理查看所有会员的统计信息。

• 例如对 UR1.1，需要补充问题域知识如下：会员的个人信息有：客户编号、姓名、联系方式（具体是什么：手机、邮箱等）、积分。

系统需求

1. 需求分析模型：用户对系统行为的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节（和用户需求有着很大的区别）
2. 描述了开发人员需要实现什么
3. 将用户需求转化为系统需求的过程是一个复杂的过程
   • 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；
   • 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
   • 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。
4. 系统级需求还可能会补充一些与软件实现相关的细节。

[示例]
1. UR1.3：系统应该允许客户经理查看会员的个人信息和购买信息。
2. R4：收银员输入购买的商品时，系统要显示该商品的描述、单价、数量和总价。（期望，展现系统输入输出，系统级需求）
3. 对用户需求 UR1.3，可以依据任务中的交互细节将之转化为系统级需求 SR1.3.1~ SR1.3.4。
    SR1.3.1 在接到客户经理的请求后，系统应该为客户经理提供所有会员的个人信息。
    SR1.3.2 在客户经理输入会员的客户编号时，系统要提供该会员的个人信息。
    SR1.3.3 在客户经理选定一个会员并申请查看购买信息时，系统要提供该会员的历史购买记录。
    SR1.3.4 经理可以通过键盘输入客户编号，也可以通过读卡器输入客户编号。

综合示例

1. R1：在系统使用 3 个月后，销售额度应该提高 20%（业务需求-为何开发系统）
2. R2：系统要帮助收银员完成销售处理；（用户需求-帮助用户做什么）
3. 系统特性 SF1：管理 VIP 顾客信息，针对每一个系统特性，都可以建立一组用户需求。例如对 SF1，每一条都是用户完成具体任务所需要的功能：
   • UR1.1：客户经理可以使用系统添加、修改或者删除会员个人信息。（用户需求）
   • UR1.2：收银员使用系统进行销售时会记录会员的购买信息。（用户需求）
   • UR1.3：客户经理可以使用系统查看会员的个人信息和购买信息。（用户需求）
   • UR1.4：客户经理可以使用系统查看所有会员的统计信息。（用户需求）
4. R3：收银员输入购买的商品时，系统要显示该商品的描述、单价、数量和总价（系统级需求-系统怎么与外界交互）
5. 对用户需求 UR1.3，可以依据任务中的交互细节将之转化为系统级需求 SR1.3.1 ~ SR1.3.4。
   • SR1.3.1 在接到客户经理的请求后，系统应该为客户经理提供所有会员的个人信息。（系统级需求）
   • SR1.3.2 在客户经理输入会员的客户编号时，系统要提供该会员的个人信息。（系统级需求）
   • SR1.3.3 在客户经理选定一个会员并申请查看购买信息时，系统要提供该会员的历史购买记录。
   • SR1.3.4 经理可以通过键盘输入客户编号，也可以通过读卡器输入客户编号。（系统级需求）
6. ATM 机：问题：营业厅人力成本过高，不吸引客户（业务需求）
7. 问题域：存钱、取钱、转账（用户需求）

课堂练习

1. NBA 数据分析应用
2. 业务需求
   1. NBA 球队老板希望知道谁是 2014-2015 赛季最大心脏的投手？
   2. 老板想要买球星
   3. 老板想要知道应该派遣哪位球星上
3. 用户需求？
   1. 系统应该允许老板可以查看各个投手的数据
   2. 系统应该允许老板查看最后两分钟，投手的得分率和投篮次数。
   3. 系统应该允许老板查看投手的转会信息和身价
4. 系统级需求？
   1. 在接到老板的请求后，系统应该为老板提供所有球星的相关信息。
5. 千万不要忘记业务需求，一定要基于业务需求出发。

需求分类

题型：对给定实例，给出不同类型的需求例子；对给定的需求示例，判断需求类型

需求谱系分类

1. 需求展开为三项，系统需求展开为三项

综合案例

1. 项目需求（人的数量、计划成本、时间）
   • R5：项目的成本要控制在 60 万元人民币以下。
   • R6：项目要在 6 个月内完成。
2. 过程需求（人的分工、合作、方法、工具）
   • R7：在开发中，开发者要提交软件需求规格说明文档、设计描述文档和测试报告。
   • R8：项目要使用持续集成方法进行开发。
3. 其他需求
   • R9：系统要购买专用服务器，其规格不低于….。
   • R10：系统投入使用时，需要对用户进行 1 个星期的集中培训。
4. 不切实际的期望
   • R11：系统要分析会员的购买记录，预测该会员将来一周和一个月内、会购买的商品；（技术上不可行）
   • R12：系统要能够对每月的出入库以及销售行为进行标准的财务分析；（在有限的资源条件下可行）
   • R13：在使用系统时，收银员必须要在 2 个小时内完成一个销售处理的所有操作。（超出了软件所影响的问题域范围）
5. 正确的形式
   • R14：如果一个销售处理任务在 2 个小时内没有完成，系统要撤销该任务的所有已执行操作

软件需求的分类（IEEE)

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

功能需求

1. 功能需求是最常见、最主要和最重要的需求，是能够为用户带来业务价值的系统行为
2. 最需要按照三个抽象层次进行展开，说明了关系
3. 软件产品产生价值的基础，需求检查最重要的部分
4. 比如：在接到客户经理的请求后，系统应该为客户经理提供所有会员的个人信息。

数据需求

1. 功能需求的补充：如果在功能需求部分明确定义了相关的数据结构，那么就不需要再行定义数据需求
2. 数据需求是需要在数据库、文件或者其他介质中存储的数据描述，通常包括下列内容：
   • 各个功能使用的数据信息；
   • 使用频率；
   • 可访问性要求；
   • 数据实体及其关系；
   • 完整性约束；
   • 数据保持要求。
3. 例如，连锁超市销售系统可以使用数据需求 DR1 和 DR2。
   • DR1：系统需要存储的数据实体及其关系为图 6-14 的内容。（数据实体及其关系）
   • DR2：系统需要存储 1 年内的销售记录和退货记录。（数据保持）

性能需求

1. 需要进行专门的模拟和测试
   • 速度（Speed)，系统完成任务的时间，例如 PR1。
     • PR1：所有的用户查询都必须在10 秒内完成。
   • 容量（Capacity)，系统所能存储的数据量，例如 PR2。
     • PR2：系统应该能够存储至少 100 万个销售信息。
   • 吞吐量（Throughput)，系统在连续的时间内完成的事务数量，例如 PR3。
     • PR3：解释器每分钟应该至少解析 5000 条没有错误的语句。
   • 负载（Load)，系统可以承载的并发工作量，例如 PR4。
     • PR4：系统应该允许 50 个营业服务器同时从集中服务器上进行数据的上传或下载。
   • 实时性（Time-Critical)，严格的实时要求，例如 PR5。
     • PR5：监测到病人异常后，监控器必须在 0.5 秒内发出警报。（和故障警报不同，故障不是系统的正常功能）
2. 一定避免使用很快、较快等修饰词，而如果难以估计明确，应当结合需求的灵活性，保证可行性。

需求的灵活性

1. PR6：98% 的查询不能超过 10 秒。
2. PR7：
   • （最低标准）在 200 个用户并发时，系统不能崩溃；
   • （一般标准）在 200 个用户并发时，系统应该在 80% 的时间内能正常工作；
   • （理想标准）在 200 个用户并发时，系统应该能保持正常的工作状态。

质量属性

1. 系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量
2. 质量属性是为了度量质量要素而选用的特征
3. 质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系
4. 质量属性的重要性
   • 对设计的影响很大
   • 对越复杂的系统越为重要
   • [Robert19901] ：真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往被满足功能性需求更为重要。

常见质量属性

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

质量属性的开发

1. 用户并不能明确地提出他们对产品质量的期望：并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组的可量化的质量属性
2. 需求工程师
   • 质量属性大都是和功能需求联系在一起的，因此需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性 ，形容词和副词通常意味着质量属性的存在
   • 对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要在碰到特定的实例时意识到它们的存在
   • 开发原型判断能不能保证可靠性等，和工程师进行确定

对外接口

1. 解系统和其他系统之间的软硬件接口：包括硬件接口、软件接口、数据库接口等
   • 接口的用途
   • 接口的输入输出
   • 数据格式
   • 命令格式
   • 异常处理要求
2. 用户界面
3. 案例，注册使用 Google Maps API

约束

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

R1：已过保质期的食品不能销售
R2：顾客可以使用美元付款

1. 提交的地址解析请求次数是否有限制？（这就是为什么 Google Map API 进行控制）
   • 如果在  24  小时时段内收到来自一个  IP  地址超过  15,000  个地址解析请求，或从一个  IP  地址提交的地址解析请求速率过快，Google  地图  API 编码器将用  620  状态代码开始响应。如果地址解析器的使用仍然过多，则从该  IP  地址对  Google  地图  API  地址解析器的访问可能被永久阻止。

一些说明

1. 整个需求：项目需求、过程需求、系统需求（包括软件需求、硬件需求和其他需求）
2. 软件需求有着三中不同的层次需求：业务需求、用户需求和系统需求，分类是按照性能需求等等。
3. 层次性：是指细节不一样，分类是指描述的东西不一样。

题目

1. 为了有效地捕获系统需求,应采用（C) 。 A.瀑布模型 B.V 模型 C.原型模型 D.螺旋模型
2. 软件开发过程中，需求分析阶段的输出不包括（D) A.数据流图 B.实体联系图 C.数据字典 D.软件体系结构图
3. "软件产品必须能够在 3 秒内对用户请求作出响应"属于软件需求中的（B) A.功能需求 B.非功能需求 C.设计约束 D.逻辑需求