摘要：抓住三个点：根，生命周期，以及结构化； 所谓根，就是根本，底层；对于需求分析而言，这个根就是这个项目的基本概念，比如对于机务维修系统而言，基本概念就是定期检修检，预提，预算，直接成本，间接成本；至于和海波龙系统交互等等，都是基于这些大的概念进行的；做到架构设计，这个根本，很大程度上就是对业务流程的抽象化理解，比如在中广核项目中，是一个订单，发货，运输，到货检验最后库存的过程；感觉上中间的环节非常多... 阅读全文

摘要：今天下午开需求评审会，我才更加深深的认识到：理解需求的"故事"以及"故事背景"的重要性；伴随着魏华的"你讲的都是流程节点，没讲出来要干些什么"，我就已经准备谢幕了。后来杜工上阵，把这帮人搞定了。其实，很多时候你那什么来"压人"，其实就是这种对于背景和认知的"优势"，炒股讲究"信息"优势，"卖方"讲究的是"信息不对称"，优势其实很多种，总之，你要比别人多一些东西，这些东西越多（故事，背景），越沉（思... 阅读全文

摘要：数据和事件分开 先从Peter的数据和事件分开说起，Peter找了李福华讨论了返运的需求实现，他的建议是将库存和返运关系分离开来，即数据和事件分离开来：不要让（事件）状态污染数据，对于正常入库、调拨入库这属于原生态状态（Native Status）没问题，对于返运这种后天事件导致的状态就不要用来污染数据，而是单独页面承载操作，单独表结构来存储状态；我是深以为然；如果这样，出库是否也应该分离出来呢？... 阅读全文

摘要：需求建模与分析篇 需求分析基本遵循三个方向，依次是：流程，对象以及关系，用例（操作容器）； 流程对应的是跨职能流程图以及活动图，对于活动图，实在是没有感到有什么优势可言；但是对于流程图究竟要细化到什么程度？只要是不影响泳道的变更就可以作为一个节点处理，这个还有待考证； 对象以及关系，作者首先推荐的是类图，但是对于类图其实使用在设计阶段，作为需求分析阶段拿了一张类图给客户看，给客户讲解你所识别出来的... 阅读全文

摘要：对于需求而言，最宏观的概念是六字诀： Who->Where->Which->How->End->Effect；谁（Who）在什么地方（Where），对那个对象（Which）做了什么（How），做完了（End），影响是什么（Effect）； 在How上面要做的文章是最多的，How其实本质就是场景，操作，数据（对象）。 刷墙 只要是被操作的数据就需要考虑是否需要添加状态，比如IMS审批从NPIOT系统... 阅读全文

摘要：需求分析七个点： 这是那一部分的业务（发货/收货/库存）Where； 出发点时机是什么When 描述的哪一个粒度，订单，订单行项目，发货明细...业务的操作是哪一个级别的？（比如调拨和WAS单是一个级别，这意味着在操作流程彼此不干扰）Which，这个Which也是之前文章提到过的"核心对象"；还需要对核心对象的属性进行跟踪，比如通过要来原始票据等方式； 操作的闭环是什么？End； 产生的数据后续如... 阅读全文

摘要：对象拿到一个需求之后首先要分析的就是这个需求的主键是什么，关键对象是什么，然后再来分析于此相关联的对象都有什么，是否有什么漏洞约束约束是神呢；限制有哪些； 关系都有哪些对象，这些对象的关系怎么样？1：*，0:*；还是1:1等等。 阅读全文

摘要：之前我们聊过了需求分析的输入-处理-输出模型，以及核心业务对象的识别，今天继续深化一下： 核心对象 到底什么是核心对象？比如设定某个设备周定时任务，定时任务是核心的对象吗？不是。周定时任务作用的对象是设备，核心对象是设备。这样的感知导致的结果是应该将设备从周任务分离出来，而不是周任务的一部分。最初设计的是周定时任务有一个mac地址属性，会将设定的设备使用“，”分割，这样设计设备是作为周定时的一... 阅读全文

摘要：1.码段的查询结果的汇总值计算有问题。被删除的是否还算是被使用范围内呢？现在是即使废弃了也算使用的。这就有范围和重叠的问题，需要识别这种集合关系的数据好概念，并搞清楚他们的关系和概念。 阅读全文

摘要：我纠结于我们项目组的预提金额问题，这里有两个问题，第一，我发现自己一直在弄错一个，我觉得最好的方式就是讲故事，而且这个故事一定要讲述的非常完整，才能真正的把一个需求讲明白，这个故事里面首先一定要有 有触发事件：是什么触发这个故事，是固定的时间，还是什么事情发生了（前置事件）。 人物（角色）：这个故事的主角是谁，配角是谁。 时间：这个故事发生在什么时候。 情节：或者说流程怎... 阅读全文

