获取需求 - ustchome.ustc.edu.cn/~xiaoning/se2017/ppt/se_04_requirements...pfleeger and atlee,...

Pfleeger and Atlee, Software Engineering: Theory and Practice

软件工程

Chapter 4

获取需求

Shari L. Pfleeger Joanne M. Atlee

4th Edition


软件工程

内容 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 实时系统的例子


软件工程

第4章的目标

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


软件工程

4.1 需求过程

• 需求(requirement) 是对期望行为的表达 • 需求处理的是

– 对象或实体 – 它们处于的状态 – 用于改变状态或对象特性的功能

• 需求集中于客户和问题，而不是解决方案和实现 – 指定客户想要什么行为，而不是如何实现这些行为

designate what behavior, without saying how that behavior will be realized


软件工程

4.1需求过程补充材料 4.1 为什么需求很重要

• 导致项目失败的首要原因 – 不完整的需求 Incomplete requirements – 缺少用户的参与 Lack of user involvement – 不切实际的期望 Unrealistic expectations – 缺乏行政支持 Lack of executive support – 改变需求和规格说明 Changing requirements and specifications – 缺乏计划 Lack of planning – 不在需要该系统 System no longer needed

• 几乎所有这些因素都涉及需求引发、定义和管理过程的某些部分 • 如果在早期没有检测到需求错误，则这些错误的代价会很高昂


软件工程

4.1需求过程获取需求的过程

• 由需求分析员(req. analyst)或系统分析员(system analyst)执行

• 最终结果是软件需求规格说明书 SRS (Software Requirements Specification document)


软件工程

4.1需求过程补充材料 4.2 敏捷需求建模

• 如果需求交织在一起且很负责，则最好使用强调前端的建模“重量级”过程 – If requirements are tighly coupled and complex, we may be better off with a

“heavy” process that empasizes up-front modeling • 如果需求是不确定的这类问题，则敏捷方法比较合适

– If the requirements are uncertain, agile methods are an alternative approach • 敏捷方法递增地收集和实现需求

– Agile methods gather and implement the requirements in increments • 极限编程(Extreme Programming,XP) 是一种敏捷方法

– 在需求刚被定义时就构建系统 – 没有关于将来需求的计划和涉及 – 将需求编码为最终实现必须通过的测试用例


软件工程

4.2 需求引发

• 客户并不总是能理解他们的需求和问题 – Customers do not always understand what

their needs and problems are • 必须和每一个与系统成败相关的人讨论需求

• 最终使所有人对需求是什么达成一致 – 如果不能就需求达成一致，项目注定失败


软件工程

4.2需求引发风险承担者

• 委托人 Clients: pay for the software to be developed • 客户 Customers: buy the software after it is developed • 用户 Users: use the system • 领域专家 Domain experts: familiar with the problem that the

software must automate • 市场研究人员 Market Researchers: conduct surveys to determine

future trends and potential customers • 律师或审计人员 Lawyers or auditors: familiar with government,

safety, or legal requirements • 软件工程师 Software engineers or other technology experts


软件工程

4.2需求引发补充材料 4.3 用“观点集”来管理不一致性

• 设法在需求过程的早期解决不一致性是毫无意义的 (Easterbrook and Nuseibah, 1996)

• 在软件开发过程自始至终，将风险承担者的看法文档化，并维护在单独的“观点集”中 – 需求分析原定义“观点”之间的一致性规则 – 对观点集进行分析，看它们是否符合一致性规则

• 突出不一致性，直到获得足够信息的时候才解决不一致性 Inconsistencies are highlighted but not addressed until there is

sufficient information to make informed decision


软件工程

4.2需求引发需求引发的手段

• 与风险承担者进行会谈 Interviewing stake holders • 评审可用文档 Reviewing available documentations • 观察当前系统 Observing the current system (if one exists) • 做用户的学徒

Apprenticing with users to learn about user's task in more details • 以小组的方式与用户和风险承担者进行交谈 Interviewing user or stakeholders in groups • 使用特定领域的策略 Using domain specific strategies, such as Joint Application Design, or PIECES • 和当前及潜在用户集体讨论

Brainstorming with current and potential users


软件工程

4.2需求引发需求引发的手段

• Volere需求过程模型提出了一些额外的需求源


软件工程

4.3 需求的类型

• 功能需求(Functional requirement): 根据要求的活动来描述需要的行为

