需求分析师培训教材课件

需求分析师培训Day03需求分析师培训Day031Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结Agenda需求建模实例2Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结Agenda需求建模实例3需求建模实例—确定业务需求总经理：为什么我们的开发项目进度计划总是那么不准确，延期经常出现，更可恨的是甚至无法给出一个相对比较明确的延迟时间。这样给市场的推广会带来很大的影响，不确定因素使得应对十分困难。研发经理：唉这个问题我花了很多时间来解决，但一直收效不好。最初我用WBS方法，根据用例包、用例的方式来组织需求，然后将某个用例或子用例作为工作任务分配的开发人员，并指定了相应的完成时间，但到了时间开发人员总是完不成，都反应时间安排不合理。后来，在技术顾问的指导下，改为自底向上的估计方法，任务明确后让开发人员反馈工作量及所需的工作天数。虽然有所好转，但还是有一些工作任务，开发人员反馈的天数到了，仍然无法完成，甚至无法告诉我要延迟多少天。汇总起来，就形成了这样的结果了。总经理：这样呀，那有什么好办法呢？技术顾问：其实问题的关键还是在于“估算”的经验上，对于软件开发而言，实际上没有万能的、准确的估算公式…

需求建模实例—确定业务需求总经理：为什么我们4需求建模实例—确定业务需求（研发经理抢过话题）研发经理：对对对！我一直在尝试使用FP、COCOMO模型来，仍然得

不出合理的估计值，真难办。技术顾问：呵呵，急了！其实估算的基础是经验数据，对于不同的开发人员而言其产能是不一致的，甚至对于相同的开发人员而言，不同的任务所需的时间也是不同的。因此关键在于积累这种经验数据。例如，我在编写技术书籍时，就采用了PSP（个人软件开发过程）的思路，对所有的工作过程进行了时间的记录，在半年之后，就积累了许多相关的产能数据，现在给编辑的时间承诺总是能够比较的准确。总经理：哦，难怪你做的承诺都一般很少延误，这种经验能否适用于软件开发的管理呢？技术顾问：呵呵，这是当然。PSP是个人软件开发过程，它本来就是为软件开发设计。它是CMM的创始人提出的，PSP、TSP和CMM分别针对软件开发员、软件开发小组和软件开发组织。通过PSP的贯彻，就一定能够提高软件开发人员的时间安排、时间估算的能力。

需求建模实例—确定业务需求（研发经理抢过话题）5需求建模实例—确定业务需求研发经理&总经理（几乎同时）：那我们就尝试一下！技术顾问：哈哈，不过贯彻PSP有两个困难。一是开发人员很难适

应，每天都要记录自己的工作时间很繁琐，而且产生数据不容易使用；

二是时间日志做出来后，管理者会忍不住用来考核开发人员，给他们带

来心理压力。研发经理：那我们可以开发一套软件来帮助他们记录，通过写到数

据库中，这样数据的使用问题也就解决了。技术顾问：对，这就是我的建议。那后者呢？总经理：我们不考核就是了！技术顾问：没那么简单！我认为要从以下几点来进行：一是鼓励，鼓励记录时间日志，奖励估算准确的开发人员，从而避免做假时间的情况；二是宣扬，宣扬有效工作时间的概念，我的经验是每个开发人员一天有效的工作时间在4个小时之上就是比较好的，树立这种概念能够打消开发人员的顾虑；三是培训，从理论高度建立开发人员执行PSP的意识。

需求建模实例—确定业务需求研发经理&总经理（6需求建模实例—确定业务需求总经理：好！我修订绩效考核，解决鼓励问题；小陈(研发经理)，我配合你树立“每天有效工作4小时”的概念；至于培训嘛只好拜托你了。技术顾问：好！没问题。为开发人员提供一个PSP工具，简化时间记录工作；同时提供数据使用的工具，帮助开发人提高估算能力。需求建模实例—确定业务需求总经理：好！我修订绩效考核7需求捕获技术顾问：根据我的经验，整个系统应该包括以下几个主要的方面。第一，项目及任务安排，由研发经理或项目经理创建项目和任务，开发人员在接到任务后进行估算填写时间计划，研发经理或项目经理对其进行确认。第二，时间记录，开发人员对自己的开发时间进行记录，与任务关联起来。第三，产能分析，研发经理及公司领导可以根据任务和相应的时间记录，来统计公司员工的产能数据。开发人员甲：我认为，开发人员自己应该能够通过这套系统来统计自己的产能数据。研发经理：那么产能数据怎么表示呢？任务可是不同的呀。技术顾问：我认为比较合适是KLOC/天(每天编写的千代码行数)。开发人员乙：但不同的程序KLOC可能接近，但难度不同所花的时间是不同的。技术顾问：对，我们可以在每个任务中加上难度系数，产能中的KLOC=实际的KLOC*难度系数。研发经理：那么测试任务怎么算？需求捕获技术顾问：根据我的经验，整个系统应该8需求捕获技术顾问：我认为这套系统主要关注的是开发时间、而对于前期的分析和概要设计，以及后续的集成和系统测试等工作可以先忽略，放在系统范围之外，这里只考虑详细设计、编码和相应的测试工作。研发经理：我明白了，就是对于一个任务而言所花的时间。对，这样比较合理。开发人员甲：我希望系统能够在让我们填写估算值时，可以查询历史数据，否则仍然没有意义。开发人员丙：查询历史数据时，还应该有类别吧！这样我们才能够根据自己将要完成的任务情况找到有参考依据的统计数据。开发人员乙：还有就是时间记录一定要方便，另外像我们这样经常要在现场开发，如何完成时间记录？研发经理：可以考虑有一个离线版本的时间记录程序，等回公司连接服务器后再进行数据同步。……需求捕获技术顾问：我认为这套系统主要关注的是9获取需求特性表获取需求特性表10建立概念模型—发现类建立概念模型—发现类11建立概念模型—关联分析建立概念模型—关联分析12建立概念模型—职责分析建立概念模型—职责分析13建立用例模型—识别参与者建立用例模型—识别参与者14建立用例模型—合并特性获得用例建立用例模型—合并特性获得用例15建立用例模型—合并特性获得用例建立用例模型—合并特性获得用例16建立用例模型—绘制用例图建立用例模型—绘制用例图17建立用例模型—简要描述用例建立用例模型—简要描述用例18建立用例模型—划分用例优先级建立用例模型—划分用例优先级19建立用例模型—详细描述用例建立用例模型—详细描述用例20建立交互/状态模型建立交互/状态模型21用户界面设计用户界面设计22Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结业务流程是信息系统的主脉落业务规则是变化的要点Agenda需求建模实例业务流程是信息系统的主脉落23什么是流程目标性：有明确的输出内在性：包含于任何事物或行为中整体性：至少由两个活动组成动态性：由一个活动到另一个活动进行层次性：组成流程的活动本身也可以是流程结构性：串联、关联、反馈等什么是流程目标性：有明确的输出24流程设计的原则流程应以产出为中心，而非任务为中心让那些需要得到流程产出的人自己执行流程将信息处理工作纳入产生这些信息的实际工作中去将各地分散的资源视为一体将并行的工作联系起来，而不是仅仅联系他们的输出在决策点位于工作执行的地方，在业务流程中建立控制程序流程多样化单点接触客户流程设计的原则流程应以产出为中心，而非任务为中心25在IT系统中实现流程设计的本质在IT系统中实现流程设计的本质26绘制流程图的核心步骤提出业务流程清单：确定有哪些流程、流程之间的界限，然后才是对流程的描述流程的要素描述：针对清单上的每一流程，分析并识别现有业务活动、活动之间的关系、活动需要接受哪些信息、产生哪些数据（表单）、数据传送的路线、活动涉及哪些岗位等。重要抓住核心业务和主要活动点，部门内/外衔接、工作繁琐/反复环节、成本高/效率低/时间长的环节、任务转手次数多的环节绘制流程图：跨职能流程图、带泳道的活动图绘制流程图的核心步骤提出业务流程清单：确定有哪些流程、流程之27流程的ESIAE：清除

