一、软件需求基础

1.1 需求的定义

1.1.1 需求开发阶段的必要性

需求开发阶段的主要任务就是分析问题，研究问题所发生的现实世界（即问题域），寻找实现软件系统与现实世界有效互动的办法，并严格描述该互动办法。而软件需求开发是一个连接现实世界与计算机世界的活动，是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提。如果需求开发过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错误修复代价较高，需求问题对软件成败的影响较大。而我们之所以认识不到需求开发阶段的重要性主要是因为学校时间项目的特殊性，具体来说学校的课程设计或实训：

问题广为人知或者需求非常明确。面对此类问题时，即使不采用需求开发的方法，开发人员也可以得到对问题的准确理解，进而开发出符合要求的系统。
问题小而简单。它们开发的代价较小，因此修复的代价也较小，即使全部推倒重来也不会有太大的影响。

所以学生在校园实践项目当中就感觉不到需求开发的重要性。

1.1.2 需求的定义

IEEE中的定义：

用户为了解决问题或达到某些目标所需要的条件或能力；
系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力；
对 1 或 2 中的一个条件或一种能力的一种文档化表述。

另一个定义：需求是用户的一种期望，是用户对问题域当中的实体状态或事件的期望描述。

1.1.3 需求的层次性

如下图所示，需求可以分为业务需求、用户需求、系统级需求三个层次。

业务需求：

抽象层次最高的需求称为业务需求(business requirement ) ，是系统建立的战略出发点，它描述了组织为什么要开发系统，描述系统高层次的解决方案，定义系统应该具备的特性，说明了系统为用户提供的各项功能，限定了系统的范围，帮助用户和开发者确定系统的边界，属于一个宏观目标。

用户需求：

用户需求(user requirement ) 是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。用户需求表达了用户对系统的期望，对所有的用户需求，都应该有充分的问题域知识作为背景支持。

系统级需求：

系统级需求( system requirement) 是用户对系统行为的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节。系统级需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。需要切记的是： 需求主要是描述用户对系统的期望，它以系统与外界的交互为主，所以即使是系统级需求也尽可能不要涉及系统的内部构造细节。

1.2 需求分类

根据不同的分类标准，可以将软件需求分成不同的种类。在各种软件需求的分类中，最常见的是[IEEE830- l 998] 的分类，［IEEE830-l 998] 将软件需求分成 5 种明确的类别：

功能需求( functional requirement )
性能需求(performance requirement )
质量属性( quality attribute)
对外接口(external interface )
约束( constraint )

1.2.1 功能需求

功能需求是和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求表现为系统和环境之间的行为交互，是软件需求中最常见、最主要、最重要的需求，也是最复杂的需求。

1.2.2 性能需求

速度( speed )，系统完成任务的时间
容届(capacity), 系统所能存储的数据量
吞吐量( throughput )，系统在连续的时间内完成的事务数量
负载( load ) ，系统可以承载的并发工作量
实时性( time-critical ) ，严格的实时要求

1.2.3 质量属性

一方面质量属性需求是隐式的；另一方面在后续的软件开发活动中，质量属性需求会极大地影响软件体系结构的设计，所以它被归为单独的一种需求类型。常见的质量属性有：

可靠性( reliability ) ：在规格时间间隔内和规定条件下，系统或部件执行所要求功能的能力
可用性(availability ): 软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率
安全性(security) ：软件阻止对其程序和数据进行未授权访问的能力
可维护性(maintainability) :为排除故障、改进质量或适应环境变化而修改软件系统或部件的容易程度
可移植性(portability) ：系统或部件能从一种硬件或软件环境转换至另外一种环境的特性
易用性(usability) :与用户使用软件所花费的努力及其对使用的评价相关的特性

1.2.4 对外接口

对外接口是指系统和环境中其他系统之间需要建立的接口，包括用户界面、硬件接口、软件接口、网络通信接口等。重要的用户界面接口需要提供界面原型。

1.2.5 约束

约束是指进行系统构造时需要遵守的约定，例如编程语言、硬件设施等。常见的约束主要有三类：

系统开发及运行的环境，包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。
问题域内的相关标准，包括法律法规、行业协定、企业规章等。
商业规则。用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围。

1.3 需求工程

1.3.1 主要任务和活动

需求工程有以下三个主要任务：

