服务流程设计过程-电脑系统服务流程设计说明

1.电脑上的软件是怎么做出来的？

2.系统设计怎么写

3.用例的程序设计·用例

电脑上的软件是怎么做出来的？

软件开发流程

先上一个软件开发的整体流程图，这就是大名鼎鼎的“瀑布模型（Waterfall Model）”。据说由温斯顿·罗伊斯（Winston Royce）在1970年提出。

瀑布模型的特点为：上一阶段的结果为本阶段的输入，开发进程从一个阶段“流动”到下一个阶段。

（图中右侧括号中为每个阶段的输出物。）

一般软件售前人员对这个流程比较熟悉，这其中项目规划、可行性论证报告、需求说明书等，通常都由IT售前人员提供。

如果将瀑布模型的设计部分分为总体设计、详细设计两部分，即“软件开发的8个流程”：

1、问题定义阶段

用户提出一个软件开发需求以后，分析人员首先要明确软件的实现目标、规模及类型：如它是数据处理问题还是实时控制问题，是科学计算问题还是人工智能问题等。

2、可行性研究

基本任务：“对于上一个阶段所确定的问题有行得通的解决办法吗”？

内容包括经济可行性、技术可行性、法律可行性、不同方案。

结束标准：提出关于问题性质、工程目标和规模的问题定义书面报告；提出可行性研究报告。

3. 需求分析

基本任务：“为了解决这个问题，目标系统必须做什么？”

确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。

结束标准：软件需求规格说明书（specification)

4. 总体设计（概要设计）

基本任务：“概括地说，应如何解决这个问题?”

设计出实现目标系统的几种可能的方案。推荐一个最佳方案。

结束标准：概要设计文档

5. 详细设计

基本任务：“应该怎样具体地实现这个系统呢?”

结束标准：设计出程序的详细规格说明。

6. 编码

基本任务：写出正确的容易理解、容易维护的程序模块

结束标准：以某种程序设计语言表示的源程序清单

7. 测试（单元测试和综合测试）

基本任务：在设计测试用例的基础上检验软件的各个组成部分是否达到预定的要求。

结束标准：软件合格，能交付用户使用。

8. 软件维护

基本任务：使系统持久地满足用户的需要。

改正性维护，适应性维护，完善性维护，预防性维护。

虽然后来提出很多模型，如演化模型（evolutionary model）、增量模型（incremental model）、原型模型（prototyping model)等，但现在软件开发的流程，依然总体遵循瀑布模型。

如何搭建一个系统

说完流程，再说说系统是如何被开发人员搭建出来的。

系统的百度百科定义为：软件系统(Software Systems)是指由系统软件、支撑软件和应用软件组成的计算机软件系统，它是计算机系统中由软件组成的部分。

搭建系统可以分为三个步骤：环境部署、软件开发、软件部署。

1、环境部署

准备服务器，部署操作系统、软件环境、安全软件、FTP服务器等。数据库和应用可分开布置在多个服务器，也可布置在同一服务器。

准备网络，分为内网和外网。外网需要购买公网IP和域名。

负责人：网络管理员

2、软件开发

包括开发语言选择、架构设计、数据库设计等工作，并进行编码、编译、测试、打包。

负责人：程序员

3、软件部署

将程序文件上传到服务器，进行部署、配置，成功后即可通过客户端访问项目。

负责人：软件实施

软件开发阶段

下面以java语言开发为例，简单讲讲程序员是如何进行软件开发的。

（本部分参考了“软帝在线”公众号、博客园“架构与我”的文章）。

1、新建java文件（或工程）

java源代码本质上就是普通的文本文件，可以用txt等工具编辑java代码（程序员一般采用源代码编辑工具，如：Notepad++；或集成开发工具IDE，如：Eclipse）。txt编写后需将文件扩展名改成java。

2、编写代码

以“Hello World”举例编写代码：

public class HelloWorld {

public static void main(String[] args) {

System.out.println("Hello World");

}

}

该程序表示的意思是输出Hello World这样一段话。

3、编译程序

