需求分析师培训

需求分析师培训,Day03,Agenda,需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结,Agenda,需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结,需求建模实例确定业务需求,总经理：为什么我们的开发项目进度计划总是那么不准确，延期经常出现，更可恨的是甚至无法给出一个相对比较明确的延迟时间。这样给市场的推广会带来很大的影响，不确定因素使得应对十分困难。研发经理：唉这个问题我花了很多时间来解决，但一直收效不好。最初我用WBS方法，根据用例包、用例的方式来组织需求，然后将某个用例或子用例作为工作任务分配的开发人员，并指定了相应的完成时间，但到了时间开发人员总是完不成，都反应时间安排不合理。后来，在技术顾问的指导下，改为自底向上的估计方法，任务明确后让开发人员反馈工作量及所需的工作天数。虽然有所好转，但还是有一些工作任务，开发人员反馈的天数到了，仍然无法完成，甚至无法告诉我要延迟多少天。汇总起来，就形成了这样的结果了。总经理：这样呀，那有什么好办法呢？技术顾问：其实问题的关键还是在于“估算”的经验上，对于软件开发而言，实际上没有万能的、准确的估算公式,需求建模实例确定业务需求,（研发经理抢过话题）研发经理：对对对！我一直在尝试使用FP、COCOMO模型来，仍然得不出合理的估计值，真难办。技术顾问：呵呵，急了！其实估算的基础是经验数据，对于不同的开发人员而言其产能是不一致的，甚至对于相同的开发人员而言，不同的任务所需的时间也是不同的。因此关键在于积累这种经验数据。例如，我在编写技术书籍时，就采用了PSP（个人软件开发过程）的思路，对所有的工作过程进行了时间的记录，在半年之后，就积累了许多相关的产能数据，现在给编辑的时间承诺总是能够比较的准确。总经理：哦，难怪你做的承诺都一般很少延误，这种经验能否适用于软件开发的管理呢？技术顾问：呵呵，这是当然。PSP是个人软件开发过程，它本来就是为软件开发设计。它是CMM的创始人提出的，PSP、TSP和CMM分别针对软件开发员、软件开发小组和软件开发组织。通过PSP的贯彻，就一定能够提高软件开发人员的时间安排、时间估算的能力。,需求建模实例确定业务需求,研发经理&总经理（几乎同时）：那我们就尝试一下！技术顾问：哈哈，不过贯彻PSP有两个困难。一是开发人员很难适应，每天都要记录自己的工作时间很繁琐，而且产生数据不容易使用；二是时间日志做出来后，管理者会忍不住用来考核开发人员，给他们带来心理压力。研发经理：那我们可以开发一套软件来帮助他们记录，通过写到数据库中，这样数据的使用问题也就解决了。技术顾问：对，这就是我的建议。那后者呢？总经理：我们不考核就是了！技术顾问：没那么简单！我认为要从以下几点来进行：一是鼓励，鼓励记录时间日志，奖励估算准确的开发人员，从而避免做假时间的情况；二是宣扬，宣扬有效工作时间的概念，我的经验是每个开发人员一天有效的工作时间在4个小时之上就是比较好的，树立这种概念能够打消开发人员的顾虑；三是培训，从理论高度建立开发人员执行PSP的意识。,需求建模实例确定业务需求,总经理：好！我修订绩效考核，解决鼓励问题；小陈(研发经理)，我配合你树立“每天有效工作4小时”的概念；至于培训嘛只好拜托你了。技术顾问：好！没问题。,为开发人员提供一个PSP工具，简化时间记录工作；同时提供数据使用的工具，帮助开发人提高估算能力。,需求捕获,技术顾问：根据我的经验，整个系统应该包括以下几个主要的方面。第一，项目及任务安排，由研发经理或项目经理创建项目和任务，开发人员在接到任务后进行估算填写时间计划，研发经理或项目经理对其进行确认。第二，时间记录，开发人员对自己的开发时间进行记录，与任务关联起来。第三，产能分析，研发经理及公司领导可以根据任务和相应的时间记录，来统计公司员工的产能数据。开发人员甲：我认为，开发人员自己应该能够通过这套系统来统计自己的产能数据。研发经理：那么产能数据怎么表示呢？任务可是不同的呀。技术顾问：我认为比较合适是KLOC/天(每天编写的千代码行数)。开发人员乙：但不同的程序KLOC可能接近，但难度不同所花的时间是不同的。技术顾问：对，我们可以在每个任务中加上难度系数，产能中的KLOC=实际的KLOC*难度系数。研发经理：那么测试任务怎么算？,需求捕获,技术顾问：我认为这套系统主要关注的是开发时间、而对于前期的分析和概要设计，以及后续的集成和系统测试等工作可以先忽略，放在系统范围之外，这里只考虑详细设计、编码和相应的测试工作。研发经理：我明白了，就是对于一个任务而言所花的时间。对，这样比较合理。开发人员甲：我希望系统能够在让我们填写估算值时，可以查询历史数据，否则仍然没有意义。开发人员丙：查询历史数据时，还应该有类别吧！这样我们才能够根据自己将要完成的任务情况找到有参考依据的统计数据。开发人员乙：还有就是时间记录一定要方便，另外像我们这样经常要在现场开发，如何完成时间记录？研发经理：可以考虑有一个离线版本的时间记录程序，等回公司连接服务器后再进行数据同步。,获取需求特性表,建立概念模型发现类,建立概念模型关联分析,建立概念模型职责分析,建立用例模型识别参与者,建立用例模型合并特性获得用例,建立用例模型合并特性获得用例,建立用例模型绘制用例图,建立用例模型简要描述用例,建立用例模型划分用例优先级,建立用例模型详细描述用例,建立交互/状态模型,用户界面设计,Agenda,需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结,业务流程是信息系统的主脉落业务规则是变化的要点,什么是流程,目标性：有明确的输出内在性：包含于任何事物或行为中整体性：至少由两个活动组成动态性：由一个活动到另一个活动进行层次性：组成流程的活动本身也可以是流程结构性：串联、关联、反馈等,流程设计的原则,流程应以产出为中心，而非任务为中心让那些需要得到流程产出的人自己执行流程将信息处理工作纳入产生这些信息的实际工作中去将各地分散的资源视为一体将并行的工作联系起来，而不是仅仅联系他们的输出在决策点位于工作执行的地方，在业务流程中建立控制程序流程多样化单点接触客户,在IT系统中实现流程设计的本质,绘制流程图的核心步骤,提出业务流程清单：确定有哪些流程、流程之间的界限，然后才是对流程的描述流程的要素描述：针对清单上的每一流程，分析并识别现有业务活动、活动之间的关系、活动需要接受哪些信息、产生哪些数据（表单）、数据传送的路线、活动涉及哪些岗位等。重要抓住核心业务和主要活动点，部门内/外衔接、工作繁琐/反复环节、成本高/效率低/时间长的环节、任务转手次数多的环节绘制流程图：跨职能流程图、带泳道的活动图,流程的ESIA,E：清除过量产出活动间的等待不必要的运输反复的加工过量的库存缺陷、失误重复的活动反复的检验跨部门协调,S：简化表格程序沟通物流I：整合活动团队顾客供应商,A：自动化脏、累、乏味活数据采集与传输数据的分析,跨职能流程图,业务流程图系统流程图可以体现数据流向,活动图：简单活动图,活动图：带泳道的活动图,业务流程与业务规则,业务流程Action用户可以做的操作？权限控制的基础业务规则Filter用户的授权操作可以影响的数据范围？权限控制的补充用例与业务流程：多个用例属于一个流程用例与业务规则：一个业务规则应用于多个用例,业务流程与业务规则,结构事实：必须成立的事实或条件。例如：与客户第一次接触的永远都是销售人员。行动约束：根据某种条件禁止的一种或多种行动。例如：不接受具有不能接受的信用历史记录的支票。行动触发：当一个或多个条件转为真时，触发某个行动。例如：当所选商品准备齐后，立即发货。参照：当一个或多个条件转为真时，得出某种结论。例如：在一年内飞行10万公里以上的会员将成为金卡会员计算：根据一组值计算另一个值。例如：销售量是商品总零售额，但是没有包含税收部分。,Agenda,需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结,数据是系统的核心内容,数据需求分析与建模,数据流通过程：数据流图（DFD）数据存储方式：实体-关系图（ERD）数据定义方式：数据字典（DD）数据需求分析与设计要素,数据流图：基本元素,输入数据在此进行变换产生输出数据，其中要注明加工的名称,数据输入的源点或数据输出的汇点，其中要注明源点和汇点的名称,存放数据的地方，这些数据在以后使用，通常与实体-联系图中的一个数据实体相对应,被加工的数据与流向，箭头边应给出数据流名字，可用名词或名词性短语命名,当过程/加工执行时，外部实体与过程之间来回通信,数据存储/文件,数据流,实时连接,过程/加工,外部实体/源/宿,数据流图：图的结构,数据流图：分层的DFD,绘制数据流图：构建顶层图,绘制数据流图：绘制DFD片断,绘制数据流图：将DFD片断合并,数据建模过程,E-R图,概念结构设计的方法,实体-关系图：图例,实体分析法,确定局部视图的范围：实体的个数应适量识别实体及标识确定实体间的联系分配实体及联系的属性,识别实体及标识,实体分析法：确定实体间联系,一对一关系：两个实体都是强制性的仅有一类实体是强制的两类实体均非强制性的一对多关系多端强制性多端非强制性多对多关系,确定实体间联系时的陷阱,E-R图到关系模式的转换,实体模型：每个实体转成一个模式客户（客户名，身份证号，地址，联系电话）一对一关系模式：在两个关系模式中的任意一个模式中，加入另一个模式的键和联系类型的属性校长（姓名，性别，职称，年龄，校名，任职时间）学校（校名，地址，电话）,E-R图到关系模式的转换,一对多关系模式：在n端实体类型对应的关系模式中加入1端实体类型的键和联系类型的属性,校长（姓名，性别，职称，年龄，校名，任职时间）学校（校名，地址，电话）,E-R图到关系模式的转换,多对多关系模式：将联系类型也转换成关系模式，属性为两端实体类型的键加上联系类型的属性,学生（学号，姓名，性别，年龄）课程（课程号，课程名，授课老师）考试（课程号，学号，成绩）,数据字典应用,数据元素说明数据元素名或标识：即对用户而言有意义的名称；别名：可选择的名字类型和长度：说明数据元素的组成部分，是数字、字母还是其他；而长度则是指其最大的组成个数默认值：即数据元素的一个初始值；可接受的值：即数据元素有效的合法取值范围数据源：即对数据元素值的起源点的具体说明安全：对于有权访问或更新每个数据元素的人或部门的标识有责任用户：负责输入/改变数据元素值的用户标识描述和评论：加上一些更好的说明数据元素的注解,数据字典应用,数据流说明数据流名或标识：即在DFD中所对应的数据流名称描述：说明数据流的用途与目的别名：可选择的名字数据源：数据流的起点目的：数据流的终止点记录：每个数据流都代表了一组被称为记录或数据结构的相关实体量和频率：描述单位时间内数据流发生的次数。,数据字典应用,数据存储（文件）说明数据存储名或标识：在DFD中对应的数据存储名称描述：说明数据存储的用途与目的别名：可选择的名字属性：输入或离开数据存储的标准数据流图名量和频率：描述数据存储中记录出现的可估计的个数和更新频度加工说明加工名或标识：即在数据流图中所对应的加工名称描述：说明加工的用途与目的加工数据标识：用来指明加工所在的层次加工描述：说明包括的输入和输出数据流,数据字典应用,外部实体说明实体名或标识：即在数据流图中所对应的实体名称描述：说明实体的用途与目的别名：可选择的名字输入数据流输出数据流数据元素说明的常用表示法：由构成：和，代表顺序连接的关系|：或，代表从中选择一个*：n次重复（）：代表可选的数据项*：表示特定限制的注释,数据字典应用实例,客户基本信息=客户编号+客户名称+身份证号码+手机+小灵通+家庭电话客户编号=098客户名称=字4身份证号码=0915|0918手机=0911|0912小灵通=（区号）+本地号家庭电话=（区号）+本地号办公电话=（区号）+本地号区号=094本地号=097|098,数据需求分析与设计要素,术语表数据结构分析，对表的内容要区分主要字段和次要字段稳定字段和不稳定字段即时记录和历史记录另个需要考虑联机事务需要报表需求决策查询需求数据量与增长速度（数据查询失效案例）性能与扩展并发可能性与数量,数据需求分析与设计要素,数据共享考虑数据库、文件、XML逐段加密问题数据Filter原则谁建立？谁修改？谁查询？谁应用？数据挖掘与分析查询报表从规则入手BI数据挖掘，仓库（电信数据整合）,数据仓库,Agenda,需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结,规格说明书是需求“圣经”,需求描述最佳实践1,定义描述需求的标准模板：在书写具体的系统需求时，应该定义一系列的标准模板用于组织需求描述。模板应该包括一些字段，通过填写这些字段，可以完整地说明一项需求。主要效益：需求前后一致，因而更加易懂引入成本：中应用成本：低使用浅显、一致、简明的语言：当使用自然语言表达某项需求时，应注意使用浅显、简明的语然言一描述，避免使用复杂的句子结构、冗长的句子和不明确的术语。主要效率：需求更加易读易懂引入成本：相当低应用成本：低-中,需求描述最佳实践2,适当地使用图解：当需要表示结构化的信息或者需要表达需求描述中信息之间的关系时应当使用图解，图解还可以用于概括数字信息或描述事件和行为序列。主要效益：图解最适于记录需求关系引入成本：低应用成本：低实施指南：应使用图解的典型情况包括当某个对象（系统、文档）由多个模块和组件组成，而你又希望阐明它们之间的相互关系时；当需要表达一系列的行为，每个行为都有一些输入和输出时；当需要说明空间组织时；当需要使用一些分解结构时。但要避免使用含义不清晰的图案（如Word中的剪贴画）,需求描述最佳实践3,用其他需求描述辅助自然语言：某此需求更适于使用特殊的方式书写，如数学公式、决策表等。主要效益：更加简明、无二义性的需求描述引入成本：很低应用成本：低定量说明需求：只要有可能，就应该使用定量的数值说明系统的需求，非功能需求最有可能采用这一点。主要效益：无二义性地表达需求引入成本：低-中应用成本：低-中实施指南：定义表达这些属性的合适的度量；为属性决定一个合适的值。,非功能需求可以使用度量,可靠性：出错时间、错误发生率有效性：请求后出错的可能性性能：每秒处理的事务数，对用户输入的响应时间存储利用：系统最大的尺寸(MB)可用性：学习75%的用户功能所需要的时间，在给定时间内由用户引起的错误的平均值健壮性：系统出错后重新启动的时间完整性：系统出错时，允许的数据丢失的最大限度,数据需求的描述形式,数据模型：E-R模型框图：描述产品内、外的数据非常适合专家使用，但不便于用户使用数据词典：产品内、外数据的文字描述非常适合专家及用户数据表达式描述数据序列的简洁公式，适合于描述复合数据及消息协议非常适合于专家使用，也为许多用户所接受虚拟窗口简化的屏幕图像，有图像、真实数据，但无按钮、菜单非常适合专家及用户，非常适合于规划新的界面,功能需求的形式1,人、机职责划分：可采用DFD、UML表示域模型：人、机结合的模型物理模型：人、机各自的职责产品层需求：人、机职责划分,功能需求的形式2,上下文图：说明产品及其环境的图示为开发人员概括了所有接口大多数客户能不费力地理解上下文图,功能需求的形式3,事件列表与功能列表：产品要处理的事件，人、机合作处理的事件域事件实例：客人预订客人入住客人退房换房提交服务记录产品事件实例查找空闲客房记录客人信息查找客人数据记录预订数据打印预订确认记录入住数据退房记录服务,功能需求的形式4,特性需求：文字形式，该产品应记录/显示/计算，很多人认为这是惟一可以接受的需求形式可能给用户及分析人员造成错觉实例：该产品应能将客户在某一期限内设为维修状态该产品应能够显示、打印下两周的人员配置表。该配备应以客房占用的历史数据为依据。该产品也应支持根据客户类型，而不是客房号的预订。客人入住时才分配实例客房,功能需求的形式5,屏幕显示及原型：包括屏幕图像及”按钮“的功能，若经仔细测试可以作为很好的设计层需求实例：,功能需求的形式6,任务说明：结构化的文字说明，用于描述用户任务；便于客户、开发人员理解；便于说明任务变体以及复杂的任务实例：,功能需求的形式7,由任务说明到产品特性：用任务说明解释产品特性；有助于理解、确认特性任务及支持：结构化的文字说明，描述任务、域问题，提出可能的方案。,功能需求的形式8,场景说明：说明一项或多项用户任务，或要测试的一个特殊情况，有助于增进开发人员的直觉，通常不作为需求。实例：夜班由于学习了一整个下午，张三在下午6点开始值夜班时，已感觉到有些疲倦。他的第一项任务是为将在7点钟抵达的客人团做准备，他打印了所有的入住登录表，并将它们同各自的客房钥匙放在一起。在处理这项任务时，来了一个家庭询问客户的情况。他们想讨价还价，这是张三最不擅长的工作。是否应该给他们提供折扣呢？正好李四从办公室里出来，她微笑地告诉他们：可以为小孩的房间提供10%的折扣。他们接受了，于是张三为他们安排房间，他们希望挨着的两间客户，但是张三总是记不住哪些客遍及是挨着的。,功能需求的形式9,用例数据流图以“标准”作为需求以“开发过程”作为需求,非功能需求的形式1,开放尺度与开放目标：通常要求达到某个数字目标。实例：该产品应能检测超速，并在0.5秒内完成拍照该产品应能够2分钟内计算并显示客户占用情况的预报表Planguage表示法：,非功能需求的形式2,能力及准确度需求,非功能需求的形式3,性能需求,需求规格说明书,规格描述的形式文档：用结合合理的自然语言精心编写图形化模型：描述转换过程、系统状态以及变化、数据关系、逻辑流或者对象类及其关系形式化规格说明：逻辑语言(伪码、决策表、决策图)常用模板ISO/GB版：面向结构化分析方法的，较陈旧RUP版：以面向对象分析方法，用例驱动Volere版：很实用的一个第三方公司版本AtlanticSystemGuild（）公司,1引言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控制说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。,RUP版需求规约1.文档概述1.1目的1.2范围1.3定义、首字母缩写词和缩略语1.4参考资料1.5概述2.整体说明让读者对整个软件系统的需求有一个框架性的认识。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。2.1用例模型2.2假设与依赖关系3.具体需求3.1用例描述3.2补充需求易用性、可靠性、性能、其它4.支持信息,Volere版：产品的目标,该项目工作的用户问题或背景内容：对引发开发任务的工作和情况的描述动机：为该项目提供合法理由例子：用户对订单到达所需的时间(10天)感到不满考虑：用户问题是否严重，是否应解决，如何解决产品的目标内容：我们希望产品做什么？动机：缺少表述清晰、易于理解的目标，会使项目开发迷失方向例子：我们希望对顾客通过电话下订单订购我们的产品作出立即和完整的响应。考虑:是否指派一个人作为“目标管理人”,Volere版：客户/顾客,客户：为开发付费的人内容：指出客户的名称动机：是最终接受该产品的，必须对该产品满意例子：公司客户服务部考虑：有时客户是间接，那么选择间接部分中的一个人作为客户顾客：花钱购买该产品的人内容：顾客的名称或特征动机：它是决定产品价值的人其它风险承担人内容：Stakeholder列表动机：各方需求源,Volere版：产品的用户,产品的用户内容：用户分类、用户工作任务、主题相关经验、技术经验、其它特征(身体、智力、工作态度、技术态度、教育、语言、年龄、性别等)动机：了解用户在确定产品易用性、设计偏好时很重要用户优先级内容：关键用户、次要用户、不重要用户动机：更好地满足不同的用户,Volere版：需求限制条件,解决方案限制条件内容：解决方案中必须采用的或不能采用的方式例子：产品必须使用WindowsNT系统，必须是一个手持设备考虑：有解决方案限制一个边界实现环境内容：将实施的技术、物理环境动机：要求解决方案必须适应的环境伙伴应用、COTS(外购软件包)预期工作场地环境开发时间、预算,Volere版：命名标准和定义,定义项目中使用的所有术语内容：一个字典，包括使用的所有名称的含义，应使用标准名称动机：减少项目开发过程中的概念澄清，减少需求歧义例子：现值：总额/(1+年利息)年考虑：利用已有的数据字典或词汇表WiKi管理，十分理想！避免二义性的词和同义词,Volere版：相关事实和假定,相关事实：可能对产品产生影响的外部因素内容：对产品产生影响的其他因素、系统和活动动机：提醒开发者可能对需求产生影响的一些情况和事实例子：原有应用程序主要的问题就是查询操作太多，无法使用假定内容：需求开发过程中所做的假设清单，对产品开发有影响动机：假定与事实是相对的，它不一定是真实的例子：用户能力的假定、外部系统的性能假定短信服务器能够完成每秒20条的发送任务,Volere版：产品的范围,工作的上下文范围内容：上下文范围图动机：清析地定义系统的边界工作切分内容：事件清单，确定工作系统要响应的业务事件，可以用“事件列表”或“用例列表”来表述动机：确定工作系统的逻辑上的大块例子：用户能力的假定、外部系统的性能假定产品边界内容：用例图，确定用户和产品的边界,Volere版：功能/数据和观感需求,功能需求内容：产品必须执行的动作描述例子：当短信发送失败时，给发送人一个消息提示验收标准：取决于要求做的动作数据需求内容：E-R图或类图表示要保存的数据，DFD表示数据流通动机：澄清产品的主题内容观感需求内容：外观设计的要求与部分原型动机：外观是产品的有机组成部分，且很重要例子：界面主色调应与公司VI吻合，应表现出稳重考虑：明确客户对产品外观的观点,Volere版：易用性需求,易于使用内容：预期用户应该如何容易地操作产品动机：指导产品设计者构建符合最终用户期望的产品例子：产品应该帮助用户避免犯错；不懂英文的用户也能操作验收标准：使用一个月后，总的错误率应是多少；经过熟悉期后，百分之多少的不懂英文用户同意能够操作学习的容易程度内容：学习时间和方式的要求动机：量化可接受的用户学习时间例子：工程师参加了一周培训后，应该能使用该产品验收标准：软件使用培训结束后的最后测验中，工程师应到一个大家同意的百分比的通过率,Volere版：性能需求,速度需求内容：明确完成特定任务需要的时间，即响应时间动机：对特定应用而言，响应时间很重要例子：产品必须每秒钟完成20条以上的短信发送验收标准：可测量的描述考虑：不同速度需求，对于设计与开发影响甚大安全悠关的需求内容：对可能产生人身伤害、财产损失和环境破坏所考虑的风险的量化描述。精度要求内容：量化描述输出结果的精度要求例子：所有有关钱的数据都精确到小数点后两位,Volere版：性能需求,可靠性和可用性需求内容：量化可靠性，平均无故障时间、总失败率动机：有些系统，可靠是十分重要的例子：产品应能够达到100小时的平均无故障时间容量需求内容：吞吐量和产品存储数据容量的要求动机：保证产品有能力处理期望和数据量例子：在上午9:0012:00应满足300个并发用户使用，其它时间最大负载为150个并发用户,Volere版：操作需求,预期的物理环境内容：明确产品将操作的物理环境动机：指出可能需要特殊需求、准备或培训的情况例子：所有的用户都是站立着操作的该系统的预期的技术环境内容：硬件和其他组成新产品操作环境的设备的规范动机：确定所有新产品要交互的元件或组成部分伙伴应用程序内容：必须与之交互的其他应用程序动机：避免在实现阶段才发现例子：必须能够与任何Web浏览器交互,Volere版：可维护性和可移植性,维护该产品需要多容易内容：对产品作特定修改所需的量化描述动机：让每个人意识到产品维护的需要例子：新添一种在原有数据基础上生成的报表格式，需要提出后一个工作周内提供是否存在一些特殊情况适用于该产品的维护内容：关于预期的产品发布周期和将采取的形式规定动机：将每年根据使用情况发布一次更新版可移植性需求内容：产品必须支持的其他平台或环境的描述动机：量化客户和用户关于产品运行平台的期望例子：必须能够运行在Windows英文版、日文版上,Volere版：安全性需求,该产品是保密的吗内容：关于谁被授权使用该产品动机：理解并突出指明对产品安全保密方面的预期需求例子：员工的个人记录只有直接经理可以读取考虑：是否存在管理层敏感数据？是否会导致损害或可能用于个人获利的过程？是否有人不应有权使用该产品？文件完整性需求内容：关于所需数据库和其他文件完整性方面的说明考虑：信息如何使用？过时信息会有什么影响？审计需求内容：需要审计检查方面的规格说明动机：构建符合相应审计规定的产品,Volere版：文化和政策/法律需求,文化和政策需求内容：针对社会和政策因素的规格说明动机：写明在开发者文件经验范围之外的需求例子：不要使用会令xx语系人民不快的图标考虑：是否熟悉最终用户的文化环境该产品是否受到某些法律管制内容：明确该产品的法律需求的描述例子：用户隐私数据不提供任何有助于传播的功能支持是否有一些必须符合的标准内容：明确适用的标准和参考的详细标准的描述考虑：标准业界组织？行业规则？特殊开发步骤？数据规范？,Volere版：开放式问题与COTS,开放式问题内容：对未确定但可能对产品产生影响的因素进行描述动机：公开不确定性例子：即将执行新的行业法规是否对软件产生影响尚未确定是否有一些成品可以购买是否可使用成品组件是否有一些我们可以复制的东西,Volere版：开放式问题与COTS,新产品会在当前环境中带来什么问题内容：新产品如何影响当前环境，不应该做什么动机：尽快发现任何潜在冲突例子：短信发送成功与否直接影响业务员工作业绩新的开发是否将影响某些已实施的系统现有用户是否会对新产品产生敌对影响预期的实现环境是否会对新产品有限制是否新产品会带来其他问题,需求项框架：Volere需求白卡,Volere白卡各项说明,需求编号：为了可追踪需求类型：可自己定义一个编号类表事件/用例编号：涉及的业务事件、用例描述：该项需求的意图理由：存在该需求的原因来源：需求提出人、部门、联系方式验收标准：必须达到的最化标准满意度/不满意度：1-5量化，乘积进行排名依赖关系：与其它需求的相关性冲突：与其它需求的冲突支持材料：相关补充说明材料历史：修改记录,Volere白卡示例,25,如果一个气象站传送读数失败，产品将发出警告。,传送读数失败可能表明气象站失效并需要维护，并且用于预测结冰的数据可能不完整,道路工程师,对每个气象站，当每小时记录下来的各类读数个数不在制造商规定的范围之内时，产品将通知用户,3,5,无,无,Rosa气象站规格说明书,GBS在05.03.12提出,Volere白卡示例,113,易用性,6,7,8,9,10,产品应该对道路工程师易于使用,工程师不必为了使用该产品而参加培训课程,Sonia,Henning,道路工程管理者,一个道路工程师将在首次接触该产品的一小时内，能够成功地执行指定的用例,3,5,无,无,HW在05.03.12提出,需求文档编写原则,使用语法、标点正确的完整句子，使语句的段落简短明了采用主动语态的表达方式：如“该系统将”，而非“将发生”使用的术语应与术语表中定义的术语保持一致将含糊不明确的顶层需求分解成足够详细的几个需求，消除歧义需求声明应该具有一致的风格，例如“系统将”，“用户将”当以“用户将”格式说明时，尽可能明确参与者使用列表、数字、图和表来表示信息强调最重要的信息避免使用语义不清的词语以相同的详细程序编写详细程度的把握：可以单独测试,歧义术语与改进,可接受、足够：具体定义可接受的内容和系统如何地此进行判断差不多可行：不要让开发人员来确定什么是可行的至少、最小、不多于、不超多：指定能够接受的最大值和最小值在之间：定义终点是否在此范围内依赖：描述依赖性的本质，是提供输入？是提前安装支持软件？有效的：定义系统如何有效地使用资源，系统执行特定的操作的速度如何，用户使用系统的容易程度如何灵活的：描述一种方式改进的、更好的、更快的、优越的：定量说明包括、包括但不限于、等等、诸如：项目列表应包含所有可能性最大化、最小化、最优：陈述对某些参数所接受的最大值和最小值,歧义术语与改进,一般情况下、理想情况下：描述系统在异常和非理想条件下的行为可选择的：指明是系统选择、用户选择还是开发人员选择合理、在必要的时候、在适当的地方：清晰解释如何判断健壮的：定义系统如何处理异常和如何响应预料外的操作条件无缝的、透明的、优雅的：将用户期望转化成能够观察的特性若干：具体是多少，最小边界值和最大边界值不应该：试着以肯定句来描述最新技术水平：描述其具体含义充分的：指定具体包括哪些内容支持、允许：精确定义系统将执行哪些功能用户友好、简单、容易：描述系统特性，这些特性将达到客户的使用需要和对易用性的期望,需求修正,原描述：后台任务管理器必须在固定的时间间隔内提供状态消息，并在每次时间间隔不得小于60秒。什么是状态消息？什么条件下和以什么方式向用户提供这些消息？显示时间是多长？间隔时间不太明确，1毫秒行吗？修改后：后台任务管理器应该在用户界面的指定区域显示状态信息在后台任务进程启动后，消息必须每隔6010秒更新一次消息应该保持持续的可见性后台任务管理器在每次可以与后台任务进程进行通信时，都应该显示后台任务已完成的百分比当完成后台任务时，后台任务管理器应该显示一个“已完成”的消息如果后台任务中止执行，那后台任务管理器应该显示一个出错信息,需求修正,原描述：如果可能的话，应该根据主要法人帐号列表来在线确认所输入的帐号的有效性。如何可能是指什么？是指技术上可行？运行时间可行？如果不能确定一定要，则应该用TBD来表示！修改后：当请求者输入帐号时，系统将根据在线的主要法人帐号的列表来验证所输入的帐号。如果在此列表中找不到，则显示一个错误信息并拒绝订货。,需求修正,原描述：编辑器不应该提供可能带来灾难性后果的查询和替换选项灾难性后果是什么？如果发现这个可能带来灾难性的查询/替换？重要的关注点实际上是：发生意外损坏或丢失时能够保护内容修改后：1.编辑器将要求用户确认全局性文本改动、删除和插入操作2.应用程序应提供多级“撤消”功能,Agenda,需求建模实例业务流程与规则分析数据需求分析与建模需求描述最佳实践需求管理最佳实践需求过程总结,需求管理最佳实践1,惟一地标识每一个需求：应该给每一个需求分配一个惟一的标识符或者引用数字，可以用于在需求文档的其他部分或在其他系统文档中指向该需求。主要效益：明确地引用特定需求是可能的引入成本：很低应用成本：很低定义需求管理的策略：定义了需求管理的目标，应该遵循的过程和应该使用的标准。主要效益：对所有参与需求管理的人提供指导引入成本：中等应用成本：低,需求管理最佳实践2,定义可跟踪性策略：应定义应用维护哪些可跟踪性的信息以及该信息应该怎样表示，可跟踪性信息是可以发现需求间、需求和系统设计、组件和文档间依赖性的信息。主要效益：维护所有系统的一致的可跟踪性信息引入成本：中等应用成本：中等-高维护可跟踪性手册：它是对需求文档的一个补充，包含了在项目中使用的特定的跟踪性策略和需求的可追踪性信息。主要效益：作为所有特定项目的可跟踪性信息的中心记录引入成本：低应用成本：中等-高,需求管理最佳实践3,使用数据库来管理需求：建立一个需求数据库，把单个需求作为条目存储进数据库，而不要用文本文档来维护需求。主要效益：使管理大量的需求变得容易引入成本：中等-高应用成本：中等实施指南：需求是怎么表达的？自然语言、图形模型、数学表达式？一般需要管理多少需求？需求总是由在同一地方工作、使用相同类型电脑的小组开发和管理的吗？已经使用一个支持软件工程的数据库了吗？有内部的数据库专家吗？需求工程师负责数据库管理吗？,需求管理最佳实践4,定义变更管理策略：陈述了变更是以何种形式提出、分析和评审的。然后实现已接爱的变更，产生一个新版本的需求文档。主要效益：提供一个系统地评估变更提议的框架引入成本：中等-高应用成本：低-中等实施指南：应包括变更请求过程和处理每个变更请求所需的信息；用来分析变更的影响和成本以及相关的可跟踪性信息的过程；正式考虑变更请求的成员人数；变更控制的软件支持,需求管理最佳实践5,标识全局系统需求：是在总体上说明了系统想要的或者必须的属性。它们不能够赋予单独的子系统。主要效益：找到变更成本最大的需求引入成本：低应用成本：低标识易变的需求：应该维护一个易变的需求列表，即那些最可能发生变更的需求。如果可能，应该对这些需求的变更进行预测。主要效益：简化需求变更管理引入成本：低应用成本：低记录丢弃的需求主要效益：当其再次提出时，保存再分析结果引入成本：低应用成本：低,软件开发中的V字模型,需求评审：方法,非正式评审：同级桌面检查：请一位同事检查轮查：同时请若干同事分别检查走查：作者向评审人员描述，并要求做出评论正式评审同级评审(审查)：最有效的软件质量技术,需求评审：方法,非正式评审：同级桌面检查：请一位同事检查轮查：同时请若干同事分别检查走查：作者向评审人员描述，并要求做出评论正式评审同级评审(审查)：最有效的软件质量技术,需求审查过程,参与者需求规格说明书的作者、同级伙伴提供规格说明信息的人：分析员、客户要根据规格书开展工作的人：开发人员负责相关接口工作的人总人数：作者主持人读者记录员,需求审查：开始标准,文档遵循标准模板文档已经进行过拼写检查作者已经检查了文档在版面上的错误已经获得了审查前需要阅读的文档或参考文档在文档中标上了行号，便于查阅所有未解决问题已标上了TBD主持人检查10分钟后，找不出3个以上重大错误,需求审查：主要阶段,规划：谁参加？准备什么材料？总体会议：确定审查的背景、假设及目标准备：审查员阅读材料审查会议：主持人引导返工：审查结果修改跟踪：确定错误已修正,需求审查：要点,需求的完整性是否存在遗漏的内容是否对所有风险承担者都有考虑需求的可追踪性惟一标识符号类型说明对用例的引用冲突描述一致使用术语,需求审查：要点,是否与目标相关产品将维护一个查询表，记录一年中日出和日落时间检查验收标准在限制条件下是否可行是需求还是解决方案顾客价值与镀金需求需求蔓延,变更管理应确保的事项,应仔细评估已建议的变更挑选合适的人选对变更做出决定变更应及时通知所有涉及的人员项目要按一定的程序来采纳需求变更,控制项目范围的扩展,对许多项目而言，需求的改进是合理且不可避免首先应把新系统的视图、范围、限制文档化并作为业务需求的一部分对于控制范围扩展的方法是要敢于说“不”基线+变更过程是解决项目范围扩展的重要手段,变更控制过程,好的变更控制过程给项目风险承担者提供了正式的建议需求变更机制变更控制过程并不是给变更设置障碍，而是提供一个渠道和过滤器控制需求变更同项目的其他配置管理决策是紧密相连的，管理需求变更类似于跟踪错误和做出相应决定的过程,变更控制策略,所有需求变更必须遵循的过程，按照此过程如果一个变更需求未被采纳，则其后过程不再予以考虑对于未批准的变更，除可行性论证之外，不应再做其他设计和实现工作简单请求一个变更不能保证能实现变更，要由项目变更控制委员会（CCB）决定实现哪些变更项目风险承担者应该能够了解变更数据库的内容绝不能从数据库中删除或修改变更请求的原始文档每一个集成的需求变更必须能够跟踪到一个经核准的变更请求,变更控制步骤,每个变更控制步骤由4个组件组成：开始条件：在执行过程或步骤前应该满足的条件过程和步骤中所包含的不同任务及项目中负责完成它们的角色验证任务正确完成的步骤结束条件：指出过程或步骤完成的条件,描述变更控制步骤,概述：说明此步骤的目的，确定步骤能够应用的范围角色和责任：列出参与变更控制活动的项目组成员并且描述他们的责任（CCB主席、CCB、评估者、修改者、建议者、项目管理者、请求接受者、验证者）变更请求状态开始条件任务验证退出条件变更控制状态报告,变更需求状态转换,变更控制工具,可以定义变更请求的数据项可以定义变更请求生存期的状态转换图可以加强状态转换图使经授权的用户仅能做出所允许的状态变更记录每一种状态变更的数据，确认做出变更的人员可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员可以根据需要生成标准的或定制的报告和图表,变更控制委员会(CCB),CCB是业界的最佳实践，可以由一个小组或多个不同的组担任，负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用负责对项目中任何基线工作产品的变更做出决定CCB的组成：项目管理部门产品管理或需求分析部门开发部门测试或质量保证部门市场或客户代表用户文档部门技术支持部门配置管理部门,测量变更活动,软件测量是深入项目、产品、处理过程的调查研究需求变更活动的下列方面值得考虑：1）接收、未作决定、结束处理的变更请求数量2）已实现需求变更的合计数量3）每个方面发出的变更请求的数量4）每一个已应用的需求建议变更和实现变更的数量5）投入处理变更的人力、物力可以通过线划图、直方图来表示,需求跟踪,跟踪能力（联系）链使你能够跟踪一个需求使用期限的全过程四类需求跟踪能力链,需求跟踪联系链,需求跟踪动机,审核：跟踪能力信息可帮助审核确保所有需求被应用变更影响分析：跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素维护：可靠的跟踪能力信息使得维护时能够正确、完整地实施变更，从而提高生产率项目跟踪：认真记录跟踪能力数据，可以获得计划功能当前实现状态的记录再设计：可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置重复利用、减少风险、测试,需求跟踪矩阵,跟踪能力联系链可能的信息源,需求跟踪能力过程,决定定义哪几种联系链选择使用的跟踪能力矩阵的种类确定对产品哪部分维护跟踪能力信息通过修订过程和核对表来提醒开发者在需求完成或变更时更新联系链制定标记性的规范确定提供每类联系链信息的个人培训项目组成员一旦有人完成某项任务就要马上更新跟踪能力数据在开发过程中周期性地更新数据,变更影响分析,变更请求ID号：.标题：.描述：.分析人员：.日期：.优先级评估：相对收益：（19）相对损失：（19）相对费用：（19）相对风险：（19）计算出的最终优先级：（相对于其他待处理需求）估计的总工作量：（人时）估计损失的总工作量：（人时）估计对进度的影响：（天）额外的成本影响：（元）质量影响：受影响的其他需求：爱影响的其他任务：集成问题：生存期费问题：检查可能要变更的其他组件：,基于文档存储需求方法的限制,很难保持文档与现实的一致通知受变更影响的设计人员是手工过程不太容易做到为每一个需求保存增补的信息很难在功能需求与相应的用例、设计、代码、测试和项目任务之间建立联系链很难跟踪每个需求的状态,常用的商业需求管理工具,DOORS：以数据库为中心RequisitePro：以文档为中心，Rational公司Caliber-RM：以数据库为核心QSSrequireit：以文档为中心RTMWorkshop：以数据库中心VitalLink：以文档为中心,使用需求管理工具的好处,管理版本和变更：提供了灵活的基线设定功能存储需求属性：对每个需求可以保存相关属性帮助影响分析：可以找到需求关联跟踪需求状态：可以很容易地知识某个产品包含的所有需求访问控制：可以对个人、用户小组确定访问权限与风险承担者进行沟通：可以通过邮件自动通知重用需求：需求保存之后可以实现需求重用，避免信息冗余,商业需求管理工具的主要特点,允许定义不同种类的数据库元素，如业务需求、用例、功能需求、硬件需求、非功能需求在某种程度上实现了Word的集成，最常见的方式是在Word中添加工具籅有统一的内部标识符，支持层次编码的数字标签，例如UR00 x表示用户需求，DOORS中还能够看到层次结构的软件需求说明书工具的输出能力包括以用户自定义格式或表单报告格式，Caliber-RM提供了强大的文档加工功能有在需求同其他系统元素之间定义联系链的跟踪能力,商业需求管理工具的互集成性,RequisitePro不仅可以建立需求与Rose