面向服装销售软件需求分析

面向服装销售软件需求分析
在软件工程中，需求分析指的是在创建一个新的或改变一个现存的系统时，确定新系统的目的、范围、定义和功能时所要做的工作。以服装行业管理软件为例，其服装销售管理软件需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要才能够分析和寻求新系统的解决方法。
前面讨论过基于数据流图的结构化需求分析方法，该方法的核心在于利用数据流图描述待开发系统的边界和数据的处理过程。然而．由于结构化分析方法将同一事物的数据和服务剥离开来，并且需求和设计阶段所采用的表示机制不统一。导致从需求向设计过渡往往需要进行转换、扭曲，因此，很难保持事物的原来面貌。
针对上述问题，本章将介绍一种区别于结构化轳件需求分析方法一一面向对象需求分析方法。顾名思义，面向对象需求分析方法就是运用面向对象方法进行需求分析。面向对象方法根本上来说是一种方法论．而不仅仅是一种编程技巧。它是一套可用于软件生命周期全过程的软件工程方法，面向对象需求分析是这套方法的第一个重要环节。
本章将针对面向对象需求分析阶段所涉及的概念、原则、表示法、过程、策略和文档规范进行介绍。

1．1面向对象需求分析概述
软件开发的本质是为了解决人们在日常生活中所遇到的各类问题。这些事物所涉及的业务范围称为软件的问题域。面向对象需求分析的核心是运用面向对象方法，对问题域进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，识别出问题域中的类和对象，定义这些类和对象的属性与服务，分析它们之间的相互关系，并建立相应的模型，即按照某种规范形成需求规约。
本节将从需求的分类、规格说明特点以及面向对象需求分析的主要过程三个方面概述面向服装销售软件需求分析。

1．1．1需求分类
用户需求可以分为不同的类别，不同的类别有不同的特性和不同的处理要求。根据不同的分类标准，可以将需求分成不同的种类。在各种需求的分类中，最常见的是按照IEEEl990的规定将需求分成5种类别。
1)功能需求(FunctionalRequirement)
和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
功能需求可以分为业务需求(BusinessRequirement)、用户需求(UserRequirement)和系统需求(SystemRequirement)。其中抽象层次最高的需求称为业务需求，是建立软件系统的战略出发点，表现为高层次的目标(Objective)，它描述了组织为什么要开发系统。业务需求通常来自项目的投资人、购买产品的顾客、实际用户的管理者、市场营销部门或产品策划部门。
用户需求就是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。用户需求主要来自系统的使用者——用户。用户需求表达了用户对系统的期望，但是要透彻和全面地了解用户的真正意图，需要了解用户对系统的期望，具有关于待开发软件的领域知识。而在实际工作中，用户表达自己的期望时，通常不会提及需求所涉及领域知识，所以需求工程师需要根据用户的需求整理完整的问题域知识。另外，在有些情况下，系统的直接用户是不可知的，所以用户需求也可能来自间接的渠道。
用户需求是从用户的角度进行描述的，主要使用的是自然语言，因此它具有以下几个计算机系统所无法接受的特性。
(1)模糊性。用自然语言作为描述用户需求工具的一个重要问题是自然语言的模糊性。计算机系统是形式化的系统，它无法表达模糊的概念，所以带有模糊特性的用户需求无法很好地被映射为系统行为。
(2)多特性混杂。在用户进行需求陈述时，往往将功能需求和非功能需求混杂在一起，而功能性需求和非功能性需求对软件工程师而言，反映待开发系统的不同侧面，对应着不同的处理模式。将功能需求和非功能需求混杂在一起会使得对系统行为的映射过程发生困难，并最终导致了低质量的需求分析。
(3)多逻辑混杂。用户需求是对用户任务的描述，而任务本身往往含有前后相继的多个逻辑处理过程。但计算机系统理想中的需求是单一逻辑的，也就是说每个需求都能唯一映射到一个系统行为，而不是多个系统行为，否则将为系统行为的限定带来困难。
2)性能需求(PerformanceRequirement)
描述系统整体或组成部分应该拥有的性能特征，如CPU使用率、内存使用率等。
3)质量属性(QualityAttribute)
描述软件系统完成的质量，如可靠性程度、可维护性程度等。
4)对外接口(ExternalInterface)
描述软件系统与运行环境中其他系统之间需要建立的交互接口，包括硬件接口、软件接口和数据库接口等。
5)约束(Constraint)
描述进行软件系统构造时需要遵守的约束，如编程语言、财务预算和人力资源等。
其中，除功能需求之外的其他4种需求可被统称为非功能需求(Non—FunctionalRequire—ment)。在非功能需求中，质量属性对系统成败的影响最大，因此在某些情况下，非功能需求又被用来特指质量属性。

1．1．2需求规约的特点
需求分析对系统的成败影响甚大，所以对需求的描述应该尽可能的好。需求规约(RequirementSpecification)作为记录需求分析结果的文档应当具有如下特征。
1．完整性
优秀的需求规约是完整的，它可以充分地说明用户所期望的系统功能。每一个需求的描述均包含了开发人员设计和实现这项功能需要的所有信息。
2．正确性
对于每一项需求都必须正确地描述所需要的系统功能．要真实地反映用户的意图。需求的正确性只有提出需求的人——用户才能加以判断，所以需求在提交给开发人员之前，必须请用户予以确认。
3．完整性与精确性
需求最大的用途是对待开发软件系统的知识实现共享，它将用户的期望准确地传递给系统的相关开发人员，如设计者、实现者和测试者等。所以需求的描述必须是可理解的。可理解性要求需求描述的信息要充分，要具有完整性。同时，过多的冗余信息会扰乱读者的思路，所以可理解性也要求描述仅包含必要的信息，即精确性。
4．可行性
需求必须能够在软件系统及其运行环境的已知条件和约束下实现。显然，用户对需求的技术可行性是无法判断的，所以需求的可行性是由开发人员进行评审。在评审过程中，开发人员可能需要进行一定的分析和研究，而不是单纯的凭借经验和直觉。对于难以判断的需求，必要的时候要通过开发原型来加以验证。
5．必要性
每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之后，系统仍然能够解决用户的问题，那么它就是非必要需求，应该删除。
6．无歧义
需求规约能够实现共享的前提是参与软件系统开发的各种角色能够形成关于需求规约共同的理解。因此每一项需求都应该只能携带一种语义，即需求无歧义。而需求规约大多采用自然语言进行描述，这显然将会导致规约中含有大量容易导致歧义的因素。因此，在保证需求描述的无歧义时，要格外注意需求描述中的词汇选择，通常在需求开发中要定义一个可以共同理解的词汇表，然后再在其基础上进行需求的描述。
7．可验证
需求应该是可验证的，即通过分析、检查、模拟或者测试等方法能够判断需求是否被满足。如果需求不可验证，就无法判断完成的软件系统是否满足了该需求，开发人员也无法选择一个能够实现该需求的方法。

