第四章获取需求

第四章获取需求 中国科学技术大学田野

Contents 4.1 需求过程 4.2 需求引发 4.4 需求的类型 4.4 需求的特性 4.5 建模表示法 4.6 需求和规格说明语言 4.7 原型化需求 4.8 需求文档 4.9 确认和验证 4.10 测量需求 4.11 选择规格说明技术 4.12 信息系统的例子 4.13 实时系统的例子

Objectives • 从客户引发需求 • 建模需求 • 评审需求以保证需求的质量 • 文档化需求、供设计和测试人员使用

4.1 需求过程 • 需求就是对期望的行为的表达 • 需求涉及 • 对象或者实体 • 对象、实体所处的状态 • 用于改变状态或对象特性的功能 • 需求集中于客户和问题，而不是解决方案和实现 • 需求指客户需要什么样的行为，而不是如何实现这些行为

4.1 需求过程需求过程为何重要 • 项目失败的首要原因 • 不完整的需求（13.1%） • 缺少用户参与（12.4%） • 缺少资源（10.6%） • 不切实际的期望（9.9%） • 缺乏行政支持（9.3%） • 需求和规格说明的变更（8.7%） • 缺乏计划（8.1%） • 不再需要该系统（7.5%） • 几乎所有因素都涉及需求引发、定义和管理过程的某些部分 • 在开发过程早期没有检测到并修复需求错误，代价可能很高昂

4.1 需求过程需求获取的过程 • 由需求分析员或者系统分析员执行获取需求的任务 • 需求引发、需求分析、需求规格说明 • 需求过程的最终结果是软件的需求规格说明（SRS）

4.1 需求过程敏捷需求建模 • 如果需求交织在一起并且和复杂，最好使用强调前端建模的“重量级”过程 • 将编码推迟到已经完成需求建模分析，提出反映需求的体系结构，并完成详细设计之后 • 如果需求不确定，可以采用敏捷方法 • 递增地收集和实现需求 • 极限编程（XP）将敏捷需求用到极端 • 在需求刚被定义的时候就构建系统 • 没有关于将来需求的计划和设计 • 将需求编码为最终必须通过的测试用例

4.2 需求引发 • 客户并不总是擅长准确描述他们想要什么或者需要什么 • 同每一个与系统成败相关的人讨论需求非常重要 • 与所有的风险承担者达成一致 • 如果不能就需求达成一致，项目注定失败

4.2 需求引发使用“观点集”管理不一致性 • 没有必要在软件开发的早期解决不一致性(Easterbrook和Nuseibah, 1996) • 在软件开发过程中，将风险承担者的看法文档化并维护在单独的“观点集”中 • 需求分析员定义“观点”之间的一致性规则 • 对“观点集”进行分析，看它们是否符合一致性规则 • 当对一个“观点集”修改时，重新检查不一致性 • 需求文档包含所有风险承担者的所有观点，突出了不一致性，直到获得足够信息的时候才解决不一致性，以进行基于可靠信息的决策

4.2 需求引发风险承担者 • 委托人：支付软件开发费用的人 • 客户：在软件开发后购买软件的人 • 用户：最终使用系统的那些人 • 领域专家：对软件必须自动化的问题很熟悉的那些人 • 市场研究人员：调查市场，确定将在趋势和潜在客户的需要的那些人 • 律师或审计人员：对政府、安全性以及法律的需求熟悉的那些人 • 软件工程师或其它技术专家

4.2 需求引发需求引发的手段 • 与风险承担者会谈 • 评审可用文档 • 观察当前系统（如果存在） • 做用户的学徒，在用户执行任务时详细地学习 • 以小组的方式与用户和风险承担者交谈，相互启发 • 使用特定领域的策略，如联合应用设计，或者PIECES • 与当前和潜在客户一起集体讨论（头脑风暴）

4.2 需求引发需求引发的手段 (continued) • Volere需求过程模型，提出一些额外的需求资源