• 质量需求(Quality requirement)/非功能需求(nonfunctional requirement): 描述软件解决方案必须拥有的质量特性

• 设计约束(Design constraint): 设计决策，例如选定的平台或者构件接口

• 过程约束(Process constraint): 对构建系统的技术和资源的限制


软件工程

4.3需求的类型补充材料4.4 使需求可测试

• 适配标准(Fit criteria)构成判断提出的解决方案是否满足需求的客观标准 – 对能量化的质量需求确定适配标准是相对容易的 – 对更为主观的质量需求困难

• 3种方式，使需求成为可测试的 – 指定每个副词和形容词的定量描述 – 用特定实体的名称替换名词 – 确保在需求文档的某个地方，正确地定义每个名词


软件工程

4.3需求的类型解决冲突

• 不同的风险承担者有不同的需求集 – potential conflicting ideas

• 需要对需求划分优先级 • 优先级划分方案可以将需求分为3类

– 必须的 essential: absolutely must be met – 值得要的 desirable: highly desirable but not necessary – 可选的 optional: possible but could be eliminated


软件工程

4.3需求的类型两种需求文档

• 需求定义(Requirements definition): 客户想要的每一件事情的完整列表 – Describing the entities in the environment where the

system will be installed • 需求规格说明(Requirements specification): 将需求重新陈述为关于要构建的系统将如何运转的规格说明


软件工程

4.3需求的类型两种需求文档

• 需求定义可以处于环境域的任何地方，可能包括系统的接口

– Requirements defined anywhere within the environment's domain, including the system's interface

• 规格说明仅仅限制在环境域和系统域的交集之处

– Specification restricted only to the intersection between environment and system domain


软件工程

4.4 需求的特性

• 正确 Correct • 一致 Consistent • 无二义Unambigious • 完备 Complete

• 可行 Feasible • 相关 Relevant • 可测试 Testable • 可跟踪 Traceable


软件工程

4.5 建模表示法 • 用于建模、文档化和交流决策的标准表示法很重要

• 建模有助于透彻地理解需求 – 模型中的漏洞揭示出未知或含糊不清的行为 – 同一个输入的多个、相互冲突的输出揭示出需求中的不一致性


软件工程

4.5建模表示法实体-联系图

• 一种表示概念模型的流行的图形表示法范型 – A popular graphical notational paradigm for

representing conceptual models • 3个核心的结构

– 实体(entity): 表示为矩形，代表具有共同性质和行为的现实世界对象构成的集合（类）

– 联系(relationship): 表示为两个实体之间的边，边中间的菱形说明联系的类型

– 属性(attribute): 是实体上的注释，描述实体相关的数据和性质


软件工程


• 十字转门问题的实体图


软件工程


• ER图被广泛应用，因为： – 提供要解决问题的总体概况 – 当需求发生变化时，该视图是相对稳定的

• ER图常在需求过程的早期用于建模问题


软件工程

4.5建模表示法 ER Diagrams Example: UML Class Diagram

• 统一建模语言UML (Unified Modeling Language) 用于文档化软件规格说明和设计的一组表示法

• 表示系统为： – 对象objects: 类似于实体，按照具有继承层次的类进行组织 – 方法methods: 在对象的变量上执行动作

• 类图(class diagram)是“flagship”模型，在所有UML规格说明中 – 与规格说明中的类(实体)相关的高级ER图


软件工程

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

∗ ∗


软件工程

4.5建模表示法 UML 类图

• 某些属性和操作是与类相关联的，而不是与类的实例相关联

• 类范围属性(class-scope attribute) 表示为带下划线的属性，被类的所有实例共享的数据值

• 类范围操作(class-scope operation)带下划线的操作，由抽象类执行的操作而不是类的实例执行

• 关联(association), 两个类之间的连线，表示类的实例之间的关系


软件工程

4.5建模表示法 UML 类图

• 聚合关联(Aggregate association): an association that represents interaction, or events that involve objects in the associated (marked with white diamond) – “has-a” relationship

• 组装关联(Composition association): a special type of aggregation, in which instances of the compound class are physically constructed from instances of component classes (marked with black diamond)


软件工程

4.5建模表示法事件踪迹

• 关于现实世界实体之间交换的事件序列的图形描述 – 竖线: 不同实体的时间线，其名字出现在线的顶部 – 水平线: 两个实体之间的一个事件或交互 – 时间按从顶到下的踪迹进展

