系统分析师学习笔记（十二）

软件需求工程

软件需求概述

软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。

1.需求的层次

（1）业务需求。业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，项目视图和范围文档把业务需求集中在一个简单、紧凑的文档中，该文档为以后的开发工作奠定了基础。
（2）用户需求。用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求。
（3）系统需求。系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能（服务），使用户的业务目标得以满足；非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性（例如，可维护性、可维护性、效率等）和其他非功能需求。

2.质量功能部署
质量功能部署（Quality Function Deployment，QFD）是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

（1）常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
（2）期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
（3）意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。

需求获取

用户访谈

用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。

1.准备访谈
在准备访谈过程中，首先也是最重要的步骤是确定访谈的目的，其次是确定访谈中应该包括哪些用户。准备访谈的第三步是为访谈准备一些详细的问题。准备访谈的最后一步是作出最终的访谈安排，并把这些安排通知所有参加者。

2.访谈过程
在访谈的过程中，要做好以下几项工作：

（1）限制访谈时间。当确定了访谈目的并准备好了问题之后，访谈的时间应该控制在90分钟左右。如果访谈需要更多的时间来覆盖一些其他的问题，比较好的方法是中断本次访谈，并安排另一次访谈，因为举行几次比较短的访谈要比举行一次马拉松式访谈的效果要好得多。
（2）寻找异常和错误情况。系统分析师要找机会问一些类似于“如果……那会怎么样”的问题，要有意识地去确定所有的特殊情况，并与用户深入探讨。
（3）深入调查细节。除了寻找意外情况外，系统分析师必须进行深入调查，以确保获得对过程和规则的完全理解。
（4）认真作好记录。主要包括本人记录、第三人记录或者是录音/录像的形式。如果采用录音/录像的方式，应该征得被访谈者的同意。

3.访谈的后续工作
后续工作的首要任务是吸收、理解和记录访谈所获得的信息。

4.用户访谈的优缺点
用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。

问卷调查

1.调查表的制作
一张好的问卷调查表要花费大量的时间来进行设计与制作，包括确定问题及其类型、编写问题、设计问卷调查表的格式三个重要活动。

（1）确定问题及其类型。与用户访谈一样，问卷调查表上使用的基本问题有开放式问题和封闭式问题。但不同的是，问卷调查表的问题必须非常清楚，组织顺序必须有说服力，必须能够预见用户可能的回答。
（2）编写问题。在具体问题的编写中，要注意使用“用户的语言”，不要使用含糊的词语，但也要避免过度明确的问题，保持问题的简短，避免措词上的偏向。
（3）设计问卷调查表的格式。一份精心设计的、恰当的问卷调查表，能帮助用户克服不愿意回答问题的情形。设计调查表的格式时，应该提供足够的空白空间让用户填写表格。对用户重要的问题放在最前面，内容相似的问题放在一起。

2.问卷调查的优缺点
问卷调查最大的不足就是缺乏灵活性，其他缺点还有：

（1）双方未见面，系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息，用户也没有机会立即澄清对问题有含糊或错误的回答。
（2）用户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。
（3）调查表不利于对问题进行展开的回答，无法了解一些细节问题。
（4）回答者的数量往往比预期的要少，无法保证用户会回答问题或进一步说明所有问题。

3.提高问卷返还率的方法
为了提高问卷返回率，通常可以采取以下措施：

（1）向所有的工作人员解释问卷的目的，以及如何使用这些信息。
（2）说明这份问卷是（客户）企业的每个工作人员都要回答的。
（3）拜托相关领导督促他所管辖的工作人员回答问卷，并及时返还。
（4）尽量参加一次（客户）企业的全体会议，在会议上解答工作人员提出的问题，并解释这些信息的用处。
（5）更改问卷中的问题，尽量减少回答问卷所花费的时间。
（6）设置一些奖品或奖励，激励大家及时返还问卷。

采样

1.样本大小
采样技术的关键是如何确定样本集的规模，即如何确定样本大小，使样本具有代表性。事实上，这又取决于希望样本具有多大的代表性。有研究人员给出了一个用于确定样本大小的既简单又有效的公式：样本大小 = α×(可信度系数/可接受的错误)2
其中，α称为启发式因子，一般取值为0.25；可信度系数表示希望“种群数据包括了样本中的各种情况”有多大的可信度，这个值可以根据可信度从表中查出来：

