免费智能真题库 > 历年试卷 > 系统分析师 > 2016年上半年 系统分析师 下午试卷 论文
  第1题      
  知识点：   开发过程   需求分析   来源   软件需求   完整性   项目干系人   一致性   用户需求

 
论软件需求验证方法及其应用
在软件开发过程中，如果后期或在交付之后发现了需求问题，则修补需求错误需要投入大量的人力物力。因此，开展软件需求验证，对软件需求规格说明书(SRS)的正确性和质量进行验证，是需求分析的重要工作内容。需求验证也称为需求确认，主要内容包括：确定SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；确定软件需求是从用户需求、业务规格和其他来源中正确推导而来的；确定需求的完整性、一致性和高质量。需求验证为后续的系统设计、实现和测试提供了足够的基础。
 
问题：1.1   请围绕“软件需求验证方法及其应用”论题，依次从以下三个方面进行论述。
1．概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。
2．简要说明需求验证的主要方法及实施过程。
3．结合你具体参与管理和开发的实际项目，阐述所选择的验证方法及其原因，说明具体实施过程，并详细分析实施效果。
 
 
 

   知识点讲解    
   · 开发过程    · 需求分析    · 来源    · 软件需求    · 完整性    · 项目干系人    · 一致性    · 用户需求
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程的方法来进行，如采用原型化方法、结构化方法等。
        由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段中产生的文档来进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境中进行调试，根据实际情况可以选用4.6.2节中的调试方法之一或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
        最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
 
       需求分析
        需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：
        （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）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
 
       来源
        （1）由信息技术支持工程师提供。召集有经验的信息技术支持工程师，要求他们提供知识库的内容，知识库的建立并不是某个人智慧的积累，毕竟一个人的知识和经验有限，我们需要在企业中营造这样一种乐意共享自身知识的氛围，能够提供有效知识条目的工程师能够获得奖励。发布一系列奖惩和鼓励措施。
        （2）从过往的事件和问题的处理日志中提炼。事件与问题的处理过程需要详细记录，能为下一次处理相同事件提供指导和参考。知识库内容可以从这些处理日志中提炼后获得，事件处理步骤的详细记录对于知识库内容的建立有着重要的帮助。
 
       软件需求
        在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
        （1）功能需求。
        （2）性能需求。
        （3）用户或人的因素。
        （4）环境需求。
        （5）界面需求。
        （6）文档需求。
        （7）数据需求。
        （8）资源使用需求。
        （9）安全保密要求。
        （10）可靠性要求。
        （11）软件成本消耗与开发进度需求。
        （12）其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               （1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               （2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               （3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
               （4）修正项目开发计划。
               （5）如有必要，可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               （1）功能需求。所开发的软件必须具备什么样的功能。
               （2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
               （3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
 
       完整性
        完整性（Integrity）是指网络信息或系统未经授权不能进行更改的特性。例如，电子邮件在存储或传输过程中保持不被删除、修改、伪造、插入等。完整性也被称为网络信息系统CIA三性之一，其中I代表Integrity。完整性对于金融信息系统、工业控制系统非常重要，可谓“失之毫厘，差之千里”。
 
       项目干系人
        定义
        项目干系人（Project Stakeholder），也称为利害相关者，是积极参与项目，或其利益因项目的实施或完成而受到积极或消极影响的个人或组织，他们还会对项目的目标和结果产生影响。项目管理团队必须明确项目的干系人，确定其需求，然后对这些需求进行管理和施加影响，确保项目取得成功。
        干系人对项目的影响
        包括积极的影响和消极的影响。项目管理团队不仅要关注积极的项目干系人，也不能忽略消极项目干系人。项目关键干系人包括：
        .项目经理（Project Manager）
        .顾客／客户（Customer/User）
        .执行组织（Performing Organization）
        .项目团队成员（Project Team Members）
        .项目管理团队（Project Management Team）
        .出资人（Sponsor）
        .有影响力的人（Influencers）
        .项目管理办公室（PMO）
 
       一致性
        在讨论一致性之前，先看一下CAP理论。它作为一种理论依据，使得在不同应用中，对一致性也有了不同的要求。CAP理论：简单地说，就是对于一个分布式系统，一致性（Consistency）、可用性（Availablity）和分区容忍性（Partition tolerance）三个特点最多只能三选二。
        一致性意味着系统在执行了某些操作后仍处在一个一致的状态，这点在分布式的系统中尤其明显。比如某用户在一处对共享的数据进行了修改，那么所有有权使用这些数据的用户都可以看到这一改变。简言之，就是所有的结点在同一时刻有相同的数据。
        可用性指对数据的所有操作都应有成功的返回。高可用性则是在系统升级（软件或硬件）或在网络系统中的某些结点发生故障的时候，仍可以正常返回。简言之，就是任何请求不管成功或失败都有响应。
        分区容忍性这一概念的前提是在网络发生故障的时候。在网络连接上，一些结点出现故障，使得原本连通的网络变成了一块一块的分区，若允许系统继续工作，那么就是分区可容忍的。
        在数据库系统中，事务的ACID属性保证了数据库的一致性。比如银行系统中，转账就是一个事务，从原账户扣除金额，以及向目标账户添加金额，这两个数据库操作的总和构成一个完整的逻辑过程，具有原子的不可拆分特性，从而保证了整个系统中的总金额没有变化。
        然而，这些ACID特性对于大型的分布式系统来说，是和高性能不兼容的。比如，你在网上书店买书，任何一个人买书这个过程都会锁住数据库直到买书行为彻底完成（否则书本库存数可能不一致），买书完成的那一瞬间，世界上所有的人都可以看到书的库存减少了一本（这也意味着两个人不能同时买书）。这在小的网上书城也许可以运行得很好，可是对Amazon这种网上书城却并不是很好。
        而对于Amazon这种系统，它也许会用Cache系统，剩余的库存数也许是几秒甚至几个小时前的快照，而不是实时的库存数，这就舍弃了一致性。并且，Amazon可能也舍弃了独立性，当只剩下最后一本书时，也许它会允许两个人同时下单，宁愿最后给那个下单成功却没货的人道歉，而不是整个系统性能的下降。
        由于CAP理论的存在，为了提高性能，出现了ACID的一种变种BASE（这四个字母分别是Basically Available，Soft—state，Eventual consistency的开头字母，是一个弱一致性的理论，只要求最终一致性）：
        .Basically Available：基本可用。
        .Soft state：软状态，可以理解为“无连接”的，而与之相对应的Hard state就是“面向连接”的。
        .Eventual consistency：最终一致性，最终整个系统（时间和系统的要求有关）看到的数据是一致的。
        在BASE中，强调可用性的同时，引入了最终一致性这个概念，不像ACID，其并不需要每个事务都是一致的，只需要整个系统经过一定时间后最终达到一致。比如Amazon的卖书系统，也许在卖的过程中，每个用户看到的库存数是不一样的，但最终卖完后，库存数都为0。再比如SNS网络中，C更新状态，A也许可以1分钟就看到，而B甚至5分钟后才看到，但最终大家都可以看到这个更新。
        具体地说，如果选择了CP（一致性和分区容忍性），那么就要考虑ACID理论（传统关系型数据库的基石，事务的四个特点）。如果选择了AP（可用性和分区容忍性），那么就要考虑BASE系统。如果选择了CA（一致性和可用性），如Google的bigtable，那么在网络发生分区的时候，将不能进行完整的操作。
        ACID理论和BASE的具体对比如下表所示。
        
        ACID和BASE的对比表
 
       用户需求
        收集用户需求是要找出用户需要的重要服务和功能。收集用户需求的机制主要包括与用户群的交流、用户服务和需求归档3个方面。
        收集用户需求最常用的方式有观察和问卷调查、集中访谈、采访关键人物。在整个设计和实施阶段，应始终保持与关键人员之间的交流，以确保网络工程建设不偏离用户需求。
        用户服务表用于表示收集和归档的需求信息，也用来指导管理人员和网络用户进行讨论。
   题号导航      2016年上半年 系统分析师 下午试卷 论文   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第1题    在手机中做本题