车海燕-软件工程-Lecture-SE-2013-Chap04-01.pptVIP

软件工程- 2013- 第四章 软件需求 客户认为有问题需要解决（用软件） 与开发方接触、探讨问题、寻求帮助 对可解的部分，双方确定解决的范围、内容、程度，签订协议 开发方按某种工程化过程解决定义的问题，形成产品 产品交付使用，及使用中维护、更新、产生新的要解决的问题…… “建造一个软件系统的最困难的部分是决定要建造什么……没有别的工作在做错时会如此影响最终系统，没有别的工作比以后矫正更困难。” 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） 需求过程不仅是可能的而且也是值得的 需求：就是系统的特征，或对系统为达到某个目标所能做的事情的一个描述。 需求：是对问题信息和系统行为、特性、设计及制造约束的描述的集合。 需求过程本质：在问题空间与求解空间中间架设桥梁。 误解 交流障碍 缺乏共同语言 “完整性”问题 需求永远不会稳定 用户意见不统一 错误的要求 认识混淆 “我知道你相信你已经理解了你认为我所说的内容，但是我并不能肯定你已经认识到你所听到的并不是我所想要的。” 需求可能首先从项目干系人角度表达为一个非形式化的、不详细的、高层的描述，称为项目干系人需求（客户需求）； 然后从开发者角度出发，发展成更详细的形式，即系统需求。 功能需求：系统与环境间的交互——描述系统必须支持的功能和过程的系统需求。 非功能需求：客户给出的具体约束、指标——描述操作环境和性能目标的系统需求。 二者的区别：功能需求描述系统应该做什么，非功能需求则为如何实现这些需求设定约束。 例如： 功能需求可能声明系统必须提供一些验证系统用户身份的工具。 非功能需求可能声明验证过程必须在4秒内完成。 性能：实时性、资源利用、硬件配置限制、精确度 可靠性：有效性、完整性 安全/保密性 运行限制：使用频度、运行期限、控制方式（如本地或远程）、对操作员的要求 物理限制：系统的规模等限制 用户界面友好性：易用性 正确性：要确保需求的表达中没有引入错误（faults）。 一致性：确保没有互相冲突、矛盾的需求；确保没有不确定的需求。 完整性：如果需求描述了所有可能的状态，以及状态的变化、输入、过程和约束，那么这组需求就是完整的。 现实性：确保客户要求系统做的事真的能做到。 实用性：确保需求和要解决的问题有直接关系。 可检验性：必须能写出测试来说明需求已被满足。 可回溯性：保证每个系统功能都能追溯到一组要求它的需求；确保很容易找到处理系统特定方面的某一组需求。 需求文档的可能使用者： 系统客户：需要阅读需求文档来检验是否表达了他们的需要； 软件项目管理者：需求文档是制定项目计划的基础之一； 系统工程师：需要理解待开发系统； 系统测试工程师：要依据需求文档制作测试用例，验证开发出的系统是否满足要求； 系统维护人员：使用需求文档理解初始系统的特性和系统不同部分之间的关系。 对应两种不同详细程度的需求（项目干系人需求、系统需求），有两种需求文档： 需求定义（需求描述） 用应用域术语编写 彻底列举客户/用户想要系统做些什么 由客户/用户和开发人员共同编写 需求规约（软件需求规格说明，Software Requirements Specification） 用开发人员擅长的技术术语编写 需求定义的技术性版本，方便设计人员理解 由分析人员编写 需求规约和设计（尤其是高层设计）之间可能不存在明显的界线 需求规约可能必须构造成能反映目标系统的体系结构模型，而且某些特殊需求可能制定对设计和实现的约束（如指定要基于浏览器的系统）； 反过来，在复用已有系统的经验时，可能参考从前的设计方案的成功或失败，来表达某些需求。 需求定义和需求规约的产生可能是分开的，也可能是合并的。因此，两种需求文档可能是分开的，也可能是合一的 某些情况下首先开发出项目干系人需