2.采样的优缺点
通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。

情节串联板

1.情节串联板的概念
情节串联板通常就是一系列图片，系统分析师通过这些图片来讲故事。在一般情况下，图片的顺序与活动事件的顺序一致，通过一系列图片说明会发生什么。

2.情节串联板的类型
情节串联板的类型包括被动式、主动式和交互式，其复杂程度依次递增。

（1）被动式情节串联板通常由草图、图片、屏幕截图、幻灯片等组成。系统分析师充当系统的角色，让用户预演情节串联板，简单地表述为“当这样做时，会出现这样的情景”。
（2） 主动式情节串联板试图使用用户能够看到类似“电影样片”，它可以自动播放，描述系统在典型用法或典型场景中的行为方式。
（3）交互式情节串联板让用户体验系统的行为，系统需要用户的参与才能继续运行。交互式情节串联板可以是仿真器、实物模型，甚至是抛弃式原型。

3.情节串联板的制作
制作情节串联板的工具大致可以分为两大类，分别是静态工具和动态工具。静态工具主要有纸和铅笔、白板、即时贴和PowerPoint等，动态工具主要有Flash、Macromedia Director和其他动画工具。

4.情节串联板的优缺点
由于情节串联板给用户一个直观的演示，因此它是最生动的需求获取技术，其优点是用户友好、交互性强，对用户界面提供了早期的评审。情节串联板的缺点是花费的时间很多，使需求获取的速度大大降低。

联合需求计划

联合需求计划（Joint Requirement Planning，JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分。

1.联合应用开发
JAD的过程大致如下：

（1）确定JAD项目，主要指确定系统的范围和规范。
（2）在JAD专题预备会上，会议主持人向参与者介绍项目和JAD专题讨论内容。
（3）准备JAD专题讨论材料。
（4）进行JAD专题讨论会，其目的是要达成对需求的一致意见，并对各种可选的技术方案加以讨论，从中研究出几套可供选择的方案。

2.JRP会议
JRP是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。

在会议开始之后，按照以下步骤进行：

首先，应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。会议的最初，针对所列举的问题进行逐项专题讨论。
然后，对现有系统和类似系统的不足进行开放性交流。鼓励与会者在短时间内说出尽量多的想法，在这一过程中不对这些想法发表任何评论。
第三步，大家在此基础上对新的解决方案进行一番设想，在这个过程中，需要把这些想法、问题、不足记录下来，形成一个要点清单。
第四步，针对这个要点清单进行整理，明确优先级，并进行评审。

3.主要原则
JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则：

（1）在JRP实施之前，应制订详细的议程，并严格遵照议程进行。
（2）按照既定的时间安排进行。
（3）尽量完整地记录会议期间的内容。
（4）在讨论期间尽量避免使用专业术语。
（5）充分运用解决冲突的技能。
（6）会议期间应设置充分的间歇时间。
（7）鼓励团队取得一致意见。
（8）保证参加JRP的所有人员能够遵守事先约定的规则。

需求记录技术

1.任务卡片
任务卡片是一种比较简单的工具，它特别适合对业务活动级的信息收集与整理。

2.场景说明
场景说明就是用户对其工作场景和过程的详细描述，这些描述将在编写测试用例和用户培训手册中再次用到。

3.用户故事
用户故事描述了对用户有价值的功能，可包括三个方面内容，分别是书面描述（用于计划和备忘）、交谈（细化故事）和测试用例（验证故事实现）。

用户故事具有六个基本属性，分别是独立性、可协商性、对用户有价值、可预测性、短小精悍和可测试性。

4.Volere白卡
Volere白卡是一种类似于任务卡片的需求记录工具。用户故事和Volere白卡定位的是最小的需求项，因此在实际应用中会导致量比较大，一般在敏捷方法中使用。

需求分析

需求分析的任务

需求分析就是提炼、分析和仔细审查已经获取到的需求，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。需求分析的关键在于对问题域的研究与理解。需求分析的工作通常包括以下七个方面：

