Requirement Analysis with use case---continue

王朝other·作者佚名  2006-01-31
窄屏简体版  字體: |||超大  

完整的需求集合包括:inputs,outputs, functions, attributes of the system(reliability,maintainability,availability, and throughput), the attributes of the system environment.

需求应该排除项目相关信息,包括:进度,项目计划,预算,测试及涉及信息。

设计约束:对系统设计或开发系统的过程的约束

三种需求:

Functional:功能性(输入,输出,提供给用户的功能)

Nonfunctional:非功能性(Usability,Reliability,Performance,Supportability)

Design constraints:设计约束(对系统的设计或开发过程的约束,不影响系统的外部行为,但是必须被完成以满足技术、业务、合同中得要求)

细化用例

用例模型要经常被审查,并经常被重构。

好的详尽的用例:定义了所有可选择的流程,前置和后置条件,特殊的需求

增加的用例关系:include,extend,有利于维护用例模型

开发补充规格说明

用例:主要反映对用户或外部设备可见的行为

哪些需求需要给出补充规格说明:

(1) 功能性需求

a 注重算法和计算性的系统

b 很多应用均是幕后工作

c 解析输入句子,语言翻译系统

(2) 非功能性需求

Usability: (1)Specify the required training time for a user to become minimally productive or operationally productive

(2)指明完成典型的人户或交易所需要的时间

(3)将本系统与用户已知系统的适用性对比

(4)指明在线帮助系统,上下文相关帮助,用户手册等是否存在及特性

(5)遵循人机界面的约定

Reliability:(1)availability(2)平均故障时间(3)平均修复时间(4)准确性(5)最大错误或缺陷率(6)Bugs per type入:critical, minor,significant,注意以上都要定义什么是availability等

Performance:

(1) 事务的相应时间:最大,平均

(2) 吞吐量:每秒的平均事务数

(3) Capacity:系统能容纳的客户或者事务数目

(4) Degradation modes:系统degrade后,可以接受的操作模式。

(5)

Supporability:

Other:

在UML中use case通过collaboration来实现

协作:用虚线画的椭圆来表示。协作出现在设计模型中。

协作有两个aspects:

结构方面:描述了系统的静态结构(类,元素、接口、子系统)

行为方面:指定了系统为达到某个结果各个元素之间如何交互,描述了动态行为。

模型既可以用来描述用例定义的功能性需求,也可以描述非功能型需求。

从用例到测试用例:

用例技术可以直接用来驱动测试过程。

从用例得到测试用例:

1, 确定use-case scenarios.(一个use case会产生若干个senario)

2, 对每个场景,确定一个或多个测试用例

3, 对每个测试用例,确定让他执行的条件

4, 通过添加数据来完成test case

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航