1．1．3面向对象分析过程
面向对象分析就是抽取和整理用户需求并建立问题域精确模型的过程。该过程按照Coad和Yourdon的观点可以分为5个层次。主题层、类与对象层、结构层、属性层和服务层。上述5个层次对应着在面向对象分析过程中的5项主要活动：识别主题、识别类与对象、识别关系、定义属性和定义服务。这5个层次自顶向下，一层比一层显现出对象模型的更多细节。
上述5项活动实际上完成了三个方面的工作：建立用例模型、识别对象和类和建立行为模型。其中建立用例模型包含了确定参与者、确定用例、确定用例关系和建立用例图及其描述4个步骤。识别对象和类涉及确定候选对象、对象筛选、类归纳、识别类之间关系和识别类属性5个步骤。建立行为模型包含了建立交互图、状态图和活动图。
综上所述，面向对象分析大体上按照下列顺序进行：建立用例模型、识别对象和类和建立行为模型。但是，分析不可能严格地按照预定顺序进行。大型、复杂系统的需求模型需要反复构造多遍才能建成。通常，先构造出模型的子集，然后再逐渐扩充，直到完全、充分地理解了整个问题，才能最终把模型建立起来。
同时，分析也不是一个机械的过程。大多数需求陈述都缺乏必要的信息，所缺少的信息主要从用户和领域专家那里获取，同时也需要从分析员对问题域的背景知识中提取。在分析过程中，系统分析员必须与领域专家及用户反复交流，以便澄清二义性，改正错误的概念，补足缺少的信息。基于面向对象思想建立的系统需求模型，尽管在最终完成之前还是不准确、不完整的，但对做到准确、无歧义的交流仍然是大有益处的。

1．2案例
本节以自动提款机(AutomatedTellerMachine，ATM)系统为例，详细地介绍了使用面向对象技术进行需求分析的相关过程、概念和方法。本案例在新英格兰戈登大学数学与计算机科学系RusselC．Bjork教授所开发的教学案例的基础上做了适当修改和扩展。案例的使用得到RusselC．Bjork教授的授权。
该软件系统模拟自动提款机的服务过程。下面给出了ATM系统的需求说明。
一个ATM系统包含读卡器、客户交互控制台、出钞口、打印机和钥匙开关。其中读卡器能够读取储蓄卡信息，并将该信息传递给银行信息系统进行处理。客户交互控制台包含键盘和显示器。打印机为客户打印收据。管理员通过钥匙开关控制ATM系统服务的运行和停止。
自动取款机服务一次只为一名顾客提供服务。当顾客将储蓄卡插入读卡器，并通过键盘输入与该储蓄卡相对应的密码后。ATM系统将把读卡器获取的储蓄卡信息和通过键盘输入获取的密码发送给银行信息系统，进行身份验证。如果验证失败，将在屏幕上给出错误提示。若验证成功，客户将能够执行一个或多个交易。在执行交易时，该储蓄卡将保留在ATM系统内，直至顾客所有的交易完成。当所有交易完成后，储蓄卡将自动从读卡器中退还给用户。与此同时，打印机将为客户打印相关交易的收据。
通过自动取款机客户能够进行如下交易：
(1)取款交易。用户将储蓄卡插入ATM系统读卡器，进行身份验证。待身份验证成功后用户可从显示器选择“取款”交易。ATM将请求用户从键盘输入取款额，若取款额小于储蓄卡账户余额，则ATM从出钞口吐出现金，并且为用户打印账单。若取款额大于储蓄卡账户余额，则在屏幕显示操作失败。
(2)存款交易。用户将储蓄卡插入ATM系统读卡器，进行身份验证。待身份验证成功后用户可从显示器上选择“存款”交易。ATM将请求用户将纸币放入现金出钞口，并从键盘输入确认信息。若客户放人的纸币经过ATM系统检查没有发现错误，则ATM系统在显示器输出交易成功提示，并为客户打印账单。否则ATM系统从出钞口退回纸币，并在显示器输出交易失败。
(3)转账交易：用户将储蓄卡插入ATM系统读卡器，进行身份验证。待身份验证成功后用户可从显示器选择“转账”交易。ATM将请求用户从键盘输入转账交易转出账号及金额，并从键盘输入确认信息。若转出金额大于储蓄卡账户余额或转出账号不正确，则ATM在屏幕显示操作失败。否则，在显示器上提示交易成功，并且为用户打印账单。
(4)查询交易：用户将储蓄卡插入ATM系统读卡器，进行身份验证。待身份验证成功后用户可从显示器选择“查询”交易。ATM系统将会在显示器上显示储蓄卡对应账户余额的信息。
ATM系统进行服务时还有一些额外的规定。顾客能够通过键盘输入取消信息终止正在进行的交易。在进行身份验证时，如果银行确定客户的密码是无效的，客户将被要求重新输入密码。如果客户三次输入的密码均是错误的，则储蓄卡将被保留在ATM系统中。客户将需要联系的银行，取回储蓄卡。如果任何一个ATM交易失败，ATM将在显示器显示交易失败原因，然后提示客户是否继续进行交易。ATM系统为每一个成功的交易打印账单。该账单包含了交易H期、时间、机器的位置、交易类型、账户和金额等信息。ATM系统将有一个钥匙开关．允许管理员启动和停止向客户提供服务。开机后切换到“ON”位置。当开关被移动到“OFF”位置时，ATM系统将会关闭，所有交易将不能被执行。ATM系统具有内部交易日志存储功能，该功能可以协助解决在交易中由于硬件或其他故障导致的交易失败。交易日志将会从ATM系统被启动的时刻开始记录所有交易，直至ATM系统被关闭。在此期间，ATM系统将会记录每一笔交易的卡号信息、交易类型和交易金额等信息。出于安全的考虑储蓄卡密码信息将不会被存储。

1．3建立用例模型
在进行面向对象需求分析时，首先确定软件系统的最终用户，并请他们叙述系统需要完成哪些事物。需求分析人员用用例模型来记录用户的需求，这些需求便是从系统外部看到的系统功能，同时它描述用户提出的一些可见的需求，以及一些具体的用户目标。在UMI，中，用例模型的基本元素有参与者、用例和关系。

