免费智能真题库 > 历年试卷 > 软件评测师 > 2014年下半年 软件评测师 上午试卷 综合知识
  第37题      
  知识点:   软件需求   用例模型
  关键词:   需求   用例        章/节:   软件工程基础       

 
在各种不同的软件需求中, (37)描述了产品必须要完成的任务,可以在用例模型中予以说明。
 
 
  A.  功能需求
 
  B.  业务需求
 
  C.  质量需求
 
  D.  设计约束
 
 
 

 
  第34题    2012年下半年  
   42%
某银行系统要求报表功能容易扩展,以便在需要的时候可以处理新的文件格式,则该需求是(34)的。
  第21题    2014年下半年  
   38%
在数据库逻辑结构设计阶段,需要 (20 ) 阶段形成的( 21)作为设计依据。
  第31题    2014年下半年  
   36%
在项目初始阶段,软件开发首先需要(31) 。
   知识点讲解    
   · 软件需求    · 用例模型
 
       软件需求
        在进行需求获取之前,首先要明确需要获取什么,也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常,这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等,并预先估计以后系统可能达到的目标。此外,还需要注意其他非功能性的需求。具体内容如下。
        (1)功能需求。
        (2)性能需求。
        (3)用户或人的因素。
        (4)环境需求。
        (5)界面需求。
        (6)文档需求。
        (7)数据需求。
        (8)资源使用需求。
        (9)安全保密要求。
        (10)可靠性要求。
        (11)软件成本消耗与开发进度需求。
        (12)其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               (1)确定软件系统的综合要求,包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               (2)分析软件系统的数据要求,包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               (3)导出系统的逻辑模型,在结构化方法中可用数据流图来描述;在面向对象分析方法中可以用类模型来描述。
               (4)修正项目开发计划。
               (5)如有必要,可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               (1)功能需求。所开发的软件必须具备什么样的功能。
               (2)非功能需求。它是指产品必须具备的属性或品质,如可靠性、性能响应时间、容错性和可扩展性等。
               (3)设计约束。其也称为限制条件、补充规约,这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的,数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
 
       用例模型
        OOA的基本任务是运用面向对象方法,对问题域和系统责任进行分析和理解,正确认识其中的事物及它们之间的关系,找出描述问题域及系统责任所需的类和对象,定义它们的属性和服务,以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求,并能直接反映问题域和系统责任的OOA模型及其详细说明。
        用例分析方法的创始人Ivar Jacobson给用例的定义是:“用例实例是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果。一个用例则定义一组用例实例。”从这个定义中,我们可以得知用例是由一组用例实例组成的,用例实例也就是常说的“使用场景”,就是用户使用系统的一个实际的、特定的场景;其次,可以知道,用例应该给参与者带来可见的价值,这点很关键;最后还可以得知,用例是在系统中的。
        用例分析技术为软件需求规格化提供了一个基本的元素,而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。构建用例模型需要经历识别参与者、合并需求获得用例、细化用例描述三个阶段。
        (1)识别参与者。参与者(actor)是系统之外与系统进行交互的任何事物,参与者可以是使用系统的用户,也可以是其他外部系统、外部设备等外部实体。在UML中采用小人符号来表示参与者。参与者有主要参与者和次要参与者之分,开发用例的重点是要找到主要参与者。
        (2)合并需求获得用例。将参与者都找到之后,接下来就是仔细地检查参与者,为每一个参与者确定用例。而其中的依据主要可以来源于已经获取得到的特征表。首先,将特征分配给相应的参与者,然后进行合并操作,最后绘制成用例图。在确定用例的过程中,不能混淆用例和用例所包含的步骤,要注意区分业务用例和系统用例。
        (3)细化用例描述。用例建模的主要工作是书写用例规约(use case specification),而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果,其内容至少包括用例名、参与者、目标、前置条件、事件流(基本事件流、扩展事件流)、后置条件等,其他的还可以包括非功能需求、用例优先级等。
        :一个较为复杂的系统会有较多的用例,为便于理解,可以为它们建立多张用例图。更为复杂的情况将导致所有用例难以维持一种平面结构,这时可以对用例进行分组。UML使用用例主题划分用例图,一组用例放置在以主题命名的方框中(类似于系统边界),每个主题中可以包含多个用例图。
   题号导航      2014年下半年 软件评测师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第37题    在手机中做本题