系统需求调研表

一卡通系统项目业务需求调研对于很多项目所要承载的业务，我们不是简单的把线下的业务流程梳理清楚就OK，而是要通过当前线下业务流程的梳理，找到线下业务存在痛点，然后在形成一卡通系统的线上业务流程时候，如何来更好的优化和调整；一：项目业务调研大纲一卡通系统二：项目业务调研内容1.项目承载的主要业务是什么？2.业务的特征和性质是怎样的？3.当前业务是怎样的？4.项目上线后，对业务流程有哪些改变的要求？5.业务涉及的使用角色说明？6.客户存在的问题和痛点是什么？考勤管理业务1.考勤主要是处理员工出勤情况的考勤系统，需要了解目前客户的考勤情况2.参与考勤的人员类型有哪些？3.参与考勤人员的数量是多少？4.考勤管理的方式使用哪种？（刷卡、指纹、面部以及刷卡、指纹、面部的组合）5.考勤管理需要提供组织结构6.考勤管理需要提供人员的基本信息（工号、姓名、部门等）7.考勤管理需要提供详细的上班时间段8.考勤管理需要提供详细的班制信息9.所有的请假、加班等是否需要审批，是否通过平台？如果通过平台，请提供各种假类的审批流程10.是否存在特殊班志，需要特殊处理的？如果有，请提供名称和相应说明11.对于考勤数据的分析结果，都需要知道哪些内容12.考勤的管理方式及管理流程13.目前由哪个部门负责人员的考勤管理？14.都有哪些业务表单？通道闸业务一卡通系统1.通道闸的数量？2.通道闸安装的位置？3.通道闸通行的人流量？4.通道闸识别的方式？5.通道闸的通行宽度？6.通道闸通行的人员类型？7.人员通行的授权管理部门？8.人员通行的管理流程？停车场业务一卡通系统1.停车场管理系统的数量是多少？2.停车场管理系统安装的位置？3.每个位置的车流量是多少？4.车辆类型有哪些？（公司领导车辆、公司内部车辆、外部车辆、特种车辆、消防车、急救车等）5.车辆类型中一般会通行哪几个位置？6.车辆入场管理流程？7.车辆出厂管理流程？8.车辆管理部门？9.现有的车辆进出厂区的管理流程10.车辆的授权流程？11.车进出权限变更有哪个部门负责？12.需要查看什么报表?，报表应显示什么信息，关注那些数据13.管理要求上还有什么特使内容？消费业务1．明确采用何种卡作为消费媒介2．人员消费的权限从哪里下发？3．相应部门主要负责哪些工作内容？工作流程是什么？4．消费的模式有哪些？（定值、分段定值、金额）5．消费的人员类型有哪些？6．明确对于每类人员的发卡、退卡、挂失、换卡的管理部门？7．是否还存在其它功能，例如：补贴下发等8．消费报表的要求，是否存在财务标准报表？消费报表的内容？访客业务1．访客的管理流程是怎么样？2．哪个部门负责访客的管理？3．要明确管理部门，部门管理范畴、部门职能等

对产品经理来说，绝大多数工作时间都是围绕需求展开的——需求分析、需求调研、跟进实现需求等。那么关于需求调研这部分，一般都有几种调研方法呢？我们又该如何使用这些方法呢？需求调研是需求实现的前提。需求调研主要内容有：了解需求背景、明确需求目标、过滤不当需求、确定大致方案。需求的用户是谁？需求解决的核心问题是什么？使用场景有哪些？哪些是主要和次要场景？业务的流程是什么？除了主要业务还有哪些流程可能使用这个功能？除了本系统还有哪些系统会关联到这个功能……这就是需求调研的“十万个为什么“。本篇结合《后端产品经理宝典》书中的内容，单从需求调研案例出发，看几种常用的调研方法。一、过滤需求的方法做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。这不是一个贬义词，反而是体现后端产品价值判断的基础。过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。1. 用户场景模拟法后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。如果不能帮助用户，那么这个需求就可能是伪需求。以下面的案例说明：背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。因此，该需求是个伪需求，应该被过滤掉。2. 功能归属分析专门的系统做专职功能，有助于合理的产品体系建设。因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。如果不属于该系统范畴，那么直接说服需求方更换方案。以下面的案例说明：背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。二、拆分和聚合的方法1. 拆分需求法业务用户提出一个需求，很可能只是短短的一段话。但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。每个需求点再当做一个子需求进行调研，最后再聚合在一起。以下面的案例说明：背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。这里不一一展开。2. 聚合需求法拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。三、利用辅助功能调研需求调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。分析：需求是很明白的，也有它的意义，但有风险。因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。四、“拔萝卜带出泥”的方式调研需求调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。举例说明：背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。分析：第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。五、需求得分权重法该方法的思路就是将需求质量的维度进行权重，然后对需求进行打分，根据最终得分的多少排列顺序。如表所示，采用五个维度：先`先`重要、紧急、收益、成本、风险，其中成本和风险是给予负分，五个维度的分值权重分别为30%、30%、20%、10%、10%。那么一旦对需求打了分，就可以用分数*权重，得到最终得分。注意：负分的要减。并且为了方便计算，分值最好设置0.5-5.0之间，或者0-10之间。这样避免打分的跨度过大出现较大偏差。如表所示，需求1的得分=6*30%+6*30%+8*20%-3*10%-7*10%=4.6。而需求2得分3.5，需求3的得分为-0.1。由此可以判断需求的价值顺序为：需求1>需求2>需求3。对于需求3，可以予以淘汰。以上的维度、分值和权重可以根据实际情况自行设计，但是要多考察和验证什么样的参数是较为合理的。并且也不能唯权重得分是从，而只是把它当做一个辅助工具。六、其他需求调研工具需求调研适合核心环节，该过程就会涉及到很多工具或分析方法，以确保需求调研高效、高质量。比如问卷调查、访谈、名义小组会议、头脑风暴法、观察法、亲和图、蒙特卡洛技术、鱼骨图、提示清单等。以上整理自《后端产品经理宝典》。#专栏作家#书籍《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交App。本文原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议

