免费智能真题库 > 历年试卷 > 系统分析师 > 2010年上半年 系统分析师 上午试卷 综合知识
  第20题      
  知识点:   需求分析   需求获取   需求分析阶段
  关键词:   捕获   分析阶段   开发   通信   需求分析   应用软件   需求        章/节:   软件工程基础知识       

 
某大型移动通信运营商欲开发一个新的应用软件,在需求分析阶段,为了有效获得用户的需求,应该采用(20)的方法捕获需求。
 
 
  A.  用户访谈
 
  B.  联合需求
 
  C.  抽样
 
  D.  头脑风暴
 
 
 

 
  第26题    2015年上半年  
   42%
下列活动,()不属于需求开发活动的范畴。
  第40题    2009年上半年  
   67%
在数据库设计的需求分析阶段,业务流程一般采用(40)表示。
  第29题    2011年上半年  
   45%
软件需求管理是软件项目开发过程中控制和维持需求约定的活动,包括(29)、 版本控制、需求跟踪、需求状态跟踪等活动。
   知识点讲解    
   · 需求分析    · 需求获取    · 需求分析阶段
 
       需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在10.3节中进行详细介绍。
        (3)面向问题域的分析(Problem Domain Oriented Analysis, PDOA)方法。PDOA更多地强调描述,而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素,是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图,但不同的是上下文图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段,并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程,明确各个部门之间的业务关系和每个业务处理的意义,为业务流程的合理化改造提供建议,为系统的数据流程变化提供依据。
               业务流程分析的步骤如下:
               (1)通过调查掌握基本情况。
               (2)描述现有业务流程(绘制业务流程图)。
               (3)确认现有业务流程。
               (4)对业务流程进行分析。
               (5)发现问题,提出解决方案。
               (6)提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               数据流图
               DFD是结构化分析中的重要方法和工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,一般将它作为需求说明书的组成部分。
               
               业务流程图符号
               DFD从数据传递和加工的角度,利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。具体来说,DFD的主要作用如下:
               (1)DFD是理解和表达用户需求的工具,是系统分析的手段。由于DFD简明易懂,理解它不需要任何计算机专业知识,因此通过它同客户交流很方便。
               (2)DFD概括地描述了系统的内部逻辑过程,是系统分析结果的表达工具,因而也是系统设计的重要参考资料,是系统设计的起点。
               (3)DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。
               在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况,用一个DFD是不够的。稍微复杂的实际问题,在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的DFD反映这种结构关系,能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1,第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,它的上层图称为父图,在它下一层的图则称为子图。
               
               分层数据流图
               概括地说,画DFD的基本步骤,就是“自顶向下,逐层分解”。检查和修改的原则如下:
               (1)DFD中的所有图形符号只限于前述4种基本图形元素。
               (2)顶层DFD必须包括前述4种基本元素,缺一不可。
               (3)顶层DFD中的数据流必须封闭在外部实体之间。
               (4)每个加工至少有一个输入数据流和一个输出数据流。
               (5)在DFD中,需按层给加工框编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
               (6)规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               (7)可以在DFD中加入物质流,帮助用户理解DFD。
               (8)图上每个元素都必须有名字。
               (9)DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合,也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD,数据字典难以发挥作用;没有数据字典,DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起,才能共同构成系统的规格说明。
               数据字典的设计包括:数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息:名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言、判定树及判定表。
               (1)结构化语言:介于自然语言和形式语言之间的一种半形式语言,在自然语言基础之上加了一些限度,使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
 
       需求获取
        在需求获取的过程中,主要解决需求调查的问题。要想做好需求调查,必须清楚地了解3个问题。
        (1)What:应该搜集什么信息。
        (2)Where:从什么地方搜集这些信息。
        (3)How:用什么机制或者技术来搜集这些信息。
               要捕获的信息
               从宏观的角度来看,要获取的信息包括3大类:一是与问题域相关的信息(如业务资料、组织结构图、业务处理流程等),二是与要求解决的问题相关的信息,三是用户对系统的特别期望与施加的任何约束的信息。
               信息的来源
               除了要明确地知道我们需要什么方面的信息,还要知道它们可以从哪里获得。而通常情况下,这些信息会藏于客户、原有系统、原有系统用户、新系统的潜在用户、原有产品、竞争对手的产品、领域专家、技术法规与标准里。
               面对这么多种可能,在具体的实践中该从何下手呢?其实也很简单,首先从人的角度来说,应该首先对项目干系人进行分类,然后从每一类项目干系人中找到1或2名代表;而对于文档、产品而言,则更容易有选择地查阅。
               在制定需求获取计划的时候,可以列出一个表格,第1列是我们想了解的信息,第2列是信息可能的来源,这样就能够建立起一一对应的关系,使得需求获取工作更加有的放矢,也更加高效。
               需求捕获技术
               当我们知道需要去寻找什么信息,并且也找到了信息的来源地,接下来就需要选择合适的技术进行需求获取了。
               (1)用户访谈。用户访谈是最基本的一种需求获取手段,其形式包括结构化和非结构化两种,结构化是指事先准备好一系列问题,有针对地进行;非结构化则是只列出一个粗略的想法,根据访谈的具体情况来发挥。最有效的访谈是结合这两种方法进行。用户访谈具有良好的灵活性,有较宽广的应用范围,但是也存在着许多困难,诸如客户经常较忙,难以安排到时间;面谈时信息量大,记录较为困难;沟通需要很多技巧,同时需要分析人员有足够的领域知识;另外,在访谈时会遇到一些对于组织来说比较机密和敏感的话题。因此,这看似简单的技术,也需要分析人员拥有足够多的经验和较强的沟通能力。
               (2)用户调查。用户访谈时最大的难处在于很多关键的人员时间有限,不容易安排到过多的时间;而且客户面经常较广,不可能一一访谈。因此,我们就需要借助用户调查,通过精心设计要问的问题,然后下发到相关的人员手里,让他们填写答案。这样就可以有效的克服前面提到的两个问题。但是与用户访谈相比,用户调查最大的不足就是缺乏灵活性;而且双方未见面,分析人员无法从他们的表情等其他动作来获取一些更隐性的信息;还有就是客户有可能在心理上会不重视一张小小的表格,不会认真对待从而使得反馈的信息不全面。因此较好的做法是将这两种技术结合使用。具体来说,就是先设计问题,制作成为用户调查表,下发填写完后,进行仔细的分组、整理、分析,以获得基础信息,然后再针对这个结果进行小范围的用户访谈,作为补充。
               (3)现场观摩。对于许多较为复杂的流程和操作而言,是比较难以用言语表达清楚的,而且这样做也会显得很低效。因此,针对这一现象,分析团队可以就一些较复杂、较难理解的流程、操作采用现场观摩的方法来获取需求。具体来说,就是走到客户的工作现场,一边观察,一边听客户的讲解,甚至可以安排人员跟随客户工作一小段时间。这样就可以使得分析人员更加直观地理解需求。
               (4)阅读历史文档。这种方式也称为“文档考古”。对于一些数据流比较复杂的,工作表单较多的项目,有时是难以通过说,或者通过观察来了解需求细节的。这个时候就可以借助于阅读历史文档的方法,对历史存在的一些文档进行研究,从中获得所需的信息。这个方法的主要风险是历史的文档可能与新系统的流程、数据有一些不吻合的地方,并且还可能承载一些原有系统的缺陷。要想有效地避免和发现这些问题,就需要分析人员能够运用自己的聪明才智,将其与其他需求捕获技术结合对照。还有一个负面因素就是,这些历史的文档中记载的信息有可能涉及到客户的商业秘密,因此对数据信息的保密也是分析人员基本的职业道德。
               (5)联合讨论会。这是一种相对来说成本较高的需求获取方法,但也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起,通过有组织的会议来讨论需求。通常该会议的参与人数为6~18人,召开时间为1~5小时。在会议之前,应该将与讨论主题相关的材料提前分发给所有将要参加会议的人。在会议开始之后,首先应该花一些时间让所有的与会者互相认识,以使交流在更加轻松的气氛下进行。会议的最初,就是针对所列举的问题进行逐项专题讨论,然后对原有系统、类似系统的不足进行开放性交流,第三步则是大家在此基础上对新的解决方案进行一番设想,在过程中将这些想法、问题、不足记录下来,形成一个要点清单。第四步就是针对这个要点清单进行整理,明确优先级,并进行评审。这种联合讨论会将会起到群策群力的效果,对于一些问题最有歧义的时候、对需求最不清晰的领域都是十分有用的一种技术。而且最大的难度就是会议的组织,要做到言之有物,气氛开放,否则将难以达到预想的效果。
               需求捕获的策略
               在整个需求过程中,需求捕获、需求分析、需求定义、需求验证四个阶段不是瀑布式的发展,而且应该采用迭代式的演化过程。也就是说,在进行需求捕获时,不要期望着一次就将需求收集完,而是应该捕获到一些信息后,进行相应的需求分析,并针对分析中发现的疑问和不足,带着问题再进行有针对性的需求捕获工作。
 
       需求分析阶段
        . 确定软件的可靠性目标;
        . 分析可能影响可靠性的因素;
        . 确定可靠性的验收标准;
        . 制定可靠性管理框架;
        . 制定可靠性文档编写规范;
        . 制定可靠性活动初步计划;
        . 确定可靠性数据收集规范。
   题号导航      2010年上半年 系统分析师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第20题    在手机中做本题