如何编写用例文档Word文件下载.docx

如何编写用例文档Word文件下载.docx

《如何编写用例文档Word文件下载.docx》由会员分享，可在线阅读，更多相关《如何编写用例文档Word文件下载.docx（11页珍藏版）》请在冰点文库上搜索。

必须同用户手册中的材料密切相关，每个用户和用户指南的各部分之间的关系必须是显而易见的。

从

手册出发的原因就是要求开发人员“必须从用户角度来分析和设计系统”。

因为手册内容一般都非常

庞大（相关模版在网上获取），动不动就几十甚至几百页。

而从中归纳出文档所需要的内容必定也是非

常繁琐的，但这一步又非常必要。

因为篇幅所限，又因为担心大家偏离本文的思想，所以这里也只有

跳过了，大家完全可以在网上找到相关的信息来填充这一空白。

另外识别用例也可以采用提问方式，

如每个参与者的任务？

系统需要何种输入输出？

等（详见“系统分析师设计指南之统一建模语言”）。

在有些书中会使用合并需求（主要是功能性需求，非功能性需求可附加到用例描述中）来获得用

例，而进行合并操作的原则也就是生成“可见结果”的过程（这一步因为所做的事情过于繁杂，本文

就不再涉略了），并完成用例命名和绘制用例图。

从我个人来看，这两者（ICONIX方法和其它方法）

是相辅相成，并无冲突。

限于篇幅直接将初步确信并整理出来的用例列出来[采纳动词（短语）-名词（短语）形式]：

注册用户（UC01）,登陆系统（UC02）,发表文章（UC03）,编辑文章（UC04）,删除文章（UC05）,

浏览评论（UC07）,删除评论（UC08）,浏览留言（UC09）,删除留言（UC10）,添加链接（UC11）,

编辑链接（UC12）,删除链接（UC13）,上传文件（UC14）,删除文件（UC15）,管理文件类型（UC16）,

编辑签名（UC17）,编辑个人信息（UC18）,编辑BLOG基本信息（UC19）,（管理员）审核用户（UC20）,

创建俱乐部[或群]（UC21）等。

（管理员的基它功能操作这里只作为次要需求被过滤掉了，希望大家能够理解。

从而

将注意力放在ICONIX方法和用例的设计分析上为宜）

而相关的Blog系统用例图如下（为下面的用例文档细化作准备）:

其实要指出一个笔者以前犯过的小错误，相信也是很多朋友不知不觉也会犯的错误，确实是如何布置

用例的层次。

ICONIX方法建议使用包来展现这种层次结构，举个例子就是管理文章（里面include几个

子用例如添加，编辑，删除文章等），ICONIX会用一个包来包含这几个用例，并写上包的名称，然后再

在包中绘出相应的子图。

这样做的原因主要是：

为开发小组之间分配工作提供了逻辑边界，一条可遵循的规则是每个包对应于用户手册的一间或者

至少一大节。

我这里直接用一个大范围用例图的做法主要是为了方便说明整个系统的全貌，使大家对系

统用例有一个整体认识而已。

希望大家在实际工作中（用例数量很大的情况下）要进行权衡。

另外有三种"

用例关系"

的定义需要在这里简短介绍一下：

include（包括）:

指一个用例的行为包含了另外一个用例的行为，这是一种特殊的依赖关系。

也就是"

hasa"

的关

系。

见上图中的（管理文章和发表，编辑以及删除文章的关系）

generation（泛化）:

指一个用例（子用例）继承另外一个用例（父用例）的行为和含义，而该用例在继承了另外一个

用例的行为和含义的基本上，还可以增加新的行为和含义以覆盖原有用例的行为和含义。

比如

“按作者进行BLOG检索”和“按内容进行BLOG检索”与“BLOG检索之间”的关系。

这种关系

可以用"

isa"

来表示。

extend（扩展）:

类似于泛化（generation）关系,不过对扩展的用例有更多的限制。

如一个用例明显地混合了两

种或以上的不同场景，即可能发生多种事情。

而我们可以断定将这个用例分为一个主用例和一个

或多个辅用例描这可能更加清晰。

好了，有了用例之后就该细化用例文本了。

3.细化用例文本。

第一先拿用户注册开刀。

假设用户文本如下:

用例名称：

注册用户（UC01）

用例文档：

基本流程：

用户输入其姓名，密码（两次），EMAIL地址，然后点击注册按钮。

系统在确认该用户提交信息

有效之后，使用当前数据初始用户相关信息并记录到用户信息列表中。

然后系统提示用户要等待系

统管理员进行审核。

分支流程：

如果用户没有提供姓名，系统将显示一条错误信息，来告之用户输入姓名。

如果用户提供的EMAIL地址格式不正确，系统将显示一条错误信息,要求用户输入正确的EMAIL

地址。

如果用户两次输入的密码不同，系统将显示一条错误信息,提示用户两次密码要一致。

如果用户提交的用户名已在用户信息列表中存在，系统将告诉用户并建议用户使用其它的用户名。

可能大家看到之后，有些人会认为这一步过于简单了，因为在不少介绍用例的书里当讲到这块都会

长篇大论一番，并且关于如何描述用例子的基本和分支流程有些UML书籍可能会提供一些可参考的规

则如：

1.主语名称，语义要易于理解

2.要让读者明确参与者在控制还是系统在控制。

....

而作为ICONIX方法中的用例模版，它与其它的UML方法或许多大师级所推荐使用的用例模版有所

不同。

