要确定业务实体，首先必须确定角色，并从角色的行为找出业务实体。角色需要我们对目标组织进行讨论。以我个人的经验，寻找业务角色一般比较简单，但是要记住，一个人可能担任好几个的业务角色，这是经常发生的情况。从业务角色的行为，我们可以找出业务角色所处理的事物，这些就是我们所需要的业务实体。业务实体是一个单独的业务实体还是业务实体的一个属性是值得研究的。一个本该是属性的事物被判断成业务实体只是会带来一些开销，可是一个本该单独列出的业务实体却只是被判定为其它业务实体的一个属性就有可能会带来灾难性的后果，最大的可能是系统难以扩展。
在一个人力资源管理系统中，员工类可能是非常重要的一个业务实体，它可能有非常多的属性。而在其它的系统中，例如进销存，员工类只是起到一个记录、权限管理的作用罢了。再比如，在一些企业内部的自动化处理系统中，客户可能只是其它一些实体的属性，而以客户为中心的设计大行其道的现在，这种设计就有它的致命缺陷。
要确定业务实体的属性和行为，主要是要确定每个类（业务实体）要做的事情，属性则是为了能够更好的描述类和类要做的事情。利用CRC卡片是一个不错的办法。
CRC是"类"（class），"责任"（responsibility）及"辅助者"（collaborator）三者的简称，这些资料常呈现在一张卡片上。
类名称
责任1 责任1的辅助者1
责任2 责任2的辅助者2
… …
通过制作这样的CRC卡片，可以比较容易的找出每个业务实体的行为（责任）和属性（辅助者）。您可能会问，为什么不直接找出属性和行为，而要多此一举呢。这个问题是我们一直在强调的。在建模阶段，我们面对的是可能对计算机技术完全不懂的涉众，所以，采用大家易于接受的方法，可以够保证需求的完整和正确。 8. 准备计划
目前在软件开发中，关于计划有两个极端的误解。
在有些软件组织中，一般不做计划，或是做一些笼统的、没什么用处的计划。一些开发人员认为，"做计划是虚的，还不如做些实际的事。"对于项目经理，或是对这种情况没有办法，或是发布的计划开发人员阳奉阴违，让计划成为一纸空文。项目执行中随意性极大，偏离方向的事情时有发生。
而在另外一些组织中，计划被视为重中之重，需要花费大量的时间、人力，做出来的计划可谓事无巨细，算无遗策。而写的出这种计划的项目经理也被视为高级人才。开发人员叹口气说，"写程序的不如写文档的。"可是在执行的时候，原来精密的计划往往漏洞百出，项目的进度一拖再拖。
我们所有人都知道那句明言：在软件开发中，要花90%的时间完成90%的项目，然后再用90%的时间完成剩下的10%的项目。为什么呢？计划不科学。
在管理学中，计划，也有叫规划的，定义是"为组织确定目标、实现目标的战略与手段、步骤、程序的过程。"打个比方说，我想要把一个箱子推倒一个地方，这个地方就是我的目的，我为了到达那里，我是不是要估计一下按什么路线推，要推多快。然后我就开始推，还要不时的和原先的计划比较比较，需不需要调整路线和速度。这个估计就是计划。
计划的目标不是消除错误，而是让所有错误变成一堆经过细心规划后的小错误。研究四种设计方式后，最终放弃三种，最多不过是三个小错误而已，但因没有做好设计而将程序重写三遍，却可能造成三个大错误。
然而为什么会出现上面提到的两个极端呢？第一种情况其实是软件行业最早期的一种形态，没有计划，资源分配混乱，软件的开发过程处于混沌、无序、自发的状态。项目的成功全凭运气和项目成员的个人能力。而第二种情况其实一个前进了的形态，最典型的代表就是我们之前提到过的瀑布模型。那这种考虑周密的计划为什么也容易失败呢？很简单，你认为你考虑周密，可是实际上却不一定。我就见过标榜自己考虑周详的计划中排出的时间表是一周7天的。看来他一开始就没打算让开发人员休息了。计划是对未来的一种估计，哪一个人能够准确的说出6个月后的情况，恐怕没人能行吧。9月11号之前，有几个人能料到那天会发生这么大的事情？那你凭什么推算出半年，甚至一年后的事情呢？另外，你是不是真的非常了解你的开发人员，以至于有信心代替他们制定计划呢？
有人说，计划没有变化快。这句话说得很对，它提醒我们，没有计划是不行的，不具备可执行性的计划也是不行的。计划不是拿来炫耀的，是要用来执行的。我们定计划的时候，可以没有华丽的词藻，美好的构想。但是我们不能没有一些要素：
什么(WHAT)：按顺序列出达到目标所需完成的工作；
何时(WHEN)：完成工作所需要的时间；
做到的程度(HOW-WELL)：要完成的工作以何标准来度量；
资源(RESOURCES)：完成工作需要的人员/资金等；
谁(WHO)：由谁负责完成任务。
但是我们仍然逃不开现实和计划的背离的问题。我们虽然对预计一年后的事情把握不大，对把握开发人员在想什么把握也不大。但是如果你自己想想自己两个星期后的事情应该还是能够猜的八九不离十吧。这就引出了迭代的概念。一个项目由几个甚至几十个的迭代周期组成，每个迭代周期都是比较容易估算并制定计划的。这就是迭代的思想，也是软件工程技术的一个大飞跃。说到这里，我又要吊大家的胃口了。关于具体制定迭代计划的讨论，我们会留到下一章节讨论细节需求建模的时候再谈。
9. 培训
我很难想象一个项目没有培训该如何进行。兵书有云，"三军未动，粮草先行。"我们可以理解为事先做好充分的准备。项目也是一样，在一开始就要指定好培训的计划，留出培训的时间。我想，除非是一个非常完美的团队，否则他的成员一定也还是有不懂的东西吧，如果没有培训计划，把学习的任务推倒个人头上，项目的风险就会变得难以控制。 说起培训，大家可能就会认为是大家正儿八经的坐在那里，听一位老师上课。并不是这样的，这里说的培训是一个广义范围的培训，达到一组课程、一次会议，小到一次讨论、一次交流，都可以是培训。而其目的，就是为了让团队成员拥有足够的知识和技能，来完成项目。
文章来源于领测软件测试网 https://www.ltesting.net/
