4 软件需求.pptVIP

软件工程 第四讲 软件需求  朱建凯 上次课给出的问题： 给出瀑布模型适应的情况，并说出理由？ 给出演化模型适应的情况，并说出理由？ 通过本次课程，需要大家了解 什么是需求?（重要） 软件需求应该具有什么属性（重要） 软件需求的构成（非常重要） 需求获取的手段（了解） 需求如何表述？（了解） 讨论 软件需求应该有些什么属性？ 软件需求会涉及一些什么问题？ 3) 需求发现技术 假如现在获得一个开发项目，如何获取需求呢？ 自悟 交谈 观察 小组会 提炼 自悟 要求对业务熟悉，用于不方便对用户调查 交谈 对供需双方都有要求，要防止需求越界 小组会 复杂系统常用方法 提炼 有一定文档或者现有一些资料，功能规范 情景模拟，用例法… … 总之，需求获取方法是灵活的 灵活组合 或者多次迭代 使用自然语言定义需求规约的问题 不确定性 读者和作者必须以同样的方式对同样的文字有相同的翻译。 过于灵活 同一个事情可以有多种表达方式。 不方便模型化 自然语言不适合结构化表达。 结构化的语言规约 需求规约的作者写作的自由度必须通过预定义模板来限定。 所有的需求都必须用统一的标准方式来表达。 使用的术语必须是有限定的。 这样的好处就是即保留了自然语言的优势，同时它的不一致性又得到了约束。 表单式需求规约 对功能或者入口进行定义. 描述所有的输入以及它们来自哪里. 面熟所有的输出以及它们到哪里去. 指出相关系的其他实体. 前置和后置条件 (如果有的话). 这个功能的副作业是什么 (如有). Form-based node specification 阅读与思考 清华大学张海藩《软件工程》3.1、3.2、3.3 思考: 1、为什么用户需求文档要对每一条需求进行编号？ 2、哪些人应该参加需求评审？ 第一次作业： 57页 习题二 13题 66页 习题三 2题(要举例)，6题 6．属性 6．1 可使用性 规定某些需求，如检查点、恢复方法和重启动性，以确保软件可使用。 6.2 保密性 规定保护软件的要素。 6．3 可维护性 规定确保软件是可维护的需求，如模块耦合矩阵。 6．4 可移植性 规定用户程序、用户接口的兼容方面的约束。 7．其他需求 7．1 数据库 说明作为产品的一部分来开发的数据库的需求。如： (1)使用的频率； (2)访问的能力； (3)数据元素和文件描述；(4)数据元素、记录和文件关系； (5)静态和动态组织； (6)数据保留要求。 7．2 操作 列出用户要求的正常及特殊的操作，如： (1)在用户组织中各种方式的操作； (2)后援和恢复操作。 7．3 故障及处理 列出可能发生的软件和硬件故障，并指出这些故障对各项性能指标所产生的影响及对故障的处理要求。 注意: 以上给出的是一份需求规格说明书的样例，在实际软件工程中，每个开发组织可根据相关的标准和从事的开发领域，规定自己组织的软件需求分析规格说明书的格式。 4)表达需求规约(规格说明书)的三种风格 ?非形式化的规约 即以一种自然语言来表达需求规约,如同使用一种自然语言 写了一篇文章. 其中:可以不局限于那种语言通常所约定的任何符号或特殊 限制(例如文法和词法）,但要为那些在一个特定语境 中所使用的术语提供语义定义，一般情况下，该语境 与通常使用该术语的语境是有区别的。 ?半形式化的规约 即以半形式化符号体系(包括术语表、标准化的表达格 式等)来表达需求规约。因此,半形式化规约的编制应遵循一 个标准的表示模板(一些约定)。 其中: --术语表明确地标识了一些词，可以基于某一种自然语言 --标准化的表达格式(例如例如数据流图、状态转换图、实 体关系图、数据结构图以及过程结构图等)标识了一些元 信息,支持以更清晰的方式系统化地来编制文档. --应用中,不论是词还是标准化的表达格式,在表达上均必 须遵循一些约定,即应以一种准确和一致方式使用之。 ?形式化规约 即以一种基于良构数学概念的符号体系来编制需求规约，一般往往伴有