05-需求基础

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

1. 一个产品的开发过程

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

2. 需求工程的内容

2.1. 软件建立的依据

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

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

2.4. 需求开发过程模型

2.5.5. 重新认识需求获取

1. ?户和开发?员的背景不同，?场不同：“床边B超,肝胆胰脾”：消除默认知识
2. ?户存在认知困境：平板电脑：原型(做一个原型帮助用户理解的草图模型)
3. ?户越俎代庖
   • 双机热备：需求是开发人员开发出来的，不是?户提出来的
   • 我们就是要求系统能够…，?于怎么实现是你开发者的事：协商
4. 缺乏用户参与：不愿参与的医?：为用户参与提供?便

2.6. 需求分析

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

2.6.1. 边界分析

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

2.6.2. 需求建模

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

2.7. 需求规格说明

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

2.8. 需求验证

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

2.9. 需求管理

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

3. 需求基础

3.1. 需求 重要

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

3.2. 需求的表述方式

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

3.3. 软件解决方案

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

3.4. 需求开发的目标

4. 三种需求层次:业务需求、用户需求、系统级需求(需求的层次性)

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

4.1. 业务需求(目标，解决方案与系统特性)

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

4.2. 用户需求(任务，问题域知识)

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

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

4.3. 系统需求

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

4.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. 问题域：存钱、取钱、转账(用户需求)

4.5. 课堂练习

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

5. 需求分类

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

5.1. 需求谱系分类

5.3.5.1. 常见质量属性

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

5.3.5.2. 质量属性的开发

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

5.3.6. 对外接口

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

5.3.7. 约束

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

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

5.4. 一些说明

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

6. 题目