（1）绘制系统上下文范围关系图：这种关系图是用于定义系统与系统外部实体间的界限和接口的简单模型，它可以为需求确定一个范围。
（2）创建用户界面原型：用户界面对于一个系统来说是十分重要的，因此在需求分析阶段通过快速开发工具开发一个抛弃式原型，或者通过PowerPoint、Flash等演示工具制作一个演示原型，甚至是用纸和笔画出一些关键的界面接口示意图，将帮助用户更好地理解所要解决的问题，更好地理解系统。
（3）分析需求的可行性：对所有获得的需求进行成本、性能和技术实现方面的可行性研究，以及这些需求项是否与其他的需求项有冲突，是否有对外的依赖关系等。
（4）确定需求的优先级：这是一项很重要的工作，迭代开发已经成为了现代软件工程方法的一个基础，而需求的优先级是制订迭代计划的一个最重要的依据。对于需求优先级的描述，可以采用满意度和不满意度指标进行说明。其中满意度表示当需求被实现时用户的满意程度，不满意度表示当需求未被实现时用户的不满意程度。
（5）为需求建立模型：也就是建立分析模型，这些模型的表现形式主要是图表加上少量的文字描述，所谓“一图抵千字”，图形化地描述需求将使得其更加清晰、易懂。需求分析模型可以帮助系统分析师理解系统，使需求分析任务更加容易实现。同时，它也是以后进行软件设计的基础，为软件设计提供了系统的表示视图。
（6）创建数据字典：数据字典是对系统用到的所有数据项和结构进行定义，以确保开发人员使用了统一的数据定义。
（7）使用QFD：这是在需求优先级基础上的一个升华，其原理与满意度和不满意度指标十分接近，通过将产品特性、属性与对用户的重要性联系起来。

需求分析的方法

1.面向问题域的分析（Problem Domain Oriented Analysis，PDOA）
PDOA更多地强调描述，而少强调建模。它的描述大致分为以下两个部分：

（1）关注问题域。用一个文档对含有的问题域进行相关的描述，并列出需要在该域中求解的问题列表，也就是需求列表。只有这个文档是在分析时产生的。
（2）关注解系统（即系统实现）的待求行为。用一个文档对解系统的待求行为进行描述。该文档将在需求定义阶段完成。

在PDOA方法中，对整个过程有着一个清晰的定义：

（1）收集基本的信息并开发问题框架，以建立问题域的类型。
（2）在问题框架类型的指导下，进一步收集详细信息，并给出一个问题域相关特性的描述。
（3）基于以上两点，收集并用文档说明新系统的需求。

结构化分析方法

数据流图

DFD是SA方法中的重要工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。

1.DFD的主要作用
DFD的主要作用如下：

（1）DFD是理解和表达用户需求的工具，是需求分析的手段。由于DFD简明易懂，不需要任何计算机专业知识就可以理解它，因此，系统分析师可以通过DFD与用户进行交流。
（2）DFD概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
（3）DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。

2.DFD的基本符号
在DFD中，通常会出现4种基本符号，分别是数据流、加工、数据存储和外部实体（数据源及数据终点）。

数据流是具有名字和流向的数据，在DFD中用标有名字的箭头表示。加工是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。

3.DFD的层次

（1）顶层图。顶层图是描述系统最高层结构的DFD，它的特点是将整个待开发的系统表示为一个加工，将所有的外部实体和进出系统的数据流都画在一张图中。顶层图用来描述系统有什么输入和输出数据流，与哪些外部实体直接相关，可以把整个系统的范围勾画出来。
（2）逐层分解。当完成了顶层图的建模之后，就可以在此基础上进行进一步的分解。

4.如何画DFD
DFD的绘制是一个自顶向下、由外到里的过程，通常按照以下几个步骤进行：

（1）画系统的输入和输出：在图的边缘标出系统的输入数据流和输出数据流。这一步其实是决定研究的内容和系统的范围。在画的时候，可以先将尽可能多的数据流画出来，然后再删除多余的，增加遗漏的。
（2）画DFD的内部：将系统的输入、输出用一系列的处理连接起来，可以从输入数据流画向输出数据流，也可以从中间画出去。
（3）为每一个数据流命名：命名的好坏与DFD的可理解性密切相关，应避免使用空洞的名字。
（4）为加工命名：使用动宾短语为每个加工命名。

