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

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