设计约束designconstraints-上海交通大学.pptVIP

第四讲. 初始化阶段Chapter 4-7 曹健 上海交通大学 内容 案例简介 初始化阶段 需求概念 基于用例的功能性需求获取 非功能性需求 1. 案例 NEXTGEN POS 系统 NextGen 销售终端(point-of-sale, POS) 系统 POS系统是用来记录销售信息和处理支付的计算机系统，它一般用于零售店 体系结构 讲授方法 2. 初始化阶段 2.1 在我们开始一个项目前… 在项目启动前，我们需要回答下列问题: 该项目的vision（设想，前景） 和business case（业务案例） ? 可行吗? 购买and/or 构造? 成本的大致估计; 是$10K-100K 或者几百万? 我们需要继续还是停止? 2.2 目的 该阶段的目的不是定义所有的需求，而是做适当的调研（to do just enough investigation） 何谓“适当的”： 对新系统的整体目的和可行性形成一个合理的意见 确定是否值得深入研究 初始化阶段的主要目标为: 建立项目的软件范围和边界条件，包括一个操作“前景”，“接受准则”和产品中包含什么，不包含什么 确定核心的用例，这是系统运行的主要场景，它将决定系统设计的方案 针对主要的场景，确定或者演示至少一个备选的系统结构 对整个项目估计总成本和计划 (更详细的估计将安排在细化阶段中) 估计可能的风险 (不可预计性的来源） 为项目准备支持环境 2.3 制品 前景和业务用例（Vision and Business Case） 用例模型（Use-Case Model） 补充规格说明（Supplementary Specification） 词汇表（Glossary） 风险列表和风险管理计划（Risk ListRisk Management Plan） 原型和概念验证（Prototypes and Proof-of-concepts） 迭代计划（Iteration Plan） 阶段计划和软件开发计划（Phase Plan Software Development Plan） 开发案例（Development Case） 3. 理解需求（Chapter 5） 3.1 概述 需求 每一个人都有需求 在不同的时间我们有不同的需求 需求驱动了软件过程 正式的定义 “需求就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件. 3.2涉及到谁? 客户（Client） – 为开发付钱的人，将来是产品的拥有者 顾客（Customer） – 买商品化软件的人，或者将来有发言权确定是否产品可以接受（开发产品）。可能与客户是同样的人 涉众 – 任何对系统的需求有直接或者间接影响的人 参考: Mastering the Requirements Process, Robertson and Robertson 3.3 需求管理 需求管理是一种系统化的方法： 获取，记载、组织和跟踪系统的需求 为客户和项目团队之间针对不断变化的需求建立和维护协议 3.4 功能需求 功能需求 系统必须提供的服务的描述，系统应该如何响应特定的输入，系统在特定的情景下的行为 例子 用户能够搜索所有的数据集合或者从中选择一部分进行搜索 系统需要为用户提供合适的浏览器从文档库中读取文档 每一个订单需要分配一个唯一标识符，用户可以永久保存起来. 3.5非功能需求 对系统提供服务或者功能的约束，如时间约束，开发过程的约束，标准等等； 许多需求是非功能性的，只能够描述系统的属性或者系统环境的属性 例子 产品需求 “It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set.” 组织需求 “The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95” 外部需求 “The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system” 3.6需求类型 另一种分类的方法是采用FURPS+ 模型 [GRA92], 缩写FURPS 描述了需求的主要类别： Functionality Usability