用例文档是一种需求文档还是详细设计文档？(附例)，谢谢!

[stillfire]

举个例子先：
用例“工艺变更”

1．工艺管理员选择需要变更的工艺流程
1.a 系统显示已审核工艺流程列表
2．工艺管理员要求变更工艺流程
2.a 系统审核查看零件工艺流程的状态。
2.b.系统显示用户选择需要更改的类型：零件工艺顺序、零件工艺文件资料、加工其他辅助信息。
3．工艺管理员选择更改工艺顺序
3.a系统显示工艺流程更改界面
4．工艺管理员调整工艺流程的顺序
4.a系统创建新的工艺流程顺序
4.b系统自动生成新的零件工艺流程版本号


1 2 3 4 表示用户操作，a,b,c表示该操作引起的系统响应。

我觉得这样一个用例变成了详细设计了，和用例文档是一种需求文档的说法不相一致。
并且，我有个奇怪的认识，
OO可能就是这种，从下而上的分析方法，然后在这个基础上建立类之间的内聚，实现组建的可扩展
大家指点以下我， 谢谢！ :)

[showerXP]

可能是我的思维有些跳跃得出了“什么过度设计、超前设计、进度慢等等问题不是用例本身的问题”这么一句话。
用例是用来描述功能性需求。
需求分析是设计的前的质量。很多人不断的做需求分析以期得到一个好的设计。而事实却往往不如愿。所以将原因转嫁到对项目而言经常是一纸空文的“用例”身上。

[hmf3000]

用例应该是用来描述系统功能的，所以属于需求文档！！！

[go_fan]

说极端一点，需求分析和设计之间的鸿沟并没有在用户、系分人员、开发人员真正融合。因为从问题域到计算机空间并不能完全匹配，等价印射。不同层次、业务类型的人员以自己的视角切入，带着自己的需求想法去审视理解一个系统，实际上是“盲人摸象”的状态。也许只有GOD能够从全局看到系统的全貌，同时又能如庖丁解牛，深刻洞察其七筋八脉。而且这其间的每一环犹如链条一样，缺一不可，不能“短板”，否则系统将从其最薄弱的环节崩溃。从“神六”上天可见大系统的复杂性。因此UML和用例对软件工程来说依旧是“没有银弹”。
所以微软并没有过分依赖UML，它用的是MSF. RUP是ROSE（被IBM收购）宣传的。我们不能迷信。还是邓老那句话：不管黑猫白猫，抓得到耗子的就是好猫。形式为手段服务，殊途同归。不要犯买椟还珠的错误。

扯远了些，有感而发。还是多谈技术，少谈主义：）

注：微软解决方案框架MSF(MicrosoftSolutionFramework)是微软公司，以及微软的产品开发者、IT组织、咨询专家、客户和全球范围合作伙伴的软件开发的经验的总结。MSF的3个基础模型：风险管理模型、小组模型及过程模型。MSF的4种软件开发范型；企业体系结构原理、应用开发原理、构件设计原理及基础设施部署原理。

[yqydaful]

go_fan(木野狐)说的好

[wangyangcheng]

Learning...

[ZeusStar]

阅。

[jordanxubin]

用例描述的是需求这点是肯定的，不过描述需求有很多种，比如数据流图，不过它们之间是有区别的，数据流图其实就是功能图。
而所谓用例，就是一种用户正确对系统的一次有意义的使用，而不是系统的业务流程（这就是功能），用例是分用户的，描述的是每种用户怎样来使用系统。
楼主举的例子，我觉的就只有一个用例在里面就是给管理员使用的工艺变更，因为其它的每个小项都是为了工艺变更而存在，如果单独存在对管理员是每有任何意义的。

[zhangmike]

用例分析属于需求。
楼主的例子是典型的需求。

[zhangmike]

在OO中，详细设计中典型应当有类，类的方法名称，参数和返回类型。
楼主所提供的例子显然没有以上特征。

[rainlight]

用例着重在需求上面

[heqinchen]

唉,都是高人啊!!Learning................

[lizi02]

唉..
学习...

[yuyifriends]

