软件工程04.1.ppt

软件工程 - 2010 - 第四章 软件需求 “建造一个软件系统的最困难的部分是决定要建造什么……没有别的工作在做错时会如此影响最终系统，没有别的工作比以后矫正更困难。” Fred Brooks 误解 交流障碍 “完整性”问题 需求永远不会稳定 用户意见不统一 错误的要求 认识混淆 不完整的需求（13.1%） 缺少用户的参与（12.4%） 缺乏资源（10.6%） 不切实际的期望（9.9%） 缺乏行政支持（9.3%） 改动需求和说明（8.7%） 缺少计划（8.1%） 不再需要该系统（7.5%） 事实1 在软件生命周期中，一个错误发现得越晚，修复错误的费用越高 事实2 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 事实3 在需求过程中会产生很多错误 事实4 在需求阶段，代表性的错误为疏忽、不一致和二义性 事实5 需求错误是可以被检查出来的 由上面这些事实，能得出如下四点结论： 在需求过程中会产生很多错误（事实3和4） 许多错误并没有在早期被发现（事实2） 这样的错误是能够在产生的初期被检查出来的（事实5） 如果没有及时检查出来这些错误，软件费用会直线上升（事实1） 需求过程不仅是可能的而且也是值得的 需求：就是系统的特征（Features），或对系统为达到某个目标所能做的事情的一个描述 需求：是问题信息和系统行为、特性、设计及制造约束的描述的集合 需求过程本质：在问题空间与求解空间中间架设桥梁 需求可能首先从项目干系人角度表达为一个非形式化的、不详细的、高层的描述，称为项目干系人需求（客户需求） 然后从开发者角度出发，发展成更详细的形式，即系统需求 功能需求：系统与环境间的交互——描述系统必须支持的功能和过程的系统需求 非功能需求：客户给出的具体约束、指标——描述操作环境和性能目标的系统需求 二者的区别：功能需求描述系统应该做什么，非功能需求则为如何实现这些需求设定约束 例如： 功能需求可能声明系统必须提供一些验证系统用户身份的工具 非功能需求可能声明验证过程必须在4秒内完成 性能：实时性、资源利用、硬件配置限制、精确度 可靠性：有效性、完整性 安全/保密性 运行限制：使用频度、运行期限、控制方式（如本地或远程）、对操作员的要求 物理限制：系统的规模等限制 用户界面友好性：易用性 正确性：要确保需求的表达中没有引入错误（faults） 一致性：确保没有互相冲突、矛盾的需求；确保没有不确定的需求 完整性：如果需求描述了所有可能的状态，以及状态的变化、输入、过程和约束，那么这组需求就是完整的。 外部完整：需求描述的所有关系都与客户想要的环境相关 内部完整：所收集的需求之间没有未定义的引用 现实性：确保客户要求系统做的事真的能做到 实用性：确保需求和要解决的问题有直接关系 可检验性：必须能写出测试来说明需求已被满足 可回溯性：保证每个系统功能都能追溯到一组要求它的需求；确保很容易找到处理系统特定方面的某一组需求 确定对系统的综合要求 功能需求 性能需求 可靠性和可用性需求 出错处理需求 接口需求--用户接口需求；硬件接口需求；软件接口需求；通信接口需求 约束--精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台 逆向需求 将来可能提出的要求 导出系统的逻辑模型 软件系统详细的逻辑模型通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述 修正系统的开发计划 可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 需求文档的可能使用者： 系统客户：需要阅读需求文档来检验是否表达了他们的需要 软件项目管理者：需求文档是制定项目计划的基础之一 系统工程师：需要理解待开发系统 系统测试工程师：要依据需求文档制作测试用例，验证开发出的系统是否满足要求 系统维护人员：使用需求文档理解初始系统的特性和系统不同部分之间的关系 对应两种不同详细程度的需求（项目干系人需求、系统需求），有两种需求文档： 需求定义（需求描述） 用应用域术语编写 彻底列举客户/用户想要系统做些什么 由客户/用户和开发人员共同编写 需求规约（软件需求规格说明，Software Requirements Specification） 用开发人员擅长的技术术语编写 需求定义的技术性版本，方便设计人员理解 由分析人员编写 需求规约和设计（尤其是高层设计）之间可能不存在明显的界线 需求规约可能必须构造成能反映目标系统的体系结构模型，而且某些特殊需求可能制定对设计和实现的约束（如指定要基于浏览器的系统） 反过来，在复用已有系统的经验时，可能参考从前的设计方案的成功或失败，来表达某些需求