爱问知识人 爱问教育 医院库

我们应当怎样做需求分析:用例说明求解答

首页

我们应当怎样做需求分析:用例说明求解答

我们应当怎样做需求分析:用例说明求解答

提交回答

全部答案

    2018-03-09 10:17:17
  •   当我们进行业务流程分析时,只空对空而不落到纸面上是不可以的。过去,在面向过程的时代,我们绘制DFD图、流程图,以及编写流程说明来描绘这一部分分析;而现在,在面向对象的时代,我们则是绘制行动图、状态图,以及编写用例说明来完成这部分工作。
    毫不疑问,做用例分析首先是要绘制出用例图(前面已经说过了)。
      图形的最大优势是能够形象生动地描述我们的分析,但它最大的缺点是会遗失许多的细节信息,因此我们必须要对它进行进一步的文字描述。
    由于不同的人对用例的理解不同,格式也不尽相同,但一些基本的元素是一样的。以上表格是我采用的用例说明格式,其中用例名称、用例描述、参与者、前置条件、事件流、后置条件是公认的、用例说明的基本元素。
      
    用例标识:就是用例的编号,一般采用“项目编号-子系统编号-模块编号-序号”来编号。
    用例名称:没啥可说的,就是用例图中该用例的名称。注意用例的命名规则:用例名称通常是一个动词短语或短句,而不是一个名词短语。
      它可以是一个动词(如:自动考核),一个动宾短语(如:提取存款),一个被动句(如:发票填报),或者一个主谓句(如:用户提款,这个不推荐,因为主语就是参与者,显得有些多余)。
    参与者:用例图中该用例的参与者,通常是业务操作的触发者和施与对象(如外部系统)。
      
    前置条件:在触发该用例相关操作前必须达到的条件。
    事件流:这是用例说明中最重要的部分,它详细描述了该用例可能出现的所有流程。
    1。 基本流程:另一个名称更能表达它的意义:最佳流程(The Best Flow)。
      它描述的是该用例以最佳的、最正常的方式流转,没有出现任何异常,并且最终成功完成操作的流程。基本流程在编写时,应当通过数字对流程中的每一步进行编号。
    2。 扩展流程:或者叫“分支流程”,它描述的是基本流程在流转过程中可能出现的所有分支。
      扩展流程最大的特点就是,它应当是在基本流程的某一步骤发生的分支,因此它的编号规则是“基本流程号 序号”。基本流程号就是发生分支的那一个基本流程的编号。在同一个基本流程上发生多个分支时,它们的序号从1依次开始编号。
    另一种情况是,某个扩展流程本身拥有多个步骤,这时应当在“基本流程号 自身序号”的基础上再添加序号,如“2。
      1。1”。
    扩展流程在描述时,应当首先描述进入这个分支的条件,即“如果××则××”、“当××时××”。
    3。 异常流程:就是发生异常情况时的处理流程。注意,用例说明是站在用例角度进行的说明,因此这里并不是我们通常一样的发生程序异常的处理流程,而是用户在处理业务操作时发生的异常情况,如:如果顾客不能提供身份证,则616161616161
    后置条件:又称为“成功保证”,就是执行基本流程获得成功以后所达到的状态(条件)。
      后置条件往往体现的是执行该用例的最终目的。如:完成用户档案的填写并提交。
    非功能需求:简称为“URPS ”,即可用性(Usability)、可靠性(Reliability)、性能(Performance)、可支持性(Supportability)以及其它( )。
      这一部分的需求分析相当重要而又最容易被忽略,后面我们再详细讨论。
    假设与约束:就是隐藏于业务功能中的各项规则与条件,如各种逻辑条件、计算公式、环境限制等等。
    除此之外,我还往往在每一个用例说明的后面与该用例相关的需求列表,便于需求跟踪。
      用例分析实质是需求人员的一份设计。既然是设计就可能出现偏差,最终偏离原始的需求(这种情况特别容易出现在日后的升级维护中)。因此,将需求列表附在用例后面,便于日后的需求评审与确认。当每次需要升级时,则添加上新的需求,或对以往的需求进行更新。
      
    我们应当怎样做需求分析我们应当怎样做需求调研:初识我们应当怎样做需求调研:拜访我们应当怎样做需求调研:研讨会我们应当怎样做需求调研:需求研讨我们应当怎样做需求调研:迭代我们应当怎样做需求调研:需求捕获(上)我们应当怎样做需求调研:需求捕获(下)我们应当怎样做需求分析:功能角色分析与用例图我们应当怎样做需求分析:业务流程分析(上)我们应当怎样做需求分析:业务流程分析(下)我们应当怎样做需求分析:查询报表分析我们应当怎样做需求分析:子用例与扩展用例我们应当怎样做需求分析:行动图和状态图我们应当怎样做需求分析:业务领域分析我们应当怎样做需求分析:原文分析法我们应当怎样做需求分析:领域驱动设计我们应当怎样做需求分析:非功能需求我们应当怎样做需求确认:需求列表我们应当怎样做需求确认:一个需求列表的实例我们应当怎样做需求确认:快速原型法我们应当怎样做需求确认:需求规格说明书我们应当怎样做需求确认:评审与签字确认会(续)。

    张***

    2018-03-09 10:17:17

类似问题

换一换
  • 物理学 相关知识

  • 教育培训
  • 教育科学
  • 教育考试

相关推荐

正在加载...
最新资料 推荐信息 热门专题 热点推荐
  • 1-20
  • 21-40
  • 41-60
  • 61-80
  • 81-100
  • 101-120
  • 121-140
  • 141-160
  • 161-180
  • 181-200
  • 1-20
  • 21-40
  • 41-60
  • 61-80
  • 81-100
  • 101-120
  • 121-140
  • 141-160
  • 161-180
  • 181-200
  • 1-20
  • 21-40
  • 41-60
  • 61-80
  • 81-100
  • 101-120
  • 121-140
  • 141-160
  • 161-180
  • 181-200
  • 1-20
  • 21-40
  • 41-60
  • 61-80
  • 81-100
  • 101-120
  • 121-140
  • 141-160
  • 161-180
  • 181-200

热点检索

  • 1-20
  • 21-40
  • 41-60
  • 61-80
  • 81-100
  • 101-120
  • 121-140
  • 141-160
  • 161-180
  • 181-200
返回
顶部
帮助 意见
反馈

确定举报此问题

举报原因(必选):