如何写需求用例 | 您所在的位置:网站首页 › 学生管理系统用例图用例描述怎么写的 › 如何写需求用例 |
今天把项目的第二部分的需求用例提交给了客户,从公司CTO前辈的口中得知客户还是较满意的 角色名称 管理员 详细描述 管理技术支持人员信息和主题的人; 一般是总公司的技术支持部门经理来担任。 状态 内部用户 关系 继承性 子类 父类 关联到用例 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/ |
CopyRight 2018-2019 实验室设备网 版权所有 |