需求工程必须说明软件系统将被应用的环境及其目标，说明用来达到这些目标的软件功能，即要同时说明软件”需要做什么” 和“为什么需要做“。
需求工程必须将目标和功能反映到软件系统当中，映射为可行的软件行为，并对软件行为进行准确的规格说明。
现实世界是不断变化的世界，因此需求工程还需要妥善处理目标和功能随着时间演化的变动情况。

需求工程的基本活动如下图所示：

需求获取的目的是从空白开始建立最初的原始需求。需求分析的目的是保证需求的完整性和一致性。需求规格说明的目的是将完整、一致的软件解决方案以文档的方式固定下来。描述的结果文档是软件需求规格说明文档。需求验证的目的是保证软件需求规格说明文档的质撮，它要求文档内的需求正确地反映用户的真实意图，并保证整个文档的完整性和一致性。

1.3.2 需求获取

需求获取是从人、文档或者环境中获取需求的过程，需求工程师必须利用各种方法和技术来”发现“需求。需求工程师需要执行的重要任务有以下两方面。

目标分析：

根据问题确定目标。需求是用户在现实与理想之间有差距时产生的一种期望，因此要开发正确的需求，首先要发现这种差距（即用户的问题）。
通过分析利害关系人确定目标。

用户需求获取：

在目标的指导下，可以使用合适的需求获取方法从用户那里获得用户需求。常见的需求获取方法有：面谈、集体获取方法、头脑风暴、原型。

1.3.3 需求分析

需求分析的主要工作是通过建模来整合各种信息，以使得人们更好地理解问题。同时需求分析工作还会为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案。需求分析还需要检查需求当中存在的错误、遗漏、不一致等各种缺陷，并加以修正。需求工程师需要执行的重要任务有以下两方面。

边界分析：

系统的边界定义了项目的范围。系统边界之内定义的是系统需要对外提供的功能，系统边界之外标识的是对系统有功能要求的外部实体或者对系统有所限制的环境要素。系统用例图和上下文图通常用来定义系统的边界。

需求建模：

需求建模是需求分析中最为重要和基础的一项任务。它将大量信息以清晰、条理的方式集成到一个模型当中，让需求工程师对问题形成更为深刻的理解。常用的技术包括数据流图、实体关系图、状态转换图、类图等半形式化建模技术。

1.3.4 需求规格说明

获取的需求需要编写成文档，编写文档的主要目的是在系统用户之间交流需求信息，因此编写的文档应该具有一定的质量。最重要的质量要求是简洁、精确、一致和易于理解。

定制文档模板：

开发团队通常都会在其内部为各种需要编写的文档维护一些文档模板，模板为记录功能说明和其他与需求相关的信息提供了统一的结构。

编写文档：

有了定制的文档模板，就可以开始编写需求文档。在编写的过程中，一方面要选择最准确的表达方式；另一方面要注意保证文档的良好结构和易读性。通常，人们会同时使用模型语言（图形、表达式等）和自然语言（文本）两种表达方式。

1.3.5 需求验证

需求规格说明文档至少要满足下面几个标准：

文档内每条需求都正确、准确地反映了用户的意图
文档记录的需求集在整体上具有完整性和一致性
文档的组织方式和需求的书写方式具有可读性和可修改性

执行验证的方法有很多，同级评审是其中最通用、最有效的一个。在有些情况下，也需要使用原型或模拟等代价相对较高的验证方法。

1.3.6 需求管理

需求的影响力贯穿于整个软件产品的生命周期，而不是单纯的需求开发阶段。需求管理保证需求作用的持续、稳定和有效发挥，需求管理会进行变更控制，纳入和实现合理的变更请求，拒绝不合理的变更请求，控制变更的成本和影响范围。

二、需求分析方法

2.1 需求分析模型

需求获取中，需求工程师可以得到需求和问题域信息，但这些信息都是用户对现实世界的理解与描述，使用的是实际业务的表达方式。所以，需求工程师需要在需求获取之后进行需求分析，以解决获取信息与软件系统解决方案之间的差距，需求分析的任务是 :

建立分析模型，达成开发者和用户对需求信息的共同理解。
依据共同的理解，发挥创造性，创建软件系统解决方案。

模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解。建立模型的过程被称为建模，它是对系统进行思考和推理的一种方式。建模的目标是建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易。

