以前做需求分析使用功能点描述的方式。比如一个账户开户功能，
相关的功能点有：开户，查询，修改，删除，注销
而用例技术中好像不提倡这种增删改查的说明方法，主张以业务活动
作为用例，而不是把开户，查询，修改，删除，注销都作为一个用例。
这样分析就只有一个“账户开户”用例，我在一个项目中这么做，但感觉
总是把问题描述不清楚，后面做设计时，也有人抱怨不如以前清晰。
谁能给指点一下？
------解决方案--------------------------------------------------------
从客户会谈纪要中寻找功能点
再把功能点描述出来
如果一个用例能够说清楚也没问题
只是用例描述看起来要多些
如果系统比较复杂的话，分开也应该问题不大吧，我觉得原则还是把问题描述清楚
------解决方案--------------------------------------------------------
为什么不把开户，查询，修改，删除，注销分别作为用例呢？
事实上，开户和销户本就是不同的业务活动
------解决方案--------------------------------------------------------
查询，修改，删除同样也是不同的用例
实际的业务活动确定了业务用例，我们也可以把一些衍生出来的功能作为系统用例。
------解决方案--------------------------------------------------------
不要脱离了业务对职责进行拆分，先把职责划分到领域实体中，然后再进行局部设计，进行必要的拆分和抽象
------解决方案--------------------------------------------------------
看需要而定。如果把增删改都作为用例容易造成用例膨胀。
但是如果相关的需求较为复杂，则可以形成单独用例。
------解决方案--------------------------------------------------------
要确定用例，首先要确定系统主角(Actor)，然后看每个Actor在实际业务中都执行哪些任务。一个用例必须能够为用户提供某种可观测到的价值，所以用例应当是具有一定粒度的，太小的粒度可呢能不能帮助用户完成他需要的任务，因此也就谈不上为用户提供价值了。
楼主所说增删查改这些操作，其实是对用例进行分析的结果，在分析模型中表达更合适一些。用例是从用户的角度来描述系统功能的，是可以给用户看的，而增删查改则主要应当作为技术人员的参考。
------解决方案--------------------------------------------------------
不要混淆增删改查类方法和业务，描述业务的时候要忘记增删改查，完全站在用户操作的角度去想，比如你列出来的“开户，查询，修改，删除，注销 ”就混淆了，你要考虑用户的操作有哪些，而不是数据库或者后台程序怎么操作。
举例说明，酒店中经常遇到的问题：换房，用增删改查去考虑，就是将入住记录中原来的房号修改成新的房号，这种描述是不对的，你要用软件使用人员也就是酒店前台服务人员的角度去描述：将顾客原房间进行退房操作，并入住新的房间。
------解决方案--------------------------------------------------------
按照楼主的描述，其实无法有任何定论。原因是大多数人都会很自然地怀疑楼主的需求分析做的过于浅尝辄止。可以参见帖子《面向对象设计原则的“单一职责”如何理解？》中我在8楼的回复，例如当你发现“删除”分好二种（或者多种）分支情况下的不同结果时，你实际上就应该废弃这个“删除”用例而给出更加具体实用的二个（或者多个）新的用例来了。
------解决方案--------------------------------------------------------
《面向对象设计原则的“单一职责”如何理解？ 》
------解决方案--------------------------------------------------------
其实说出你的用例不够明确这并不重要，重要地是我在那个帖子中回复时所解释的原理，知其然还要知其所以然才是最有用的。