每画好一张DFD，就需要进行检查和修改，检查和修改的原则如下：

（1）DFD中的所有图形符号只限于前述4种基本图形元素，图上每个元素都必须有名字。
（2）每个加工至少有一个输入数据流和一个输出数据流，而且要保持数据守恒。也就是，一个加工的所有输出数据流中的数据必须能从该加工的输入流中直接获得，或者通过该加工能产生的数据。一个加工的输出数据流不应与输入数据流同名，即使它们的组成完全相同。
（3）在DFD中，需按层给加工编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。
（4）规定任何一个DFD子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。也就是说，父图中的某加工的输入输出流必须与它的所有子图的输入输出数据流在数量上和名字上相同。值得注意的是，如果父图中的一个输入（输出）数据流对应于子图中的几个输入（输出）数据流，而子图中组成这些数据流的数据项的全体正好是父图中的这一个数据流，那么它们仍然算是平衡的。
（5）在整套DFD中，每个数据存储必须既有读的数据流，又有写的数据流。但是在某张子图中可能只有读没有写，或者只有写没有读。
（6）可以在DFD中加入物质流，帮助用户理解DFD，但不可夹带控制流。

状态转换图

STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为。此外，STD还指出了作为特定事件的结果将执行哪些动作（例如，处理数据等）。

在STD中，用圆形框或椭圆框表示状态，通常在框内标上状态名。

在STD中，从一个状态到另一个状态的转换用箭头线表示，箭头表明转换方向，箭头线上标上事件名。必要时可在事件名后面加一个方括号，括号内写上状态转换的条件。

在STD中，初始状态用实心圆表示，最终状态用一对同心圆（内圆为实心圆）表示。

数据字典

数据字典是在DFD的基础上，对DFD中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。

1.数据字典的条目
数据字典中一般有六类条目，分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体。不同类型的条目有不同的属性需要描述。

2.数据字典的作用
具体来讲，数据字典具有以下作用：

（1）按各种要求列表。可以根据数据字典，把所有数据条目按一定的顺序全部列出，保证系统设计时不会遗漏。如果系统分析师要对某个数据存储的结构进行深入分析，需要了解有关的细节，了解数据结构的组成乃至每个数据元素的属性，数据字典也可提供相应的内容。
（2）相互参照，便于系统修改。根据初步的DFD，建立相应的数据字典。在需求分析过程中，系统分析师常会发现原来的DFD及各种数据定义中有错误或遗漏，需要修改或补充。有了数据字典，这种修改就变得容易多了。
（3）由描述内容检索名称。在一个稍微复杂的系统中，系统分析师可能没有把握断定某个数据元素在数据字典中是否已经定义，或者记不清楚其确切名字时，可以由内容查找其名称。
（4）一致性检验和完整性检验。根据各类条目的规定格式，可以发现一些问题，例如，是否存在没有指明来源或去向的数据流，是否存在没有指明数据存储或所属数据流的数据元素，加工逻辑与输入的数据元素是否匹配，是否存在没有输入或输出的数据存储等。

3.数据字典的管理
为了保证数据的一致性，数据字典必须由专人（数据管理员）管理。数据管理员的职责就是维护和管理数据字典，保证数据字典内容的完整性和一致性。

面向对象分析方法

统一建模语言

1.UML的结构
从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。

（1）构造块。UML有三种基本的构造块，分别是事物（thing）、关系（relationship）和图（diagram）。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。
（2）公共机制。公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制四种。规格说明是事物语义的细节描述，它是模型真正的核心；UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类，分别是类与对象（类表示概念，而对象表示具体的实体）、接口与实现（接口用来定义契约，而实现就是具体的内容）；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。
（3）规则。规则是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，就是指以下5个系统视图：

（1）逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
（2）进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
（3）实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
（4）部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
（5）用例视图。用例视图是最基本的需求分析模型。

2.事物
UML中的事物也称为建模元素，包括结构事物（structural things）、行为事物（behavioral things，动作事物）、分组事物（grouping things）和注释事物（annotational things，注解事物）。这些事物是UML模型中最基本的OO构造块。

3.关系
UML 用关系把事物结合在一起，主要有下列四种关系：