抽象和分解是建模最为常用的两种手段：

抽象一方面要求人们只关注重要的信息，忽略次要的内容；另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节。
分解将单个复杂和难以理解的问题分解成多个相对容易的子问题，并掌握各子问题之间的联系，体现了问题求解中的“分而治之“思想。

常见的需求分析模型：

2.2 结构化分析

2.2.1 概念

结构化分析方法把现实世界描绘为数据在信息系统中的流动，以及在数据流动过程中数据向信息的转化。它帮助开发人员定义系统需要做什么（处理需求），系统需要存储和使用哪些数据（数据需求），需要什么样的输入和输出，以及如何把这些功能结合在一起来完成任务。

数据流图(DFD) 是结构化分析方法的核心技术，它表明系统的输入、处理、存储和输出，以及它们如何在一起协同工作。
实体关系图(ERD) 是结构化分析方法的另一个核心技术，用来描述系统需要存储的数据信息。
状态转移图(STD) 也是结构化分析方法常用的技术，可以通过识别系统需要做出响应的所有事件来定义系统的处理需求。
状态转移图后来发展成为面向对象方法的状态图。

2.2.2 数据流图DFD

数据流图将系统看做过程的集合，其中一些由人来执行，另一些由软件系统来执行。过程的执行就是对数据的处理，它接收数据输入，进行数据转换，输出数据结果。过程执行时可能需要和软件系统外的实体尤其是人进行交互，会要求外界提供数值输入或者将数据结果提供给外部实体。

基本元素：

外部实体是指处于待构建软件系统之外的人、组织、设备或者其他软件系统，它们不受系统的控制，开发者不能以任何方式操纵它们。
过程是指施加千数据的动作或者行为，它们使得数据发生变化，包括被转换、被存储或者被分布。
数据流是指数据的运动，它是系统与其环境之间或者系统内两个过程之间的通信形式。DFD 的数据流是必须和过程产生关联的，要么是过程的数据输入，要么是过程的数据输出。
数据存储是软件系统需要在内部收集、保存，以供日后使用的数据集合。如果说数据流描述的是运动的数据，那么数据存储描述的就是静止的数据。

语法规则：

过程是对数据的处理，必须有输入，也必须有输出，而且输入数据集和输出数据集应该存在差异。
数据流是必须和过程产生关联的，它要么是过程的数据输入，要么是过程的数据输出。
DFD 中所有的对象都应该有一个可以唯一标识自己的名称。过程使用动词，外部实体、数据流和数据存储使用名词。

分层结构：

在分层结构中， DFD 定义了三个层次类别：上下文图(context diagram)、0 层图( level-0 diagram) 和N 层图(level-N diagram , $N$ >0) 。

上下文图是DFD 最高层次的图，是系统功能的最高抽象。上下文图将整个系统看做一个过程，实现系统的所有功能。所以，上下文图中存在且仅存在一个过程，表示整个系统。这个单一的过程通常编号为0 。在上下文图中需要表示出所有和系统交互的外部实体，并描述交互的数据流，包括系统输入和系统输出。
在DFD 的层次结构中，位于上下文图下面一层的就是0 层图。它被认为是上下文图中单一过程的细节描述，是对该单一过程的第一次功能分解，它需要在一个图中概括系统的所有功能。0 层图通常被用来作为整个系统的功能概图。为了概述整个系统的功能，建立0 层图时需要分析需求获取的信息，归纳出系统的主要功能，并将它们描述为几个高层的抽象过程。
0 层图中的每个过程都可以进行分解，以展示更多的细节。被分解的过程称为父过程，分解后产生的揭示更多细节的图称为子图。对 0 层图的过程分解产生的子图称为1 层图。对 $N$ 层图的过程分解后产生的子图称为 $N+1$ 层图。在低与 0 层图的子图上通常不显示外部实体。父过程的输入输出数据流称为子图的接口流，在子图中从空白区域引出。如果父过程连接到某个数据存储，则子图可以不包括该数据存储，也可以包括该数据存储。子图中过程的编号需要以父过程的编号为前缀。

过程分解的平衡原则：要求DFD 子图的输入流、输出流必须和父过程的输入流、输出流保持一致。

2.2.3 实体关系图ERD

