【读书笔记】软件工程·实践者的研究方法第7版 第二部分 建模 第5章 理解需求

需求工程（Requirement Engineering,RE）:致力于不断理解需求的大量任务和技术。

需求工程在设计和构造之间建立起联系的桥梁。

需求工程通过执行七个不同的活动来实现：起始、导出、精化、协商、规格说明、确认和管理

起始：确定了商业要求或潜在市场，业务领域的利益相关者定义业务用例。

导出：产品的目标是什么、要实现什么，最终系统或产品如何用于日常工作。包括：范围、理解（双方理解）、易变

精化：开发一个精确的需求模型（分析类的属性、方法、类之间的协作）

协商：需求排序、按优先级讨论冲突，修改需求

规格说明（软件需求规格说明SRS）：在系统非常复杂或设计十分重要的业务时非常必要。可以是文档、图形化的模型、数学模型、一组场景、原型或任意组合

确认：对需求工程的工作产品进行质量评估。正式的技术评审是最主要的需求确认机制。

需求管理：标识、控制和跟踪需求一级需求变更的一组活动。

以下大概描述了需求获得的过程和方法：

建立根基

利益相关者：直接或间接地从正在开发的系统中获益的人。

识别多重观点：多个角度收集信息时，所形成的需求可能不一致或矛盾

协同合作：标识公共区域（一致同意的需求）和矛盾区域

首次提问（Q&A会议）用于首次接触打破坚冰：1、环境无关问客户和相关利益者；2、问开发组；3、“元问题”关注提问本身的质量

导出需求：

需求收集会议产生功能描述，与会者列出：

1、系统周围环境对象

2、系统产生的其他对象

3、系统用来完成功能的对象

4、服务操作（方法）和对象交互的服务（过程或功能）

5、约束列表（成本、规模、业务规则）

6、性能标准

修改调整以上列表，生成系统的对象、服务约束和性能的列表。为每个条目编写小规格说明（+用例），此过程可能会增改原列表

这部分书上原文的小结：

项目利益相关者建立基本的问题需求，定义最重要的项目约束以及陈述主要的特征和功能。利用有主持人的会议，QFD和使用场景的开发进行需求收集活动。

质量功能部署（Quality Function Deployment,QFD）:将客户要求转化成软件技术需求的质量管理技术。以最大限度地满足客户的方式来定义需求。

用户场景：场景通常被称为用例，描述了如何使用系统。

导出工作产品：

1、要求和可行性描述

2、范围界限说明

3、客户、用户和相关利益者

4、技术环节的说明

5、需求列表

6、一系列场景

7、原型

用例：讲述了能表达主题场景的故事；最终用户如何在一特定环境下和系统交互。从用户的角度描述了软件或系统。

1、首先确定参与者，参与者：任何与系统或产品通信的事务，对系统本身而言是外部的。UML中的火柴人（可以是另外一个系统，存储器等非人）

2、询问参与者：1、目标；2、故事的前提；3、主要工作和功能；4、异常情况；.......

基本的用例：从较高层次上给出参与者和系统之间交互的故事。

3、画用例图，“传感器”应该用火柴人，但形式不是最重要的，重点是交流，方框示意更清楚



构建需求模型：（分析模型=需求模型）

分析模型：给出系统必须的信息、功能和行为域的说明。是任意给定时刻的需求快照（对应变更）

三种建模元素：

1、场景：基于场景的方法从用户的视觉描述系统。用例图

2、类：类暗示着场景中交互时操作的一组对象，类图

3、行为：事件，状态图

4、数据流：针对系统中的数据形式，输出输入建模。属性集、数据结构

协商需求：双赢最好

确认需求：检查一致性、歧义性，有无遗漏。过细？可测试？可实现？简化没？

这一章仍然不是重点。主要讲述了需求获得的过程，简介了需求建模，为下一章提供了准备。

之所以看这本书，主要是要考研，科目：上海交通大学软件学院825软件学科基础。没有拿到最新的课件，课件上说的跟书本的章节排版不太一致