需求师培训-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=实际的实际的KLOCKLOC* *难度系

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

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

15、间记录程序，等回公司研发经理：可以考虑有一个离线版本的时间记录程序，等回公司连接服务器后再进行数据同步。连接服务器后再进行数据同步。 获取需求特性表获取需求特性表编号特性FEAT01研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目FEAT02项目经理可以对项目设置工作包，工作包允许多级嵌套，它只用来组织工作任务FEAT03项目经理可以为开发人员指派工作任务，工作任务属于特定的工作包FEAT04项目经理在分配工作任务时，能够查阅开发人员的日程安排表，可以按开发人员查询、也可按日程查询FEAT05开发人员接到任务时，通过系统填写计划时间（计划开始时间和计划结束时间），项目经理确

16、认后，更新日程安排表FEAT06开发人员可以查询相近工作任务的历史数据（估算数据、实际数据）FEAT07开发人员任务执行将超计划时，应报告项目经理，项目经理通过系统更新其日程表FEAT08当任务完成之后，项目经理负责Close任务，并填入实际的完成情况（KLOC、实际结束时间）FEAT09开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长-中断时长）FEAT10开发人员可以根据任务编号、关键字、起止时间进行分类组合查询与统计FEAT11

17、时间记录程序会自动连接服务器，完成时间日志上传的工作，未能连接服务器，则在本机暂存时间日志FEAT12项目经理可以按项目、任务、关键字统计实际工作时长、产能FEAT13研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能建立概念模型建立概念模型发现类发现类研发经理研发经理 项目项目 项目经理项目经理 工作任务工作任务 工作包工作包开发人员开发人员 日程安排表日程安排表 计划时间计划时间 历史数据历史数据 估算数据估算数据实际数据实际数据 任务编号任务编号 工作关键字工作关键字 开始时间开始时间 暂停时间暂停时间停止时间停止时间 总时长总时长 有效时长有效时长 服务器服务器 产能

18、产能管理层管理层 时间日志时间日志项目项目 工作任务工作任务 工作包工作包 开发人员开发人员日程安排表日程安排表 时间日志时间日志建立概念模型建立概念模型关联分析关联分析建立概念模型建立概念模型职责分析职责分析建立用例模型建立用例模型识别参与者识别参与者建立用例模型建立用例模型合并特性获得用例合并特性获得用例参与者特性用例开发人员FEAT05.开发人员接到任务时，应通过系统填写计划时间（计划开始时间和计划结束时间），项目经理确认后，更新日程安排表 UC01.填写任务计划FEAT06.开发人员可以查询相近工作任务的历史数据（估算数据、实际数据）FEAT10.开发人员可以根据任务编号、关键字、起止

19、时间进行分类组合查询与统计UC02.查询历史任务数据(UC01的扩展)FEAT09.开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长-中断时长）FEAT11.时间记录程序会自动连接服务器，完成时间日志上传的工作，未能连接服务器，则在本机暂存时间日志UC03.记录时间日志建立用例模型建立用例模型合并特性获得用例合并特性获得用例项目经理FEAT02.项目经理可以对项目设置工作包，工作包允许多级嵌套，它只用来组织工作任务UC04.设置工作包

20、FEAT03.项目经理可以为开发人员指派工作任务，工作任务属于特定的工作包FEAT04.项目经理在分配工作任务时，能够查阅开发人员的日程安排表，可以按开发人员查询、也可按日程查询UC05.分配工作任务UC5A.查看日程安排(扩展用例)FEAT07.开发人员任务执行将超计划时，应报告项目经理，项目经理通过系统更新其日程表UC06.更新日程表FEAT08.当任务完成之后，项目经理负责Close任务，并填入实际的完成情况（KLOC、实际结束时间）UC07.关闭工作任务FEAT12.项目经理可以按项目、任务、关键字统计实际工作时长、产能UC08.统计项目产能研发经理FEAT01.研发经理能够创建项目、

21、指定或修改项目经理、删除尚未分配工作任务的项目UC09.管理项目信息管理层FEAT13.研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能UC10.统计团队产能建立用例模型建立用例模型绘制用例图绘制用例图建立用例模型建立用例模型简要描述用例简要描述用例用例编用例编号号UC01用例名用例名称称填写任务计划用例概用例概述述开发人员对项目经理安排给自己的工作任务进行计划，填入计划开始时间和计划完成时间。主参与主参与者者开发人员补充说补充说明明在填入计划开始时间和计划完成时间时，开发人员可以查询与该任务的关键字相关的历史任务的数据。建立用例模型建立用例模型划分用例优先级划分用例优先级

22、优先级用例说明1UC11.登录系统 系统使用的基础，并且可复用原有资源UC09.管理项目信息 UC04.设置工作包 UC05.分配工作任务 UC01.填写任务计划 任务管理的完整流程，是记录时间日志的基础UC03.记录时间日志系统核心功能2UC07.关闭工作任务只是对任务信息进行更新，重要性次之UC06.更新日程表 UC5A.查看日程安排对日程安排进行优化，使任务安排合理化3UC02.查询历史任务数据UC08.统计项目产能 UC10.统计团队产能对系统记录的时间记录进行有效的利用，必须有前面的信息才能够开发UC12.管理用户前期可以通过直接往数据库中写值的方式进行使用，最后提供界面操作即可建立

