6软件需求分析2.pptVIP

* * * 软件需求分析 --目录 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 需求规约的原则-1 从现实中分离功能，即描述要“做什么”而不是“怎样实现” 规约必须是一个认识模型，而不是设计或实现的模型 使用面向处理的规约语言(或称系统定义语言)，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约 需求规约的原则-2 系统工程：如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中 规约必须包括系统运行环境 规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约 需求规约的原则-3 规约必须允许不完备性并允许扩充 规约必须局部化和松散耦合 它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落(理想情况) 规约应被松散地构造(即松耦合)，以便能够很容易地加入和删去一些段落 需求验证 需求验证目的是要检验需求是否能够反映用户的意愿 评审人员评审时往往需要检查以下内容： 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求； 被开发项目的数据流与数据结构是否确定且充足； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 设计的约束条件或限制条件是否符合实际； 开发的技术风险是什么； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。 软件需求分析 --目录 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 需求管理 需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动 需求跟踪有两种方式，正向跟踪与逆向跟踪 正向跟踪：以用户需求为切入点，检查《需求规约》中的每个需求是否都能在后继工作产品中找到对应点 逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在《需求规约》中找到出处 需求变更的原因 初期的认识不足导致错误或不完整的需求 需求本身存在不一致 业务变化导致的刚性需求变更 外部经济、市场环境的变化 客户和项目组对已确认的需求理解不一致 技术制约或多目标权衡带来的需求变更 需求变更管理过程支持 变更申请 需求方 开发方 忽略 选择变更方式 SCCB评估 项目经理自行决定 根据评估结果 拒绝 接受本次修改 下个版本再修改 修改合同相关信息 修改相关需求 修改相应的项目计划 * *