第三章 需求工程.ppt

第三章 需求工程 需求工程是当前软件工程中的关键问题，从客观意义上说，需求工程面对的问题几乎是没有范围的。由于应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。其客观上的难度还体现在非功能性需求及其与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏大大增加了需求工程的复杂性。从主观意义上说，需求工程需要方方面面人员的参与（如领域专家、领域用户、系统投资人、系统分析员、需求分析员等等），各方面人员有不同的着眼点和不同的知识背景，沟通上的困难给需求工程的实施增加了人为的难度。 3.1 软件需求 软件需求的定义 需求的层次 需求错误的原因 3.1.1软件需求的定义 IEEE软件工程标准词汇表（1997年）将需求定义为：　　（1）用户解决问题或达到目标所需的条件或能力；　　（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。　　（3）一种反映（1）或（2）所描述的条件或能力的文档说明。 3.1.1软件需求的定义 另外，以下列出其他几种关于“需求”的定义： 需求是用户所需要的并能触发一个程序或系统开发工作的说明； 需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等； 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 3.1.2需求的层次 3.1.2需求的层次 业务需求（business requirement）反映了组织机构或客户对系统或产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求（user requirement）描述了用户使用产品必须要完成的任务，可以在用例模型或方案脚本中予以说明。 功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 非功能需求（non-functional requirement）是从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求。非功能需求包括过程需求、产品需求和外部需求三类，其中过程需求有交付、实现方法和标准等需求，产品需求包括性能、可用性、实用性、可靠性、可移植性、安全必威体育官网网址性、容错性等方面的需求，外部需求有法规、成本、操作性等需求。 3.1.3需求错误的原因 1.缺乏足够的用户参与 2.用户需求不断增加 3.需求模棱两可 4.添加不必要的特性 5.规格说明过于简单 6.忽略了用户分类 3.2 需求工程 需求工程是指应用已证实有效的原理和方法，系统地描述出待开发系统及其行为特征和相关约束。通常，需求工程由一些过程组成，可分为需求开发和需求管理两部分，而需求开发又可进一步分为问题获取、分析、编写规格说明和验证四个阶段，如下图所示： 3.2.1 需求工程的内容 1.需求开发的主要活动 确定产品所期望的用户类； 获取每个用户类的需求； 了解实际用户任务和目标以及这些任务所支持的业务需求； 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息； 将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件； 了解相关质量属性的重要性； 商讨实施优先级的划分； 将所收集的用户需求编写成规格说明和模型； 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 3.2.1 需求工程的内容 2 需求管理的主要活动 定义需求基线； 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它； 以一种可控制的方式将需求变更融入到项目中； 使当前的项目计划与需求一致； 估计变更需求所产生影响并在此基础上协商新的承诺； 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪； 在整个项目过程中跟踪需求状态及其变更情况。 3.2.2 需求获取 1 工作内容 聆听用户的需求 分析和整理所获取的信息 文档化的描述 3.2.2 需求获取 2 基于用例的方法 确定角色 确定用例 描述用例 3.2.3 需求分析 需求分析的主要活动包括： 绘制系统关联图 创建用户接口原型 分析需求可行性 确定需求的优先级别 为需求建立模型 创建数据字典 3.2.4 需求传递 需求传递的主要任务是书写软件需求规格说明，其目的是： 传达对需求的理解； 作为软件开发项目的一份契约； 作为评价后续工作的基线； 作为控制需求进化的基线。 编写软件需求规格说明有三种方法： 将结构化语言与自然语言结合，编写文本型文档； 建立可视化的模型； 采用形式化的方法进行需求规格说明，如Z模式、Petri Net等 3.2.5需求验证 1 需