人脉系统V1.0由牛工负责开发。在调查系统需求阶段，他要做的第一件事是阅读人脉系统V1.0需求范围说明书，了解人脉系统V1.0要实现的功能，确定要调查的工作。虽然人脉系统V1.0功能相对简单，无需调查系统相关者。牛工仍然决定要进行系统相关者的调查工作，他把系统相关者分为两类。一类是客户，也就是决定投资开发该系统的人或机构，他需要从客户方了解新系统的背景（为什么要开发这个系统？）、客户对新系统的期望（系统要做成什么样？）、客户对新系统的支持力度等内容；一类是用户，也就是使用系统的人或机构，他需要从用户方了解用户如何使用系统，用户对新系统的期望等内容。调查系统客户牛工首先与客户进行了面谈，投资该项目的客户是人脉科技，人脉科技的贾总与牛工进行了面谈。牛工向贾总提出了三个问题：第一个问题是为什么要开发这个系统？第二个问题是系统要做成什么样？第三个问题是公司对系统的支持力度如何？贾总针对第一个问题的回答：“当前人与人之间的交流更多的是通过互联网进行，通过互联网认识的朋友也逐渐多起来，时间长了，很多朋友就记不清谁是谁了，有必要开发一个系统把朋友的资料给管理起来。另外就是当需要展示自己给陌生朋友时，可以把最好的一面展示给朋友”。贾总针对第二个问题的回答：“人脉系统把与自己相关的朋友、同学、同事、商业伙伴的信息和资料，通过人脉管理起来，并利用互联网技术积极拓展和维护个人的人脉资源”。贾总针对第三个问题的回答：“人脉系统是公司的重点项目，公司的想法是先实现简单的功能，让系统尽快上线。然后再根据用户的反馈分阶段完善系统，根据系统的运营情况，公司会逐渐加大支持力度”。贾总对第一个问题的回答，让牛工明白了人脉科技要研发人脉系统的必要性，人脉系统的核心功能就是基于互联网的社交功能；贾总对第二个问题的回答，让牛工明确了新系统要采用的技术体系，新系统采用BS技术体系，系统部署到服务器端，用户通过浏览器访问和使用系统；贾总对第三个问题的回答，让牛工确定了新系统的开发方式，新系统采用迭代增量的开发方式，在前一个迭代阶段的基础上增加和完善系统功能。和贾总面谈结束后，牛工确定了人脉系统的以下内容：人脉系统的核心功能是基于互联网的社交功能人脉系统采用BS技术体系人脉系统采用迭代增量的开发方式牛工和贾总的面谈确定了人脉系统的技术体系、开发方式和系统研发方向。牛工和贾总的面谈是非常重要的，面谈让系统研发团队和系统拥有者对新系统的研发方向、技术体系和开发方式都有了统一的认识。防止出现系统研发完成后，系统功能和客户对系统期望不一致的问题。小提示：在开发一个软件项目之前，一定要和软件项目的拥有者达成一致。例如，假设公司领导让开发一个软件项目，他只是简单的把项目要求说了一下。你需要先做的事情是把项目的背景、项目的研发方向弄清楚，然后再和领导面谈，核实你对项目的理解和领导对项目的期望是否一致。调查系统用户有社交需求的人都是人脉系统的用户。牛工与人脉科技负责商务的张女士进行了面谈。牛工向张女士提出了三个问题：第一个问题是平时如何管理自己的通讯录；第二个问题是：收集的名片如何放置？第三个问题是：当需要获取朋友的联系资料时，你是如何做的？第四个问题是：如果有一个系统帮忙管理通讯录、名片资料时，你希望这个系统有什么功能？张女士对第一个问题的回答：“我主要负责公司的商务活动，需要联系的人比较多，我一般用EXECL来管理自己的通讯录，当需要打电话或发邮件给联系人时，我会通过EXECL来查找联系人”。张女士对第二个问题的回答：“我从商务活动中收集的名片，一般把名片的通讯资料录入到EXECL文档中，名片也会放置到一个抽屉里，但时间长了就容易丢失”。张女士对第三个问题的回答：“这个问题在第一个问题已经回答了，因为通讯录是EXECL文档，我会从EXECL文档中查找朋友的联系资料”。张女士对第四个问题的回答：“我进入系统应该只能看到自己的联系人信息，名片信息应该能自动识别录入、也可以手动录入，在手机、电脑上随时可以查询通讯录，可以发送个人的数字名片给朋友，朋友间可以互相交换数字名片”。和张女士面谈结束后，结合人脉系统V1.0需求范围，牛工确定了人脉系统V1.0的系统事件，系统在发生如下事件时能进行一些处理：用户登录用户注册用户添加名片用户查询名片用户查看名片信息牛工和用户的需求面谈主要是确定与系统相关的事件。实际上，所有的系统开发方法都是以事件概念开始建模的，调查系统需求阶段主要的工作就是确定与系统相关的事件，并编制事件列表。下节课我们会讨论什么是事件？

