需求分析师培训-3

1、需求分析师培训需求分析师培训Day03Agendal需求建模实例需求建模实例l业务流程与规则分析业务流程与规则分析l数据需求分析与建模数据需求分析与建模l需求描述最佳实践需求描述最佳实践l需求管理最佳实践需求管理最佳实践l需求过程总结需求过程总结Agendal需求建模实例需求建模实例l业务流程与规则分析业务流程与规则分析l数据需求分析与建模数据需求分析与建模l需求描述最佳实践需求描述最佳实践l需求管理最佳实践需求管理最佳实践l需求过程总结需求过程总结需求建模实例需求建模实例确定业务需求确定业务需求 总经理：为什么我们的开发项目进度计划总是那么不准确，延期经总经理：为什么我们的开发项目进度计划总

2、是那么不准确，延期经常出现，更可恨的是甚至无法给出一个相对比较明确的延迟时间。这样常出现，更可恨的是甚至无法给出一个相对比较明确的延迟时间。这样给市场的推广会带来很大的影响，不确定因素使得应对十分困难。给市场的推广会带来很大的影响，不确定因素使得应对十分困难。 研发经理：唉这个问题我花了很多时间来解决，但一直收效不好。研发经理：唉这个问题我花了很多时间来解决，但一直收效不好。最初我用最初我用WBSWBS方法，根据用例包、用例的方式来组织需求，然后将某个方法，根据用例包、用例的方式来组织需求，然后将某个用例或子用例作为工作任务分配的开发人员，并指定了相应的完成时间用例或子用例作为工作任务分配的开

3、发人员，并指定了相应的完成时间，但到了时间开发人员总是完不成，都反应时间安排不合理。后来，在，但到了时间开发人员总是完不成，都反应时间安排不合理。后来，在技术顾问的指导下，改为自底向上的估计方法，任务明确后让开发人员技术顾问的指导下，改为自底向上的估计方法，任务明确后让开发人员反馈工作量及所需的工作天数。虽然有所好转，但还是有一些工作任务反馈工作量及所需的工作天数。虽然有所好转，但还是有一些工作任务，开发人员反馈的天数到了，仍然无法完成，甚至无法告诉我要延迟多，开发人员反馈的天数到了，仍然无法完成，甚至无法告诉我要延迟多少天。汇总起来，就形成了这样的结果了。少天。汇总起来，就形成了这样的结果了

4、。 总经理：这样呀，那有什么好办法呢？总经理：这样呀，那有什么好办法呢？ 技术顾问：其实问题的关键还是在于技术顾问：其实问题的关键还是在于“估算估算”的经验上，对于软件的经验上，对于软件开发而言，实际上没有万能的、准确的估算公式开发而言，实际上没有万能的、准确的估算公式 需求建模实例需求建模实例确定业务需求确定业务需求 （研发经理抢过话题）（研发经理抢过话题） 研发经理：对对对！我一直在尝试使用研发经理：对对对！我一直在尝试使用FPFP、COCOMOCOCOMO模型来，仍然得模型来，仍然得 不出合理的估计值，真难办。不出合理的估计值，真难办。 技术顾问：呵呵，急了！其实估算的基础是经验数据，对

5、于不同的技术顾问：呵呵，急了！其实估算的基础是经验数据，对于不同的开发人员而言其产能是不一致的，甚至对于相同的开发人员而言，不同开发人员而言其产能是不一致的，甚至对于相同的开发人员而言，不同的任务所需的时间也是不同的。因此关键在于积累这种经验数据。例如的任务所需的时间也是不同的。因此关键在于积累这种经验数据。例如，我在编写技术书籍时，就采用了，我在编写技术书籍时，就采用了PSPPSP（个人软件开发过程）的思路，（个人软件开发过程）的思路，对所有的工作过程进行了时间的记录，在半年之后，就积累了许多相关对所有的工作过程进行了时间的记录，在半年之后，就积累了许多相关的产能数据，现在给编辑的时间承诺总

6、是能够比较的准确。的产能数据，现在给编辑的时间承诺总是能够比较的准确。 总经理：哦，难怪你做的承诺都一般很少延误，这种经验能否适用总经理：哦，难怪你做的承诺都一般很少延误，这种经验能否适用于软件开发的管理呢？于软件开发的管理呢？ 技术顾问：呵呵，这是当然。技术顾问：呵呵，这是当然。PSPPSP是个人软件开发过程，它本来就是个人软件开发过程，它本来就是为软件开发设计。它是是为软件开发设计。它是CMMCMM的创始人提出的，的创始人提出的，PSPPSP、TSPTSP和和CMMCMM分别针对分别针对软件开发员、软件开发小组和软件开发组织。通过软件开发员、软件开发小组和软件开发组织。通过PSPPSP的贯

7、彻，就一定的贯彻，就一定能够提高软件开发人员的时间安排、时间估算的能力。能够提高软件开发人员的时间安排、时间估算的能力。 需求建模实例需求建模实例确定业务需求确定业务需求 研发经理研发经理& &总经理（几乎同时）：那我们就尝试一下！总经理（几乎同时）：那我们就尝试一下！ 技术顾问：哈哈，不过贯彻技术顾问：哈哈，不过贯彻PSPPSP有两个困难。一是开发人员很难适有两个困难。一是开发人员很难适 应，每天都要记录自己的工作时间很繁琐，而且产生数据不容易使应，每天都要记录自己的工作时间很繁琐，而且产生数据不容易使用；用； 二是时间日志做出来后，管理者会忍不住用来考核开发人员，给他二是时

