需求基础

一、需求工程

需求工程分为：需求开发、需求管理

需求开发：

  • 需求获取

  • 需求分析

  • 需求规格说明

  • 需求验证

需求工程的概念：知识点

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

主要任务：

  • 同时说明软件需要“做什么”，“为什么”需要做

  • 将目标和功能映射为可行的软件行为

  • 妥善处理目标和功能随时间演化的变动情况

需求工程的活动：知识点

需求开发过程模型：知识点

需求获取

从人、文档或者环境当中获取需求的过程，要利用各种方法和技术来发现需求

主要任务：

1、目标分析

  • 根据问题确定目标

  • 通过分析利害关系人确定目标

用户获取需求的方法：知识点

  • 面谈

  • 问卷

  • 文档分析

  • 头脑风暴

  • 专题讨论

  • 原型

  • 民族志

  • 竞品分析

需求分析

  • 通过建模来整合出信息，以使人们更好的理解问题

  • 为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案

  • 检查需求当中存在的错误，遗漏，不一致等各种缺陷，并加以修正

知识点：

一、边界分析

  • 定义项目的范围

  • 系统边界的定义，要保证系统能够和周围环境形成有效的互动

  • 系统用例图：通常用来定义系统的边界

二、需求建模

  • 为展现和解释信息而进行的抽象描述活动

  • 常用的技术包括类图、顺序图、状态图等建模技术

需求规格说明

在系统用户之间交流需求信息，要简洁、精确、一致和易于理解

  • 定制文档模板

  • 编写文档

标准：

  • 每条需求正确反映用户意图

  • 需求集在整体上具有完整性和一致性

  • 组织方式和需求书写方式可读性可修改性

需求验证

方法：同级评审、原型、模拟

需求管理

  • 保证需求作用的持续、稳定和有效发挥

  • 进行变更控制

二、需求基础

什么是需求？

需求的定义：知识点

  • 用户为了解决问题或达到某些目标所需要的条件或能力

  • 系统或系统部件为了满足合同，标准，规范或其他正式文档所规定的要求而需要具备的条件或能力

  • 对1或2中的一个条件或一种能力的一种文档化表述

需求的表述

  • 系统应该…

  • 在…时，系统应该…

  • 用户可以通过系统…等

（系统应该允许顾客退回已经购买的产品）

需求开发的目标：知识点

问题域

现实世界运行规律的一种反映，是需求的产生地也是解决地。

最终的产品在现实中部署，可以影响问题域，但是不能任意改变现实

解决方法：需求规格说明

规格说明：知识点

软件产品的方案描述，以软件产品的运行机制为主要内容，

不是需求但实现需求，不是问题域但需要与问题域互动

规格说明要以对外交互的方式描述解决方案，既要从产品的角度而不是用户的角度描述又，不能太多地涉及软件产品的内部构造

需求层次性：知识点

  • R2：在系统使用三个月后，销售额度应该提高20%

  • R3：系统要帮助收银员完成销售处理

  • R4：收银员输入购买的商品时，系统要现实该商品的描述、单价、数量和总价

业务需求：知识点

  • 战略出发点（Objective）：表现为高层次的目标，描述了组织为什么要开发系统

  • 特性（feature）：为了满足用户的业务需求，需求工程师要描述系统高层次的解决方案，定义系统应该具备的特性

  • 前景（vision）：参与方对高层次的解决方案达成一致，以建立一个共同的前景

  • 范围（scope）：特性说明了系统为用户提供的各项功能，限定了系统的范围

例如：基于销售额提高20%的战略出发点，定义高层次的解决方案feature：（系统特性）

  • SF1：管理VIP顾客信息

  • SF2：提供VIP顾客服务，增加回头率

  • SF3：使用多样化的特价方案，吸引顾客购买，增加销售额

  • SF4：使用多样化的赠送方案，吸引顾客购买，增加销售额

用户需求：知识点

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

  • 直接用户、间接用户（通用软件的销售人员和售后支持人员）

  • 对所有的用户的需求，都应该有充分的问题域知识作为支持背景

