>>>>系统集成项目管理工程师网络课堂

    >>>>系统集成项目管理工程师模拟考试

      2016上半年系统集成项目管理工程师考试已经结束，2016年下半年开始将使用新版考试大纲和教材，希赛小编为大家整理了一些系统集成项目管理工程师教程知识点精讲，希望对大家有所帮助。

      软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。根据IEEE的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

      1.需求的层次

      简单地说，软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。

      （1）业务需求。业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，项目视图和范围文档把业务需求集中在一个简单、紧凑的文档中，该文档为以后的开发工作奠定了基础。

      （2）用户需求。用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求。

      （3）系统需求。系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能（服务），使用户的业务目标得以满足；非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性（例如，可维护性、可维护性、效率等）和其他非功能需求。设计约束也称为限制条件或补充规约，通常是对系统的一些约束说明，例如，必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

      2.质量功能部署

      质量功能部署（Quality Function Deployment，QFD）是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

      （1）常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。

      （2）期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。

      （3）意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。

      3.需求获取

      需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是一件看上去很简单，做起来却很难的事情。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。因此，需求获取只有与用户的有效合作才能成功。

      常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等，有关这些方法的详细介绍，请阅读8.3.2节。

      4.需求分析

      在需求获取阶段获得的需求是杂乱的，是用户对新系统的期望和要求，这些要求有重复的地方，也有矛盾的地方，这样的要求是不能作为软件设计的基础的。一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

      需求分析将提炼、分析和审查已经获取到的需求，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。需求分析的关键在于对问题域的研究与理解。为了便于理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干个基本元素，然后对元素之间的关系进行建模。

      使用SA方法进行需求分析，其建立的模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。在实际工作中，一般使用实体联系图（E-R图）表示数据模型，用数据流图（Data Flow Diagram，DFD）表示功能模型，用状态转换图（State Transform Diagram，STD）表示行为模型。E-R图主要描述实体、属性，以及实体之间的关系；DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能；STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作（例如，处理数据等）。

      OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。OOA模型包括用例模型和分析模型，用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模；分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。

      5.软件需求规格说明书

      软件需求规格说明书（Software Requirement Specification，SRS）是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

      在标准GB/T 8567-2006中，提供了一个SRS的文档模板和编写指南，其中规定SRS应该包括以下内容：

      （1）范围。本部分包括SRS适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号；简述SRS适用的系统和软件的用途，描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、承建方和支持机构；标识当前和计划的运行现场；列出其他有关的文档；概述SRS的用途和内容，并描述与其使用有关的保密性和私密性的要求；说明编写SRS所依据的基线。

      （2）引用文件。列出SRS中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通过正常的供货渠道获得的所有文档的来源。

      （3）需求。这一部分是SRS的主体部分，详细描述软件需求，可以分为以下项目：所需的状态和方式、需求概述、需求规格、软件配置项能力需求、软件配置项外部接口需求、软件配置项内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求（包括硬件需求、硬件资源利用需求、软件需求和通信需求）、软件质量因素、设计和实现约束、数据、操作、故障处理、算法说明、有关人员需求、有关培训需求、有关后勤需求、包装需求和其他需求，以及需求的优先次序和关键程度。

      （4）合格性规定。这一部分定义一组合格性的方法，对于第（3）部分中的每个需求，指定所使用的方法，以确保需求得到满足。合格性方法包括演示、测试、分析、审查和特殊的合格性方法（例如，专用工具、技术、过程、设施和验收限制等）。

      （5）需求可追踪性。这一部分包括从SRS中每个软件配置项的需求到其涉及的系统（或子系统）需求的双向可追踪性。

      （6）尚未解决的问题。如果有必要，可以在这一部分说明软件需求中的尚未解决的遗留问题。

      （7）注解。包含有助于理解SRS的一般信息，例如，背景信息、词汇表、原理等。这一部分应包含为理解SRS需要的术语和定义，所有缩略语和它们在SRS中的含义的字母序列表。

      （8）附录。提供那些为便于维护SRS而单独编排的信息（例如，图表、分类数据等）。为便于处理，附录可以单独装订成册，按字母顺序编排。

      另外，标准《计算机软件需求说明编制指南》（GB/T 9385-1988）也给出了一个详细的SRS写作大纲，由于该标准年代久远，一些情况已经与现实不符，本书不再介绍。

      6.需求验证

      资深软件工程师都知道，当以SRS为基础进行后续开发工作，如果在开发后期或在交付系统之后才发现需求存在问题，这时修补需求错误就需要做大量的工作。相对而言，在系统分析阶段，检测SRS中的错误所采取的任何措施都将节省相当多的时间和资金。因此，有必要对于SRS的正确性必须进行验证，以确保需求符合良好特征。需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

      （1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。

      （2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。

      （3）需求是完整的和高质量的。

      （4）需求的表示在所有地方都是一致的。

      （5）需求为继续进行系统设计、实现和测试提供了足够的基础。

      在实际工作中，一般是通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审，SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。需求的遗漏和错误具有很强的隐蔽性，仅仅通过阅读SRS，通常很难想象在特定环境下的系统行为。只有在业务需求基本明确，用户需求部分确定时，同步进行需求测试，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。

    返回目录：信息系统集成专业技术知识知识点精讲汇总

    希赛软考网，拥有十四年软考培训经验，希赛网一直坚持自主研发，将丰富的软考培训经验有效融入教程研发过程，自成体系的软考在线题库（软考历年真题）、软考培训教材和软考视频教程，多样的培训方式包括在线辅导、面授、和，使考生的学习更具系统性，辅导更具针对性。采用全程督学机制，，软考平均通过率在全国。