1．3．1确定参与者
参与者(Actor)是指与系统交互的人或事物，可以分为3类，即系统的使用者、外部系统和时间。其图形化的表示是一个类似人的图形符号。
通过关注系统的业务参与者，设计者可将工作重点放在识别用户如何使用系统，而不是如何构造系统上，并且有助于进一步明确系统边界。当系统规模比较庞大时，要弄清系统的需求往往比较困难。通过明确参与者，可以针对参与者确定系统需求，有助于保证系统需求的完整性，还有助于确定日后进行访谈的候选人。建立用例模型的另外一个目的是提供给用户验证需求的正确性。
在确定参与者过程中，可以通过考察下面的四个方面来确定参与者：标识系统范围和边界环境；现有系统的文档和用户手册；项目会议和研讨会的记录；现有的需求文档、工作手册等。
另外，还可以通过提出以下问题明确参与者：谁或者什么为系统提供输入；谁或者什么接收系统输出；是否需要与其他系统连接；是否在预定时间自动触发事件；谁将维护系统信息。确定参与者时，从用户的角度出发，并使用用户的词汇给出参与者的文字定义。应该使用名词或名词词组来命名参与者。
在3类参与者中，系统使用者是最重要的角色。例如，在ATM系统中系统的使用者有持有储蓄卡的顾客、ATM系统的管理员。一个用户可能会有多种作用，在命名时按照作用来命名，可以提高模型的稳定性。例如，张三负责ATM系统的维护，起管理作用。当他取钱时，他是客户，起ATM的客户的作用。第二种角色是外部系统．例如，ATM系统要与银行信息系统相连，用于维护每位客户的账户信息。也就是说ATM系统与银行计算机系统相连进行信息交互，此时，银行信息系统就是外部系统角色。第三种常用的角色是时间。时间作为角色，经过一定的时间触发系统中的某个事件。例如，如果ATM系统在每天夜里运行日志备份功能。

1．3．2确定业务需求用例在控制之内，则将时间也视为角色。
面对一个大系统，要列出所有用例的清单常常十分困难。比较可行的方法是先列出所有角色的清单，再对每个角色列出用例，问题就会变得比较容易。
综上所述，根据ATM系统分析则该系统对应着3个参与者，即客户、管理员和银行计算机系统，如图5—1所示。
从用户的视角看，一个用例是参与者与系统之间的一次典型的交互作用。从系统内部的视角出发，一个用例代表系统执行的一系列动作，动作的执行结果能够被外部的参与者所察觉。
以下问题可以帮助更好的标识系统的用例：
(1)每个参与者的特定任务是什么。
(2)是否每个参与者都要从系统中创建、存储、改变、移动或者读取信息。
(3)是否任何参与者都需要通知系统有关突发性的、外部的改变。
(4)哪些用例支持或维护系统。
(5)目前的用例是否覆盖了所有的功能需求。
例如，在ATM系统中客户可以完成取钱、存钱、转账和查询任务，因此，在系统中必定存在取钱、存钱、转账和查询4个用例，银行信息系统除了与上述4个用例有关外，还需要完成身份验证事务，因此银行信息系统对应着身份验证用例。同样，管理员可以改变ATM系统的状态，因此对应着开启ATM系统和关闭ATM系统两个用例。因此，ATM系统总共对应着7个用例，如图5—2所示。在实际项目开发过程当中，虽然项目开发得非常辛苦，但用户还是不满意，有一个非常重要的原因是对需求没有区分优先级。实践表明，确定每一个需求的优先级是制订项目开发进度和成本、提升用户满意度的一个简单有效的方法。确定用户需求的优先级首先需要对用例的优先级进行确定。该过程根据已经生成的用例，确定哪些用例涉及的功能先开发，哪些用例涉及的功能后开发。而这个开发顺序是以系统功能关于用户需求的重要程度进行排序的。

1．3．3确定用例关系
(1)关联关系：关联关系是用例和参与者之间的关系，描述用例和参与者之间的交互。如果一个参与者与一个用例相关联，那么该参与于者与该用例之间存在一个关联关系。关联关系使用一条连接参与者和用例的实线来表示。如图5-3所示。
(2)包含关系：在多个用例中常常会发生相同的行为，这些行为图5-3用例的关联关系跨越了多个用例。与其重复书写这些共同的部分，不如将这些共同部分抽取出来，形成一个抽象用例，然后原有的用例通过使用新建立的抽象用例来减少用例描述的冗余。原有用例和新建立的抽象用例的关系即为包含关系。需要注意的是，抽象用例是不能被实例化的，它必须被包含在其他用例中才能得以执行。例如，ATM系统无论是进行取钱还是存钱交易都需要进行身份验证，因此就可以从取钱和存钱两个用例中抽取出附加用例身份验证，建立用例模型，如图5—4所示。
(3)扩展关系：在需求分析中，随着对问题域理解的深入，经常需要依据新的需求扩充原有的用例描述，增加新的处理流程和场景。但是在有些情况下，原有用例不能被直接修改，这就需要建立一个针对新需求的附加用例，然后用附加用例扩展原有用例。新的用例会描述对新需求的处理流程，并定义新的处理流程在原有流程中的扩展点和触发条件。在执行新的用例时，新的用例将会首先执行原有用例的流程，只有在到达新流程在原有流程中的扩展点并且条件满足触发条件时，才可能执行薪用例定义的薪流程。例如，若ATM系统由于业务的扩展，可以进行外币存储业务。外币存储用例就扩展了存钱用例。扩展后的用例关系如图5-5所示。
(4)泛化关系：若用例间存在继承关系，则可以用泛化关系进行描述。例如，若ATM系统中具有外币取钱交易，那么在ATM系统中取钱用例与外币取钱用例就形成了继承关系。因此，两个用例之间的关系可以用泛化关系描述，如图5-6所示。

1．3．4建立用例描述
用例描述是用规范的方法给出关于用例图的静态的结构化的文本描述。表5—1中给出了一个用于用例描述的模板。当然，该模板也仅仅是一个参考模板，具体的用例描述方式还需要参考用例的内容。如果用例仅仅需要一段概括性的描述，那么该模板的许多内容就不需要进行描述。这样就需要对模板进行裁剪。如果用例的内容是专门针对某特殊情况，如医院管理流程、股票交易流程等，这样就需要对模板内容进行丰富，以适应特殊的需求。
根据ATM系统用例图可以生成系统用例表，详细情况如表5—2所示。下面以取钱用例为例，给出相关的用例和用例描述如图5-8和表5—3所示。在ATM系统中取钱用例描述了用户取钱的业务过程。首先向读卡器插入储蓄卡，然后从键盘输入与储蓄卡对应的密码，ATM系统将从读卡器得到的储蓄卡信息和用户输人的密码提交给远端的银行信息系统进行身份验证。待验证成功后，提示用户输入希望取钱的金额，之后将取钱金额信息再次提交银行信息系统，银行信息系统对用户取钱金额是否小于账户余额进行验证，若判定成功，则进行取钱交易，ATM机从出钞口吐出现金。否则，提示交易失败。
1．4发现对象和类
在拥有用例图描述信息充分的情况下，发现对象和类成为面向对象需求分析下一阶段主要完成的工作。对象和类是在问题域中客观存在的，系统分析员的主要任务就是通过分析找出这些对象和类。首先找出所有的候选对象和类，然后从候选的对象和类中筛选掉不正确的或不必要的。