（1）依赖（dependency）。依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
（2）关联（association）。关联描述一组对象之间连接的结构关系。
（3）泛化（generalization）。泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
（4）实现（realization）。实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

4.图
UML 2.0包括14种图，分别列举如下：

（1）类图（class diagram）。类图描述一组类、接口、协作和它们之间的关系。在OO系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
（2）对象图（object diagram）。对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
（3）构件图（component diagram）。构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。
（4）组合结构图（composite structure diagram）。组合结构图描述结构化类（例如，构件或类）的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容。
（5）用例图（use case diagram）。用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
（6）顺序图（sequence diagram，序列图）。顺序图是一种交互图（interactiondiagram），交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
（7）通信图（communication diagram）。通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。在UML 1.X版本中，通信图称为协作图（collaboration diagram）。
（8）定时图（timing diagram，计时图）。定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。
（9）状态图（state diagram）。状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
（10）活动图（activity diagram）。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。
（11）部署图（deployment diagram）。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
（12）制品图（artifact diagram）。制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
（13）包图（package diagram）。包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
（14）交互概览图（interaction overview diagram）。交互概览图是活动图和顺序图的混合物。

用例模型

1.用例图的元素
用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。

（1）参与者。参与者是指存在于系统外部并与系统进行交互的任何事物，既可以是使用系统的用户，也可以是其他外部系统和设备等外部实体。
（2）用例。用例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。也就是说，用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
（3）通信关联。通信关联表示的是参与者和用例之间的关系，或用例与用例之间的关系。箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者，箭尾所指方是对话的主动发起者。如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。

2.识别参与者
参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。

（1）其他系统：当系统需要与其他系统交互时，其他系统就是一个参与者。
（2）硬件设备：如果系统需要与硬件设备交互，硬件设备就是一个参与者。
（3）时钟：当系统需要定时触发时，时钟就是一个参与者。

3.合并需求获得用例
在确定用例的过程中，需要注意以下问题：

（1）用例命名。用例的命名应该注意采用“动词（短语）+名词（短语）”的形式，例如，“开通课程”和“课程测试”等。而且，最好能够对用例进行编号，这也是实现需求跟踪管理的重要技巧，通过编号可以将用户的需求落实到特定的用例中去。
（2）不能混淆用例和用例所包含的步骤。例如，“开通课程”功能要经过验证学员信息、检查学员权限、保存开通记录、修改课程选修人数等步骤才能完成，在系统中这些步骤不能作为单独的功能对外提供，它们只是一个用例所包含的事件流，或是是用例的子功能。
（3）注意区分业务用例和系统用例。当针对整个业务领域建模时，需要使用业务用例，其中会涉及大量的人工活动。

4.细化用例描述
用例建模的主要工作是书写用例规约（use case specification），而不是画图。

用例描述通常包括以下几个部分：

（1）用例名称。用例名称应该与用例图相符，并写上其相应的编号。
（2）简要说明。对用例为参与者所传递的价值结果进行描述，应注意语言简要，使用用户能够阅读的自然语言。
（3）事件流。事件流是指当参与者和系统试图达到一个目标时所发生的一系列活动，也就是用例所完成的工作步骤。
（4）非功能需求。因为用例所涉及的非功能需求通常很难在事件流中进行表达，因此单列为一小节进行描述。在非功能需求的描述方面，一定要注意使其可度量和可验证。否则，就容易流于形式，形同摆设。
（5）前置条件和后置条件。前置条件是执行用例之前必须存在的系统状态，如果前置条件不满足，则用例无法启动；后置条件是用例执行完毕系统可能处于的一组状态。
（6）扩展点。如果包括扩展（或包含）用例，则写出扩展（或包含）用例名，并说明在什么情况下使用。
（7）优先级。说明用户对该用例的期望值，为以后的开发工作确定先后顺序。可以采用满意度/不满意度指标进行说明

5.调整用例模型
例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。

（1）包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。
（2）扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。
（3）泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。

分析模型

建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等，其中有学者将前三个步骤统称为CRC（Class-Responsibity-Collaborator，类-责任-协作者）建模。

1.定义概念类
发现类的方法有很多种，其中广泛最应用的是名词短语法。它的主要规则是先识别有关问题域文本描述中的名词或名词短语，然后将它们作为候选的概念类或属性，其具体步骤如下：