>过量产出

>活动间的等待

>不必要的运输

>反复的加工

>过量的库存

>缺陷、失误

>重复的活动

>反复的检验

>跨部门协调S：简化

>表格

>程序

>沟通

>物流I：整合

>活动

>团队

>顾客

>供应商A：自动化

>脏、累、乏味活

>数据采集与传输

>数据的分析流程的ESIAE：清除

>过量产出

>活动间的等待

>28跨职能流程图业务流程图系统流程图可以体现数据流向跨职能流程图业务流程图29活动图：简单活动图活动图：简单活动图30活动图：带泳道的活动图活动图：带泳道的活动图31业务流程与业务规则业务流程Action

>用户可以做的操作？

>权限控制的基础业务规则Filter

>用户的授权操作可以影响的数据范围？

>权限控制的补充用例与业务流程：多个用例属于一个流程用例与业务规则：一个业务规则应用于多个用例业务流程与业务规则业务流程Action

>用户可以做的操32业务流程与业务规则结构事实：必须成立的事实或条件。例如：与客户第一次接触的永远都是销售人员。行动约束：根据某种条件禁止的一种或多种行动。例如：不接受具有不能接受的信用历史记录的支票。行动触发：当一个或多个条件转为真时，触发某个行动。例如：当所选商品准备齐后，立即发货。参照：当一个或多个条件转为真时，得出某种结论。例如：在一年内飞行10万公里以上的会员将成为金卡会员计算：根据一组值计算另一个值。例如：销售量是商品总零售额，但是没有包含税收部分。业务流程与业务规则结构事实：必须成立的事实或条件。例如：与客33Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结数据是系统的核心内容Agenda需求建模实例数据是系统的核心内容34数据需求分析与建模数据流通过程：数据流图（DFD）数据存储方式：实体-关系图（ERD）数据定义方式：数据字典（DD）数据需求分析与设计要素数据需求分析与建模数据流通过程：数据流图（DFD）35数据流图：基本元素输入数据在此进行变换产生输出数据，其中要注明加工的名称数据输入的源点或数据输出的汇点，其中要注明源点和汇点的名称存放数据的地方，这些数据在以后使用，通常与实体-联系图中的一个数据实体相对应被加工的数据与流向，箭头边应给出数据流名字，可用名词或名词性短语命名当过程/加工执行时，外部实体与过程之间来回通信数据存储/文件数据流实时连接过程/加工外部实体/源/宿数据流图：基本元素输入数据在此进行变换产生输数据输入的源点或36数据流图：图的结构数据流图：图的结构37数据流图：分层的DFD数据流图：分层的DFD38绘制数据流图：构建顶层图绘制数据流图：构建顶层图39绘制数据流图：绘制DFD片断绘制数据流图：绘制DFD片断40绘制数据流图：将DFD片断合并绘制数据流图：将DFD片断合并41数据建模过程E-R图数据建模过程E-R图42概念结构设计的方法概念结构设计的方法43实体-关系图：图例实体-关系图：图例44实体分析法确定局部视图的范围：实体的个数应适量识别实体及标识确定实体间的联系分配实体及联系的属性实体分析法确定局部视图的范围：实体的个数应适量45识别实体及标识识别实体及标识46实体分析法：确定实体间联系一对一关系：

>两个实体都是强制性的

>仅有一类实体是强制的

>两类实体均非强制性的一对多关系

>多端强制性

>多端非强制性多对多关系实体分析法：确定实体间联系一对一关系：

>两个实体都是强制47确定实体间联系时的陷阱确定实体间联系时的陷阱48E-R图到关系模式的转换实体模型：每个实体转成一个模式

客户（客户名，身份证号，地址，联系电话）一对一关系模式：在两个关系模式中的任意一个模式中，加入另一个模式的键和联系类型的属性

校长（姓名，性别，职称，年龄，校名，任职时间）

学校（校名，地址，电话）E-R图到关系模式的转换实体模型：每个实体转成一个模式

客户49E-R图到关系模式的转换一对多关系模式：在n端实体类型对应的关系模式中加入1端实体类型的键和联系类型的属性校长（姓名，性别，职称，年龄，校名，任职时间）学校（校名，地址，电话）E-R图到关系模式的转换一对多关系模式：在n端实体类型对应的50E-R图到关系模式的转换多对多关系模式：将联系类型也转换成关系模式，属性为两端实体类型的键加上联系类型的属性

学生（学号，姓名，性别，年龄）课程（课程号，课程名，授课老师）考试（课程号，学号，成绩）E-R图到关系模式的转换多对多关系模式：将联系类型也转换成关51数据字典应用数据元素说明

>数据元素名或标识：即对用户而言有意义的名称；

>别名：可选择的名字

>类型和长度：说明数据元素的组成部分，是数字、字母还是其他；而长度则是指其最大的组成个数

>默认值：即数据元素的一个初始值；

>可接受的值：即数据元素有效的合法取值范围

>数据源：即对数据元素值的起源点的具体说明

>安全：对于有权访问或更新每个数据元素的人或部门的标识

>有责任用户：负责输入/改变数据元素值的用户标识

>描述和评论：加上一些更好的说明数据元素的注解数据字典应用数据元素说明

>数据元素名或标识：即对用户而言52数据字典应用数据流说明

>数据流名或标识：即在DFD中所对应的数据流名称>描述：说明数据流的用途与目的

>别名：可选择的名字

>数据源：数据流的起点

>目的：数据流的终止点

>记录：每个数据流都代表了一组被称为记录或数据结构的相关实体

>量和频率：描述单位时间内数据流发生的次数。数据字典应用数据流说明

>数据流名或标识：即在DFD中所53数据字典应用数据存储（文件）说明

>数据存储名或标识：在DFD中对应的数据存储名称

>描述：说明数据存储的用途与目的

>别名：可选择的名字

>属性：输入或离开数据存储的标准数据流图名

>量和频率：描述数据存储中记录出现的可估计的个数和更新频度加工说明

>加工名或标识：即在数据流图中所对应的加工名称

>描述：说明加工的用途与目的

>加工数据标识：用来指明加工所在的层次

>加工描述：说明包括的输入和输出数据流数据字典应用数据存储（文件）说明