1．4．1确定候选对象
本节讨论如何发现各种可能有用的候选对象。主要策略是，从问题域、系统边界和系统责任三个方面，考虑各种能启发发现对象的因素，找出可能有用的候选对象。本章多次提到问题域(ProblemDomain)和系统责任(SystemResponsibilities)，其中问题域是指被开发系统的应用领域，即现实世界中有这个系统处理的业务范围。系统责任是指所开发的系统应该具有的职能。两个概念既有相似的地方也存在区别。例如，在ATM系统中，ATM业务就是这个系统的问题域。ATM系统的日常业务(存款、取款、查询等)及与此有关的人或物既属于问题域也属于系统责任。但ATM系统运行日志属于系统责任但不属于问题域。因为，有没有系统运行日志并不影响日常业务的正常执行。
1．考虑问题域
可以启发分析员发现对象的因素包括人员、组织、物品、设备、事件、表格和结构等。
(1)人员：大多数软件系统的问题域都涉及各种各样的人员，需要考虑的是以下两种情况：一是需要由系统保存和管理其信息的人员，如ATM系统中的每个用户；二是在系统中扮演一定角色(提供某些服务)的人员，如ATM机管理员。符合上述情况之一者，应考虑用相应的人员对象来描述。
(2)组织：在系统中发挥一定作用的组织机构。如行政单位、办事机构、业务部门、社会团体和工作班组等。例如，在ATM系统中银行信息系统就属于组织的范畴。
(3)物品：需要由系统管理的各种物品。如库房的各种物资，生产所用的材料、器件，出厂的产品，经营的商品等。还应注意那些无形的事物，如ATM系统中的显示器、出钞口等容易被忽视，所以要特别注意。
(4)设备：在系统中动态地运行的，由系统进行监控或者供系统使用的各种设备、仪表、机器和运输工具等。这些对象也可以广义地属于物品的范畴，不过这里强调的是它们的动态特征，所以单独列出来讨论。分析中要考虑的是问题域中固有的设备，例如，ATM系统中显示器、键盘等。这是为了使分析模型不受硬件选择的影响。
(5)事件：指那些需要由系统长期记忆的事件。大部分系统每时每刻都会发生许多事件，其中部分事件的信息需要在系统中长期记忆。对于这样的事件，可考虑设立相应的对象记录其信息。例如，在ATM系统中，客户在ATM机上的查询交易一般不需要在系统中记录，因为查询事件并不会修改账户信息，取款交易则是需要记录的。因为取款交易修改了账户信息。在需要由系统记忆的事件中，有些事件的信息比较简单，不一定要设立专门的对象来记录，例如，图书馆管理系统的借书事件，可以在读者对象的属性部分记录该读者借了哪些书，不必设立一个“借书事件”对象。信息比较复杂的事件，例如，ATM系统中的取钱交易等，则需要设立专门的对象来记录其信息更为合理。分析员首先要判断哪些事件是需要长期记忆的，然后根据其信息的复杂程度和与其他对象的相关情况决定是否为它设立一个对象。
(6)表格：这里“表格”的概念是广义的。如各种业务报表、统计表、登记表、申请表、身份证件、户口簿、商品订单、预支款单、报销单、账目和学生的成绩单等。分析员进入问题域，首先容易看到的就是各种各样的表格，也很容易想到设立一些对象来映射这些表格。由于表格在形式上比较规范，因此在系统中设立相应的对象来描述它们是很便当的。但是无节制地设立许多表格对象却并不明智，往往会产生一个臃肿的、畸形的系统。其原因如下：
①尽管表格也是问题域中的一种事物，但大多数情况下并不是那种固有的、原始的事物。它们是由人根据对一些原始事物的理解，经过头脑的加工而产生的二手信息，是对一些现实事物的映射。例如，账户信息表是对账户对象的一种映射。有些表格是某些事物经过多次映射的组合产物。如果过分依靠这些表格来构造系统，反而看不清它们所描述的那些客观事物固有的属性和行为，使面向对象的分析变了味，变成“面向表格”。
②许多表格的信息，是可以从其他表格(或某些对象)导出的。因此，如果针对每一种表格设立一类对象，必然造成大量的信息冗余，并使系统十分臃肿。
正确的策略是：不要急于考虑从表格发现对象，而要把产生各种表格看成一种用户需求。通过考虑问题域的其他事物，发现了许多对象之后，检查这些对象能否满足表格的需求。如果不能满足，则考虑是否遗漏了某些对象，或者一些对象中遗漏了某些属性和服务。最后，再考虑针对某些表格设立相应的对象。
2．考虑系统边界
考虑系统边界，可能启发分析员发现一些与系统边界以外的活动者进行交互，并处理系统对外接口的对象。考虑的因素包括：人员、设备和外系统。
(1)人员：作为系统以外的活动者与系统进行直接交互的各类人员，如系统操作员、直接使用系统的用户等。
(2)设备：作为系统以外的活动者与系统相连并交换信息的设备。
(3)外系统：与系统相连并交换信息的其他系统。
这里讨论的人员和设备，在考虑问题域中也谈到上述内容。分析员可以从不同的角度去观察问题。前面的讨论是把这些人员和设备看作问题域范畴以内的事物，系统中的对象是对它们的抽象描述。现在是从另一个角度去看：当计算机应用系统建立之后，它们是在系统边界之外与系统进行交互的活动者，系统中需要设立相应的对象处理系统与这些实际的人和设备的交互。两种观点都有道理，但产生的结果会有风格上的差异：前一种观点侧重于以系统中的对象模拟现实中的人和设备；后一种观点侧重于以系统中的对象处理现实中的人和设备与系统的交互。哪种效果更好。要看系统的具体情况。
至于外系统的接口，无疑只能从系统边界这个角度去考虑。因为无论何时把外系统解释为问题域中的一个对象都是很不自然的。只能说在系统中设立一个对象处理与外系统的接口，不能说用这个对象去映射外系统。
3．考虑系统责任
通过对问题域和系统边界的考察，发现了许多对象，但不能保证没有疏漏，考虑系统责任可以检查存在的疏漏。策略是：对照系统责任所要求的每一项功能，查看是否可以由现有的对象完成这些功能。如果发现某些功能没有在现有的对象与之对应，则可启发发现问题域中某些遗漏的对象。
ATM系统所对应的对象如图5-9所示。其中通过考察问题域可以得到ATM管理员对象、用户对象、银行信息系统对象、钥匙开关对象、ATM机对象、读卡器对象、出钞口对象、客户交互控制台对象、显示器对象、键盘对象、打印机对象、储蓄卡对象、交易对象、取钱对象、存钱对象、转账对象和查询对象。通过考察系统边界可以得到ATM管理员对象、用户对象、银行信息系统对象和网络连接对象。通过考虑系统责任可以得到日志对象。