它用的是1040EZ式模版，换言之它所主要包括的是基本流程（基本事件流）和分支流程

（扩展事

件流）。

它不像复杂的模版中还要有前置，后置条件，非功能性需求，扩展点和优先级等内容。

该方法认

为那些东西不仅会分散注意力同时也会浪费宝贵的时间。

作为ICONIX它所推荐的做法是:

1.创建简结的用例模版（其中标有“大体流程”和“分支流程”）

2.提出“将发生什么”的问题，然后进行大体流程。

3.提出“然后将如何”，并非断提出如此的问题，直到你取得有关大体流程的所有细节。

4.提出“不然将如何”，是不是还有其它情形?

areyousure?

不断提出这些问题，直到记录下来大

量分支流程为止。

总之这么做不求十全十美，而是考虑用户可能执行的操作。

大家可以参考这些规则来看上面的"

注册用户"

看看是否还有什么别的启发:

）

另外需要要强调的就是用例文本基本形式:

名词-动词-名词

“同时这一过程中如果发现新的对象后，还应对（问题）域模型进行更新，来加深对以前发现对象

的理解”。

（比如我们将在下一个用例中发现新的对象）

下面说一个用例就是“管理文章”用例的三个子用例，大家在这里看到它包含三个子用例，分别是发

表，编辑和删除文章，而有关包含（include）上面已做过说明。

它自身的三个子用例是系统的主要功能。

发表文章（UC03）

大体流程：

用户在发表文章页面中输入文章题目，所属分类（自概念或系统类型），文章内容，是不是利用摘

要，是否发表（或放入草稿箱）等信息之后点击提交按钮，系统在确认该篇文章提交信息有效之后，

使用当前数据添加到文章列表中。

如果用户没有文章标题，系统将显示一条错误信息，告之用户输入文章标题。

如果用户提供文章内容，系统将显示一条错误信息,要求用户输入文章内容。

如果用户采用摘要形式发布，但却没有录入摘要内容时，系统将显示一条错误信息,要求用户输

入摘要内容。

如果用户在未完成当前文章内容时要跳转到其它页面，系统将显示一条警告信息，提示用户所编

辑的内容将会丢失。

如果用户提交的文章标题已在文章列表中存在，系统将告诉用户并建议用户使用其它的标题。

编辑文章（UC04）

用户在编辑文章页面中修改文章标题，所属分类（自定义或系统类型），文章内容，是否使用摘

使用当前数据修改文章列表中的相应文章信息。

如果用户没有输入文章内容，系统将显示一条错误信息,告之用户输入文章内容。

如果用户采用摘要形式发布，但却没有录入摘要内容时，系统将显示一条错误信息,

要求用户输

删除文章（UC05）

用户在文章列表页面上点击相应文章标题左侧的"

删除"

按钮后，系统提示用户是否删除该标题的

文章，当用户确认后则删除文章列表中的相应文章内容信息。

如果用户在提示框中点击"

取消删除"

按钮，则系统将不会进行任何操作并将页面重定向到文章列

表页。

在上面三个用例文本中都提到了一个新的对象就是文章列表，而这个对象是我在上一篇文章中提到但

没加入到域模型中，而这里因为从需求中得到了系统确定需要这个对象，所以需要更新一下相应的域模型

了:

下面要说的一个用例就是"

管理文件类型"

。

在聊这个用例之前有些问题需要先解释一下，就是这个用例本身是否需要分解为三个子用例（添加，

编辑，删除）会更为合适?

可是若是如此做的话，就会使得用例的数量多添加三个。

若是说一碰到这种情

况就去如此分解的话，可能会使用例的数目过于庞大。

这其实也是一个需要注意的问题，在许多用例驱动

的书中都肯定会不可避免的谈到这一问题，即“用例的分解粒度”，因为分解过度会显著提高复杂度，而

过低则有可能违背用例的“可见价值结果”的原则。

如果说“管理BLOG系统”这个用例就是一个太大的

用例，根本看不出什么对用户有价值结果。

而“输入用户名”这个用例又太小，把它当成一个步骤会更合

适，这个“度”上的把握最终还是要从系统（软件）的整体来衡量才是根本。

聊了这么一大堆再回到当前的"

这一用例上，在我看来，它本身可能是因为用户（文档）

比较简单所以就把三个所谓的子用例做了一下合并，变成一个用例。

当然这也是仁者见仁，智者见智，不

是完全绝对化的，还希望大家自行斟酌，多提意见:

治理文件类型（UC16）

系统管理员在"

添加文件类型"

表单中（位于"

文件类型列表"

页面）输入文件类型名称（如RAR，JPEG

等），类型描述，最大上传尺寸，上传路径名称等信息之后点击提交按钮，系统在确认该信息有效之后，

使用当前数据添加到文件类型列表中。

系统管理员在文件类型列表页面中的相关类型上点击删除按钮，系统提示是否删除该文件类型，在

管理员确认后则从文件类型列表中删除相应的记录。

系统管理员在编辑文件类型页面中修改相应类型名称，类型描述，最大上传尺寸,以及相应路径后

点击更新按钮，系统在确认该信息有效之后，使用当前数据修改类型列表中的相应文件类型信息。

如果用户在添加和编辑表单中没有输入类型名称，最大上传尺寸，上传路径名称时系统提示输入相

关信息。

若是用户提交的类型名称已在文件类型列表中存在，系统将告知治理员并建议治理员利用其它的名

称。

如果用户在提示框中点击取消删除按钮，则系统将不会进行任何操作并将页面重定向到"

管理文件类

型"

页面。