摘要：今天去和包括众多业务使用人员在内的客户进行一次系统原型、完善需求的讨论。用了大半天的时间，有几点心得。1、交流过程中，客户的思路是无序的，他们并不可能按你的预先的设计的次序去依次交流一些问题。“想到哪说到哪”这个词最恰当不过。这可能就需要我们既要一个引导，不能总是不得重点，以免在有限的时间内不能完成预先的交流计划。同时，可能也需要我们真正要注意他们所谈到任意一个方面，尽管这个方面不是你当时所关注的......
摘要： 项目中有个子系统规模不大，利用这次对其彻底重整的机会，准备建立这个业务领域的业务模型。调研了两家单位，整理出的业务模型主要有以下部分： 一、业务组织 1、业务角色的描述分析 2、业务工人的描述分析二、用例模型 1、全业务领域的uml用例图及用例关系。 2、以业务用例的格式对各个业务用例的详细文字编写。三、业务实体 1、业务实体的文字定义描述。 2、业务实体的uml关系图。四、业务术语
......
探索需求（2）我刚接手的一个项目,一个核心的业务子系统在很多地方客户都提了完善的意见.并且有很多功能还无法实现,易用性设计也比较差.总之要改造的地方很多.我采用用例把所有要改造的功能点重新表述出来,这在分析系统功能上要远比使用菜单表达更合理,因为即便一个最底层的子菜单也并不代表就是一个软件的功能点,另外,菜单的组织是着眼于便于客户使用与便于导航的,它与系统功能并没有一一对应的关系. 用例毕竟是软件领域的技术方法,对于客户来说,理解阅读用例的每个元素所代表的意义应该说还要一段时间的交流与适应.用例可以很方便的让系统分析员根据功能点主事件流做出原型.而原型可以使软件实在化.用原型配合的需求交流,比起让客户阅读一份冗长无味的软件需求规格说明自然会取得很好的效果.当然,原型最终的有效性是需要目标用户群的充分检验评价的,因此«softdemand»提示与客户交流原型要关注以下问题: 这个原型所实现的功能与你所期望的一致吗?有遗漏的功能吗?你能考虑一下这个原型所没涉及的一些出错情况吗?有多余的功能吗?这些导航对于你意味着怎样的逻辑性与完整性?有更简单的方法来完成这一任务吗?
摘要：《程序员》杂志第七期有篇潘加宇的文章《业务建模vs系统建模》。最近正好一直在做业务建模和系统建模的工作，所以对这篇文章中的很多观点体会颇深。 ? 1、“业务建模并不意味着有软件项目开发跟随”。 记得一年前，公司一个会我发言，为了说明扎扎实实调研分析透客户单位的实际业务对后期系统需求分析的重要以及要避免过早去考虑软件系统需求甚至设计的时候，我说“我们就假设我们调研不是要开发软件，就是要弄清楚实际业务......