1．4．2对象的审查和筛选
1．4．1节介绍了如何获得候选对象的方法。本节将在1．4．1节内容的基础上讨论如何对候选对象进行审查和筛选。审查和筛选的过程大致可以分为审查对象、对象精简和推迟到面向对象设计阶段考虑对象。
1．审查对象
对于每一个候选对象，需求分析工程师均要面对一个核心问题：如何最终确定一个候选对象是否应该作为一个对象存在。判断的标准就是在问题域中考察候选对象的内涵，看其是否同时具有状态和行为两种特征。因为标识特征基本上都是会存在的，所以通常需要考察的就是判断候选对象是否同时具有状态和行为两种特征。
如果候选对象既维持一定的状态，又依据状态表现一定的行为，那么它就应该是一个独立存在的对象。如果候选对象只有状态没有行为，那么就要分析它的状态是否是系统需要的数据。如果系统需要它的状态数据，那么该候选对象就应该作为其他对象的属性出现在最终的模型中。否则，该候选对象应该被摒弃。如果候选对象只有行为没有状态，那么往往意味着需求信息的遗漏，因为行为的表现总是要以状态为基础的。此时就需要重新进行需求的获取。既没有状态也没有行为的候选对象很少会出现，即使出现也很容易被摒弃。
另外，在对候选对象进行审查过程中还要关注两个问题：属性的复杂度问题和单值属性对象问题。
对于属性的复杂度问题，对象的属性往往是以二维关系表的形式表达出来。因此人们就会体对于属性的复杂度问题，对象的属性往往是以二维关系表的形式表达出来，因此人们就会使用“二维”形式来限制对象的属性。例如，在对象出现组合属性或者多值属性时，这些属性就会超出二维的限制，以至于无法被实现为一个对应的关系表，就常常会被独立为单独的对象。其实这种二维的限制本来就不该出现在对象建模中，它应该是数据设计需要考虑的内容，而不是对象分析。在面向对象分析中，这种限制就更不应该存在。例如，在ATM系统中描述“储蓄卡”对象时，需要“账户信息”的信息。假设“账户信息”的信息比较复杂，包括姓名、省份证号、联系方式等很多内容，而且这些信息仅仅是被用来描述储蓄卡。按照“二维”形式的对象建模思想，具有复杂结构的“账户信息”自然应该是独立的对象。但是如果将“账户信息”作为候选对象进行考察，那么依据对象的含义进行判断，“账户信息”具有系统需要的状态数据但是没有独立的行为，它就自然应该被抽象为“储蓄卡”对象的属性，是“储蓄卡”对象的一个复杂属性。
2．对象的精简
如果系统中的对象种类及数量过多，将增加系统的复杂性，应该考虑是否能够精简。下列情况需要重点审查：
(1)只拥有一个服务的对象。如果一个对象只有一个服务，没有属性，并且只有一个其他类的对象请求这个服务，可以合并到它的请求对象中。推而广之，如果一个对象只有多个服务，没有属性，并且每个服务各自只被一个类的对象使用，则可考虑把这些服务分别放到它的使用对象中，从而取消这个对象。例如，ATM系统中有“网络连接”对象，它只有一个“连接”服务，而这个对象是被“交易”对象引用的。此时完全可以将它合并到“交易”对象中，只在“交易”对象中增加一个“连接银行信息系统”服务。
(2)只拥有一个属性的对象。如果一个对象只有一个属性，应该考虑它是被哪些对象引用，看看能否合并到这些对象中。
3．推迟到面向对象设计阶段考虑的对象
候选对象中那些与具体实现密切相关的对象，例如，与图形用户界面、数据库管理系统、操作系统等可以推迟到设计阶段进行考虑。

1．4．3类的归纳
在确定对象之后，进行分类以归纳出类。该工作通常是比较容易的，所要完成的事可以归纳为每一种对象定义一个类，用一个类符号表示，将陆续发现的属性和服务填写到类符号中，就可以得到这些对象的类。
但是在有些情况下，事情未必都那么简单。从认识对象到定义它们的类，是一个从特殊个体升华为一般概念的抽象过程。从单个对象人手考察对象的特征是否正好可作为整个类的特征是一项极其需要经验和智慧的工作。同时，由于在软件系统当中的各个对象之间的关系是极其复杂的，因此，要对如此规模庞大且关系复杂的对象集合进行分类同样是一件极具挑战的工作。
本节罗列了一些方法，这些方法大多是经验的总结。根据它们可以有效地帮助读者从纷繁复杂的对象中归纳出类。
1．分类列表法
Ross、Mellor和Yourdon等先后于1987年、1988年和1990年提出了分类列表方法，这种方法事先给出一个类的分类列表，然后由分析人员针对候选对象寻找符合分类列表的对象实体，最后对候选对象进行确定和归纳，形成类。
2．行为分析法
行为分析法是从需求描述中搜寻动词，识别出系统行为，然后找出系统行为的主动对象和被动对象作为候选对象。在找出候选对象之后，就按照对象的含义进行对象的确定。针对确定后的对象，以其发起行为的组合作为特征描述，并以特征的相似性进行归纳分类，产生类。
3．名词分析法
名词分析法是一种运用语言分析的实用方法。名词分析从需求文本描述中识别出有关的名词和名词短语，将它们作为候选对象。根据类的定义对候选对象进行归纳、筛选，最后形成类。
根据名词分析法从用例描述中获得类的示例如表5-6所示。其中，带下划线的名词是候选类。