• 每一个图都描述一个踪迹(trace), 表示若干可能行为中的一个 • 事件踪迹的语义相对精确，而且简单、易于理解


软件工程

4.5建模表示法事件踪迹

• 十字转门问题中的事件踪迹 – 左：典型行为 – 右：异常行为


软件工程

4.5建模表示法 Event Traces Exampe: 消息时序图(Message Sequence Chart)

• 扩展的事件跟踪表示法。具有创建和撤销实体、指定动作和计时器、以及组合事件跟踪的能力 – 竖线Vertical line 表示一个参与的实体 – 消息表示为从发送实体到接受实体的箭头 – 动作(Action) 表示为位于实体执行线上的带标记的矩形 – 条件(Conditions) 实体演化的重要状态，用有标记的六边形表示


软件工程

4.5建模表示法消息时序图

• 图书馆借出事务的消息时序图


软件工程

4.5建模表示法状态机

• 一种图形描述，描述了系统与其环境之间的所有对话 – Node (state) ：表示存在于事件发生之间的一个稳定的条件集合

– Edge (transition) ：表示由于一个事件的发生而产生的行为或条件的变化

• 在表示动态行为方面，在描述响应已经发生的历史事件时行为将如何变化方面，状态机都很有用


软件工程


• 十字转门的有限状态机模型


软件工程


• 路径(path): 起始于状态机的初始状态，沿着从状态到状态的转移 – 环境中一条可观察事件的踪迹

• 确定状态机器(Deterministic state machine): for every state and event there is a unique response


软件工程

4.5建模表示法 State Machines Example: UML Statechart Diagrams

• UML状态图：描述一个UML类中对象的动态行为 – UML类图没有说明实体是如何运转的，或对于输入事件它们的行

为是如何变化的

• 一个UML模型是一组并发执行的状态图 • UML状态图有丰富的语法，包括状态层次、并发性、状态

机间通信


软件工程

4.5建模表示法 UML Statechart Diagrams

• 状态层次(State hierarchy)：通过将那些具有公共转移的状态合并进超状态(superstate)，以使得状态图整洁

• 超状态(superstate)可以包含多个并发的子状态机，由虚线分开 – 子状态机并发运转


软件工程


• Publication 类的

UML状态图


软件工程


• 同样的Publication 类的UML状态图，没有使用状态层次和并发 – 相当杂乱和重复


软件工程


• Loan 类的UML状态图：如何用局部变量、动作和活动来注释状态


软件工程

4.5建模表示法状态机: 考虑状态的方式

• 将来可能行为的等价类 – Equivalence classes of possible future behavior

• 连续事件之间的时间段 – Periods of time between consecutive event

• 在一个对象演变过程中命名的控制点 – Named control points in an object's evolution

• 对对象行为的分割 – Partition of an object's behavior


软件工程

4.5建模表示法 State Machines Example: Petri网(Petri Nets)

• 是状态-转移表示法的一种形式，用于建模并发活动以及它们之间的交互 – 圆Circles (位置 places) ：表示活动或条件represent

activities or conditions – 条Bars：表示变迁(transitions) – 弧Arcs ：将变迁与其输入位置和输出位置连接起来 – 位置上常有令牌(tokens), 作为变迁的启动条件 – 一个弧上可分配一个权重(weight)，指出在变迁出发的时候，在弧的输入位置清除了多少令牌


软件工程

4.5建模表示法 Petri Nets

• 描述借书的Petri网


软件工程

4.5建模表示法 Petri Nets

• 描述图书馆问题的Petri网


软件工程

4.5建模表示法数据流图

• ER diagram, event trace, state machines 仅描述低层的行为

• 数据流图(data-flow diagram, DFD) 对功能、以及一从一个功能到另一个功能的数据流建模 – 泡泡(bubble)表示一个加工 (process) – 箭头表示数据流(data flow) – 数据存储(data store): 正式的库或者信息库(a formal repository or

database of information) – 矩形表示参与者(actors): 提供输入数据或接收输出结果的实体


软件工程


• 图书馆问题的数据流图


软件工程


• 优点: – 提供关于被提议系统的高层功能的、以及各种加工之间的数据依

赖关系的一个直观模型 – Provides an intuitive model of a proposed system's high-level

