软件需求基础知识教案.docVIP

《软件需求（第2版）》教案 目录 1 软件需求基础知识 2 1.1 软件需求的定义 2 1.1.1 对需求的不同解释 3 1.1.2 需求的层次 3 1.1.3 不属于需求的内容 6 1.2 需求的开发与管理 6 1.2.1 需求开发 6 1.2.2 需求管理 7 1.3 所有项目都有需求 8 1.4 优秀的团队遇到糟糕的需求 8 1.4.1 用户参与不足 9 1.4.2 用户需求扩展 9 1.4.3 有歧义的需求 10 1.4.4 镀金问题 10 1.4.5 过于抽象的需求 10 1.4.6 忽略了某类用户 10 1.4.7 不准确的计划 10 1.5 优质需求过程的好处 11 1.6 优秀需求的特点 11 1.6.1 需求陈述的特点 11 1.6.2 需求规格说明的特点 13  软件需求基础知识 章首案例的概括总结见课件。 本章要点： （1）需求的重要性 软件问题主要在于需求：许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当。包括信息收集方式不正规，没有明确提出想要的功能，连假设也是未经沟通的错误假设，需求的定义不够充分，以及未经仔细考虑进行需求变更等。 需求问题造成很大的麻烦：软件项目中40%～60%的缺陷都是由需求分析阶段的过失所致。 需求问题，一是轻视，而是不得方法：许多组织仍然没有采取有效手段来实施这两个必要的项目活动。由此导致的结果是用户和开发者之间产生需求的鸿沟。 （2）软件项目知识——项目涉众 客户：为达到其公司的业务目标而投资项目或购买产品。 用户：直接或间接与产品打交道，是客户的一部分。 需求分析员：负责编写需求并传达给开发团队。 开发人员：设计、实现和维护产品。 测试人员：确定产品的行为是否与预计的相一致。 文档编制人员：负责编写用户手册、培训资料和系统帮助。 项目经理：制定项目计划并带领开发人员获得成功。 法律人员：确保产品符合所有相关法规。 生产人员：制造包含该软件的产品。 市场营销、技术支持及其它与产品和客户打交道的人员。 理解涉众，关键在于“只有涉众承诺遵循有效的需求过程，才能为软件开发和项目管理活动奠定基础。 本章讲授内容： 软件需求工程的一些重要术语。 需求开发与需求管理。 注意潜在的与需求相关的问题。 完善的需求应该具备哪些特征。 软件需求的定义 术语混乱： 用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。 一般的误解: 开发人员——看到客户对需求说法，认为只是高级别的产品概念； 用户——看到的开发人员的需求描述，认为是用户界面设计。 需求定义，即用文字进行规范地、正确地、完整地描述。需求必须被记录成文档。 对需求的不同解释 需求的几种定义，都很有参考价值。 咨询专家Brian Lawrcnce提出，需求是“任何促成设计决策的因素”。很多信息都属于这一范围。 IEEE的软件工程标准术语表（199⑴则将需求定义为： 用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。 作者对需求的理解：需求是产品为向涉众提供价值而必须具备的特性。 需求类型的多样性（Sommerville和Sawyer 1997）：需求是……对应该实现什么功能的说明——可以是对系统运行方式或系统特征与属性的描述；还可能是对系统开发过程的约束。 需求的层次 本节的内容十分重要。——需求工程领域一些常用术语的定义。 软件需求包括3个不同的层次： 业务需求 用户需求 功能需求 。除此之外，每个系统还有各种非功能需求。 重要：图1-1中的模型给出了各种需求关系的示意图。 图中的椭圆代表各类需求信息，矩形则是存储这些信息的载体（文档、图形或数据库）。  图1-1 各种需求的关系图 注：第7章中介绍了各种需求的示例。 三大需求 业务需求（Business requirement）——表示组织或客户高层次的目标。 业务需求通常来自项目的投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。 业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。 本书规定用前景和范围（vision and scope）文档来记录业务需求。见第5章的主题（作为实验3内容）。 任务是：定义项目范围（随后会发生如何控制范围扩大的问题）。 2.用户需求（user requirement）——描述的是用户的目标，或用户要求系统必须能完成的任务。 用户需求描述的是软件使用者（用户）使用系统能够完成什么业务任务或信息处理工作。 具体内容是用例、场景描述和事件-响应表等。见第8章（作为实验4）。 3.功能需求（functional requirement）——规