4.3 需求的类型 • 功能需求：根据要求的活动来描述需要的行为 • 质量需求或非功能需求：描述一些软件解决方案必须拥有的质量特性 • 例如，响应时间 • 设计约束：是已经做出的设计决策或限制问题解决方案集的设计决策 • 例如，接口的选择 • 过程约束：对于构建系统的技术和资源的限制

4.3 需求的类型使需求可测试 • 一旦规定了需求，就应该能够确定提出的解决方案是否满足需求，这种评估必须是客观的 • 确定能够自然量化的质量需求的适配标准是相对容易的，例如，性能、规格、精度… • 对更主观的质量需求难以量化，可使用性、可维护性 • 使需求可测试的三种方法 • 指定每个副词和形容词的定量描述 • 用特定实体的名称替换代名词 • 要确保在需求文档的某个地方，准确定义每个名词

4.3 需求的类型解决冲突 • 不同的风险承担者对需求应该是什么看法不一致 • 导致冲突 • 对需求进行优先级划分对于解决冲突是有用的 • 将需求划分为以下三类 • 必须的：绝对需要满足的需求 • 值得要的：非常值得但是并非必须的需求 • 可选的：可要可不要的需求 • 可以避免试图优化多个冲突的质量需求

4.3 需求的类型两种需求文档 • 需求定义：客户想要的每一件事情的完整列表 • 通过描述打算构建的系统将要安装的环境中的实体，以及这些实体的约束、监控和转换，来表述需求 • 面向业务相关人员，如客户 • 作为合同使用 • 需求规格说明：将需求重新陈述为关于将要构建的系统将如何运转的规格说明 • 面向技术性人员，如设计人员、测试人员、项目经理

4.3需求的类型两种需求文档(continued) • 环境领域中定义的需求包含系统的接口 • 需求规范仅涉及环境和系统领域的交织部分

4.3需求的类型两种需求文档(continued) • 十字转门问题 • 需求定义： • 未付费的人不能进入动物园 • 对每次付费，系统不应该阻止其相应的选入 • 需求规格说明（部分） • 当-个游客使用一定的力推动锁开着的十字转门时，十字转门将自动旋转半周，然后锁上

4.4 需求的特性 • 正确性 • 一致性 • 需求之间无冲突 • 无二义性 • 只存在唯一有效的解释 • 完备性 • 指定了所有约束、所有状态下所有可能的输入输出及必需的行为 • 可行性 • 解决方案确实存在 • 相关性 • 不包含与客户需要没有关系的功能 • 可测试性 • 可跟踪性 • 需求定义的每一条都在需求规格说明中存在对应

4.5 建模表示法 • 软件工程的重要特征，存在用于建模、文档化和交流决策的标准表示法 • 建模有助于我们透彻地理解需求 • 模型中的漏洞揭示未知或含糊不清的行为 • 同一个输入的多个、相互冲突的输出揭示出需求的不一致性 • 7种需求建模表示法范型 • 两个示例问题 • 十字转门问题 • 图书馆问题：图书馆记录书籍和主顾信息，图书预留，超期归还罚金

4.5 建模表示法实体—联系图（ER图） • 一种表示概念模型的流行的图形表示法范型 • ER图有三个核心的结构 • 实体：表示为矩形，代表具有共同性质和行为的现实世界对象构成的集合 • 联系：表示为两个实体之间的边，边中有一个菱形，说明联系的类型 • 属性：实体上注释，描述实体相关的数据或性质

4.5 建模表示法ER图(continued) • 十字转门问题的E-R图

4.5 建模表示法ER图(continued) • ER图被广泛运用，因为 • 提供要解决问题的总体概况 • 当问题需求发生变化时，该视图是相对稳定的 • ER图用于在需求过程早期用来建模问题

4.5 建模表示法ER图例子：UML类图 • UML(统一建模语言)是用于文档化软件规格说明和设计的一组表示法 • 使用对象和方法表示系统 • 对象：类似于实体，按照继承层次的类进行组织 • 方法：每一个对象提供方法，在对象变量上做动作 • 类图是UML规格说明中的旗舰型模型 • 是一种与规格说明中“类”相关的高级ER图

