需求工程-05.ppt

* * * RE vs. Systems Analysis  需求工程vs.系统分析 * 需求工程vs.系统分析RE vs. Systems Analysis 需求工程由系统分析发展而来 系统分析关注企业内部的信息系统 主要采用非形式化的需求描述，工具和方法, 例如：DFD, E-R, OO,… 80年代中期形成，90年代以来成为研究热点。 多见于管理学院，工程学科，和计算机科学的本科生和研究生教学 * 需求工程vs.系统分析RE vs. Systems Analysis 需求工程超出系统分析的范围 涵盖整个形式化问题 从“企业需求”到“精确描述” 不仅限于信息系统 实时系统 嵌入系统 交互系统 基于组件的系统 web services 相对较少关注企业管理问题和企业业务流程 * But, what is a requirement? 每一个“人造物”都是一个内部环境与外部环境的“接口”。这里内部环境指人造物本身的设计组成。外部环境指人造物的周遭及其作用环境。对这个接口的描述即是需求。 —— Herbert Simon, 1969 需求, 即是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收，提交的依据。 —— IEEE 610.12, 1990 * 将问题与解决方案分开 理解问题 需求获取 问题的形式化表示 形式规约，形式建模 就问题性质达成共识 验证, 冲突及矛盾消解, 磋商 需求管理– 维护双方的共识 * 设计活动改变客观世界状态 * 什么是需求？（Jackson, 1995） 领域性质(Domain Property)：无论系统存在与否均存在的应用领域的性质。 需求(Requirements)：由系统的存在而产生的应用领域性质。 规约描述(Specification)：描述系统为满足需求而应具有的行为。 需求证明的标准(Verification Criteria)：1、运行在某台机器上的程序满足规约描述；2、针对给定的领域性质，规约描述满足需求。 需求验证的标准（Validation Criteria）：1、是否已发现所有重要需 求？2、是否已发现所有有关的领域性质？ * 实例 Requirement R需求: 只有被授权者能够访问数据库。 Domain Properties D领域性质: 授权者持有密码。 密码不会分享给未授权者。 Specification S 规约描述: 用户输入密码后，将被准许访问数据库。 S+D imply R 当领域模型出错时，会有什么后果 * 需求：关于为什么？做什么？不包括怎么做？（why, what, how） …需求描述必须给出为什么需要这样一个系统。 —— Ross, 1977 通常，需求描述系统要做什么，而不是怎么做。但是，二者不太容易区分，上一个抽象层次的“怎么做”经常在下一个抽象层次上转化为“做什么”。 Jackson给出的稍为清楚的解释： “为什么”和“做什么”是指系统的设计目的，是置身系统外部，对应用领域性质的描述。 “怎么做”是指系统的内部结构和行为。 —— Jackson, 1995 * “描述”是需求工程的核心（Jackson, 1995） 用非形式化的语言指出感兴趣的主题现象，并命名(designation)。例如： Parent (x, p)：p是x的父母。 Female(x): x是女性。 术语的形式化定义(definition)和使用。例如： Mother(x,m) ≡ Parent(x,m) and Female(m) Sister(x, y) ≡ Female(y) and mother(x,m) and mother (y,m) and father(x,f) and father(y, f) * “描述”是需求工程的核心（Jackson, 1995, p58-59） 关于领域性质的无可驳的描述(refutable description)。无可驳性依赖于与主题现象的一致性。例如： 对所有的m和x，Parent(x，m)蕴含not(parent(m,x)) 开发过程中的带有假设性质的概略描述(rough sketch)。例如： “人与人之间总是通过某种方式相互联系” “每个人实际上只能有一个家” * 存在问题的需求描述实例 含糊的需求描述： “工资总额由上一条记录获得” “所有客户都具有同一控制域“ 错误的需求描述： “所有系统将九月作为财政年度的起始时间” 不完整的需求描述： “出错信息显示在屏幕的第24行“ 矛盾或不一致的需求描述： “C=A+B”；“C=A-B” 无法测试的需求： “系统应具有友好的界面“