第三讲 嵌入式系统需求定义 嵌入式软件设计开发

问题定义
案例[FRIEND,1994] 应急联动系统
4. 接受标准 ① 第一版不要求实现所有功能。 ② 在需求工程阶段，客户与软件工程师协商一个可交付的 原型。 ③ 在协商阶段之后，用户验收测试的具体需求将被冻结。 ④ 客户需求在4-6周内开始正式交付。 ⑤ 最低限度，原型可扩展。 ⑥ 最低限度的验收测试，希望协商的原型能在有一个无线 组件的系统上演示。 ⑦ 理想的演示，希望在警察的现场系统上演示。
• • •
基本原理
基本原理是决策的依据。给定一个决 策，它的基本原理包括它针对的问题、备 选方案、评价备选方案的标准、开发人员 的争论以及决策本身。
需求模型的建模步骤
问题定义 需求提出 系统规格说明： 模型 基本原理模型： 模型
需求分析 系统分析模型： 模型
需求提出和分析仅仅集中在使用者对系 统的观点上。
问题定义的活动
确定系统约束
• • • • • • • • 网络带宽、系统平台、接口、兼容旧系统等 用户使用软件的能力与习惯 价格 时间 质量 用户的配合度 公司现有状况(人力\资金\销售\开发平台\业务领域等 等) 非功能性需求
问题定义的活动
确定系统范围
• • • 确定应用域----环境与系统的边界 确定应用Baidu Nhomakorabea的边界 确定系统的边界
需求定义
基本概念 • 伪需求 伪需求是客户强加的需求，它约束系统的 实现。典型的伪需求是实现系统的编程 语言和运行平台。
需求定义
基本概念 • 需求描述的要求 需求定义的最终目的是要获得没有二义 性的、全面的、详尽的目标需求。因此， 需求规格说明要满足正确性、完整性、 一致性、清晰性、现实性、可修改性、 可追踪性等要求。
问题定义
案例 [FRIEND,1994] 1. 当前紧急情况处理的缺陷
①
应急联动系统
基于电话线路，处理能力？ 一般不用 传送信息的方式 无线电传送。 ② 防火、警察、紧急医疗服务、重大工 程事故等，纸制资料在紧急情况发生 使用已有信息 时用不上或不好用。 ③ 紧急情况发生时，关键信息不能快速 获得。如事件位置信息（危险品、煤 获取有用信息 气管道等地点）不能得到或根本不存 在。
需求定义
基本概念
非功能性需求:指与系统功能行为没有直接关系但用户可见的系 统部分，是系统的特定特性，以保证功能的正常实现、优化产品 的功能或者是限定产品应达到的目标值。非功能性需求为确定系 统的结构和系统选用的技术等进行了约束，包括定量约束，如响 应时间或精度等。 最常见的非功能性需求有： • 系统处理速度； • 可靠性； • 可用性； • 安全性； • 耐用性； • 产品的最终价格； • 系统的尺寸和质量； • 系统的功耗。
问题定义的活动
确定系统目标
• • • • • • • • • •
目标是用来指导项目的高层准则。目标常是相互冲突的。
性能最好 功能最多最强 价格最便宜 明确、量化 界面最美观 性价比最好 最快完成 比竞争对手的要好 可复用/一次性 可靠性 。。。。。。 • • • • • • • 正确 完整 一致 清晰 现实 可验证 可追溯
第三讲 嵌入式系统需求定义 3.2 需求定义
需求定义
基本概念
• • • • • •
功能性需求 非功能性需求 伪需求 需求描述的要求 确定一致的术语 描述的层次
需求定义
基本概念 • 功能性需求 功能性需求是系统功能的陈述，明确系统 应该提供什么功能。如电梯控制系统中 的一个功能需求就是：当电梯求生系统 开启时，电梯自动控制系统开启应急电 灯。
问题定义
案例[FRIEND,1994]
2. ① ② ③ ④
应急联动系统
功能性需求 在异常呼叫负载情况下能同时处理多个紧急事件。 对紧急情况的更坏状况有所准备 使用宽带，传输不能成为限制。 提供实时信息，如：
◇ 地理信息——如城市地图，包括地上和地下公共设施 ◇ 危险品信息 ◇ 建筑物位置信息——如煤气或供水管道、消防栓位置、楼层地图 ◇ 可用的政府资源——如紧急情况操作方案（Emergency
问题定义
在正式的需求工程之前。
其目标是让项目经理和客户就所构建系统的 范围达成意见一致，产生一个问题定义文档，概 括系统的功能和领域，也包括非功能性需求。 问题定义并不产生问题的完整描述，它只是一个 初步的需求活动。
第三讲 嵌入式系统需求定义 3.1 问题定义
问题定义的活动
• • • 确定系统目标 确定系统约束 确定系统范围
嵌入式软件设计开发
康一梅
kangyimei@yahoo.com
BeiHang College of Software
关于需求
需求就是关于系统应该“做什么” 而不是“怎么做”的问题描述。需求通 常分为需求定义和需求分析两个阶段。 需求定义产生客户理解的系统规格说明 书，需求分析产生开发人员可以清楚解 释的分析模型。
问题定义
案例[FRIEND,1994] 应急联动系统
3. 非功能性需求 ① 首先在公安警务部门使用。医疗卫生部门使用 ② 之后在医疗、消防、市政管理部门等使用，对本地信息 警务 提供更高级的管理功能。 ③ 现场人员使用的设备应适合恶劣天气和艰苦工作。 ④ 可移植到当地政府可用的现有硬件上。 ⑤ 原型希望是可扩展的，以便处理省级、国家级事件。
系统分析员素质
虽然许多传统的需求问题仍未解决，但是客户 对系统的要求却在不断提高。这是因为客户本身面临 着更激烈的竞争，他们需要以最快的速度调整业务以 满足市场的需要。相应地，软件开发者对需求的定义 与分析不仅要考虑当前的需求，还要考虑可能面临的 需求变化。对于软件开发者而言，现在已经进入随需 应变的时代，这对系统分析员的要求也越来越高。 一个合格的系统分析员应该具备以下素质： 业务知识 技术背景分析能力 沟通技巧
Operation Plan,EOP)
问题定义
案例[FRIEND,1994] 应急联动系统
2. 功能性需求 ⑤ 遵照指导方针和EOP，系统将自动通知适当部门的工作 人员，创建任务列表、配置资源及其他一些在紧急情况 中节省时间的工作。 ⑥ 每一个与系统交互的现场指挥工具上都有一台移动电脑 使用无线通信向总部调度员报告。目标是试图用一种更 简单的输入手段、响应式的用户界面、语音识别、触摸 屏或手写笔式的系统，来替换第一响应者报告输入机制。 系统事务都须归档，以便将来分析所需。