如何写需求用例

    今天把项目的第二部分的需求用例提交给了客户,从公司CTO前辈的口中得知客户还是较满意的[UC]如何写需求用例 - Petery - Peters Blog!,这周的任务也算圆满完成了。这几天病得越来越厉害了,看来我得在开发任务下来前好好休息休息了。今天我就先把我对分析和书写需求文档进行一个简短得总结。

    在写需求用例的之前,一定要对所涉及的业务流程有一个比较完整认知,最好先和客户进行一次交流。
    现在就可以写需求用例了。主要分为一下几个步骤:

    1)描述涉及的角色(Roles)
       在系统中会与系统惊醒交互的角色都有哪些

角色名称

管理员

详细描述

管理技术支持人员信息和主题的人;

一般是总公司的技术支持部门经理来担任。

状态

内部用户

关系

继承性

子类

父类

关联到用例

UC_001-009

       那就算是一个模板吧

    2)设计基本用例图(UML-Usecase)
       该图应涵盖承接项目中的完整的业务用例,粒度要适中,每个用例能说明业务中一个主要步骤就好。不要过细,也不要过粗!(这个尺度的把握比较难,主要是看用例是否能表述清楚一个业务中的问题)
       对于基本用例图,主要是为了建立一个全局的视图,角色和用例之间的关系。对于中等规模的项目,我建议要分出不用的业务模块,并且把业务模块用不同的“包”来表示,这样可以大大降低用例图的视觉复杂性。

    3)书写用例描述
       对不同业务模块中的用例分别书写具体的用例描述
      


 

UC_002

修改主题

所属域

主题管理

涉及角色

管理员

用例概述

管理员对主题进行添加

前置条件

1.       使用者必须是“管理员”角色

后置条件

1.       主题信息变更

基本路径

1.       管理员登陆系统

2.       进入主题管理功能区

3.       选择要修改的主题

4.       修改主题名称和描述并可以重新指定主题的父级主题

5.       确认并完成修改主题

异常路径

被包含的用例

被扩展的用例


这是一个用例描述的例子,可以作为模板来使用

      4)为复杂用例设计交互图/活动图(UML- Activity)
          主要是根据用例描述中的“路径”信息来设计活动图,所以只要为比较复杂的用例设计就可以了。这样可以更直观的理解用例描述中的路径流程。

       5)为主要业务对象设计状态图(UML- Statechart)
          主要是用来说明业务对象的有哪些状态,并且在什么情况下有状态的迁移。

主要就是这些,剩下的就是Doc文档的编排和设计了,同样很重要的!

以上的内容供大家参考,希望都能写出好的需求用例文档!
同时推荐大家一个设计UML的好工具:JUDE (http://jude.change-vision.com/)  开源

转载:http://yk1001.blog.163.com/blog/static/1824769200710263024474/

  • 1
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值