- 软件需求基础
- 需求基本概念
- 软件需求是利益相关方对目标软件系统在功能、质量等方面的期望，以及对目标软件系统在运行环境、资源消耗等方面的要求或约束
- 软件开发需求工程：通过对应用问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将软件需求精确化、一致化、完全化，最终形成需求规约。
- 精确化：需求正确地反映利益相关方的期望和约束，需求地表述无歧义，并且可通过客观手段予以验证
- 一致化：各需求项之间无逻辑冲突
- 完全化：不遗漏重要的软件需求条目。
- 需求工程
- 需求工程介于系统工程和软件设计之间的重要桥梁，以系统规约作为基本出发点，并从软件角度对他们进行检查与调整
- 需求规约是软件设计、实现、测试直至维护的重要基础
- 软件需求分类：
- 功能需求：利益相关方要求目标软件系统应该具有的功能（主体部分）
- 质量需求：利益相关方对目标软件系统的质量要求。质量需求+约束性需求=非功能需求。
- 约束性需求：利益相关方对目标软件系统在项目预算、完成时间、技术选型、遵循的标准与规范等方面提出的要求。以及由预期的开发、运行环境的特征而导致的针对目标软件系统的约束。
- 软件需求的质量要素
- 正确性
- 真实性：每个需求能真实反映利益相关方的需求
- 一致性：需求项内部、需求项之间没有逻辑冲突
- 精确性：需求项的表述不会引起二义或多义理解
- 无冗余：每项需求在软件需求模型中仅出现一次，多项需求之间不存在语义重叠。
- 完全性：所有需求项构成的全集完整的覆盖所有必须在目标软件产品中实现的利益相关方需求，尤其不能遗漏重要或者紧迫的需求。
- 可行性：在实际资源约束条件下，软件需求能够被完整实现的可能性。
- 可验证性：在验收测试阶段，开发方能否通过呈现测试结果，客观地、无争议地向利益相关方表明需求已完整实现。
- 优先级：所有需求项已经根据其重要性、紧迫性、实现难度和资源要求等因素地综合考量而明确赋予了优先级。
- 风险预案明晰性：对于存在实现风险的需求项，其实现过程中科能出现的风险因素已明确标识，其应对预案充分且合理。
- 正确性
- 需求沟通技巧
- 利益相关方代表和需求工程师组成联合工作组
- 克服沟通障碍
- 消弭利益冲突
- 需求调查与建模的基本方法
- 需求调查的主要形式（五种）
- 需求工程师对用户或客户进行访谈
- 召集用户、客户和需求工程师共同参与需求调查会议
- 通过调查问卷收集需求或澄清问题
- 研究用户提供的业务运作文档
- 观摩业务处理现场
- 需求建模基本方法：
- 抽象
- 分解，问题分解遵循原则：各个子问题具有较强的独立性，子问题之间具有松耦合性
- 多视点分析可以使用的视角：系统观点与用户观点，信息观点
- 需求调查的主要形式（五种）
- 需求基本概念
- 需求工程过程模型
- 需求工程的核心（三项活动）（首要任务）
- 通过各种信息渠道获取并表示利益相关方对目标软件系统的需求
- 对这些需求进行分析和整理
- 按照项目组预定的标准将需求表示为规范化的需求规约
- 完整需求工程过程活动：需求工程策划、需求获取、需求分析、需求规范化、需求验证、总结。
- 需求工程的核心（三项活动）（首要任务）
-
- 迭代式的过程模型
- 通过初次迭代明确软件项目/产品的目标与范围，进行子系统划分，明确子系统的功能域以及子系统之间的接口；在后面的每次迭代中按优先级选取若干子系统进行需求获取、分析、规范化和验证工作。
- 迭代式过程模型不排斥相邻迭代的时间段发生重叠
- 一次迭代完成后进入后续迭代的条件：所有参与者对新需求的获取或针对已有需求的变更之必要性达成共识。
- 三种应用场景
- 对于小型软件项目或软件需求容易确立的项目，迭代仅需进行一次。
- 一个软件能够分解成多个子系统，针对各子系统的需求工程活动可以并行的在各自的迭代子过程中进行。
- 在本次迭代的需求验证阶段，若发现了缺陷，或认为某些需求项需要新增或变更，可以形成缺陷分析报告或需求变更申请报告，以此为输入启动下次迭代。
- 迭代式的过程模型
- 需求获取
- 需求获取
- 目标：完整的收集、整理利益相关方对目标软件系统的需求，并以其容易理解的业务语言阐述这些需求，形成文档
- 需求获取是需求工程中后续活动（分析、规范化等）的基础。又是后续软件开发活动的基础
- 活动主要完成者：软件开发方的需求工程师
- 软件需求初始表示机制：UML的用例、用例图、类图、活动图
- 主要输出制品：经评审通过的软件问题定义、领域概念模型、业务流程模型、业务规则、非功能需求说明。
- 需求表示
- 用例
- 概念
- 外部用户视角：一个用例是执行者与目标软件系统之间一次典型的交互作用。效果：执行者在软件系统的帮助下完成了某项业务功能，或达成了某项业务目标。
- 软件系统内部视角：一个用例代表系统执行的一系列动作，动作执行的结果能够被外部执行者所察觉。
- 执行者：外部用户或外部实体在系统的交互过程中扮演的角色，它与软件系统交换信息并使用软件系统的供能
- 用例必备两项特征
- 相对独立性、完整性：用例表示执行者为达成一项相对独立、完整的业务目标而与目标软件系统协同完成的功能。为了更清晰的描述这种外部可见功能，用例进一步表示：执行者与软件系统之间的交互动作序列。
- 对于执行者来说：交互的目的（效果）在于达成其业务目标。对于待开发软件系统来说：交互的过程是该项外部可见功能的使用过程
- 用例与软件需求之间的关系：用例是功能性软件需求的主体部分。
- 框架用例：宏观功能已基本明确但内容尚不完整的用例。引入目的：满足需求获取过程中记录、表示细节尚未完全确定的用例需求。
- 概念
- 用例图
- UML用例模型由一到多副用例图构成，它们表示从软件系统的外部使用者的角度看到的各项系统功能，并清晰地说明软件系统的边界。即用例图中所有用例的集合构成目标软件系统应该提供的功能，除此之外软件系统不再承诺其他功能。
- 用例节点与边
- 节点：执行者、用例
- 边：
- 执行者与用例之间的关系（无向边）
- 意义：执行者触发用例的执行，向用例提供信息或者从用例获取信息。
- 主动执行者：触发用例的执行者
- 被动执行者：仅从用例获取信息的执行者
- 利用有向边（使用当慎重）的两种情况
- 有多和执行者与用例相连，为了强调其中某个执行者是该用例的主要执行者，从该执行者到用例之间连一条有向边。（信息仍可能是双向的)
- 强调被动执行者仅从从用例获取信息，而不向用例提供信息，从用例到别动执行者之间连一条有向边。
- 用例之间的关系
- 包含
- 含义：若B是A的某项子功能，并且建模者确切地知道在A所对应地动作序列中何时将调用B，称用例A包含用例B。
- 包含关系常被用来将多个用例中公共的子功能项提取出来，以避免重复和冗余。
- 扩展
- 含义：若A与B相似，但A的功能较B的多，A的动作序列是通过在B的动作序列中的某些执行点上插入附加的动作序列而构成的，称用例A扩展用例B。
- 扩展点：A的附加动作在B的动作序列中的插入点
- 扩展关系常用来区隔正常的业务处理功能和带有例外处理的功能，可避免例外处理逻辑搅乱或泯灭正常处理逻辑。
- 继承
- 含义：若A与B相似，但A的动作序列是通过改写B的部分动作或者扩展B的部分动作而获得的，称用例A继承用例B。
- 继承关系符合针对类间继承关系的可替代性原则：任何特化用例都可应用于其泛化用例能够应用的场合。
- 继承关系与扩展关系的取舍原则
- 能够指出明确的扩展点，采用扩展关系
- 希望区隔正常的业务处理功能和带有例外处理的功能，采用扩展关系
- 不仅要插入新动作，还要修改原动作，采用继承关系
- 为避免语义上的复杂性，用例之间的关系不应超过两层。
- 包含
- 执行者之间的关系
- 继承：若执行者B继承执行者A，A触发用例UC，那么B与UC之间的触发执行关系不必显示表达。
- 与面向对象中继承关系区别：主要强调子类执行者对父类执行者与用例之间的交互行为的继承。
- 执行者与用例之间的关系（无向边）
- 用例的表示
- 触发条件：激励用例开始执行的事件、动作或系统所处的状态
- 前置条件：用例在启动时参与该用例的执行者与目标软件系统应该处于何种状态
- 后置条件：在用例执行完成之后目标软件系统应该处于何种状态
- 触发条件和前置条件的联合语义：当触发事件或动作发生，或者当系统进入触发状态，并且前置条件成立，则用例开始执行。
- 一个用例可以有多个触发条件。
- 基本交互动作过程表示正常情况下执行者与目标软件系统之间的信息交互的内容及过程，包括系统每次响应执行者传入的信息时应完成的功能或动作序列。
- 扩展交互动作过程表示特殊情况或异常情况下的信息交互及动作序列。
- 类图
- 概念
- 类图：描述面向对象软件系统的静态结构
- 节点：系统中的类及其属性和操作
- 边：类之间的关系
- 各个阶段的含义
- 需求获取或业务理解过程：类图表达领域概念模型，即业务领域中的概念及概念之间的关系
- 需求分析阶段：类图表示软件需求模型之静态结构部分
- 软件设计和实现阶段：类图表示软件的结构及详细设计
- 在面向对象分析与设计过程：处于核心地位
- 类之间的关系
- 继承
- 聚合
- （一般）聚合
- 在聚合关系下，作为部件类的对象可能是多个整体类的对象的组成部分
- 整体类必须具备完整的管理部件类生命周期的职责
- 组合
- （一般）聚合
- 关联
- 关联关系表示两个类之间迥异于继承关系的一种语义上、逻辑上的联系
- 聚合关系是关联关系的一种
- 在其表示图元的两端，可以标示参与关联的多重性、角色名、约束特性
- 多重性：说明位于关联端的类可以有多少个实例对象与另一端的类的单个实例对象相联系，它表示参与关联的两个类的对象之间的数量对应关系
- 角色名：描述参与关联的类的对象在关联关系中扮演的角色或发挥的作用。
- 约束特性：说明针对参与关联的对象或对象集的约束条件
- 依赖
- A和B之间有语义上的关系，并且B的变化会导致A必须相应修改。依赖关系是有向的
- 实现
- 表示一个类实现了另一个类中定义的对外接口。
- 依赖与实现的抽象级别低于继承和关联。
- 聚合与组合是特殊的关联关系。关联和继承都是依赖关系的一种
- 耦合角度，继承关系最强，组合次之，普通聚合再次之，除组合和聚合之外的普通关联关系最弱。
- 关联的方向
- 在分析模型中，表示两个类的逻辑联系
- 在设计模型和实现模型中：表示参与关联的类必须具有查询职责和关系维护职责。
- 管理可以有方向—有向关联（导航）
- 概念
- 活动图
- 节点
- 活动
- 决策点
- 并发控制
- 对象
- 边
- 控制流：连接在两个非对象节点之间的有向边，表示处理流程的顺序推进。
- 对象流：从对象节点指向活动节点的有向边表示将对象作为输入数据传入活动
- 泳道机制
- 将活动图用形如游泳池中的泳道分成数个活动区，每个区由一个对象或一个控制线程负责。每个活动节点应位于负责执行该活动的对象或线程所在的区域内
- 初始节点和终止节点
- 初始节点：通过一条简单的有向边指明进入活动图时首个被执行的活动（唯一）
- 终止节点：整个活动图执行完毕。（表示持续活动过程可以没有，其他情况至少一个）
- 节点
- 用例
- 需求获取的过程模型
- 定义软件问题
- 创建框架用例
- 精化用例
- 评审用例模型
- 主要关注点：用例模型的正确性、精确性、一致性、完整性
- 定义软件问题
- 目标：理解软件要解决的主要业务问题、业务背景，尽量消除需求工程师与用户之间的交流障碍；明确待开发软件系统的目标、业务价值、范围、边界。
- 过程：
- 标识客户和用户
- 理解业务背景
- 策划并实施需求调查
- 定义软件系统的轮廓，包括其目标、业务价值、范围及边界
- 用例图
- 创建框架用例
- 目标：提取框架用例，并通过它们完整地覆盖用户需求面。
- 子活动
- 策划并实施用例调查
- 以框架用例记录用例调查结果
- 创建用例图
- 整合并评审框架用例
- 精化用例
- 目标:将框架用例精化为严谨、完整的用例，精化用例图，在此过程中根据需要适当补充新的业务规则和非功能需求。
- 主要任务：确定每个框架用例的交互动作序列。
- 基本交互动作序列：在不考虑任何例外的情况下，最简单、最直接的交互动作序列
- 扩展交互动作序列：在基本交互动作序列基础上，因为特殊情形的出现而导致动作序列出现分支
- 子活动
- 分解或合并用例
- 构建完整用例
- 精化用例图
- 精化业务规则及非功能需求
- 评审用例模型
- 主要关注点：需求模型的正确性、完全性、可行性
- 创建框架用例
- 需求获取
- 需求分析与验证
- 需求分析
- 分析模型的表示
- 需求分析的任务：在需求获取阶段的输出制品的基础上，获得对软件需求的更深入、更完善的理解，并且将软件需求表示为面向软件设计人员、易于修改和维护的分析模型
- 需求分析的主要任务：建立比用例模型更完整、更精细的分析模型，以期获得对软件需求的更深入理解，提高软件需求的质量，为软件设计奠定更坚实的基础
- 构建分析模型的两点理由
- 分析模型比用例模型更加结构化、更加清晰直观。分析魔心的构建过程实际上是不断深入理解用例模型的过程，也是剔除用例的自然语言描述中可能存在的模糊性和不一致性的过程。
- 分析模型是用例模型与软件设计模型之间的”桥梁“，理解分析模型对业务知识的要求远低于理解用例模型。
- 需求分析的输出制品：软件需求的分析模型，该模型是需求规约的主要组成部分，是后续软件设计、构造和测试的工作基础。
- 分析模型表示：类图、活动图、交互图、状态图
- 交互图
- 概念：描述一组对象通过消息传递而形成的协作行为
- 用处：
- 用于描述单个用例的功能的实现方式
- 软件系统在某种给定的使用场景下对象之间的交互协作流程
- 软件系统的某个复杂操作的逻辑实现模型
- 作用：可以清晰地了解对象在软件系统中扮演的角色以及对象之间的交互协作。
- 分类
- 顺序图：强调消息传递的时间序
- 构成的图形元素：对象及其生命线与活跃期，消息传递，注解
- 消息
- 同步消息：其发送者等待消息接收对象将消息处理完后再继续
- 异步消息：其发送者在发送完消息后不再等待接收方即继续自己的处理
- 同步消息会指向作为消息接收目标对象的活跃期的顶端。
- 四种特殊消息：自消息、返回消息、创建消息、销毁消息
- 主动对象对象与被动对象
- 考察整张顺序图，在该图表示的时间段内，若有多个对象同时处于活跃期，其中某些对象的活跃是直接或间接地起因于某个对象A传出的消息，A为主动对象，由A直接或间接激活的对象为被动对象。
- 一张顺序图中，可能存在多个主动对象，所掌握的控制流并发执行
- 两个主动对象之间的消息传递应该是异步的
- 通信图：突出消息的对象之间的合作关系。构成元素
- 节点：是参与交互的对象
- 连接器：对象之间的连接，扮演对象之间的消息传递通道的角色
- 在连接器上可以标识一到多条消息
- 二者之间的选取
- 强调消息传递的时间序——顺序图，强调对象之间的交互、协作关系——通过图
- 刻画用例的动作序列——顺序图，刻画软件内部等某项功能的实现构想——通信图
- 业务分析和需求建模阶段——顺序图，设计和实现阶段——通信图
- 顺序图：强调消息传递的时间序
- 状态图
- 基本概念
- 含义：描述一个实体在事件刺激下的反应式动态行为，它包含实体所有可能的状态，在每个状态下能够响应的事件以及事件发生时的状态变迁与响应动作。
- 表现形式：可以是类的典型对象，可以是一个软件系统（或其子部分）或其其中一个软构件，可以是包含目标软件系统的整个大系统
- 用途：描述一个类的典型对象、软件系统、软构件或系统的行为
- 四个基本概念：状态、事件、活动、动作
- 对象的状态：对象的具有统一行为模式的某个生命周期阶段
- 事件：在对象生命周期中某时刻发生的、值得关注的针对该对象的一种瞬时刺激或触发
- 消息型事件
- 信号型事件
- 时间型事件
- 条件型事件
- 活动和动作在过程中可以向对象发送同步消息或异步信号，创建或删除对象。其差异在于
- 动作位于状态之间的迁移边上，比较简单，执行时间短
- 活动位于状态中，可以比动作复杂、执行时间稍长
- 基本机制
- 状态图由状态节点和迁移边构成
- 状态节点由状态名以及可选的入口动作、出口动作、do活动、内部迁移构成
- 迁移边表示状态之间因事件激励而触发的对象状态变化
- 特殊的状态：初态和终态，一张图中一个初态，一到多个终态。
- 状态图由状态节点和迁移边构成
- 基本概念
- 扩充机制
- 约束
- 最常使用约束的模型元素：类、属性、操作（用约束表达前置、后置条件、不变式）、关联关系
- 标记值：三种使用场景
- 作为一种特殊的语义约束
- 作为非语义性的项目管理和信息跟踪的标注
- 作为模型转换和代码生成工具的指引器
- 构造型
- 约束
- 需求分析的过程模型
- 需求优先级分析
- 用例分析
- 分析模型评审
- 为辅助需求分析而构建快速原型
- 需求优先级分析
- 主要任务：为每项需求确定优先级
- 三种诠释：
- 基于实现紧迫度的优先级
- 基于需求实现度的优先级
- 基于产品可接受度的优先级
- 决定需求优先级的三个因素的综合作用
- 需求项为利益相关方提供的价值
- 需求项的实现成本
- 实现过程中的风险
- 优先级计算公式
- 分析模型的表示
- 需求分析
-
-
- 用例分析
- 目标：将用例模型中关于用例的自然语言描述转化为更接近于软件设计的分析模型
- 分析类，软件设计于构造阶段的设计类、实现类
- 区别：分析类仅表示为完成用例的功能而假想的逻辑职责单元，不考虑软件结构、用户界面、软件复用等因素，也不考虑目标软件的运行支撑环境，更不考虑面向对象的编程实现细节。
- 用例分析子活动
- 精化领域概念模型
- 设置分析类
- 构思分析类之间协作关系
- 导出分析类图
- 利用快速原型辅助需求分析
- 分析与规划
- 设计与实现
- 检查与评审
- 改进
- 原型划分为探索性、实验性、进化性
- 用例分析
- 需求评审
- 被评审的主体对象：分析模型
- 模型的一致性、精确性、完全性，分析模型相对于用例模型的一致性，分析模型面向软件设计师的可理解性、详略恰当性
- 采用快速原型法
- 判断决策合理性基于决策理解、评审分析模型
- 需求规约
- 目标：1.便于利益相关方、需求工程。师和软件设计人员进行理解和交流。2.支持目标软件系统的确认。3.控制系统进化过程。
- 需求验证
- 目标：确保需求规约真实、准确、全面地反映了利益相关方的所有需求
- 利益相关方对需求规约的认可程度是衡量需求工程是否成功的主要指标
- 需求评审、问题整理、问题求解、达成一致
-
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
