软件需求工程简介【荐】.ppt

软件需求工程简介 了解软件需求开发中使用的一些关键名词。 警惕在软件项目中可能出现的与需求相关的一些问题。 知道优秀的需求规格说明应该具有的特点。 明白需求开发与需求管理之间的区别。 软件需求的定义 软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。 客户所定义的“需求”对开发者似乎是一个较高层次的产品概念。而开发人员所说的“需求”对用户来说又像是详细设计了。 实际上，软件需求包含着多个层次，不同层次是从不同角度与不同程度反映着细节问题。 软件需求的定义 用户所需要的并能触发一个程序或系统开发工作的说明。 从系统外部能发现系统所具有的满足于用户的特点、功能、属性等 。 指明必须实现什么样的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束 。 软件需求的定义 IEEE软件工程标准词汇表（1997年）中定义需求为： 用户解决问题或达到目标所需的条件或权能（Capability）。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面①或②所描述的条件或权能的文档说明。 * 需求风险 过于精简的规格说明。 容易导致遗漏某些关键需求。 会给开发人员带来挫折，（使他们在不正确的假设前提下和极其有限的指导下工作）。 也会给客户带来烦恼（他们无法得到他们所设想的产品）。 重视需求分析的重要性，完成尽量详细的需求说明。 * 需求风险 忽略了用户分类。 多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同 。 忽略某一部分用户类的需求将导致众多客户的不满 。 不在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。 * 需求风险 不准确的计划。 对需求分析缺乏理解会导致过分乐观的估计，而当不可避免的超支发生时，会带来颇多麻烦。 通常未经准备的估计是作为一种猜测而给出的，听者却认为是一种承诺。 我们要尽力给出可达到预期的期望并坚持一贯如此。 * 需求风险 不准确的计划。 需求过程中软件成本估计极不准确的原因主要有以下五点： 频繁的需求变更； 遗漏的需求； 与用户交流不够； 质量低下的需求规格说明 不完善的需求分析 * 高质量的需求过程带来的好处 在开发后期和整个维护阶段的重做的工作大大减少了 。 让用户积极参与需求收集过程能使产品更富有吸引力，而且能建立起更加忠实的客户关系 。 用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟”（期望差异）。 将确定的系统需求明确地分配到各软件子系统，确保软硬件系统功能匹配适当。 有效的变更控制也能降低需求变更带来的负面影响 。 将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量 。 * 优秀需求说明的特征 正确性。 完整性。 无二义性。 必要性。 可行性。 划分优先级。 可验证性。 * 优秀需求说明的特征 正确性。 每一项需求都必须准确地陈述其要开发出的功能性。 只有用户代表才能确定用户需求的正确性，这就是为何一定要有用户的积极参与的原因。 没有用户参与的需求只是是评审者凭空猜测。 * 优秀需求说明的特征 完整性。 不能遗漏任何必要的需求信息。遗漏需求将很难查出。 每一项需求都必须将所要实现的功能描述清楚 。 开发人员可以从需求规格说明中获得设计和实现这些功能所需的所有必要信息。 * 优秀需求说明的特征 无二义性。 对所有需求说明的读者都只能有一个明确统一的解释。 尽量把每项需求用简洁明了的用户性的语言表达出来。 避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。 * 优秀需求说明的特征 必要性。 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。 “必要性”也可以理解为每项需求都是用来授权你编写文档的“根源” 。 要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。 * 优秀需求说明的特征 可行性。 每一项需求都必需是在已知系统和环境的权能和限制范围内可以实施的。 最好在获取需求过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他来负责技术可行性上的检查。 * 优秀需求说明的特征 划分优先级。 给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。 不划分优先级，将导致项目管理者在开发或节省预算或调度中就丧失控制自由度 。 * 优秀需求说明的特征 可验证性。 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。 如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。 一份前后矛盾，不可行或有二义性的需求也是不可验证的