需求分析第二章

第二章：需求基础

需求的定义

1.用户为了解决目的或达到某些目标所需的条件或能力；
2.系统或系统部件为了满足合同，标准，规范或其他正式文档所规定的要求而需要具备的条件和能力；
3.对1,2中的条件与能力的文档化表达

满足需求就是解决问题

问题：当现实与人们期望的状况产生差距时，就产生了问题

人们开发软件系统的目的：就是希望用它作为解决方案来解决问题，使得实现改善到期望的状况

问题解决的两个方面——问题域与解系统

问题域：问题解决的基本范围——解决问题必须涉及的事件和事物（实体，状态）

问题域与需求的区别:
1.问题域是自治的，可以有自己的运行规律，这些规律不会因为解系统的引入而发生改变
2.需求是一种对未来的期望，是可以打折，部分满足甚至不予满足的
3.问题域是既定事实，可以改善，但不能忽略，更不能违背

解系统
软件系统通过影响问题域帮助人们解决问题（解决方案，及其实现）

用户关注问题域
软件开发人员更加关注解系统
需求工程师扮演一个桥梁的作用

问题域与需求
需求是用户对问题域中实体状态或事件的期望描述

解系统与需求规格说明：
解系统核心：软件解决方案（软件系统的需求规格说明） 软件解决方案在通用计算机上的实现

软件工程仅仅关心解决方案，不涉及软件的实现细节（开发者）

问题解决的基础——模拟与共享现象

问题域与解系统之间存在有效的互动，并在互动中相互影响

交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分具有模拟特性

问题解决的方法——直接与间接

直接：模拟并操控共享现象是软件系统满足需求最直接的方法
间接：软件系统操控共享现象影响问题域的一部分，然后利用问题域内在规律自动性影响另一部分

如何选择: 考虑问题解决和需求满足的方法，成本是最重要的因素。如果成本能够接受，就尽量使用直接的方式解决，如果成本太高，就可以折中使用间接方式解决

问题解决方案——需求规格说明

需求规格说明：对共享现象的描述 对系统对共享现象所施加的操作的描述
这也是软件系统核心： 数据 功能

问题解决的困难性

描述明确的问题域特征 E
定义良好的系统行为 S
预期需求 R

问题解决的困难：
1.不存在描述明确的E
2.不存在确定的针对S的评估标准R
3.E,R=>S是一个创造性的过程，即根据问题域特性和期望的系统应用效果构建系统行为是困难的

需求工程的主要工作：
1.进行需求开发，确定用户的期望效果R
2.研究问题背景，描述问题域特性E
3.构建解系统，描述解系统行为S，使得E,S|—>R.

需求和问题都有层次性

需求的层次性

战略问题与业务需求

业务需求：抽象层次最高的需求，是系统建立的战略出发点。

业务需求必须是可验证的，其检验标准可以是一个数值指数或布尔指数（通过研究问题域的背景资料得出的）

需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（feature），参与各方必须就此解决方案达成一致，以创建一个共同的前景（vision），系统特性说明了系统为用户提供的各项功能，限定了系统范围（scope)

业务需求BR ，系统特性SF

任务问题与用户需求

用户需求：执行实际工作的用户，对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么

用户的任务应该是有目的性，有价值的

基本表达：“xx用户可以使用系统完成xx任务”

用户需求可以是不可验证性的，因为用户需求有以下特点:
1.模糊，不清楚
2.多特性混杂
3.多逻辑混杂

用户表达期望时，通常不会提及需求所涉及的问题域知识，需要补充问题域知识

用户需求 UR

系统行为问题与系统级需求

系统级需求：关注系统的行为，尤其是系统与外界的交互行为

基本表达：“系统可以xx”或“在xx用户提出xx请求时，系统应该xxx”

系统级需求比用户需求 更详细，数量更多

将用户需求转化为系统需求是一个复杂的过程，技术加工的过程被称为需求分析

系统级需求SR

需求开发要遵从层次性

层次关系

业务需求————>项目前景和范围文档
用户需求————>用例说明文档
系统需求————>需求规格说明文档（SRS）

需求的分类与描述

需求的分类

广义上分类

严格意义上分类（功能需求和非功能需求）

ps：用户在描述中使用的形容词和副词通常意味着质量属性的存在
约束（不受解系统影响，却给解系统带来影响的问题域特征）

约束分类：

• 系统开发及其运行环境

• 问题域的相关标准

• 商业规则

• 社会性因素

优秀需求的特性

• 完备性
• 正确性：多问用户“为什么”，从业务方面描述需求
• 可行性
• 必要性
• 无歧义
• 可验证