做任何产品，不能直接了解需求，这样容易陷入细节，而偏离整体项目。当你的目标不明确时，你需要了解清楚现状：问题和机会是什么？有什么影响？再确定解决方案，有效进行需求分析。“为什么这次又延期上线？！”“因为需求方又变更需求啊！”“那具体什么时间可以准确上线！”“大概…”“……”看着业务方一脸愤慨，产品经理摊手表示无奈。这个场景相信不少产品经理有遇见过。如果是小需求变更倒还好，涉及核心流程的变更，相信程序猿已经磨刀霍霍向猪羊…产品延期上线的大部分原因多半是需求变更频繁，既定上线日期一拖再拖。那我们要如何去解决这个问题呢？需求变更频繁，大部分错不在需求方，而是在于我们产品经理对需求分析与挖掘不够全面与深入，因为需求方往往对自己的需求是模糊且想一是一。那如何做有效的需求分析呢？以企业组织系统举例，后续我用几张篇幅给大家详细说明。做任何产品，不能从直接了解需求，这样容易陷入细节，而偏离整体项目。首先，我们要了解产品的价值需求这一条线，次之才是详细需求线。价值需求主线分为三大方面，目标与愿景分析、干系人识别、干系人分析。详细需求主线分为系统分解线、功能线、数据线、质量线、其它方面。下面讲述目标与分析的六个点。一、需求=预期-现状我们在做产品调研时，大致会遇到三种情况。相关系统涉及的部门的同事有的表现积极、无所谓、不搭理的情况时有发生，其实这些就是他们现状有所不同。当他们在使用系统经常遇到让他们无法理解或头疼繁复的操作时，他们会对你的需求调研发现出热情，恨不得把诉求一股脑抛给你。反之，系统用着还行，这时你提出迭代优化，这种打破他们习惯的做法造成的不安全，他们会比较抵制你的调研。这时不要慌，我们需要去了解他们的工作流程与操作体验，找出更为快捷高效率的思路，提高他们的预期，创造新的需求机会，这样他们才会配合你的工作。因此，我们进行需求分析时，首先要识别这是机会还是问题。两种情况下了解需求的套路有所不一。二、问题场景出现问题场景，它有外部和内部两种触因。外部触因下常见的有三种情况。第一种情况：主导看到别人的产品，察觉自身差距。需求分析思路：让对方分享观察后的收获。一般情况，需求方有较为明确的思路，进行需求获取较为轻松一些。第二种情况：竞品的动向，想模仿。需求分析思路：做竞品分析。常见需求方没明确的思路，只是看好的就想抄。此时产品人员需谨慎分析。第三种情况：新技术的趋势。需求分析思路：让对方分享对所谓新技术的理解，了解背后的需求，以防有差。内部触因下，内部员工已经明确意识到现状与预期的差距，但是无法详细阐述。这时比较考验产品人员的访谈技巧，我们的大致思路是还原表象-分享原因-共商决策。此处详细的知识可以查看需求获取的相关书籍三、机会场景对机会场景的分解可以从三个角度去分析。第一、新业务。追标杆、赛同行、借鉴别的行业第二、新技术。关注新技术的应用趋势，寻找灵感。关注客户的业务痛点以及系统缺陷第三、新人群。假如一个产品的用户年龄段虽然是固定的，但是若干年过去后，这个年龄段的人由于出身的社会背景有所不同，其个性和需求会有所不同。像寿命较长、垂直化产品更是要关注一点。四、准确定义问题/机会面对客户，最核心一点是，先讲场景再谈数据。如果一开始，把问题用专业的语言进行描述，对方要么一脸懵逼要么理解偏差，影响沟通效果。我们该如何描述一个问题？业务态。每个产品经理刚入门时，对需求方讲解系统时，直入主题讲解系统功能与架构，对方多半是一脸懵逼状。我们应该从对方关心的业务层次来讲系统的作用。比如当需求方是企业管理层，我们应该从“问题、机会、成本、效益”这四方面去讲述我们的系统，不要深陷技术实现的细节。客观性。需求方给我们描述诉求时，往往模糊不准确。而我们产品人在了解完需求后，一定要准确、客观地描述好；匹配性。项目的愿景和目标往往是高层读者，我们关注点应从经营层面、管理藐视、业务模式依次去描述问题五、分析影响明确指明问题影响到了谁，可以指明部门岗位分析带来的影响与后果（注意读者的层次）推理合理、层次清晰六、分析问题和确定解决方案分析问题。鱼骨法、问题现状树法、问题现状法、系统思考法等，涉及的技巧可以看相关书籍宏观说明，强调具体策略，业务化语言描述。用“措施+效果”的结构一句话提炼目标场景本章节知识主要是适用于从0开始或者目标不明确的项目，不适用于内部有明确的方向和框架的项目。本文由 @PM达云霄 原创发布于人人都是产品经理，未经作者许可，禁止转载。题图来自Unsplash，基于CC0协议。

制造企业引入MES制造执行系统之前，除了要企业高层做了战略决策，还有就是具体执行的IT部门，进行前期的需求调研工作。那么，企业MES系统业务流程需求调研基本原则与办法又有哪些需要注意的呢？MES系统调研工作在制造业企业的MES系统新项目中，企业内部业务流程需求调研与详细分析，这是选择MES系统过程中，最为重要的核心内容；同时，也是选择MES系统中较为复杂的部分，所以，选择MES系统的内部业务流程需求调研与详细分析，尤其要注重办法和基本原则。选择MES系统小组成立后，对于内部业务流程要求的调研与详细分析，在办法和原则上，提供下列的经验给予借鉴：首先，选择MES系统小组成员需要时刻掌握一个度的基本原则，就是这个阶段并不是MES系统需求分析报告，给出具体需求说明书的阶段，也不是MES系统项目执行制定工作任务、任务分解的阶段，业务流程需求调研不可以求细、求全，否则就是将本来新项目要求分析阶段的工作任务提前了，造成无法把握住工作重点，很有可能花费大量的人力、物力和时间，MES系统需求分析报告工作任务疲惫不堪，也不会交出让高管满意的选择方案与提议。所以，现阶段尽管以业务流程驱动，以业务流程为核心，但来源于信息部门的实施顾问，对整个任务的有效工作任务起到最关键的功能，协助业务流程用户把握度的基本原则。其次，在掌握了度的基本原则前提下，选择MES系统小组成员，必须遵守以目标为导向的工作任务具体方法，就是一直坚持以选择MES系统小组的整体规划目标为方向——为高管提供选择评估报告，为实现这份报告所必须的几个层面内容，包括了对投资项目的必要性和市场预测的结果进行评估，分析项目建设的必要性、对项目建设的条件和技术工艺方案进行评估，分析项目实施的资源与技术保证条件、对项目技术经济评价指标，评价方法进行比较评估，分析项目效益的可行性、对项目的费用，适用环境，对企业运营的影响进行评估，提供项目取舍的依据、对影响投资效益的经济政策和管理体制进行评估，为项目顺利实施提出建议；最后就是给出可行性分析结果报告，是否真的可以施行，风险有多大？MES系统调研工作拥有这种的工作思维方式，企业本身内部业务流程需求调研分析阶段的工作任务在四个层面的调研就顺理成章了：关键业务流程关键要求的调研整体规划、企业本身IT技术指标分析及相关系统的详细分析与整体规划、执行MES系统新项目的团队与上线后日常运作支撑团队整体规划、MES系统执行成本预算及ROI投入产出比详细分析。MES是一个复杂的大系统，面对差异化极大的制造企业，想要真正达到预期的效果，需要MES系统产品提供厂商、执行服务商、制造企业，和中立的第三方服务机构共同努力。安达发MES系统，一个开放式的MES系统代表，既有适合大中型制造企业，也有适合中小型企业的C1智能制造管理软件，同时拥有石化MES、机加MES、注塑MES、电子MES、电线电缆MES等解决方案，是制造业生产管理值得推荐的MES系统。MES系统解决方案安达发能提供全面、高效的企业信息化解决方案，涵盖业界最优秀的APS高级计划排产、MES系统和WMS智能仓储，完美实现计划、排产、执行、履约、仓储闭环，是真正意义上的软件+硬件+管理的一体化解决方案，助力制造业数字化转型，成就智能制造发展新动能，实现卓越制造。