（1）阅读和理解需求文档或用例描述。
（2）筛选出名词或名词短语，建立初始类清单（候选类）。
（3）将候选类分成三类，分别是显而易见的类、明显无意义的类和不确定类别的类。
（4）舍弃明显无意义的类。
（5）小组讨论不确定类别的类，直到将它们都合并或调整到其他两个类别，并进行相应的操作。

2.确定类之间的关系
当完成了类的寻找工作之后，就需要理清这些类之间的关系，类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等。

（1）关联关系。关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系，而不表示两个类之间的关系。
（2）依赖关系。两个类A和B，如果B的变化可能会引起A的变化，则称类A依赖于类B。
（3）泛化关系。泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化。
（4）共享聚集。共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。
（5）组合聚集。组合聚集关系通常简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。
（6）实现关系。实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。

3.为类添加职责
类的职责包括两个方面的内容，一个是类所维护的知识，即成员变量或属性；另一个是类能够执行的行为，即成员方法或责任。

4.建立交互图

5.分析模型的详细程度问题

需求定义

需求定义的方法

需求定义的过程也就是形成需求规格说明书的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

1.严格定义方法
严格定义也称为预先定义，需求的严格定义建立在以下的基本假设之上：

（1）所有需求都能够被预先定义。假设意味着，在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。这对某些规模较小、功能简单的系统是可能的，但对那些功能庞大、复杂且较大的系统显然是困难的。因此，再好的预先定义技术也会经常反复。
（2）开发人员与用户之间能够准确而清晰地交流。
（3）采用图形（或文字）可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流与通信的主要工具是定义报告，包括叙述文字、图形、逻辑规则和数据字典等技术工具。

2.原型方法
采用原型方法时需要注意以下几个问题：

（1）并非所有的需求都能在系统开发前被准确地说明。一个系统的开发过程，无论对于开发人员还是用户来说，都是一个学习和实践的过程，为了帮助他们在这个过程中提出更完善的需求，最好的方法就是提供现实世界的实例——原型，对原型进行研究和实践，并进行评价。
（2）项目干系人之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。用户和开发人员通过屏幕和键盘进行对话、讨论和交流，从他们自身的理解出发来测试原型。原型系统由于直观性和动态性，而使得项目干系人之间的交流上的困难得到较好的克服。
（3）需要实际的、可供用户参与的系统模型。虽然图形和文字描述是一种较好的通信交流工具，但是，其最大缺陷是缺乏直观的和感性的特征，因此不易理解对象的全部含义。交互式的系统原型能够提供生动的需求规格说明，用户见到的是一个“活”的和实际运行着的系统。实际使用在计算机上运行的系统，显然比理解纸面上的系统要深刻得多。
（4）有合适的系统开发环境。随着计算机硬件、软件技术和软件工具的迅速发展，软件的设计与实现工作越来越方便，对系统进行局部性修改甚至重新开发的代价大大降低。因此，对大系统的原型化已经成为可能。
（5）反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。系统分析师应该鼓励用户改进他们的系统，只有做必要的改变后，才能使用户和系统间获得更加良好的匹配。所以，从某种意义上说，严格定义需求的方法实际上抑制了用户在需求定义以后再改进的要求，这对提高最终系统的质量是有害的。另一方面，原型方法的使用并不排除严格定义方法的运用，当通过原型在演示中得到明确的需求定义后，应采用行之有效的严格方法来完成最终系统的开发。

软件需求规格说明书

软件需求规格说明书（Software Requirement Specification，SRS）是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。

1.SRS的编写方法
通常有三种方法编写SRS，分别列举如下：

（1）用好的结构化和自然语言编写文本型文档。
（2）建立图形化模型，这些模型可以描述转换过程、系统状态及其变化、数据关系、逻辑流、对象类及其关系。
（3）编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。

不管采用什么方法编写SRS，都应注意其正确性、完整性、一致性、必要性、可行性、确定性、可修改性和可追踪性。

需求验证

需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。

需求评审

1.技术评审的类型
根据IEEE的词汇表，技术评审可以分为以下三种类型：

