Chapter07建模….ppt

Chapter 7构建分析模型Analysis Modeling IEEE的需求定义 用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。 —— IEEE的软件工程标准术语表（1990） Sommerville的需求定义 对应该实现什么功能的说明； 可以是系统运行方式或系统特征与属性的描述； 可能是对系统开发过程的约束。 Sommerville，Sawyer（1997） 软件需求的类型 功能需求 系统可以完成的所有事情 涉及与本系统有接口的其他系统的所有事情 非功能需求 软件开发过程中必须遵守的约束（Constraint)。是对可以使用的资源和软件质量的各个方面的限制，往往会影响软件工程师做决策的自由度。 非功能需求应是可验证的（Verifiable)。 需求分析越来越难 问题域的复杂性越来越高。 交流障碍。(涉众的文化背景不同；自然语言的多义性，一语双关等）。 完整性问题。（用户对问题的陈述往往是不完备的；用户意见不统一，需求之间可能存在着矛盾；涉及许多细节） 需求易变性。（需求永远不会稳定，往往存在错误的需求） 应该足够重视需求分析 软件项目中40%-60%的缺陷都是由需求分析阶段的过失所致（Daivs 1993，Leffingwell 1997） 对欧洲软件行业的大规模调查显示：确定和管理用户需求是问题最多的两个环节（ESPITI 1995） 许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当 信息收集方式不正规 没有明确提出想要的功能 常常存在未经沟通的错误假设 需求的定义不够充分 未经仔细考虑进行需求变更 ······ 7.1 需求分析 需求分析产生软件操作特征的规格说明，指明软件系统和其它外部实体的接口，建立软件系统必须满足的约束。 需求分析对最初的需求进行细化，并建立模型描述用户场景、功能活动、类及类之间的关系、系统和类行为、数据流等。 需求分析为设计提供信息、功能和行为的表示，以便设计出软件的结构、接口和构件（模块）。 分析模型和需求规格说明为开发人员和客户提供了评估软件质量的手段。 Software Requirements Analysis identify the “customer” and work together to negotiate “product-level” requirements build an analysis model focus on data define function represent behavior prototype areas of uncertainty develop a specification that will guide design conduct formal technical reviews The Analysis Process 分析模型必须实现的三个主要目标 描述客户需要什么 为软件设计奠定基础 定义在软件完成可以被确认的需求 分析的经验原则（p109） 模型应关注在问题域或业务域内可见的需求，抽象级别应该相对高一些。 分析模型的每个元素都应该增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。 关于基础结构和其它非功能的模型应推迟到设计阶段再考虑。 最小化整个系统的关联 确认分析模型为所有涉众都带来价值 尽可能保持模型简介。 Analysis Principle IModel the Data Domain define data objects describe data attributes establish data relationships Analysis Principle IIModel Function identify functions that transform data objects indicate how data flow through the system represent producers and consumers of data Analysis Principle IIIModel Behavior indicate different states of the system specify events that cause the system to change state Analysis Principle IVPartition the Models refine each model to represent lower levels of