需求分析及需求管理工具介绍.docx
- 文档编号:344088
- 上传时间:2022-10-09
- 格式:DOCX
- 页数:15
- 大小:99.39KB
需求分析及需求管理工具介绍.docx
《需求分析及需求管理工具介绍.docx》由会员分享,可在线阅读,更多相关《需求分析及需求管理工具介绍.docx(15页珍藏版)》请在冰豆网上搜索。
需求工程及需求管理工具介绍
V1.0
MarcoLee
2012-09-04
Contents
一、需求工程综述 3
1)需求定义 3
2)需求工程概述 3
3)需求工程主要过程 4
4)需求分析的特点 4
5)需求开发的十种常用方法 5
6)需求建模方法 5
7)主要概念区分 6
1、项目范围管理 6
2、需求开发、需求管理、项目范围管理的区别和联系 7
二、CMMI需求开发过程 7
1)基本概念 7
2)需求调查方法 8
3)CMMI需求分析过程 9
三、需求管理工具介绍 12
1)RationalRequisitePro 12
2)IBMRationalDOORS 12
3)BorlandCaliberRM 14
4)CloudtopoTopo 14
摘要
需求是研发团队工作的起点,很多研发团队的开发过程混乱的源头都在于需求管理没有做好。
项目失败或严重超支的八个最重要原因中有五个都与需求相关:
1)不完整的需求;
2)缺乏用户的参与;
3)不实际的客户期望;
4)需求和需求规格说明的变更;
5)提供许多不必要的功能。
本文就有关需要的概念以及主流需求管理系统,进行了论述。
一、需求工程综述
图1-需求分析组成部分
1)需求定义
通俗的讲,“需求”就是用户的需要,它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件,它是一个程序或系统开发工作的说明,表现形式一般为文档形式。
按CMMI软件能力成熟度的定义,需求是开发方和客户方就系统未来所达到的功能和质量所达成的一致约定和协议。
PMP定义,需求是指发起人、客户和其它干系人的已量化且记录下来的需要与期望。
收集需求旨在定义和管理客户期望。
2)需求工程概述
需求工程过程——即需求分析活动,以下统称为需求工程——在整个系统开发与维护过程中越来越重要,它贯穿于系统开发的整个生存周期。
上个世纪80年代中期,形成了软件工程的子领域——需求工程(RequirementEngineering,RE)。
需求工程,是应用已证实有效的技术、方法进行需求分析,确定需求客户,帮助系统开发分析人员理解问题,评估可行性,协商合理的解决方案、无歧义地规约方案、确认规约以及将规约转换到可运行的系统时的管理要求。
需求工程通过合适的工具和符号系统地描述待开发系统及其行为特征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持。
需求工程是一个项目的开端,也是项目建设的基石。
需求工程的过程包括了需求开发和需求管理两个部分。
整体需求工程过程在项目启动后开始,进行需求获取、分析、规划定义和需求验证,并进行组织内外的需求评审,以确定需求基线,并在需求发生变更时,重新进行需求的获取、分析、定义和验证评审,并对需求变更影响项进行相关识别、风险应对、修改和跟踪,并对需求状态和变化过程进行统计分析和测量汇报。
需求开发(RD,RequirementDevelopment)指的是从问题收集、分析和评价到编写文档、评审等一系列产生需求的活动,这几个阶段的活动可以是相互独立和反复的,不一定非要遵循线性的顺序。
需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。
需求管理(RM,RequirementManagement)则是与需求直接相关的活动,即软件项目开发过程中控制和维持需求约定的活动,主要包括:
变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求管理强调的是需求的确认以及需求变更的控制,其目的是确保各方对需求的一致理解,管理和控制需求的变更,从需求到最终产品的双向跟踪。
3)需求工程主要过程
1)需求开发规程:
分为需求获取、需求分析、规格化定义和需求验证等操作过程。
2)需求评审规程:
对完成的系统需求进行组织内外评审的过程;
3)需求变更管理规程:
需求基线产生后对需求进行变更管理的过程;
4)需求跟踪管理规程:
对需求进行状态跟踪和过程跟踪的管理过程;
5)需求的测量和分析:
对需求状态和需求变化过程进行测量和分析评估的管理过程;
4)需求分析的特点
需求分析工作的复杂性及面临的潜在风险主要体现在以下方面:
1)需求描述的准确性问题;
2)需求的完备程度问题;
3)需求开发的时间问题;
4)需求的细化程度问题;
5)需求的变更问题。
5)需求开发的十种常用方法
1)需求调查:
采用需求调查表进行需求收集和调查;
2)需求访谈:
进行面对面的需求访谈、记录、整理并确认;
3)资料收集和文档考古:
收集业主方的有关资料进行分析提炼;
4)需求研讨:
召开需求研讨会有目的的对需求进行研讨;
5)需求头脑风暴:
发散式的对需求进行遐想和探索;
6)需求原型:
依据需求原型进行需求沟通和探索,是电子政务行业常用的需求开发方法;
7)实地学习:
实地深入业主方业务现场进行观摩学习,以提炼需求;
8)实务跟踪/实地工作:
更加深入的跟踪现场多个实物,甚至深入业主方现场进行实地、实务长时间、多案例的实地工作;
9)案例讲述和故事板:
通过对案例或故事的讲解和分析获取需求;
10)场景模拟/角色扮演:
通过模拟一个场景或者由不同人员扮演不同的角色进行需求模拟和角色分析,来获取需求。
6)需求建模方法
需求建模是软件需求工程过程的重要阶段。
不同的需求建模方法蕴含了不同的建模理念,代表了看待软件系统的不同视角。
1、结构化需求分析方法
自20世纪70年代中期以来,结构化的需求建模方法一直是比较流行和普及的需求建模技术之一。
它认为系统的功能就是“数据”流经系统时发生变迁的能力,同时需要外部事件触发进行完成变迁的过程。
2、面向对象的需求分析方法
面向对象的需求建模方法是当今工业界的主流方法,它认为现实系统是由各种各样的现实“对象”组成,对象可以被分类、被描述、被组织、被操作、被创建,系统是要实现对现实世界实体(对象)的计算,需要在系统中建立这些实体的映像,这些实体的个体操作模型和交互模型就是系统的功能模型。
面向对象的需求建模方法的关键是从获取的需求信息中识别出问题域中的类与对象,并分析它们之间的关系,最终建立起简洁、精确和易理解的需求模型。
UML是随着面向对象方法发展起来的统一建模语言,包括用来表示系统静态结构的用例图、类图等,以及表示系统动态结构的状态图、活动图、序列图、协作图和配置图等。
3、面向问题域的需求分析方法
上述两种传统方法都只是针对软件系统本身的建模方法,并没有涉及软件需求从哪里来、客户存在什么问题需要解决、为什么客户会期望或者需要软件来帮助它们解决这些问题、他们需要软件帮他们做什么等问题。
20世纪90年代之后,提出在进行软件系统建模之前,需要对软件将处于的环境,即软件将要解决的现实世界的问题进行建模,需要对包含软件及其环境的软件加强型系统进行建模,这样才能识别出或者推导出人们对软件的真正需求。
面向问题域(ProblemDomain,PD)的需求分析方法(ProblemDomain-OrientedAnalysis,PDOA)是由M·Jackson和P.Zave等人提出的一种需求分析方法。
与传统的结构化需求分析方法和面向对象需求分析方法相比显著不同,其本质在于从待求解问题的角度,考虑待开发的软件系统将在与待求解问题相关的域内产生的效果。
面向问题域建模的核心是问题框架。
问题框架方法认为,软件系统对现实世界的作用是软件问题的来源,对软件系统将与现实世界发生的作用进行结构化分析是需求分析的切入点。
问题框架方法强调需要对软件系统将要作用的客观现实世界进行刻画,并将需求的含义指称(映射)到对现实世界相关领域的描述上。
其建模的基本概念是现实世界中的领域以及未来软件系统与领域的交互。
问题框架方法定义了一些常见的软件问题类型,称为问题框架。
问题框架方法的基本思想就是在问题分析中使用问题框架,将复杂的现实世界软件问题结构化为相互作用的可以匹配到问题框架的子问题的集合。
基于问题框架方法进行需求建模,其第1类概念是现实世界中的领域和未来软件系统与领域的交互。
它认为,系统的功能体现在未来软件系统与现实世界领域的交互下产生的对现实世界领域的作用效果。
在问题框架方法中,用机器领域显式地表示了要创建的软件系统。
用问题领域建模现实世界领域,严格区分了问题领域和机器领域,由此确定了问题的边界,却又不涉及任何关于机器领域的细节描述。
由此避免过早进入问题的解决方案。
它强调在关注解决方案之前关注问题本身,尽可能地识别出关键的困难并尽早地加以解决。
这是它与其他需求工程方法的根本区别。
7)主要概念区分
1、项目范围管理
项目范围管理,包括为成功完成项目所需要的一系列过程,以确保项目包含且仅仅只包含项目所必须完成的工作。
范围管理首先要定义和控制在项目内包括什么、不包括什么。
一般来说,范围分为产品范围和项目范围:
1)产品范围是指表示产品或服务的特性和功能。
2)项目范围是指为了完成具有所规定特征和功能的产品必须完成的工作(需求定义)。
项目范围是否完成以项目管理计划作为衡量标准,而产品范围是否完成以产品需求作为衡量标准。
两种范围管理需要很好地集成起来,以确保项目工作能产生所规定的产品并准时交付。
2、需求开发、需求管理、项目范围管理的区别和联系
主要如下:
1)首先通过需求开发来获取项目的需求,在此基础上确定项目的范围,进行项目范围管理。
2)对于项目需求,可以根据需求的紧急重要程度、项目本身和项目双方的实际情况,分步或分期满足。
确定每期应满足的需求后,本期的范围管理就有了基础。
3)需求管理处理需求的变更,需求的变更同时会引起项目范围的变更。
二、CMMI需求开发过程
1)基本概念
CMMI提出了需求开发--RD,要理解好RDPA(ProcessArea,过程域),需要先理解清楚以下几个关键的概念:
·客户需求(CustomerRequirements):
客户需求可以理解成客户为什么要做本系统,要解决什么问题,客户对系统有怎样的期望,希望能具备一些怎样的特点,简单的说,就是客户的需求是什么(通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述)。
·产品需求(ProductRequirements):
产品需求是能满足客户需求,并对软件产品规格进行了详细描述的需求,软件设计师可以根据产品需求进行设计、编码等工作。
·产品组件需求(ProductComponentRequirements):
产品组件需求是对产品需求的进一步细化,产品可能会分割成几个子系统、几个部分,每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等,这些可以认为是产品组件需求。
图2-需求间的层次关系
从另外一个角度,需求可以分为功能性需求和非功能性需求两类。
功能性需求就是系统具备怎样的功能,能做什么事情,而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。
软件需求分为三大部分:
·功能需求:
指系统需要完成那些事情,即向用户提供那些功能。
·非功能需求:
指产品所具备的品质和属性,比如可靠性、扩展性、响应时间、性能等
·设计约束与限制:
也称条件约束、补充规则。
比如用户要安装该产品他需要有什么样的必备条件。
(系统对操作系统的要求、硬件环境的要求等)
客户需求、产品需求和产品组件需求,都会包含功能需求和非功能需求。
2)需求调查方法
需求调查与问题定义,在做需求调查时需要做到2W1H即What、Where、How
·What-----应该收集什么信息
·Where----从什么地方收集
·How-------用什么机制或技
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 分析 管理工具 介绍