8、间日志做出来后，管理者会忍不住用来考核开发人员，给他们带们带 来心理压力。来心理压力。 研发经理：那我们可以开发一套软件来帮助他们记录，通过写到数研发经理：那我们可以开发一套软件来帮助他们记录，通过写到数 据库中，这样数据的使用问题也就解决了。据库中，这样数据的使用问题也就解决了。 技术顾问：对，这就是我的建议。那后者呢？技术顾问：对，这就是我的建议。那后者呢？ 总经理：我们不考核就是了！总经理：我们不考核就是了！ 技术顾问：没那么简单！我认为要从以下几点来进行：一是鼓励，技术顾问：没那么简单！我认为要从以下几点来进行：一是鼓励，鼓励记录时间日志，奖励估算准确的开发人员，从而避免做假时间的情鼓

9、励记录时间日志，奖励估算准确的开发人员，从而避免做假时间的情况；二是宣扬，宣扬有效工作时间的概念，我的经验是每个开发人员一况；二是宣扬，宣扬有效工作时间的概念，我的经验是每个开发人员一天有效的工作时间在天有效的工作时间在4 4个小时之上就是比较好的，树立这种概念能够打个小时之上就是比较好的，树立这种概念能够打消开发人员的顾虑；三是培训，从理论高度建立开发人员执行消开发人员的顾虑；三是培训，从理论高度建立开发人员执行PSPPSP的意的意识。识。 需求建模实例需求建模实例确定业务需求确定业务需求 总经理：好！我修订绩效考核，解决鼓励问题；小陈总经理：好！我修订绩效考核，解决鼓励问题；小陈( (研发

10、经理研发经理) )，我配，我配合你树立合你树立“每天有效工作每天有效工作4 4小时小时”的概念；至于培训嘛只好拜托你了。的概念；至于培训嘛只好拜托你了。 技术顾问：好！没问题。技术顾问：好！没问题。 为开发人员提供一个为开发人员提供一个PSPPSP工具，简化时间工具，简化时间记录工作；同时提供数据使用的工具，帮助记录工作；同时提供数据使用的工具，帮助开发人提高估算能力。开发人提高估算能力。 需求捕获需求捕获 技术顾问：根据我的经验，整个系统应该包括以下几个主要的方技术顾问：根据我的经验，整个系统应该包括以下几个主要的方面。第一，项目及任务安排，由研发经理或项目经理创建项目和任务，面。第一，项目

11、及任务安排，由研发经理或项目经理创建项目和任务，开发人员在接到任务后进行估算填写时间计划，研发经理或项目经理对开发人员在接到任务后进行估算填写时间计划，研发经理或项目经理对其进行确认。第二，时间记录，开发人员对自己的开发时间进行记录，其进行确认。第二，时间记录，开发人员对自己的开发时间进行记录，与任务关联起来。第三，产能分析，研发经理及公司领导可以根据任务与任务关联起来。第三，产能分析，研发经理及公司领导可以根据任务和相应的时间记录，来统计公司员工的产能数据。和相应的时间记录，来统计公司员工的产能数据。 开发人员甲：我认为，开发人员自己应该能够通过这套系统来统开发人员甲：我认为，开发人员自己应

12、该能够通过这套系统来统计自己的产能数据。计自己的产能数据。 研发经理：那么产能数据怎么表示呢？任务可是不同的呀。研发经理：那么产能数据怎么表示呢？任务可是不同的呀。 技术顾问：我认为比较合适是技术顾问：我认为比较合适是KLOC/KLOC/天天( (每天编写的千代码行数每天编写的千代码行数) )。 开发人员乙：但不同的程序开发人员乙：但不同的程序KLOCKLOC可能接近，但难度不同所花的时可能接近，但难度不同所花的时间是不同的。间是不同的。 技术顾问：对，我们可以在每个任务中加上难度系数，产能中的技术顾问：对，我们可以在每个任务中加上难度系数，产能中的KLOC=KLOC=实际的实际的KLOCKL

13、OC* *难度系数。难度系数。 研发经理：那么测试任务怎么算？研发经理：那么测试任务怎么算？需求捕获需求捕获 技术顾问：我认为这套系统主要关注的是开发时间、而对于前期技术顾问：我认为这套系统主要关注的是开发时间、而对于前期的分析和概要设计，以及后续的集成和系统测试等工作可以先忽略，放的分析和概要设计，以及后续的集成和系统测试等工作可以先忽略，放在系统范围之外，这里只考虑详细设计、编码和相应的测试工作。在系统范围之外，这里只考虑详细设计、编码和相应的测试工作。 研发经理：我明白了，就是对于一个任务而言所花的时间。对，研发经理：我明白了，就是对于一个任务而言所花的时间。对，这样比较合理。这样比较合

14、理。 开发人员甲：我希望系统能够在让我们填写估算值时，可以查询开发人员甲：我希望系统能够在让我们填写估算值时，可以查询历史数据，否则仍然没有意义。历史数据，否则仍然没有意义。 开发人员丙：查询历史数据时，还应该有类别吧！这样我们才能开发人员丙：查询历史数据时，还应该有类别吧！这样我们才能够根据自己将要完成的任务情况找到有参考依据的统计数据。够根据自己将要完成的任务情况找到有参考依据的统计数据。 开发人员乙：还有就是时间记录一定要方便，另外像我们这样经开发人员乙：还有就是时间记录一定要方便，另外像我们这样经常要在现场开发，如何完成时间记录？常要在现场开发，如何完成时间记录？ 研发经理：可以考虑有