今天刚作完以用例为中心的需求分析报告，算来是第三种方式写需求报告了，觉得以用例为中心的需求分析报告是最好用的。
按照《3P》的思想，源代码就是设计，这样是否可以推出根本就没必要把需求和系统设计区分很清楚？系统设计的过程某种程度上就是需求细化的过程。
个人的体会，用例最大的作用在于分清用户要干的每件事情，然后是细化到测试人员需要的层次－－－开发人员喜欢看的很少，也需要给他们留出足够的供他们发挥的空间。

[sucan]

学习...

[nirvana_li]

用例文档是需求文档，而且主要还是功能性需求文档。用例描述，用例图，补充规约，术语表……都是用来进行需求工程的手段，主要是为满足涉众的利益，产生有价值的结果。

而且OO思想和用例并没有一定的关系，采用用例的方式只是一种需求手段。和XP里面的Story一样，都是需求手段。

它绝对不同于详细设计。详细设计的时候面向的是系统，而不是涉众。详细设计考虑的除了功能性需求之外，还更多的会考虑非功能性需求。即，RUP中的FURPS＋模型。

[zhangcf76]

我不太赞成用例文档是需求文档。简单的从“阅读对象”的角度来谈：

1、软件工程的第一个里程碑是“软件项目规划得到认可”，它产生的文档是《需求规格说明书》。而《需求规格说明书》的阅读对象是用户，用户是看不懂用例图的， 用户能看懂的是业务流程图，能看懂系统要显示哪些表单等等，而用例图是给我们软件人员看的。

2、软件工程的第二个里程碑是“完成产品设计”，它产生的文档包括《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》。由于《需求规格说明书》是用自然语言描述的，所以对于系统设计师一方面要精通业务，至少理解用户的业务，另一方面还要精通如何将业务模型转化成设计模型。这时对于我国一般的软件企业，都会有一个中间文档，我把它称作《详细的需求规格说明书》，它是面向软件人员的一种需求规格说明书，在这里会用到用例图。

可能会有朋友说，我们公司没有什么《详细的需求规格说明书》啊，但是请想想，我们通常写的《需求规格说明书》是不是都带有很浓厚的“设计”思想？是不是恨不得在做需求的时候就把设计怎么实现都写出来了？用户是往往看不懂的。——为什么会这样？因为我们把给用户看的《需求规格说明书》，写成了面向软件人员的《详细的需求规格说明书》了。

3、在概要设计时要用到用例图，因为概要设计是个承前启后的过程，它要兼顾需求，又要兼顾详细设计。它的阅读对象是软件人员。

[nirvana_li]

楼上混淆一个概念《需求规格说明书》和 《 用例文档》 是不同的。

《需求规格说明书》是关于需求的概况，而
《用例文档》 是需求的具体细节及过程。

[zhangcf76]

singlepine(小山)所说的“用例是业务需求，是程序开发的一个依据，它主要描述业务的流程”，感觉此言不妥，

业务的流程是跨包描述的，用例图是对包内部的描述。

[raze911]

我个人的理解:

用例文档是用户可以看懂的

用例文档直接描述了用户与系统的交互过程

比如ATM机例

用例文档会展示以下事件流：

用户->选择查询帐户余额->系统读取余额->系统显示余额

至于用什么样的技术手段来读取余额及显示余额,就不用在用例中描述了

而如果需要在当余额为透支状态时显示警告信息,则可以在用例文档中写入"非正常事件流"

所以,用例文档在某个程度上可以做为客户级的评测文档(比较粗糙级别的评测文档),来视查客户所要求具备的系统功能是否具备,及所实现的用户交互过程是否符合用例描述

用例描述通常应该由需求分析员与客户共同讨论而得,这样客户在软件设计过程的一开始,就可以了解未来与软件的交互过程,客户有可能会提出比较详细的自己设想的交互过程,而系统分析员根据客户的描述结合自己的经验提出改进建议并把最终讨论结果以标准文档模式记录下来

之后,在用例文档(或用例图)的基础上由系统分析员分析出业务实体类,之后进行类的抽象,画类关系图

另外说一点,我觉得系统分析员的概念是否应该分两个层次,一个层次是需求分析级系统分析员,就是分析客户需求,分析到业务实体类及类关系图这一层的；另一个层次则是在需求系统分析员所作工作的基础上考虑整个软件架构的稳定性\可扩展性\软件执行的性能等方面的软件实现级系统分析员

[cms2140]

学习中^^^^