第4章 软件过程的需求管理.pptVIP

软件过程管理 -Ch.4 软件过程的需求管理 软件过程的需求管理 开发软件系统最为困难的部分就是准确说明开发什么。 ——弗雷德里克·布鲁克斯 软件需求工程 软件需求工程 需求开发 需求获取概述 需求获取的方法 需求研讨会 头脑风暴 用例模型 访谈 角色扮演 原型法 基于用例的需求获取 课堂案例：学生学籍处理业务 学生学籍处理业务 每学期开学时，各学办进行注册管理，注册信息记录在在校生信息卡中。 学生转专业由本人向所在系提出申请，教务处审批。 在本系内转专业，由学生所在系考核同意，报教务处审批； 在学校范围内转专业（跨系），由学生所在系推荐，拟转入系考核同意，报教务处审批。 转专业手续应在每学年开学前办理。 课堂案例：学生学籍处理业务 需求定义 需求定义指的是解释涉众需求,并根据需求规模整理成对要构建系统的明确的说明。 前景文档是用一般的语言定义系统特征的文档 软件需求规格说明书是用更专业的术语定义系统特征的文档。 软件需求规格说明书 4. 产品的功能需求 需求确认 为什么需要需求评审？ 需求确认 如何进行需求评审？ （1）分层次评审 目标性评审 功能性评审 操作性评审 （2）分阶段评审 需求确认 如何保证需求规格说明书的质量？ 正确性 完备性 易理解性 一致性 可行性 健壮性 易修改性 易测试性和可修改性 易追溯性 兼容性 需求跟踪 1. 需求的标识 需求类型需求# 需求类型可以是：F=功能需求，D=数据需求，B=行为需求，I=接口需求；O=输出需求。 需求跟踪 2. 需求的属性 创建需求的时间 需求的版本号 创建需求的作者 负责认可该需求的人员 需求状态 需求的原因或根据（或信息的出处） 需求涉及的子系统 需求涉及的产品版本号 …… 需求跟踪 3. 需求状态 已建议——该需求已被有权提出需求的人建议 已批准——该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已有一个确定的产品版本号或编号，软件开发团队已同意实现该项需求 已实现——使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成 已删除——计划的需求已被删除，并包含一个原因说明和作出删除决定的人员 需求跟踪 正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。 逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。 正向跟踪和逆向跟踪合称为“双向跟踪”。 需求变更控制流程 需求变更控制策略 （1）项目启动阶段的变更预防 （2）项目实施阶段的需求变更 （3）项目收尾阶段的总结 作业 Q A * Zhu.Kerry@ * Zhu.Kerry@ 作者 所有与需求直接相关的活动统称为需求工程，需求工程分为了两个部分：需求开发和需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪 软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。 业务需求（business requirement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。 用户需求(user requirement) 文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（user case）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。 功能需求(functional requirement)定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 获取数据 分析、处理 目标系统模型 需求获取 系统分析员 从数据流和数据结构出发，找出系统各元素之间的联系、接口特征及设计限制、能否满足功能需求 需求获取是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。 某个执行者要求系统为其提供什么功能？该执行者需要做哪些工作？