软件需求捕获.pptVIP

软件需求捕获 一、有关需求的基础知识 需求捕获在整个OOAD过程中的位置 软件需求的定义 IEEE的软件工程标准术语表（1990）将需求定义为： 用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。 该定义从反映系统外部行为的用户角度（第一点所述）和从反映系统内部特性的开发者角度（第二点所述）来阐述需求，重要的是编写相关文档（第三点所述）。 可以把需求理解为：软件系统或软件产品为向涉众提供价值而必须具备的特性。或者定义为： 需求是……对应该实现什么功能的说明——可以是对系统运行方式或系统特征与属性的描述；还可以是对系统开发过程的约束。 关于软件项目的涉众（stakeholder） 客户：为达到组织业务目标而投资项目或购买产品者。 用户：直接或间接与产品打交道者，通常是客户的一部分。 需求捕获人员：负责获取用户的需求并传达给开发团队的人员。 开发人员：需求分析、设计、实现和维护产品的人员。 测试人员：确定产品的行为是否与预计相一致的人员（验证者）。 项目经理：软件项目的管理者，负责项目的计划、组织、协调和控制。 市场营销、技术支持及其他与产品和客户打交道的人员。 需求的层次 有关需求的名词解释 业务需求（Business requirement）表示组织或客户高层次的目标。业务需求描述了组织为什么要开发一个系统。可用前景或范围（vision and scope）文档来记录。 用户需求（User requirement）描述的是用户的目标，或用户要求系统必须能够完成的任务。用户需求描述了用户能使用系统来做些什么。可用用例、场景描述或事件—响应表来记录。 功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也称作行为需求（behavioral requirement）。可用功能特性列表来表示。 系统需求（system requirement）用于描述包含多个子系统的产品（或系统）的顶级需求。系统可以只包含软件子系统，也可以既包含软件又包含硬件子系统，人也可以是系统中的一部分。 需求开发与管理 本PPT侧重于讲解需求开发的需求获取部分。 需求开发与需求管理的界线 软件客户的权利 1、要求需求调研和分析人员使用客户的语言。 2、要求需求调研和分析人员熟悉客户的业务，了解客户对系统的目标。 3、要求需求调研和分析人员把需求收集过程中客户提供的信息组织成书面的软件需求规格说明。 4、要求需求调研和分析人员解释需求过程生成的所有工作结果。 5、要求需求调研、分析人员和其他开发人员尊重客户，始终以合作和专业的态度与客户进行互动。 6、要求需求调研、分析人员和其他开发人员为需求和产品实现提供思路和备用方案。 7、要求开发人员实现能让产品使用起来更容易、更有趣的特性。 8、调整需求，便于重用已有的软件组件。 9、在提出需求变更时，获得对变更的成本、影响及二者权衡关系的真实评估。 10、获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意。 软件客户的义务 1、为需求调研、分析人员和开发人员讲解业务并定义业务术语。 2、提供需求，阐明需求，通过与开发人员的交互将需求充实完善。 3、对系统需求的描述必须详细、准确。 4、需要时，及时对需求做出决断。 5、尊重开发人员对需求成本和可行性的评估。 6、与开发人员协作，为功能需求、系统特性和用例设置优先级。 7、审阅需求文档，评估原型。 8、发现需要变更需求时，及时与开发人员沟通。 9、按照开发组织的变更控制过程提出需求变更。 10、尊重需求调研和分析人员在需求工程中使用的过程。 需求获取的主要活动 定义需求获取过程（如需求调研提纲）。 定义项目前景和范围。 确定用户群和他们的特点。 为每类用户选择用户代言人（外部的用户代表）。用户代言人必须一直参与项目的开发而且有权在用户需求方面作出决策。 建立典型用户的中心小组。中心小组与用户代言人不同，他们通常没有决策权。 与用户代表沟通以确定用例。 召开专门的需求获取讨论会。 观察用户工作的过程。 检查当前系统的问题报告来进一步完善需求。 跨项目重用需求。 需求开发是一个迭代过程 不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。实际上，这些活动是交叉的、递增的和反复的。 需求获取人员的职责 需求获取人员是对项目涉众的需求进行收集、记录和验证等职责的主要承担者。 需求获取人员是一种项目角色，而不是职务头衔。这个角色可由一个或多个人员专任，也可由同时担负其他职责的团队成员兼任，如项目经理、开发