（1）评审。评审是指一次正式的会议，在会议上向用户或其他项目干系人介绍一个或一组工作产品，以征求对方的的意见和批准。
（2）检查。检查是一种正式的评估方法，将由非制作者本人的个人或小组详细检查工作产品，以验证是否有错误、是否违反开发标准、是否存在其他问题。
（3）走查。走查是一个评审过程，由某个开发人员领导一个或多个开发团队成员对他（或她）的工作产品进行检查，由其他成员针对技术、风格、可能的错误、是否违反开发标准和其他问题提出意见。

2.正式评审的过程
正式评审是一种结构化的评审技术，一般通过会议的形式来进行评审，需要经过以下过程：

（1）计划。首先要对评审制订计划，以确定评审的重点和范围，并确保所有参与者理解自己的角色和评审的目标。在评审之前，要确定评审的对象及原因、评审小组成员、议程和进行评审所需的信息。评审小组成员应该在要评审的领域拥有丰富的经验，具有相当的背景来理解所介绍的材料，缺乏经验的评审人员对评审的帮助很小，同时他们的参与还可能会分散评审力量。同时，选择评审人员的另一个标准就是评审对象的质量与之有利害关系。
（2）准备。评审之前，应该收集要评审的工作产品和所有背景材料，并分发给评审参与者。预先分发足够的评审材料，让评审人员有时间准备评审，可以显着提高评审的质量。评审人员应该在评审之前研究材料、构思和确定要讨论的问题。
（3）进行评审。要进行成功的评审，首先，评审小组人员应理解评审流程，理解自己的角色。一般来说，评审流程是一个重复进行的循环过程，包括评审员提出问题，讨论问题，同时对问题进行确认，确定缺陷（确定需要解决的地方），直到没有确定的问题时再继续下一步；其次，会议主持人（协调员）要确保评审按议程进行，并以当前的主题为重点。主持人应该确保对枝节问题的讨论不会使评审脱离正轨，而且所有评审人员都以平等的身份参加讨论；最后，在评审的过程中，要注意确定问题而不要试图解决问题，要对所有问题和讨论做好记录。
（4）对评审结果采取行动。如果不对评审结果采取行动，那么评审就没有什么价值。因此，评审结束时，要确定问题列表的优先顺序，并跟踪问题及其解决办法。

3.如何做好需求评审
在如何做好需求评审工作方面，业内人士总结了一些经验，简单列举如下：

（1）分层次评审。用户的需求是分层次的，对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。
（2）正式评审与非正式评审相结合。正式评审与非正式评审各有利弊，但往往非正式评审比正式评审的效率更高，更容易发现问题。因此，在评审时，应该更灵活地利用这两种方式。
（3）分阶段评审。应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。
（4）精心挑选评审人员。需求评审可能涉及的人员包括建设单位的中高层管理人员和操作人员、IT主管和采购主管，承建单位的市场人员、系统分析师、系统架构设计师、软件工程师、测试人员、质量保证人员、实施人员和项目经理，以及第三方的领域专家等。
（5）对评审人员进行培训。在很多情况下，评审人员是领域专家而不是进行评审活动的专家，他们没有掌握评审的方法、技巧和过程等。因此，需要对他们进行培训，以便于评审人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率。
（6）充分利用需求评审检查单。需求评审检查单可以帮助评审人员系统而全面地发现需求中的问题。需求评审检查单可以分为两类，分别是需求形式的检查单和需求内容的检查单。需求形式的检查可以由质量保证人员负责，主要检查SRS的格式是否符合质量标准；需求内容的检查是由评审人员负责的，主要检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等，这是需求评审的重点。
（7）建立标准的评审流程。需求评审需要建立正规的流程，按照流程中定义的活动进行规范的评审过程。例如，在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤和评审通过的条件等。
（8）做好评审后的跟踪工作。在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分、客观的理由和证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。
（9）充分准备评审。评审质量的好坏很大程度上取决于在评审会议前的准备活动。通常出现的问题是，SRS在评审会议前并没有提前下发给评审人员，没有留出更多、更充分的时间让评审人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量、低级的错误，或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。

需求测试

软件测试应该从需求定义开始，如果在开发过程的早期就开始制订测试计划和进行测试用例的设计，就可以在发生错误时立即检测到并纠正它。这样，就可以防止这些错误进一步“放大”，并且可以减少测试和维护费用。

