第三章需求分析.ppt

第二章软件需求与软件需求规约 软件定义时期的最后阶段 回答 系统必须作什么 的问题 任务是确定系统必须完成哪些工作 对目标系统提出完整 准确 清晰 具体的要求 交付的文档应包括详细的数据流图 数据字典和一组简明的算法描述 需求分析的结果是系统开发的基础 必须进行严格的审查验证 3 1需求分析的要求 确定对系统的综合要求 系统功能 性能要求 运行要求 将来可能要求 分析系统的数据要求 利用图形工具辅助描绘数据结构 导出系统的逻辑模型 数据流图 数据字典 算法描述修正系统开发计划 较准确的估计系统的成本和进度 开发原型系统 重要方法 3 2需求分析的分析过程 1 需求分析阶段的工作 可以分成以下四个方面 1 问题识别首先系统分析人员要确定对目标系统的综合要求 即软件的需求 并提出这些需求实现条件 以及需求应达到的标准 这些需求包括功能需求 性能需求 环境需求 可靠性需求 安全保密要求 3 2需求分析的分析过程 2 用户界面需求 资源使用需求 软件成本消耗与开发进度需求 并预先估计以后系统可能达到的目标 此外 还需要注意其它非功能性的需求 如针对采用某种开发模式 确定质量控制标准 里程碑和评审 验收标准 各种质量要求的优先级等 以及可维护性方面的需求 此外 要建立分析所需要的通信途径 以保证能顺利地对问题进行分析 分析所需的通信途径如图所示 3 2需求分析的分析过程 3 2 分析与综合问题分析和方案的综合是需求分析的第二方面的工作 分析员必须从信息流和信息结构出发 逐步细化所有的软件功能 找出系统各元素之间的联系 接口特性和设计上的限制 判断是否存在因片面性或短期行为而导致的不合理的用户要求 是否有用户尚未提出的真正有价值的潜在要求 剔除其不合理的部分 增加其需要部分 最终综合成系统的解决方案 给出目标系统的详细逻辑模型 3 编制需求分析阶段的文档已经确定下来的需求应当得到清晰准确的描述 通常我们把描述需求的文档叫做软件需求说明书 同时 为了确切表达用户对软件的输入输出要求 还需要制定数据要求说明书及编写初步的用户手册 4 需求分析评审作为需求分析阶段工作的复查手段 应该对功能的正确性 文档的一致性 完备性 准确性和清晰性 以及其它需求给予评价 为保证软件需求定义的质量 评审应以专门指定的人员负责 并按规程严格进行 评审结束应有评审负责人的结论意见及签字 除分析员之外 用户 需求者 开发部门的管理者 软件设计 实现 测试的人员都应当参加评审工作 3 3用于支持需求分析的快速原型化方法 通常 原型是指模拟某种产品的原始模型 在软件开发中 原型是软件的一个早期可运行的版本 它反映最终系统的部分重要特性 如果在获得一组基本需求说明后 通过快速分析构造出一个小型的软件系统 满足用户的基本要求 使得用户可在试用原型系统的过程中得到亲身感受和受到启发 做出反应和评价 然后开发者根据用户的意见对原型加以改进 随着不断试验 纠错 使用 评价和修改 获得新的原型版本 如此周而复始 逐步减少分析和通信中的误解 弥补不足之处 进一步确定各种需求细节 适应需求的变更 从而提高了最终产品的质量 1 原型的分类由于运用原型的目的和方式不同 原型可分为以下两种不同的类型 废弃型 先构造一个功能简单而且质量要求不高的模型系统 针对这个模型系统反复进行分析修改 形成比较好的设计思想 据此设计出更加完整 准确 一致 可靠的最终系统 系统构造完成后 原来的模型系统就被废弃不用 追加型或演化型 先构造一个功能简单而且质量要求不高的模型系统 作为最终系统的核心 然后通过不断地扩充修改 逐步追加新要求 最后发展成为最终系统 有人把废弃型原型又细分为探索型和实验型 探索型原型的目的是要弄清对目标系统的要求 确定所希望的特性 并探讨多种方案的可行性 它主要针对开发目标模糊 用户和开发者对项目都缺乏经验的情况 而实验型原型用于大规模开发和实现之前 考核方案是否合适 规格说明是否可靠 2 原型类型的选择1984年Boar提出一系列选择原型化方法的因素 如果是在需求分析阶段要使用原型化方法 必须从系统结构 逻辑结构 用户特征 应用约束 项目管理和项目环境等多方面来考虑 以决定是否采用原型化方法 当系统规模很大 要求复杂 系统服务不清晰时 在需求分析阶段先开发一个系统原型是很值得的 特别是当性能要求比较高时 在系统原型上先做一些试验也是很必要的 1992年Andriole给出6个问题 用来帮助选择原型方法 下表指明了对这些问题的典型答案和对使用原型方法的建议 选择适当的原型方法 3 原型生存期 原型的开发和使用过程叫做原型生存期 下图是原型生存期模型 软件需求规格说明和需求评审 1 制定软件需求规格说明的原则1979年由Balzer和Goldman提出了做出良好规格说明的8条原则 原则1 功能与实现分离 即描述要 做什么 而不是 怎样实现 原则2 要求使用面向处理的规格说明语言 讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应 来定义一个行为模型 从而得到 做什么 的规格说明 原则3 如果目标软件只是一个大系统中的一个元素 那么整个大系统也包括在规格说明的描述之中 描述该目标软件与系统的其它系统元素交互的方式 原则4 规格说明必须包括系统运行的环境 原则5 系统规格说明必须是一个认识的模型 而不是设计或实现的模型 原则6 规格说明必须是可操作的 规格说明必须是充分完全和形式的 以便能够利用它决定对于任意给定的测试用例 已提出的实现方案是否都能满足规格说明 原则7 规格说明必须容许不完备性并允许扩充 原则8 规格说明必须局部化和松散的耦合 它所包括的信息必须局部化 这样当信息被修改时 只要修改某个单个的段落 理想情况 同时 规格说明应被松散地构造 即耦合 以便能够很容易地加入和删去一些段落 尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性 但这些原则对于其它各种形式的规格说明都适用 当然要结合实际来应用上述的原则 2 软件需求规格说明软件需求规格说明是分析任务的最终产物 通过建立完整的信息描述 详细的功能和行为描述 性能需求和设计约束的说明 合适的验收标准 给出对目标软件的各种需求 3 需求规格说明评审 作为需求分析阶段工作的复查手段 在需求分析的最后一步 应该对功能的正确性 完整性和清晰性 以及其它需求给予评价 评审的主要内容是 系统定义的目标是否与用户的要求一致 系统需求分析阶段提供的文档资料是否齐全 文档中的所有描述是否完整 清晰 准确反映用户要求 与所有其它系统成分的重要接口是否都已经描述 被开发项目的数据流与数据结构是否足够 确定 所有图表是否清楚 在不补充说明时能否理解 主要功能是否已包括在规定的软件范围之内 是否都已充分说明 软件的行为和它必须处理的信息 必须完成的功能是否一致 设计的约束条件或限制条件是否符合实际 是否考虑了开发的技术风险 是否考虑过软件需求的其它方案 是否考虑过将来可能会提出的软件需求 是否详细制定了检验标准 它们能否对系统定义是否成功进行确认 有没有遗漏 重复或不一致的地方 用户是否审查了初步的用户手册或原型 软件开发