接u原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所存的冲突之处。 分析可行性
分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。 确定需求优先级
确定软件工程需求的优先级别
?应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。 ?以优先级为基础确定产品版木将包括哪些特性或哪类需求。
?当允许需求变更时，在特定的版木屮加入每一项变更，并在那个版本计划屮作出需要的变更。
为需求建立模型
为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。
?它们能提供不同的信息与关系以宥助于找到不正确的、不一致的、遗漏的和冗余的需求。
?这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
?(在后续章节详细讲述，此处省略)
RUP细化：用例建模 用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。
?用例方法敁早是由Iva Jackboson博士提山的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
?从用产的角度釆看’他们笄不想了解系统的闪部结构和设计，他们所哭心的是系：统所能提偌的服务,圯就慝衹开芡幽来的系：统将慝忉何衹丨更用的,这就用彳列方法的基不慝想。
用例是系统功能需求的反映。 ?软件目标是用例建模的依据。
?软件目标是用例引入的主要来源。 ?用例图描述用例建模的结果。
? 一个系统的全部用例图构成该软件包的需求模型。 建立用例模型
1用例的泠法來描遠系统的功能需求的遠程就是用例建棋，用例棋型立要包招以下两部分内東：
?用例图(Use Case Diagram)
确定系统屮所包含的参与者、用例和两者之间的对应 关系，用例图描述的是关于系统功能的一个概述。 ?用例规约(Use Case Specification)
针对每一个用例都应该存一个用例规约文档与之相对 应，该文档描述用例的细节内容。 ■用例的厌用在^p中铍推崇备至：
21
?鼙个足程鄄绞秫饱慝\用例驱劢” (Vse-Case ?各神券型的讦亥话劲窆括项目管理、分柝埂计、测芪、宾现等鄠夏 以系:统用闵窍歪耍褕入工T牛 ?用例镆型黧定了鼙个系统5U牛开茨：的基础。 用例图（Use Case Diagram)用来描述软件系统向交互活动卷与者提供的一组相关的功能。在一个用例图中，有一个或多个参与者与一个或多个用例相互关联。 用例模型元素 ?:?参与者(JLctot) 参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。 用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 通讯笑联(Communication Association) 通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。 参与关联 ?描述角色和用例之间有信息交流或系统为谁提供哪些功能与服务。 使用关联 ?指一个用例使用另一个用例的功能行为，用于在用例间共享公共的功 能行为。（也是一种泛化（继承）关联、也称包含关联） 扩展关联 ?通过对已有用例增加一些额外的步骤来建立新的用例。 22 用例规约 提供了用例规约的模杈，每一个用例的用例规约都应该包含以下内容： ?简要说明(Brief Description) 简要介绍该用例的作用和目的。 ?事件流(Flow of Event) 包括基本流和备选流，事件流应该表示出所有的场景。 ?用例场景(Use-Case Scenario) 包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。 ?特殊需求(Special Requirement) 描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。 ?前置条件(Pre-Condition) 执行用例之前系统必须所处的状态。 ?后置条件(Post-Condition) 用例执行完毕后系统可能处于的一组状态。 事件流：基本流 基本洗描連的是该用例最正常的一种场景，在暮本洗中系统机行一糸列活动步腺東嘀应参与者提出的服务锖求。 成们建说用以下格式来描連基本洗： ?1)每一个步骤都需要用数字编呈以清楚地标明步骤的先后顺序。 ?2)用一句简短的■来概括每一步骤的主要内容，这样阅读者可以通过丨—《< 题来快速地了解用例的主要步骤 。彺用例建模的早期，我们圯只需耍描逑到事件流步骤标逦这一层，以免迓早杷陷入到用例描逑的细节中去。 ?3)当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交IL。建议采用双向（roundtrip)描述法来保证描述的完整性，即每一步骤 都需要从正反两个方面来描述： > (1)参与者向系统提交了什么信息； >(2)对此系统有什么样的响应。具体例子请参见附录。 事件流：备选流 备迷洗负责描遂用例执行过程中弄常的或偶糸发生 的一些情况，备速洗和基本洗的组合应该能够棗盖 该用例所有可能发生的场景。在描遂备迷洗对，应 该包杨以下几个要素： ?1)起点：该备选流从事件流的哪一步开始； ?2)条件：在什么条件下会触发该备选流； ?3)动作：系统在该备选流下会采取哪些动作； ?4)恢复：该备选流结束之后，该用例应如何继续执行。 备速洗的描14格式可以与基木洗的格式一玫，也需 要编号并以标題概連其A東，编号前可以加以孝母 前敬A (Alternative)以示与基木洗步腺相区别。 23 3.定义 ?建立并维护操作概念和相关场景 ?创建数据字典确保客户和开发人员使用一致的定义 和术语。 ?应用质量功能调配将产品特性、属性与对客户的重 要性联系起来。 ?编写需求规格说明书 ?建立需求跟踪矩阵 构造：用例的动态行为分析 用例分析是软件行为分析的手段 ■诸如：在线支付用例的三位一体描述 ?业务流程图 ?实体类图 ?界面原型图 多数情况下，使用顺序图来阐明用例实现，即说明对象如何通过交互来执行全部或部分用例的行为。 可以用一个或多个顺序图来阐明实现用例的对象交互过程。 在典型的组织结构屮，主事件流将有一个顺序图，而每个独立的用例分支流都分别有一个丨序图。 24 协作图 协作图强调参加交互的对象的组织。 顺序图和协作图都来自UML的元模型中相同的信息，所以两者在语义上是等价的。它们可以从一种形式的图转换为另一种形式的图，而不丢失任何伯息。 交互图用于对系统的动态方面建模。这些动态方面可能涉及一个系统的体系结构的任意视图中的任何种类的实例的交互，包括类(含主动类）、接口、构件和节点的实例的交互。 协作图中的基本原素 L.对象：用于表示协作图中参与交互的类的实例 > 多个对象：用于表不一组对象。 协作图中的对象 属性定义 ?对象名称：在可视化表示屮所用的对象的名字。 用冒号与类名分隔。 ?类名：对象所属的类的名称。用冒号与对象名分隔。 ?限制类型：可供选择的类型有： >None ： 对对象不做限制。 > {new}： 说明对象在交互期间被创建。 > {destroyed}说明对象在交互期间被删除。 > {transient}说明对象是临时的。 ?描述： 关于对象的文字描述。 应用质量功能调配 使用质量功能调配质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的要性联系起来。 ?该技术提供了一种分析方法以明确那些是客户最为关注的特性。 ?kano模型将需求分为三类： >普通需求;必须有的基本需求 >期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意； >兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。 25