functionality and of the data dependencies among various processes

• 缺点: – 对于不太熟悉正在建模的问题的软件开发人员来讲，数据流图是

更加含糊不清的 – Can be aggravatingly ambiguous to a software developer who is

less familiar with the problem being modeled


软件工程

4.5建模表示法 Data-Flow Diagrams Example: 用例(Use Cases)

• Components – 大方框: 系统的边界 – 方框外的小人: 参与者(actors), 包括人和系统 – 方框外的椭圆: 用例(use case)，表示必须的主要功能及其变种 – 参与者和用例之间的线: 参与者参与了该用例

• 用例并不一定建模系统应该提供的所有任务，而是用于说明用户对重要系统行为的观察

Use cases do not model all the tasks, instead they are used to specify user views of essential system behavior


软件工程

4.5建模表示法 Use Cases

• 图书馆用例 • 包括：

– borrowing a book – returning a borrowed

book – paying a library fine


软件工程

4.5建模表示法函数和关系

• 形式化方法(Formal methods or approach): 基于数学的规格说明和设计技术

• 形式化方法将需求或软件行为建模为一组数学函数(functions)或关系(relations) – 函数(Functions) 说明系统的执行状态，输出 – 关系(Relation) 用于一个输入值映射到多个输出值的情况

• Functional method is consistent(一致的) and complete(完备的)


软件工程

4.5建模表示法函数和关系

• Example: 用两个函数表示十字转门问题 – 跟踪十字转门的状态 – 指定十字转门的输出

unlocked s=locked AND e=coin NetState(s,e)= rotating s=unlocked AND e=push locked (s=rotating AND e=rotated) OR (s=locked AND e=slug) buzz s=locked AND e=slug Output(s,e) = <none> Otherwise


软件工程

4.5建模表示法 Functions and Relations Example: 判定表(Decision Tables)

• 用表格式表示的函数规格说明，将事件和条件映射到适当的反应和动作上

• 该规格说明是非形式化的，因为：输入(events and conditions) 和输出(actions) 可以表示为自然语言

• 如果有n 个输入条件，则可能有2n 个条件组合 • 映射到同样的结果集的组合，可以处理为单个列


软件工程

4.5建模表示法判定表

• 图书馆函数的判定表(borrow, return, reserve, unreserve)


软件工程

4.5建模表示法 Functions and Relations Example: Parnas Tables

• 数学函数和关系的表格式表示 – 行列的头用于说明情况的谓词 – 内部的表条目存储可能的函数结果 – 条目 “X” 表示在指定的条件下该操作无效；或者条件的组合是不

可行的

Calc due date(patron, publication, event, Today) =


软件工程

4.5建模表示法逻辑(Logic)

• 操作性的表示法(operational notation) ：a notation used to describe a problem or a proposed software solution in terms of situational behavior – 基于情况的行为的模型 Model of case-based behavior – Examples: state machine, event traces, data-flow diagram,

functional method

• 描述性的表示法(descriptive notation)：a notation that describes a problem or a proposed solution in terms of its properties or its variant – Example: logic


软件工程


• 逻辑(logic)由一个表述性质的语言，加上一组推理规则组成。这些推理规则用于从规定的性质导出新的、合乎逻辑的性质

– A logic consists of a language for expressing properties and a set of inference rules for deriving new, consequent properties from the stated properties

• 一个性质规格说明仅表示性质的表达式取值为真时的那些性质的变量值 – In logic, a property specification represents only those values of the property's

variables for which the property's expression evaluates to true

• 一阶逻辑，包含类型变量、常量、函数、谓词 – It is first-order logic, comprising typed variables, constants, functions, and

predicates


软件工程


• 考虑下列十字转门问题中的变量及其初始值

• 一阶逻辑表示

num_coins : integer := 0; /* number of coins inserted */ num_entries : integer := 0; /* number of half-rotations of

turnstile */ barrier :{locked, unlocked}:= locked;/* whether barrier is locked */ may_enter : boolean := false; /* event of coin being inserted */ push : boolean := false; /* turnstile is pushed sufficiently hard to rotate it one-half rotation*/

num_coins > num_entries