Java程序之所以能做到跨平台运行，是因为Java程序运行在JVM中的，然而JVM只能够识别字节码文件，而不能直接识别Java文件。所以需要先将Java文件编译成字节码文件，即class文件，然后字节码文件才能够在JVM中运行。

编译文件，可以通过手动执行Dos命令javac，或直接用编译器如Eclipse完成。

4、运行程序

可在Dos命令窗口中输入java命令，按回车，输出Hello World；

或在编译器的控制台中看到输出结果。

5、单元测试

单元测试（模块测试）是开发者对编写的一小段代码，检验一个很小的、很明确的功能是否正确。

通常采用JUnit框架（多数java开发环境已集成）进行测试，即所谓白盒测试，叫“白盒”是因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。

测试通过后，就完成了软件开发阶段，可以打包部署了。（IT售前圈）

系统设计怎么写

问题一：关于系统的总体设计谁教我一下怎么写？ 学生公寓管理系统设计与实现该学生公寓管理系统主要实现了后勤部门对学校宿舍的管理功能。系统分为管理员模块和学生模块两个部分。管理员模块实现的功能有：1) 学生信息管理功能：主要是添加系，专业，班级和学生的具体信息，来创建以班级，专业，系等为单位的学生信息。包括添加，删除和修改功能，还有学生的总体查看和个别查询功能。2) 宿舍楼信息管理功能：分为宿舍楼信息的添加删除和修改功能：添加修改功能具体实现为每栋楼的楼名，层，房间，床位的添加和修改；删除功能执行一次删除整栋楼。更多的资料详情： lw5173/article/html/2289、他们网站资料很多的，应该可以帮上你的忙~去看看对你的帮助很大

问题二：系统设计应该怎么写 仓储管理系统没做过！代码设计书我猜想是这样的，就是Id字符串中不同的位应该具有特定的含义。

比如17位的仓储Id：前三位是仓库代号；4-6 位是库房号；7-9位是货架或货区号；10-17是货物的8位条码号。

比如系统的管理人员9位工号： 1-3 位是顶级部门编码；4-6位是次级部门编码；7-9是员工编码

所谓的代码设计；就是要说明系统中使用的代码和代码不同位所代表的含义。

这个需要具体调研，根据需求来定。

问题三：系统详细设计包括哪些内容 1、模块说明。说明该模块需要实现什么功能，还有设计要点。

2、流程逻辑。用流程图说明该模块的处理过程。

3、算法。不一定有，如果涉及一些比较特殊的算法或关键模块，就写一下算法的伪代码或用流程图说明。

4、限制条件。该模块的功能有哪些限制常比如用户ID不能重复，只能查询自己权限范围内的用户。

5、输入项。每个子模块可以看做一个”方法“，我传给你什么，你给我输出什么。比如删除用户，输入项就是用户ID。

6、输出项。删除用户的输出项，就是不能在查询模块里查询到已删除的用户

7、界面设计。用visio或者其他工具画一些界面图

8、需要操作的数据表。

问题四：软件系统的详细设计文档该怎么写 按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~

详细设计文档规范

1.0概述

这部分提供对整个设计文档的概述。描述了所有数据，结构，接口和软件构件级别的设计。

1.1 目标和对象

描述软件对象的所有目标。

1.2 陈述范围

软件描述。主要输入，过程功能，输出的描述，不考虑详细细节。

1.3 软件内容

软件被置于商业或者产品线中，讨论相关的战略问题。目的是让读者能够对“宏图”有所了解。

1.4 主要系统参数

任何商务软件或者产品线都包含软件规定、设计、实现和测试的说明和规范。

2.0 数据设计

描述所有数据结构包括内部变量，全局变量和临时数据结构。

2.1 内部软件数据结构

描述软件内部的构件之间的数据传输的结构。

2.2 全局数据结构

描述主要部分的数据结构。

2.3 临时数据结构

为临时应用而生成的文件的描述。

2.4 数据库描述

作为应用程序的一部分，描述数据库结构。

3.0 结构化和构件级别设计

描述程序结构。

3.1 程序结构

详细描述应用程序所选定的程序结构。

