Zhu.Kerry@gmail.com作者软件过程管理-Ch4软件过程的需求管理Zhu.Kerry@gmail.com软件过程的需求管理开发软件系统最为困难的部分就是准确说明开发什么。——弗雷德里克·布鲁克斯Zhu.Kerry@gmail.com软件需求工程所有与需求直接相关的活动统称为需求工程,需求工程分为了两个部分:需求开发和需求管理。其中,需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分,而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪软件需求包括三个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求)。Zhu.Kerry@gmail.com软件需求工程业务需求(businessrequirement)反映了组织机构或客户对系统、产品的概括的目标要求,它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估,得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。用户需求(userrequirement)文档描述了用户使用系统而完成的任务的集合,用户需求在用户案例(usercase)文档或方案脚本中予以说明。收集和分析用户需求是不容易的,因为很多需求是隐形的,很难获取,更难保证需求完整,而需求又是易变的,这就要求用户和开发人员进行充分地交流。功能需求(functionalrequirement)定义了开发人员必须实现的软件功能,它源于用户需求。功能需求是软件需求说明书中最重要的部分之一,它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等,包括要遵从的业务规则、人机接口、安全性和可靠性等要求。Zhu.Kerry@gmail.com需求开发需求开发的目的是通过调查与分析,获取用户需求并定义产品需求。获取数据分析、处理目标系统模型需求获取系统分析员从数据流和数据结构出发,找出系统各元素之间的联系、接口特征及设计限制、能否满足功能需求Zhu.Kerry@gmail.com需求获取概述需求获取是通过各种途径获取用户的需求信息(原始材料),产生《用户需求说明书》。Zhu.Kerry@gmail.com需求获取的方法需求研讨会头脑风暴用例模型访谈角色扮演原型法Zhu.Kerry@gmail.com基于用例的需求获取执行者的识别谁使用系统的主要功能?谁将提供、使用和删除信息?谁负责维护、管理并保持系统正常运行?谁会对某一特定需求感兴趣?系统的外部资源是什么?系统需要和哪些外部系统交互?用例的识别某个执行者要求系统为其提供什么功能?该执行者需要做哪些工作?执行者需要阅读、创建、销毁、更新或存储系统中哪些(类)信息?系统中的事件一定要告之执行者吗?执行者需要告诉系统一些什么吗?那些系统内部的事件从功能的角度代表什么?由于新功能的识别,执行者的日常工作被简化或效率提高了吗?系统需要什么样的输入输出?输入在哪里?输出去往哪里?该系统的当前情况存在哪些问题?Zhu.Kerry@gmail.com课堂案例:学生学籍处理业务学生学籍处理业务每学期开学时,各学办进行注册管理,注册信息记录在在校生信息卡中。学生转专业由本人向所在系提出申请,教务处审批。在本系内转专业,由学生所在系考核同意,报教务处审批;在学校范围内转专业(跨系),由学生所在系推荐,拟转入系考核同意,报教务处审批。转专业手续应在每学年开学前办理。Zhu.Kerry@gmail.com课堂案例:学生学籍处理业务学生本系内转专业申请学办教务处转入系学生处在校生信息卡片转出系注册名单统计表学籍变动通知跨系转专业申请本系内转专业申请跨系转专业申请跨系转专业申请学生学办各类统计表初步审查学生申请审批审核审核推荐注册查询统计Zhu.Kerry@gmail.com需求定义需求定义指的是解释涉众需求,并根据需求规模整理成对要构建系统的明确的说明。前景文档是用一般的语言定义系统特征的文档软件需求规格说明书是用更专业的术语定义系统特征的文档。Zhu.Kerry@gmail.com软件需求规格说明书0.文档介绍0.1文档目的0.2文档范围0.3读者对象0.4参考文档0.5术语与缩写解释1.产品介绍提示:(1)说明产品是什么,什么用途;(2)介绍产品的开发背景。2.产品面向的用户群体提示:(1)描述本产品面向的用户(客户、最终用户)的特征;(2)说明本产品将给他们带来什么好处?特们选择本产品的可能性有多大?3.产品应当遵循的标准或规范提示:阐述本产品应当遵循什么标准、规范或业务规则。Zhu.Kerry@gmail.com4.产品的功能需求……FunctionC.1FeatureC……FunctionB.1FeatureB……FunctionA.1FeatureA描述功能名称、标识符功能类别5.产品的非功能需求质量需求软硬件需求用户界面需求描述需求名称、标识符需求类别6.其他需求软件需求规格说明书Zhu.Kerry@gmail.com需求确认为什么需要需求评审?在哪个阶段发现成本率需求1设计3-6编码10功能测试15-40验收测试30-70发布之后40-1000修订一个缺陷的相关成本Zhu.Kerry@gmail.com需求确认如何进行需求评审?(1)分层次评审目标性评审功能性评审操作性评审(2)分阶段评审Zhu.Kerry@gmail.com需求确认如何保证需求规格说明书的质量?正确性完备性易理解性一致性可行性健壮性易修改性易测试性和可修改性易追溯性兼容性Zhu.Kerry@gmail.com需求跟踪1.需求的标识需求类型需求#需求类型可以是:F=功能需求,D=数据需求,B=行为需求,I=接口需求;O=输出需求。例:需求标识为F03的需求表示编号为3的功能需求。Zhu.Kerry@gmail.com需求跟踪2.需求的属性创建需求的时间需求的版本号创建需求的作者负责认可该需求的人员需求状态需求的原因或根据(或信息的出处)需求涉及的子系统需求涉及的产品版本号……Zhu.Kerry@gmail.com需求跟踪3.需求状态已建议——该需求已被有权提出需求的人建议已批准——该需求已被分析,估计了其对项目余下部分的影响(包括成本和对项目其余部分的干扰),已有一个确定的产品版本号或编号,软件开发团队已同意实现该项需求已实现——使用所选择的方法已验证了实现的需求,例如测试和检测,审查该需求跟踪与测试用例相符。该需求现在被认为完成已删除——计划的需求已被删除,并包含一个原因说明和作出删除决定的人员Zhu.Kerry@gmail.com需求跟踪正向跟踪:以用户需求为切入点,检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。逆向跟踪:检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪”。Zhu.Kerry@gmail.com需求变更控制流程需求的变更是不可避免的,因此如何有效控制需求的变化对于项目成功至关重要。Zhu.Kerry@gmail.com需求变更控制策略(1)项目启动阶段的变更预防(2)项目实施阶段的需求变更(3)项目收尾阶段的总结Zhu.Kerry@gmail.com作业第4章2、4Zhu.Kerry@gmail.comQ&A