实体关系图(Entity Relationship Diagram, ERD) 是能够弥补 DFD 在数据说明方面的缺陷，描述数据的定义、结构和关系等特性的技术。实体关系图使用实体、属性和关系三个基本元素来描述数据模型，它最常见的两个图形表示法是Peter Chen 表示法和 James Martin 表示法。下图是 James Martin 表示法：

Peter Chen 表示法如下：

2.3 面向对象分析

面向对象分析方法认为系统是对象的集合，这些对象之间相互协作，共同完成系统的任务。面向对象分析方法有儿个主要的优点，其中包括自然性和可复用性。统一建模语言( Unified Modeling Language, UML ) 是面向对象分析的主要模型技术。UML 其实是很多种技术的综合体，而非一种单一的技术。

2.3.1 用例图

面向对象分析方法主张使用用例作为需求获取和组织的主要手段，用例有多种定义：

UML 将用例定义为“在系统（或者子系统或者类）和外部对象的交互中所执行的行为序列的描述，包括各种不同的序列和错误的序列，它们能够联合提供一种有价值的服务”。
[Cockburn2001] 认为用例描述了在不同条件下系统对某一用户的请求的响应。根据用户的请求和请求时的系统条件，系统将执行不同的行为
序列，每一个行为序列被称为一个场景。一个用例是多个场景的集合。
换句话说，每个用例是对相关场景的集合，这些场景是用户和系统之间的交互行为序列，帮助实现用户的目的。
更精确地说，一个用例承载了所有与用户某一个目标相关的成功和失败场景的集合。用例是一个理想的容器，以交互的方式记录系统的需求。

用例图 (Use-Case Diagram ) 的基本元素有4 种：用例、参与者、关系和系统边界。用例是用例模型最重要的元素，使用一个水平的椭圆来表示。发起或参与一个用例的外部用户以及其他软件系统等角色被称为参与者。它的图示是一个小人。系统边界是指一个系统所包含的系统成分与系统外事物的分界线。用例图使用一个矩形框来表示系统边界，以显示系统的上下文环境。

画图要点：

在画用例图时，可以根据下面几点确定用例：

位于系统边界之内，用例是从外部用户角度出发系统所提供的功能和服务，定义了系统的行为特征。
以动宾短语的形式出现，如修改订单，用例表达的是一次完整的人机交互序列。
用例相对独立，在功能上完备，无需与其他用例交互，如转账是一个用例，输入收款账号就不是。
用户的执行结果对参与者来说是可观测且有意义的，如系统内部的性能监控就不是一个用例。
用例由参与者启动，不能自启动也不能由另外一个用例启动。

参与者的UML表示方法有图标表示法和标签表示法两种，参与者具备的基本特征为：

位于系统边界之外。
直接且主动的向系统发出动作并获得反馈。

用例图的关系：

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。简单来说包含关系就是指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 判断方法：只有将被包含的用例都执行完成，基础用例才能执行。
拓展关系：一个用例扩充了另外一个用例的功能，只有在满足特定条件的情况下才会被执行。
关联关系：表示参与者与用例间的关系，用于两者建立连接。
泛化关系：参与者之间特殊与一般的关系，即子类和父类的关系

Use22CaseDiagram1

举例：

仅做参考，文字描述不完整。

图书馆系统用例图

2.3.2 用例描述

用例规约就是以用例为核心来组织需求内容的需求规约，用例通过前置条件（precondition）、后置条件（postcondition）以契约的形式表达需求。

前置条件：用例开始前，系统需要满足的约束。
后置条件：用例成功结束后，系统需要满足的约束。
前置条件、后置条件必须是系统能检测的。前置条件必须是用例开始前系统能检测到的。前置后置条件是状态，不是动作。前置后置条件要用核心域词汇描述。“已登录”不应作为前置条件。

2.3.3 概念类图（领域模型）

在进行系统分析时，开发人员关注系统与外界的交互，而不是软件系统的内部构造机制，所以分析阶段的类图与设计阶段的类图有所不同，它关注用户的业务领域，称为概念类图，又称为领域模型。类型、方法、可见性等复杂的软件构造细节都不会在概念类图中出现。

类与对象

对象：

对象的概念是面向对象分析方法的基础。在面向对象分析模型中，对象是对具体问题域事物的抽象，有三个方面的内容：标识符、状态、行为。状态是对象的特征描述，包括对象的属性和属性的取值，属性是描述对象时使用的特征选项。行为是对象在其状态发生改变或者接收到外界消息时所采取的行动。

