本篇介绍软件工程、软件需求分析的基本概念和相关知识

一、软件工程

1、基本概念

（1）软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程；

（2）IEEE对软件工程的定义是：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。

2、目的

提高软件生产率、提高软件质量、降低软件成本。

3、软件工程由方法、工具和过程三个部分组成

（1）软件工程方法：是指完成软件工程项目的技术手段，它支持整个软件生命周期;

（2）软件工程工具：是人们在开发软件的活动中智力和体力的扩展与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成；

（3）软件工程过程：软件工程中的过程贯穿于软件开发的各个环节，管理人员在软件工程过程中，要对软件开发的质量、进度、成本进行评估、管理和控制，包括人员组织、计划跟踪与控制、成本估算、质量保证和配置管理等。

二、需求分析

1、软件需求的定义：

（1）软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望；

（2）IEEE对软件需求的定义是：用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

2、需求的层次

软件需求是多层次的，包括业务需求、用户需求和系统需求

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

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

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

3、质量功能部署

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

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

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

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

4、需求获取

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。

5、需求分析

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

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

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

6、软件需求规格说明书

软件需求规格说明书（Software Requirement Specification，SRS）是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS 是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。SRS内容包括：范围、引用文件、需求、合规性规定、需求可追踪性、尚未解决的问题、注解、附录等。

7、需求验证

需求验证也称为需求确认，主要确认以下方面内容：

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

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

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

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

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