1.概念测试用例
概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。

概念测试用例的设计应该覆盖用例的主事件流和备选事件流（OO方法），或者系统的功能描述（SA方法），以及在需求获取和分析期间所确定的约束条件。

2.需求测试的过程
基于概念测试用例进行需求测试的基本过程如下：

（1）需求测试人员根据概念测试用例所描述的若干可能的过程，进行“概念上”的执行，期望发现遗漏的、错误的和不必要的需求。
（2）根据测试结果快速修改对应的需求文档，完成一轮完整的需求测试过程。

在整个需求开发的过程中，需求获取、需求分析、需求定义、需求验证四个阶段不是瀑布式的发展，而是应该采用迭代式的演化过程。

需求管理

在CMM中，需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

需求变更管理

1.需求基线
需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。

基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。

在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。

开发团队可以根据已知的需求基线来区分“旧需求”和“新需求”。一旦建立了需求基线，就很容易对新需求进行识别和管理，可以把新需求和已有的基线加以比较，确定适合它的位置以及它是否会与其他需求产生冲突。如果接受新需求，就可以管理它的变更过程。

2.需求的状态
在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。

3.需求变更
需求变更通常意味着新需求的增加和对已有需求的修改，一般不会减少需求，而且减少需求的问题也比较容易处理。需求变更是需要代价的，包括时间、人力、资源等方面。

需求风险管理

1.带有风险的做法
系统分析师在进行需求开发的过程中，有时也会“陷自身于困境”，无意之中给项目带来风险。这些做法列举如下：

（1）无足够用户参与。在需求获取的过程中，如果没有足够的用户参与，系统分析师所获得的需求就是片面的和不完整的，这样，在需求开发之初就埋下了风险。
（2）忽略了用户分类。用户不止一个人，各类用户有自己的特点和需求，如果系统分析师不能针对所有主要用户进行分类，就必然会导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但命令和快捷键又会使不熟练的用户感到困难。
（3）用户需求的不断增加。需求蔓延有可能引起项目范围蔓延，而这是项目中的大忌，因为它会对项目成本、进度和质量等方面带来很大的负面影响，甚至直接导致项目失败。
（4）模棱两可的需求。模棱两可的需求会使不同的项目干系人产生不同的期望，会使开发人员为错误问题而浪费大量时间。
（5）不必要的特性。这是技术人员的一个通病，喜欢画蛇添足。经常发生的情况是，用户并不认为这些添加的“足”很有用，以致在其上耗费的努力白搭，浪费项目资源。
（6）过于精简的SRS。过于精简的SRS为用户和开发人员提供了“无限遐想”的机会，却给项目开发带来了无限的麻烦，导致不断的修改，项目完工遥遥无期。
（7）不准确的估算。系统分析师在信息不充分的情况下，如果未经深思就对需求做出估算，则这种估算通常只是一种猜测而已。一旦传递给用户，他们却认为这是一种承诺。

2.与需求有关的风险
项目风险管理的一个主要过程是识别风险，也就是事先要“预知”项目进展过程中可能会发生的风险，然后对其进行分析，制订相应措施。

需求跟踪

1.需求跟踪的内容
SRS中的每个软件配置项的需求到其涉及的系统（或子系统）需求都要具有双向可追踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。

2.需求跟踪的目的
在项目实践中，使用需求跟踪能力，可以获得如下好处：

（1）审核。跟踪能力信息可以帮助开发人员审核和确保所有需求都被正确应用。
（2）变更影响分析。在增、删、改需求时，跟踪能力信息可以确保不忽略每个受到影响的系统元素。
（3）维护。可靠的跟踪能力信息使得维护时能够正确而完整地实施变更，从而提高生产率。
（4）项目跟踪。认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。
（5）再工程。可以列出遗留系统中将要替换的功能，记录它们在新系统中的需求和在软件构件中的位置。
（6）重复利用。跟踪能力信息可以帮助开发人员在新系统中对相同的功能利用现有系统的相关资源。例如，功能设计、相关需求、代码和测试等。
（7）减小风险。需求联系文档化可减少由于项目团队关键成员离职带来的风险。
（8）测试。测试模块、需求和代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。