15、一个离线版本的时间记录程序，等回公司研发经理：可以考虑有一个离线版本的时间记录程序，等回公司连接服务器后再进行数据同步。连接服务器后再进行数据同步。 获取需求特性表获取需求特性表建立概念模型建立概念模型发现类发现类建立概念模型建立概念模型关联分析关联分析建立概念模型建立概念模型职责分析职责分析建立用例模型建立用例模型识别参与者识别参与者建立用例模型建立用例模型合并特性获得用例合并特性获得用例建立用例模型建立用例模型合并特性获得用例合并特性获得用例建立用例模型建立用例模型绘制用例图绘制用例图建立用例模型建立用例模型简要描述用例简要描述用例建立用例模型建立用例模型划分用例优先级划分用例优先级建立用

16、例模型建立用例模型详细描述用例详细描述用例建立交互建立交互/状态模型状态模型用户界面设计用户界面设计Agendal需求建模实例需求建模实例l业务流程与规则分析业务流程与规则分析l数据需求分析与建模数据需求分析与建模l需求描述最佳实践需求描述最佳实践l需求管理最佳实践需求管理最佳实践l需求过程总结需求过程总结业务流程是信息系统的主脉落业务规则是变化的要点什么是流程什么是流程l目标性：有明确的输出l内在性：包含于任何事物或行为中l整体性：至少由两个活动组成l动态性：由一个活动到另一个活动进行l层次性：组成流程的活动本身也可以是流程l结构性：串联、关联、反馈等流程设计的原则流程设计的原则l流程应以产

17、出为中心，而非任务为中心l让那些需要得到流程产出的人自己执行流程l将信息处理工作纳入产生这些信息的实际工作中去l将各地分散的资源视为一体l将并行的工作联系起来，而不是仅仅联系他们的输出l在决策点位于工作执行的地方，在业务流程中建立控制程序l流程多样化l单点接触客户在在IT系统中实现流程设计的本质系统中实现流程设计的本质绘制流程图的核心步骤绘制流程图的核心步骤l提出业务流程清单：确定有哪些流程、流程之间的界限，然后才是对流程的描述l流程的要素描述：针对清单上的每一流程，分析并识别现有业务活动、活动之间的关系、活动需要接受哪些信息、产生哪些数据（表单）、数据传送的路线、活动涉及哪些岗位等。重要抓住

18、核心业务和主要活动点，部门内/外衔接、工作繁琐/反复环节、成本高/效率低/时间长的环节、任务转手次数多的环节l绘制流程图：跨职能流程图、带泳道的活动图流程的流程的ESIAlE：清除 过量产出 活动间的等待 不必要的运输 反复的加工 过量的库存 缺陷、失误 重复的活动 反复的检验 跨部门协调lS：简化 表格 程序 沟通 物流lI：整合 活动 团队 顾客 供应商lA：自动化 脏、累、乏味活 数据采集与传输 数据的分析跨职能流程图跨职能流程图l业务流程图l系统流程图l可以体现数据流向活动图：简单活动图活动图：简单活动图活动图：带泳道的活动图活动图：带泳道的活动图业务流程与业务规则业务流程与业务规则l

19、业务流程Action 用户可以做的操作？ 权限控制的基础l业务规则Filter 用户的授权操作可以影响的数据范围？ 权限控制的补充l用例与业务流程：多个用例属于一个流程l用例与业务规则：一个业务规则应用于多个用例业务流程与业务规则业务流程与业务规则l结构事实：必须成立的事实或条件。例如：与客户第与客户第一次接触的永远都是销售人员一次接触的永远都是销售人员。l行动约束：根据某种条件禁止的一种或多种行动。例例如：不接受具有不能接受的信用历史记录的支票如：不接受具有不能接受的信用历史记录的支票。l行动触发：当一个或多个条件转为真时，触发某个行动。例如：当所选商品准备齐后，立即发货当所选商品准备齐后，

20、立即发货。l参照：当一个或多个条件转为真时，得出某种结论。例如：在一年内飞行在一年内飞行10万公里以上的会员将成为金卡万公里以上的会员将成为金卡会员会员l计算：根据一组值计算另一个值。例如：销售量是商销售量是商品总零售额，但是没有包含税收部分品总零售额，但是没有包含税收部分。Agendal需求建模实例需求建模实例l业务流程与规则分析业务流程与规则分析l数据需求分析与建模数据需求分析与建模l需求描述最佳实践需求描述最佳实践l需求管理最佳实践需求管理最佳实践l需求过程总结需求过程总结数据是系统的核心内容数据需求分析与建模数据需求分析与建模l数据流通过程：数据流图（DFD）l数据存储方式：实体-关系

21、图（ERD）l数据定义方式：数据字典（DD）l数据需求分析与设计要素数据流图：基本元素数据流图：基本元素输入数据在此进行变换产生输出数据，其中要注明加工的名称数据输入的源点或数据输出的汇点，其中要注明源点和汇点的名称存放数据的地方，这些数据在以后使用，通常与实体-联系图中的一个数据实体相对应被加工的数据与流向，箭头边应给出数据流名字，可用名词或名词性短语命名当过程/加工执行时，外部实体与过程之间来回通信数据存储/文件数据流实时连接过程/加工外部实体/源/宿数据流图：图的结构数据流图：图的结构数据流图：分层的数据流图：分层的DFD绘制数据流图：构建顶层图绘制数据流图：构建顶层图绘制数据流图：绘制

