1,268
社区成员
发帖
与我相关
我的任务
分享用例文档该怎么写
我写用例文档的时候，出现一些问题
比如路径要写的是业务流程，还是系统流程；我感觉应该是要写业务流程（因为目的是得到用户的需求）但我看到一个文章，说是主语只能是系统或执行者（我的理解就是系统流程）
希望大家给点意见
比如路径要写的是业务流程，还是系统流程；我感觉应该是要写业务流程（因为目的是得到用户的需求）但我看到一个文章，说是主语只能是系统或执行者（我的理解就是系统流程）
希望大家给点意见
...全文
请发表友善的回复…
发表回复
shahuqiu 2006-05-24
- 打赏
- 举报
建模实例：http://www.csdn.net/download/px/distributeDoc.rar
部分内容可参考。
这是全程建模2006年第1次培训时候的部分资料，不知是否可用？
另，第二次全面的培训在山东 青岛举行，欢迎有兴趣的朋友参加、提出建议。
QQ群：23799667 (全程建模)
部分内容可参考。
这是全程建模2006年第1次培训时候的部分资料，不知是否可用？
另，第二次全面的培训在山东 青岛举行，欢迎有兴趣的朋友参加、提出建议。
QQ群：23799667 (全程建模)
Changefish 2006-05-24
- 打赏
- 举报
建议阅读书籍 <用例分析技术>
lisir010 2006-04-19
- 打赏
- 举报
呵呵，mengxianbao1521(彪汉的人生，不需要解释！) ( )的话，让咱又学习了点东西！
测试用例由什么角度写，喔感觉应该从系统角度！
因为再现实中，测试用例的更大作用是指导测试过程，
理论上好的测试用例：让你一个没有接触过这个系统的人，看测试用例就可以测试好系统！
当然，如果从系统的角度写测试用例，可能就无法详细的覆盖客户的需求！
但是，喔感觉，测试更主要的是，验证功能的正确性，具体到需求的实现方式对不对，那不应该由测试人员决定！
测试用例由什么角度写，喔感觉应该从系统角度！
因为再现实中，测试用例的更大作用是指导测试过程，
理论上好的测试用例：让你一个没有接触过这个系统的人，看测试用例就可以测试好系统！
当然，如果从系统的角度写测试用例，可能就无法详细的覆盖客户的需求！
但是，喔感觉，测试更主要的是，验证功能的正确性，具体到需求的实现方式对不对，那不应该由测试人员决定！
yuyifriends 2006-04-12
- 打赏
- 举报
毫无疑问，用例应该写成用户角度的系统分析，而不是系统角度的系统分析。理由只有一个：写用例的目的是确定系统能为用户提供的服务，满足用户的功能需求。
我觉得LZ需要可能有两方面没想清楚：（1）用例的对象不是真正的用户，而是从用户中抽象出来的他们在系统中所扮演的角色（也可以叫用户角色）。（2）以我的理解，根本就没有系统流程，有的只是在实现用户业务流程中用户角色与系统的交互。在交互的过程中当然主语可以是用户可以是系统。例如：
(1) A用户登陆系统并请求准备新报表
(2) 系统显示县的新报表界面
(3) A用户填写和更正报表统计项并存档报表
我觉得LZ需要可能有两方面没想清楚：（1）用例的对象不是真正的用户，而是从用户中抽象出来的他们在系统中所扮演的角色（也可以叫用户角色）。（2）以我的理解，根本就没有系统流程，有的只是在实现用户业务流程中用户角色与系统的交互。在交互的过程中当然主语可以是用户可以是系统。例如：
(1) A用户登陆系统并请求准备新报表
(2) 系统显示县的新报表界面
(3) A用户填写和更正报表统计项并存档报表
wxrwan 2006-04-11
- 打赏
- 举报
学习
boydream 2006-03-27
- 打赏
- 举报
study~~~
以专业开发人员为伍 2006-03-25
- 打赏
- 举报
时序（顺序）图，也是从领域的角度去理解的，主要是描述假想的用户所看到的主要的各子系统的交互机制，比逻辑设计尚且粗略得多（大概只有其五分之一），根本不可能理解为“流程设计”。
有人说，“用例和时序图设计好之后就可以编写程序了”，这简直没有软件工程的存在的必要了。
有人说，“用例和时序图设计好之后就可以编写程序了”，这简直没有软件工程的存在的必要了。
以专业开发人员为伍 2006-03-25
- 打赏
- 举报
用例分析往往与逻辑设计交叉进行，这是正常的。但是要注意分清楚。
以专业开发人员为伍 2006-03-25
- 打赏
- 举报
用例文档应该表达系统的需求，和初始条件。当然要假设每一种主要场景、主要人员。
写系统角度的文档，那是逻辑设计。即使是在逻辑设计阶段，也不是写流程。如果你看到些流程的风格，可以说此人一定难以搞复杂的业务系统。逻辑设计的时候，对于每一种“第一时间意识到”的操作，经过分析，都可以找出好几种甚至十几种“异常”流程来（！），这些在异常不是从编程语言的异常，而是设计人员避免“设计不周”的结果，正是逻辑设计的要点。
写系统角度的文档，那是逻辑设计。即使是在逻辑设计阶段，也不是写流程。如果你看到些流程的风格，可以说此人一定难以搞复杂的业务系统。逻辑设计的时候，对于每一种“第一时间意识到”的操作，经过分析，都可以找出好几种甚至十几种“异常”流程来（！），这些在异常不是从编程语言的异常，而是设计人员避免“设计不周”的结果，正是逻辑设计的要点。
mengxianbao1521 2006-03-25
- 打赏
- 举报
楼主的概念不清晰。
在RUP中有明确的规定，用例分两种，在业务建模阶段叫业务用例，在需求分析阶段叫系统用例。系统用例是由业务用例转化成的，标准来将一个业务用例可以对应一个或多个系统用例。
在RUP中有明确的规定，用例分两种，在业务建模阶段叫业务用例，在需求分析阶段叫系统用例。系统用例是由业务用例转化成的，标准来将一个业务用例可以对应一个或多个系统用例。
yanfeng 2006-03-22
- 打赏
- 举报
用例应该就是从用户的观点对系统行为的一个描述
用UML中的用例图不就可以非常直观的描述了吗？
用UML中的用例图不就可以非常直观的描述了吗？
pinxue 2006-03-22
- 打赏
- 举报
建议买一本〈软件需求〉看看。粗略的说，Use Case就是描述外部的用户打算告诉系统点啥然后期望系统告诉他点啥或者为他做点啥。把这个描述清楚就可以了，不必执着于业务/系统啥的，等你多写几回自然就有感觉了。
liushui1981 2006-03-17
- 打赏
- 举报
顶
chinank 2006-03-07
- 打赏
- 举报
学习，
cuiyue4420 2006-03-07
- 打赏
- 举报
客户和外部系统都是你的User
showerXP 2006-03-05
- 打赏
- 举报
用例的定义就是从用户的角度出发，经过一系列交互，系统给用户一个有价值的结果。
业务流程最根本的是反映现实事物模型中业务处理的过程。
业务流程最根本的是反映现实事物模型中业务处理的过程。
wjjabc 2006-03-02
- 打赏
- 举报
我现在不清楚的是步骤该写成用户角度的系统分析，还是系统角度的系统分析？
jiezhi 2006-03-02
- 打赏
- 举报
一般是写Basic Flow和分支Flow,把问题描述清楚,将用户的一个需求由一句话展开,考虑到多种情况,逐渐丰富充实,得到一个合理的用例说明文档.
文档中当然要说明Actor,还有它做的事情和软件系统做的事情.
文档中当然要说明Actor,还有它做的事情和软件系统做的事情.