1．4．4建立类之间的关联
在得到孤立的类之后，要建立它们之间的关联，把它们联系起来。发现类之间的关联可以从两个方面着手：首先，分析问题域内的静态结构关系，发现概念类之间的整体部分关系和明显的语义联系。其次，分析概念类之间的协作，协作能够体现概念类之间明显以及不明显的语义联系。
建立类之间的关联还是需要从需求陈述人手。在需求陈述中使用的描述性动词或动词词组，通常表示关联关系。因此，在确定关联时，大多数关联可以通过直接提取需求陈述中的动词词组而得出。通过分析需求陈述，还能发现一些在陈述中隐含的关联。最后，分析员还应该与用户及领域专家讨论问题域对象(类)间的相互依赖、相互作用关系，根据领域知识再进一步补充一些关联。
经初步分析得出的关联只能作为候选的关联，还需经过进一步筛选，去掉不正确的或不必要的关联。筛选时主要根据下述标准删除候选的关联：
(1)已删去的类之间的关联：如果在分析确定类与对象的过程中已经删除了某个候选类，则与这个类有关的关联也应该删去，或用其他类重新表达这个关联。
(2)与问题无关的或应在实现阶段考虑的关联：应该把处在本问题域之外的关联或与实现密切相关的关联删去。
(3)瞬时事件：关联应该描述问题域的静态结构，而不是一个瞬时事件。
(4)三元关联：三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。
(5)派生关联：应该去掉那些可以用其他关联定义的冗余关联。
经过筛选后的候选关联，需要进一步完善。通常从下述几个方面进行改进：
(1)正名：好的名字是帮助读者理解的关键因素之一。因此，应该仔细选择含义更明确的名字作为关联名。
(2)分解：为了能够适用于不同的关联，必要时应该分解以前确定的对象和类。
(3)补充：发现了遗漏的关联就应该及时补上。
(4)标明重数：应该初步判定各个关联的类型，并粗略地确定关联的重数。建立类之间的关联时，要注意下列原则：
(1)保证类之间协作所必需的可见性。如果两个对象实例需要实现互相之间的协作．那么至少它们中的一个对象实例要持有另一个对象实例的链接。在保证可见性的情况下协作才能成为可能。因此，如果两个类存在协作关系，那么它们就应该具有能够保证可见性的关联。为保证类之间协作而建立的关联是必要关联，是对象模型必不可少的部分。
(2)适当使用问题域内的关联，增强领域模型的可理解性。有些类之间不需要互相协作，但是它们的对象实例在问题域内存在某些重要而且固定的关系。这些关系是问题域特性的必要部分，因此需要为这些关系建立关联以增强领域模型的可理解性。对问题域内关系的识别要适可而止，因为问题域内的关系是复杂和繁多的，它们建立太多的关联不仅不能有效地表示领域模型，反而会使得领域模型变得混乱。
(3)不要在关联的识别上花费太多的时间。识别概念类比识别关联更加重要。一方面是因为遗漏的概念类比较难以发现，而遗漏的关联则很容易在后续的处理阶段得到建立。另一方面是因为常常有些深层次的关联发现起来非常费时，但带来的好处不大。
(4)避免显示冗余和导出的关联。发现关联后使用合适的动词短语为关联命名，描述每个关联端的角色和多重性。关联名称通常按照自上至下、自左至右的方式表达概念类之间的关系。在分析阶段，一般不会描述关联的方向和关联端的可见性。不过在非常必要的情况下(如存在重要的约束或者某些类有特殊要求)，也可以描述关联的方向和关联端的可见性。
经过对类建立关联后，ATM系统中类间关系如图5—10所示。

1．4．5添加类的属性
属性是对象的性质，借助于属性能对对象和类有更加深入的认识。一般说来确定属性的过程包括分析和选择两个步骤。
1．分析
通常，在需求陈述中用名词词组表示属性，例如，“汽车的颜色”或“光标的位置”。往往用形容词表示可枚举的具体属性，例如，“红色的”、“打开的”。但是，不可能在需求陈述中找到所有属性，分析员还必须借助于领域知识和常识才能分析得出需要的属性。幸运的是，属性对问题域的基本结构影响很小。随着时间的推移，问题域中的类始终保持稳定，属性却可能改变了，相应地，类中方法的复杂程度也将改变。
属性的确定既与问题域有关，也和目标系统的任务有关。应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。在分析过程中应该首先找出最重要的属性，以后再逐渐把其余属性增添进去。在分析阶段不要考虑那些纯粹用于实现的属件。
2．选择
认真考察经初步分析而确定下来的那些属性，从中删除不正确的或不必要的属性。通常有以下几种常见情况。
1)误把对象当作属性
如果某个实体的独立存在比它的值更重要，则应把它作为一个对象而不是对象的属性。在具体应用领域中具有自身性质的实体，必然是对象。同一个实体在不同应用领域中，到底应该作为对象还是属性，需要具体分析才能确定。例如，在邮政目录中，“城市”是一个属性，而在人口普查中却应该把“城市”当作对象。
2)误把关联类的属性当作一般对象的属性
如果某个性质依赖于某个关联的存在，则该性质是关联类的属性，在分析阶段不应该把它作为一般对象的属性。特别是在多对多关联中，关联类属性很明显，即使在以后的开发阶段中，也不能把它归并成相互关联的两个对象中任一个的属性。
3)把限定误当成属性
正确使用限定词往往可以减少关联的重数。如果把某个属性值固定下来以后能减少关联的重数，则应该考虑把这个属性重新表述成一个限定词。
4)误把内部状态当成了属性
如果某个性质是对象的非公开的内部状态，则应该从对象模型中删除这个属性。
5)过于细化
在分析阶段应该忽略那些对大多数操作都没有影响的属性。
6)存在不一致的属性
类应该是简单而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。
ATM系统中各个类的属性如表5—7所示。

1．5建立行为模型
对象的行为可以用三类模型进行建模，即交互图、状态图和活动图。本节将介绍上述三种模型的建模方法。
1．5．1建立交互图
交互图建模一般采用顺序图作为载体。建立交互图的一般步骤如下：
(1)确定交互图的上下文环境。交互图是对用例描述中典型场景的实现，展示了场景中发生的对象交互行为。也就是交互图的交互是在一定的场景环境下发生的，离开这个上下文环境的限定，对交互行为的描述和理解都会出现一定的问题。因此，建立交互图时需要首先确定交互图的上下文环境，限定交互图描述的范围。而且，上下文环境的前置条件和后置条件应该被分配给交互图中的相应行为，这个工作会在为交互行为添加说明的时候得到实现。
(2)找出参与交互的对象。在上下文环境中寻找参与交互的对象。交互图中的参与对象(和对象之间的关联)应该和领域模型中的知识保持一致。
(3)根据发现的对象(和关联)建立交互图框架。如果需要建立的是顺序图，那么将对象平行排列，并添加对象的生命线。
(4)添加消息，描述交互行为。以消息的方式，将对象之间的交互行为描述出来，并建立行为之间的顺序。如果建立的是顺序图，还要注意维护对象生命线的激活状态。描述时仅仅需要考虑和系统相关的(系统内的、系统与外部对象之间的)交互行为，同时忽略那些与系统无关的(外部对象之间的)交互行为。如果建立的是系统顺序图，那么系统内的行为也可以被忽略。
(5)进行消息标识、特化图示等详细信息的描述，将交互图的信息补充完整。
例如，针对启动ATM用例描述，可以按照下述步骤建立系统顺序图：
(1)确定上下文环境，以用例描述中的流程为场景环境。例子中的场景描述相对比较独立。没有对其他用例或场景的引用，因此建立系统顺序图的过程和结果也相对比较简单。
(2)根据用例描述可以找到钥匙开关、ATM机和银行业务系统3个交互对象。
(3)按照用例描述中的流程顺序，逐步添加消息，并在进行详细信息描述后建立系统顺序图，如图5—1l所示。同理，取钱用例的顺序图如图5一12所示。