>数据存储名或标识：在D54数据字典应用外部实体说明

>实体名或标识：即在数据流图中所对应的实体名称

>描述：说明实体的用途与目的

>别名：可选择的名字

>输入数据流

>输出数据流数据元素说明的常用表示法

>：由…构成

>：和，代表顺序连接的关系

>[|]：或，代表从中选择一个

>{}*：n次重复

>（）：代表可选的数据项

>*…*：表示特定限制的注释数据字典应用外部实体说明

>实体名或标识：即在数据流图中所55数据字典应用实例客户基本信息=客户编号+客户名称+身份证号码+手机+小灵通+家庭电话客户编号={0…9}8客户名称={字}4身份证号码=[{0…9}15|{0…9}18]手机=[{0…9}11|{0…9}12]小灵通=（区号）+本地号家庭电话=（区号）+本地号办公电话=（区号）+本地号区号={0…9}4本地号=[{0…9}7|{0…9}8]数据字典应用实例客户基本信息=客户编号+客户名称+身份证号码56数据需求分析与设计要素术语表数据结构分析，对表的内容要区分

>主要字段和次要字段

>稳定字段和不稳定字段

>即时记录和历史记录另个需要考虑

>联机事务需要报表需求决策查询需求

>数据量与增长速度（数据查询失效案例）

>性能与扩展

>并发可能性与数量数据需求分析与设计要素术语表57数据需求分析与设计要素数据共享考虑

>数据库、文件、XML

>逐段加密问题

>数据Filter原则

>谁建立？谁修改？谁查询？谁应用？数据挖掘与分析

>查询报表—从规则入手

>BI

>数据挖掘，仓库（电信数据整合）数据需求分析与设计要素数据共享考虑

>数据库、文件、XML58数据仓库数据仓库59Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结规格说明书是需求“圣经”Agenda需求建模实例规格说明书是需求“圣经”60需求描述最佳实践1定义描述需求的标准模板：在书写具体的系统需求时，应该定义一系列的标准模板用于组织需求描述。模板应该包括一些字段，通过填写这些字段，可以完整地说明一项需求。

>主要效益：需求前后一致，因而更加易懂

>引入成本：中>应用成本：低使用浅显、一致、简明的语言：当使用自然语言表达某项需求时，应注意使用浅显、简明的语然言一描述，避免使用复杂的句子结构、冗长的句子和不明确的术语。

>主要效率：需求更加易读易懂

>引入成本：相当低>应用成本：低-中

需求描述最佳实践1定义描述需求的标准模板：在书写具体的系统61需求描述最佳实践2适当地使用图解：当需要表示结构化的信息或者需要表达需求描述中信息之间的关系时应当使用图解，图解还可以用于概括数字信息或描述事件和行为序列。

>主要效益：图解最适于记录需求关系

>引入成本：低>应用成本：低

>实施指南：应使用图解的典型情况包括当某个对象（系统、文档）由多个模块和组件组成，而你又希望阐明它们之间的相互关系时；当需要表达一系列的行为，每个行为都有一些输入和输出时；当需要说明空间组织时；当需要使用一些分解结构时。但要避免使用含义不清晰的图案（如Word中的剪贴画）需求描述最佳实践2适当地使用图解：当需要表示结构化的信息或62需求描述最佳实践3用其他需求描述辅助自然语言：某此需求更适于使用特殊的方式书写，如数学公式、决策表等。

>主要效益：更加简明、无二义性的需求描述

>引入成本：很低>应用成本：低定量说明需求：只要有可能，就应该使用定量的数值说明系统的需求，非功能需求最有可能采用这一点。

>主要效益：无二义性地表达需求

>引入成本：低-中>应用成本：低-中

>实施指南：定义表达这些属性的合适的度量；为属性决定一个合适的值。需求描述最佳实践3用其他需求描述辅助自然语言：某此需求更适63非功能需求可以使用度量可靠性：出错时间、错误发生率有效性：请求后出错的可能性性能：每秒处理的事务数，对用户输入的响应时间存储利用：系统最大的尺寸(MB)可用性：学习75%的用户功能所需要的时间，在给定时间内由用户引起的错误的平均值健壮性：系统出错后重新启动的时间完整性：系统出错时，允许的数据丢失的最大限度非功能需求可以使用度量可靠性：出错时间、错误发生率64数据需求的描述形式数据模型：E-R模型

>框图：描述产品内、外的数据

>非常适合专家使用，但不便于用户使用数据词典：

>产品内、外数据的文字描述

>非常适合专家及用户数据表达式

>描述数据序列的简洁公式，适合于描述复合数据及消息协议

>非常适合于专家使用，也为许多用户所接受虚拟窗口

>简化的屏幕图像，有图像、真实数据，但无按钮、菜单

>非常适合专家及用户，非常适合于规划新的界面数据需求的描述形式数据模型：E-R模型

>框图：描述产品内65功能需求的形式1人、机职责划分：可采用DFD、UML表示

>域模型：人、机结合的模型

>物理模型：人、机各自的职责

>产品层需求：人、机职责划分功能需求的形式1人、机职责划分：可采用DFD、UML表示

66功能需求的形式2上下文图：说明产品及其环境的图示

>为开发人员概括了所有接口

>大多数客户能不费力地理解上下文图功能需求的形式2上下文图：说明产品及其环境的图示

>为开67功能需求的形式3事件列表与功能列表：产品要处理的事件，人、机合作处理的事件域事件实例：

>客人预订>客人入住>客人退房

>换房>提交服务记录产品事件实例

>查找空闲客房>记录客人信息

>查找客人数据>记录预订数据

>打印预订确认>记录入住数据

>退房>记录服务

功能需求的形式3事件列表与功能列表：产品要处理的事件，人、68功能需求的形式4特性需求：文字形式，该产品应记录/显示/计算…，很多人认为这是惟一可以接受的需求形式可能给用户及分析人员造成错觉实例：

>该产品应能将客户在某一期限内设为维修状态

>该产品应能够显示、打印下两周的人员配置表。该配备应以客房占用的历史数据为依据。

>该产品也应支持根据客户类型，而不是客房号的预订。客人入住时才分配实例客房功能需求的形式4特性需求：文字形式，该产品应记录/显示/计69功能需求的形式5屏幕显示及原型：包括屏幕图像及”按钮“的功能，若经仔细测试可以作为很好的设计层需求实例：

功能需求的形式5屏幕显示及原型：包括屏幕图像及”按钮“的功70功能需求的形式6任务说明：结构化的文字说明，用于描述用户任务；便于客户、开发

人员理解；便于说明

任务变体以及复杂的

任务实例：

功能需求的形式6任务说明：结构化的文字说明，用于描述用户任71功能需求的形式7由任务说明到产品特性：用任务说明解释产品特性；有助于理解、确认特性任务及支持：结

构化的文字说明，

描述任务、域问

题，提出可能的

方案。

功能需求的形式7由任务说明到产品特性：用任务说明解释产品特72功能需求的形式8场景说明：说明一项或多项用户任务，或要测试的一个特殊情况，有助于增进开发人员的直觉，通常不作为需求。实例：夜班