本文笔者将从系统的数据性能、系统的并发性、相应特性以及结构特性来对系统的性能需求进行分析。一、数据性能平台支持不低于400个在建工地的数据汇集和分析计算，系统应满足如下技术指标：1. 数据类型支持系统除支持一般结构性事务数据外，还需要支持主要二三维地理信息格式（shp、tiff、dem、3ds、max等），支持GPS、GLONASS、北斗等卫星定位数据，主要视频协议的接入。2. 数据量支持系统对GIS数据的支持能力不小于20TB；对图片、视频等非结构化数据的支持能力不小于200TB；对结构化数据的存储和查询数据量支持能力不小于500GB。3. 数据库性能要求根据本系统数据的特点,采用标准MYSQL语句，以便将来的扩展和移植。系统将采用数据库建模工具，根据系统功能模块的设计，构建出整个数据库。在构建数据库时，也会定义好数据库表的约束、关联以及索引。针对系统的具体特点和系统要求，我们在进行数据库方案设计时对数据库平台提出下列性能方面的要求：标准化程度高，符合标准ANSI SQL 92语言的规范；支持对称处理和多线程技术，支持XML/CORBA，支持数据分区；可在多种操作系统，HP、IBM等服务器下运行，独立性强，对系统结构影响比较小；高级语言、汉化功能先进，易于方便使用，支持汉字，GB18030标准；支持主流的网络协议，如TCP/IP、IPX/SPX、NETBIOS、DECNET、SNA等。能支持同构、异构网络分布操作，支持松散耦合及海量并行处理；有足够的并发控制，授权控制和事务处理能力及恢复能力；与异种数据源有良好的可互操作性；具有可靠的数据安全保密措施以及故障恢复能力；具有SMP和MPP功能，具有快速的并发用户查询速度，并发控制稳定可靠；具有很强的容错能力，错误恢复能力，错误记录及预警能力，具备异地容灾能力；允许行级锁，具有死锁自动解出功能而无需额外的数据一致性校验；具有强大的复制能力，支持主从式、级连式、对等式以及N-向复制，并支持复制日志技术，具有分布式模式管理能力；具有完整的安全性（帐号安全，系统级权限，对象安全性，审查等），细粒度化的访问控制，适合于多层环境的安全模式的能力；拥有支持MIS的功能强大的开发工具，提供数据仓库和数据挖掘的工具。二、 并发性1. 数据库并发数据库支持超过500个用户的并发访问能力。2. 访问并发管理端平台具备不少于100个访问并发的能力。3. 传输并发系统业务功能包括附件和图片的传输的时候，需提供稳定快速的传输效率，以及支持多附件多图片并发上传和下载的能力。三、响应特性1. 查询响应一般数据查询响应时间<5秒。2. 制表速度一般固定表格制表不超过10秒钟，复杂统计汇集表格不超过5分钟。四、架构特性1. 可靠性系统需提供7*24的不间断服务。2. 稳定性系统需合理的利用资源，保证前后台数据操作的效率，以及在数据响应和界面承载方面都要达到不会出现界面混乱、数据报错、触发按钮功能缺失、操作频繁或者快速容易崩溃的问题。3. 兼容性前端方面具有兼容各大主流浏览器的能力。4. 灵活性PC端前端自适应方面具有能够适配主流笔记本、台式电脑的能力，手机APP能够适应主流手机屏幕尺寸。5. 扩展性系统应便于新业务或者新功能的生成和实现第三方系统与平台的连接。另外，系统提供动态页面定制组件，能够有效的帮助运营方生成产品和服务表单，方便管理人员扩充分类目录等信息，并在权限管理、用户管理上有高度的灵活性、合理性。6. 诊断性通过详细信息资料的方式确保用户身份的可靠性，线上实施管理操作时，需确认用户的身份。为了防止操作失误，应该将用户的操作过程信息以日志形式保存，以作为失误诊断的原始依据。7. 扩充性保证已有平台和系统的兼容性及对未来发展的适应性，使系统可在原有的基础升级改造和更新，并应当充分考虑技术进步因素的影响。8. 开放性平台不是一个封闭的系统，今后必须通过接口和其他平台或系统相连，在平台建设中应充分考虑与外界信息系统交换的需求，保证既能满足基本功能的需要，有具有与外界系统进行信息交换与处理的能力。9. 可伸缩性要求在不用修改系统架构的情况下，通过增加或增强相应的设备即可实现系统功能的扩展支持，包括垂直扩展和水平扩展。9.1 纵向伸缩能够通过增加硬件资源提高目标平均性能和峰值性能（即响应时间、延迟等）及目标平均负荷和峰值负荷（即并发用户、信息量等）。9.2 横向伸缩能够通过增加应用服务器及实现应用服务器负载均衡、多节点等措施提高目标平均性能和峰值性能（即响应时间、延迟等）及目标平均负荷和峰值负荷（即并发用户、信息量等）。10. 可交换性系统应符合开放的原则，充分考虑各种业务需求有机结合，建立完善的系统整体构架，可与外部系统进行通讯并可提供标准的接口。既能实现业主业务，还可以完成数据交换、信息共享功能。11. 经济性系统应具备高性价比，能对系统资源的使用进行优化，在实现系统功能的前提下，尽量节省硬件资源的开销。12. 安全性主要体现在能够通过冗余措施加以保证，具体包括线路冗余、设备备份措施；能够在外网与Internet互连区采用安全可靠的防火墙；能够建立完整的网络防毒机制，以及建立严格完善的防毒管理规范；能够确保必须的网络服务的安全和可靠性，如DNS；对其它网络基本服务，限制使用范围，建立严格的使用管理规定，防止被黑客利用，绝对禁止匿名FTP服务，对需要使用又必须保证安全的场合，要经过身份认证、访问授权和审计记录机制的控制；能够在Internet互联区域及与内网互连区域设置防火墙，并采用防黑客攻击软件实现安全漏洞的扫描，结合系统管理及时修补安全漏洞；提供网络实时入侵检测，在一定程度上实现对内网与外网的入侵阻隔；做好攻击的跟踪审计；能够防止网站数据被非法篡改，并且在被篡改之后能够及时的恢复。13. 业务驱动性项目实施以提供业务支持为首要因素。应从业务实际需要出发，选择重点与关键的环节进行信息化管理与控制，在信息化价值和灵活性、管理工作量之间取得良好的平衡，保证在系统实施后能提高工作效率、降低成本。14. 集成性系统具有良好的集成性，对流程审批、数据获取、信息集成等功能提供标准接口，以实现与其他相关系统的功能和数据集成。15. 可层次性系统可以统一各个层次管理规范，统一数据结构、数据表达方式、数据访问方式。16. 可模块化性系统须提供通用的组件支持，能够减少重复开发工作，保证产品和项目的质量，缩短应用系统的开发周期，有利于系统的扩展。在统一的数据环境下集成化开发各个模块，模块的划分应独立于当前的组织机构，各个模块之间的数据交换是结构化的、公用的，从而也是高效的和完整的，最大限度消除冗余和不一致。17. 可维护性方案和产品的架构须紧密跟踪国家信息安全、业主标准和国际主流技术标准，开放性好，便于系统的升级维护、以及与各种信息系统进行集成。18. 先进实用性系统规划和设计理念可对照现有技术先进、成熟的产品，提高用户体验，以减少系统开发的周期和成本；功能定位充分考虑平台服务对象的需求。结语请路过的朋友们多多支持哈，笔者在这里先谢谢了，以后会有更多优质的文章在这个平台上进行发布，请尽请期待呦！本文由 @卧枕江山 原创发布于人人都是产品经理。未经许可，禁止转载题图来自Unsplash，基于CC0协议

