【2006-8-2916:13:01 阿兵】
请教您一下，如下这种用例应该如何表达？
2.1 添加图幅
用例场景
当××大队完成一幅新图或者一幅图的新版本时，启动此用例。
主执行者
系统管理员
基本路径
1. 用户提交图幅详细信息。
2. 系统检查当前库是否已经存在此图幅。
2a.已经存在此图幅
2a1.向当前库添加一条记录。
2a2.向历史库中添加一条记录。
2b.不存在此图幅
2b1.更新当前库中的图幅信息。
2b2.向历史库中添加一条记录。
3.系统提示操作信息。
【2006-8-2916:15:39 UMLChina 潘加宇答疑专用】
当××大队完成一幅新图或者一幅图的新版本时，启动此用例。－－－应该改为系统能感知的前置条件
2. 系统检查当前库是否已经存在此图幅。－－系统验证此图幅未存在
当前库、历史库－－是不是涉众所关心的？
为什么要这样分？涉众知道这样分的好处吗？
【2006-8-2916:17:16 阿兵】
是的，因为他必须获取这些历史信息。要记录图幅的历史信息，随时备查。
【2006-8-29 16:43:15 UMLChina 潘加宇答疑专用】
那么涉众关心的是：系统验证不存在该图幅的历史信息
【2006-8-29 16:44:27 阿兵】
需要针对当前是否存在此图幅决定是添加一条新的记录还是修改现有的记录的操作
【2006-8-29 16:46:04 UMLChina 潘加宇答疑专用】
那就直说嘛：系统判断需要添加一个新图幅还是需要修改现有图幅
当前库、历史库这只是数据库设计的手段
减轻查询的负载而已
且不说合理不合理，就说涉众无法理解和验证这一点，就不应出现
添加一条记录－－这个也是数据库的术语
【2006-8-29 16:48:16 阿兵】
那应该如何表达呢？我还是不是很清楚如何能表达这种信息，您能把这个小用例修改一下我参考吗？
【2006-8-29 16:51:46 UMLChina 潘加宇答疑专用】
前置条件
系统管理员已经登录
后置条件
系统已保存或更新图幅信息
基本路径
1. 用户提交图幅详细信息。
2. 系统验证需要添加新图幅
3. 系统添加新图幅
4. 系统反馈已添加，提示××××
2a.不需要添加新图幅
2a1.系统修改已有图幅
2a2.系统反馈已修改，提示××××
非功能需求： ××××××
【2006-8-29 16:53:50 阿兵】
如果系统验证当前添加的图幅不是新图时，需要保存以前版本的图幅信息，增加一个新的版本，这应该在用例里说明吗？
【2006-8-29 16:54:27 UMLChina 潘加宇答疑专用】
图幅分为版本，如果这是业务知识，一定要说明
关键点并不在于写什么，而在于写的时候有没有从涉众关心的是角度去写而已
【2006-8-29 16:56:49 阿兵】
但是应该在哪个部分说明呢？您有稍微现实一点的文档范例可以做参考吗？
【2006-8-29 17:01:13 UMLChina 潘加宇答疑专用】
在哪个部分说明呢－－就可以步骤里说明，如果系统验证当前添加的图幅不是新图时，需要保存以前版本的图幅信息，增加一个新的版本
就这样说不是挺好吗
您有稍微现实一点的文档范例可以做参考吗－－你先写，写完方便的话给我看，我来提些建议
【2006-8-29 17:08:58 阿兵】
比如刚才这些困惑，如果有一个现实的参考，就算不大懂，照葫芦画瓢也知道大概了
【2006-8-29 17:09:12 UMLChina 潘加宇答疑专用】
照葫芦画瓢是不行的
就象这个：如果系统验证当前添加的图幅不是新图时，需要保存以前版本的图幅信息，增加一个新的版本
不同的系统有不同的需求表示法
关键点并不在于写什么，而在于写的时候有没有从涉众关心的是角度去写而已
另外，你的用例里没有涉众利益，所以怎么写都是没有根据的
【2006-8-29 17:11:50 阿兵】
但是我们接的项目，好多需求都是客户公司信息中心的一两个人来确定需求，涉众的利益都随着双方的BOSS 走
我们得到的资料大都是二手的，根本无法深入到最终使用者
【2006-8-29 17:13:59 UMLChina 潘加宇答疑专用】
那也要想办法揣摩老大的想法，不能指望信息中心的一两个人，他们不能代表涉众。除非，系统搞砸了他们负大部分责任，那就可以依赖他们了
或者让"客户公司信息中心的一两个人"也提升需求技能，这样通过他们去接触涉众得到的信息就比较准确
你的需求不解决涉众利益问题，抄"规范样板"也是没用的；如果解决了涉众利益问题，不写具体需求文档都可以
【2006-8-29 17:16:50 阿兵】
嗯，我写完后您给指点一下:)
【2006-8-29 17:17:25 UMLChina 潘加宇答疑专用】
好，一定要加上涉众利益啊，自己揣摩也要加上去 |