4.5 建模表示法图书馆问题的UML类图  

4.5 建模表示法UML类图 (continued) • 每个方框是一个类，表示一组相似类型的实体。一个类具有名称、属性集和类的属性上的操作集 • 属性是简单的数据变量，其值可以变化 • 某些属性和操作是与类相关连的，不是与类的实例相关连的 • 类范围属性用带下划线的属性表示，是被类的所有实例共享的数据值 • 类范围操作 • 两个类之间的连线被称为关联，表示涉及对象的类中对象的交互或事件 • 聚合关联表示一个类是另一个类的所有物或元素，使用一端带有空心菱形的关联来表示 • 表示“has-a”的关系

4.5 建模表示法UML类图 (continued) • 组装关联是一种特殊类型的聚合，复合类的实例是物理上有成分类的实例组成，用带实心菱形的聚合表示 • Article和Periodical • 一端带三角形的关联表示概化关联，其中，处于关联的三角形端的那个类是关联另一端那个类的父类。一个子类继承父类的所有属性、操作和关联 • 表示“is-a”的关系 • Book、Periodical和Publication • 关联可以使用标记（通常是动词）描述关联的实体之间的关系，也可以对关联端进行标记，表示角色名 • 可以在关联端上注释多重性(multiplicity)，指定实体数目或者关联的实体之间的链接数目上的约束 • 关联类用于收集不能只归于一个类或另一个类的那些信息 • Loan类

4.5 建模表示法事件踪迹 • 事件踪迹是关于现实世界实体之间交换的事件序列的图形描述 • 竖线表示不同实体的时间线，其名字出现在线的顶部 • 水平线表示两个实体之间的一个事件或交互；消息传递 • 时间按从顶到下的踪迹进展 • 每个图描述一个踪迹，表示的只是若干可能行为中的一种 • 事件踪迹的语义相对精确，还简单、易于理解

4.5 建模表示法事件踪迹(continued) • 十字转门中的两个事件踪迹 • 左边：普通行为 • 右边：意外行为（插入slug）

4.5 建模表示法事件踪迹例子：消息时序图 • 消息时序图是扩充的事件踪迹表示法。具有创建和撤销实体、指定动作和计时器，以及组合事件踪迹的能力 • 每条竖线表示一个参与的实体 • 一个消息描述为从发送实体到接收实体的箭头，箭头标记该消息的名称和数据参数 • 虚线箭头表示创建事件，产生新的实体 • 动作表示为实体执行线上带标记的矩形，处于踪迹中动作发生的那一刻 • 将一个实体演化的重要状态指定为条件，用有标记的六边形表示

4.5 建模表示法事件踪迹例子：消息时序图 • 图书馆借出事务的消息时序图

4.5 建模表示法状态机 • 状态机是一种图形描述，描述系统与环境之间的所有对话 • 每一个节点被称为状态，表示存在于事件发生之间的一个稳定的条件集合 • 每一个边被称为转移，表示由于一个事件的变化而产生的行为或条件的变化 • 每一个转移有触发事件，还可能有输出事件，用“/”间隔 • 状态机用于 • 表示动态行为 • 描述在响应已经发生的历史事件时行为将如何变化

4.5 建模表示法状态机(continued) • 十字转门的有限状态机模型

4.5 建模表示法状态机(continued) • 一条通过状态机的路径，起始于状态机的初始状态，沿着状态到状态的转移 • 表示环境中一条可观察事件的踪迹 • 如果每一个状态和事件都有一个唯一的响应，状态机是确定的 • coin, push, rotated, coin, push, rotated, …

4.5 建模表示法状态机例子：UML状态图 • UML状态图用于描述一个UML类中对象的动态行为 • UML类图没有说明实体是如何运转的，或者对于输入事件，它的行为是如何变化的 • 一个UML模型就是一组并发执行的状态图 • 每个类都有一个关联的状态图 • 每一个状态图对应一个实例化的对象 • UML状态图包含丰富的语法，包括状态层次、并发性、状态机间通信