23、用例模型建立用例模型详细描述用例详细描述用例用例编号用例编号UC03用例名称用例名称记录时间日志用例概述用例概述开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”等功能，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长-中断时长）。主参与者主参与者开发人员前置条件前置条件用户进入“记录时间日志”程序后置条件后置条件将本次时间日志存入数据库基本事件流基本事件流步骤活动1系统显示“开始”、“暂停”和“停止”按钮，但仅“开始”可用2用户点击“开始”，系统记录开始时间，并将“开始”置为不可用，

24、使“暂停”和“停止”按钮可用3用户点击“停止”按钮，系统记录停止时间，并统计暂时时间、暂停次数、总时长、有效时长，并要求用户选择任务编号、输入工作关键字和相关信息。填写完成后，点击确定，用例完成。扩展事件流扩展事件流3a在此期间，若用户点击“暂停”按钮，系统则记录暂停开始时间，并使暂停次数增加1次，并使“暂停”按钮变为“恢复”，使“停用”按钮不可用3a1当用户点击“恢复”按钮，用当前时间减去暂停开始时间得到本次暂停时间，并累加到“暂停时间”时间中，并使“恢复”按钮变为“暂停”，使“停用”按钮恢复可用规则与约束规则与约束时间记录程序应以离线式工作，该程序会自动连接服务器，完成时间日志上传的工作，

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

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

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

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

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

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

31、制数据流图：绘制DFD片断片断绘制数据流图：将绘制数据流图：将DFD片断合并片断合并数据建模过程数据建模过程E-RE-R图图概念结构设计的方法概念结构设计的方法方法实体分析法属性综合法别称自顶向下法自底向上法要点从总体概念入手，从分析一个单位的事务活动开始将收集的数据元素作为分析对象，各层实体及联系通过低层属性综合而成步骤1.识别用户关心的实体及实体间联系，建立初步数据模型框架；逐步求精，加上必要描述属性，形成完整的模型（用户视图）将这些视图集成为一个统一的数据模型（用户视图集成）1.用E-R图描述全局信息结构1.确定属性分类确定实体构成确定实体间联系联系1.通过对数据元素与应用任务联系的定性

32、、定量统计分析技术推导出相应的信息结构优点减少分析中所涉及的对象数，简化分析过程；采用图形法使得整个过程更直观、易理解，有利用户介入基于统计分析（定量/定性）推导，对于较为简单的设计对象特别有效实体实体-关系图：图例关系图：图例实体分析法实体分析法l确定局部视图的范围：实体的个数应适量l识别实体及标识l确定实体间的联系l分配实体及联系的属性识别实体及标识识别实体及标识序号步骤原则描述1对数据对象进行分类同一类中的对象在概念上应具有共性这个过程，类似于面向对象中类的识别，也可以有超类和子类的概念2识别实体与属性描述信息原则实体均有描述信息，属性则没有实体均有描述信息，属性则没有多值性原则若描述中

33、存在多个值描述，则即使该描述项本身无描述信息也应划为实体实体存在性原则若对象类R的描述的值集中去掉某个值，如果对应用不产生影响，就应为属性，否则应为属性，否则应为实体实体多对一联系性属性不再与其描述对象之外的其他对象类发属性不再与其描述对象之外的其他对象类发生联系生联系组合标识判别原则若一个对象类的标识是由其它对象类的标识组成的，则通常应定义为联系联系3对象命名命名原则对象名清晰、易于记忆，反应对象的主要特定，遵守缩写规则4确定实体标识（键）实体的标识是指能够惟一标识一个实体的属性或属性组，也就是该惟一标识一个实体的属性或属性组，也就是该实体的关键字。实体的关键字。实体分析法：确定实体间联系实

34、体分析法：确定实体间联系l一对一关系： 两个实体都是强制性的 仅有一类实体是强制的 两类实体均非强制性的l一对多关系 多端强制性 多端非强制性l多对多关系确定实体间联系时的陷阱确定实体间联系时的陷阱类型说明示例扇形陷阱若两个实体类间的一对多联系，由一个实体值引出多个同一类型的联系值，那么其值图将呈扇形结构，也称为扇形联系。而扇形陷阱是指由一个实体引出两种不同类一个实体引出两种不同类型的扇形联系，形成双扇形型的扇形联系，形成双扇形结构。结构。这样将丢失教师和系之间的联系表示。断层陷阱是指因为型图包含了传递联系，而掩盖了某些特定的直接联系该模型无法表示直接属于学校的教师E-R图到关系模式的转换图到

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

51、运行的方法和控制信号，并说明这些控制信号的来源。 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该项目工作的用户问题或背景 内容：对引发开发任务的工作和情况的描述 动机：为该项目提供合法理由 例子：用户对订单到

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

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

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

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

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

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

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

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

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