由于学习了一整个下午，张三在下午6点开始值夜班时，已感觉到有些疲倦。他的第一项任务是为将在7点钟抵达的客人团做准备，他打印了所有的入住登录表，并将它们同各自的客房钥匙放在一起。

在处理这项任务时，来了一个家庭询问客户的情况。他们想讨价还价，这是张三最不擅长的工作。是否应该给他们提供折扣呢？正好李四从办公室里出来，她微笑地告诉他们：可以为小孩的房间提供10%的折扣。他们接受了，于是张三为他们安排房间，他们希望挨着的两间客户，但是张三总是记不住哪些客遍及是挨着的。功能需求的形式8场景说明：说明一项或多项用户任务，或要测试73功能需求的形式9用例数据流图以“标准”作为需求以“开发过程”作为需求功能需求的形式9用例74非功能需求的形式1开放尺度与开放目标：通常要求达到某个数字目标。实例：

>该产品应能检测超速，并在0.5秒内完成拍照

>该产品应能够2分钟内计算并显示客户占用情况的预报表Planguage表示法：非功能需求的形式1开放尺度与开放目标：通常要求达到某个数字75非功能需求的形式2能力及准确度需求非功能需求的形式2能力及准确度需求76非功能需求的形式3性能需求非功能需求的形式3性能需求77需求规格说明书规格描述的形式

>文档：用结合合理的自然语言精心编写

>图形化模型：描述转换过程、系统状态以及变化、数据关系、逻辑流或者对象类及其关系

>形式化规格说明：逻辑语言(伪码、决策表、决策图)常用模板

>ISO/GB版：面向结构化分析方法的，较陈旧

>RUP版：以面向对象分析方法，用例驱动

>Volere版：很实用的一个第三方公司版本

AtlanticSystemGuild（）公司

需求规格说明书规格描述的形式

