高质量软件需求的分析.pptVIP

求职应注意的礼仪 求职时最礼貌的修饰是淡妆 面试时最关键的神情是郑重 无论站还是坐，不能摇动和抖动 对话时目光不能游弋不定 要控制小动作 不要为掩饰紧张情绪而散淡 最优雅的礼仪修养是体现自然 以一种修养面对两种结果 必须首先学会面对的一种结果----被拒绝 仍然感谢这次机会，因为被拒绝是面试后的两种结果之一。 被拒绝是招聘单位对我们综合考虑的结果，因为我们最关心的是自己什么地方与用人要求不一致，而不仅仅是面试中的表现。 不要欺骗自己，说“我本来就不想去”等等。 认真考虑是否有必要再做努力。 必须学会欣然面对的一种结果----被接纳 以具体的形式感谢招聘单位的接纳，如邮件、短信 考虑怎样使自己的知识能力更适应工作需要 把走进工作岗位当作职业生涯的重要的第一步，认真思考如何为以后的发展开好头。 Thank you * * * * * * * * * * * * * Zhu.Kerry@ 作者 高质量的软件需求管理 1 需求分析的概念 2 需求的获取与分析 3 需求分析建模 4 系统需求的质量保证 * * 1 需求分析的概念 1.1软件系统的构建层次 1.2软件需求工程过程 * * 1.1软件系统的构建层次 * * 软件系统需求的层次 * * 软件需求工程 所有与需求直接相关的活动统称为需求工程，需求工程分为了两个部分：需求开发和需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪 软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。 * * 软件需求工程 业务需求（business requirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。 用户需求(user requirement) 文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（user case）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。 功能需求(functional requirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。 * * 2 需求的获取与分析 2.1需求获取 2.2需求分析 2.3需求的传递 * * 需求获取 项目视图及范围文档 业务需求确定项目视图（图13-2）。通过对业务需求的收集（问题域的研究），项目的业务需求在范围上形成文档。 系统关联图 绘制系统关联图，是用于定义系统与系统外部实体间的界限和接口的简单模型。 用户需求获取 便利的应用规约技术 便利的应用规约技术鼓励建立客户和开发者的联合团队。他们一起工作以标识问题、提出解决方案的元素、谈判不同的方法以及刻画初步的解决方案的需求集合。 * * 需求获取的方法 需求研讨会 头脑风暴 用例模型 访谈 角色扮演 原型法 * * 产品功能说明书 产品功能说明书 开发小组 客户 准确的需求传递——软件的产品功能说明书作为需求开发的成果，它和最终解决方案的质量密切相关（它将用户需求和需求分析结果传递给实现人员）。 * * 3需求分析建模 3.1 结构化分析建模 3.2 面向对象的分析建模 3.3 敏捷建模 * * 需求分析建模 1. 结构化分析建模 * * 需求分析模型 2.面向对象的分析建模 诱导系统的客户需求； 标识场景或用例（use case）； 使用基本需求来确定类和对象； 为每个系统对象表示属性和操作； 定义组织类的结构和层次； 建造对象-关系模型； 建造对象-行为模型； 依据use-case/场景来评审OOA模型。 * * 需求分析建模 3.敏捷建模 * * 4 系统需求的质量保证 4.1 需求确认 4.2 需求管理 * * 需求评审 需求说明书的标准 正确性 完备性 易理解性 一致性 可行性 健壮性 易修改性 易测试性和可修改性 易追溯性 兼容性 * * 需求评审方法 1. 分层次评审 目标性评审 功能性评审 操作性评审 2. 分阶段评审 * * 需求管理 1. 需求的标识 需求类型需求# 需求类型可以是：F=功能需求，D=数据需求，B=行为需求，I=接口需求；O=输出需求。