软件需求工程的概念.ppt

软件需求工程的概念 * 软件需求工程的概念 * 63 * 需求开发 需求开发包括三个知识和实践要点: 1.需求获取 2.需求分析 3.需求定义 63 * 需求开发 需求开发可分为两个阶段：“用户需求调查阶段”和“产品需求定义阶段”，“需求分析”则贯穿于上述两个阶段。 需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（系统分析员） 63 * 需求管理 需求管理包括三个知识和实践要点 1.需求验证和确认 2.需求跟踪 3.需求变更控制 63 * 什么是需求管理 需求定义了系统必须具有的能力,一个项目的成功与否往往取决于它是否符合一系列的需求。因此,探讨需求的确切含义、把它们写下来、组织起来、跟踪它们的变更就显得非常有意义。 需求管理定义为:为系统的需求进行启发、组织、建档的系统方法,建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。 63 * 需求管理 任何曾经参与过复杂软件系统的人,无论是作为用户还是开发人员,都知道从用户和风险承担人那里获取需求的能力是非常关键的技能; 与一个系统相关的需求即使没有上千条,也至少有数百条,因此把它们合理地组织起来非常重要。 我们无法记忆太多的信息,因此为需求建档能够有效支持风险承担人之间的沟通。 必须把需求用可访问的介质来记录:文档,模型。 63 * 需求管理 需求管理与项目的大小和复杂度有关 两个人、十条需求的项目,不需要管理需求。但是,如果要验证一个有500-1000条需求的软件产品,我们就面临着必须对这些需求进行组织、划定优先级、控制对它们的访问以及为它们提供存储资源的问题。 可以把需求管理看成处理重要的复杂项目需求的一系列理有组织的、标准化的、系统化的过程和技术。 63 * 需求获取 需求分析 需求定义 需求验证 需求跟踪 设计编码测试 变更控制 需求开发 需求管理 软件需求工程的螺旋模型 63 * 过程活动的方法和技术 需求获取的方法和技术 发现(方法：角色、活动、资源、产品) 收集(方法：用例、流程图) 分类(方法：按活动、角色相关度) 评估(方法：风险、原因) 优先级(方法：重要性、价值) 文档(用户需求说明书) 需求分析的方法和技术 结构化分析方法和面向对象的基本方法(基于UML的用例分析技术) 63 * 过程活动的方法和技术 需求定义的方法和技术(需求规格说明书) 用例模型建模方法和用例补充规约说明 需求验证和确认的方法和技术 验证与评审和测试方法技术 需求跟踪的方法和技术 需求跟踪矩阵 需求变更控制的方法和技术 需求变更控制流程和变更控制委员会 63 * 需求与其他项目过程的联系 需求 构造 用户编 制文档 项目跟踪 和控制 制定项 目计划 系统测试 变更控制 状态 范围 基础 参考 估算 基线 63 * 需求工程描述 63 * 需求工程的用例 63 * 涉众 涉众是所有会受到项目结果重大影响的人。? 要有效地解决任何复杂的问题，就会涉及到满足不同涉众的需要。涉众通常会对问题持有不同的观点，因而必须用所提供的解决方案来满足不同的需要。 许多涉众都是系统的用户。其中许多涉众只是系统的间接用户，或者只受到系统所影响的业务结果的影响。还有许多涉众是系统的经济型买主或支持者。 了解涉众的组成及其特定需要是开发有效解决方案的关键。 63 * 风险承担者 风险承担者是高层需求的提出者，他们往往对需求细节不是很关心。 系统的主要功能产生的作用及效益是他们关心的重点。 注意系统风险承担者的宏观需求是有效解决问题的关键和项目成功的保证之一。 63 * 客户 客户有两种: 系统的操作者和维护者，他们对系统的界面、易使用性、易维护性、稳定性比较关心。 系统的用户，对系统的功能可以给他们带来的便利程度、舒适度、工作效率、工作满意度比较关心。 63 * 领域专家 领域专家具有丰富的业务领域经验，是系统业务流程、业务规则的提供者。 领域专家是业务建模的主要角色。 但是领域专家一般缺乏将业务模型转化为计算机逻辑模型的经验和能力。 具有领域经验和计算机建模经验的专家是非常少的，两者的结合是需求成功的保证。 63 * 变更控制经理 变更控制经理负责对变更控制过程进行监督。 此角色通常由配置（或变更）控制委员会 (CCB) 来担任，该委员会应该由有关各方（包括客户、开发人员和用户）的代表组成。 在小型项目中，项目经理或软件构架设计师一人即可承担此角色。 63 * 系统分析员 系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在哪些主角和用例，以及他们之间如何交互。 担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术