中科院需求工程 需求工程(第九讲)文档驱动的方法_.ppt

需 求 工 程 金芝 中国科学院数学与系统科学研究院 zhijin@amss.ac.cn 第九讲：文档驱动方法 需求文档的重要性 四变量模型 SCR需求方法 形式化SCR和表演算机制 总结 从软件工程师的职责谈起 工程师的职责之一：保证产品的适用性 要求和应用专家准确、细致地沟通 沟通必须以写下来的需求陈述为基础 用户和实现者能够阅读和分析 能够在产品开发完成后用于评估这个产品 能够用于评定产品完成后的关于产品缺陷的争论 …… 没有文档，任何工程师做不到这一点 发现需求是一门艺术，文档化需求并验证它的完整性是一门学科 需求文档 需求文档不表达如何开发产品,需求文档是关于将开发什么产品要做什么的描述 三个术语 描述：关于该产品的一些信息,可以不完整,但必须是真实的 规格说明：该产品需求属性的一个描述,软件产品的外部可见的行为 模型：具有产品的部分属性，以及可能不属于产品的属性，维护完整性一致性，方便验证 好文档的作用 可以描述已经存在的软件——我们可以不用读代码就能够回答关于该软件的问题 可以描述还不存在的软件——程序员和客户可以就需求达成一致意见 验证产品是否满足需求（测试和/或审查） 可以建立工具检查规格说明 可以建立工具模拟系统并检查系统 文档可接受的标准 描述必须比代码容易理解 文档必须用一种不限制解决方案的方式陈述需求 测试和证明最终能够自动化 程序与其它工程产品不同吗？ 在计算机出现之前，工程师使用经典数学来描述和分析产品 在计算机科学中，大多数研究者发明新的“语言” 我们将软件作为产品来开发 程序与其它工程产品不同吗？ 我们为什么不能简单地用我们习惯的数学来建模？ 传统产品是无生命的东西（X） 我们需要描述被程序遵循的过程（X） 功能不是连续的（√） 需求阶段的目的 在开始构建产品之前，决定要构建什么 在设计之前显式地说出是“什么决定”，而不是象设计中那样隐式地给出 确定你构建的是必需的 让用户在产品构建之前进行评判 为软件开发者提供有组织的参考文档 提供精确，一致的信息 关于约束的问题只涉及一次 让他们不用决定什么对用户来说是最好的 补偿他们对环境的知识的缺少 给他们足够的信息进行设计决策 让他们准确地估计需要的时间和资源 需求阶段的目的 容许人员的更替 为质量保证组提供参考文档 测试设计不应该以来程序 授权的需要——质量保证组和程序员可能不一致 说明实现相关的所有约束 知道你面临什么 为应付客户的变化提供某种形式的保护 能够评判可行性和代价 说明未来修订的约束 两变量模型 硬件/软件系统的传统模型基于两个假设： 系统具有输入和输出 输出是输入的数学函数 其中，输入是系统的实际物理输入 数学函数可能很复杂并难以描述 难以得到应用专家的审查 四变量模型 在系统的外部，存在物理变量，一些是监视变量、一些是控制变量、一些两者都是 外部设备感应监视变量，决定计算机的输入，读取计算机输出，影响控制变量的值 系统需求说明在监视变量和控制变量之间希望存在的关系 领域专家根据监视变量和控制变量来审查需求，而不是根据输入和输出变量 软件需求使用输入和输出变量来描述 四变量模型 四变量模型的关系 整个系统：满足监视变量和控制变量之间的关系 输入设备：满足监视变量和输入变量之间的关系 输出设备：满足输出变量和控制变量之间的关系 软件系统：满足输入设备和输出设备之间的关系 识别和声明监视和控制变量 识别监视变量：(mt1, mt2, …, mtn) 识别控制变量：(ct1, ct2, …, ctp) 主要的监视变量是系统外的东西，它的值应该影响系统的输入，比如： 客户计量器的读数 蒸汽温度 主要的控制变量是系统外的东西，它的值应该由系统来决定，比如： 操作者来计算机屏幕上看到的东西 什么将出现在帐单上 定义变量之间的关系 NAT关系：mt? ct mt：m在t时刻的取值 ct：c在t时刻的取值 (mt, ct) ? NAT 当且仅当ct描述的环境控制量是环境约束在mt描述的环境监视量下是允许的 REQ关系：mt? ct mt：m在t时刻的取值 ct：c在t时刻的取值 (mt, ct) ? REQ 当且仅当ct描述的环境控制量是计算机系统在mt描述的环境监视量下是允许的 关系满足的条件 domain(REQ) ? domain(NAT) domain(REQ?NAT) = domain(REQ) ? domain(NAT) 其中， （1）表示系统需求文档的完整性； （1）和（2）表示系统需求文档的可行性 定义变量之间的关系 IN关系：mt? it mt：m在t时刻的取值 it：c在t时刻的取值 (mt, it) ? IN 当且仅当在mt描述的环境监视量下输入设备正常工作时可能产生的值 OUT关系：ot? ct ot：m在t时刻的取值 c