软件工程课程第七章-需求

1. 什么是需求？

需求是对系统必须做什么或它需要具有什么特性的简单声明。（重点是分析阶段的业务用户需求、随着项目从分析到设计再到实现，需求会随着时间的推移而变化）

1. 功能性和非功能性需求

1. 功能性需求

1. 系统应提供的服务说明、系统应如何对特定的输入作出反应，以及系统在特定情况下应如何表现
2. 说明系统不应该做什么

1. 非功能性需求

1. 对系统提供的服务或功能的限制，如时间限制、对开发过程的限制、标准等
2. 通常适用于系统作为一个整体，而不是单个的特性或服务。

1. 功能性需求详述

• 一个系统的功能需求描述了这个系统应做什么
• 这些需求取决于正在开发的软件类型、软件的预期用户，以及组织在编写需求时所采取的一般方法。
• 功能性需求举例

1. 用户应能够搜索所有诊所的预约名单。
2. 该系统应为每个诊所生成一份当天预约的患者名单。
3. 使用该系统的每个员工都应由其八位数的员工编号进行唯一标识。

1. 非功能性需求详述

1. 与紧急的系统属性有关，如可靠性、响应时间和存储占用率
2. 定义系统实现的约束，例如I/O设备的功能或与其他系统接口中使用的数据表示。
3. 非功能需求通常比个别功能需求更重要。
4. 这些要求的实现可以分散到整个系统中：

1. 非功能性需求可能会影响系统的整体体系结构，而不是影响单个组件。
2. 一个单一的非功能需求，如安全需求，可能会产生许多相关的功能需求，以定义所需的新系统服务。

1. 非功能性需求的类型

1. 功能性需求和非功能性需求之间没有明显的区别

需求是功能性需求还是非功能性需求取决于:

在需求文档中包含的详细级别上

存在于系统客户和系统开发人员之间的信任程度

1. 产品需求示例

1. 系统服务X的可用性应为999/1000或99.9%。

（这是一个可靠性要求，这意味着在该服务的每1000个请求中，必须满足999个。）

1. 系统Y应每秒至少处理8次事务。

（这是一个性能要求。）

1. 系统Z的可执行代码应限制在512k字节以内。

（这是一个资源需求，它指定了系统的最大内存大小。）

1. 过程需求示例

1. 要使用的开发过程必须被明确地定义，并且必须符合ISO 9000标准
2. 该系统必须使用XYZ系列CASE工具套件进行开发。
3. 必须每两周制作一次在每个确定的系统组件所花费的管理报告。
4. 必须指定系统开发指定灾难恢复计划。

1. 外部需求示例

1. 医疗数据系统该组织的数据保护工作人员必须证明所有数据都是根据数据保护法规进行维护的。
2. 使用子公司主要语言来生成子公司报告

1. 需求工程

• 需求工程定义：发现、分析、记录和检查这些服务和约束条件的过程。
• 需求工程的任务

1. 起始（启发阶段）：要建立基本的理解，包括存在的问题，谁需要解决方案，所期望解决方案的性质，与项目利益相关者和开发人员之间达成初步交流合作的效果。
2. 获取（导出）：从所有利益相关者中引出需求（有效整理需求）
3. 细化（精化）：创建一个识别数据、功能和行为需求的分析模型
4. 协商：对开发人员和客户实际可行的可交付系统达成一致
5. 规格说明：可以是一份写好的文档，一套图形化的模型，一个形式化的数学模型，一组使用场景，一个原型或上述各项的任意组合。（文档化）
6. 确认（正式的技术评审是最主要的确认机制-检查）内容或解释上的错误；需要进一步澄清的地方；丢失的信息；不一致性（这是建造大型产品或系统时遇到的主要问题）；冲突的需求或者不可实现（不能达到）的需求
7. 需求管理：需求的变更的要求贯穿于系统的整个生命周期。需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动

• 启动阶段（Inception）（会找利益相关者）

1. 确认利益相关者（直接或间接的从正在开发的系统中获益的人）：在开始阶段，需求工程师应该创建一个人员列表，列出那些有助于获取需求的人员。最初的人员列表将随着接触的利益相关者人数的增多而增加，因为每个利益相关者都将被询问“你认为我还应该和谁交谈”。
2. 识别多重观点
3. 协同合作
4. 首次提问

