软件工程概论（四） 获取需求

I. The Requirements process（需求过程）

1、需求就是对期望的行为的表达。需求处理的是对象或者实体（输出），他们可能处于的状态（输出形式），以及用于改变状态或对象特性的功能（产生输出或修改形式）。

2、标记关键实体，限定实体，定义实体间的关系。

3、特定于实现的描述不是需求，除非是客户说的。需求就是确定客户的问题和需要，而不是解决方案。首先，抽象为现实世界中现象之间的交互，就能抓住客户需求的核心内容，易用客户熟悉的方式陈述。

4、是否敏捷，需求分析起很大作用。需求复杂时，就重点分析；需求不定，就敏捷开发。极限编程里需求是测试用例，但用例不等于客户真正的需求。

II. Requirements elicitation（需求引发）

需求引发是过程中极为关键的一部分，我们必须用各种技术来确定用户和客户到第要什么。

在项目的早期阶段，需求对每一个人来讲都是含糊的，形式也是混乱的。客户并不总是删除于准确描述他们想要什么，开发人员并不总是擅长理解他人的业务含义。只有通过同每一个与系统成败相关的人讨论需求，将这些不同的观点合并成一组需求，并且与风险承担者一起评审这些文档，才能使所有人对需求是什么达成一致。

谁是风险承担者？

委托人：有最终话语权，为开发支付费用的人
客户：在软件开发之后购买软件的人。
用户：最终使用系统的人，了解实际需求以及特殊需求
领域专家：软件内容所涉及领域的专家
市场研究人员：进行调查，确定将来趋势以及潜在客户需要的那些人
律师或审计人员：对政府、安全性以及法律需求熟悉的那些人
软件工程师或其它技术人员：技术评估

需求引发的手段:

与风险承担者进行会谈
评审可用文档
观察当前系统（如果存在），收集关于用户如何执行任务的客观信息。
做用户的学徒，在用户执行任务时，更详细的学习。
使用特定领域策略
就如何改进将要构建的产品，与当前潜在用户一起讨论

III. Types of requirement（需求类型）

1、Functional requirements！！

根据要求的活动（如对输入的反应、活动发生时每一个实体之前的状态和之后的状态）来描述需要的行为。
功能需求定义问题解决方案空间的边界。解决方案空间是使得软件满足需求的设计方式的集合。最初，该集合可能会很大，但是，实践中就一个软件产品而言，仅仅是计算正确的输出是不够的，还有其它类型的需求，将可接受的产品和不可接受的产品区分开来。

2、Quality requirements/nonfunctional requirements！！

质量需求或非功能需求，描述一些软件解决方案必须拥有的质量特性，如快速的响应时间、易使用性、高可靠性或低维护代价。

3、Design constraint

设计约束是已经作出的设计决策或限制问题解决方案集的设计决策，如平台或构件接口的选择。

4、Process constraint

过程约束是对用于构建系统的技术和资源的限制。例如，客户可能坚持使用敏捷方法，以便在继续增加新特征时能够使用早期版本。

质量需求、设计约束以及过程约束通过将可接受的、喜欢的解决方案与无用的产品加以区分，进一步限制了我们的解决方案空间。

IV. Resolving conflicts - priority

一种大致的优先级划分方案可能将需求划分为以下三类：

绝对要满足的需求（必要的）
非常值得要但并非必需的需求（值得要的）
可要可不要的（可选的）

在解决质量需求之间的冲突时，优先级非常有用。通常，两种属性是会冲突的，这就不能同时优化两者。对质量需求划分优先级迫使用户在那些软件质量因素中选择最关心的因素，有助于开发人员根据客户的质量需求，提供合理的解决方案。

V. Two kinds of requirements documents

Requirements definition

面向业务相关的人员，如委托人、客户以及用户
需求定义是客户想要的每一件事的完整列表。该文档根据环境编写，说明系统如何影响环境，以及关于这些实体的约束、监控和转换，来表述需求。

Requirements specification