1．5．2建立状态图
建立状态图的步骤如下：
(1)确定上下文环境。状态图是立足于状态迁移而进行行为描述的。因此建立状态图时首先要搞清楚状态的主体，确定状态的上下文环境。常见的状态主体有：类、用例、多个用例和整个系统。
(2)识别状态。状态主体会表现出一些稳定的状态，它们需要被识别出来，并且标记出其中的初始状态和结束状态集。在有些情况下，可能会不存在确定的初始状态和结束状态。
(3)建立状态转换。根据需求所描述的系统行为，建立各个稳定状态之间可能存在的转换。
(4)补充详细信息，完善状态图。添加转换的触发事件、转换行为和监护条件等详细信息。在有些情况下也可能会需要建立状态图的层次结构或者进行其他更加复杂的工作。
例如，针对ATM系统示例，可以按照下面的步骤建立取钱类的状态图：
(1)明确状态图的主体：取钱类。
(2)识别取钱类可能存在的稳定状态：
①接收取钱请求状态。
②身份验证状态。
③向银行信息系统提交取钱信息状态。
④处理取钱交易状态。
⑤处理身份验证错误状态。
⑥处理取钱成功状态。
⑦询问是否进行其他交易。
其中，接收取钱请求为系统的初始状态。
(3)建立状态转换。可能的状态转换如表5—8所示，其中如果第i行第J列的元素被标记为y，则表示第i行的状态可以转换为第J列的状态。
(4)在已识别状态和转换的基础上，添加详细的信息说明，如图5—13所示，建立状态图。

1．5．3建立活动图
建立活动图的步骤如下。
(1)确定活动图的上下文环境。活动图是对业务流程的描述，因此建立活动图首先需要确定作为描述内容的复杂业务流程。要界定业务流程的处理界限。
(2)识别参与者。在复杂的业务流程中，识别主要的流程参与者。这些参与者将分享业务流程中的各项职责与行为，构成活动图中的不同泳道。在业务流程比较简单时，可以不进行参与者识别的工作。
(3)分析业务流程中的主要处理步骤。复杂的业务流程总是会按照一定的步骤顺序执行，要发现并列举这些主要的处理步骤。分析清楚这些步骤之间的先后衔接顺序。
(4)分析业务流程中的主要数据流。业务流程往往会利用数据的传递作为工作衔接的重要手段，要发现这些具有重要意义的被传递数据，并分析这些数据在业务流程中不同步骤下的状态差异。
(5)进行职责分配，将业务流程的处理步骤划分到不同的泳道，并将处理步骤和数据流的传递组织起来，建立活动图。
(6)添加活动图的详细信息，完善活动图描述。
例如，对关闭ATM系统活动，可以按照下列步骤建立活动图。
(1)以钥匙开关状态置为off开始，以ATM机关闭服务为结束。整个中间阶段的处理均属于交易活动的处理流程。
(2)交易的参与者有：ATM机、银行业务系统和钥匙开关。
(3)整个处理流程可以分为下列几个步骤：钥匙开关状态置为off、关闭ATM系统、关闭与银行信息系统连接和结束ATM服务。
(4)ATM机和银行信息系统主导整个业务流程的进行。
(5)最后，将前面步骤中发现的参与者和过程组织起来，建立活动图如图514所示。

1．5．4识别服务
发现和定义对象的服务和面向对象分析的其他活动一样，应借鉴以往同类系统的面向对象分析结果尽可能加以复用。同时，研究问题域和系统责任以明确各个对象应该设立哪些服务以
及如何定义这些服务。特别要考虑以下几个问题。
1．考虑系统责任
在面向对象分析模型中，对象的服务是最直接地体现系统责任并实现用户需求的成分，因此定义服务的活动比其他面向对象分析活动更强调对系统责任的考察。要逐项审查用户需求中提出的每一项功能要求，看它应该由哪些对象来提供，从而在该对象中设立相应的服务。
换一个角度对每个对象提出问题：设置这个对象的目的是什么?如果是为了完成某些功能，那么，应该由什么服务来完成这些功能?如果是为了保持某些信息，那么．系统怎样运用这信息?是否需要由这个对象的服务进行某种计算或加工，然后向对象外部提供?
2．考虑问题域
对象在问题域中具有哪些行为?其中哪些行为是与系统责任有关的?应该设立何种服务来模拟这些行为?
3．分析对象的状态
状态图是启发分析员认识对象服务的重要工具。找出对象生命历程中所经历的(或者说可能呈现的)每一种状态，画出状态图。与此同时提出下述问题：在每一种状态下对象可以发生什么行为?应该由什么服务来描述?对象从一种状态转换到另一种状态是由什么操作引起的?是否已经设立了相应的服务?
4．追踪服务的执行路线
在上述问题的启发下能够发现的服务都已发现时，模拟每个服务的执行并追踪其执行路线，可以帮助分析员发现遗漏的服务。所谓模拟是指分析员把自己设想为当前对象服务的执行者，做这个服务所做的事。设想现正在做某事，为了完成此事，需要其他对象(或者本对象)提供什么服务?发现了这种需要就追踪到下一个对象中，看看是否定义了所需要的服务。如果没有，则加以补充，并做与上一个对象相同的模拟。以穷举式的搜索一直进行到全部服务都被模拟过。这叫做“执行路线追踪”，在对已发现的服务进行具体的定义和详细说明时进行较为合适。一次对执行路线的跟踪可以同时起到两种作用：既可发现一些服务，又可发现一些消息连接，二者都应及时加入到模型中。
5．服务的命名和定位
服务的命名应采用动词或动同加名词所组成的动宾结构。服务名应尽可能准确地反映该服务的职能。
服务放置在哪个对象，应和问题域中拥有这种行为的实际事物相一致。例如，在ATM系统中，“启动”服务应该放在“ATM”对象而不应放在“管理员”对象，因为按问题域的实际情况和人的常识，它是ATM的行为而不是管理员的行为。
与一般一特殊关系中属性的定位原则一样，通用的服务放在一般类，专用的服务放在特殊类，一个类中的服务应适合这个类及其所有特殊类的每一个对象实例。