>文档：用结合合理的自然语言781．引言1.1编写的目的1.2背景1.3定义[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]1.4参考资料[列出用得着的参考资料。]2．任务概述2.1目标[叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景

材料。解释被开发系统与其他有关系统之间的关系。]2.2用户的特点[列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，

以及本系统的预期使用频度。]2.3假定和约束[列出进行本系统开发工作的假定和约束。]3．需求规定3.1对功能的规定[用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、

经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支

持的并行操作的用户数等指标。]3.2对性能的规定3.2.1精度3.2.2时间特性要求3.2.3灵活性3.3输入输出要求3.4数据管理能力要求（针对软件系统）3.5故障处理要求3.6其他专门要求4．运行环境规定4.1设备[列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：4.2支持软件[列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等。]4.3接口[说明该系统同其他系统之间的接口、数据通信协议等。]4.4控制[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。]1．引言79RUP版需求规约1.文档概述1.1目的1.2范围1.3定义、首字母缩写词和缩略语1.4参考资料1.5概述2.整体说明[让读者对整个软件系统的需求有一个框架性的认识。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。]2.1用例模型2.2假设与依赖关系3.具体需求3.1用例描述3.2补充需求[易用性、可靠性、性能、其它]4.支持信息

80Volere版：产品的目标该项目工作的用户问题或背景

>内容：对引发开发任务的工作和情况的描述

>动机：为该项目提供合法理由

>例子：用户对订单到达所需的时间(10天)感到不满

>考虑：用户问题是否严重，是否应解决，如何解决产品的目标

>内容：我们希望产品做什么？

>动机：缺少表述清晰、易于理解的目标，会使项目开发迷失方向

>例子：我们希望对顾客通过电话下订单订购我们的产品作出立即和完整的响应。

>考虑:是否指派一个人作为“目标管理人”Volere版：产品的目标该项目工作的用户问题或背景

>内81Volere版：客户/顾客…客户：为开发付费的人

>内容：指出客户的名称

>动机：是最终接受该产品的，必须对该产品满意

>例子：公司客户服务部

>考虑：有时客户是间接，那么选择间接部分中的一个人作为客户顾客：花钱购买该产品的人

>内容：顾客的名称或特征

>动机：它是决定产品价值的人其它风险承担人

>内容：Stakeholder列表

>动机：各方需求源Volere版：客户/顾客…客户：为开发付费的人

>内容：82Volere版：产品的用户产品的用户

>内容：用户分类、用户工作任务、主题相关经验、技术经验、其它特征(身体、智力、工作态度、技术态度、教育、语言、年龄、性别等)

>动机：了解用户在确定产品易用性、设计偏好时很重要用户优先级

>内容：关键用户、次要用户、不重要用户

>动机：更好地满足不同的用户Volere版：产品的用户产品的用户

>内容：用户分类、用83Volere版：需求限制条件解决方案限制条件

>内容：解决方案中必须采用的或不能采用的方式

>例子：产品必须使用WindowsNT系统，必须是一个手持设备

>考虑：有解决方案限制一个边界实现环境

>内容：将实施的技术、物理环境

>动机：要求解决方案必须适应的环境伙伴应用、COTS(外购软件包)预期工作场地环境开发时间、预算Volere版：需求限制条件解决方案限制条件

>内容：解决84Volere版：命名标准和定义定义项目中使用的所有术语

>内容：一个字典，包括使用的所有名称的含义，应使用标准名称

>动机：减少项目开发过程中的概念澄清，减少需求歧义

>例子：现值：总额/(1+年利息)年

>考虑：利用已有的数据字典或词汇表

WiKi管理，十分理想！

避免二义性的词和同义词Volere版：命名标准和定义定义项目中使用的所有术语

>85Volere版：相关事实和假定相关事实：可能对产品产生影响的外部因素

>内容：对产品产生影响的其他因素、系统和活动

>动机：提醒开发者可能对需求产生影响的一些情况和事实

>例子：原有应用程序主要的问题就是查询操作太多，无法使用假定

>内容：需求开发过程中所做的假设清单，对产品开发有影响

>动机：假定与事实是相对的，它不一定是真实的

>例子：用户能力的假定、外部系统的性能假定

短信服务器能够完成每秒20条的发送任务

Volere版：相关事实和假定相关事实：可能对产品产生影响86Volere版：产品的范围工作的上下文范围

>内容：上下文范围图

>动机：清析地定义系统的边界工作切分

>内容：事件清单，确定工作系统要响应的业务事件，可以用“事件列表”或“用例列表”来表述

>动机：确定工作系统的逻辑上的大块

>例子：用户能力的假定、外部系统的性能假定产品边界

>内容：用例图，确定用户和产品的边界

Volere版：产品的范围工作的上下文范围

>内容：上下文87Volere版：功能/数据和观感需求功能需求

>内容：产品必须执行的动作描述

>例子：当短信发送失败时，给发送人一个消息提示

>验收标准：取决于要求做的动作数据需求

>内容：E-R图或类图表示要保存的数据，DFD表示数据流通

>动机：澄清产品的主题内容观感需求

>内容：外观设计的要求与部分原型

>动机：外观是产品的有机组成部分，且很重要

>例子：界面主色调应与公司VI吻合，应表现出稳重

>考虑：明确客户对产品外观的观点Volere版：功能/数据和观感需求功能需求

>内容：产品88Volere版：易用性需求易于使用

>内容：预期用户应该如何容易地操作产品

>动机：指导产品设计者构建符合最终用户期望的产品

>例子：产品应该帮助用户避免犯错；不懂英文的用户也能操作

>验收标准：使用一个月后，总的错误率应是多少；经过熟悉期后，百分之多少的不懂英文用户同意能够操作学习的容易程度

>内容：学习时间和方式的要求

>动机：量化可接受的用户学习时间

>例子：工程师参加了一周培训后，应该能使用该产品

>验收标准：软件使用培训结束后的最后测验中，工程师应到[一个大家同意的百分比]的通过率Volere版：易用性需求易于使用

>内容：预期用户应该如89Volere版：性能需求速度需求

>内容：明确完成特定任务需要的时间，即响应时间

>动机：对特定应用而言，响应时间很重要

>例子：产品必须每秒钟完成20条以上的短信发送

>验收标准：可测量的描述

>考虑：不同速度需求，对于设计与开发影响甚大安全悠关的需求

>内容：对可能产生人身伤害、财产损失和环境破坏所考虑的风险的量化描述。精度要求

>内容：量化描述输出结果的精度要求

>例子：所有有关钱的数据都精确到小数点后两位Volere版：性能需求速度需求

>内容：明确完成特定任务90Volere版：性能需求可靠性和可用性需求

>内容：量化可靠性，平均无故障时间、总失败率

>动机：有些系统，可靠是十分重要的

>例子：产品应能够达到100小时的平均无故障时间容量需求

>内容：吞吐量和产品存储数据容量的要求

>动机：保证产品有能力处理期望和数据量

>例子：在上午9:00~12:00应满足300个并发用户使用，其它时间最大负载为150个并发用户Volere版：性能需求可靠性和可用性需求

>内容：量化可91Volere版：操作需求预期的物理环境

>内容：明确产品将操作的物理环境

>动机：指出可能需要特殊需求、准备或培训的情况

>例子：所有的用户都是站立着操作的该系统的预期的技术环境

>内容：硬件和其他组成新产品操作环境的设备的规范

>动机：确定所有新产品要交互的元件或组成部分伙伴应用程序

>内容：必须与之交互的其他应用程序

>动机：避免在实现阶段才发现

>例子：必须能够与任何Web浏览器交互Volere版：操作需求预期的物理环境

>内容：明确产品将92Volere版：可维护性和可移植性维护该产品需要多容易

>内容：对产品作特定修改所需的量化描述

>动机：让每个人意识到产品维护的需要

>例子：新添一种在原有数据基础上生成的报表格式，需要提出后一个工作周内提供是否存在一些特殊情况适用于该产品的维护

>内容：关于预期的产品发布周期和将采取的形式规定

>动机：将每年根据使用情况发布一次更新版可移植性需求

>内容：产品必须支持的其他平台或环境的描述

>动机：量化客户和用户关于产品运行平台的期望

>例子：必须能够运行在Windows英文版、日文版上Volere版：可维护性和可移植性维护该产品需要多容易

>93Volere版：安全性需求该产品是保密的吗

>内容：关于谁被授权使用该产品

>动机：理解并突出指明对产品安全保密方面的预期需求

>例子：员工的个人记录只有直接经理可以读取

>考虑：是否存在管理层敏感数据？是否会导致损害或可能用于个人获利的过程？是否有人不应有权使用该产品？……文件完整性需求

>内容：关于所需数据库和其他文件完整性方面的说明

>考虑：信息如何使用？过时信息会有什么影响？审计需求

>内容：需要审计检查方面的规格说明

>动机：构建符合相应审计规定的产品Volere版：安全性需求该产品是保密的吗

>内容：关于谁94Volere版：文化和政策/法律需求文化和政策需求

>内容：针对社会和政策因素的规格说明

>动机：写明在开发者文件经验范围之外的需求

>例子：不要使用会令xx语系人民不快的图标

>考虑：是否熟悉最终用户的文化环境该产品是否受到某些法律管制

>内容：明确该产品的法律需求的描述

>例子：用户隐私数据不提供任何有助于传播的功能支持是否有一些必须符合的标准

>内容：明确适用的标准和参考的详细标准的描述

>考虑：标准业界组织？行业规则？特殊开发步骤？数据规范？Volere版：文化和政策/法律需求文化和政策需求

>内容95Volere版：开放式问题与COTS开放式问题

>内容：对未确定但可能对产品产生影响的因素进行描述

>动机：公开不确定性

>例子：即将执行新的行业法规是否对软件产生影响尚未确定是否有一些成品可以购买是否可使用成品组件是否有一些我们可以复制的东西Volere版：开放式问题与COTS开放式问题

>内容：对96Volere版：开放式问题与COTS新产品会在当前环境中带来什么问题

>内容：新产品如何影响当前环境，不应该做什么

>动机：尽快发现任何潜在冲突

>例子：短信发送成功与否直接影响业务员工作业绩新的开发是否将影响某些已实施的系统现有用户是否会对新产品产生敌对影响预期的实现环境是否会对新产品有限制是否新产品会带来其他问题Volere版：开放式问题与COTS新产品会在当前环境中带来97需求项框架：Volere需求白卡需求项框架：Volere需求白卡98Volere白卡各项说明需求编号：为了可追踪需求类型：可自己定义一个编号类表事件/用例编号：涉及的业务事件、用例描述：该项需求的意图理由：存在该需求的原因来源：需求提出人、部门、联系方式验收标准：必须达到的最化标准满意度/不满意度：1-5量化，乘积进行排名依赖关系：与其它需求的相关性冲突：与其它需求的冲突支持材料：相关补充说明材料历史：修改记录Volere白卡各项说明需求编号：为了可追踪99Volere白卡示例25如果一个气象站传送读数失败，产品将发出警告。传送读数失败可能表明气象站失效并需要维护，并且用

于预测结冰的数据可能不完整道路工程师对每个气象站，当每小时记录下来的各类读数个数不在制造商规定的范围之内时，产品将通知用户35无无Rosa气象站规格说明书GBS在05.03.12提出Volere白卡示例25如果一个气象站传送读数失败，产品将发100Volere白卡示例113易用性6,7,8,9,10产品应该对道路工程师易于使用工程师不必为了使用该产品而参加培训课程Sonia,Henning,道路工程管理者一个道路工程师将在首次接触该产品的一小时内，能够成

功地执行指定的用例35无无HW在05.03.12提出Volere白卡示例113易用性6,7,8,9,10产品应该101需求文档编写原则使用语法、标点正确的完整句子，使语句的段落简短明了采用主动语态的表达方式：如“该系统将…”，而非“…将发生”使用的术语应与术语表中定义的术语保持一致将含糊不明确的顶层需求分解成足够详细的几个需求，消除歧义需求声明应该具有一致的风格，例如“系统将…”，“用户将…”当以“用户将…”格式说明时，尽可能明确参与者使用列表、数字、图和表来表示信息强调最重要的信息避免使用语义不清的词语以相同的详细程序编写详细程度的把握：可以单独测试需求文档编写原则使用语法、标点正确的完整句子，使语句的段落简102歧义术语与改进可接受、足够：具体定义可接受的内容和系统如何地此进行判断差不多可行：不要让开发人员来确定什么是可行的至少、最小、不多于、不超多：指定能够接受的最大值和最小值在…之间：定义终点是否在此范围内依赖：描述依赖性的本质，是提供输入？是提前安装支持软件？有效的：定义系统如何有效地使用资源，系统执行特定的操作的速度如何，用户使用系统的容易程度如何灵活的：描述一种方式改进的、更好的、更快的、优越的：定量说明包括、包括但不限于、等等、诸如：项目列表应包含所有可能性最大化、最小化、最优：陈述对某些参数所接受的最大值和最小值歧义术语与改进可接受、足够：具体定义可接受的内容和系统如何地103歧义术语与改进一般情况下、理想情况下：描述系统在异常和非理想条件下的行为可选择的：指明是系统选择、用户选择还是开发人员选择合理、在必要的时候、在适当的地方：清晰解释如何判断健壮的：定义系统如何处理异常和如何响应预料外的操作条件无缝的、透明的、优雅的：将用户期望转化成能够观察的特性若干：具体是多少，最小边界值和最大边界值不应该：试着以肯定句来描述最新技术水平：描述其具体含义充分的：指定具体包括哪些内容支持、允许：精确定义系统将执行哪些功能用户友好、简单、容易：描述系统特性，这些特性将达到客户的使用需要和对易用性的期望歧义术语与改进一般情况下、理想情况下：描述系统在异常和非理想104需求修正原描述：后台任务管理器必须在固定的时间间隔内提供状态消息，并在每次时间间隔不得小于60秒。什么是状态消息？什么条件下和以什么方式向用户提供这些消息？显示时间是多长？间隔时间不太明确，1毫秒行吗？修改后：

后台任务管理器应该在用户界面的指定区域显示状态信息

在后台任务进程启动后，消息必须每隔60±10秒更新一次

消息应该保持持续的可见性

后台任务管理器在每次可以与后台任务进程进行通信时，都应该显示后台任务已完成的百分比

当完成后台任务时，后台任务管理器应该显示一个“已完成”的消息

如果后台任务中止执行，那后台任务管理器应该显示一个出错信息需求修正原描述：后台任务管理器必须在固定的时间间隔内提供状态105需求修正原描述：如果可能的话，应该根据主要法人帐号列表来在线确认所输入的帐号的有效性。如何可能是指什么？是指技术上可行？运行时间可行？如果不能确定一定要，则应该用TBD来表示！修改后：

当请求者输入帐号时，系统将根据在线的主要法人帐号的列表来验证所输入的帐号。如果在此列表中找不到，则显示一个错误信息并拒绝订货。需求修正原描述：如果可能的话，应该根据主要法人帐号列表来在线106需求修正原描述：编辑器不应该提供可能带来灾难性后果的查询和替换选项灾难性后果是什么？如果发现这个可能带来灾难性的查询/替换？重要的关注点实际上是：发生意外损坏或丢失时能够保护内容修改后：

1.编辑器将要求用户确认全局性文本改动、删除和插入操作

2.应用程序应提供多级“撤消”功能需求修正原描述：编辑器不应该提供可能带来灾难性后果的查询和替107Agenda需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结Agenda需求建模实例108需求管理最佳实践1惟一地标识每一个需求：应该给每一个需求分配一个惟一的标识符或者引用数字，可以用于在需求文档的其他部分或在其他系统文档中指向该需求。

>主要效益：明确地引用特定需求是可能的

>引入成本：很低>应用成本：很低定义需求管理的策略：定义了需求管理的目标，应该遵循的过程和应该使用的标准。

>主要效益：对所有参与需求管理的人提供指导

>引入成本：中等>应用成本：低需求管理最佳实践1惟一地标识每一个需求：应该给每一个需求分109需求管理最佳实践2定义可跟踪性策略：应定义应用维护哪些可跟踪性的信息以及该信息应该怎样表示，可跟踪性信息是可以发现需求间、需求和系统设计、组件和文档间依赖性的信息。

>主要效益：维护所有系统的一致的可跟踪性信息

>引入成本：中等>应用成本：中等-高维护可跟踪性手册：它是对需求文档的一个补充，包含了在项目中使用的特定的跟踪性策略和需求的可追踪性信息。

>主要效益：作为所有特定项目的可跟踪性信息的中心记录

>引入成本：低>应用成本：中等-高需求管理最佳实践2定义可跟踪性策略：应定义应用维护哪些可跟110需求管理最佳实践3使用数据库来管理需求：建立一个需求数据库，把单个需求作为条目存储进数据库，而不要用文本文档来维护需求。

>主要效益：使管理大量的需求变得容易

>引入成本：中等-高>应用成本：中等

>实施指南：需求是怎么表达的？自然语言、图形模型、数学表达式？一般需要管理多少需求？需求总是由在同一地方工作、使用相同类型电脑的小组开发和管理的吗？已经使用一个支持软件工程的数据库了吗？有内部的数据库专家吗？需求工程师负责数据库管理吗？需求管理最佳实践3使用数据库来管理需求：建立一个需求数据库111需求管理最佳实践4定义变更管理策略：陈述了变更是以何种形式提出、分析和评审的。然后实现已接爱的变更，产生一个新版本的需求文档。

>主要效益：提供一个系统地评估变更提议的框架

>引入成本：中等-高>应用成本：低-中等

>实施指南：应包括变更请求过程和处理每个变更请求所需的信息；用来分析变更的影响和成本以及相关的可跟踪性信息的过程；正式考虑变更请求的成员人数；变更控制的软件支持需求管理最佳实践4定义变更管理策略：陈述了变更是以何种形式112需求管理最佳实践5标识全局系统需求：是在总体上说明了系统想要的或者必须的属性。它们不能够赋予单独的子系统。

>主要效益：找到变更成本最大的需求

>引入成本：低>应用成本：低标识易变的需求：应该维护一个易变的需求列表，即那些最可能发生变更的需求。如果可能，应该对这些需求的变更进行预测。

>主要效益：简化需求变更管理

>引入成本：低>应用成本：低记录丢弃的需求

>主要效益：当其再次提出时，保存再分析结果

>引入成本：低>应用成本：低需求管理最佳实践5标识全局系统需求：是在总体上说明了系统想113软件开发中的V字模型软件开发中的V字模型114需求评审：方法非正式评审：

>同级桌面检查：请一位同事检查

>轮查：同时请若干同事分别检查

>走查：作者向评审人员描述，并要求做出评论正式评审

>同级评审(审查)：最有效的软件质量技术需求评审：方法非正式评审：

>同级桌面检查：请一位同事检查115需求评审：方法非正式评审：

>同级桌面检查：请一位同事检查

>轮查：同时请若干同事分别检查

>走查：作者向评审人员描述，并要求做出评论正式评审

>同级评审(审查)：最有效的软件质量技术需求评审：方法非正式评审：

>同级桌面检查：请一位同事检查116需求审查过程参与者

>需求规格说明书的作者、同级伙伴

>提供规格说明信息的人：分析员、客户

>要根据规格书开展工作的人：开发人员…

>负责相关接口工作的人

>总人数：<=6人角色

>作者>主持人

>读者>记录员需求审查过程参与者

>需求规格说明书的作者、同级伙伴

>117需求审查：开始标准文档遵循标准模板文档已经进行过拼写检查作者已经检查了文档在版面上的错误已经获得了审查前需要阅读的文档或参考文档在文档中标上了行号，便于查阅所有未解决问题已标上了TBD主持人检查10分钟后，找不出3个以上重大错误需求审查：开始标准文档遵循标准模板118需求审查：主要阶段规划：谁参加？准备什么材料？总体会议：确定审查的背景、假设及目标准备：审查员阅读材料审查会议：主持人引导返工：审查结果修改跟踪：确定错误已修正需求审查：主要阶段规划：谁参加？准备什么材料？119需求审查：要点需求的完整性

>是否存在遗漏的内容

>是否对所有风险承担者都有考虑需求的可追踪性

>惟一标识符号

>类型说明

>对用例的引用

>冲突描述

>一致使用术语需求审查：要点需求的完整性

>是否存在遗漏的内容

>是否120需求审查：要点是否与目标相关

产品将维护一个查询表，记录一年中日出和日落时间检查验收标准在限制条件下是否可行是需求还是解决方案顾客价值与镀金需求需求蔓延需求审查：要点是否与目标相关

产品将维护一个查询表，记录一年121变更管理应确保的事项应仔细评估已建议的变更挑选合适的人选对变更做出决定变更应及时通知所有涉及的人员项目要按一定的程序来采纳需求变更变更管理应确保的事项应仔细评估已建议的变更122控制项目范围的扩展对许多项目而言，需求的改进是合理且不可避免首先应把新系统的视图、范围、限制文档化并作为业务需求的一部分对于控制范围扩展的方法是要敢于说“不”基线+变更过程是解决项目范围扩展的重要手段控制项目范围的扩展对许多项目而言，需求的改进是合理且不可避免123变更控制过程好的变更控制过程给项目风险承担者提供了正式的建议需求变更机制变更控制过程并不是给变更设置障碍，而是提供一个渠道和过滤器控制需求变更同项目的其他配置管理决策是紧密相连的，管理需求变更类似于跟踪错误和做出相应决定的过程变更控制过程好的变更控制过程给项目风险承担者提供了正式的建议124变更控制策略所有需求变更必须遵循的过程，按照此过程如果一个变更需求未被采纳，则其后过程不再予以考虑对于未批准的变更，除可行性论证之外，不应再做其他设计和实现工作简单请求一个变更不能保证能实现变更，要由项目变更控制委员会（CCB）决定实现哪些变更项目风险承担者应该能够了解变更数据库的内容绝不能从数据库中删除或修改变更请求的原始文档每一个集成的需求变更必须能够跟踪到一个经核准的变更请求变更控制策略所有需求变更必须遵循的过程，按照此过程如果一个变125变更控制步骤每个变更控制步骤由4个组件组成：开始条件：在执行过程或步骤前应该满足的条件过程和步骤中所包含的不同任务及项目中负责完成它们的角色验证任务正确完成的步骤结束条件：指出过程或步骤完成的条件变更控制步骤每个变更控制步骤由4个组件组成：126描述变更控制步骤概述：说明此步骤的目的，确定步骤能够应用的范围角色和责任：列出参与变更控制活动的项目组成员并且描述他们的责任（CCB主席、CCB、评估者、修改者、建议者、项目管理者、请求接受者、验证者）变更请求状态开始条件任务验证退出条件变更控制状态报告描述变更控制步骤概述：说明此步骤的目的，确定步骤能够应用的范127变更需求状态转换变更需求状态转换128变更控制工具可以定义变更请求的数据项可以定义变更请求生存期的状态转换图可以加强状态转换图使经授权的用户仅能做出所允许的状态变更记录每一种状态变更的数据，确认做出变更的人员可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员可以根据需要生成标准的或定制的报告和图表变更控制工具可以定义变更请求的数据项129变更控制委员会(CCB)CCB是业界的最佳实践，可以由一个小组或多个不同的组担任，负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用负责对项目中任何基线工作产品的变更做出决定CCB的组成：

>项目管理部门>产品管理或需求分析部门

>开发部门>测试或质量保证部门

>市场或客户代表>用户文档部门

>技术支持部门>配置管理部门变更控制委员会(CCB)CCB是业界的最佳实践，可以由一个小130测量变更活动软件测量是深入项目、产品、处理过程的调查研究需求变更活动的下列方面值得考虑：

1）接收、未作决定、结束处理的变更请求数量

2）已实现需求变更的合计数量

3）每个方面发出的变更请求的数量

4）每一个已应用的需求建议变更和实现变更的数量

5）投入处理变更的人力、物力可以通过线划图、直方图来表示测量变更活动软件测量是深入项目、产品、处理过程的调查研究131需求跟踪跟踪能力（联系）链使你能够跟踪一个需求使用期限的全过程四类需求跟踪能力链需求跟踪跟踪能力（联系）链使你能够跟踪一个需求使用期限的全过132需求跟踪联系链需求跟踪联系链133需求跟踪动机审核：跟踪能力信息可帮助审核确保所有需求被应用变更影响分析：跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素维护：可靠的跟踪能力信息使得维护时能够正确、完整地实施变更，从而提高生产率项目跟踪：认真记录跟踪能力数据，可以获得计划功能当前实现状态的记录再设计：可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置重复利用、减少风险、测试需求跟踪动机审核：跟踪能力信息可帮助审核确保所有需求被应用134需求跟踪矩阵需求跟踪矩阵135跟踪能力联系链可能的信息源跟踪能力联系链可能的信息源136需求跟踪能力过程决定定义哪几种联系链选择使用的跟踪能力矩阵的种类确定对产品哪部分维护跟踪能力信息通过修订过程和核对表来提醒开发者在需求完成或变更时更新联系链制定标记性的规范确定提供每类联系链信息的个人培训项目组成员一旦有人完成某项任务就要马上更新跟踪能力数据在开发过程中周期性地更新数据需求跟踪能力过程决定定义哪几种联系链137变更影响分析变更请求ID号：

.标题：

.描述：

.分析人员：

.日期：

.优先级评估：相对收益：

（1~9）相对损失：

（1~9）相对费用：

（1~9）相对风险：

（1~9）计算出的最终优先级：

（相对于其他待处理需求）估计的总工作量：

（人时）估计损失的总工作量：

（人时）估计对进度的影响：

（天）额外的成本影响：

（元）质量影响：

受影响的其他需求：爱影响的其他任务：集成问题：生存期费问题：检查可能要变更的其他组件：变更影响分析变更请求ID号：138基于文档存储需求方法的限制很难保持文档与现实的一致通知受变更影响的设计人员是手工过程不太容易做到为每一个需求保存增补的信息很难在功能需求与相应的用例、设计、代码、测试和项目任务之间建立联系链很难跟踪每个需求的状态基于文档存储需求方法的限制很难保持文档与现实的一致139常用的商业需求管理工具DOORS：以数据库为中心RequisitePro：以文档为中心，Rational公司Caliber-RM：以数据库为核心QSSrequireit：以文档为中心RTMWorkshop：以数据库中心VitalLink：以文档为中心常用的商业需求管理工具DOORS：以数据库为中心140使用需求管理工具的好处管理版本和变更：提供了灵活的基线设定功能存储需求属性：对每个需求可以保存相关属性帮助影响分析：可以找到需求关联跟踪需求状态：可以很容易地知识某个产品包含的所有需求访问控制：可以对个人、用户小组确定访问权限与风险承担者进行沟通：可以通过邮件自动通知重用需求：需求保存之后可以实现需求重用，避免信息冗余使用需求管理工具的好处管理版本和变更：提供了灵活的基线设定功141商业需求管理工具的主要特点允许定义不同种类的数据库元素，如业务需求、用例、功能需求、硬件需求、非功能需求…在某种程度上实现了Word的集成，最常见的方式是在Word中添加工具籅有统一的内部标识符，支持层次编码的数字标签，例如UR00x表示用户需求，DOORS中还能够看到层次结构的软件需求说明书工具的输出能力包括以用户自定义格式或表单报告格式，Caliber-RM提供了强大的文档加工功能有在需求同其他系统元素之间定义联系链的跟踪能力商业需求管理工具的主要特点允许定义不同种类的数据库元素，如业142商业需求管理工具的互集成性RequisitePro不仅可以建立需求与Rose的用例之间的联系，还可以与RationalTeamTest中的测试实例建立联系DOORS能够建立需求与RationalRose的设计元素之间的联系RequisitePro和DOORS能够建立需求与Project中项目任务间的连接Caliber-RM通过一个中央通信框架，实现多种方面的联系建立商业需求管理工具的互集成性RequisitePro不仅可以建143Agenda需求分析与建模(续)需求描述最佳实践需求管理最佳实践需求过程总结千里之行，始于跬步Agenda需求分析与建模(续)千里之行，始于跬步144需求过程需求过程145项目驱动项目可以多种方式开始：迫切的需要、高明的想法、参考他人的产品、长期的困扰项目最初，要解决以下问题：目标、范围、前景、成本/效果、相关人员首先，应从建立POS（项目综述）开始项目驱动项目可以多种方式开始：迫切的需要、高明的想法、参考他146从POS开始：问题/机会对一份问题或机会说明的认可是进一步论证项目的基础。对于新项目而言，首先应由起草POS开始，其内容可以源于：已知的问题/机会领域：对待解决问题提出的解决方案客户要求：内部或外部客户对产品或服务提出的需求团队主动性：内部改进的需求强制性要求：因市场变化、客户要求、国家法律或其他原因引发的。从POS开始：问题/机会对一份问题或机会说明的认可是进一步论147POS：项目目标一个项目只有一个目标，目标决定项目的目的和方向，也决定了项目的最终交付成果和产出。目标说明应当用商业语言书写。目标说明不应该包括任何具体的完成时间。目标说明的要求：S.M.A.R.T

>Specific：明确性，明确针对一个目的

>Measurable：度量性，建立进展的度量尺度

>Assignable：授权性，每个目的都可授权给具体人

>Realistic：现实性，利用可用资源能完成什么

>Time-related：时间相关，何果可以达到该目的POS：项目目标一个项目只有一个目标，目标决定项目的目的和方148POS：项目目的项目目的是对项目目标的详细说明，是为了明确目标说明的准确界限和定义项目的范围。目的说明的是一种未来状态，而不是基于活动的。目的陈述应包括以下部分：

>产出：项目将要完成什么

>时间框架：预计完成时间

>度量：评价成功的尺度

>行动：如何达到这一目的POS：项目目的项目目的是对项目目标的详细说明，是为了明确目149POS：成功标准为什么要做这个项目—即这个项目产生的可度量的商业价值采用的表述方法类似于：增加的利润、增加的纯收入、减少的处理时间、提高的生产力、降低的生产或销售费用例如：项目将把定单的处理时间降低6%POS：成功标准为什么要做这个项目—即这个项目产生的可度量的150POS：假设、风险和障碍列表想引起管理层关注的可能影响项目结果的各种因素，常见的因素主要有以下几种：

>技术：缺乏对新技术的经验…

>环境：诸如一个不稳定的或变化频繁的管理机构可能会在一夜之间将一个高优先的项目变成低优先级的

>人际关系：项目团队成员之间的关系很重要

>文化：项目是否适合企业？…

>因果关系：对某些因素的假设如果不

成立，将影响最终结果POS：假设、风险和障碍列表想引起管理层关注的可能影响项目结151POS：附件风险分析财务分析费用/收益分析收支平衡分析投资回报（ROI）POS：附件风险分析152合同内部开发：为自己的需要，在内部进行。通常客户与IT部门合作编写并签署规格说明。它也应指定交付时间，以及任务、费用的分担产品开发：开发公司将在市场上销售的商业产品成品购买：供应商交付一个现成的产品招标：发出投标要求（RFP），同时提供由客户或顾问编写的需求规格说明

>资格预审>合同签署合同开发：供应商为客户开

发并交付系统合同内部开发：为自己的需要，在内部进行。通常客户与IT部门合153比较建议书普通需求：对需求的平均或总体评价最弱需求：某些重要需求无法得到充分的支持产品类总分：上述两项之和理解具体问题：只是简单说明能够满足需求，但未提供证据表明如何满足历史记录：在相关行为的经验可靠性：供应商财务状态总分数：以上总和基本价格：基本版本的价格选项1~n：各可选项的价格比较建议书普通需求：对需求的平均或总体评价154比较建议书比较建议书155需求的评价为每项需求指定优先级说明可选的需求，供应商可以单独的价格实现或忽略采用“开放尺度”或“开放标准方法采用”任务及支持“技术说明需求需求的评价为每项需求指定优先级156编写建议书供应商完成必须提供客户所要求的所有信息应该说明如何解决其问题编写建议书供应商完成157设计与编程直接实现：逐项实现需求，同时完成由需求至设计或代码的追踪验证：逐一考虑每项需求，检查是否已实现嵌入式的追踪信息：为每段代码或设计的每个部分，说明所处理的需求编号设计与编程直接实现：逐项实现需求，同时完成由需求至设计或代码158验收测试与交付安装测试：保证硬件、软件已为下一步测试做好了准确系统测试：检查产品是否完成了所有能够在开始日常运作之前就验证的需求部署测试：检查产品能否使用生产数据进行日常支作验收测试：检查产品能否处理所有任务的变体，以及是否已安装好，可以投入日常运作，

内容包括系统测试+部署测试运作测试：检查另一部分需求，即

只有经过一段时间运行才能测试的验收测试与交付安装测试：保证硬件、软件已为下一步测试做好了准159需求管理建立变更控制部门（CCB）报告：记录日期、来源、说明分析：新要求？修改请求？误解？真实需要是？客户可能结果是？完成该请求的成