类：

对象是类的实例，每个类都有能够唯一标识自己的名称，同时包含有属性和行为方法。概念类图中的类大多是概念类，，概念类会显式地描述自己的一些重要属性，但不是全部的详细属性，而且概念类的属性通常没有类型的约束。概念类不会显式地标记类的行为，即概念类不包含明确的方法。

属性定义语法

属性的描述方法为：[可见性] 属性名 [: 类型] [ [多重性] ] [ =初始值 ] [{特性串，特性串}]，其中 [ ] 内的为可选内容。

可见性：类的成员是否可以被其他类可见或者访问，有如下几种：
类型：属性值的类型，比如string、int等，类型名可以自定义。
多重性：类的实例中有多个该属性的实例，如一个具体的用户（实例）可以有多个电话号码属性（实例），如[1..2]，省略号左右定义上限和下限。
初始值：属性初始化即具有的值。
特性串：属性其他需要特别说明的特性，比如{readonly}，表示只读属性。

操作定义语法

[可见性] 操作名称 ([参数列表]) [: 返回类型] [{属性字符串}]

属性列表：定义操作的参数，放在( ) 中，定义语法为： [方向] 参数名：类型 [= 默认值]，这里的方向指的是操作调用时该参数的传递方向，有如下几种：
属性字符串：说明操作的特殊性或约束

链接

系统中的对象不是孤立存在的，它们需要互相协作完成任务。对象之间的这种互相协作的关系称为链接，它描述了对象之间的物理或业务联系。链接通常是单向的，也可以是双向的。如果一个对象a 存在指向b 的链接，那就意味着a能够在链接的指引下，正确地找到并将消息发送给b 。

关联

类之间的关系被称为关联，它指出了类之间的某种语义联系。类是对象集合的抽象，关联则是对象之间链接的抽象。对象依据关联所带有的信息进行链接的建立和撤销，如果两个类之间没有关联，那么两个类的对象实例之间就不存在链接，就无法实现相互协作。UML 使用类（对象）之间的直线来表示关联（链接），它可以是单向的（带有方向箭头），也可以是双向的（无方向箭头）。另外，如果类之间的关联关系也拥有一些属性和操作，那么可以把这个操作独立出来写成一个关联类，如下图所示就是一个关联类的示例。

Main1

另外，关联之间也存在多重性，可以用上下限表示法来表达关系之间的多重性，下图表示5到多名球员可对应1个球队：

关联存在自身关联，为了表达清晰可以写出两端的角色，如下示例：

继承与泛化

一个类可以继承另外一个类的属性和操作，即子类继承父类，继承的识别可以通过子类是否为父类的一种来判断，如蜂鸟是一种鸟，所以蜂鸟继承鸟。在UML中有泛化的概念，它和继承类似，泛化指一般化的过程，示例如下：

接口

接口是一组操作的集合，这组操作用于描述类或者构件的一个服务，需要描述这些操作的特征标记（可见性、参数、范围）

供接口：表示一个类对外提供的服务，可以与提供服务的类构成实现关系。
需接口：表示一个类需要的其他类的服务，可以与需要服务的类构成依赖关系。

棒糖图：

下图所示的是类的表示方式和棒糖图的表示方法

依赖与实现

依赖： 类 A 使用类 B 的信息和服务，类 B 的变化会影响到类 A，则称A依赖B，这种关系可能是偶然性的、临时性的，属于比较弱的关系，如下：

Main

接口： 接口中仅仅定义操作的归约（即操作的特征标记），而不给出操作的实现，抽象方法：只有归约没有实现的操作，如下：

实现： 类对接口中的操作（抽象方法）给出具体实现，类在实现接口的抽象方法时，方法规格的定义与接口中必须完全相同，如下：

聚合与组合

聚合： 描述整体-部分之间的关系，如下示例：

组合： 在某一时刻，部分类的实例只属于一个整体，表示整体拥有部分，比如桌腿和桌子。如果整体对象被销毁了，那么部分对象也会被销毁，或者依附于其他对象，画法如下：

2.3.4 交互图（顺序图）

