{需求}求助关于用例。

[hu]

我们公司再次遇到需求问题。我第一次有机会参与需求分析。那位达人能帮我讲解一下用例的概念，如何追踪，以及如何划分。

[Brooklyn]

On 11/23/2009 05:41 PM, hu wrote:
> 我们公司再次遇到需求问题。我第一次有机会参与需求分析。那位达人能帮我讲解一下用例的概念，如何追踪，以及如何划分。

requirements analysis?
用例是use case?
我们的software engineering 刚上完这部分，这次作业我们被老师骂了好久，因
为做得不好。
追踪是什么？ 没碰到过，只知道有sequence diagram，还有一些system
decomposition 或者 class diagram。
我对于这个也没有好的概念，看看有没有这方面的牛人来回答，另外，建议你去老
外的网站搜一搜，我感觉这种东西，国内没有很好的参考资料吧。

[lcgong]

就当写电影脚本，剧情主线是你要做的那个系统是如何解放深陷业务流程困境的员工们，最后与他们和睦共处共创新事业。将剧情分成一个个镜头，每个镜头就是一个用例。分镜头的原则，就是利于场景重复利用，利于演员当期安排，也就是利于模块复用，利于降低耦合。写剧本(用例)的一个要点：每个分镜头(用例)的句子一定按照主、谓、宾的形式写，缺一不可，主语是角色，宾语是实体，谓语是操作；不要嫌麻烦，一句一行，句句间过渡连贯，想象一下镜头是平移过去的，不可能有跳跃的镜头，如果必须另外描述一些细节，那就是另一个分镜头的事了。如何把握粗细有度，那些该写那些不该写，毕竟你是写用例的编剧可以思考在这个镜头内导演该知道什么，演员该知道什么，剧务该知道什么。写了一些用例，编辑整理将这些用例串连起来，反复思维演推，实在不行就找两个同事扮演一下，看看连贯不连贯还缺啥，一个常见的问题，想当然的认为“谁已经知道”、“什么已经存在”；同时查看那些作为宾语的实体，名称是否全称且确定，消除起义，区分哪是系统内哪是系统外，尽可能保持实体的数量，尤其是系统内，对于已经确定是系统外的，一定要向用户确认他们能不能提供愿不愿提供这些实体，此处千万不要想当然。反复几轮后，组织一下，按业务某个层次按时间排一下，用例名称重新确认一下，编个号，定稿，另一个建议是，用例修改也是新编号，可利用issue tracking.

我个人认为写用例靠的是对业务（或产品）的实质把握能力、想象力、文字写作以及逻辑，为了方便把握来龙去脉和各种关系，在技术上可以画个地图、组织结构、状态图，甚至粗造的数据流图，归根到底还是“创作”，UML那套花拳绣腿，不是买了打字机学会了打字，人人就可以写小说了。

2009/11/23 Brooklyn <yuan15...@gmail.com>