在前面的课程中，我们主要讨论了人脉V1.0系统的角色及角色间的关系，也讨论了角色的属性和行为。在这节课中，我们将使用UML建模语言的用例图对人脉V1.0系统的角色及角色行为建立系统功能模型。在建模之前，先简单介绍一下什么是UML建模语言。UML是面向对象开发的建模语言，由OMG（OMG是一个世界性的计算机标准协会），该协会致力于发展和传播面向对象系统，OMG在1997年公布了UML建模语言标准。UML定义了9种模型图，为软件开发过程的需求分析、系统设计、系统部署阶段提供建模支持，这9种模型图分别是用例图、类图、对象图、状态图、活动图、序列图、协作图、构件图和部署图。这些模型图从不同的侧面对系统进行建模。在需求分析阶段，UML使用用例图、类图、协作图、顺序图和状态图从面向对象的角度出发来定义应用需求。在大多数情况下，为了得到一个完整的业务需求定义，这5种模型都要使用。但在系统功能相对简单的情况下，可以只使用用例图、类图、顺序图来定义需求。用例描述了角色在系统中承担的职责，用例从系统角色的角度对系统功能进行建模。也可以说用例是事件表的延伸，事件表最先捕捉到系统需要响应的事件，然后通过事件表分析出系统角色，确定角色的属性和行为，最后再通过用例图对系统功能建模。下图显示了一个用户注册的用例。一个简单的小人图形表示系统角色。这个小人图形有一个可以表示其角色的名字。用例用一个在里面标有名称的椭圆所代表，角色与用例之间的线条表示了角色参与哪些用例。图 1 有一个角色的简单用例用例表明了角色与系统如何交互来完成业务活动，用例包含完成这个业务活动的所有步骤，这些活动步骤需要在用例中完整描述出来。一个用例可能会对应不同的活动场景，例如用户注册可能会对应在手机端注册和电脑端注册两种活动场景。所以，场景是对用例内部活动的识别和描述。绘制用例图时，我们需要明确角色和用例，用例和用例之间的关系。角色和用例是关联关系，也就是角色参与到这个用例中，关联关系是一条直线（有些UML绘图工具也使用带单向箭头的直线），用于连接角色和用例。图 2 角色和用例的关联关系用例和用例之间主要是包含关系、扩展关系和依赖关系。包含关系包含关系是指一个用例在执行过程中，会调用另外一个用例来完成相关任务，也就是在一个用例的内部包含了另外一个用例。例如，用户注册和用户登录用例都需要调用数据库角色的存储用户信息用例，在这种情况下，就可以把数据库角色的存储用户信息用例包含到用户注册和用户登录用例中。图 3 用例和用例间的包含关系扩展关系扩展关系是一个用例对另一个用例功能的扩展。例如，用户注册有手机端注册和电脑端注册两个注册场景，则可以把用户注册作为基本用例，手机端注册和电脑端注册作为扩展用例。图 4 用例和用例间的扩展关系依赖关系依赖关系是一个用例在活动执行过程中，要依赖另一个用例的执行。例如，A用例依赖B用例，A用例或使用B用例执行后的返回结果，或使用B用例执行部分功能。依赖关系类似于包含关系，都是在用例执行过程中，调用其它用例来完成部分任务。了解了用例的关系和绘制方法后，我们就可以根据前面给出的角色表来绘制人脉V1.0系统的用例图。绘制用例图使用的工具有很多，在这里我使用Visio工具绘制用例图。我们分别绘制用户角色、名片角色和数据库角色的用例图。用户角色用例图下图是用户角色用例图，用户角色用例有注册、登录、添加名片、编辑名片、删除名片、查看名片和翻阅名片用例。虚线椭圆的用例是数据库角色和名片角色的用例，这些用例被用户角色的用例所使用。例如，下图的添加名片用例使用了名片角色的存储名片用例，而名片角色的存储名片用例又使用了数据库角色的存储名片信息用例。其中注册用例没有按注册场景分，这是因为在V1.0版我们主要考虑在电脑端注册。图 5 用户角色用例图名片角色用例图下图是名片角色用例图。名片角色用例有存储名片、获取名片、查询名片、删除名片和展示名片用例。图 6 名片角色用例图数据库角色用例图下图是数据库角色用例图。数据库角色用例图有存储用户信息、存储名片信息、获取用户信息、获取名片信息、名片查询和删除名片用例。图 7 数据库角色用例图至此，我们已经完成了人脉项目V1.0系统用户角色、名片角色、数据库角色用例图的绘制，建立了人脉项目V1.0系统功能需求模型。下节课我们将对每个用例配置用例规约。