对象需要相互协作才能完成任务，交互图( Interaction Diagram ) 就是描述对象协作的技术。顾名思义，交互图用于描述在特定上下文环境中一组对象的交互行为，这个上下文环境通常被指定为用例的场景。所以，交互图通常描述的是单个用例的典型场景，它也因此被称为“用例的实现“ 。交互图有顺序图、通信图、交互概述图和时间图4 种类型，其中顺序图是最为常用的一种。在此主要讲述顺序图。

顺序图将交互表示成一个二维图表。纵向是时间轴，时间沿纵轴向下延伸。横轴表示了参与协作的对象。图的内容以交互行为中的消息序列为主，消息以时间顺序在图中从上到下排列。

顺序图的基本概念包括：对象、生命线、控制焦点和消息

对象

顺序图中的对象(Object)，可以是系统参与者或任何有效的系统对象。
对象置于顺序图的顶部，意味着交互开始时对象就已经存在了。
对象不置于顶部，意味着对象是在交互过程中创建的。
三种表示形式：

顺序图中经常使用分析类的对象，一共有三种：
- 边界类：系统界面，负责输入信息或展示输出。
- 控制类：负责对界面输入的数据进行计算。如果计算结果需要保存，则传递给实体类。如果计算结果需要输出，则传递给边界类。
- 实体类：负责存储计算的结果。

生命线

生命线(Lifeline)是一条垂直的虚线，用于表示顺序图中的对象在一段时间内的存在。对象与生命线结合在一起称为对象的生命线。

控制焦点

控制焦点(Focus of Control，也称为激活)是对象操作的执行，表明对象正在进行交互。它表示一个对象直接或通过从属操作完成操作的过程。控制焦点在顺序图中用一个细长的矩形框表示，它的顶端与激活时间对齐，而底端与完成时间对齐。一个被激活的对象要么执行自己的代码，要么等待另一个对象的返回结果。对象在完成自己的工作后，被去激活，对象就处于空闲状态。

消息

消息(Message)是从一个对象(发送者)向另一个或几个其他对象(接收者)发送信号，或由一个对象(发送者或调用者)调用另一个对象(接收者)的操作。消息主要包括编号、名称、类型等组成部分。类型由不同形式的带箭头的线段表示，线段上方标注“编号：名称”格式的消息文本。通常一个顺序图的消息流从左上方开始，消息按照先后顺序从上到下排列。

消息的编号可以进行嵌套，表示包含关系，把属于同一个对象发送和接受的消息放在同一层进行编号：

消息的名称： [守卫条件] [序列表达式] [返回值 := ] 消息名 [(参数列表)]

守卫条件：形式为 [条件短语]，用伪代码表示，如 2 : [x<0] invert(x,y)
序列表达式：表示一个循环或者选择的执行：
- *[循环字句]：重复执行
- [条件语句] :选择某个分支执行

调用操作：形式为[返回值：]消息名[(参数列表)]，消息经常是调用对象的某个操作，而操作可能具有参数和返回值

2.3.5 状态图

状态图常用的简单元素包括状态、开始状态、结束状态、事件、监护条件、活动和转换。

按照下列步骤可以建立一个状态图：

确定上下文环境。状态图是立足于状态快照进行行为描述的，因此建立状态图时首先要搞清楚状态的主体，确定状态的上下文环境。常见的状态主体有类、用例、多个用例和整个系统。

识别状态。状态主体会表现出一些稳定的状态，它们需要被识别出来，并且标记出其中的初始状态和结束状态集。在有些情况下，可能会不存在确定的初始状态和结束状态。
建立状态转换。根据需求所描述的系统行为，建立各个稳定状态之间可能存在的转换。
补充详细信息，完善状态图。添加转换的触发事件、转换行为和监护条件等详细信息。

三、需求文档化与验证

3.1 需求文档基础

3.1.1 需求文档的交流对象

用户。用户要验证文档内描述的需求信息是否与其最初的意图相一致。
项目管理者。软件需求文档全面、准确地定义了软件的功能和非功能要求，因此，项目管理者可以基千它进行软件估算，并根据估算数据安排项目进度和人员分工。
设计人员和程序员。设计人员和程序员需要依据软件需求文档来完成自己的任务。文档内容是其工作是否正确的一个重要判断标准。
测试人员。测试人员需要根据文档的需求内容进行验收测试，确保最终产生的软件系统能够满足用户的要求。
文档编写人员。用户使用手册的编写人员需要依据需求信息编写用户使用手册，包括确定手册的内容和要点。
维护人员。在软件维护当中，维护人员需要在充分理解软件原有需求的基础上进行信息的修改。

