文章目录
需求工程
需求的问题
- 用户不知道自己想要什么，或知道自己想要什么却无法描述清楚
- 产品经理、分析设计人员等在理解用户描述中更加偏差
概述
- “为什么要开发需求”、“如何得到需求”，要考虑到软件与现实世界的关系；单纯的软件系统是不能解决问题的，他只有和现实世界之间形成有效互动才能解决现实问题
- 软件建立的依据
先在现实世界中找到问题
抽象出问题及问题域知识
软件建模、构建方案，构建软件的solution
实现软件，形成软件程序
来源于现实，应用回现实
形成现实世界与软件世界的互动，互动过程要从需求工程开始
- 需求工程的概念：所有需求处理活动的总和；他收集信息、分析问题、整合观点、记录需求并验证其正确性，最终描述出软件被应用后与其环境互动形成的期望效应（需求的期望）
- 需求工程的三个主要任务
需求工程必须说明软件系统将被应用的应用环境及其目标（为什么做），说明用来达成这些目标的软件功能（要做什么），即同时说明软件需要“做什么”和“为什么”需要做
需求工程必须将目标和功能反映到软件系统中，映射为可行的软件行为（在需求阶段就要保持可行），并对软件行为进行准确的规格说明（即严格、详细、无歧义地描述软件规格/软件是什么）
现实世界是不断变化的世界，因此需求工程还需要妥善处理目标和功能随着时间演化的变动情况（即随整体世界（外部现实）的改变，solution也改变；交互） - 需求工程的活动
其中：
需求开发是为了生成整个开发过程、产生需求时做的活动
需求管理是伴随着整个开发活动的支撑服务（包括需求跟踪、究责等）
需求开发
需求开发过程模型
其中：
利害相关人：现实中与软件相关的所有人
需求规格说明之后产生文档
文档出来之后要与用户、开发人员进行确认
需求验证阶段发现不一致，就回退；不同原因导致的不一致回到不同阶段
需求获取
-
需求获取
从人、文档或环境当中获取需求的过程
要利用各种方法和技术来“发现”需求
目标分析：根据问题确定目标；通过分析利害关系人确定目标（即上图中“问题域”和“利害关系人”） -
需求获取的常见困难
困难描述 举例 解决方法 用户和开发人员背景不同、立场不同 “床边B超，肝胆胰脾” 消除默认知识 普通用户缺乏概括性、综合性的表述能力 不聪明的记者 专业需求人员（不要指望用户就把需求搞好） 用户存在认知困境 平板电脑 原型 用户越俎代庖 双机热备；“我就是希望系统能……，怎么实现是开发人员的事” 需求是开发人员开发出来的，不是用户提出来的；协商 缺乏用户参与 不愿参与的医生 为用户提供方便（这主要是给院长听的，如果一个医生有任务，其他事上要提供方便） -
用户需求获取的方法
面谈
问卷
文档分析（如果有文档资源）
头脑风暴
专题讨论
原型（不一定是一个软件什么的，可以基于原型软件工具，最基础的甚至可以是Story Board）
民族志（如为法官开发，就观察一段时间法官工作）
Story Board（敏捷的一种方式）为原型的图例
需求分析
- 需求获取之后，进行需求分析
- 需求分析
通过建模来整合各种信息，已使得人们更好的理解问题
为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案（即收集好信息要提供一种软件层面上的方案）
检查需求当中存在错误、遗漏、不一致等各种缺陷，并加以修正（方案们整理到一起） - 边界分析
定义项目的范围：什么是系统做的，什么事不是系统做的，确定好范围之后才能继续进行
系统边界定义要保证系统能够和周围环境形成有效的互动（确定哪些交互才是系统之内的）
系统用例图通常被用来定义系统的边界 - 需求建模：建模要用软件方式解释，抽象地描述信息；用软件表现来解决需求
建模是为了展现和解释信息而进行抽象描述活动
常用的技术包括类图、顺序图、状态图等建模技术
需求规格说明
- 需求分析之后要产生需求规格说明
- 需求规格说明
在系统用户之间交流需求信息，是交流的凭证（与用户交流、与后面的开发人员交流）（如究责时可用）
要简洁、精确、一致和易于理解（一致表示没矛盾，易于理解主要针对用户） - 需求工程师在此阶段重要工作包括：定制文档模版（属于团队内基本经验）、编写文档
需求验证
得到需求规格说明后需要对其验证，验证保证：
- 文档内每条需求都正确、准确地反应了用户的意图
- 文档记录的需求集在整体上具有完整性（所有的需求都具备）和一致性（前后描述一致）
- 文档的组织方式和需求的书写方式具有可读性和可修改性
验证方法有：
- 同级评审
- 原型（用开发出的原型（根据需求）来讨论）
- 模拟
需求管理
需求管理，如上章描述，属于配置管理项，要进入配置管理库；再事后确认等等都根据此
- 保证需求作用的持续、稳定和有效发挥
在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要以围绕需求开展工作 - 进行变更控制
一旦有变更，纳入和实现合理的变更请求，拒绝不合理的变更请求，控制变更的成本和影响范围
需求基础
什么是需求
概述 & 需求开发的目标
- IEEE的需求定义
用户为了解决问题或达到某些目标所需要的条件或能力
系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力
对前两点的一个条件或一种能力的一种文档化表达
注意：这个定义是从两个角度对于产品的期望和他们的文档化 - 需求的表述
作为一种期望（人的期望），需求通常被表述为“系统应该…”，“在…时，系统应该…”，“用户可以通过系统…”等，如例：
“系统应该允许顾客退回已经购买的商品” - 软件解决方案
需求是一种解决问题后所能达到的期望
一件事情的两面：问题（在现实世界）是糟糕的一面，需求（即期望）是理想的一面；两面之间的跨越就是软件(solution)
- 需求开发的目标
从问题域推导出规格
需求开发目标各元素
- 需求
是一种期望
源自现实高于现实
需求是多变和可调整的，项目可依据实际情况来调整需求的实现程度（不能脱离任何一方来看） - 问题域
现实世界运行规律的一种反映
需求产生地，也是需求的解决地（从现实中来，最终回到现实解决问题）
最终的软件产品要在现实中部署，它能够部分影响问题域，但不能任意改变现实
软件开发必须尊重问题域，不能因为技术原因妄自修改现实世界的实际情况（如AlphaGo不是为了碾压人类棋手，而是为了促进进步） - 问题的解决
基础：模拟与共享现象
软件世界会模拟现实世界，甚至会共享一些信息，这样才能用软件来解决现实问题
方法：直接与间接
解决方案：需求规格说明
通过规格说明展示软件到底怎么样（通过规格说明，规格说明为对软件的描述，来解决问题） - 规格说明
规格说明代表整个软件产品的方案（即做什么）
规格说明是对软件产品的方案描述，他以软件产品的运行机制为主要内容（规格说明描述软件产品的运行机制）
他不是需求但实现需求，不是问题域但需要与问题域互动
规格说明要以关注对外交互的方式描述软件解决方案，它既需要从软件产品的角度而不是用户的角度进行描述，又不能太多地涉及软件产品的内部构造机制（即描述的是做什么，而不是怎么做）
需求的层次
概述
业务需求：表达业务的目标和效果
最容易得到的就是业务需求，由业务需求推导下层需求
用户需求：某用户用系统做什么任务
知道了业务需求后，从问题域/领域知识来考虑我们到底要完成什么任务，这些任务能帮助解决前面的业务需求
系统级需求：系统行为表示系统与外界交互（即响应什么）（能更好地做需求分析模型）
注：丢开现实世界与软件世界中的任何一方谈需求都没有意义
业务需求
- 系统建立的战略出发点，表现为高层次的目标(objective)，他描述了组织为什么要开发系统
- 为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性(feature)
- 参与各方必须要对高层次的解决方案达成一致，已建立一个共同的前景(vision)
- 特性说明了系统为用户提供的各项功能，他限定了系统的范围(scope)
- 最终达成一个一致认可的业务需求
- 案例
R2: 在系统使用三个月后，销售额度应该提高20%
可以建立高层次的解决方案，其系统特性如SF1～SF4所示
SF1: 管理VIP顾客信息
SF2: 提供VIP服务，增加回头率
SF3: 使用多样化的特价方案，吸引顾客购买，增加销售额
SF4: 使用多样化的赠送方案，吸引顾客购买，增加销售额
注意：SF(system feature)中，如何具体做管理VIP顾客信息等还没有讲，代表着初步解决方案
用户需求
- 执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么
直接用户
间接用户（通用软件的销售人员和售后支持人员） - 对所有的用户需求，都应该有充分的问题域知识作为背景支持
- 特性
模糊、不清晰（允许适当的形容词和副词）
多特性混杂（功能和非功能的混杂）
多逻辑混杂（一个任务需要多次系统交互才能完成） - 针对每个系统特性，都可以建立一组用户需求，他们中每一条都是用户完成具体任务所需要的功能
- 案例
SF1: 管理VIP顾客信息
UR1.1: 系统应该允许客户经理添加、修改或者删除会员个人信息
UR1.2: 系统应该记录会员的购买信息
UR1.3: 系统应该允许客户经理查看会员的个人信息和购买信息
UR1.4: 系统应该允许客户经理查看所有会员的统计信息
注意：通过这些来达到管理 的目的（如它们对应的SF内容）；用户需求的描述中要指明谁来操作；部分内容依旧模糊，如“个人信息都是什么”，这就需要补充问题域知识 - 补充问题域知识
用户需求表达了用户对系统的期望，但是要透彻和全面的了解用户的真正意图，仅仅拥有期望是不够的，还需要知道期望所来源的背景知识
因此，对所有的用户需求，都应该有充分的问题域知识作为背景支持
例：
UR1.1: 系统应该允许客户经理添加、修改或者删除会员个人信息
对于此，需要补充问题域知识如下：
会员的个人信息有：客户编号、姓名、联系方式、积分
注：上例中，联系方式其实还可以再精细
系统需求
概述
- 用户对系统行为的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节
- 描述了开发人员需要实现什么
- 将用户需求转化为系统需求的过程是一个复杂的过程
将用户需求转化为系统级需求
- 首先需要分析问题域及其特性，从中发现问题域和计算机系统共享的知识，建立系统的知识模型
如上述，软件是对现实世界的模拟 - 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让他们联合起来实现用户需求，每一个系统行为即为一个系统需求（进一步清晰系统在交互过程中怎么做）
- 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动（通过用户需求明晰交互，想清楚系统需求什么样）
- 案例
对用户需求UR1.3，可以根据任务中的交互细节将之转化为系统级需求SR1.3.1~SR1.3.4
UR1.3: 系统应该允许客户经理查看会员的个人信息和购买信息
SR1.3.1: 在接到客户经理的请求后，系统应该为客户经理提供所有会员的个人信息
SR1.3.2: 在客户经理输入会员的客户编号时，系统要提供该会员的个人信息
SR1.3.3: 在客户经理选定一个会员并申请查看购买信息时，系统要提供该会员的历史购买记录
SR1.3.4: 经理可以通过键盘输入客户编号，也可以通过读卡器输入客户编号
功能需求的层次看需求开发
系统级需求后，产生分析模型
需求分类
需求谱系综述
注意：
- 软件需求下分为两类：功能需求和非功能需求，详述见下
- 中间一列中的“系统需求”与前面所述的需求层次的“系统级需求”不同：此处的系统需求所占地位是需求的不同方面（同列意为：项目方面需求-项目需求、过程方面需求-过程需求、系统方面需求-系统需求）指开发系统、描述系统的需求；上述的系统级需求所占地位是软件需求的不同层级，此层级上描述软件系统时从交互角度描述
不切实际的期望
- 例
R11: 系统要分析会员的购买记录，预测该会员将来一周和一个月内会购买的商品
R12: 系统要能够对每月的出入库以及销售行为进行标准的财务分析
R13: 在使用系统时，收银员必须要在2个小时之内完成一个销售处理的所有操作 - 正确的形式：不应该强求做到什么，而是应该对某种情况做出什么反应
R14: 如果一个销售处理任务在2小时之内没有完成，系统要撤销该任务的所有已执行操作
需求
项目需求
例
R5: 项目的成本要控制在60万元人民币以下
R6: 项目要在6个月之内完成
过程需求
例
R7: 在开发中，开发者要提交软件需求规格说明文档、设计描述文档和测试报告
R8: 项目要使用持续集成方法进行开发
系统需求
其他需求
R9: 系统要购买专用服务器，其规格不低于……
R10: 系统投入使用时，需要对用户进行一个星期的集中培训
功能需求
功能需求
- 功能需求(functional requirement)：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统能够执行的活动，这些活动可以帮助用户完成任务；功能需求主要表现为系统和环境之间的行为交互
- 功能需求是最常见、最主要和最重要的需求
- 功能需求是能够为用户带来业务价值的系统行为
- 功能需求是软件产生价值的基础
数据需求
- 数据需求是功能需求的补充：如果在功能需求部分明确定义了相关的数据结构，那就不需要再行定义数据需求
- 数据需求时需要在数据库、文件或者其他介质中存储的数据描述，通常包括：
各个功能使用的数据信息
使用频率
可访问性要求
数据实体及其关系
完整性约束
数据保持要求 - 示例
DR1: 系统需要存储的数据实体及其关系为如图6-14的内容
DR2: 系统需要存储1年内的销售记录和退货记录
非功能需求
性能需求(performance requirement)
- 性能需求是系统整体或系统组成部分应该拥有的性能特征，如CPU使用率、内存使用率等
- 性能需求需要进行专门模拟和测试
- 性能需求的几个方面
速度(speed)，系统完成任务的时间，如：
PR1: 所有的用户查询都必须在10秒内完成
容量(capacity)，系统所能存储的数据量，如：
PR2: 系统应该能存储至少100万个销售信息
吞吐量(throughput)，系统在连续的时间内完成事务数量，如：
PR3: 解释器每分钟应该至少解析5000条没有错误的语句
负载(load)，系统可以承载的并发工作量，如：
PR4: 系统应该允许50个营业服务器同时从集中服务器上进行数据的上传或下载
实时性(time-critical)，严格的实时要求，如：
PR5: 检测到病人异常后，监控器必须在0.5秒之内发出警报 - 性能需求一般都有数字，不能说“用户查询要很快完成”，因为这样的表述没法确定，不够准确
- 性能需求需要的准确数字也需要严格得来，不能拍脑袋，需要估算；估算由需求人员与开发人员一起完成
- 一旦这些性能需求写成了规格文档，他就是一份与客户的协议，就有了责任；写了就得实现，故一定要谨慎、准确、小心；不过可以有灵活性
- 需求的灵活性，例
PR6: 98%的查询不能超过10秒
PR7:
（最低标准）在200个用户并发时，系统不能崩溃；
（一般标准）在200个用户并发时，系统应该在80%的时间内能够正常工作；
（理想标准）在200个用户并发时，系统应该能保持正常的工作状态
质量属性(quality attribute)
- 质量属性：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等
- 系统为满足规定的及隐含的所有要求而需要具备的要素称为质量
- 质量属性是为了度量质量要素而选用的特征
- 质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系
- 质量属性的重要性
对设计的影响很大
对越复杂的系统越为重要（因为系统越复杂，质量差的代价越大）
真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往比满足功能性需求更为重要 - 常见质量属性
可靠性(reliability)：在规格时间间隔内和规定条件下，系统或部件执行所要求能力的能力，如：
QA1: 在进行数据的下载和上传中，如果网络故障，系统不能出现故障
可用性(availability)：软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率，如：
QA2: 系统的可用性要达到98%
安全性(security)：软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意，也可能是无意的，如：
QA3: VIP顾客只能查看自己的个人信息和购买记录；收银员只能查看，不能修改、删除VIP顾客的信息
可维护性(maintainability)：软件系统或部件能修改以排除故障、改进性能或其他属性或适应变更了环境的容易程度，包括可修改性(modifiability)和可扩展性(extensibility)，如：
QA4: 如果系统要增加新的特价类型，要能够在2人月之内完成
可移植性(portability)：系统或部件能从一种硬件或软件环境转换至另一种环境的能力，如：
QA5: 集中服务器要能够在1人月内从Windows7操作系统个更换到Solaris10操作系统
易用性(usability)：与用户使用软件所花费的努力及其对使用的评价相关的特性
QA6: 使用系统1个月的收银员进行销售处理的效率要达到10件商品每分钟 - 质量属性的开发
用户并不能明确地提出他们对产品质量的期望（他们可能提出期望，但是不会量化）：并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组的可量化的质量属性
需求工程师：质量属性大都是和功能需求联系在一起的，因此需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性；形容词和副词通常意味着质量属性的存在；对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要再碰到特定的实例时意识到它们的存在 - 质量需求由需求工程师和后面的技术工程师一起决定
对外接口(external interface)
- 对外接口：系统和环境中其他系统之间需要建立的借口，包括硬件接口、软件接口、数据库接口等
- 系统和其他系统之间的软硬件接口
接口的用途
接口的输入输出
数据格式
命令格式
异常处理要求 - 用户界面
约束
- 进行系统构造时需要遵守的约束
- 总体上限制了开发人员设计和构建系统时的选择范围
系统开发及运行的环境：包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等，如：
C1: 系统要使用Java语言进行开发
问题域内相关标准，包括法律法规、行业协定、企业规章等
商业规则：用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围 - 注意的一点：提交地址解析请求次数是否有限制（实例，Google API）
618
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