在前面的课程中，已经了解了结构化开发方法和面向对象的开发方法，并且学习了分析和设计阶段的活动以及这些阶段的每一项活动的目标。从这节课开始，我们将结合人脉项目，讨论在分析阶段使用的技巧及有关任务。分析阶段有两个关键任务，分别是识别系统需求和根据系统需求为系统建立需求模型。一般说来，负责开发软件项目的项目经理或系统分析员，需要尽可能地了解软件项目涉及的业务活动细节，这是因为只有熟悉了项目的业务活动细节，才能确保系统完全满足业务需求。例如，人脉项目是社交类项目，社交涉及的业务活动都需要熟悉和了解。如微信是主要的社交软件，只有了解微信的分享、微信公众号等业务功能，才能实现人脉项目与微信的互动。功能和技术需求系统分析阶段要做的主要工作就是确定系统需求。系统需求是新系统必须要完成的功能，在《人脉项目技术要求》任务说明书中已经给出了系统的功能范畴。在系统分析阶段，项目经理或系统分析员需要详细地定义和描述这些功能，换句话说，项目经理或系统分析员要把这些高层功能分解为详细的系统需求。一般而言，系统需求分为功能需求和技术需求两类。功能需求是系统必须完成的活动，功能需求直接来自项目招标书、任务说明书、项目合同书等确定的系统功能。例如，在《人脉项目技术要求》任务说明书中规定了项目要实现这样一些功能：支持人脉资料的自动识别、批量导入和手动录入、支持人脉资料的管理和分类、支持构建人脉网络结构等等。这些都是人脉项目要实现的功能，确定和描述所有这些功能需要花费大量的时间和精力，给功能需求建模是理解功能需求最好的方式。技术需求是描述软件运行环境和性能目标的系统需求。例如在《人脉项目技术要求》任务说明书中，要求人脉项目支持Windows和Linux平台、支持的移动终端为Android平台和iOS平台、用户访问系统并完成操作的响应时间一般控制在5秒以内等等，这些都是技术需求。对于新系统的完整定义，功能需求和技术需求是必不可少的。这两种系统需求都包含在系统需求调查中，功能需求通常记载在已建立的分析模型中，技术需求则通常记载在技术需求的叙述性描述里。系统相关者系统功能需求的主要来源是新系统的各种系统相关者。系统相关者是对系统感兴趣的人。系统相关者有三类，一是类是使用系统的人，这类人也称为用户；二是购买和拥有系统的人，这类人也称为客户；三是确保系统运行的维护人员，这类人也称为技术人员。图 1 人脉项目系统相关者用户是使用系统处理日常事务的人，用户在使用系统时可能会处于不同的角色，不同角色的用户对系统会有不同的需求。例如在库存管理系统中，会涉及到生产部门、进货部门、仓库和销售部门，每个部门的工作人员对系统的需求都会不同。因此在调查系统需求时，必须要确保这些部门的每个人都讲述了自己的需求。在人脉系统中，如图1所示。用户分为商务用户、普通用户、学生用户、职业用户、客户和技术人员。商务用户会有维护客户关系、拓展客户的需求；普通用户可能就是单纯记录通讯资料的需求；学生用户更注重于社交资料的真实性、个性化数字名片、校园社交等需求；职业用户包括公务员、医生、律师、科技工作者等用户，这类用户会有社交圈、分享等需求。客户是为系统提供资金的人和组织。客户可能是项目招标方、购买系统的个人和组织、制定项目的公司管理层等。把客户包括在系统相关者列表中，是因为项目开发小组必须在项目的整个开发过程中，始终向客户提供项目进展的概要情况。技术人员并不是真正的用户，但他们是技术需求的来源。技术人员包括系统研发人员和维护系统运行的人员。技术人员会在编程语言、技术体系、计算机平台和其它设备方面对项目提供帮助。如何识别系统需求？在系统开发中分析阶段的目标就是要理解项目涉及的业务流程和定义系统需求。理解一个新系统的业务流程，最好的方法就是做好系统相关者的需求调查。也可以通过确定类似系统的业务流程和活动，来推断出新系统的业务流程和系统需求。类似的系统可以是原有的系统，也可以是第三方公司的产品。图 2 识别系统需求的方法在进行系统分析时，项目经理或系统分析员首先要问的问题是：我需要收集哪方面的信息？通常情况下，调查系统需求主要是获取能够建立新系统逻辑模型的信息。开展系统需求调查可以从三个问题入手：● 项目涉及的业务过程和活动是什么？也就是提问用户“你要干什么”？● 业务过程和活动该怎样完成？也就是提问用户“你准备怎么完成它”或“需要哪些步骤”？● 需求信息是什么？也就是提问用户“为了实现这些业务过程，你需要哪些信息”？第一个问题“你要干什么”。是从用户的角度来理解系统要完成的功能。在大多数情况下，用户会从已知的系统或者自身的需求来作出回答。作为项目经理或系统分析员需要从用户的回答中仔细辨别出用户提出的功能，哪些功能是重要的，哪些功能是需要保留的，哪些功能是需要删除的。例如，人脉项目的商务用户可能希望在节假日给选定的客户自动发送贺卡等。第二个问题是“你准备怎么完成它？”。从用户的角度描述完成功能的步骤。例如在自动发送贺卡功能中，用户可能希望首先选定要自动发送的客户，然后设定发送的时间，再设置贺卡模板，输入贺卡内容，最后系统在设定的时间自动发送贺卡。第三个问题是针对第一个和第二个问题的。用户提出了新系统的功能和完成步骤后，项目经理和系统分析员需要确定要给系统提供哪些信息来完成这些功能。第一个问题和第二个问题用于确定新系统的功能及完成步骤，第三个问题给出了描述第一个问题和第二个问题的具体信息。对这三个问题的回答定义了系统需求的基础。作为一个项目经理或系统分析员，理解用户需求并建立需求模型是最重要的能力之一。调查系统需求时也可以遵循一些已经证明行之有效的方法，这些方法往往被项目经理和系统分析员组合起来使用，提高了系统分析的效率，这些方法可以广泛地用于不同规模的软件项目开发中。下面列出了这些方法：● 向系统相关者分发和收集调查表● 复查现有报表、表格或过程描述● 主持与用户的面谈和讨论● 观察类似系统的过程和工作流● 建立新系统原型在后面的课程中会介绍如何使用这些方法。小结1、系统需求主要由功能需求和技术需求组成。功能需求是系统必须完成的活动。项目招标书、任务说明书、项目合同书等确定了系统的功能范畴。在分析阶段，项目经理或系统分析员要把这些高层功能分解为详细的功能需求；技术需求是描述软件运行环境和性能目标的系统需求，例如系统的性能指标等。2、系统功能需求的主要来源是新系统的各种系统相关者。系统相关者是对系统感兴趣的人。如使用系统的用户、购买或给系统提供资金的客户、技术人员等。3、识别新系统需求最好的方法是做好系统相关者的需求调查，调查系统相关者的方法有向系统相关者分发和收集调查表、复查现有报表、表格或过程描述、主持与用户的面谈和讨论。也可以通过确定类似系统的业务流程和活动，来推断出新系统的业务流程和系统需求。