22、绘制数据流图：绘制DFD片断片断绘制数据流图：将绘制数据流图：将DFD片断合并片断合并数据建模过程数据建模过程E-RE-R图图概念结构设计的方法概念结构设计的方法实体实体-关系图：图例关系图：图例实体分析法实体分析法l确定局部视图的范围：实体的个数应适量l识别实体及标识l确定实体间的联系l分配实体及联系的属性识别实体及标识识别实体及标识实体分析法：确定实体间联系实体分析法：确定实体间联系l一对一关系： 两个实体都是强制性的 仅有一类实体是强制的 两类实体均非强制性的l一对多关系 多端强制性 多端非强制性l多对多关系确定实体间联系时的陷阱确定实体间联系时的陷阱E-R图到关系模式的转换图到关系模式

23、的转换l实体模型：每个实体转成一个模式客户（客户名，身份证号，地址，联系电话） l一对一关系模式：在两个关系模式中的任意一个模式中，加入另一个模式的键和联系类型的属性 校长（姓名，性别，职称，年龄，校名，任职时间） 学校（校名，地址，电话） E-R图到关系模式的转换图到关系模式的转换l一对多关系模式：在n端实体类型对应的关系模式中加入1端实体类型的键和联系类型的属性校长（姓名，性别，职称，年龄，校名，任职时间）校长（姓名，性别，职称，年龄，校名，任职时间）学校（校名，地址，电话）学校（校名，地址，电话） E-R图到关系模式的转换图到关系模式的转换l多对多关系模式：将联系类型也转换成关系模式，属

24、性为两端实体类型的键加上联系类型的属性 学生（学号，姓名，性别，年龄）学生（学号，姓名，性别，年龄）课程（课程号，课程名，授课老师）课程（课程号，课程名，授课老师）考试（课程号，学号，成绩）考试（课程号，学号，成绩） 数据字典应用数据字典应用l数据元素说明 数据元素名或标识：即对用户而言有意义的名称； 别名：可选择的名字 类型和长度：说明数据元素的组成部分，是数字、字母还是其他；而长度则是指其最大的组成个数 默认值：即数据元素的一个初始值； 可接受的值：即数据元素有效的合法取值范围 数据源：即对数据元素值的起源点的具体说明 安全：对于有权访问或更新每个数据元素的人或部门的标识 有责任用户：负责

25、输入/改变数据元素值的用户标识 描述和评论：加上一些更好的说明数据元素的注解数据字典应用数据字典应用l数据流说明 数据流名或标识：即在DFD中所对应的数据流名称 描述：说明数据流的用途与目的 别名：可选择的名字 数据源：数据流的起点 目的：数据流的终止点 记录：每个数据流都代表了一组被称为记录或数据结构的相关实体 量和频率：描述单位时间内数据流发生的次数。数据字典应用数据字典应用l数据存储（文件）说明 数据存储名或标识：在DFD中对应的数据存储名称 描述：说明数据存储的用途与目的 别名：可选择的名字 属性：输入或离开数据存储的标准数据流图名 量和频率：描述数据存储中记录出现的可估计的个数和更新

26、频度l加工说明 加工名或标识：即在数据流图中所对应的加工名称 描述：说明加工的用途与目的 加工数据标识：用来指明加工所在的层次 加工描述：说明包括的输入和输出数据流数据字典应用数据字典应用l外部实体说明 实体名或标识：即在数据流图中所对应的实体名称 描述：说明实体的用途与目的 别名：可选择的名字 输入数据流 输出数据流l数据元素说明的常用表示法 ：由构成 ：和，代表顺序连接的关系 | ：或，代表从中选择一个 *：n次重复 （）：代表可选的数据项 *：表示特定限制的注释数据字典应用实例数据字典应用实例客户基本信息客户基本信息=客户编号客户编号+ +客户名称客户名称+ +身份证号码身份证号码+ +

27、手机手机+ +小灵通小灵通+ +家庭电话家庭电话客户编号客户编号=098=098客户名称客户名称=字字44身份证号码身份证号码=0915|0918=0915|0918手机手机=0911|0912=0911|0912小灵通小灵通=（区号）（区号）+ +本地号本地号家庭电话家庭电话=（区号）（区号）+ +本地号本地号办公电话办公电话=（区号）（区号）+ +本地号本地号 区号区号=094=094本地号本地号=097|098=097|098数据需求分析与设计要素数据需求分析与设计要素l术语表l数据结构分析，对表的内容要区分 主要字段和次要字段 稳定字段和不稳定字段 即时记录和历史记录l另个需要考虑 联

28、机事务需要报表需求决策查询需求 数据量与增长速度（数据查询失效案例） 性能与扩展 并发可能性与数量数据需求分析与设计要素数据需求分析与设计要素l数据共享考虑 数据库、文件、XML 逐段加密问题 数据Filter原则 谁建立？谁修改？谁查询？谁应用？l数据挖掘与分析 查询报表从规则入手 BI 数据挖掘，仓库（电信数据整合）数据仓库数据仓库Agendal需求建模实例需求建模实例l业务流程与规则分析业务流程与规则分析l数据需求分析与建模数据需求分析与建模l需求描述最佳实践需求描述最佳实践l需求管理最佳实践需求管理最佳实践l需求过程总结需求过程总结规格说明书是需求“圣经”需求描述最佳实践需求描述最佳实

29、践 1l定义描述需求的标准模板：在书写具体的系统需求时，应该定义一系列的标准模板用于组织需求描述。模板应该包括一些字段，通过填写这些字段，可以完整地说明一项需求。 主要效益：需求前后一致，因而更加易懂 引入成本：中 应用成本：低l使用浅显、一致、简明的语言：当使用自然语言表达某项需求时，应注意使用浅显、简明的语然言一描述，避免使用复杂的句子结构、冗长的句子和不明确的术语。 主要效率：需求更加易读易懂 引入成本：相当低 应用成本：低-中需求描述最佳实践需求描述最佳实践 2l适当地使用图解：当需要表示结构化的信息或者需要表达需求描述中信息之间的关系时应当使用图解，图解还可以用于概括数字信息或描述事