面向技术性人员，如设计人员、测试人员以及项目经理
需求规格说明将需求重新陈述为关于要构建的系统如何运转的规格说明。该规格说明也是完全按照环境来编写，唯一的区别是它仅仅提及系统提供其接口可访问的环境实体。需求定义可以处于环境域的任何地方。规格说明仅仅限制在环境域和系统域的交集处。

VI. Modeling notations！！（建模）

软件工程原理的一个显著特性是，它具有用于开发安全的、成功的产品的可重复过程。第二个显著特征是，存在用于建模、文档化和交流决策的标准表示法。

1、Entity-relationship diagrams！！(实体-联系图——UML类图）

Definition

是一种表示概念模型的图形表示法范型，主要描述对象、实体，以及实体之间的关系。是大多数面向对象需求和设计表示法的基础。

Three elements

实体：表示为矩形，代表具有共同性质和行为的现实世界对象构成的集合（有时称为类）
联系：表示为两个实体之间的边，边的中间有一个菱形，说明联系的类型。
属性：是实体上的注释，描述实体相关的数据或性质。

Properties/application

ER图被广泛使用的原因：
它提供要解决问题的总体概况，并且当问题的需求发生变化时，该视图是相对稳定的。由于这两个原因，ER图更可能在需求过程的早期用于建模问题。

ER表示法的简单性具有欺骗性。事实上，在实践中有效的使用ER建模表示法相当困难。即使只有三个主要的建模结构，在什么样的细节层次上建模具体的问题也不是那么容易，同样，要确定什么数据是实体，什么数据是属性可能也是困难的。
对每一个选择，都有两种相反意见。判断的主要标准是：这个选择是否产生了更为清晰的描述，这个选择是否不必要地限制了设计决策。

UML（ Unified Modeling Language ) class diagrams

统一建模语言是用于文档化软件规格说明和设计的一组方法。

由于UML最初是用于开发面向对象系统的，应而UML根据对象和方法表示系统。对象类似于实体，按照具有继承层次的类进行组织。每一个对象提供方法，在对象的变量上执行动作。在对象执行的过程中，他们发送消息来调用其它对象的方法、确认动作、传送数据。

在所有UML规格说明中，类图是旗舰模型。
类图虽然被普遍认为是设计表示法，但用于表示概念也是可以的。
概念模型中的类，可以是一个程序类，也可以不是，因为本质上是为了表示现实世界中的实体。
一般来说实体包括，参与者（如主顾、操作员、人员），要存储、分析、转换或显示的复杂数据，瞬时时间的记录等（业务事物、电话交谈）等

UML通俗解释：UML类图总结

2、Event traces（事件踪迹——时序图）

Definition

事件踪迹是关于现实世界实体之间交换的事件序列的图形描述。每一条竖线表示不同实体的时间线，其名字出现在线的顶部。每一条水平线表示两个实体之间的一个事件或交互，通常理解为一个实体到另一个实体的消息传递。时间按从顶向下进展。
每一个图描述一个踪迹，表示的只是若干可能行为中的一个。

Properties/application

事件追踪广泛用于开发人员和客户中，因为除了计时问题，事件追踪的语义相对精确且易于理解。其简单性多数是因为它将需求描述分为场景，将每一个场景分别考虑（建模、阅读、理解）为不同的踪迹。
由于这些特性，事件踪迹对于文档化系统的行为并不是非常有效。
事件踪迹最好用在项目的开始，以对关键需求达成共识，并帮助开发人员识别正在建模的问题中的重要实体。

UML sequence diagrams

消息时序图是扩充的事件踪迹表示法。具有创建和撤销实体、指定动作和计时器，以及组合事件踪迹的能力。

消息时序图详解

3、State machines（状态机——状态图、Pertinent）

Definition

状态机表示法用于在单个模型中表示一组事件踪迹。状态机是一种图形描述，描述了系统与其环境之间的所有对话。

Two elements

每一个节点称为状态，表示存在于事件发生之间的一个稳定的条件集合。
每一个边称为转移，表示由于一个事件的发生而产生的行为或条件的变化。

