本文围绕软件需求工程展开，涵盖需求开发与管理。介绍需求层次、获取方法、分析方法（如SA、OOA、PDOA），阐述结构化与面向对象分析方法，包括DFD、STD、ER图等。还涉及需求定义、验证、管理，如需求定义方法、SRS编写，需求评审与测试，以及变更、风险和跟踪管理。
文章目录
软件需求工程是包括 创建和维护软件需求文档 所必须的一切活动的过程，可分为 需求开发和需求管理 两大工作。
什么是需求工程？
所有与需求直接相关的活动称为需求工程。
需求工程的活动可以分为两大类：
- 需求开发：通过调查与分析，获取用户需求并定义产品需求
- 需求管理：确保各方对需求的理解一致，管理和控制需求的变更，从需求到最终产品的双向跟踪
# 需求工程的工作大概可以细分为：
1、需求获取
2、需求分析与协商
3、系统建模
4、需求规约
5、需求验证
6、需求管理
# 需求和软件需求，不一样
软件需求和业务需求也是有区别的
1、软件需求
2、硬件需求
3、网络需求
1、软件需求概述
软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
1.1 需求的层次
简单的讲，软件需求就是系统必须完成的事以及必须具备的品质。
需求是多层次的，包括：业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。
# 比较喜欢考选择
业务需求：比较笼统，比较概述，没有大概的细节，比如：我就想要一个***功能
用户需求：偏操作
系统需求：比较细节，
（1）功能
（2）非功能：比如像性能、安全、可靠性等
（3）设计约束：比如：限制开发人的学历、限制开发语言等
PIECES框架—描述 非功能需求
- 性能：Performance - 描述企业当前的运行效率，可以分析当前业务的处理速度
- 信息：Information
- 经济：Economics
- 控制：Control - 提高信息系统的安全和控制水平
- 效率：Efficiency - 人、财、物的使用效率
- 服务：Service - 提高对客户、供应商、合作伙伴、顾客等的服务质量
1.2 质量功能部署-QFD
- QFD-Quality Function Deployment
- 是一种将 用户要求 转化为 软件需求 的技术，其目的是最大限度地提升软件工程中用户的满意度。
为了达到这个目标，QFD将软件需求分为三类
- 常规需求：也称基本需求
- 期望需求
- 意外需求：也称兴奋需求
2、需求获取
需求获取的方法
| 方法 | 特点 | 补充说明 |
|---|---|---|
| 收集资料 | 把与系统有关的、对系统开发有益的信息收集起来。 | |
| 用户访谈 | 1对1-3,有代表性的用户。成本高。 | 开放式问题和封闭式问题相结合。耗时。 |
| 问卷调查 | 用户多，无法一一访谈。成本低。 | |
| 现场观摩 | 针对较为复杂的流程和操作。 | |
| 参加业务实践 | 有效地发现问题的本质和寻找解决问题的办法。 | |
| 联合需求计划（JRP) | 高度组织的群体会议，各方参与，成本高。 | 会议的形式获取需求。成本高。 |
| 阅读历史文档 | 对收集数据性的信息较为有用。 | 对数据性的信息较为有用。 |
| 情节串联板 | 一系列图片，通过这些图片来讲故事 。 | 原型法 |
| 抽样调查 | 降低成本。 |
【重点】
- 联合需求计划：很有用，很及时，但是成本高
- 看到 降低成本 ，选择抽样调查
- 对数据性的信息，选择阅读历史文档
- 流程复杂，选择现场观摩
- 发现问题的本质找到解决问题的办法，选择参加业务实践
2.1 用户访谈
| 用户访谈方式 | 描述 |
|---|---|
| 结构化 | 事先准备好一系列的问题，有针对行的进行。 |
| 非结构化 | 只列出粗略的想法，根据访谈情况发挥。 |
最有效的方式：两者结合。
访谈的过程
| 序号 | 步骤 | 描述 | 补充说明 |
|---|---|---|---|
| 01 | 准备访谈 | 1.确定访谈的目的； | |
| 2.访谈中应该包括哪些用户； | 2.最好限制参加访谈用户个数； | ||
| 3.为访谈准备一些详细的问题； | 3.分为开放式问题、封闭式问题； | ||
| 4.做出最终的访谈安排，并把这些安排通知所有者。 | 4.具体的时间和地点应该征求被访谈者的同意。 | ||
| 02 | 访谈过程 | 1.限制时间； | 1.控制在90分钟 |
| 2.寻找异常和错误情况； | 2.要找机会问一些类似“如果…那会怎么样”的问题，要有意识的去确定所有的特殊情况，并与用户深入探讨 | ||
| 3.深入调查细节； | 3.除了寻找意外情况外，还必须深入调查，以确保获得对过程和规则的完全理解。 | ||
| 4.认真做好记录。 | 4.主要包括本人记录、第三人记录或者是录音录像的形式。手写比较温和。 | ||
| 03 | 访谈的后续工作 | 1.吸收、理解和记录访谈所获得的信息； | |
| 2.用户回答不上来的问题，不要丢失或遗忘； | 2.可以下次再访谈 | ||
| 3.总结内容，反馈给客户。 | 3.给用户机会澄清错误 |
用户访谈的优点和缺点？
| 优点 | 缺点 |
|---|---|
| 1.具有较好的灵活性 | 1.用户忙，难以安排时间 |
| 2.较宽广的应用范围 | 2.面谈时信息量大，记录较为困难 |
| 3.沟通需要技巧，需要足够的领域知识 | |
| 4.可能会遇到对与企业来说比较机密和敏感的话题 |
2.2 问卷调查
调查表的制作
| 步骤 | 描述 |
|---|---|
| 1.确定问题及其类型 | (1)开放式问题;封闭式问题； |
| (2)问题必须写的很具体； | |
| (3)问题顺序必须有说服力； | |
| (4)必须能够预见用户可能的回答。 | |
| 2.编写问题 | (1)注意使用用户的语言； |
| (2)不要含糊，保持问题简短； | |
| (3)避免措辞偏向。 | |
| 3.设计问卷调查表格式 | 一份精心设计的、恰当的问卷调查表，能够帮助用户客服不愿意回答的问题。 |
| (1)流出空白； | |
| (2)相似内容的问题放在一起； | |
| (3)重要的问题放在最前面。 |
调查表的优点和缺点
| 优点 | 缺点 |
|---|---|
| 1.短时间内，以低廉的代价从大量的回答中收集数据 | 1.双方未见面，无法从用户的表情等动作来获得更隐性的信息。用户也没有机会立即澄清对问题有含糊或错误的回答。 |
| 2.允许回答者匿名填写，大多数用户会提供真实信息。 | 2.用户可能在心理上不重视一张小小的表格，不认真对待。 |
| 3.问卷调查结果比较好整理额统计 | 3.调查表不利于对问题进行展开的回答，无法了解一些细节问题。 |
| 4.回答者的数量往往比预期的少，无法保证用户会回答问题或进一步说明所有问题 |
提高问卷返还率的方法
问卷调查的返还率通常比较低，系统分析师在采用问卷调查的方式获取需求时，除了设计适当的问题，选择合适的调查人群之外，一定要事先考虑到如何解决问卷返还率低的问题。为了提高问卷返回率，通常可以采取以下措施：
- 向所有的工作人员解释问卷的目的，以及如何使用这些信息。
- 说明这份问卷是（客户）企业的每个工作人员都要回答的。
- 拜托相关领导督促他所管辖的工作人员回答问卷，并及时返还。
- 尽量参加一次（客户）企业的全体会议，在会议上解答工作人员提出的问题，并解释这些信息的用处。
- 更改问卷中的问题，尽量减少回答问卷所花费的时间。
- 设置一些奖品或奖励，激励大家及时返还问卷。
2.3 采样
样本大小计算
2.4 情节串联板
情节串联板通常就是一系列图片，系统分析师通过这些图片来讲故事。在一般情况下，图片的顺序与活动事件的顺序一致，通过一系列图片说明会发生什么。人们发现，通过以图片辅助讲故事的方式叙述需求，有助于有效和准确地沟通。在情节串联板中可以使用的图片类型包括流程图、交互图、报表和记录结构等。
简单地说，情节串联板技术就是使用工具向用户说明（或演示）系统如何适合企业的需要，并表明系统将如何运转。系统分析师将初始的情节串联板展示给讨论小组，小组成员提供意见。
情节串联板分类
情节串联板的类型包括被动式、主动式和交互式，其复杂程度依次递增。
- 被动式情节串联板通常由草图、图片、屏幕截图、幻灯片等组成。系统分析师充当系统的角色，让用户预演情节串联板，简单地表述为“当这样做时，会出现这样的情景”。
- 主动式情节串联板试图使用用户能够看到类似“电影样片”，它可以自动播放，描述系统在典型用法或典型场景中的行为方式。
- 交互式情节串联板让用户体验系统的行为，系统需要用户的参与才能继续运行。交互式情节串联板可以是仿真器、实物模型，甚至是抛弃式原型。
情节串联板制作
制作情节串联板的工具大致可以分为两大类：静态工具和动态工具。
- 静态工具主要有纸和铅笔、白板、即时贴和PowerPoint等。
- 动态工具主要有Flash、Macromedia Director和其他动画工具。
为了避免分散注意力，一般最好使用简单的工具，例如，图表、白板或PowerPoint等。
最大的缺点！费时间！！！
2.5 联合需求计划-JRP
为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。
联合需求计划（Joint Requirement Planning,JRP)是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development,JAD)的一部分。
2.5.1 联合应用开发-JAD
JAD是以小组形式定义和建立系统的，它是由企业主管部门经理、会议主持人、用户、协调人员、IT人员、秘书等共同组成的专题讨论组。由这个专题讨论组来定义并详细说明系统的需求和可选的技术方案。
JAD的过程大致如下：
- 确定JAD项目，主要指确定系统的范围和规范。
- 在JAD专题预备会上，会议主持人向参与者介绍项目和JAD专题讨论内容。
- 准备JAD专题讨论材料。
- 进行JAD专题讨论会，其目的是要达成对需求的一致意见，并对各种可选的技术方案加以讨论，从中研究出几套可供选择的方案。
JAD方法充分发挥了JAD专题讨论会的优势，以使更好地满足用户的需求。使用JAD法，比传统的收集需求的时间更快，可以加速系统开发周期。JAD方法充分发挥了管理人员和用户的积极性，增强了管理人员和用户的责任感，从而使系统开发工作做得更好。
2.5.2 JRP会议
JRP是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6-18人，召开时间为1~5小时。
在会议之前，应该将与讨论主题相关的材料提前分发给所有将要参加会议的人。在会议开始之后，按照以下步骤进行：
- 应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议的最初，针对所列举的问题进行逐项专题讨论。
- 对现有系统和类似系统的不足进行开放性交流。鼓励与会者在短时间内说出尽量多的想法，在这一过程中不对这些想法发表任何评论。
- 大家在此基础上对新的解决方案进行一番设想，在这个过程中，需要把这些想法、问题、不足记录下来，形成一个要点清单。
- 针对这个要点清单进行整理，明确优先级，并进行评审。
为了更好地进行以后可能碰到的类似JRP会议，JRP会议后一般会让与会者完成一个评价性的调查问卷。JRP会议最后有一个总结性的报告，主要内容是与会者达成一致的需求和未解决的问题。
2.5.3 JRP主要原则
JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则：
- 在JRP实施之前，应制订详细的议程，并严格遵照议程进行。
- 按照既定的时间安排进行。
- 尽量完整地记录会议期间的内容。
- 在讨论期间尽量避免使用专业术语。
- 充分运用解决冲突的技能。
- 会议期间应设置充分的间歇时间。
- 鼓励团队取得一致意见。
- 保证参加JRP的所有人员能够遵守事先约定的规则。
JRP将会起到群策群力的效果，对于一些问题最有歧义的时候、对需求最不清晰的领域都是十分有用的一种方法。这种方法最大的难度是会议的组织和相关人员的能力，要做到言之有物，气氛开放。否则，将难以达到预想的效果。
2.6 需求记录技术
# 常用的需求记录工具具有
1、任务卡片
2、场景说明
3、用户故事
4、Volere白卡
1、任务卡片：适用业务活动级的信息收集与整理
2、场景说明
有时候，系统分析师可能很难总结出子任务和任务变体，因为这需要对任务执行过程进行抽象。此时，系统分析师可以使用场景说明来对用户的描述进行整理，抽象出子任务。简单地理解，场景说明就是用户对其工作场景和过程的详细描述，这些描述将在编写测试用例和用户培训手册中再次用到。
3、用户故事
用户故事描述了对用户有价值的功能，可包括三个方面内容，分别是书面描述（用用户故事是用户编写的，分析师辅助编写于计划和备忘）、交谈（细化故事）和测试用例（验证故事实现）。用户故事描述的传统形式是手工书写的用户故事卡，系统分析师辅助用户编写故事，**告诉用户所编写的故事是进一步讨论的引子，而不是详细的需求规范。**在任何项目中，需要用户团队根据故事的重要性来安排开发工作，回答所有开发问题，编写所有的故事。在编写故事之前应该建立用户角色模型，必须包含对项目成功至关重要的角色，尽量保证所有用户对系统完全满意。
用户故事具有6个基本属性：独立性、可协商性、对用户有价值、可预测性、短小精悍和可测试性。
- 独立性。尽可能避免故事之间存在依赖关系，因为依赖关系会产生优先级和规划问题。
- 可协商性。故事是可协商的，不是必须实现的书面合同或者需求。
- 对用户有价值。确保每个故事对用户有价值的最好方式是让用户编写故事。[用户故事是用户编写的，分析师辅助编写。]
- 可预测性。系统分析师应该能够预测（至少大致猜测）故事的规模，以及实现所需要的工作量。
- 短小精悍。故事规模对实现有影响，何种故事规模最合适，取决于开发团队的规模和能力，以及技术实现等方面。
- 可测试性。所编写的故事必须是可测试的。
4、Volere白卡：一般敏捷方法中用
3、需求分析
在需求获取阶段，系统分析师所获得的需求是杂乱的，是用户对新系统的期望和要求，这些要求有重复的地方，也有矛盾的地方，这样的要求是不能作为软件设计的基础的。一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要系统分析师把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
用户要求和期望转化为用户需求！
在需求获取阶段，获得的需求是杂乱的，是用户对新系统的期望和要求.
这些需求有重复的地方，也有矛盾的地方，这样的要求不能作为软件设计的基础。
系统分析师需要把杂乱的用户要求转化为产品需求，这就是需求分析的工作。
# 下述是原题解析，此处做摘录
需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用
需求分析使得系统工程师能1）刻画出软件的功能和性能；2）建立软件必须满足的约束；
需求分析允许系统分析师细化软件的分解，并建立将被软件处理的数据、功能和行为模型。
需求分析为软件设计师提供了被翻译成数据、架构、界面和过程设计的模型
最后，需求规约为开发者和客户提供了软件开发完成后质量评估的依据
需求分析是 发现、求精、建模和规约 的过程
包括
1）详细的细化由系统工程师建立并在软件项目计划中明确的项目范围
2）创建所需数据、信息和控制流及操作行为的模型
3）还要分析可选择的解决方案，并将它们分配到各软件元素中去
需要注意：在需求分析阶段，得到详细的规约是不可能的。客户可能并不能明确滴肯定需要什么
开发者可能不能肯定可用什么特定的方法来适当的完成功能和性能
主要有两种分析方法
1、结构化需求分析
2、面向对象需求分析
| 结构化分析方法-SA | 面向对象分析方法-OOA | |
|---|---|---|
| 关键词 | 以模块为中心；功能的分层和分解；自上而下、逐步分解问题。 | 从所处理的数据入手，以数据为中心来描述系统。 |
| 一次性把系统的功能分解到位 | 持续 观测并理解 的方法 | |
| 缺点 | 容易混淆需求和设计的界限 | |
| 缺点 | 分割了各项系统功能的应用环境，从各项功能项入手，很难了解到这些功能项如何相互关联来实现一个完整的系统服务。 | 优点：1)并不是减少开发时间；2)而是提高了目标系统的可重用性，减少了生命周期后续阶段的工作量和可能犯的错误，提高了软件的可维护性。 |
| 缺点 | 由于用户的需求和软、硬件技术的不断发展变化，作为系统基本成分的功能模块很容易受到影响，局部修改甚至会引起系统的根本性变化。开发过程前期入手快而后期频繁改动的现象比较常见。 | 初次使用此技术，可能比SA的时间更长，需要花精力去分析对象是什么，每个对象应该承担什么责任等。 |
3.1 需求分析的任务
# Karl E.Wiegers 在《软件需求》一书中指出，需求分析的工作通常包括以下 7个方面：
1、绘制系统上下文 范围关系图
2、创建用户界面原型
3、分析需求的可行性
4、确定需求的优先级
5、为需求建立模型
6、创建数据字典
7、使用QFD
【下述内容重点！仔细理解。】
- 绘制系统上下文范围关系图：这种关系图是用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围。【范围】
- 创建用户界面原型：用户界面对于一个系统来说是十分重要的，因此在需求分析阶段通过快速开发工具开发一个抛弃式原型，或者通过PowerPoint、Flash等演示工具制作一个演示原型，甚至是用纸和笔画出一些关键的界面接口示意图，将帮助用户更好地理解所要解决的问题，更好地理解系统。【画图】
- 分析需求的可行性：对所有获得的需求进行成本、性能和技术实现方面的可行性研究，以及这些需求项是否与其他的需求项有冲突，是否有对外的依赖关系等。【可行性】
- 确定需求的优先级：这是一项很重要的工作，选代开发已经成为了现代软件工程方法的一个基础，而需求的优先级是制订迭代计划的一个最重要的依据。对于需求优先级的描述，可以采用满意度和不满意度指标进行说明。其中满意度表示当需求被实现时用户的满意程度，不满意度表示当需求未被实现时用户的不满意程度。【优先级】
- 为需求建立模型：也就是建立分析模型，这些模型的表现形式主要是图表加上少量的文字描述，所谓“一图抵千字”，图形化地描述需求将使得其更加清晰、易懂。根据采用的分析方法不同，采用的图也将不同。例如，OOA中的用例模型和领域模型，SA中的DFD和E-R图等。需求分析模型主要描述系统的数据、功能、用户界面和运行的外部行为，它是系统的一种逻辑表示技术，并不涉及软件的具体实现细节。需求分析模型可以帮助系统分析师理解系统，使需求分析任务更加容易实现。同时，它也是以后进行软件设计的基础，为软件设计提供了系统的表示视图。【建模】
- 创建数据字典：数据字典是对系统用到的所有数据项和结构进行定义，以确保开发人员使用了统一的数据定义。
- 使用QFD:这是在需求优先级基础上的一个升华，其原理与满意度和不满意度指标十分接近，通过将产品特性、属性与对用户的重要性联系起来。
3.2 需求分析的方法
- SA方法
- OOA方法
- 面向问题域的分析方法 - PDOA
- 一些形式化的方法 - VDM 、 Z
之后的章节会详细介绍SA 和 OOA ，此处只介绍 PDOA
3.2.1 面向问题域的分析方法 - PDOA
非重点
- 与SA和OOA相比，PDOA更多的强调描述，更少的强调建模。
它的描述大致分为以下两个部分：
- 关注问题域。用一个文档对含有的问题域进行相关的描述，并列出需要在该域中求解的问题列表，也就是需求列表。只有这个文档是在分析时产生的。
- 关注解系统（即系统实现）的待求行为。用一个文档对解系统的待求行为进行描述。此文档在需求定义阶段完成。
在PDOA方法中，对整个过程有一个清晰的定义：
- 收集基本的信息并开发问题框架，以建立问题域的类型。
- 在问题框架类型的指导下，进一步收集详细信息，并给出一个问题域相关特性的描述。
- 基于以上两点，收集 并 用文档说明新系统的需求。
可以看出，问题框架是PDOA的核心元素。
3.2.2 SA、OOA、PDOA 方法对比
SA
- 关注于功能的分层和分解，非常符合人们自上而下、逐步分解问题直到可解决的自然思考。
- SA方法本身隐含几个基本假设：1.问题域是可以定义的；2.问题域是有限的；3.通过有限的步骤总可以将复杂问题分解到可解决的程度。
- SA方法应用的是科学方法中的 因果律、归纳法 和 逻辑法。
- 通过对现实世界中的问题域进行不断的"测量"和“分解”，直到得到问题域的逻辑模型。
OOA
- 基于抽象、信息隐藏、功能独立和模块化 这些基本理念对系统进行分析。
- OOA方法首先对问题域的事物的“外在表象”进行观测，然后再逻辑世界中模拟出一个对象的逻辑对象，“断定”该对象与现实事物是一直的。随后，观测到的对象被计入对象集合，观测到的行为和表象被记录入对象关系模型和对象行为模型。
- OOA方法建立的对象彼此之间通过接口来相互沟通，每传递一个消息即触发一个事件，并引起内部方法的执行。
- 只有观测 对象内部的时候，才能看到具体的属性和方法。否则，只能看到对象对外部开放的接口。
- 只承诺一种可以持续“观测并理解”的方法，以及 “观测后建立”的对象和现实世界的外在表象是一致的。
PDOA
- 将重点定位在问题域和需求上，通过对问题域的分类，向系统分析师提供具体问题的相关指南。
- 将规格说明作为另外的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。
4、结构化分析方法-SA
Structured Analysis - SA
-
是一种面向数据流的需求分析方法
-
主要用于分析大型的数据处理系统，特别是企事业管理系统
-
其基本思想可以概括为“分解”和“抽象”
-
一般遵循“先全局后局部，先整体后细节，先抽象后具体”的原则。
-
通过逐层分解数据流图，可以获得系统的顶层、中间层和底层DFD图，从而更深入地了解系统的功能和数据流程
# 图片解释
在结构化需求分析中，主要完成功能模型、数据模型和行为模型的构建。
1、【核心】功能模型：通常用数据流图（DFD）进行建模，以展示系统内部的数据传递和变换关系，从而描绘出满足功能要求的软件模型。
2、数据模型：则关注数据的结构、属性和关系，确保数据的准确性和完整性。
3、行为模型：则描述系统的行为特征，包括系统的状态变化、事件响应等。
4、数据字典：是重要的文档，对加工的描述是数据字典的组成内容之一，常见的加工描述方法有：结构化语言、判定树、判定表！！！【区分：系统设计-业务流程表示工具】
4.1 SA-DFD- 数据流图（功能模型）
- DFD是SA方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。 （即功能需求，而不是用户需求，也不是业务需求）
- DFD还可被认为是一个系统模型，在信息系统开发中，如果采用结构化方法，则一般将DFD作为需求规格说明书的一个组成部分。
4.1.1 DFD 基本组成
概念补充说明
- 数据项：DFD描述了系统的分解，但是它并没有给出图中各成分的说明，数据项就是数据流图的组成部分，不在数据流图中显示，但是在题目中会描述某条数据流的组成元素。
- 加工特点：对于每一个基本加工，必须有一个加工规格说明，加工规格说明必须描述 把输入数据流变换为输出数据流的加工规则；决策表可以用来表示加工规格说明。
- 四大模块
传入模块
传出模块
变换模块
协调模块
DFD 示例
4.1.2 数据流图设计原则
可能会考
- 数据守恒原则：对任何一个加工来说，其所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者说是通过该加工能产生的数据。
- 守恒加工原则：对同一个加工来说，输入与输出的名字必须不相同，及时它们的组成成分相同。
- 对于每一个加工，必须既有输入数据流，又有输出数据流。
- 外部实体和外部实体之间不存在数据流。
- 外部实体与数据存储之间不存在数据流。
- 数据存储和数据存储之间不存在数据流。
- 父图与子图的平衡原则。
- 数据流与加工有关，且必须经过加工。
异常情况
- 黑洞：一个加工只有输入没有输出
- 奇迹：一个加工只有输出没有输入
- 灰洞：“输入皮鞋，产出酸奶”
真题：数据流图和流程图的区别？
| 数据流图 | 流程图 | |
|---|---|---|
| 描述 | 用来说明业务处理过程、系统边界内所包含的功能和系统的数据流 | 以图形化的方式，展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流，往往涉及具体的设计实现。 |
| 适用阶段 | 逻辑建模阶段 | 物理建模阶段 |
| 处理过程可并行 | 某个时间点只能处于一个处理过程。 | |
| “流” | 展现系统的数据流 | 展现系统的控制流 |
| 计时标准 | 展现全局的处理过程，过程间遵循不同的计时标准。 | 遵循一致的计时标准 |
4.2 SA-STD-状态转换图（行为模型）
- 大部分业务系统是数据驱动的，所以适合用DFD。
- 但是实时控制系统却主要是事件驱动的，因此行为模型是最有效的描述方式。
# State Transform Diagram - STD
它通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为，
并指明作为特定事件的结果系统将执行哪些动作。
实心圆：初态
同心圆（内圆为实心圆）：终态
中间状态用圆角矩形表示
4.3 SA-ER图-实体联系图（数据模型）
ER - entity relationship diagram
- 是一种用于描述现实世界概念模型的图形化表示方法。
4.3.1 ER 三要素
- 实体：用矩形表示，框内标注实体名称
- 属性：
（1）单值属性：用椭圆表示，用连线与实体连接起来
（2）多值属性: 双层椭圆，里面虚线，外面实线。如：学生的兴趣，可以有电影、音乐、烹饪等
（3）派生属性：用虚线椭圆表示。是从基本属性计算出来的属性。如：学生的总成绩和平均成绩等。 - 实体之间的联系：用菱形框表示，框内标注联系名称。
并用连线将菱形框分别与有关实体相连，并在连线上注明联系的类型。
4.4 数据字典-DD
- DFD描述了系统分解，但是对于数据的详细内容却无法在DFD中得到反馈。
- 数据字典是在DFD的基础上，对DFD中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。
- DFD和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。
4.4.1 数据字典的条目
数据字典中一般有6类条目
- 数据元素
- 数据结构
- 数据流
- 数据存储
- 加工逻辑
- 外部实体
1、数据元素
- 数据元素也称为数据项，是数据的最小组成单位。例如：例如，课程号、课程名等。
- 对数据元素的描述，应该包括数据元素的名称、编号、别名、类型、长度、取值范围和取值的含义等
2、数据结构
- 数据结构用于描述某些数据元素之间的关系，它是一个递归的概念
- 数据结构的描述重点是数据元素之间的组合关系，即说明数据结构包括哪些成分。
这些成分中有三种特殊情况，分别是任选项、必选项和重复项。
（1）任选项是可以出现也可以省略的项，用 “[]”表示；
（2）必选项是在两个或多个数据元素中，必须出现其中的一个。例如，任何一门课程是必修课或选修课，二者必居其一。必选项的表示是将候选的多个数据项用“（}”括起来；
（3）重复项是可以多次出现的数据项。例如，一张学员注册表可选择多门课程，“课程细节”可重复多次，表示成“课程细节*”。
3、数据流
- 数据流由一个或一组数据元素组成
- 对数据流的描述应包括数据流的名称、编号、简要说明、来源、去处、组成和流通量(含高峰时期的流通量）。
4、数据存储
-
数据存储的条目主要描写该数据存储的结构，以及有关的数据流和査询要求。
-
有些数据存储的结构吋能很复杂.
“学员”包括学员的基本情况、学员动态、在线模拟测试记录、论文成绩等，其中每一项又是一个数据结构，这些数据结构有各自的条目分别加以说明。因此，在 “学员”的条目中只需列出这些数据结构，而不要列出数据结构的内部构成。 -
DFD是分层的，下层图是上层图的具体化。同一个数据存储可能在不同层次的图中出现。描述这样的数据存储，应列出最底层图中的数据流。
5、加工逻辑
- 需要描述加工的编号、名称、功能的简要说明、有关的输入数据流和输出数据流。
- 对加工进行描述，目的在于使相关人员能有一个较明确的概念，了解加工的主要功能。
- 详细的加工逻辑则需要借助一些工具来描述，包括判定树、判定表和结构化语言等
6、外部实体
- 外部实体是数据的来源和去向.
- 对外部实体的描述应包括外部实体的名称、编号、简要说明、外部实体产生的数据流和系统传给该外部实体的数据流，以及该外部实体的数量。
- 外部实体的数量对于估计系统的业务量有参考作用，尤其是关系密切的主要外部实体。
4.4.2 数据字典的作用
- 数据字典实际上是 ”关于系统数据的数据库“。
- 在整个系统开发过程和系统运行与维护阶段，数据字典是必不可少的工具。
- 数据字典是所有人员 工作的依据，统一的标准，它可以确保数据在系统中的完整性和一致性。
具体来讲，数据字典具有以下作用：
- 按各种要求 列表。可以根据数据字典，把所有数据条目按一定顺序全部列出，保证系统设计时不会遗漏。
- 相互参照，便于系统修改。根据初步的DFD，建立相应的数据字典。在需求分析过程中，系统分析师会发现原来的DFD以及各种数据定义中有错误或遗漏，需要修改或补充。有了数据字典，这种修改就变得容易多了。
- 由描述内容检索名称。在一个稍微复杂的系统中，系统分析师可能没有把我断定某个数据元素在数据字典中是否已经定义，或者记不清其确切的名字，可以由内容查找其名称。
- 一致性检验和完整性检验。根据各类条目的规定格式，可以发现一些问题，例如：是否存在没有知名来源或去向的数据流，是否存在没有指明数据存储或所属数据流的数据元素，加工逻辑与输入的数据元素是否匹配，是否存在没有输入或输出的数据存储等。
4.4.3 数据字典的管理
- 为了保证数据的一致性，数据字典必须由专人管理，如：数据管理员。
- 任何人，如果要修改数据字典的内容，都必须通过数据管理员。
5、面向对象分析方法-OOA
- OOA 的基本任务是：运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反应问题域和系统功能的OOA模型及其详细说明。
- OOA模型独立于具体实现
- OOA的任务是 “做什么”
- OOD的任务是 “怎么做”
5.1 面向对象基本概念
# OOA
OOA基于用例模型，通过对象建模 记录
1）确定的对象、
2）对象封装的数据和行为、
3）以及对象之间的关系。
OOA包括三个活动
1、建模系统功能
2、发现并确定业务对象
3、组织对象 并 确定对象间的关系
一些个 面向对象 常见的概念！
1、对象：属性+方法+对象ID
2、类：是对象的抽象，定义了一组相似的对象结构，定义了 数据和行为。
（1）实体类：实体类映射需求中的每个实体，保存需要存储在永久存储体中的数据。
（2）边界类：边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处。
（3）控制类：控制类是用于控制用例工作的类，用于对一个或多个用例所特定的控制行为进行建模，控制对象通常控制其他对象，因此，它们的行为具有协调性。
【领域类模型】：会涉及描述类自身情况的属性与操作，还会有描述类与类之间的关联，但不会有对象层次的内容
3、消息：对象之间进行通信的一种构造
4、继承：父类和子类。共性的抽取，代码的复用。鲸鱼 is a 哺乳动物。
5、覆盖：方法名称和属性参数，需要一致，只是实现步骤不一样，如鸟和鱼的run()
6、重载：同一个类中，有多个重名的方法，每个方法可以有不同的参数和返回值
7、多态：子类必须要对父类中方法进行【重写】
8、封装
9、静态成员
10、静态类型
11、静态绑定
12、动态绑定
13、组合：如：汽车 has a 轮胎
参考文章
继承和多态 （详解）
5.2 统一建模语言
UML(Unified Modeling Language)的作用域不限于支持OOA和OOD，还支持从需求分析开始的软件开发全过程
UML不仅仅用于需求分析！！！本系列只在此处做介绍~
总体上看，UML包括：构造块、公共机制、规则
- 构造块：事物、关系和图。事物是UML的重要组成部分。关系把事物紧密的联系在一起。图是多个相互关联的事物的集合。
- 规则：定义了UML图中的元素如何组合、命名、关联以及它们之间如何相互作用的准则。这些规则确保了UML图的一致性和准确性。
- 公共机制：是一组共享的概念和语义，用于支持不同模型元素之间的交互和通信。这些公共机制使得UML图能够更简洁、协调和一致的表达系统的结构和行为。
UML对系统架构的定义是：系统的组织结构，包括 系统分解的组成部分，以及它们的关联性、交互机制和指导原则等 提供系统设计的信息。
具体来讲，就是指一下五个系统视图：
- 逻辑视图：也称设计视图。它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
- 进程视图：是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
- 实现视图：对组成系统物理代码的文件和构件进行建模
- 部署视图：把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构
- 用例视图：是最基本的需求分析模型。
5.2.1 OOA-UML-构造块-事物
事物主要是考选择
1. 结构事物
2. 行为事物
3. 分组事物：包、构件
包大于构件
包没有那么多限制
构件：限制比较多，限制组成部分之类
4. 注释事物
1、结构事物
- 结构事物 是模型中 最静态的部分，代表概念上或物理上的元素。
- UML有七种结构事物 Structural Things
- 类：类是描述具有相同属性、方法、关系和语义的对象的集合。
- 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
- 协作：定义了交互的操作，是一些角色和其他事物一起工作，提供一些合作的动作，这些动作比事物的总和要大
- 用例：用例是描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的。
- 活动类：活动类的对象有一个或多个进程或线程。活动类和类很相似，只是它的对象代表的事物的行为和其他事物是同时存在的。
- 构件：是物理上或可替换的系统部分，它实现了一个接口集合。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
- 节点：节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。
2、行为事物
- 行为事物是UML模型中的动态部分，代表时间和空间的动作。
- UML有两种主要的行为事物
- 交互（内部活动）
交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。
交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作）、连接（对象之间的连接） - 状态机
状态机由一系列对象的状态组成
3、分组事物
- 分组事物是UML模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。
- UML 中只有一种分组事物
- 包：包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于幵发阶段，而构件可以存在于系统运行阶段。
4、注释事物
注释事物是 U M L 模型的解释部分。
5.2.2 OOA-UML-构造块-关系
UML用关系把事物结合在一起
主要有下列4 种关系
- 依赖-dependency：依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
- 关联-association：关联描述一组对象之间连接的结构关系。一个事物的变化并不影响另一个事物。指针关系！
（1）组合：强-公司和部门
（2）聚合：不强 - 汽车和轮胎 - 泛化-generalization：泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。子类和父类之间的关系。
- 实现-realization：实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
5.2.3 OOA-UML-构造块-图
重点！！！考点！！！
1、类图/对象图（Class Diagram / Object Diagram） 2、用例图（Use Case Diagram）
5.2.3.1 UML图-动态图-用例图
# 考点
用例图描述一组
（1）用例：功能模块
（2）参与者：外部触发因素（包括用户、组织、外部系统、时间、湿度等）
（3）和它们之间的关系
包含、扩展、泛化
1、包含关系：提取出来的公共部分
2、扩展关系：可发生、可不发生
3、泛化关系：衍生，理解为父子关系即可
举例
5.2.3.2 UML图-静态图-类图 / 对象图
类图/对象图 定义
# 类图：Class Diagram
描述一组 类、接口、协作和它们之间的关系
# 对象图：Object Diagram
描述一组对象和它们之间的关系
描述在类图中所建立的 事物实例 的静态快照
描述的是参与交互的各个对象在交互过程中某一时刻的状态。
对象图可以被看做是类图在某一时刻的实例。
在UML中，对象图使用的是与类图相同的符号和关系，因为对象就是类的实例
类图：展示一组类、接口、协作和它们之间的关系
对象图：展示某一时刻一组对象及它们之间的关系，为类图的某一快照。在没有类图的前提下，对象图就是静态设计视图
类与类之间的关系
四种，类属于结构事物的一种，事物的关系有四种：依赖、关联、泛化、实现。
所以类也是四种。
例题
5.2.3.3 UML图-动态图-交互图
1、UML图-动态图-交互图-顺序(时序)图
顺序图，也称序列图
强调消息发送的时间顺序
- 是一种动态图，是场景的图形化表示。
- 描述了 以时间顺序组织的对象之间的 交互活动。
- 强调对象之间 消息发送的顺序，同时显示对象之间的交互。
有三种消息类型：
- 同步消息：进行阻塞调用，调用者终止执行，等待控制权返回，需要等待返回消息，实心三角箭头
- 异步消息：发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，空心箭头
- 返回消息：由从右到左的虚线箭头表示
2、UML图-动态图-交互图-定时(计时)图
强调 特定的时间点
- 用于展示交互过程中的真实时间信息
- 具体描述对象状态变化的时间点以及维持特定状态的时间段
3、UML图-动态图-交互图-通信(协作)图
即：协作图，强调参加交互的对象的组织
- 强调对象之间存在的消息收发关系，而不专门突出这些消息发送的时间顺序。
4、UML图-动态图-交互图-交互概览图
待补充~
5.2.3.4 UML图-动态图-状态图
- 也称 动态图
- 展现了一个状态机，描述单个对象在多个用例中的行为
- 包括：1）简单状态 和 2）组合状态
- 转换可以通过 事件触发器 触发，事件触发后相应的监护条件会进行检查。
- 状态图中的转换和状态是两个独立的概念。
- 核心：状态图是对类描述的补充，用于展现此类对象所具有的可能状态，以及某些事件发生时其状态转移情况。
5.2.3.5 UML图-动态图-活动图(泳道图)
非重点
类似程序流程图，【并发】，出现 并发 ，就选活动图
-
是一种特殊的状态图
-
展示了在系统内从一个活动到另一个活动的流程。
-
名词含义：并发分叉、并发汇合、监护表达式、分支、流 层 等。
-
活动图描述一个操作中 要进行的各项活动的执行流程。同时，也常被用来描述一个用例的处理流程或某种交互流程。
-
活动图将进程或其他计算机构 展示为计算内部一步步的 控制流和数据流，强制对象间的控制流程。
UML动态图-活动图的另一种形式：泳道图
状态图和活动图
5.2.3.6 UML图-静态图-构件图 / 包图
包 > 构件
5.2.3.7 UML图-静态图-部署图
# 部署图
是一种静态图，为系统静态部署视图，部署物理模块的节点分布。
它与构件图相关。
通常一个节点包含一个或多个构件。
其依赖关系类似于包依赖，因此部署组件之间的依赖是单向的类似于包含关系。
真题说明
面向对象分析的目的是为了获得对问题域的理解，以确定系统的功能、性能要求。
逻辑模型，也称概念模型，展示了系统是什么或者系统做什么，他们独立于任何技术实现来描述系统，说明了系统的本质。
1、在UML中，类图显示了一组类、接口、协作及它们之间的关系，类图用于对系统静态设计视图的建模。在面向对象分析过程中，用类模型表示概念模型。
2、用例图描述了一组用例和参与者以及它们之间的关系，它对于系统行为的组织和建模特别重要。
3、序列图和协作图统称为交互图。序列图强调消息时间顺序，协作图强调接收和发送消息的对象的结构组织。交互图主要观察传送消息的对象。
4、构件图显示了一组构件以及它们之间的关系。用构件图来说明系统的静态实现视图。
5、状态图和活动图用来描述对象的行为。活动图观察的是对象之间传送的操作
5.2.4 OOA-UML-规则
主要用于描述和定义一个结构良好的模型应该如何呈现。
5.2.5 OOA-UML-公共机制
- UML图中的公共机制是指一组共享的概念和语义，用于支持不同模型元素之间的交互和通信。这些公共机制使得UML图更为简单、协调和一致。
- 公共机制共同作用，使得UML图能够更清晰地表达系统的结构和行为，支持开发人员、利益相关者和其他相关人员之间的有效沟通。通过遵循这些公共机制，可以确保UML图的一致性和准确性，从而提高软件开发的效率和质量。
5.3 需求建模
- SA方法：系统功能被分解到各个功能模块中，比较容易混淆需求和设计的界限；分割了各项系统功能的应用环境，从各项功能项入手，很难了解到整体。
- 从用户的角度来看，ta们并不想了解系统的内部结构和设计，所关系的就是系统所能提供的服务。这就是用例方法的基本思想。
用例方法是一种需求合成技术，获取需求，记录下来，然后从这些零散的要求和期望中进行整理和提炼，从而建立用例模型。
一些很重要的说明
可能会疑惑：之前不是一直在讲需求分析，现在怎么突然又讲模型？
额，思考一下，需求分析的输出是什么呢？怎么更好的展示需求分析的结果嘞?
所以：需求分析 和 需求建模 ，这两个，基本是分不开的，也没有说哪个步骤一定在前，哪个步骤一定在后。
- 软件需求建模（modeling for software requirement）是在需求调查的基础上，在需求分析过程中采用软件建模工具建立软件需求模型的过程。
需求模型包括：
- 用例模型：也称功能模型。功能模型用来描述 软件的功能 【用例和功能不一定能画等号，往往一个用例需要系统的多个功能来协作完成】
UML通过一组用例图来描述 软件需求； - 非功能性模型：
需求建模不仅是 用例模型！！！！
补充说明：功能、用例、业务流程？
5.4 OOA-需求建模
OAA的建模过程包含两个步骤：建立用例模型、建立分析模型。
总述：用例模型和分析模型~
用例模型和分析模型在软件开发过程中相互关联，共同推动系统的设计和实现。用例模型为开发人员提供了系统的功能需求和行为描述，是分析模型的输入之一。开发人员可以根据用例模型来确定分析模型中的类和接口等元素。同时，分析模型也为用例模型提供了验证和补充，确保系统能够满足用户的需求。在分析模型的设计和实现过程中，开发人员需要不断与用例模型进行交互和迭代，以确保系统的正确性和完整性。
5.4.1 用例模型
在OOA中，构建用例模型，一般需要经历四个阶段
- 识别参与者【必须】
- 合并需求获得用例【必须】
- 细化用例描述【必须】
- 调整用例模型【非必须】
补充说明：Q:什么是用例？
Ans:描述系统需求的方法。可以简单理解为 功能模块。
一些 用例图 的说明~
一个用例图包括：
- 参与者
- 用例
- 通信关联
- 用例图是描述系统需求的方法，所谓系统需求，即站在系统外部，对系统提出的需求。因此，用例图并非是描述系统 内部需求 的方法。
- 如果需要描述系统内部的需求，需要把系统拆分成更小的模块和单元，然后对每个单元进行系统需求分析。
- 使用用例的方法来描述系统需求的过程就是用例建模。
5.4.1.1 识别参与者
参与者识别
参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。
- 其他系统：当系统需要与其他系统交互时，其他系统就是一个参与者。如：对某企业的在线教育平台系统而言，该企业的OA系统就是一个参与者；
- 硬件设备：如果系统需要与硬件设备交互，硬件设备就是一个参与者。如：在幵发集成电路IC卡门禁系统时，IC卡读写器就是一个参与者。
- 系统时钟：当系统需要定时触发时，时钟就是一个参与者。如：发在线测试系统中的“定时交卷”功能时，就需要引入时钟作为参与者。
注意：参与者一定在系统之外，不能是系统的一部分。
5.4.1.2 合并需求获得用例
将参与者都找到之后，接下来的工作就是仔细的检查参与者，为每一个参与者确定用例。
- 首先，将获取到的需求 分配 给其相关的参与者，以便可针对每个参与者进行工作，而无遗漏；
- 进行合并操作（合并前，明确为什么要合并）；
- 产生用例；
- 将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架。
# 在确定用例的过程中，需要注意以下问题
1、用例命名：尽量采用“动词+名词”的形式，如：开通课程等；
而且，最好对用例进行标号，是实现 需求跟踪管理 的重要技巧，通过编号，可以将用户的需求落实到特定的用例中。
2、不能混淆用例和用例所包含的步骤【重点】
例如：“开通课程”功能要经过验证学员信息、检查学员权限、保存开通记录、修改课程选修人数等步骤才能完成，
在系统中这些步骤不能作为单独的功能对外提供，它们只是一个用例所包含的事件流，或是是用例的子功能。
3、注意区分业务用例和目标系统用例
（1）当针对整个业务领域建模时，需要使用业务用例，其中会涉及大景的人工活动，例如，在线教育平台系统中有一项重要工作是“编写教材”，这就是业务用例，是信息系统无法完成的。
（2）信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，因此，只需要识别出系统用例，而不需考虑业务用例。
5.4.1.3 细化用例描述
用例建模的主要工作是书写用例规约 （use case specification )，而不是画图。
用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括：
1、用例名：应该与用例图相符，并写上其相应的编号。
2、参与者
3、用例目标
4、前置条件：
5、事件流 （基本事件流和扩展事件流）：事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动，也就是用例所完成的工作步骤。
对于一些事件流较为复杂的，可以在用例描述中引用顺序图、状态图和通信图等手段进行描述。
6、后置条件
7、其他的还可以包括非功能需求和用例优先级等。
一个较为复杂的系统会有较多的用例，为便于理解，可以为它们建立多张用例图。
更为复杂的情况将导致所有用例难以维持一种平面结构，这时吋以对用例进行分组。UML使用用例主题划分用例图 ，一组用例放置在以主题命名的方框中（类似于系统边界），每个主题中可以包含多个用例图。
用例的描述可以迭代完成，先对一些重要的用例编制相对细致的用例描述，对于些不重要的用例，可以留待以后再补充完成。
5.4.1.4 调整用例模型
在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。
用例之间的关系：
- 包含
- 扩展
- 泛化
利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。
用例关系—包含
用例关系—扩展
用例关系—泛化
# 用例关系总结
1、从UML事物关系的本质上来看，包含关系和扩展关系都属于依赖关系。
（1）对包含关系而言，抽象用例中的事件流是一定插入到基本用例中去的，并且插入点只有一个。
（2）扩展用例的事件流往往可以抽象为基本用例的备选事件流，在扩展关系中，可以根据一定的条件来决定是否将扩展用例的事件流插入到基本用例的亊件流中，并且插入点可以有多个。
2、在实际应用中，很少使用泛化关系，子用例的特殊行为都可以作为父用例中的备选事件流而存在。
5.4.2 分析模型 / 领域模型
简单来讲：分析模型就是来描述系统内部组成的 （ps：用例模型描述了系统和外部的交互）
- 从用户的观点对系统进行了用例建模，但捕获了用例并不意味着分析的结束，还要对需求进行深入分析，获取关于问题域本质内容的分析模型。
分析模型是做什么?
分析模型描述 系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统的行为（动态模型）。
建立分析模型，四步：
- 定义概念类
- 确定类之间的关系
- 为类添加职责（即类自身的行为）
- 建立交互图（不同类之间的行为关系）
5.4.2.1 定义概念类==>类图
什么是概念类？概念类的定义？
- 类：是一组具有相同数据结构和相同操作的对象的集合。
- 概念类：是对具有相同属性和行为的一类事物的描述，可以用来抽象和表示现实世界的概念。
概念类和类的对比
5.4.2.2 确定类之间的关系
| 关系 | 子 | 实例 | 补充说明 |
|---|---|---|---|
| 继承关系（Inheritance） | / | 子类可以继承父类的属性和方法，并且可以在此基础上进行扩展或修改 | 类和类之间 |
| 实现关系（Realization） | / | 一个类实现一个或多个接口，意味着这个类提供了接口中定义的所有方法的实现。 | 类和接口之间 |
| 关联关系（Association） | 聚合关系（Aggregation） | 如：公司和人，脱离也可有意义 | |
| 组合关系（Composition） | 如：汽车和轮胎，房子和房间，脱离则没有 | ||
| 依赖关系（Dependency） | / | 是一种弱关系，仅表示了类之间的使用关系，而不涉及类的实现细节 | 类和类之间 |
5.4.2.3 为类添加职责
类的职责包括两方面的内容
- 类所维护的知识：成员变量、属性
- 类能执行的行为：成员方法、责任
5.4.2.4 建立交互图
UML2.0提供四种交互图：
- 顺序图：最常用，几乎可以在任何系统使用
基本元素有：对象、参与者、生命线、激活框、消息、和消息路线等。其中，消息 是顺序图的灵魂 - 交互概览图
- 通信图
- 定时图
5.5 模型分析
在对实际应用问题建立数学模型并求得结果后，还需要根据建模的目的和要求，利用相关知识，结合研究对象的特点，进行模型分析。
模型分析的工作主要包括：
- 模型的合理性分析
- 模型的误差分析
- 参数的灵敏性分析
6、需求定义
在获取了用户需求，并进行了详细的分析后，接下来的工具就需要把这些需求形成文档，作为系统后续开发的基础，这就是需求定义。
6.1 需求定义的方法
6.1.1 严格定义法
- 所有需求都能被预先定义。
- 开发人员和用户之间能够准确而清晰的交流。
- 采用图形（或文字）可以充分体现最终系统。
6.1.2 原型法
原型法的需求定义过程是一个开发人员与用户通力合作的反复过程。
从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断对系统进行完善，它实质上是一种迭代的 循环型的开发方式。
- 并非所有的需求都能在系统开发前被准确的说明。
- 项目干系人之间通常都存在一些交流上的困难，原型提供了克服该困难的一个手段。
- 需要实际的、可供用户参与的系统模型。
- 有合适的系统开发环境。
- 反复是完全需要和值得提倡的。
6.2 软件需求规格说明书 - SRS
需求规格说明说！！！ = 需求基线！！！
6.2.1 SRS的编写方法
- 用好的结构化和自然语言编写文本型文档。【为主！】
- 建立图形化模型，这些模型可以描述转换过程、系统的状态及其变化、数据关系、逻辑流、对象类及其关系。【补充！】
- 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。【基本不用！】
6.2.2 SRS的内容和格式
一般应该包括
- 范围：SRS适用的系统和软件的完整标识
- 引用文件
- 需求：主体部分，详细描述软件需求。所需的状态和方式、需求概述、需求规格、软件配置项能力需求、软件配置项外部接口需求、软件配置项内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求、软件质量因素、设计与实现约束、数据、操作、故障处理、算法说明、有关人员需求、有关培训需求、有关后勤需求、包装需求和其他需求，以及需求的优先级次序和关键程度。
- 合格性规定
- 需求可追踪性
- 尚未解决的问题
- 注解
- 附录
7、需求验证
也称需求确认~
主要是为了确定一下内容：
- SRS 正确的描述了预期的、满足项目干系人需求的系统行为和特性。
- SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导来的。
- 需求是完整的和高质量的
- 需求的表示在所有地方都是一致的
- 需求为继续进行系统设计、实现和测试提供了足够的基础。
简述
目的是(1)与用户一起确认需求无误
(2)对 需求规格说明书SAS 进行评审和测试
包括两个步骤
（1）需求评审：正式评审和非正式评审
（2）需求测试：设计概念测试用例
***需求验证通过后，要请用户签字确认，作为验收标准之一
此时，这个【需求规格说明书】就是【需求基线】
不可以再随意更新，
如果需要更新，必须走需求变更流程。
7.1 需求评审
SRS的 评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。
7.1.1 技术评审的类型
- 评审
- 检查
- 走查
7.1.2 正式评审的过程
- 计划
- 准备
- 进行评审
- 对评审结果采取行动
7.1.3 如何做好需求评审
- 分层次评审
- 正式评审与非正式评审结合
- 分阶段评审
- 精心挑选评审人员
- 对评审人员进行培训
- 充分利用需求评审检查单
- 建立标准的评审流程
- 做好评审后的跟踪工作
- 充分准备评审
7.2 需求测试
概念测试用例~
Q：需求定义和需求规约的区别？
Ans：需求定义关注于需求的本质和来源，而需求规约则是对这些需求进行规范化描述和管理的文档。
| 需求定义 | 需求规约 |
|---|---|
| 一个“描述” | 更为正式和详细的文档，包含了所有需求陈述的正式描述，表达了一个软件产品/系统的概念模型。 |
| 为什么需要这个功能？这个功能应该满足什么条件？ | 需求规约不仅包含了功能需求，还可能包括非功能需求，如性能、可靠性、安全性等。 |
| 需求规约需要满足一些基本性质，如重要性和稳定性程度、完整性、一致性和可修改性等。它还需要对需求进行分级，以便开发团队可以根据优先级进行开发。此外，需求规约也是创建产品验收测试计划和用户指南的基础，是软件开发过程中的重要参考文档。 |
8、需求管理
8.1 需求变更管理
8.1.1 需求基线
通过了评审的【需求规格说明书】就是需求基线。下次如果需要变更需求，则需要按照流程一步步进行。
定义需求基线：需求验证通过后，生成需求基线！
8.1.2 需求的状态
与需求的版本控制不一样。
需求的版本控制：比如更关注需求增加、需求变更
需求状态跟踪：是需求被确定了要做，是否最后做成。
需求的各种状态，见下图：
8.2 需求风险管理
带有风险的做法
1、无足够用户参与：获取的需求不明确
2、忽略了用户分类：可能存在权限控制的问题
3、用户需求的不断增加
4、模棱两可的需求
5、不必要的特性
6、过于精简的SRS
7、不准确的估算
变更产生的原因
1、外部环境的变化
2、需求和设计做的不够完整
3、新技术的出现
4、公司机构重组造成业务流程的变化
变更控制委员会 CCB ：也称为 配置控制委员会
其任务时对建议的配置项变更项 做出评价、审批、以及监督已经批准变更的实施。
8.3需求跟踪
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