30、件和行为序列。 主要效益：图解最适于记录需求关系 引入成本：低 应用成本：低 实施指南：应使用图解的典型情况包括当某个对象（系统、文档）由多个模块和组件组成，而你又希望阐明它们之间的相互关系时；当需要表达一系列的行为，每个行为都有一些输入和输出时；当需要说明空间组织时；当需要使用一些分解结构时。但要避免使用含义不清晰的图案（如Word中的剪贴画）需求描述最佳实践需求描述最佳实践 3l用其他需求描述辅助自然语言：某此需求更适于使用特殊的方式书写，如数学公式、决策表等。 主要效益：更加简明、无二义性的需求描述 引入成本：很低 应用成本：低l定量说明需求：只要有可能，就应该使用定量的数值说明系统的需

31、求，非功能需求最有可能采用这一点。 主要效益：无二义性地表达需求 引入成本：低-中 应用成本：低-中 实施指南：定义表达这些属性的合适的度量；为属性决定一个合适的值。非功能需求可以使用度量非功能需求可以使用度量l可靠性：出错时间、错误发生率l有效性：请求后出错的可能性l性能：每秒处理的事务数，对用户输入的响应时间l存储利用：系统最大的尺寸(MB)l可用性：学习75%的用户功能所需要的时间，在给定时间内由用户引起的错误的平均值l健壮性：系统出错后重新启动的时间l完整性：系统出错时，允许的数据丢失的最大限度 数据需求的描述形式数据需求的描述形式l数据模型：E-R模型 框图：描述产品内、外的数据 非

32、常适合专家使用，但不便于用户使用l数据词典： 产品内、外数据的文字描述 非常适合专家及用户l数据表达式 描述数据序列的简洁公式，适合于描述复合数据及消息协议 非常适合于专家使用，也为许多用户所接受l虚拟窗口 简化的屏幕图像，有图像、真实数据，但无按钮、菜单 非常适合专家及用户，非常适合于规划新的界面功能需求的形式功能需求的形式 1l人、机职责划分：可采用DFD、UML表示 域模型：人、机结合的模型 物理模型：人、机各自的职责 产品层需求：人、机职责划分功能需求的形式功能需求的形式 2l上下文图：说明产品及其环境的图示 为开发人员概括了所有接口 大多数客户能不费力地理解上下文图功能需求的形式功能

33、需求的形式 3l事件列表与功能列表：产品要处理的事件，人、机合作处理的事件l域事件实例： 客人预订 客人入住 客人退房 换房 提交服务记录l产品事件实例 查找空闲客房 记录客人信息 查找客人数据 记录预订数据 打印预订确认 记录入住数据 退房 记录服务功能需求的形式功能需求的形式 4l特性需求：文字形式，该产品应记录/显示/计算，很多人认为这是惟一可以接受的需求形式可能给用户及分析人员造成错觉l实例： 该产品应能将客户在某一期限内设为维修状态 该产品应能够显示、打印下两周的人员配置表。该配备应以客房占用的历史数据为依据。 该产品也应支持根据客户类型，而不是客房号的预订。客人入住时才分配实例客房

34、功能需求的形式功能需求的形式 5l屏幕显示及原型：包括屏幕图像及”按钮“的功能，若经仔细测试可以作为很好的设计层需求l实例：功能需求的形式功能需求的形式 6l任务说明：结构化的文字说明，用于描述用户任务；便于客户、开发人员理解；便于说明任务变体以及复杂的任务l实例：功能需求的形式功能需求的形式 7l由任务说明到产品特性：用任务说明解释产品特性；有助于理解、确认特性l任务及支持：结构化的文字说明，描述任务、域问题，提出可能的方案。功能需求的形式功能需求的形式 8l场景说明：说明一项或多项用户任务，或要测试的一个特殊情况，有助于增进开发人员的直觉，通常不作为需求。l实例：夜班由于学习了一整个下午，

35、张三在下午6点开始值夜班时，已感觉到有些疲倦。他的第一项任务是为将在7点钟抵达的客人团做准备，他打印了所有的入住登录表，并将它们同各自的客房钥匙放在一起。在处理这项任务时，来了一个家庭询问客户的情况。他们想讨价还价，这是张三最不擅长的工作。是否应该给他们提供折扣呢？正好李四从办公室里出来，她微笑地告诉他们：可以为小孩的房间提供10%的折扣。他们接受了，于是张三为他们安排房间，他们希望挨着的两间客户，但是张三总是记不住哪些客遍及是挨着的。功能需求的形式功能需求的形式 9l用例l数据流图l以“标准”作为需求l以“开发过程”作为需求非功能需求的形式非功能需求的形式 1l开放尺度与开放目标：通常要求达

36、到某个数字目标。l实例： 该产品应能检测超速，并在0.5秒内完成拍照 该产品应能够2分钟内计算并显示客户占用情况的预报表lPlanguage表示法：非功能需求的形式非功能需求的形式 2l能力及准确度需求非功能需求的形式非功能需求的形式 3l性能需求需求规格说明书需求规格说明书l规格描述的形式 文档：用结合合理的自然语言精心编写 图形化模型：描述转换过程、系统状态以及变化、数据关系、逻辑流或者对象类及其关系 形式化规格说明：逻辑语言(伪码、决策表、决策图)l常用模板 ISO/GB版：面向结构化分析方法的，较陈旧 RUP版：以面向对象分析方法，用例驱动 Volere版：很实用的一个第三方公司版本A