大牛：“上节课我们讲到了需求分析常用的逻辑模型，对常用的需求模型有了大概了解。本节课来认识需求分析的基础——事件”。大牛在黑板上写下了本节课的学习内容。● 什么是事件？● 事件的类型大牛：“所有的系统开发方法都是以事件开始建模的，事件发生在某一特点的时间和地点、可描述并且系统应该记录下来”。大牛：“我们来看个例子。家中用的空调都是自动调节温度的，用于调节温度的重要部件是温度控制器，它可以感知周围的环境温度。当温度高于设定温度时，温度控制器触发继电器闭合，空调运转，当温度低于设定温度时，温度控制器触发继电器断开，空调停止运转”。随后大牛将一张图片投影到屏幕上。图 2-4 空调温度控制器事件大牛：“从这张图可以看出，温度控制器本身触发了2个事件，一个事件是当温度高于设定温度时发生，事件发生后执行的动作是启动空调；另外一个事件是当温度低于设定温度时发生，事件发生后行的动作是关闭空调”。大牛问小白：“小白，如果把空调看作系统，你来说说，该系统还需要响应哪些事件？温度控制器的事件就不要说了”。小白：“定时事件、温度调整事件、风速调整事件、还有选择制冷还是制热的事件，暂时想到了这么多”。大牛：“其实，只要是触发系统响应并处理的，都可以称为事件。例如，空调的启动与关闭本身也是事件，启动空调会触发一系列如风扇开启等动作，关闭空调会触发风扇停止运转等动作”。小白：“按这样理解的话，空调系统有太多事件了”。大牛：“是的，系统所有的过程都是由事件驱动或触发的，因此，当你定义系统需求时，把所有事件罗列出来并加以分析是很有意义的”。大牛在黑板上写下了事件的描述。什么是事件—可以描述的、值得记录的在某一特定时间和地点发生的事情。大牛：“当为一个系统定义需求时，先调查清楚能对该系统产生影响的事件是十分有用的，概括说，就是什么事件发生时，需要系统做出响应？”。大牛在黑板上强调了下面这句话。什么事件发生时，需要系统做出响应？大牛：“这样做的好处是，通过调查对系统有影响的事件，你可以把注意力集中在系统外部环境上，并把整个系统看成一个黑盒，从较高层次上全面考察系统，而不是集中在系统内部工作上”。小白：“哦，明白了。譬如前面的空调例子，如果让我调查空调系统需求的话，我得先找出空调系统能够响应的事件，像定时、温度调整、风速调整等事件”。大牛：“非常正确。通过调查分析得出的系统事件可以把系统需求划分为多个部分，把复杂的系统需求分解成容易处理并能更好理解的小单元，分而治之也符合我们处理复杂事情的原则”。大牛：“小白，咱们尝试对第一课的案例进行分析，看看这个案例有多少个系统事件？”大牛把第一课的案例内容投影到屏幕上。某一快餐连锁店，一直为顾客提供快餐服务，由于价格实惠，服务优良，到店吃饭的顾客很多，顾客需要排很长的队才能点餐和配餐，严重影响了顾客体验。快餐老板希望能够实现顾客电话预订餐，顾客提前通过电话预定餐，并预约到店时间，这样快餐店可以提前做准备，缩短了顾客在餐厅的等候时间。大牛：“既然是电话订餐，就要有打电话、接听电话、记录电话内容、通知厨房备餐、取餐等操作。小白，你来分析一下电话订餐系统有哪些事件是需要系统来响应并处理的？”小白：“客户打来电话是一个事件”；小白：“接听电话也是一个事件”；小白：“还有记录电话内容、备餐完成、顾客到店、取餐等事件”。大牛：“我们来分析一下你说的几个事件，先说客户打来电话这个事件”。大牛：“客户打来电话后，系统要记录电话号码、拨打电话时间，并自动拨通分机号码。因此，客户打来电话是系统事件”。小白：“牛老师，我有点不明白哦。客户打来电话，客服人员不就直接接电话了嘛，系统怎么记录电话事件啊？需要服务人员来记录吗？”。大牛笑了笑：“一般的电话订餐系统都是和通讯设备结合的，用于控制电话的接听、转接、记录通话时间等”。小白：“哦，明白了”。大牛：“再来看第二个事件——接听电话”。大牛：“客服人员拿起电话后，需要系统做出什么响应？”。小白：“我想，应该是需要给系统发出电话已经接通的消息”。大牛：“对，接听电话也是一个事件”。大牛：“再看——记录电话内容事件，记录电话内容应该是客服在系统的订餐界面选餐或输入订餐内容，此时系统需要响应客服的输入，因此也属于事件”。大牛：“你说的还有一个事件——顾客到店，顾客进入店中，并没有直接影响到系统，系统对顾客进入店中也无需进行响应，只有当顾客提出取餐时，系统才开始响应。因此，顾客到店不是事件，取餐是事件”。小白：“怎么才能识别哪些是事件，哪些不是呢？”。大牛：“需要系统做出响应的就是系统事件。例如：顾客到店后，对系统并没有影响，只有提出取餐后，系统才开始响应”。小白：“哦，明白一些了”。随后大牛将一张图片投影到屏幕上。图 2-5 影响电话订餐系统的事件大牛：“这张图列出了影响电话订餐系统的事件，云形灰色区域内的事件是系统内部发生的临时事件。例如，当顾客在预定的时间没来取餐时，系统应给出提示，再如，系统需要每天在规定的时间形成当天的订餐单汇总表。云形灰色区域外的事件是系统之外发生的事件，如顾客拨打电话、顾客支付订餐费用等”。小白：“还是牛老师厉害，这些事件我怎么都想不到呢？”。大牛哈哈大笑：“你现在已经不错了，定义系统需求需要长时间的经验积累，相信你会慢慢成长起来的”。小白：“事件还分为临时事件和外部事件？”。大牛：“是的，定义系统需求时，我们需要考虑三类事件，外部事件、临时事件和状态事件”。大牛：“前面我们分析了电话订餐系统的事件，其中拨打电话、取消订餐、取餐等事件都是由顾客触发或参与的，顾客可以称之为外部实体或动作参与者，它为系统提供信息或从系统中获取信息”。小白：“外部实体是仅指人吗？”。大牛：“外部实体可以是一个人，如顾客；也可以是一个单位或事物，如学生信息管理系统的课程”。大牛：“为了识别系统的关键事件，首先需要确定有哪些外部实体从系统中获取信息或为系统提供信息。例如，电话订餐系统的顾客就是很重要的外部实体，顾客拨打电话订餐对电话订餐系统来说是个非常重要的事件”。大牛：“和顾客相关的还有其它事件，如当顾客想取消订餐时、或者顾客支付订餐费用时，诸如此类的事件称为外部事件，这些外部事件需要系统响应并处理”。大牛边说边把外部事件的描述写在黑板上。外部事件—系统之外发生的事件，通常都是由外部实体或动作参与者触发的。大牛：“当描述外部事件时，需要给事件命名，这样外部实体才能清楚。如电话订餐系统中，拨打电话这个事件可以命名为——顾客拨打电话”。大牛：“顾客拨打电话这个事件描述了一个外部实体（顾客）以及这个顾客想做的事情（拨打电话），这个事件直接影响着系统”。小白：“一个很重要的问题，如何识别外部事件呢？”。大牛：“识别外部事件并不容易，但是有一些方法可以帮助我们识别外部事件”。大牛：“一种方法是当外部实体需要系统响应时。例如，电话订餐系统的顾客拨打电话”。大牛：“再一种方法是当外部实体需要从系统获取信息时。例如，电话订餐系统的顾客取餐时，服务人员需要从系统中获取该顾客的订餐信息”。大牛：“还有一种方法是当外部实体需要变更系统信息时。例如，电话订餐系统的顾客需要取消订餐或者变更定餐内容时”。小白：“用这些方法来识别事件，相对就容易些了”。大牛把识别外部事件的方法写到了黑板上。识别外部事件的方法—当外部实体需要系统响应时当外部实体需要从系统获取信息时当外部实体需要变更系统信息时大牛：“前面说了外部事件，再来看看临时事件”。大牛：“前面分析的电话订餐系统的事件，也包括了一些临时事件。如未取餐提示、未备餐提示、定餐单汇总都属于临时事件”。小白：“为什么这些是临时事件呢？”。大牛：“这些事件有一个共同特征，都是在某一时刻发生的事件。例如，当顾客在规定的时间没来取餐时就会触发未取餐事件，系统将做相应处理。再如，在每天的固定时间内生成当天订餐单汇总表”。小白：“哦，在某一时间需要系统处理一些事情的事件是不是可以称为临时事件呢”。大牛：“对，临时事件是到达某一时刻所发生的事件。许多系统按预定的时间间隔产生一些输出结果。例如，工资系统每月生成工资表。换句话说，没有外部实体参与，而是系统自身在需要的时候产生所需的信息或输出”。大牛边说边把临时事件的描述写在黑板上。临时事件—系统到达某一时刻自身触发的事件。大牛：“临时事件不一定非要在确定的时间发生，也可以在预先定义的一段时间过后发生。例如，当客户购买商品后，在某一时间段内没有支付商品费用，淘宝系统会自动关闭该交易”。大牛：“临时事件命名一般都采用需要系统产生的结果这种方式来命名。例如，电话订餐系统中的未取餐提示、未备餐提示、定餐单汇总事件命名”。小白：“明白，那如何识别临时事件呢？”。大牛：“当系统需要在某一最后期限之前必须完成的任务，可以确定为临时事件”。大牛把识别临时事件的方法写到了黑板上。识别临时事件的方法—当系统需要在某一最后期限之前必须完成的任务时当系统需要有内部输出结果时当系统定时需要对外部输出结果时大牛：“前面了解了外部事件和临时事件，再来看状态事件”。大牛：“状态事件类似于临时事件，也是系统内部发生了需要处理的情况时所引发的事件。例如，淘宝商户所售商品的库存降到了一定数量后，就必须要提前进货，该状态事件可以命名为‘达到进货点’”。小白：“哦，状态事件也和临时事件一样，都是由系统内部触发的，它们之间有什么区别吗？”。大牛：“问得好，虽然状态事件和临时事件都是由系统内部触发的，但有所区别，状态事件无法定义事件发生的时间，而临时事件都是在固定的时间或过后一段时间触发”。小白：“明白了，状态事件不受时间的控制，可能会随时发生，而系统又必须要处理的”。大牛对小白点了一个赞：“说的不错”。大牛把状态事件的描述写到了黑板上。状态事件—当系统内部发生了需要处理的情况时所引发的事件。大牛：“这节课主要了解了影响系统的事件，以及事件的类型。事件的类型有外部事件、临时事件、状态事件。外部事件是由外部实体触发的，如电话订餐系统的顾客；临时事件是系统在某个固定时间自动触发的；状态事件是系统内部发生了需要处理的情况时触发的。下节课，我们将主要学习如何从识别影响系统的事件”。