摘要：本文转自tudou@NorthWind 话说小P刚刚加入到一个项目组里面，项目经理安排他做需求分析，小P一听需求分析就有点不乐意，心里嘀咕：“需求有什么分析的啊？客户要什么给什么呗，简直是浪费我这个人才！” 虽然不乐意，但毕竟工作还是要做，很快小P接到了的第一个需求，客户打电话来说“我要一只羊”，小P一听就觉得太简单了，简单的写了一下需求“XXX客户需要一只羊”，然后就交给同样是新手的小Q去处... 阅读全文

摘要：先不说那种需求说明给客户糊弄的情况，如果你希望书写一份需求说明书对于开发有知道意义，描述清楚需求，那么你需要描述清楚下面的事情： 1.功能描述 业务背景：对于业务应用的描述，即该业务（产生的数据）应用在那些场景下；还要包括对于一些概念和原理的解释。 业务场景：描述操作者如何使用这个业务，这里包括常用方式，非常用方式。 操作角色：拥有什么权限的人拥有此项业务的操作权限。 ... 阅读全文

摘要：客户的需求和观点只是引子，至于怎么去圆这个需求还是需要和他们进行真刀真枪的讨论，决不能一带而过。 1.需求的设计其实很多时候没有正确错误之分，有的就是一个策略的指定。比如腾讯空间的好友动态，不是严格按照最新的显示，而是按照人，一定程度最新的显示。 2.需求分析不要听客户的讲述，一定要进行论证和讨论。比如客户曾经讲过：OrderType直接可以和成本科目对应，但是实际上一开会讨论，才发现其实真正... 阅读全文

摘要：不要担心客户会讲“这个你不用关心”，你需要知道和需求相关的场景，因为了解了场景之后才能一定程度上保证理解的准确性。很多时候就是问“场景”比问“为什么”会更加缓和一些。至于不用担心只是一个原因：不要担心让客户不爽。还是那句话：只有让客户有时候有些问题不爽，才能说明你的能力和强硬，才说明你的需求拿的比较到位。 阅读全文

摘要：什么是需求分析？对于临场而言其实其实是两条线：客户介绍流（需求），通过提问题来过滤需求，分析需求的分析流（分析）。这两条流一定都要关注，每当通过介绍流了解一部分业务之后，就要切换到分析流，来考虑是否落在真实需求范围内，这些业务是否是在本系统中完成的，如果是，那么输入是什么？如果不是那么需要我们系统做什么？当牵涉到和别的系统协作，工作流程又是如何？ 阅读全文

摘要：1. 准备结果列表 一定要在需求调研之前有一个成果列表，就是一次调研会议应该是由他们的主题，那么基于这些主题，你需要了解那些信息，解决那些问题？你需要一个成果List。有感于今天我们开会，赵工一说，好今天就这样，大家这都起座要离去，我们的项目经理发现一个租赁的业务还没有介绍清楚，马上跟言：还有租赁的业务没有介绍，于是接口人员赶忙叫来了相关人员，继续开会。通过列表可以校验此次会议的目标是否已经达成... 阅读全文

摘要：1. 时刻抓住主线路，客户介绍的一个集合，你需要过滤把握对你有用的子集。客户再给你讲系统的时候很可能是洋洋洒洒，介绍自己熟悉的东西，但是我们做需求的人一定要明确自己需要获取业务信息。做需求分析一定要时刻抓住主线路，可以让对方讲一些拓展的东西，但是自己一定要清楚关心的是核心业务+核心对象是什么，用户的对于核心业务+对象的意图如何，现实中又是如何操作的。在和某航空公司的信息以及生产部门负责人谈需求的时候，他们介绍自己的业务头头是道，我们的项目经理一般都会等对方介绍完毕问道：这些业务中那些是和我们的XXX业务相关？如何相关？你们又是在现状中如何使用的？在上图中重叠的部分是客户提供的实现范围内的需求， 阅读全文

摘要：昨天和住房公积金办回来，在和工作人员讨论“需求”时，对方抛出了需要北京连续缴费一年。对方的说法和我之前的听说的不一致，我所听的是包括在大连缴费满一年证明即可，但是当时的我忽略了这一说法的来源，所以没有和对方据理以争。回来后我打电话96688，大连公积金对外电话，得到明确的回答，证明连续缴纳一年即可，即使异地。 做需求分析，和人讨论一样，需要做到如下： 1.梳理清晰我对于... 阅读全文

摘要：需求分析大致分为三个阶段：头脑风暴，梳理需求以及校验需求。 1. 头脑风暴 实际操作是需求收集。无条件的收集客户各方面的信息，需求，反馈； 2. 梳理需求 首先就是参照着范围说明书，搞清楚此次调研的需求范围是什么。然后便是对需求进行筛选，剔除掉范围外的需求，当然这一步也可以是在头脑风暴，收集过程中进行。经过了初步的筛选之后，就开始罗列范围内的需求，并和客户确认需求的优先级别，每条需求的... 阅读全文