1．6需求验证
需求规约作为需求分析阶段的阶段性成果，如果没有经过验证，则最终用户、需求分析师、系统设计师以及投资商均难以确定其分析结果的正确性。因此，验证活动普遍存在于需求开发活动中。
在需求验证过程中主要考察以下两个问题。
(1)在需求分析中建立的分析模型是否正确地反映了问题域特性和需求?细化的系统需求是否充分和正确地支持用户需求?
(2)需求规约文档是否组织良好、书写正确?需求规约文档内容是否充分和正确地反映了最终用户的意图?需求规约文档是否可以作为后续开发工作(设计、实现、测试等)的基础?
本节所述的需求验证是专指在需求规约完成之后，对需求规约文档进行的验证活动。
需求验证并不是一个可以一次结束的活动，它可能需要多次、反复地执行验证。执行验证最重要的方法是需求评审。在每次执行评审时都会发现一些问题，并给出相应的修改建议。这些问题应该在验证后及时地得到修正，修正过程应该落实修改的建议。

1．6．1需求评审
1．需求评审
评审(Review)又被称为同级评审(PeerReview)，是指由作者之外的其他人来检查产品问题的方法。在需求验证中，评审是主要的静态分析手段，所以评审也是需求评审的一种主要方法。原则上，每一个需求都应该经过评审。
2．参与评审的人员
审查过程中的所有参与者，包括作者，他们的任务都是查找缺陷和提出对其进行改进的意见。审查组中的成员在审查期间可能扮演下面的角色：
(1)组织者(Organizer)，负责整个项目当中审查活动的组织和规划。
(2)仲裁者(Moderator)。负责确保整个审查过程的正确进行，协调审查活动。在审查会议上，负责审查会议的主持，是审查活动成功的最为关键的角色。在最为正式的评审类型中，要求对仲裁者进行专门的培训。
(3)作者(Author)。创建或者维护软件需求规约的人，在评审中作为听众听取评论，并在需要时解答审查人员的问题。在严格的评审形式中，作者不可以同时担任仲裁者、阅读人员或者记录人员。
(4)阅读人员(Reader)。在审查会议上，阅读人员负责逐一解释软件需求规约的内容，并在每次解释后由审查人员指出可能的问题和缺陷。
(5)记录人员(Recorder)。在审查会议上，记录人员负责记录审查中发现的问题以及修改建议。
(6)收集人员(Collector)。有些评审过程并不会举行集中的会议，而是由分散的检查人员各自独立完成检查。这时，就需要由收集人员分别从检查人员那里收集检查结果。
(7)审查人员(Inspector)，包括领域专家(DomainSpecialist)。审查人员中至少应该存在一名领域专家。用户代表(UserRepresentation)，审查人员中应该尽可能的包括各种类型的涉众，尤其是用户。每种重要类型的用户都至少应该有一人参与审查。
(8)技术人员(Technologist)。审查人员中应该包括那些需要以被审查的文档内容开展工作的技术人员。例如，设计人员、测试人员等。
(9)观察员(Observer)。在被审查的文档内容上具有一定经验的人可以被邀请为观察员参与审查过程。例如，作者的同级伙伴、相关产品(前期系统、类似产品、竞争产品以及需要通过特定接口协作的其他产品)的需求工程师等。
在上面的角色中，审查人员的数量是可以控制和调整的，团队规模的合适大小取决于评审的项目环境，没有某个确定的数量是适合于所有项目的。

1．6．2评审的过程
常见的服装销售软件评审过程可以分为6个阶段，分别是规则→总体部署→准备→审查会议→返工→跟踪。
在规划阶段(Planning)，作者和仲裁者共同制订审查计划，决定审查会议的次数，安排每次审查会议的时间、地点、参与人员、审查内容。
在总体部署阶段(Overview)，作者和仲裁者向所有参与审查会议的人员描述待审查材料的内容、审查的目标以及一些假设，并分发文档。
在准备阶段(Preparation)，审查人员各自独立执行检查任务。在检查的过程中，他们可能会被要求使用检查清单、场景等检查方法，记录下来检查中发现的问题，以准备开会讨论或者提交给收集人员。
在审查会议阶段(InspectionMeeting)，通过会议讨论，识别、确认和分类发现的错误。在审查会议结束时，还可以根据审查发现的问题严重程度来确定软件需求规约是可以在修正后接受，还是需要在修正后再次进行评审。
在返工阶段(Rework)，作者修改发现的缺陷。
在跟踪阶段(Followup)，仲裁者要确认所有发现的问题都得到了解决，所有的错误都得到了修正。仲裁者还要判断修正后的文档是否已满足审查的结束标准，如果不满足就需要再次进行评审。
在审查的结束标准问题上，本书给出如下建议：
(1)审查期间审查人员提出的所有问题都已解决。
(2)文档中和相关的工作产品中的所有更改都已正确完成。
(3)修订过的文档已经进行了拼写检查。
(4)所有标识为待确定的问题都已经解决，或者已经对每个待确定问题的解决过程、计划解决的目标El期和由谁来解决等编制了文档。
(5)文档已经在项目的配置管理系统中作了登记。

1．6．3评审的类型
在实践中，评审有多种不同的类型，它们在不同+的程度和灵活度上遵循评审过程，有的非常严格，有的非常灵活。
审查是最为严格的评审方式，严格遵守整个评审过程。通常情况下，审查还会收集评审过程中的数据，并改进自身的评审过程。
小组评审是“轻型审查”。和严格的审查相比，它的总体会议和跟踪审查步骤被简化或者省略了，一些评审者的角色也可能会被合并。
走查是由产品的作者将产品逐一的向同事介绍，并希望他们给出意见。评审小组很少参与审查问题的跟踪和修正，也很少需要进行耗时的事先准备工作。
轮查是同时请作者的多个同事分别进行产品的检查。各个检查人员可能在各自的检查中互相沟通，但是最终参与会议讨论的可能只是一部分甚至少数检查人员。
临时评审是最不正式的评审，它只是作者临时提议(如工作中碰到了问题)发起的评审活动。这些评审方法在过程和活动上的区别如表5-10所示。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com