37、tlantic System Guild（）公司 1引言 1.1编写的目的 1.2背景 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出用得着的参考资料。2任务概述 2.1目标 叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景 材料。解释被开发系统与其他有关系统之间的关系。 2.2用户的特点 列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长， 以及本系统的预期使用频度。 2.3假定和约束 列出进行本系统开发工作的假定和约束。3需求规定 3.1对功能的规定 用列表的方式，逐项定量和定性地叙述对

38、系统所提出的功能要求，说明输入什么量、 经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支 持的并行操作的用户数等指标。 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控制 说明控制该系统的运行的方

39、法和控制信号，并说明这些控制信号的来源。 RUP版需求规约1. 文档概述 1.1目的 1.2范围 1.3 定义、首字母缩写词和缩略语 1.4参考资料 1.5 概述2. 整体说明 让读者对整个软件系统的需求有一个框架性的认识。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。 2.1用例模型 2.2 假设与依赖关系3. 具体需求 3.1用例描述 3.2补充需求 易用性、可靠性、性能、其它4.支持信息Volere版：产品的目标版：产品的目标l该项目工作的用户问题或背景 内容：对引发开发任务的工作和情况的描述 动机：为该项目提供合法理由 例子：用户对订单到达所需的

40、时间(10天)感到不满 考虑：用户问题是否严重，是否应解决，如何解决l产品的目标 内容：我们希望产品做什么？ 动机：缺少表述清晰、易于理解的目标，会使项目开发迷失方向 例子：我们希望对顾客通过电话下订单订购我们的产品作出立即和完整的响应。 考虑: 是否指派一个人作为“目标管理人”Volere版：客户版：客户/顾客顾客l客户：为开发付费的人 内容：指出客户的名称 动机：是最终接受该产品的，必须对该产品满意 例子：公司客户服务部 考虑：有时客户是间接，那么选择间接部分中的一个人作为客户l顾客：花钱购买该产品的人 内容：顾客的名称 或特征 动机：它是决定产品价值的人l其它风险承担人 内容：Stake

41、holder列表 动机：各方需求源Volere版：产品的用户版：产品的用户l产品的用户 内容：用户分类、用户工作任务、主题相关经验、技术经验、其它特征(身体、智力、工作态度、技术态度、教育、语言、年龄、性别等) 动机：了解用户在确定产品易用性、设计偏好时很重要l用户优先级 内容：关键用户、次要用户、不重要用户 动机：更好地满足不同的用户Volere版：需求限制条件版：需求限制条件l解决方案限制条件 内容：解决方案中必须采用的或不能采用的方式 例子：产品必须使用WindowsNT系统，必须是一个手持设备 考虑：有解决方案限制一个边界l实现环境 内容：将实施的技术、物理环境 动机：要求解决方案必须

42、适应的环境l伙伴应用、COTS(外购软件包)l预期工作场地环境l开发时间、预算Volere版：命名标准和定义版：命名标准和定义定义项目中使用的所有术语 内容：一个字典，包括使用的所有名称的含 义，应使用标准名称 动机：减少项目开发过程中的概念澄清，减少需求歧义 例子：现值：总额/(1+年利息)年 考虑：利用已有的数据字典或词汇表 WiKi管理，十分理想！ 避免二义性的词和同义词Volere版：相关事实和假定版：相关事实和假定l相关事实：可能对产品产生影响 的外部因素 内容：对产品产生影响的其他因素、系统和活动 动机：提醒开发者可能对需求产生影响的一些情况和事实 例子：原有应用程序主要的问题就是

43、查询操作太多，无法使用l假定 内容：需求开发过程中所做的假设清单，对产品开发有影响 动机：假定与事实是相对的，它不一定是真实的 例子：用户能力的假定、外部系统的性能假定 短信服务器能够完成每秒20条的发送任务Volere版：产品的范围版：产品的范围l工作的上下文范围 内容：上下文范围图 动机：清析地定义系统的边界l工作切分 内容：事件清单，确定工作系统要响应的业务事件，可以用“事件列表”或“用例列表”来表述 动机：确定工作系统的逻辑上的大块 例子：用户能力的假定、外部系统的性能假定l产品边界 内容：用例图，确定用户和产品的边界Volere版：功能版：功能/数据和观感需求数据和观感需求l功能需求

44、 内容：产品必须执行的动作描述 例子：当短信发送失败时，给发送人一个消息提示 验收标准：取决于要求做的动作l数据需求 内容：E-R图或类图表示要保存的数据，DFD表示数据流通 动机：澄清产品的主题内容l观感需求 内容：外观设计的要求与部分原型 动机：外观是产品的有机组成部分，且很重要 例子：界面主色调应与公司VI吻合，应表现出稳重 考虑：明确客户对产品外观的观点Volere版：易用性需求版：易用性需求l易于使用 内容：预期用户应该如何容易地操作产品 动机：指导产品设计者构建符合最终用户期望的产品 例子：产品应该帮助用户避免犯错；不懂英文的用户也能操作 验收标准：使用一个月后，总的错误率应是多少

