4.1 需求的过程
4.1.1 需求 requirement
1. 需求的定义
定义：对来自用户的关于软件系统的期望行为的描述、处理的是类、类的状态、改变这些状态或对象的函数。
定义：对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象或实体（objects or entities）、状态（state）、改变这些状态或对象的函数。
任务（聚焦）：理解客户的问题和需求，针对的是客户和问题，不是问题和实现
项目失败的主要原因：
①不完整的需求
②缺少用户参与
③不切实际的期望/需求
④缺乏行政及政策支持
⑤需求和规格说明的变更
⑥缺乏计划
⑦系统不再需要了
4.1.2 确定需求的过程
2. 需求的过程
最终产出outcome：Software Requirements Specification（SRS）软件规格说明文档
①原始需求获取 Elicitation：客户给出的需求
②问题分析 Analysis：理解需求并通过建模或模型化方式进行描述
③规格说明草稿 Specification：利用符号描述系统将定义规范化表示
④需求核准 Validation：开发人员与客户进行核准
⑤软件规格说明（SRS）
4.1.3 补充材料：
问题：需求分析时，若小团队且需求不确定，可采用敏捷开发方法；若大团队进行需求确定的开发时可采用“重量级”过程。
① 敏捷开发方法（agile methods）的需求建模
适用范围：小团队，不确定的需求
方法：增量式开发（或迭代式开发）
XP是一种敏捷开发
② “重量级”过程
适用范围：大团队，确定的需求
特点：开发人员将编码推迟到已经对需求进行了建模和分析，详细的设计已完成，其中每一步都需要模型，模型间是相关的、相互配合的，以便于设计完全实现需求。
4.2 需求的引出
需求的引出是极为重要的一部分，我们必须使用各种技术来确定客户和用户到底想要什么。
4.2.1 风险承担者
风险承担者包括：委托人（clients），客户（customers），用户（users），领域专家（domain experts），市场研究人员（market researchers），律师或审计人员（lawyers or auditors），软件工程师或其他技术专家（software engineers）
4.2.2 需求引出的具体手段
①与风险承担者（stakeholders）进行会谈
②评审相关文档
③观察当前系统
④做用户的学徒，当用户进行任务时更详细的进行学习
⑤以小组形式与用户和风险承担者交谈
⑥使用特定领域的策略
⑦就如何改进产品，与当前的和潜在用户进行集体讨论
4.3 需求的类型
3. 需求的分类
请求客户对需求进行优先级划分通常是有用的，这可以迫使客户思考提议的服务或特征中哪些是最重要的。
一种大致的优先级划分方案可能将需求分为3类：
- essiential基本的：必须要满足的需求
- desirable期望的：非常值得做但是不是必须的需求
- optional可选的：可选的需求（可做可不做）
举例：信用卡记账系统必须能够列出最近的费用，将他们加起来并要求在某个日期前支付，这是必须的需求。但是，该记账系统也可能按照购买类型区分费用，以帮助消费者理解购买的模式，这是值得要的需求。最后，记账系统可能要求用黑色来打印贷方账目，用红颜色打印借方账目，这用需求是有用的，但它是可选的需求。
按照类型对需求进行优先级的分类，能够帮助所有相关人员理解自己到底需要什么。
当软件开发项目受到时间或资源的限制时，如果系统的成本太高或者开发的时间太长，就可以去掉可选需求，并对值得要的需求进行分析，考虑是去掉还是延期。还可解决与质量需求之间的矛盾。
4.3.1 需求的类型
5. 功能性需求 非功能性需求 质量需求 设计性约束 过程约束
学会区分
① 功能需求 Functional requirement：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。（例：系统必须完成自动计算工资功能，系统必须存储每次的用户操作记录）
② 设计约束 Design constraint：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。（例：系统要采用ARM 64架构设计）
③ 过程约束 Process constraint：对用于构建系统的技术和资源的限制，涵盖资源、文档，标准等方面。
④ 非功能需求/质量 Quality requirement or non-functional requirement：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。（例：用户工资查询的响应式时间小于5秒）
4.3.2 解决冲突
需求的优先级划分
当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的
①必须要被满足的需求
②非常值得做但是不是必须的需求
③可选的需求（可做可不做）
(2)使需求变得可测试方法：
①针对需求确定一种量化的描述方法，避免模糊的表达方式
②将各种指代用词替代为实体的正式名字
③每个名词或事项应在需求文档中给出唯一定义
4.3.3 两种需求文档（需求文档化）
(1) 需求定义
完整罗列了客户期望的需求
(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。
需求定义和需求规格说明的关系如下图所示：
(3)补充材料：
配置管理：使软件过程各阶段文档保持一致的系列过程。软件配置管理：
定义：一种标识、组织和控制修改的技术，目的是最有效的提高生产率，能够协调软件开发，使混乱减少到最小。
任务：制定软件配置管理计划；确定配置表示规则；实施变更控制；报告配置状态；进行配置审核；进行版本管理和发行管理。
与软件开发过程的区别：变更的评估和批准都需要由软件配置管理人员去做，开发过程应纳入配置管理过程的控制之下。
忽视软件配置管理可能导致的混乱现象：发错了版本，安装后不工作，异地不能正常工作，已经解决的缺陷过后又出现错误，开发人员把产品拿出去出售赢利，找不到最新修改了的源程序，找不到编程序的人
4.4 需求的特征
需求的特征：
正确性；一致性；无二义性；完备性；可行性；相关性；可测试性；可跟踪性
4.5 需求的表示
1. E-R图
比较流行的图形化表示，用来表示概念
实体-关系-属性
结构稳定 容易了解
缺点：没有提供实体行为
实体：用一个矩形rectangle表示，代表用友共同属性和行为的一个真实世界的物体的集合
关系：用两个实体间的边表示
属性
E-R图流行的原因：
- 提供了一个解决问题的整体
- 当问题的需求有变化时，视角比较稳定
UML (Unified Modeling Language)
7. UML活动图
用于系统功能的建模，强调对象之间的控制流
UML类图 class diagram（以类和对象为基础，对简单的协作进行建模，以及对逻辑数据库模式进行建模）
系统结构的图形化工具
UML状态图 state diagram
对特定对象所有可能的状态、以及各种事件的发生而引起的状态转移，对于类/写作的行为建模非常重要
8. 依赖关系
依赖关系是类之间存在的短暂的非结构化的使用关系
类之间的关系：
聚合（has-a）：部分类对象是多个整体类对象的组合，例：一名学生同时参与多个兴趣小组；空心菱形
组合：物理上由xxx组成，用实心黑色菱形
泛化/实现（is-a）：在一端有一个三角形来表示
ppt实例Answers：
Association
Aggregation
Composition
Aggregation
2. Event trace 事件追踪
一个实体是一个竖线 中间数据流通 实体 六边形表示事件
Message Sequence Chart 消息序列图MSC
例子：一个用户打开微信扫描二维码支付流程
1，用户输入手机密码
2，打开手机
3，打开微信扫一扫
4，返回微信扫一扫界面
5.1 扫描商家收款码
5.2 商家生成收款二维码
5.3 返回收款二维码
5.4 识别商家收款码
6，提示用户输入微信支付密码
7.1 输入微信支付密码
7.2 微信验证用户输入密码正确
7.3 向商家汇款
7.4 汇款成功
8，提示用户支付成功
3. state machine 状态机
系统跟环境的所有对话的图形化表示
方块表示状态集合
要素：
- 点：状态
- 边：转移，事件发生带来行为
UML Statement Diagrams
Petri Nets
4. data-flow diagram (DFD) 数据流图
6. 数据流图 DFD
便于用户理解和分析系统数据、流程的图形工具，摆脱了系统和具体内容，在逻辑上描述了系统的功能、输入、输出、DS，是系统逻辑模型的重要组成部分
具体绘图也许要会吧（没说）
定义：从一个功能到另一个功能的数据功能建模
要素：源泉 数据流 数据存储 对象
优点：高层次功能的直观模型、不同处理/加工之间数据依赖关系的直观模型
缺点：对于一个不熟悉这个被建模的问题的的软件开发者会加重歧义性
Use Cses 用例图
框：表示系统边界
任务线条（系统边界之外）：参与者（用户/系统）
椭圆形（系统边界之内）：用例，表示重要功能或变体
线：（在actor和use case之间）：表示参与者参与用例
5. 函数与关系 Functions and Relations
完备的
一个输出→函数
多个输出→关系
Decision Tables 决策表
课前复习总结时略
6. Logic
表示性质的语言及一组推理规则
Temporal logic时态逻辑 引入额外的逻辑连接符，以约束变量随时间的变化
OCL
对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0
Z没有讲
代数规格说明 Algebraic Specifications
要知道有这么个方法
4.6 Requirements and Specification Languages 需求和规格说明语言
知道即可
UML (Unified Modeling Language)
SDL (Specification and Description Language)
p117 p118
SCR没讲
4.7 Prototyping Requirements 原型化需求
(1) 原因：用户有时不能确定自己的详细/完整需求；开发者无法确定自己的方案是否真实可行；帮助获取需求的更多细节。
(2) 方法：
①抛弃型原型：仅用于了解问题，探索可行性，用完扔掉
②进化型（演进式）原型：用于了解问题，并作为将来提交的系统的一部分。
PS：上述两种方法合称为快速原型化，在设计之前进行原型化，可以帮助理解决定最终设计的需求
(3) 示例：
(4) 目的：有些需求难以用文字、符号描述，原型可以帮助我们找到“好的视觉和感觉”；可以评价非功能需求的性能和效率
4.8 需求文档化
列出目标、背景、核心特点、运行环境、方案描述
IEEE Standard 知道就好
4. 文档 需求定义 需求规格说明
4.8.1 必要性：
进行配置管理；每个阶段都需要对文档进行参考
4.8.2 需求定义
包含一般用途；系统的背景和目标；描述客户建议的方法；详细特征；运营环境等
4.8.3 需求规格说明（SRS）：
包含文件系统接口；对功能、性能要求进行正式化的重述等
4.9 Validation and Verification 确认和验证
确认：需求定义准确地反映了用户的需求，build the right system
验证：检查文档所说的或看软件制品或与其他文档/制品相符合 build the system right
4.10 Measuring Requirements 度量需求
产品的度量、过程的度量、资源的度量
打分机制
可用性、可实现性、可测试性
0. 用例图等都需要会填空！！！
例：借书还书的用例图、取钱还钱的作业题（or ppt上的）
UML图经常考综合题
习题
(1)用例图
用例图着重于从系统外部执行者角度描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁，用例图在 UML 中占有很重要的地位，甚至称为 UML 是一种用例驱动的开发方法。
①组成介绍：
执行者
可能使用这些用例的人或外部程序。
用例
对系统提供的功能（或称系统的用途）的一种描述。
特点：本质上讲，一个用例是用户（角色）与计算机之间为达到某个目的的一次典型交互作用；描述了用户提出的一些可见需求；用例可大可小；用例对应一个具体的用户目标；用例也必须描述用户没有直接提出的一些需求。
②图符：
③实例：
④用例模型的获取：
获取执行者：谁使用系统的主要功能（主要使用者）；谁需要系统支持他们的日常工作；谁来维护、管理系统使其能正常工作（辅助使用者）；系统需要控制哪些硬件；系统需要与其他哪些系统交互；对系统产生的结果感兴趣的是哪些人
获取用例：执行者要求系统提供哪些功能；执行者需要读取、产生、删除、修改或存储系统中的信息有哪些类型；必须提醒执行者的系统事件有哪些；执行者必须提醒系统事件有哪些；怎样把这些事件表示成用例中的功能？
PS：用例只跟参与者打交道，不能把功能分解成大量用例；用例不能是内部实现，也不能没有结果。
(2)类图
定义：描述了系统中的类及其相互之间的各种关系，其本质反映了系统中包含的各种对象的类型及对象间的静态关系（关联、子类型等关系）
(3).其他图
①包图：
介绍：包图也存在类图里面的继承、引用等依赖关系，也包含接口，接口与包之间用带小圆圈的实线相连。
示例：
示例介绍： B、C、D、E 在 A 中，C 依赖于 B，C 也依赖于外部的 F，而 D、E 分别继承了 B，而 G 使用了软件系统 A 的接口
②序列图：
介绍：序列图中的对象可以是并发执行的，每一个对象有自己运行的线程控制着。这时，需要通过激活、异步消息、同步控制和活动对象来表示。序列图有两种，一种是描述特定对象之间生存期中消息通信的所有情节，称作一般序列图；一种是描述消息通信的个别情节的实例序列图，如果需要描述所有的情节，则需要多个实例序列图。
简单画法示例：
复杂画法示例：
复杂画法解析：M2 和 M3 是有条件的互斥消息，M4 消息创建了对象 Obj5，它的 delete 消息则撤销了对象 Obj6，M5 消息进行了递归调用，Obj1 左面的标签和约束指明了 a、b、c三点之间的时间约束要求。
③部署图
介绍：部署图描述了系统在运行时的物理结构、配置和关系，涉及处理器、设备、通讯等硬件单元和软件部件。部署图的描述是基于代表硬件单元的节点之上的。
节点：系统中计算资源的代表，每个节点是一个计算机设备及受其管理支配的、处理器、打印机、通讯设备等，以及在其上运行的类、对象等部件。通过这些部件的识别，可以跟踪确认系统的组成以及组成间的关系和在硬件上的配置关系。节点按照硬件资源标识。节点的描述包括三方面：位置（标识）、构成（包含的硬件设备和软件部件）、能力（计算能力、计算功能、等）。可以把节点作为类或实例加以描述。节点类描述了具有相同特性的等待实例化的节点，实例代表了实际出现的节点。（有个别时候把某个客户端描述成一个综合节点类）在把部件分配给节点时，需要考虑许多因素。例如：资源和能力的利用、地理位置对功能实现和系统性能的影响、资源配置与效率的发挥、保密和安全性的实现、系统综合性能的影响、可扩展和可移植等特性的影响。
示例：奥运福娃的架构图和部署图：
④活动图：
示例：
示例介绍：圆形矩形表示活动，实心圆表示起点，内部包含实心圆的圆表示终点。