(num_coins > num_entries (barrier = unlocked)

(barrier = locked ) ¬may_enter


软件工程


• 时态逻辑(Temporal logic)引入额外的逻辑连接符，用以约束变量是如何随着时间的变化改变其值的

• 下列连接符在单个执行踪迹上约束将来的变量值 – □f Ξ f is true now and throughout the rest of execution – ⋄f Ξ f is true now or at some point in the execution – ○f Ξ f is true in the next point in the execution – f W g = f is true until a point where g is true, but g may never be

true • 十字转门问题用时态逻辑表示

□(insert_coin => ○ (may_enter W push)) □(∀n(insert_coin ∧ num_coins=n) => ○(num_coins=n+1))


软件工程

4.5建模表示法 Logic Example: 对象约束语言 Object Constrain Language (OCL)

• 一种约束语言 – 具有数学的精确性 – 对非数学专业人士易读、易写、易理解

• 专门为…而设计的 – 表述对象模型上的约束 expressing constrains on object models – 表达对象类型上的查询 expressing queries on object type


软件工程

4.5建模表示法用OCL性质注释的图书馆类


软件工程

4.5建模表示法 Logic Example: Z

• 一种形式化的需求规格语言 – 将集合论的变量定义组织到一个问题的完整的抽象数据类型

模型中 • structures set-theoretic definitions of variables into a complete

abstract-data-type model of problem – 使用逻辑来表示每一个操作的前置条件和后置条件

• uses logic to express the pre- and post-conditions for each operation

• 利用软件工程抽象方法将规格说明分解为可管理规模的模块，称为模式(schemas)


软件工程

4.5建模表示法图书馆问题的Z规格说明


软件工程

4.5建模表示法代数规格说明

• 通过指定操作对之间的相互作用，而不是建模单个操作，来指定操作的行为

• 对于一个操作集，构造一个完备的、一致的乃至是正确的公理集是很难的 It is hard to define a set of axioms that is

complete and consistent and that reflects the desired behavior


软件工程

4.5建模表示法 Algebraic Specifications Example: SDL数据

• 图书馆问题的部分SDL数据规格说明


软件工程

4.6 需求和规格说明语言

• 是几种表示法范型的组合 • UML标准包括8种图形建模表示法，加上OCL约束语言，用于需求定义和规格说明的： – 用例图 Use-case diagram (a high-level DFD) – 类图 Class diagram (an ER diagram) – 时序图 Sequence diagram (an event trace) – 合作图 Collaboration diagram (an event trace) – 状态图 Statechart diagram (a state-machine model) – OCL特性 OCL properties (logic)


软件工程

4.6需求和规格说明语言 Specification and Description Language (SDL)

规格说明与描述语言 • 国际电信联盟(International Telecommunication Union)的一个标准化语

言 • 用于精确说明通过无限的消息队列通信的实时、并发、分布处理的行为 • 包括

– SDL系统图 SDL system diagram (a DFD) – SDL方框图 SDL block diagram (a DFD) – SDL进程图 SDL process diagram (a state-machine model) – SDL数据类型 SDL data type (algebraic specification)

• 通常伴随着一组消息顺序图 Message Sequence Chart (MSC)


软件工程

4.6需求和规格说明语言 SDL系统图

• 描述的是规格说明的高层块和连接各个块的通信信道

The top-level blocks of the specification and communication channels that connect the blocks

• 信道是有向的，用信号类型标注 Channels are directional and

are labelled with the type of signals

• 消息是异步的 Message is asynchronous


软件工程

4.6需求和规格说明语言 SDL方框图

• SDL方框图建模低层的一组块以及连接它们的消息延迟信号

SDL block diagram Models a lower-level collection of blocks and the message-delaying channels that interconnect them

• 建模一组最低层的通过信号路由通信的进程

Figure depicts a collection of lowest-level processes that communicate via signal routes

• 信号路由同步地传递消息 Signal routes pass messages

synchronously


软件工程

4.6需求和规格说明语言 SDL进程图

• 是一个状态机，其转移是语言构成成分的序列(输入、决策、任务、输出)，起始或终止于状态的构成成分

• It is a state-machine whose transitions are sequences of language constructs (input, decisions, tasks, outputs) that start and end at state constructs


软件工程

4.6需求和规格说明语言软件成本降低(Software Cost Reduction, SCR)

• 专为鼓励软件开发人员采用好的软件工程设计原则而设计的一组技术

• 将软件需求建模为数学函数：REQ，该函数将监测变量(monitored variables)映射为控制变量(controlled variables) – 监测变量monitored variables: 系统感知到的环境变量 – 控制变量controlled variables: 系统设置的环境变量

• 函数RQE碑分解为一组表格式函数 The function REQ is decomposed into a collection of

tabular functions


软件工程

4.6需求和规格说明语言 SCR

• REQ is the result of composing the tabular functions into network (a DFD) as shown in the picture.

• 边反应的是函数之间的数据依赖关系 Edges reflect the data dependecies among the functions • 每一个执行步起始于一个监测变量值的变量，然后用单个的、同步的步骤，

将这个变化通过网络进行传递 Execution steps start with a change in the value of one monitored variable,

then propagate through the network, in a single syncronized step Condition Mode

on off Warning’ =

Temp ≥ 175 Temp < 175 Heat, Maintain

X True Off

Condition Mode

on off Warning’ =


X True Off

Condition Mode

on off Warning’ =


X True Off

Condition Mode

on off Warning’ =


X True Off

Condition Mode

on off Warning’ =


X True Off

Condition Mode

on off Warning’ =


X True Off

A B C D

F E


软件工程

4.6需求和规格说明语言需求表示法的其他特征

• Some techniques include notations – 将不确定性的程度和风险与每一个需求关联起来 for the degree of uncertainty or risk with each requirement – 跟踪需求至其他其他文档（例如设计或代码）、到其他系统（例如复用

需求）的能力 for tracing requirements to other system documents such as design or

code, or to other systems, such as when requirements are reused • 大部分规格说明技术已具有某种程度的自动化


软件工程

4.7 原型化需求构造原型

• 引发系统的细节 • 请求潜在用户的反馈

– 希望看到哪些方面被改进 – 哪些特征不是很那么有用 – 遗漏了哪些功能

• 确定客户的问题是否具有一个可行的解决方案 • 有助于探讨优化质量需求的可选方案


软件工程

4.7原型化需求 Prototyping Example

• Prototype for building a tool to track how much a user exercises each day

• Graphical respresentation of first prototype, in which the user must type the day, month and year


软件工程


• Second prototype shows a more interesting and sophisticated interface involving a calendar

– User uses a mouse to select the month and year

– The system displays the chart for that month, and the user selects the appropriate date in the chart


软件工程


• Third prototype shows that instead of calendar, the user is presented with three slide bars

– User uses the mouse to slide each bar left or right

– The box at the bottom of the screen changes to show the selected day, month, and year


软件工程

4.7原型化需求原型开发的方法

• 抛弃型方法 Throwaway approach – 为了对问题或者提议的解决方案有更多的了解而开发的软件，不会作为交付软件的一部分

– 允许编写“quick-and-dirty”的软件 • 演化型方法 Evolutionary approach

– 不仅帮助我们回答问题，而且还要演变为最终的产品 – 原型必须展现最终产品的质量需求，而且这些质量需求不能改进

• 这两种技术有时都被称为快速原型化(rapid prototyping)


软件工程

4.7原型化需求 Prototyping vs. Modeling

• Prototyping – 易于回答关于用户界面的问题

• Modeling – 易于回答关于事件将要发生的顺序这样的约束问题，或者关于活动的同步这样的问题


软件工程

4.8 需求文档需求定义: Steps Documenting Process

• 概述系统的总体目的和范围，包括相关的益处、目的和目标 – Outline the general purpose and scope of the system, including relevant benefits, objectives,

and goals • 描述系统开发的背景和理由

– Describe the background and the rationale behind proposal for new system • 描述可接受方案的基本特征

– Describe the essential characteristics of an accepatable solution • 描述系统将运转的环境

– Describe the environment in which the system will operate • 概述客户对解决问题的提议方法

– Outline a description of the proposal, if the customer has a proposal for solving the problem • 列出对环境所做的任何假设

– List any assumptions we make about how the environment behaves


软件工程

4.8需求文档需求定义: Steps Documenting Process

• 详细描述所有的输入和输出，包括 – 输入的源 the sources of inputs – 输出的目的地 the destinations of outputs, – 值的范围 the value ranges – 输入输出数据的格式化 data format of inputs and output data – 数据协议 data protocols – 串口格式与组织 window formats and organizations – 计时约束 timing constraint

• 根据接口的输入和输出重新陈述要求的功能 Restate the required functionality in terms of the interfaces' inputs and

outputs • 对每一个客户的质量需求，设计适配标准

Devise fit criteria for each of the customer's quality requirements


软件工程

4.8需求文档补充材料 4.6 规格说明的层次

• 调查现实需求规格说明的一个问题是：规格说明的层次是不均衡的 – 不同的书写风格 Different writing sytles – 经验的差异 Difference in experience – 不同的格式 Different formats – 对需求过分的说明 Overspecifying requirements – 需求说明不足 Underspecifying requirements

• 减少不均衡性的建议 – 每一个条款都应该只包含一个需求

• Write each clause so that it contains only one requirement – 避免使得一个需求引用另外一个需求

• Avoid having one requirement refer to another requirement – 把相似的需求放在一起

• Collect similar requirements together


软件工程

4.8需求文档补充材料4.7 隐藏的假设

• 两种类型的环境行为 – desired behavior to be realized by the proposed system – existing behavior that is unchanged by the proposed system

• often called assumptions(假设) or domain knowledge(领域知识)

• 大部分需求编写人员任务假设就是保证系统正常运行的条件


软件工程

4.8需求文档按对象组织的软件需求规格说明书的IEEE标准

1. Intodruction to the Document 1.1 Purpose of the Product 1.2 Scope of the Product 1.3 Acronyms, Abbreviations, Definitions 1.4 References 1.5 Outline of the rest of the SRS 2. General Description of Product 2.1 Context of Product 2.2 Product Functions 2.3 User Characteristics 2.4 Constraints 2.5 Assumptions and Dependencies 3. Specific Requirements 3.1 External Interface Requirements

3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces

3.2 Functional Requirements 3.2.1 Class 1 3.2.2 Class 2 …

3.3 Performance Requirements 3.4 Design Constraints 3.5 Quality Requirements 3.6 Other Requirements 4. Appendices


软件工程

4.8 需求文档过程管理和需求的可跟踪性

• 过程管理(Process management)是一套步骤，跟踪： – 定义系统应该做什么的需求 – 需求生成的设计模块 – 实现设计的程序代码 – 验证系统功能的测试 – 描述系统的文档

• 提供将系统部件联系起来的线索


软件工程

4.8需求文档开发活动

• Horizontal threads show the coordination between development activities


软件工程

4.9 确认和验证 • 需求确认(requirements validation), 检查需求定义是否准

确地反映了客户的需要 • 验证(verification), 检查文档和制品是否相符 • 确认(Verification)确保正确地构建产品(build the system

right), 验证(validation)确保构建正确的系统(build the right system)


软件工程

4.9确认和验证确认和验证技术

Validation Walkthroughs Readings Interviews Reviews Checklists Models to check functions and relationships Scenarios Prototypes Simulation Formal inspections

Verification Checking

Cross-referencing Simulation Consistency checks Completeness checks Check for unreachable states of transitions Model checking Mathematical proofs


软件工程

4.9确认和验证需求评审Requirements Review

• Review the stated goals and objectives of the system • Compare the requirements with the goals and objectives • Review the environment in which the system is to

operate • Review the information flow and proposed functions • Assess and document the risk, discuss and compare

alternatives • Testing the system: how the requirements will be

revalidated as the requirements grow and change


软件工程

4.9确认和验证补充材料4.8 需求故障的数目

• Jone and Thayes's studies show that – 35% of the faults to design activities for project of 30,000-35,000 delivered

source instructions – 10% of the faults to requirements activities and 55% of the faults to design

activities for projects of 40,000-80,000 delivered source instructions – 8% to 10% of the faults to requirements activities and 40% to 55% of the faults to

design activities for project of 65,000-85,000 delivered source instructions

• Basili and Perricone report – 48% of the faults observed in a medium-scale software project were attribute to

“incorrect or misinterpreted functional specification or requirements”

• Beizer attributes 8.12% of the faults in his samples to problems in functional requirements


软件工程

4.9确认和验证验证 Verification

• 检查需求规格说明文档是否对应于需求定义文档 – Check that the requirements-specification document corresponds to the

requirements-definition • 确保如果实现了满足需求规格说明的系统，则该系统就将满足客户的

需求 – Make sure that if we implement a system that meets the specification,

then the system will satisfy the customer's requirements • 确保定义文档中的每一项需求都可跟踪到规格说明

– Ensure that each requirement in the definition document is traceable to the specification


软件工程

4.9确认和验证补充材料 4.9 计算机辅助验证

• 模型检查(Model checking) 对规格说明执行空间的穷举搜索，以确定有关执行的一些时态逻辑性质是否成立 – Atlee (1996) used the SMV model checker to verify five

properties of an SCR specification of the A-7 naval aircraft • 定理证明器(theorem prover) 使用一组内嵌的定理、推

理规则、判定过程，来确定一个断言的事实集合是否逻辑地导出一些未断言的事实 – Dutertre and Stavridou (1997) used theorem prover PVS to verify

some of the functional and safety requirements of an avionic system


软件工程

4.10 测量需求 • 测量集中于3个领域

– 产品 product – 过程 process – 资源 resources

• 通过需求数目可以了解要开发的系统的规模有多大 • 需求改变的数目

– Many changes indicate some instability or uncertainty in our understanding of the system

• 需求规模和变化的测量应该按照需求类型来记录


软件工程

4.10测量需求 Rating Scheme on Scale from 1 to 5

1. You understand this requirement completely, have designed systems from similar requirements, and have no trouble developing a design from this requirement

2. Some elements of this requirement are new, but they are not radically different from requirements that have been successfully designed in the past

3. Some elements of this requirement are very different from requirements in the past, but you understand the requirement and can develop a good design from it

4. You cannot understand some parts of this requirement, and are not sure that you can develop a good design

5. You do not understand this requirement at all, and can not develop a design


软件工程

4.10测量需求 Testers/Designers Profiles

• Figure (a) shows profiles with mostly 1s and 2s – The requirements

are in good shape • Figure (b) shows

profiles with mostly 4s and 5s – The requirements

should be revised


软件工程

4.11 选择规格说明技术评估规格说明方法的标准

• 适用性 Applicability • 可实现性 Implementability • 可测试性/模 Testability/Simulation • 可检查性 Checkability • 可维护性 Maintainability • 模块化 Modularity • 抽象层次 Level of abstraction • 合理性 Soundness

• 可验证性 Veriability • 运行时安全性 Run time safety • 工具成熟度 Tools maturity • 宽松性 Looseness • 学习曲线 Learning curve • 技术成熟度 Technique maturity • 数据建模 Data modeling • 记录性 Discipline


软件工程

4.11选择规格说明技术 Steps

• 确定哪一种标准是最重要的 • 对照标准，评估每一个候选技术 • 选择为最重要标准提供最佳支持的规格说明技术


软件工程

Important of Specification Criteria During Reactive-System Life Cyle

• R=Requirements, D=Design, I=Implementation, T=Testing, M=Maintenance, O=Other

R D I T M O Criteria + + + + + + + +

+ + + + + +

+ + + + + +

+ + + + + +

+ + + + + + +

+ +

Applicability Implementability Testability Checkability Maintainability Modularity Level of abstraction Soundness Verifiability Runtime safety Tools maturity Looseness Learning curve Technique maturity Data modeling Discipline


软件工程

4.12 信息系统的例子 Picadilly Television System

• 高层图反应系统的基本功能

– Shows nothing about the ways in which each of these use cases might succeed or fail


软件工程

4.12信息系统的例子 Picadilly Television System: Message Sequence Chart


软件工程

4.12信息系统的例子 Picadilly Television System: Partial UML Class Diagram


软件工程

4.13 实时系统的例子

• Ariane-5 failed due to requirement validation not done properly – Requirements validation could have played a crucial

role in preventing the rocket's explosion • Two criteria that are especially important for

specifying a system such as Ariane-5 – Testability/simulation and runtime safety – SDL was rated “strong” for testability/simulation and

runtime safety


软件工程

4.13实时系统的例子 SDL Model

• SDL model for coin slot process that consists of several concurrent communicating process


软件工程

4.14 本章对你的意义 • 很重要的一点是，需求定义和规格说明文档描述的是问题，而将解决

方案的选择留给设计人员 • 引发需求的源和手段有多种 • 有很多种不同类型的定义和规格说明技术 • 不同的规格说明技术在…方面有所不同

– tool support, maturity, understandability, ease of use, and mathematical formality

• 可以适用建模或者原型来回答需求相关问题 • 必须确认需求，以保证它们真正反应了客户的期望

获取需求 - ustchome.ustc.edu.cn/~xiaoning/se2017/ppt/se_04_requirements...pfleeger and atlee,...

Documents