需求开发指南.doc

需求开发指南
公司
拟制:
文档编号:XXX_需求开发指南
审核:
批准:
版本号:
生效日期:
机密等级:内部公开

修改记录
修订号
作者
日期
简要说明
目录
1 简介 4
目的 4
适用范围 4
术语表 4
2 确定系统边界 4
目的 4
确定执行者 4
确定用例 5
描述执行者和用例 5
处理时间 6
潜在的边界问题 6
确定项目范围 6
边界和范围的图形化 7
3 编写基本用例 8
基本用例 8
进入与退出标准 9
事件流 9
基本用例的评审 9
表示形式 10
其他需求 11
基本路径 11
可选路径 11
文档化可选项 12
场景 15
关联用例和执行者 16
4 高级用例 16
包含 16
扩展 17
继承 17
接口 18
5 图形化用例 19
活动图 19
时序图 21
6 图解用户界面 21
7 常见错误 22
简介
目的
介绍需求开发中用到的方法,供项目组在需求开发中学习使用。
适用范围
适用于公司软件开发人员、需求开发工程师。
术语表
请参见《CMMI术语表》。
确定系统边界
目的
将项目的参与者定位到一个共同的和明确的方向上。
确定系统中有什么(必须为创建他们投入大量精力),系统外有什么(不需要创建,但是必须考虑与它们的接口)。
估计项目规模,定义要创建系统的哪些部分(在一定时间段和一定预算的基础上)。
确定执行者
我们将采用用例分析技术,通过确定执行者和用例来确定系统边界。在一些参考资料中,我们会经常看到“外部实体”这个术语,我们认为外部实体和执行者具有同样的含义。
执行者是同系统交互的事物,包括人、其它软件、硬件设备、数据存储或者网络。每个执行者定义一种特定的角色,每个系统之外的实体可以用一个或多个执行者来代表。执行者总是在系统之外,不是系统的一部分。提出下列问题会帮助分析员确定执行者:
谁使用这个系统?
谁安装这个系统?
谁启动系统?
谁维护系统?
谁关闭系统?
哪些其它的系统使用这个系统?
谁从这个系统获取信息?
谁为这个系统提供信息?
是否有事情自动在预计的时间发生?
确定用例
用例是系统的一种行为,它为执行者产生一种可以估量的价值结果,它描述执行者想要系统完成的事情。从执行者的角度看,用例应该是一个完整的任务,一个用例行为经常是在一个相对较短的时间段内完成。如果用例的各部分被分在不同的时间段,尤其是被不同的执行者执行时,最好还是将各部分作为单独的用例对待。用例通常由执行者启动,所以我们可以从执行者角度出发,判断有哪些用例。考虑以下问题:
执行者希望系统提供什么样的功能?
系统存储信息吗?执行者将要创建、读取、更新或删除什么信息?
系统是否需要把自身内部状态的变化通知给执行者?
系统必须知道哪些外部的事件?执行者将怎样通知系统这些事件?
怎样修复系统?是否需要把系统关闭或者在系统运行的情况下进行系统维护?
描述执行者和用例
用一个名字和简单的话描述每个执行者和用例。建议采用“执行者列表”和“用例表”分别描述执行者和用例。
表1 执行者列表
执行者名称
执行者描述
客户代表
ABC公司处理客户请求的雇员
客户
从ABC公司订购商品的人
表2 用例表
用例
触发器
来源
动作
响应
目的地
客户发送订单
新订单
客户
生成新订单
实时连接
信用卡部门
订单确认
客户
订单细节
发货部门
交易处理
银行
用例:引起系统去执行某种操作的事情;
触发器:系统如何知道这个用例发生了?或者是进入系统的数据,或者是定义好的时间点。
来源:执行者;
动作:当用例发生时,系统做了什么操作?
响应:系统产生了什么样的输出结果(如果有的话)?
目的地:哪个执行者获得了产生的输出结果?
首先,对每个用例来说,系统怎么知道某一事件发生了呢?用来通知系统某一事件发生了的事物称为触发器。对于一个外部事件,触发器就是系统必须处理的数据到达了。对于临时事件,触发器是某一个时间点。
其次,当用例发生时,系统该做些什么呢?系统对用例的响应称为动作。
最后,动作导致系统产生什么响应呢?响应是系统的输出结果。一个动作通常会有多个响应。目的地就是系统发送响应的地方,也就是执行者。注意,有些时候不需要系统响应。
处理时间
在用例中主要用两种方法来处理时间。一个方法