5.1 软件工程定义
软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、 提高软件质量、降低软件成本。
5.2 软件需求
软件需求 是指用户对系统在功能、行为、性能、设计约束等方面的期望。根据IEEE的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
5.2.1 需求的层次
软件需求 就是系统必须完成的事和必须具备的品质。需求是多层次的，包括业务需求、 用户需求和系统需求，这3个不同层次从目标到具体，从整体到局部，从概念到细节。
1、业务需求：指反映组织机构或用户对系统、产品高层次的目标要求，从总体上描述了为什么要达到某种效应，组织希望达到什么目标。通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。
2、用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务和想要达到的结果，这构成了用户原始需求文档的内容
3、系统需求：是从系统的角度来说明软件的需求包括功能需求、非功能需求和约束等。
5.2.2 质量功能部署
质量功能部署 (QFD)，即通过多种角度对产品的特点进行描述，从而反映产品功能，是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为3类，分别是常规需求、期望需求和意外需求。
①常规需求。用户认为系统应该做到的功能或性能，实现得越多，用户会越满意。
②期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
③意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性)，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。
5.2.3 需求获取
需求获取是确定和理解不同的项目干系人对系统的需求和约束的过程。
常见的需求获取方法 包括用户访谈、问卷调查、采样、 情节串联板、联合需求计划等。
5.2.4 需求分析
一 个好的需求 应该具有无二义性、完整性、一致性、可测试性、确定性、可
跟踪性、正确性、必要性等特性。因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
1.结构化分析
结构化分析(SA)方法给出一组帮助系统分析人员产生功能规约的原理与技术，其建立模型的核心是数据字典。围绕这个核心，有3个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。
结构化分析通常包含以下几个步骤：
①分析业务情况，做出反映当前物理模型的DFD；
②推导出等价的逻辑模型的DFD；
③设计新的逻辑系统，生成数据字典和基元描述；
④建立人机接口，提出可供选择的目标系统物理模型的DFD；
⑤确定各种方案的成本和风险等级，据此对各种方案进行分析；
⑥选择一种方案；
⑦建立完整的需求规约。
1)DFD需求建模方法
DFD需求建模方法 也称为过程建模和功能建模方法。DFD建模方法的核心是数据流，从应用系统的数据流着手，以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流。
DFD方法由以下4种基本元素 (模型对象)组成：数据流、处理/加工、数据存储和外部项。
建立DFD图的目的 是描述系统的功能需求。
具体的建模过程及步骤如下：
（1）明确目标，确定系统范围。
（2）建立顶层DFD图。
（3）构建第一层DFD分解图。
（4）开发DFD层次结构图。
（5）检查确认DFD图。
2)数据字典的应用
数据字典 (Data Dictionary) 是一种用户可以访问的记录数据库和应用程序元数据的目录。
数据字典最重要的作用 是作为分析阶段的工具。任何字典最重要的用途都是供人查询，在结构化分析中，数据字典的作用是给数据流图上的每个元素加以定义和说明。
数据字典 主要包括数据项、数据结构、数据流、数据存储、处理过程等几个部分。
2.面向对象分析
面向对象分析与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对00A方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。
OOA模型由5个层次 (主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。
在这种方法中定义了两种对象类之间的结构，分别是分类结构和组装结构。
****·****分类结构就是所谓的一般与特殊的关系。
****·****组装结构则反映了对象之间的整体与部分的关系。
- 00A的基本原则
2）OOA的基本步骤：
①确定对象和类；
②确定结构；
③确定主题；
④确定属性；
⑤确定方法。
5.2.5 需求规格说明书
软件需求规格说明书 (SRS)是在需求分析阶段需要完成的文档，是软件需求分析的最终结果，是确保每个要求得以满足所使用的方法。SRS是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应该缺少。
SRS 应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。
一般通过需求评审和需求测试工作来对需求进行验证。
5.2.6 需求变更
需求变更的原因有很多种，可能是需求获取不完整，存在遗漏的需求，可能是对需求的理解产生了误差，也可能是业务变化导致了需求的变化等。
1)变更控制过程
变更控制过程 用来跟踪已建议变更的状态，以确保已建议的变更不会丢失或疏忽。一旦确定了需求基线，应该使所有已建议的变更都遵循变更控制过程。
需求变更管理过程：
·问题分析和变更描述：当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
·变更分析和成本计算：当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该采取是否执行这一变更的决策。
·变更实现：当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新做对应的需求分析、设计和实现等步骤，在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。
变更控制过程 并不是给变更设置障碍。相反地，它是一个渠道和过滤器通过它可以确保采纳最合适的变更，使变更产生的负面影响降到最低。
2)变更策略
常见的需求变更策略主要包括：
·所有需求变更必须遵循变更控制过程；
·对于未获得批准的变更，不应该做设计和实现工作；
·应该由项目变更控制委员会决定实现哪些变更；
·项目风险承担者应该能够了解变更的内容；
·绝不能从项目配置库中删除或者修改变更请求的原始文档；
·每一个集成的需求变更必须能跟踪到一个经核准的变更请求。
3)变更控制委员会
变更控制委员会 (CCB)是项目所有者权益代表，负责裁定接受哪些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。
变更控制委员会可能包括如下方面的代表：
·产品或计划管理部门；
·项目管理部门；
·开发部门；
·测试或质量保证部门；
·市场部或客户代表；
·用户文档的编制部门；
·技术支持部门；
·桌面或用户服务支持部门；
·配置管理部门。
过程及操作步骤 主要包括制定决策、交流情况和重新协商约定等。
·制定决策。制定决策过程的描述应确认：
①变更控制委员会必须到会的人数或做出有效决定必须出席的人数；
②决策的方法，例如投票、一致通过或其他机制；
③变更控制委员会主席是否可以否决该集体的决定等。
·交流情况。一旦变更控制委员会做出决策，相应的人员应及时更新请求的状态。
·重新协商约定。协商的内容可能包括推迟交付时间、要求增加人手、推迟实现尚未实现的较低优先级的需求，或者质量上进行调整等。
5.2.7 需求跟踪
需求跟踪 提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的 是建立与维护"需求一设计一编程一测试"之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪 有正向跟踪和逆向跟踪两种方式。
·正向跟踪：检查SRS中的每个需求是否都能在后继工作成果中找到对应点；
·逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。
正向跟踪和逆向跟踪合称为"双向跟踪"。