特性：模糊、不清晰（适度的用形容词和副词）；多特性混杂；多逻辑混杂（一个任务需要多次系统交互才能完成）

例如：针对SF1管理VIP顾客信息，可以建立用户需求：

  • UR1.1：系统应该允许客户经理添加、修改或者删除会员个人信息。

  • UR1.2：系统应该记录会员的购买信息

  • UR1.3：系统应该允许客户经理查看会员的个人信息和购买信息

  • UR1.4：系统应该允许客户经理查看所有会员的统计信息

补充问题域知识

获得用户真正的意图还需要背景知识，例如如果要系统允许客户经理修改会员个人信息，先要补充会员的个人信息有哪些？客户编号、姓名、联系方式、积分

系统需求

用户对系统行为的期望。每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节。

描述了开发人员需要实现什么

例如：对用户需求UR1.3，系统应该允许客户经理查看会员的个人信息和购买信息，可以细分为系统级需求：

  • SR1.3.1：在接到客户经理的请求后，系统应该为客户经理提供所有会员的个人信息。

  • SR1.3.2：在客户经理输入会员的客户编号时，系统要提供该会员的个人信息

  • SR1.3.3：在客户经理选定一个会员并申请查看购买信息时，系统要提供该会员的历史记录

  • SR1.3.4：经理可以通过键盘输入客户编号，也可以通过读卡器输入客户编号

从功能需求的层次性看需求开发：知识点

练习：NBA数据分析应用

自己的答案：

业务需求：球迷希望知道比赛中选手在比赛中的综合水平

用户需求：

  • 系统应该能够显示在一场比赛中每名选手的得分情况；

  • 系统应该能够显示某名球员在每场比赛中的得分情况；

系统需求：

  • 在接到球迷的选择比赛的请求后，系统应该为球迷提供某个比赛的详细信息和参赛球员

  • 球迷可以通过输入姓名搜索某名球员

  • 球迷点击某个球员的头像后，系统可以为其提供球员的详细信息

  • 球迷点击统计后，系统可以生成球迷的得分情况折线图

三、需求分类

需求图谱

  • 项目需求：（项目的成本要控制在60万元人民币以下）

  • 过程需求：（开发者要提交软件需求规格说明文档）

  • 其他需求：（系统要购买服务器，其规格不低于…）

  • 不切实际的期望：（预测会员一周内会购买商品；表进行标准财务分析；收银员要在2小时内完成一个销售处理的所有操作）

  • 正确的形式：如果2小时没完成则撤销已执行操作

需求的分类IEEE：知识点：

功能需求、性能需求、质量属性、对外接口、约束

  • 功能需求：常见主要，能够为用户带来业务价值的系统行为

  • 性能需求：速度容量吞吐量负载实时性（最低标准、一般标准、理想标准）

  • 质量属性：系统为了满足规定的及隐含的所有要求而具备的要素

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

  • 约束：进行系统构造时需要遵守的约束，例如编程语言，硬件设施等

知识点：

  • 可靠性：数据下载上传中，如果网络故障，系统不能出现故障

  • 可用性：系统的可用性要达到98%

  • 安全性：收银员只能查看，不能修改、删除VIP顾客的信息

  • 可维护性：如果系统要增加新的特价类型，要能够在2个人月内完成

  • 可移植性：集中服务器要能够在1人月内从Windows7操作系统更换到Solaris10操作系统

  • 易用性：使用系统1个月内的收银员进行销售处理的效率要达到10件商品/分钟

质量属性的开发：需求工程师，需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性

对外接口：知识点

解系统和其他系统之间的软硬件接口；用户界面

  • 接口的用途/输入输出/数据格式/命令格式/异常处理要求

约束：知识点

总体上限制了开发人员设计和构建系统时的选择范围（运行环境、问题域内的相关标准、商业规则）

​

数据需求：知识点

功能需求的补充，存储的数据描述（各个功能使用的数据信息、使用频率、可访问性要求等等）

项目实践，有没有性能需求、质量需求、对外接口、约束、数据需求？