3.1.1 结构图

图形化描述结构。

3.1.2 选择性

讨论其它可供考虑的结构。选定3.1.1中结构类型的原因。

3.2 构件描述

详细描述结构中的每个软件构件。

3.2.1 构件过程叙述(PSPEC)

描述构件的过程。

3.2.2 构件接口描述

详细描述构件的输入和输出。

3.2.3 构件执行细节

每个构件的详细演算描述。

3.2.3.1 接口描述

3.2.3.2 演算模型(e.g., PDL)

3.2.3.3 规范/限制

]3.2.3.4 本地数据结构

3.2.3.5 在3.2.3.6设计中包含的执行结果

3.3 软件接口描述

软件对外界的接口描述

3.3.1机器对外接口

与其他机器或者设备的接口描述。

3.3.2系统对外接口

对其它系统、产品和网络的接口描述。

3.3.3与人的接口

概述软件与任何人的界面。

4.0 用户界面设计

描述软件的用户界面设计。

4.1 描述用户界面

详细描述用户界面，包括屏幕显示图标、或者类型。

4.1.1 屏幕

从用户角度描述界面。

4.1.2 对象和操作

所有屏幕对象和操作的定义。

4.2 界面设计规范

用户界面的设计和实现的规范和标准。

4.3 可见构件

实现的GUI可见构件说明。

4.4 UIDS描述

用户界面开发系统描述。

5.0约束、限制和系统参数

会影响软件的规格说明、设计和实现的特殊事件。

6.0测试标准

测试策略和预备测试用例描述。

6.1 ......>>

问题五：在系统设计中怎样写系统体系结构的设计？ 20分 简单来说，就是：画图，全方位的剖析系统，设计类。其中要画出用例图，状态图，时序图，类图。下面就我做过的一个“大富翁”游戏的体系结构设计为例。

用例图：

时序图：

类图：

把用户对系统的需求划分成系统的一个个功能模块并设计好类，就可以进行开发了。

问题六：游戏系统设计文档怎么写 具体内容很多的，这个需要你自己去写和完善，别人写出来就不是你的了，再说没有谁会愿意无偿的给你写网游策划草案的，这个草案其实是一个想法的开始。具体写的话主要写游戏的种类、有哪些系统、有什么玩法、特点在哪，与其他网游的不同之处是什么，运营方式是什么，盈利点是什么为什么，还有就是世界观、故事背景等等。这些写完了差不多就一篇草案出来了！ 如果是细化到系统的策划则按一下写、相关资料2、设计目的、设计方法、设计原则3、系统概述：背景简介、玩法简介4、逻辑设计：流程图、逻辑细则、子玩法设计5、文案设计：与NPC对话的可能。6、数值设计：相关数值的列举和设计。7、修改意见： 我这是我现在公司系统文案用的一套，写的时候一定要简明扼要，流程图要规范就行了！希望能够帮助你！总的来说，我们公司的策划书分为以上几个部分，当然这个是系统策划，大策划是将每个系统策划拼合在一起！一个总策划案是由很多系统策划、文案策划、数值策划、关卡策划、执行策划组成！ 系统策划做系统设计和规则设定的；文案策划做故事情节以及任务对话剧情对话的；数值策划做的是游戏内一切数值相关的设定、关卡策划主要设计游戏中的地图、怪物、任务等，并交与美术、程序等制作，执行策划就是要将前面所说的策划案，整理成执行文档，给程序进行程序开发。

问题七：学生信息管理系统代码设计怎么写 好多语言都可以写学生信息管理系统的，这里以C语言为例，只供参考：

#include

#include

#include

using namespace std;

typedef struct student {

unsigned m_id;

string m_name;

unsigned m_age;

string m_sex;

string m_address;

string m_contact;

string m_dormitory;

struct student *m_next;

}student;