4.5 建模表示法状态机例子：UML状态图(continued) • 状态层次，通过将那些具有公共转移的状态合并进超状态，可使状态图更简洁 • 一个超状态包含多个并发的子状态机，使用虚线分开 • 子状态机被认为是并发运转的，用于建模单独的、不相关的子行为 • Publication有两个子状态机，loan和reserve

4.5 建模表示法状态机例子：UML状态图(continued) • 图书馆问题中Publication类的UML状态图

4.5 建模表示法状态机例子：UML状态图(continued) • Publication类的一个等价状态图，没有使用层次或并发， • 显得杂乱和重复

4.5 建模表示法状态机例子：UML状态图(continued) • 状态转移用它们的激活事件、条件及其副作用来标记，语法为例如：borrow(patron)^Loan.create(patron, self) • 触发事件是一个可能携带参数的消息 • 激活条件是关于对象属性值的谓词 • 如果一个转移发生，动作表示对象属性的赋值 • 如果转移发生，可能生成输出事件，输出事件可携带参数，指定目标对象

4.5 建模表示法状态机例子：UML状态图(continued) • Load类的UML状态图，用局部变量、动作和活动来注释状态

4.5 建模表示法状态机：分解状态的方式 • 构造一个状态机模型最困难的部分是决定如何将对象的行为分解为不同的状态 • 将来可能的行为的等价类 • 连续事件之间的时间段 • 在一个对象演变过程中的命名的控制点 • 对象行为的分割

4.5 建模表示法状态机例子：Petri网 • Petri网是状态-转移表示法的一种形式，用于建模并发活动以及它们之间的交互 • 圆圈称为位置，表示活动或条件 • 条表示变迁 • 有向的箭头称为弧，将变迁与其输入输出连接起来 • 位置中放置令牌，作为变迁的启动条件。当一个变迁被触发时，就清除每一个输入位置中的令牌，并将令牌插入每一个输出位置

4.5 建模表示法状态机例子：Petri网(continued) • 描述借书的Petri网

4.5 建模表示法状态机例子：Petri网(continued) • 图书馆问题高层Petri网规格说明，每一个位置存储了不同数据类型的令牌

4.5 建模表示法数据流图 • ER图、事件踪迹以及状态机仅描述低层的行为 • 数据流图建模功能以及从一个功能到另一个功能的数据流 • 一个泡泡表示一个加工或功能，它转换数据 • 箭头表示数据流，进入泡泡的箭头表示功能的输入，出去的箭头表示功能的输出 • 单个计算使用之外的持久型数据保存在数据存储中，表示为两个平行的条 • 数据源或者数据接收器表示为矩形，称为参与者：提供输入数据或接收输出结果的实体

4.5 建模表示法数据流图(continued) • 图书馆问题的数据流图

4.5 建模表示法数据流图(continued) • 优势： • 提供被提议系统高层功能的直观模型，表述各种加工之间的数据依赖关系 • 缺点 • 领域专家便于阅读和理解，但是对于不太熟悉正在建模的问题的软件开发人员，数据流图更加含糊不清

4.5 建模表示法数据流图例子：用例 • 用例包含 • 大的方框表示系统边界 • 方框外的小人描绘参与者，包括人与系统 • 方框内的椭圆是用例，表示必须的主要功能及其变种 • 参与者和用例之间的线表示，参与者参与了该用例 • 用例不一定建模系统应该提供的所有任务，而是用于说明用户对重要系统行为的观察。

4.5 建模表示法用例(continued) • 图书馆用例，包括借书、还书和交付罚款

4.5 建模表示法函数和关系 • 形式化方法： • 基于数学的规格说明和设计技术 • 更精确，有助于分析和验证 • 一些形式化范型将需求成软件行为建模为一组数学函数或关系，当组合在一起的时候，将系统输入映射到系统输出 • 一些函数说明系统的执行状态，而其他一些函数说明输出 • 当一个输入值映射到多个输出值的时候，就使用关系 • 函数定义上是一致的 • 每一个输入都映射到单个输出 • 全函数：为每一个输入指定一个输出

第四章 获取需求