45、；经过熟悉期后，百分之多少的不懂英文用户同意能够操作l学习的容易程度 内容：学习时间和方式的要求 动机：量化可接受的用户学习时间 例子：工程师参加了一周培训后，应该能使用该产品 验收标准：软件使用培训结束后的最后测验中，工程师应到一个大家同意的百分比的通过率Volere版：性能需求版：性能需求l速度需求 内容：明确完成特定任务需要的时间，即响应时间 动机：对特定应用而言，响应时间很重要 例子：产品必须每秒钟完成20条以上的短信发送 验收标准：可测量的描述 考虑：不同速度需求，对于设计与开发影响甚大 l安全悠关的需求 内容：对可能产生人身伤害、财产损失和环境破坏所考虑的风险的量化描述。l精度要求

46、 内容：量化描述输出结果的精度要求 例子：所有有关钱的数据都精确到小数点后两位Volere版：性能需求版：性能需求l可靠性和可用性需求 内容：量化可靠性，平均无故障时间、总失败率 动机：有些系统，可靠是十分重要的 例子：产品应能够达到100小时的平均无故障时间l容量需求 内容：吞吐量和产品存储数据容量的要求 动机：保证产品有能力处理期望和数据量 例子：在上午9:0012:00应满足300个并发用户使用，其它时间最大负载为150个并发用户Volere版：操作需求版：操作需求l预期的物理环境 内容：明确产品将操作的物理环境 动机：指出可能需要特殊需求、准备或培训的情况 例子：所有的用户都是站立着操

47、作的该系统的l预期的技术环境 内容：硬件和其他组成新产品操作环境的设备的规范 动机：确定所有新产品要交互的元件或组成部分l伙伴应用程序 内容：必须与之交互的其他应用程序 动机：避免在实现阶段才发现 例子：必须能够与任何Web浏览器交互Volere版：可维护性和可移植性版：可维护性和可移植性l维护该产品需要多容易 内容：对产品作特定修改所需的量化描述 动机：让每个人意识 到产品维护的需要 例子：新添一种在原有数据基础上生成的报表格式，需要提出后一个工作周内提供l是否存在一些特殊情况适用于该产品的维护 内容：关于预期的产品发布周期和将采取的形式规定 动机：将每年根据使用情况发布一次更新版l可移植性

48、需求 内容：产品必须支持的其他平台或环境的描述 动机：量化客户和用户关于产品运行平台的期望 例子：必须能够运行在Windows英文版、日文版上Volere版：安全性需求版：安全性需求l该产品是保密的吗 内容：关于谁被授权使用该产品 动机：理解并突出指明对产品安全保密方面的预期需求 例子：员工的个人记录只有直接经理可以读取 考虑：是否存在管理层敏感数据？是否会导致损害或可能用于个人获利的过程？是否有人不应有权使用该产品？l文件完整性需求 内容：关于所需数据库和其他文件完整性方面的说明 考虑：信息如何使用？过时信息会有什么影响？l审计需求 内容：需要审计检查方面的规格说明 动机：构建符合相应审计规

49、定的产品Volere版：文化和政策版：文化和政策/法律需求法律需求l文化和政策需求 内容：针对社会和政策因素的规格说明 动机：写明在开发者文件经验范围之外的需求 例子：不要使用会令xx语系人民不快的图标 考虑：是否熟悉最终用户的文化环境l该产品是否受到某些法律管制 内容：明确该产品的法律需求的描述 例子：用户隐私数据不提供任何有助于传播的功能支持l是否有一些必须符合的标准 内容：明确适用的标准和参考的详细标准的描述 考虑：标准业界组织？行业规则？特殊开发步骤？数据规范？Volere版：开放式问题与版：开放式问题与COTSl开放式问题 内容：对未确定但可能对产品产生影响的因素进行描述 动机：公开

50、不确定性 例子：即将执行新的行业法规是否对软件产生影响尚未确定 l是否有一些成品可以购买l是否可使用成品组件l是否有一些我们可以复制的东西Volere版：开放式问题与版：开放式问题与COTSl新产品会在当前环境中带来什么问题 内容：新产品如何影响当前环境，不应该做什么 动机：尽快发现任何潜在冲突 例子：短信发送成功与否直接影响业务员工作业绩l新的开发是否将影响某些已实施的系统l现有用户是否会对新产品产生敌对影响 l预期的实现环境是否会对新产品有限制l是否新产品会带来其他问题需求项框架：需求项框架：Volere需求白卡需求白卡Volere白卡各项说明白卡各项说明l需求编号：为了可追踪l需求类型：

51、可自己定义一个编号类表l事件/用例编号：涉及的业务事件、用例l描述：该项需求的意图l理由：存在该需求的原因l来源：需求提出人、部门、联系方式l验收标准：必须达到的最化标准l满意度/不满意度：1-5量化，乘积进行排名l依赖关系：与其它需求的相关性l冲突：与其它需求的冲突l支持材料：相关补充说明材料l历史：修改记录Volere白卡示例白卡示例2525如果一个气象站传送读数失败，产品将发出警告。如果一个气象站传送读数失败，产品将发出警告。 传送读数失败可能表明气象站失效并需要维护，并且用传送读数失败可能表明气象站失效并需要维护，并且用于预测结冰的数据可能不完整于预测结冰的数据可能不完整道路工程师道路

52、工程师 对每个气象站，当每小时记录下来的各类读数个数不在对每个气象站，当每小时记录下来的各类读数个数不在制造商规定的范围之内时，产品将通知用户制造商规定的范围之内时，产品将通知用户3 35 5无无无无RosaRosa气象站规格说明书气象站规格说明书GBSGBS在在05.03.1205.03.12提出提出Volere白卡示例白卡示例113113易用性易用性6,7,8,9,106,7,8,9,10产品应该对道路工程师易于使用产品应该对道路工程师易于使用 工程师不必为了使用该产品而参加培训课程工程师不必为了使用该产品而参加培训课程Sonia,Henning,Sonia,Henning,道路工程管理者