class CStudent {

private :

student *head;

public :

CStudent() {

head = new student;

head->m_id = 0;

head->m_name = noname;

head->m_next = NULL;

}

~CStudent() {

student *p = head,*q;

while(p) {

q = p;

p = q->m_next;

delete q;

}

}

student readdata(int model); model = 1:不读取学号，2:不读取姓名，其他，读取所有信息

void entering();

bool insert(const student &astu);

student *findid(unsigned id) const;

student *findname(const string &name) const;

student *findsex(const string &sex) const;

student *finddormitory(const string &dormitory) const;

unsigned boys() const;

unsigned girls() const;

unsigned headcount() const;

bool eraseid();

bool erasename();

bool modifyid();

bool modifyname();

void Show() const;

void query() const;

void friend statistics(const CStudent &aclss);

void friend erase(CStudent &aclss);

void friend modify(CStudent &aclss);

};

string readstring() {

string str;

while(cin.get() != '\n');

cin >> str;

return......>>

问题八：系统开发详细设计书功能描述输入输出处理怎么写 详细设计就是把项目里每个功能点都要完完整整列出来。 好比用户注册：在XX页面输入用户名、密码、电话、地址。 提交之后会返回什么样消息。出错会提示什么情况。 最后还要加个流程图。 而需求只需要写明大概功能点要达到什么要的目的就可以了。没这么细。

问题九：系统维护设计 怎么写 维护方案设计 1.1 信息资源维护 1.1.1 稽查案审管理系统服务内容: 稽查...检查系统各个进程所占用内存情况;剩余内存大小。

问题十：有多个子系统的详细设计文档怎么写 你好 我可以.

用例的程序设计·用例

那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。

对不同的Actor来说，他要使用系统的某项功能也不同。所以，在识别和分析Use Case时，我们要对每个Actor逐一进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

Use Case可以用很多方式来描述，我们可以用自然语言（英语，汉语，随您的便），可以用形式化语言（哇！太酷了吧！），也可以用各种图示。在UML中，通常用两种图来描述Use Case，它们就是顺序图（Sequence Diagram）和协作图（Collaboration Diagram）

Use Case 由以下元素组成：

名称

简单描述

事件流

关系

活动图和状态图

Use Case 图

特殊需求

前条件

后条件 1.1 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成： 参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。 用例(Use Case)用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 通讯关联(Communication Association)通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。 以银行自动提款机(ATM)为例，它的主要功能可以由下面的用例图来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行帐户的查询、提款和转帐交易。 通讯关联表示的是参与者和用例之间的关系，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果你不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的（用例本身描述的就是参与者和系统之间的对话），并且信息流向是双向的，它与通讯关联箭头所指的方向亳无关系。

1.2 用例的内容用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。如在ATM系统中的提款用例可以用事件流表述如下：

1. 用户插入银行卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回银行卡 但是这只描述了提款用例中最顺利的一种情况，作为一个实用的系统，我们还必须考虑可能发生的各种其他情况，如银行卡无效、输入密码错、用户帐号中的现金余额不够等，所有这些可能发生的各种情况（包括正常的和异常的）被称之为用例的场景(Scenario)，场景也被称作是用例的实例(Instance)。在用例的各种场景中，最常见的场景是用基本流(Basic Flow)来描述的，其他的场景则是用备选流(Alternative Flow)来描述。对于ATM系统中的提款用例，我们可以得到如下一些备选流：

备选流一：用户可以在基本流中的任何一步选择退出，转至基本流步骤5。

备选流二：在基本流步骤1中，用户插入无效银行卡，系统显示错误并退，用例结束。

备选流三：在基本流步骤2中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。 … 通过基本流与备选流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。我们在描述用例的事件流的时候，就是要尽可能地将所有可能的场景都描述出来，以保证需求的完备性。

1.3 用例方法的优点用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。 与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。 在RUP中，用例被作为整个软件开发流程的基础，很多类型的开发活动都把用例作为一个主要的输入工件(Artifact)，如项目管理、分析设计、测试等。根据用例来对目标系统进行测试，可以根据用例中所描述的环境和上下文来完整地测试一个系统服务，可以根据用例的各个场景(Scenario)来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。 Ivar Jacobson在1967年定义爱立信AXE系统的构架时开始书写使用场境usage scenarios。

二十世纪八十年代中期Jacobson花了很多精力来思考过去十多年的工作方法。他造了一个术语anvendningsfall，大意是“使用情况”（situation of usage）或用况（usage case）。但当用英文出版的时候，他发现“useage case”在英语里说不通，所以写作用例“use case” 用例是短文

用例可以是一个场景，包括动作和互交。

用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。

用例里不要有系统设计

用例里不要有界面设计

用例里不要有特性列表

用例里不要有测试

用例应该描述行为需求

用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。

用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。 Use Case具有一个基本事件流（可称为理想路径）、多个例外流，包括：

基本变化

特殊情况

处理错误情况的异常事件流 Use Case 说明书应包括以下内容：

功能描述

可用性

可靠性

性能

可支持性

设计约束 试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的场景不允许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。

对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。

Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。

给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。 Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。

不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。

下面是客户对Use Case“下定单”的粗略概略：

“确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用”

结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对顺序的叙述。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例：

Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。 Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：

1 Use Cases把系统当作一个黑盒

2 Use Case 使在需求中看到实现的决定变得更加容易

最后一点源于第一点的补充，一个Use Case没有指定任何这些需求相关的系统的内部结构，所以说，如果这个Use Case中陈述了提交改变到定单数据库、显示结果到Web页面等的话，那么内部结构是显而易见的，并造成对设计的潜在约束。

为什么这些需求不指定内部结构的原因是，说明的内部结构给设计者带来了额外的约束，没有这些约束设计者们能更自由地建立一个正确实现客观可见行为的系统，并存在出现突破方案的可能性。 这里是Use Cases的图形符号描述，UML中一个单一的Stick-Man符号标示角色（Actor），用椭圆标示Use Cases，如这些图对于你想看到Use Cases之间如何关联的大图和获得系统上下文的大体描述来说是非常重要的。

Use Cases图没有显示不同的场景，它们的意图是显示角色和Use Cases之间的关系。所以Use Cases图需求用结构化叙述文本来补充。UML提供一些可供选择的图来显示不同的场景，这些常规的图形有交互图、活动图、顺序图、状态图等（本文暂不讨论这些图）。使用这些图的主要缺点是它们不象文本一样是紧密的，但它们能用于给出Use Case的整体感觉。 是否每个Use Case 都包括至少一个actor？

是否每个Use Case 都独立于其他Use Case？

是否每个Use Case 都有一个简单的行为或事件流？

是否每个Use Case 都有一个唯一的、直观的、可扩展的名称，使它不至于在后期被混淆。

用户是否容易理解Use Case 的名称和描述。 Use Case模型显示系统中的Use Case与Actor 及其相互关系。其评价标准有：

Use Case 模型是可理解的吗？

通过对Use Case 模型的研究是否能对系统功能有一个清晰的概念。

所有的actor都定义了吗？所有的功能需求都满足了吗？

Use Case 模型是否存在多余的行为。

从模型到Use Case包的划分是否是恰当的。 由于具有简单的图形符号、易理解的自然语言说明书，Use Case在文档系统和软件需求领域成为一 项越来越受欢迎的技术。Use Case对开发小组极具吸引力，即使小组成员对正式的需求文档没有经验，但这些简单性却具有欺骗性，即使项目小组在开始使用Use Case 时没有任何麻烦，当他们将其应用于大项目时常常会遇到许多同样的问题。

1 使用 use case 十大误区

1． 系统的boundary 没有定义或经常改变；

2． 从系统观点而不是actor观点来定义Use Case；

3． Actor的名称不一致；

4． Use Case 定义过多；

5． Use Case 和actor之间的关系象蜘蛛网一样错综复杂；

6． Use Case的说明太长；

7． Use Case的说明不清楚；

8． Use Case没有正确的描述功能需求；

9． 用户无法理解Use Case；

10． Use Case 无法正常结束。

2 如何避免以上问题

清楚的确定系统的boundary.

简单来说，系统的boundary就像一个加了标签的盒子，actor在盒子外，而Use Case在盒子内。我们称之为系统的这个盒子究竟是什么呢？一个计算机系统？一个应用系统？或一个完整的企业？…Use Case 可以用来合理地描述任意系统。但一次只能用来描述一个系统，在一个系统中恰当定义的actor和Use Case用于另一个不同的系统中就会出现错误。

使用标准模板书写Use Case 说明书

Use Case 图形符号已经被标准化并作为对象管理小组UML的一部分，但自然语言的Use Case 说明书还没有被标准化。为了成功书写Use Case 说明书，我们需要一个标准模板来保证Use Case 的一致性。

关注actor的真正目的，从actor的观点而不是系统观点来命名Use Case

面向Use Case 的需求与传统的功能性系统需求之间最显著的区别在于actor ，以面向Use Case的观点，系统存在是由于actors 要通过该系统实现某些目标，actor与系统进行交互来实现其目标，我们将这些交互行为定义为Use Case 。

不要将Use Case 说明书与用户接口设计相混淆

现在有一种很流行的观点：由于Use Case 是actors 与系统之间的交互，所以将所有的用户接口设计图放在Use Case说明书中是一个好办法。初看时，这的确很有用，因为它将在说明书中描述的actor/系统之间的交互行为以图的形式表示出来，非常直观。但是这样做的负面影响却远远大于其好处，用户接口设计可能会随着时间而改变，我们不应该让系统需求依赖于用户接口设计，相反地，用户接口设计应该满足Use Case 需求。如果我们将用户接口设计置于Use Case 说明书中，当需求需要被认可和定为基线时，很自然地，这些设计元素可能仍然在改变，这就使得用户接口设计成为不完整的、不正确的和/或不一致的。

将用户接口设计置于Use Case 说明书还会出现另一个问题，为了在Use Case 之间和接口之间建立一对一的通信，我们会选择反映用户接口的Use Case块而不是反映用户目标的Use Case 块，这样，为了表达一个完整的用户目标，我们使用交互Use Case 关系，将不同的、基于用户接口的Use Case 联接起来，结果在Use Case 模型中，我们得到了一幅类似蜘蛛网的关系图。实际上，这副图是用户接口说明图，虽然它在系统文档中是很重要的一部分，但他属于用户接口设计文档，而不是Use Case 需求文档。

实现用户接口和Use Case 交互之间的松散耦合

松散耦合是比较合适的，低逼真度的用户接口图有助于理解Use Case ，但要注意不要过度的将基本交互与用户界面机制相连，用户界面很有可能会改变。在功能说明书中，要注意actor做些什么（如提交请求）而不是交互是怎样完成的(如双击提交按钮)。

不要在Use Case 和用户接口之间建立通信

试图在Use Case 和用户接口之间建立通信可能会存在潜在的、不正确的功能操作。Use Case 不仅与只能访问某个接口的actor相联，而且与那些能够更新该接口的actors相连（这可能是例外流），结果就造成了不正确的功能操作。我们应该在基于实际用户目标和功能操作的基础上拆分Use Case ，而不是在基于用户接口的基础上组合Use Case ，只有这样才能得到正确的Use Case 模型。

回顾Use Case 模型和Use Case 说明书，如果你不能防止所有的误区，你应该尽早认识问题并确定问题

这个观点并不是什么新东西，有关代码检查的经典算法已有大约25年历史了，但怎样将其应用于Use Case 呢？ 首先，回顾Use Case 模型，回顾一下Use Case 的简单说明（Use Case 名称、目标、简单描述）。这项工作应在绘制草图时尽早执行，并在写详细的Use Case 说明书之前完成。接着是回顾Use Case 草图，保证图是正确的，并且详细的Use Case说明书是完整的。最后是正式回顾最终的Use Case 图和Use Case 说明书。

我们发现这种三阶段式回顾比单一的宇宙大爆炸式回顾有效，在我们花大量的时间写说明书之前，Use Case图中存在的许多实质性问题可以被发现，这种方法减少了当需求改变时需要做的重复工作。 主要行为者（Actor）和Use Case之间没有连结

一些情况下，从Use Case中取值的行为者（Actor）和积极参与这个Use Case的行为者（Actor）之间没有清晰的连结。如：财务主管能成为“发票确认”的行为者（Actor），但他未必是创建发票的人。这不是什么问题，这个Use Case仍然是正确的，它正说明行为者取值和设计的系统的范围外的Use Case发生的初始化之间的关系。主要行为者是有用的，因为这个人扮演的角色是当你说明Use Case时需要跟他说的人。

情节步骤不需要连续

情节中步骤顺序的情况是没问题的，这里有一些机制去突出可能的并行步骤。在UML中活动图是首选的机制，通过非正式地看Use Case的情节你可以注意到可能的平行步骤；可以看Use Case内一些邻近的步骤；也可以有相同的行为者（Actor）对步骤负责。之前我们举过的例子里，确认数量和确认信用额可能是平行的。有时候在Use Case的说明文档中标记这些可能的平行步骤是有用的。

Use Cases的大小

当开始做Use Cases的时候有个很显然的危险就是它要么有很多步骤要么就很少步骤。如果在Use Case中有超过15个步骤，它可能包含一些实现明细。如果它只有非常少的步骤则检查它的目标是否是达到一个没有很多分支的活动的单一线索。

较少的人类行为者（Actor）

如果Use Case有较少的人类行为者，而大多数行为者是其它系统，通常的做法是修改这个Use Case。寻找系统必须做出反映或公认的事件胜过会见这些行为者。

需求捕获和系统复杂性

总而言之，这些情节捕获到系统复杂度的同时行为者：目标语句对容许大的系统以相对压缩的格式说明。Use Case的格式的作用是用户和开发者能标志出行为者，然后确认这些行为者工作职责对应（或不对应）的目标，代替一个大的很难读的功能规格说明书。

仅仅这样，用户和开发者就有足够的兴趣进而研究那些情节的细节。

系统不仅仅有应得的功能性需求

一些Use Cases并没有捕获所有的客观需求，仅仅是捕获了系统怎么用的那些功能性需求。然而还有许多方面的需求需要去捕获的。其中有的非功能性需求使用关联以至于也能隶属于个别的Use Case，如性能需求和系统容量的需求。另外的一些不是关联的而是要单独地去捕获，它们是以下的需求：

· 系统范围

· 系统用户的目标

· 用户界面原型

· 一般规则

· 约束

· 算法

运行时期和建立时期的需求比较

一个重要的因数要记住，就是系统的赞助者是大过用户团体的。系统中有许多的风险承担者，Use Cases仅仅捕获其中一些风险承担者的需要，具体说，Use Cases仅仅捕获系统运行时期的需求而忽略做为系统开发组织的风险承担者的需求，开发组织最有兴趣的是对建立时期需求的描述。

运行时期需求包括：系统范围、用户组织对产品的期望和目标、Use Cases、其它非功能性需求。

建立时期需求包括：减少开发成本、较少的变更处理、现存组件的重用。

建立时期的需求可以部分的由Use Cases把握。但许多方面是需要由开发组织的处理的。

· 项目范围和目标：项目必须提交什么。（和系统范围的区别是它提交的是所有项目的东西）

· 增长性和变更请求：这些可以在捕获为常规Use Cases格式中的“Change Cases”

· 开发负责人的约束：包括标准、习惯、工具、品质度量标准、品质保证原则、及品质保证的习惯。 Use Cases首先用于需要响应客观事件的系统。它们能用于提供了一个有很容易理解的目标的清楚的行为者的环境。当结果不可定义或不清晰时不能用Use Cases。意思是如果目标成功或目标失败不能有一个明确的定义，那么Use Cases不能用来捕获需求。

然而说到这，现在大部分对象方法都使用Use Cases。因为Use Cases被证明是捕获需求的非常有效的机制。 Use Case 是系统提供的功能块，换句话来说Use Case演示了人们如何使用系统。通过Use Case观察系统，能够将系统实现与系统目标分开，有助于了解最重要的部分――满足用户要求和期望，而不会沉浸于实现细节。通过Use Case 用户可以看到系统提供的功能，先确定系统范围再深入开展项目工作。