前言：系统集成项目管理工程师专业，现分享一些教材知识点。觉得文章还不错的喜欢点赞收藏的同时帮忙点点关注。
软考同样是国家人社部和工信部组织的国家级考试，全称为“全国计算机与软件专业技术资格（水平）考试”，目前涵盖了计算机软件、计算机网络、计算机应用技术、信息系统、信息服务5大领域，总共27个科目，也是分为初、中、高三个级别。
通信专业主要需要关注“计算机网络”这个专业类别，可以考的科目有初级资格的“网络管理员”、中级的“网络工程师”。
还有5个高级资格专业，分别是“信息系统项目管理师“”系统分析师“”系统架构设计师“”网络规划设计师“”系统规划与管理师“。
软考高级证书在通信行业比较吃香，主要原因有两个： 通信行业与计算机软件是相近专业，评职称满足相近专业的要求； 通信高级不能以考代评，但软考高级可以，很多考生通过考软考高级来评高级职称。
————————————————
目录
前言：系统集成项目管理工程师专业，现分享一些教材知识点。觉得文章还不错的喜欢点赞收藏的同时帮忙点点关注。
第5章 软件工程
5.1软件工程定义
5.2软件需求
5.2.1需求的层次
1.业务需求
2.用户需求
3.系统需求
5.2.2质量功能部署
5.2.3需求获取
5.2.4需求分析
1.结构化分析
1）DFD需求建模方法
2）数据字典的应用
2.面向对象分析
1）OOA的基本原则
2）OOA的基本步骤
5.2.5需求规格说明书
5.2.6需求变更
1）变更控制过程
2 ）变更策略
3）变更控制委员会
5.2.7需求跟踪
第5章 软件工程
20世纪 60 年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在 指定的计算机上进行设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件规模比较 小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上 是个人设计、个人使用、个人操作、 自给自足的私人化的软件生产方式。
20世纪 60 年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开 发量急剧增长，软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。 1968年，软件危机（Software Crisis） 的概念被首次提出，具体表现为软件开发进度难以预测、软 件开发成本难以控制、软件功能难以满足用户期望、软件质量无法保证、软件难以维护、软件缺少 适当的文档资料等，为解决软件危机，软件工程概念诞生。
5.1软件工程定义
软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问 题的工程，其目的是提高软件生产率、提高软件质量、 降低软件成本 。 电气与电子工程师协会 （Institute of Electricaland Electronics Engineers ，IEEE）对软件工程的定义是：将系统的、规范的、 可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。计算机科学家 FritzBauer给出的软件工程的定义是：建立并使用完善的工程化原则， 以较经济的手段获得能在实 际机器上有效运行的可靠软件的一系列方法。
软件工程由方法、工具和过程 3个部分组成。软件工程使用的方法是完成软件项目的技术手 段，它支持整个软件生命周期；软件工程使用的工具是人们在开发软件的活动中智力和体力的扩展 与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成；软件工程中的过程 贯穿于软件开发的各个环节，是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系 列软件工程活动。管理人员在软件工程过程中，要对软件开发的质量、进度、成本进行评估、管理 和控制，包括人员组织、计划跟踪与控制、成本估算、质量保证和配置管理等。
5.2软件需求
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。根据IEEE的软件工 程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满 足合同、标准、规范或其他正式规定文档所需具有的条件或能力， 以及反映这些条件或能力的文档 说明，
5.2.1需求的层次
简单地说，软件需求就是系统必须完成的事和必须具备的品质。需求是多层次的，包括业务需 求、用户需求和系统需求，这3个不同层次的需求从目标到具体，从整体到局部，从概念到细节。
1.业务需求
业务需求是指反映组织机构或用户对系统、产品高层次的目标要求，从总体上描述了为什么要 达到某种效应，组织希望达到什么目标。通常来自项目投资人、购买产品的客户、客户单位的管理 人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，项目视图和范围 文档把业务需求集中在一个简单、紧凑的文档中，该文档为以后的设计开发工作奠定了基础（ 高19 上、18下）。
2.用户需求
用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务和想要达到的结果，这 构成了用户原始需求文档的内容。也就是说，用户需求必须能够体现某种系统产品将给用户带来的 业务价值，描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的 场景进行整理，从而建立用户需求。
3.系统需求
系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和约束等。
功能需求
也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任 务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的。所谓特性，是指一组逻辑上 相关的功能需求，表示系统为用户提供某项功能（服务），使用户的业务目标得以满足。非功能需 求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和合约，是指 系统必须具备的属性或品质，又可细分为软件质量属性（例如易用性、可维护性、效率等）和其他 非功能需求。约束是指对开发人员在软件产品设计和构造上的限制，常见的有设计约束和过程约 束。例如，必须采用安全可靠的自主知识产权的数据库系统，必须运行在开源操作系统之下等。
5.2.2质量功能部署
质量功能部署（Quality Function Deployment ，QFD），即通过多种角度对产品的特点进行描述，从而反映产品功能，是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件 工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为3类，分别是常规需求、期望 需求和意外需求（ 高21上）。
（1）常规需求。用户认为系统应该做到的功能或性能，实现得越多，用户会越满意。
（2）期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
（3）意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开 发人员很乐意赋予系统的技术特性） ，实现这些需求用户会更高兴，但不实现也不影响其购买的决 策。意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求， 以便得到高满 意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。
5.2.3需求获取
需求获取是确定和理解不同的项目干系人对系统的需求和约束的过程。需求获取是一件看上去 很简单、做起来却很难的事情。需求获取是否科学、准备充分，对获取到的结果影响很大，因为用 户往往很难给出完整正确的原始需求，也很难想象出未来的软件应该提供哪些功能， 以解决自己的 业务问题。因此，需求获取的过程中，只有与用户有效合作、得到软件人员的协助、进行多次沟通 讨论才能成功确认需求。常见的需求获取方法包括用户访谈、 问卷调查、采样、情节串联板、联合 需求计划等。
需求获取是开发者、用户之间为了定义新系统而进行的交流，需求获取是获得系统必要的特 征，或者是获得用户能接受的、系统必须满足的约束。如果双方所理解的领域内容在系统分析、设 计过程出现问题，通常在开发过程的后期才会被发现，将会使整个系统交付延迟，或者上线的系统 无法或难以使用，最终导致项目失败。例如，遗漏的需求或理解错误的需求。
5.2.4需求分析
在需求获取阶段获得的需求是杂乱的，是用户对新系统的期望和要求，这些要求有重复的地 方，也有矛盾的地方，这样的要求是不能作为软件设计的基础的。一个好的需求应该具有无二义 性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。因此，需要分析人 员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
需求分析将提炼、分析和审查已经获取到的需求，以确保所有的项目干系人都明白其含义，并 找出其中的错误、遗漏或其他不足的地方。需求分析的关键在于对问题域的研究与理解。为了便于 理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干个基本元素， 然后对元素之间的关系进行建模。
1.结构化分析
结构化分析（Structured Analysis ，SA）方法给出一组帮助系统分析人员产生功能规约的原理 与技术，其建立模型的核心是数据字典。围绕这个核心，有3个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型） 。在实际工作中，一般使用实体关系图（E-R图）表示数据 模型（ 高20下），用数据流图（Data Flow Diagram ，DFD）表示功能模型，用状态转换图（State Transform Diagram ，STD）表示行为模型（ 高22上、19下）。
E-R图主要描述实体、属性，以及实体之间的关系；
DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据 在它们之间传递的情况，来说明系统所完成的功能；
STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件 的结果将执行哪些动作（例如处理数据等）。
结构化分析通常包含以下几个步骤：
●分析业务情况，做出反映当前物理模型的DFD；
●推导出等价的逻辑模型的DFD；
●设计新的逻辑系统，生成数据字典和基元描述；
●建立人机接口，提出可供选择的目标系统物理模型的DFD；
●确定各种方案的成本和风险等级，据此对各种方案进行分析；
●选择一种方案；
●建立完整的需求规约。
1）DFD需求建模方法
DFD需求建模方法也称为过程建模和功能建模方法。DFD建模方法的核心是数据流，从应用系 统的数据流着手， 以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流。DFD建模 方法首先抽象出具体应用的主要业务流程，然后分析其输入，例如其初始的数据有哪些，这些数据 从哪里来，将流向何处，又经过了什么加工，加工后又变成了什么数据，这些数据流最终将得到什 么结果。通过对系统业务流程的层层追踪和分析，把要解决的问题清晰地展现及描述出来，为后续 的设计、编程及实现系统的各项功能打下基础。DFD方法由以下4种基本元素（模型对象）组成：
数据流、处理/加工、数据存储和外部项。
●数据流（DataFlow）：用一个箭头描述数据的流向，箭头上标注的内容可以是信息说明或数 据项。
●处理（Process）：表示对数据进行的加工和转换，在图中用矩形框表示。指向处理的数据流 为该处理的输入数据，离开处理的数据流为该处理的输出数据。
●数据存储：表示用数据库形式（或者文件形式）存储的数据，对其进行的存取分别以指向或
离开数据存储的箭头表示。
●外部项：也称为数据源或者数据终点。描述系统数据的提供者或者数据的使用者，如教师、 学生、采购员、某个组织或部门或其他系统，在图中用圆角框或者平行四边形框表示。
建立DFD图的目的是描述系统的功能需求。DFD方法利用应用问题域中数据及信息的提供者与 使用者、信息的流向、处理和存储这4种元素描述系统需求，建立应用系统的功能模型。具体的建 模过程及步骤如下：
（1）明确目标，确定系统范围。首先要明确目标系统的功能需求，并将用户对目标系统的功能 需求完整、准确、一致地描述出来，然后确定模型要描述的问题域。虽然在建模过程中这些内容是 逐步细化的，但必须自始至终保持一致、清晰和准确。
（2）建立顶层DFD图。顶层DFD图表达和描述了将要实现的系统的主要功能，同时也确定了整 个模型的内外关系，表达了系统的边界及范围，也构成了进一步分解的基础。
（3）构建第一层DFD分解图。根据应用系统的逻辑功能，把顶层DFD图中的处理分解成多个更 细化的处理。
（4）开发DFD层次结构图。对第一层DFD分解图中的每个处理框做进一步分解，在分解图中要 列出所有的处理及其相关信息，并要注意分解图中的处理与信息包括父图中的全部内容。分解可采 用以下原则：保持均匀的模型深度；按困难程度进行选择；如果一个处理难以确切命名，可以考虑 对它重新分解。
（5）检查确认DFD图。按照规则检查和确定DFD图， 以确保构建的DFD模型是正确的、一致 的，且满足要求。具体规则包括：父图中描述过的数据流必须要在相应的子图中出现，一个处理至 少有一个输入流和一个输出流，一个存储必定有流入的数据流和流出的数据流，一个数据流至少有 一端是处理端，模型图中表达和描述的信息是全面的、完整的、正确的和一致的。
经过以上过程与步骤后，顶层图被逐层细化，同时也把面向问题的术语逐渐转化为面向现实的 解法，并得到最终的DFD层次结构图。层次结构图中的上一层是下一层的抽象，下一层是上一层的 求精和细化，而最后一层中的每个处理都是面向一个具体的描述，即一个处理模块仅描述和解决一 个问题。
2）数据字典的应用
数据字典（Data Dictionary）是一种用户可以访问的记录数据库和应用程序元数据的目录。数 据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述，其目的 是对数据流图中的各个元素做出详细的说明。简而言之，数据字典是描述数据的信息集合，是对系 统中使用的所有数据元素定义的集合。
数据字典最重要的作用是作为分析阶段的工具。任何字典最重要的用途都是供人查询，在结构 化分析中，数据字典的作用是给数据流图上的每个元素加以定义和说明。换句话说，数据流图上所 有元素的定义和解释的文字集合就是数据字典。数据字典中建立的严密一致的定义，有助于改进分 析员和用户的通信与交互。数据字典主要包括数据项、数据结构、数据流、数据存储、处理过程等 几个部分。
●数据项：数据流图中数据块的数据结构中的数据项说明。数据项是不可再分的数据单位。对 数据项的描述通常包括数据项名、数据项含义说明、别名、数据类型、长度、取值范围、取值含义 及与其他数据项的逻辑关系等。其中，“取值范围 ”“与其他数据项的逻辑关系 ”定义了数据的完 整性约束条件，是设计数据检验功能的依据。若干个数据项可以组成一个数据结构。
●数据结构：数据流图中数据块的数据结构说明。数据结构反映了数据之间的组合关系。一个 数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构 混合组成。对数据结构的描述通常包括数据结构名、含义说明和组成（数据项或数据结构）等。
●数据流：数据流图中流线的说明。数据流是数据结构在系统内传输的路径。对数据流的描述 通常包括数据流名、说明、数据流来源、数据流去向、组成（数据结构）、平均流量、高峰期流量 等。其中，“数据流来源 ”说明该数据流来自哪个过程，即数据的来源； “数据流去向 ”说明该数 据流将到哪个过程去，即数据的去向； “平均流量 ”是指在单位时间（每天、每周、每月等）里的 传输次数； “高峰期流量 ”则是指在高峰时期的数据流量。
●数据存储：数据流图中数据块的存储特性说明。数据存储是数据结构停留或保存的地方，也 是数据流的来源和去向之一。对数据存储的描述通常包括数据存储名、说明、编号、流入的数据流、流出的数据流、组成（数据结构）、数据量、存取方式等。其中，“数据量 ”是指每次存取多 少数据，每天（或每小时、每周等）存取几次等信息； “存取方式 ”指出是批处理还是联机处理， 是检索还是更新，是顺序检索还是随机检索等； “流入的数据流 ”要指出其来源；“流出的数据流 ”要指出其去向。
处理过程：数据流图中功能块的说明。数据字典中只需要描述处理过程的说明性信息，通常包 括处理过程名、说明、输入（数据流）、输出（数据流）、处理（简要说明）等。其中，“简要说 明 ”中主要说明该处理过程的功能及处理要求。功能是指该处理过程用来做什么（并不是怎样做）；处理要求包括处理频度要求（如单位时间里处理多少事务、多少数据量）和响应时间要求 等，这些处理要求是后续物理设计的输入及性能评价的标准。
2.面向对象分析
面向对象的分析（Object-Oriented Analysis ，OOA）方法能正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成 的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细 说明。
面向对象分析与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对 00方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。OOA模型由5 个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象、标识结构、定义 主题、定义属性和定义服务）组成。在这种方法中定义了两种对象类之间的结构，分别是分类结构 和组装结构。分类结构就是所谓的一般与特殊的关系；组装结类构则反映了对象之间的整体与部分 的关系。
1）OOA的基本原则
OOA的基本原则主要包括抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制和行 为分析。
●抽象：是从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征。抽象是形 成概念的必要手段。抽象是面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据抽 象两个方面。过程抽象是指任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一 的实体，尽管实际上它可能是由一系列更低级的操作完成的。数据抽象是根据施加于数据之上的操 作来定义数据类型，并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则，它强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（对象），对象的外部只 需要知道它做什么，而不必知道它如何做。
●封装：把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。 这个概念也经常用于从外部隐藏程序单元的内部表示。（ 中22下广）
●继承：特殊类的对象拥有其对应的一般类的全部属性与服务，称作特殊类对一般类的继承。 在OOA中运用继承原则，在特殊类中不再重复地定义一般类中已定义的内容，但是在语义上，特 殊类却自动地、隐含地拥有一般类（以及所有更上层的一般类） 中定义的全部属性和服务。继承原 则的好处是能够使系统模型比较简练、清晰。
●分类：把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则 实际上是抽象原则运用于对象描述时的一种表现形式。（补充：将实体的属性（数据）和操作（函 数）封装在一起）（ 中20下）
●聚合：又称组装，其原则是把一个复杂的事物看成若干比较简单的事物的组装体，从而简化 对复杂事物的描述。
●关联：关联是人类思考问题时经常运用的思想方法，即通过一个事物联想到另外的事物。能 使人发生联想的原因是事物之间确实存在着某些联系。
●消息通信：这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取 对象内部的属性。通过消息进行通信是由于封装原则而引起的。在OOA中要求用消息连接表示出 对象之间的动态联系。
●粒度控制：一般来讲，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又 能洞察秋毫。因此需要控制自己的视野，即考虑全局时，注意其大的组成部分，暂时不考虑具体的 细节，考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则。
●行为分析：现实世界中事物的行为是复杂的， 由大量的事物所构成的问题域中，各种行为往 往相互依赖、相互交织。
2）OOA的基本步骤
OOA大致遵循如下5个基本步骤：
●确定对象和类：这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现 实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个 类中建立一个新对象的描述。
●确定结构：结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体- 部分结构反映整体和局部之间的关系。
●确定主题：主题是指事物的总体概貌和总体分析模型。
●确定属性：属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对 象的存储中指定。
●确定方法：方法是在收到消息后必须进行的一些处理方法，即方法要在图中定义，并在对象 的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择的方法本身都是隐含 的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。
5.2.5需求规格说明书
软件需求规格说明书（Software Requirement Specification ，SRS）是在需求分析阶段需要完成 的文档，是软件需求分析的最终结果，是确保每个要求得以满足所使用的方法。编制该文档的目的 是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。 SRS是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应该缺少。
在国家标准《计算机软件文档编制规范》（GB/T8567）中，提供了一个SRS的文档模板和编写 指南，其中规定SRS应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。
（1）范围：包括SRS适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号；简述SRS适用的系统和软件的用途，描述系统和软件的一般特性；概述系统 开发、运行和维护的历史；标识项目的投资方、需方、用户、承建方和支持机构；标识当前和计划 的运行现场；列出其他有关的文档；概述SRS的用途和内容，并描述与其使用有关的保密性和私密 性的要求；说明编写SRS所依据的基础。
（2）引用文件：列出SRS中引用的所有文档的编号、标题、修订版本和日期，还应标识不能通 过正常的供货渠道获得的所有文档的来源。
（3）需求：这一部分是SRS的主体部分，详细描述软件需求。具体可以分为以下项目：所需的 状态和方式、需求概述、需求规格、软件配置项能力需求、软件配置项外部接口需求、软件配置项 内部接口需求、适应性需求、保密性和私密性需求、软件配置项环境需求、计算机资源需求（包括 硬件需求、硬件资源利用需求、软件需求和通信需求）、软件质量因素、设计和实现约束、数据、 操作、故障处理、算法说明、有关人员需求、有关培训需求、有关后勤需求、包装需求和其他需求， 以及需求的优先次序和关键程度。
（4）合格性规定：这一部分定义一组合格性的方法，对于第（3）部分中的每个需求指定所使 用的方法， 以确保需求得到满足。合格性方法包括演示、测试、分析、审查和特殊的合格性方法 （例如，专用工具、技术、过程、设施和验收限制等）。
（5）需求可追踪性：这一部分包括从SRS中每个软件配置项的需求到其涉及的系统（或子系 统）需求的双向可追踪性。
（6） 尚未解决的问题：如果有必要，可以在这一部分说明软件需求中尚未解决的遗留问题。
（7）注解：包含有助于理解SRS的一般信息（例如，背景信息、词汇表、原理等）。这一部分 应包含理解SRS所需要的术语和定义，所有缩略语和它们在SRS中的含义的字母序列表。
（8）附录：提供那些为便于维护SRS而单独编排的信息（例如，图表、分类数据等） 。为便于 处理，附录可以单独装订成册，按字母顺序编排。
另外，国家标准《计算机软件需求规格说明规范》（GB/T9385）中也给出了一个详细的SRS写作大纲，可以作为SRS写作的参考之用。
资深软件工程师都知道，当以SRS为基础进行后续开发工作时，如果在开发后期或在交付系统 之后才发现需求存在问题，这时修补需求错误就需要做大量的工作。相对而言，在系统分析阶段， 检测SRS中的错误所采取的任何措施都将节省相当多的时间和资金。因此，有必要对于SRS的正确 性进行验证，以确保需求符合良好特征。需求验证也称为需求确认，其活动需要确定的内容包括：
●SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；
●SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的；
●需求是完整的和高质量的；
● 需求的表示在所有地方都是一致的；
●需求为继续进行系统设计、实现和测试提供了足够的基础。
在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进 行技术评审，SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为 项目干系人提供在需求问题上达成共识的方法。需求的遗漏和错误具有很强的隐蔽性，仅仅通过阅 读SRS ，通常很难想象在特定环境下系统的行为。只有在业务需求基本明确、用户需求部分确定 时，同步进行需求测试的情况下，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这 些问题。
5.2.6需求变更
在当前的软件开发过程中，需求变更已经成为一种常态。需求变更的原因有很多种，可能是需 求获取不完整，存在遗漏的需求，可能是对需求的理解产生了误差，也可能是业务变化导致了需求 的变化等。一些需求的改进是合理的且不可避免的，要使得软件需求完全不变更基本上是不可能 的。但毫无控制的变更会导致项目陷入混乱，不能按进度完成或者软件质量无法保证。
事实上，迟到的需求变更会对已进行的工作产生非常大的影响。如果不控制变更的影响范围， 在项目开发过程中持续不断地采纳新功能，不断地调整资源、进度或者质量标准是极为有害的。如 果每一个建议的需求变更都采用，该项目将有可能永远不能完成。软件需求文档应该精确描述要交 付的产品与服务，这是一个基本的原则。为了使开发组织能够严格控制软件项目，应该确保做到仔 细评估已建议的变更、挑选合适的人选对变更做出判定、变更应及时通知所有相关人员、项目要按 一定的程序来采纳需求变更，以实现对变更的过程和状态进行控制。
1）变更控制过程
变更控制过程用来跟踪已建议变更的状态，以确保已建议的变更不会丢失或疏忽。一旦确定了 需求基线，应该使所有已建议的变更都遵循变更控制过程。需求变更管理过程如图5-1所示。
●问题分析和变更描述：当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它 的有效性，从而产生一个更明确的需求变更提议。
●变更分析和成本计算；当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变 更成本计算应该包括该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工 作成本。一旦分析完成并且被确认，应该采取是否执行这一变更的决策。
●变更实现：当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相 应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新做对应的需求分析、 设计和实现等步骤；在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。
变更控制过程并不是给变更设置障碍。相反地，它是一个渠道和过滤器，通过它可以确保采纳 最合适的变更，使变更产生的负面影响降到最低。
2 ）变更策略
控制需求变更与项目其他配置的管理决策有着密切的联系。项目管理应该达成一个策略，用来 描述如何处理需求变更，而且策略应具有现实可行性。常见的需求变更策略主要包括：
●所有需求变更必须遵循变更控制过程；
●对于未获得批准的变更，不应该做设计和实现工作；
●应该由项目变更控制委员会决定实现哪些变更；
●项目风险承担者应该能够了解变更的内容；
●绝不能从项目配置库中删除或者修改变更请求的原始文档：
●每一个集成的需求变更必须能跟踪到一个经核准的变更请求。
目前存在很多问题跟踪工具，这些工具用来收集、存储和管理需求变更。 问题跟踪工具也可以 随时按变更状态分类报告变更请求的数目和实现情况等。
3）变更控制委员会
变更控制委员会（Change Control Board ，CCB）是项目所有者权益代表，负责裁定接受哪些变 更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案 （高21上）。变更控制委员会可能包括如下方面的代表：
●产品或计划管理部门；
●项目管理部门；
●开发部门；
●测试或质量保证部门；
●市场部或客户代表；
●用户文档的编制部门；
●技术支持部门；
●桌面或用户服务支持部门；
●配置管理部门。
变更控制委员会应该有一个总则，用于描述变更控制委员会的目的、管理范围、成员构成、做 出决策的过程及操作步骤。总则也应该说明举行会议的频度和事由等。管理范围描述该委员会能做 什么样的决策，以及哪一类决策应上报到高一级的委员会。过程及操作步骤主要包括制定决策、交 流情况和重新协商约定等。
●制定决策。制定决策过程的描述应确认：①变更控制委员会必须到会的人数或做出有效决定 必须出席的人数；②决策的方法，例如投票、一致通过或其他机制；③变更控制委员会主席是否可 以否决该集体的决定等。变更控制委员会应该对每个变更权衡利弊后做出决定： “利 ”包括节省的 资金或额外的收入、增强的客户满意度、竞争优势、减少上市时间等：“弊 ”是指接受变更后产生 的负面影响，包括增加的开发费用、推迟的交付日期、产品质量的下降、减少的功能、用户不满意 度等。
●交流情况。一旦变更控制委员会做出决策，相应的人员应及时更新请求的状态。
●重新协商约定。变更总是有代价的，即使拒绝的变更也因为决策行为（提交、评估、决策）
而耗费了资源。当项目接受了重要的需求变更时，为了适应变更情况，要与管理部门和客户重新协 商约定。协商的内容可能包括推迟交付时间、要求增加人手、推迟实现尚未实现的较低优先级的需 求，或者质量上进行调整等。
5.2.7需求跟踪
需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他需求、体系结构、 其他设计部件、源代码模块、测试、帮助文件和文档等，是要在整个项目的工件之间形成水平可追 踪性。跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必需的工作。
需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与 维护“需求一设计一编程—测试 ”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有 正向跟踪和逆向跟踪两种方式。
●正向跟踪：检查SRS中的每个需求是否都能在后继工作成果中找到对应点；
●逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪 ”。不论采用何种跟踪方式，都要建立与维护需求跟踪 矩阵（表格） 。需求跟踪矩阵保存了需求与后继工作成果的对应关系。跟踪能力是优秀SRS的一个 特征，为了实现可跟踪能力，必须统一地标识出每一个需求， 以便能明确地进行查阅。需求跟踪是 一个要求手工操作且劳动强度很大的任务，需要组织提供支持。随着系统开发的进行和维护的执 行，要保持关联信息与实际一致。跟踪能力信息一旦过时，可能再也不会重建它。在实际项目中， 往往采用专门的配置管理工具来实现需求跟踪。
1 #include "stdio.h"
2 void main()
3 {
4 int time;
5 for (time=1;time<=10;time++)
6 printf("%d、喜欢的帮忙点赞收藏加关注哦！\n",time);
7 }