53、道路工程管理者 一个道路工程师将在首次接触该产品的一小时内，能够成一个道路工程师将在首次接触该产品的一小时内，能够成功地执行指定的用例功地执行指定的用例3 35 5无无无无HWHW在在05.03.1205.03.12提出提出需求文档编写原则需求文档编写原则l使用语法、标点正确的完整句子，使语句的段落简短明了l采用主动语态的表达方式：如“该系统将”，而非“将发生”l使用的术语应与术语表中定义的术语保持一致l将含糊不明确的顶层需求分解成足够详细的几个需求，消除歧义l需求声明应该具有一致的风格，例如“系统将”，“用户将”l当以“用户将”格式说明时，尽可能明确参与者l使用列表、数字、图和表来表示信息l

54、强调最重要的信息l避免使用语义不清的词语l以相同的详细程序编写l详细程度的把握：可以单独测试歧义术语与改进歧义术语与改进l可接受、足够：具体定义可接受的内容和系统如何地此进行判断l差不多可行：不要让开发人员来确定什么是可行的l至少、最小、不多于、不超多：指定能够接受的最大值和最小值l在之间：定义终点是否在此范围内l依赖：描述依赖性的本质，是提供输入？是提前安装支持软件？l有效的：定义系统如何有效地使用资源，系统执行特定的操作的速度如何，用户使用系统的容易程度如何l灵活的：描述一种方式l改进的、更好的、更快的、优越的：定量说明l包括、包括但不限于、等等、诸如：项目列表应包含所有可能性l最大化、最

55、小化、最优：陈述对某些参数所接受的最大值和最小值歧义术语与改进歧义术语与改进l一般情况下、理想情况下：描述系统在异常和非理想条件下的行为l可选择的：指明是系统选择、用户选择还是开发人员选择l合理、在必要的时候、在适当的地方：清晰解释如何判断l健壮的：定义系统如何处理异常和如何响应预料外的操作条件l无缝的、透明的、优雅的：将用户期望转化成能够观察的特性l若干：具体是多少，最小边界值和最大边界值 l不应该：试着以肯定句来描述l最新技术水平：描述其具体含义l充 分的：指定具体包括哪些内容l支持、允许：精确定义系统将执行哪些功能l用户友好、简单、容易：描述系统特性，这些特性将达到客户的使用需要和对易用

56、性的期望需求修正需求修正l原描述：后台任务管理器必须在固定的时间间隔内提供状态消息，并在每次时间间隔不得小于60秒。l什么是状态消息？什么条件下和以什么方式向用户提供这些消息？l显示时间是多长？间隔时间不太明确，1毫秒行吗？l修改后：后台任务管理器应该在用户界面的指定区域显示状态信息在后台任务进程启动后，消息必须每隔6010秒更新一次消息应该保持持续的可见性后台任务管理器在每次可以与后台任务进程进行通信时，都应该显示后台任务已完成的百分比当完成后台任务时，后台任务管理器应该显示一个“已完成”的消息如果后台任务中止执行，那后台任务管理器应该显示一个出错信息需求修正需求修正l原描述：如果可能的话，

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

58、上是：发生意外损坏或丢失时能够保护内容保护内容l修改后：修改后：1.编辑器将要求用户确认全局性文本改动、删除和插编辑器将要求用户确认全局性文本改动、删除和插入操作入操作2.应用程序应提供多级应用程序应提供多级“撤消撤消”功能功能Agendal需求建模实例需求建模实例l业务流程与规则分析业务流程与规则分析l数据需求分析与建模数据需求分析与建模l需求描述最佳实践需求描述最佳实践l需求管理最佳实践需求管理最佳实践l需求过程总结需求过程总结需求管理最佳实践需求管理最佳实践 1l惟一地标识每一个需求：应该给每一个需求分配一个惟一的标识符或者引用数字，可以用于在需求文档的其他部分或在其他系统文档中指向该需

59、求。 主要效益：明确地引用特定需求是可能的 引入成本：很低 应用成本：很低l定义需求管理的策略：定义了需求管理的目标，应该遵循的过程和应该使用的标准。 主要效益：对所有参与需求管理的人提供指导 引入成本：中等 应用成本：低需求管理最佳实践需求管理最佳实践 2l定义可跟踪性策略：应定义应用维护哪些可跟踪性的信息以及该信息应该怎样表示，可跟踪性信息是可以发现需求间、需求和系统设计、组件和文档间依赖性的信息。 主要效益：维护所有系统的一致的可跟踪性信息 引入成本：中等 应用成本：中等-高l维护可跟踪性手册：它是对需求文档的一个补充，包含了在项目中使用的特定的跟踪性策略和需求的可追踪性信息。 主要效益

60、：作为所有特定项目的可跟踪性信息的中心记录 引入成本：低 应用成本：中等-高需求管理最佳实践需求管理最佳实践 3l使用数据库来管理需求：建立一个需求数据库，把单个需求作为条目存储进数据库，而不要用文本文档来维护需求。 主要效益：使管理大量的需求变得容易 引入成本：中等-高 应用成本：中等 实施指南：需求是怎么表达的？自然语言、图形模型、数学表达式？一般需要管理多少需求？需求总是由在同一地方工作、使用相同类型电脑的小组开发和管理的吗？已经使用一个支持软件工程的数据库了吗？有内部的数据库专家吗？需求工程师负责数据库管理吗？需求管理最佳实践需求管理最佳实践 4l定义变更管理策略：陈述了变更是以何种形式提出、分析和评