每一个转移都标记有触发事件，还可能有输出事件，前面用符号‘/’表示，输出事件是转移发生时产生的。

一条通过状态机的路径，起始于状态机的初始状态，沿着状态到状态的转移，表示了环境中的一条可观察事件的踪迹。如果状态机是确定的（即对每一个状态和事件都有唯一的响应），那么，通过该状态机的一条路径表示将要发生的事件踪迹，给出触发路径转移的输入事件序列。

Properties/application

在表示动态行为方面，以及在描述在响应已经发生的历史事件时行为将如何变化方面，状态机都是很有用的。
特别适合的建模模型是：
随着系统的执行过程，对于同样的输入，系统响应是如何变化的。
对每一个状态，从那个状态发出的转移集指明可能触发一个响应的事件集及对事件集的相应响应。

UML statechart diagrams

UML状态图

4、Data-flow diagrams(DFD)！！（数据流图——用例图）

Definition

数据流图建模：功能以及从一个功能到另一个功能的数据流。

Four elements

椭圆表示一个加工或功能，它转换数据。
箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。
持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。
数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

一个椭圆可以是另一个数据流图的高层描述，它更详细的说明该抽象功能是如何计算的。一个最低层的椭圆是一个功能，如前置条件、后置条件、异常等，其效果可以用另一种表示法在一个链接的单独文档中加以说明。

Properties/application

优点：
提供了两种直观模型，一种是关于被提议系统的高层功能，一种是各种加工数据之间的依赖关系。
领域专家容易理解。
缺点：
对于不太熟悉正在建模的问题的软件开发人员来讲，数据流图含糊不清。

因此，DFD最好由熟悉正在建模的应用领域的用户使用，并且最好作为问题的早期模型使用，因为此时细节并不是很重要。

5、Functions and relations

一些形式化范型将需求或软件行为建模为一组数学函数或关系，当组合在一起时，将系统输入映射到系统输出。一些函数说明系统的执行状态，而其它一些函数说明输出。当一个输入值映射到多个输出值时，就使用关系，不使用函数。

Decision table

判定表是函数规格说明的表格表示，将事件和条件映射到适当的反应或动作上。该规格说明是非形式化的，因为输入（事件和条件）和输出（动作）可以用自然语言表示，也可以用数学表达式表示，或者同时使用两者。

优点：
容易检查，看看是否满足条件，是否完备，是否有冲突，以及明确条件与动作的关联之处。

判定表示例

VII. Prototyping requirements（原型化）

大部分人发现，详细地评论一个现有的产品比详细想象一个新的产品要容易得多。同样，能够引发细节的一种方式是构建被提议系统的原型，并请求潜在用户反馈。他们希望看到哪些方面被改进，哪些特征不那么有用，遗漏了哪些功能。构建原型还有助于确定客户的问题是否有一个可行的解决方案，或者帮助我们探讨优化质量需求的可选方案。

Rapid prototyping

Throwaway prototyping

抛弃型原型是为了对问题或者提议的解决方案有更多了解而开发的软件，永远不会作为交付软件的一部分。
允许我们去编写“快速但不考虑质量的软件”，但是能够迅速抓住我们面临的问题的核心。

Evolutionary prototyping

演化型原型不仅帮助我们回答问题，而且还要演变为最终产品。这类软件在开发必须展现最终产品的质量需求（如响应速度、模块化），并且这些质量的要求不能改进。

Prototyping vs. modeling

探索关于需求的问题有两种方式，建模或者原型化。哪一种方法更好，取决于我们的问题是什么。

用原型更容易回答关于用户界面的问题。原型实现了一些提议的特征，将更有效的帮助用户对这些特征的进行优先级划分，并可能识别出一些不必要的特征。

关于事件将要发生的顺序这样的约束问题，或者关于活动同步这样的问题，使用模型能够更快速的得到答案。

最终都要给出需求文档，二者之间哪种更好，取决于哪种能更好地帮助后续的软件开发。