3.1.2 常见的需求文档

用例文档和软件需求规格说明文档是最为常见的两种需求文档，用例文档从用户的角度以用例文本为主描述软件系统与外界的交互，软件需求规格说明文档则从软件产品的角度以系统级需求列表的方式描述软件系统解决方案。软件需求规格说明文档描述了软件系统的解决方案，有很多不同的格式类型。

3.2 需求文档化要点

3.2.1 技术文档写作要点

简洁：技术文档与文学作品的最大区别是技术文档必须简洁。技术文档很少会使用各种修辞手法，都是平铺直叙。技术文档的书写主要使用简单语句，主要由动词、名词和一些辅助词组成，尽量不要使用复杂长句，避免使用形容词和副词。

精确：精确文档的书写不能使用模糊和歧义词汇，尤其是那些比较常用的模糊和歧义词汇。

易读（查询）：技术文档被使用的主要目的是进行交流与沟通，所以它必须具有易读性。主要有两个特点：有效使用引言、目录、索引等能够增强文档易读性的方法。使用系统化的方式组织内容信息，提供文档内容的可读性。

易修改： 技术文档通常会随着开发工作的持续而被不断修改，所以技术文档还要易于修改。能够增强技术文档易读性的目录、索引和系统化表达方式都能有效提高文档的可修改性，使得技术文档易修改的另一个注意事项是用引用代替重复。

3.2.2 需求写作要点

使用用户术语：需求文档有一个极其重要、不可忽视的读者一用户，他们要验证需求文档的内容是否符合自己的最初意图。因此，在书写需求时，要首先保证能够对用户易读，尽量使用用户的语言和问题域的概念。

可验证：需求应该是可验证的，通过分析、检查、模拟或者测试等方法能够判断需求是否被满足。在进行需求的描述时要让需求具体化，小心形容词和副词的使用，避免程度词的使用。

可行性： 需求必须能够在系统及其运行环境的已知条件和约束下实现。需求可行性不仅要考虑理论上的技术实现可能性，更要考虑在限定的成本、时间和人员约束内，实现需求的可能性。

3.2.3 软件需求规格说明文档书写要点

充分利用标准的文档模板，保待所有内容位置得当。
保持文档内的需求集具有完备性和一致性。
为需求划分优先级。需求优先级的划分要充分考虑用户的意见，因为他们是需求是否重要和必要的唯一评判者。

3.3 评审软件需求规格说明文档

评审是进行需求验证与确认的主要方法，原则上每一条需求都应该进行评审。进行软件需求规格说明文档评审时，要注意以下事项：

重视需求评审，需求基础是影响项目成败的重要因素，忽视需求验证是需求工程中的最大风险之一。
需求评审的组织，需求评审的组织在下列方面有自己的要求：
- 评审的人员不能仅由技术人员组成，必须包括客户和用户
- 在评审中使用线索
- 使用需求检查列表

3.4 以需求为基础开发系统测试用例

在需求开发完成之后，测试人员就可以以需求为基础开发系统测试用例（主要是功能测试）了。在为需求开发测试用例的过程中可以发现软件需求规格说明文档的缺陷与问题。以需求为基础开发系统测试用例有两个步骤：

以需求为线索，开发测试用例套件；
使用测试技术确定输入／输出数据，开发测试用例。

3.4.1 开发测试用例套件

以需求列表为线索，可以开发测试用例套件。测试用例套件是测试用例的集合，它将相关的测试用例组织在一起，通常每个测试用例套件是目标明确的一项功能。原则上，除测试代价过高或者测试难度过大的需求之外，所有的需求都应该有测试用例套件覆盖。使用用例描述的正常流程和异常流程作为线索可以很好地满足这一点。

3.4.2 开发测试用例

对确定的测试用例套件，使用软件测试技术，主要是基千规格的技术，设计测试场景的输入与输出数据，建立测试用例。

3.5 将需求制品纳入配置管理

在完成需求开发之后，要及时地将需求阶段的重要制品纳入配置管理。这些重要的制品包括：

需求分析模型；

需求文档；

系统测试用例。