①谁是这个工作的幕后需求

②谁将用这个解决方案

③一个成功的解决方案的经济效益是什么？

④你需要的解决方案有其他来源吗？

• 确定利益相关者的案例

1. 确定精神卫生保健患者信息系统的利益相关者

1. 信息被记录在系统中的患者。
2. 负责评估和治疗病人的医生。
3. 协调与医生的咨询并进行一些治疗的护士。
4. 管理病人预约的医务人员。
5. 负责安装和维护系统的IT人员。
6. 医疗道德经理，必须确保系统符合当前病人护理的道德准则。
7. 从系统中获取管理信息的医疗保健经理。
8. 负责确保系统信息能够得到维护和保存，以及记录保存程序已得到妥善执行的医疗记录工作人员

1. ATM利益相关者

①银行部门的客户②其他银行的代表 ③银行业务经理④柜台工作人员⑤“数据库”管理员 ⑥ “安全部经理” ⑦市场部⑧软硬件维护工程师⑨银行监管机构

• Eliciting Requirements（获取需求）

• 协作性的收集需求

• 会议由软件工程师和利益相关者共同举办和参与

• 制定筹备和参与会议的规则。
• 建议拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的要点，但也不能太正式，以鼓励思维的自由交流。
• 由一个“主持人”（可以是客户，开发人员或其他人）控制会议
• 采用“方案论证手段”（可以是工作表，活动挂图，不干胶贴纸，电子公告牌，聊天室或虚拟论坛）
• 协作收集需求的目标是：标识问题、提出解决方案的相关元素、协商不同方法以及确定一套解决需求问题的初步方案。

1. 获取需求的方式

• 访谈
• 问卷调查
• 分析资料
• 实地考察
• 选择合适的方式：信息的深度、信息的广度、信息的整合度、用户参与度、花费（开销）

1. 质量功能部署（QFD）

• 将客户要求转化成软件技术需求的技术
• 从软件工程过程中最大化客户的满意度。
• 功能部署-确定系统所需的每个功能的“价值”（由客户感知）
• 价值分析-确定需求的相对优先级

• 常规（正式）需求：在会议中向客户陈述一个产品或系统时的目标，如果这些需求存在，客户就会满意。
• 期望需求：在产品和系统中客户没有清晰表达的基础功能，缺少了这些将会引起客户不满
• 兴奋需求：超出客户预期的需求，当这些需求存在时令人非常满意

1. 获取需求：

1. 用户场景：（用例）-标识使用情况的线程
2. 获取工作产品（Elicitation Work Products）

• 要求和可行性的陈述。
• 系统或产品范围的界限说明。
• 参与需求获取的客户、用户和其他利益相关者的列表
• 系统技术环境的描述。
• 需求列表（最好按功能组织）以及每个需求适用的领域限制。
• 一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用。
• 任何能够更好地定义需求的原型。

1. 细化需求，建立需求模型

掌握各类元素的特点

需求模型的元素：

• 基于场景的元素

• 用例-参与者”和系统之间交互的描述
• 用例图（作为输入）
• 活动图/泳道图

• 基于类的元素：类图。每个使用场景都意味着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类-具有相似属性和共同行为的事物集合UML
• 行为元素：行为图、状态图。基于计算机的系统行为能够对所选择的设计和所采用的实现方法产生深远影响。
• 面向流的元素：数据流图

1. 简要用例的示例

用户暗示她希望订购被选中的商品。

该系统将显示用户以前存储的账单和运输信息。

用户将确认现有的账单和发货信息应用于此订单。

该系统将显示订单的成本金额，包括适用的税收和运费。

用户将确认订单信息是否准确。

该系统将为用户提供一个针对订单的跟踪ID。

1. 协商（细化）需求（Negotiating Requirements）

• 确定主要的利益相关者（这些人将参与协商）
• 确定每个利益相关者的“获胜条件”（获胜的条件并不总是很明显的）
• 协商（细化）：朝着一系列能导致“双赢”的要求而努力

用例图

1. 规格说明
2. 确认
3. 需求管理