软件工程学习篇1：需求工程

软件的需求分析是软件生命周期的基础，也是决定性的一步。经过项目经验表明，用户对自身将要开发的系统也并不是完全理解，他们对需求目标的陈述也往往带有主观片面性、模糊性、不一致性，甚至还会出现错误。需求分析是一个往复迭代的过程，是对用户需求不断认识和逐步细化的过程

1.1 软件需求的基本概念

​ 需求分析是准确回答：“系统必须做什么？”的问题，在这个阶段我们不需要知道系统如何实现，我们只需要知道系统必须要完成的任务是什么，用户的操作流程是什么？有什么约束条件？

1.1.1 需求分析的任务

​ 定义软件的使用领域和必须满足的约束条件；确定系统功能、性能、领域等内容；建立功能模型、数据模型和行为模型。

1. 确定系统将要实现的各项要求
   • 系统中最主要最基本的就是功能需求，是用户体验中最重要的部分。
2. 数据分析
   • 对于很多项目从本质上来讲还是一个信息系统管理项目，数据从哪来，到哪里去，系统内部如何操作和转换这些数据，都需要数据分析过程。
3. 定义逻辑模型
   • 将实际问题转化为信息域问题。

1.1.2 需求分析内容

​ 需求分析的内容通常分为功能需求、性能需求、领域需求和其他需求。

1. 功能需求
   • 功能需求描述系统提供的服务和在特定条件下的行为；通过功能需求分析，划分出系统必须完成的所有功能。
2. 性能需求
   • 性能需求规定了软件系统必须满足在时间上或者空间上的约束。
3. 领域需求
   • 对需求中的功能或者数据在领域上需要特别的实现。
4. 其他需求
   • 其他需求是与软件系统有关的外在约束，例如法律需求、道德需求、外部数据交换需求等。

1.1.3 可行性分析

​ 可行性分析是需求分析的第一个阶段，他力求用最小的代价、在尽可能短的时间里面确定问题能否解决。它包含如下4点：

1. 经济可能性：系统所带来的经济效益能超过开发成本吗？
2. 技术可行性：现有的技术能实现这个系统吗？
3. 操作可行性：系统的操作方式符合用户操作流程和方式吗？
4. 法律可能性：系统的开发过程和使用符合当前法律吗？

1.2 需求工程的过程

1.2.1 需求工程的活动

​ 需求工程在进行可能性研究之后，通过需求获取、需求分析与建模、需求评审的迭代过程，对需求工程的过程不断的迭代，最后得到需求规格说明。

1. 需求获取
   • 通过获取技术，得到用自然语言描述的问题陈述和功能陈述。
2. 需求分析与建模
   • 以需求获取文档为基础，逐步细化需求中的软件功能，将目标系统的物理模型转化为详细逻辑模型，形成最终的软件需求规格说明和初步的用户手册
3. 需求评审
   • 作为准备提交的软件需求规格说明，需要进行技术审查和管理审查。

1.2.2 需求工程的管理

​ 需求管理贯穿整个需求工程的全部过程。在需求工程管理过程中存在两大难题：一是需求确认困难；二是需求不断变更

1.3 需求获取技术

​ 需求获取是需求分析的前提，没有完整的、正确的获取用户的需求，就不能保证软件产品的质量，其获取技术包括：

1. 会谈与会议
2. 问卷调查
3. 面向用例的场景分析
4. 快速原型技术

1.4 结构化需求分析和建模

​ 结构化需求分析的核心是数据。将分析、设计和实现中涉及的术语、概念定义在数据字典中，围绕数据字典完成功能模型、数据模型和行为模型的建构化建模过程。

1.4.1 面相数据的数据建模

​ 数据建模回答软件开发过程中与各部分设计有关的所有数据对象。数据对象包括实体、实体属性和实体间关系。数据建模需要回答以下的的几个问题：

1. 系统中有哪些数据对象？
2. 数据对象具有哪些属性？
3. 数据对象间有什么关系？
4. 数据对象分别处于系统的哪些功能或流程中？

1.4.2 ER图

实体关系图(ER图)，是数据建模的一种工具，用于描述数据库中的数据及其关系。

1. 实体：
   • 实体是数据库中的一个对象，可以是一个人、地方、事件或事物等，具有独立存在的意义。
   • 在ER图中，实体通常用矩形表示，矩形内写上实体的名称。
2. 属性：
   • 属性是实体的特征或性质，用于描述实体的具体信息。
   • 在ER图中，属性通常用椭圆表示，并通过线条与对应的实体相连。
   • 属性可以分为以下几类：
     • 简单属性（Simple Attribute）： 不可再分的基本属性。
     • 复合属性（Composite Attribute）： 可以进一步分解成多个简单属性。
     • 多值属性（Multivalued Attribute）： 可以有多个值的属性，用双椭圆表示。
     • 派生属性（Derived Attribute）： 可以从其他属性计算得出的属性，用虚线椭圆表示。
3. 关系（Relationship）：
   • 关系是实体之间的关联或连接，表示两个或多个实体之间的逻辑联系。
   • 在ER图中，关系通常用菱形表示，并通过线条与相关的实体相连。

关系的类型

1. 一对一关系（One-to-One）：
   • 一个实体实例与另一个实体实例之间有且只有一个对应关系。
   • 例如，一个人只能拥有一个身份证号码，一个身份证号码只能对应一个人。
2. 一对多关系（One-to-Many）：
   • 一个实体实例可以与多个其他实体实例相关联，而这些其他实体实例只能与一个该实体实例相关联。
   • 例如，一个部门可以有多个员工，但一个员工只能属于一个部门。
3. 多对多关系（Many-to-Many）：
   • 一个实体实例可以与多个其他实体实例相关联，而这些其他实体实例也可以与多个该实体实例相关联。
   • 例如，学生可以选修多门课程，一门课程也可以被多名学生选修。

ER图的作用

1. 可视化数据库设计： ER图提供了一个图形化的工具，可以直观地展示数据库结构，使设计人员和开发人员更容易理解和交流。
2. 数据库规范化： ER图有助于识别和消除数据库中的冗余数据，提高数据的一致性和完整性。
3. 生成数据库结构： ER图可以作为数据库设计的蓝图，帮助生成数据库的表结构、字段和约束等。
4. 需求分析： 在数据库设计的早期阶段，通过ER图可以有效地进行需求分析，确保数据库设计满足用户的需求。

1.4.3 面相数据流的功能建模

​ 数据流图(DFD)是结构化建模中最流行的功能建模工具，它描述了从数据输入、数据转化再到数据输出的全过程。

外部实体：

• 外部实体是系统外部与系统进行交互的人、组织或系统，通常用矩形表示。
• 外部实体是系统的输入源或输出目的地。

数据流：

• 数据流是数据在系统中的传递路径，表示数据在外部实体、处理过程和数据存储之间的流动，通常用箭头表示。
• 数据流的箭头指向表明数据的流向，箭头旁边的标签描述数据的内容。

处理过程：

• 处理过程是对输入数据进行操作、转换、计算等处理的活动，通常用圆形或椭圆形表示。
• 每个处理过程都有一个唯一的编号，并标明处理过程的名称。

数据存储：

• 数据存储是系统中存放数据的地方，表示为数据在系统内的暂时或永久存储，通常用两个平行线表示。
• 数据存储的名称描述存储的数据内容。
  

​ DFD分解可以用来表示所有抽象级别的系统功能，随着系统功能和信息的逐步增加，DFD通过分解来逐层细化用户需求。DFD通常分为多个层次，从高层次的概览到低层次的详细描述：

1. 上下文图（Context Diagram）：
   • 上下文图是最高层次的DFD，显示系统的边界及其与外部实体的交互。
   • 它只包含一个处理过程，代表整个系统，并展示系统与外部实体之间的主要数据流。
2. 一级图（Level 1 Diagram）：
   • 一级图是对上下文图中系统的详细分解，展示系统内部的主要子过程及其相互关系。
   • 一级图进一步分解为多个具体的处理过程，显示更详细的数据流和数据存储。
3. 进一步分解：
   • 根据系统的复杂性，可以将一级图中的子过程进一步分解为二级图、三级图等，以展示更详细的处理过程。

1.5 数据字典

数据字典是关于数据库系统中数据的描述、定义和规范的集合。它是数据模型的重要组成部分，用于管理和定义数据库中的数据元素及其关系。

1.5.1 数据字典的主要内容

1. 数据元素（Data Elements）：
   • 名称（Name）： 数据元素的唯一标识。
   • 别名（Alias）： 数据元素的其他名称或简称。
   • 描述（Description）： 数据元素的详细描述，说明其含义和用途。
   • 数据类型（Data Type）： 数据元素的数据类型，如整数、字符、日期等。
   • 长度（Length）： 数据元素的最大长度。
   • 取值范围（Value Range）： 数据元素的有效取值范围或列表。
   • 缺省值（Default Value）： 数据元素的默认值。
2. 数据结构（Data Structures）：
   • 名称（Name）： 数据结构的唯一标识。
   • 描述（Description）： 数据结构的详细描述。
   • 组成元素（Components）： 数据结构包含的数据元素及其关系。
3. 数据存储（Data Stores）：
   • 名称（Name）： 数据存储的唯一标识。
   • 描述（Description）： 数据存储的详细描述。
   • 数据结构（Data Structure）： 数据存储中包含的数据结构。
   • 存储介质（Storage Medium）： 数据存储的物理存储介质，如磁盘、内存等。
4. 数据流（Data Flows）：
   • 名称（Name）： 数据流的唯一标识。
   • 描述（Description）： 数据流的详细描述。
   • 源（Source）： 数据流的起点。
   • 目的地（Destination）： 数据流的终点。
   • 数据结构（Data Structure）： 数据流中包含的数据结构。
5. 处理过程（Processes）：
   • 名称（Name）： 处理过程的唯一标识。
   • 描述（Description）： 处理过程的详细描述。
   • 输入数据流（Input Data Flows）： 处理过程的输入数据流。
   • 输出数据流（Output Data Flows）： 处理过程的输出数据流。
   • 处理规则（Processing Rules）： 处理过程的具体规则和算法。

1.5.2 数据字典的作用

1. 数据标准化： 数据字典提供了数据元素的统一定义，确保了不同系统和应用之间的数据一致性和兼容性。
2. 系统开发支持： 数据字典为系统开发人员提供了详细的数据描述和规范，有助于系统的设计、开发和维护。
3. 数据管理： 数据字典帮助数据库管理员有效地管理和维护数据库，确保数据的完整性和准确性。
4. 用户指南： 数据字典为终端用户提供了数据的详细信息，帮助用户理解和使用系统中的数据。

1.6 需求评审

需求评审是软件开发过程中一个关键的阶段，旨在确保项目的需求明确、准确、一致，并且满足所有利益相关者的期望。需求评审通常包括需求文档的检查、讨论和确认，以便在项目开发的早期发现和解决潜在问题，从而减少后续开发阶段的返工和错误。

1.6.1 需求评审的目的

1. 验证需求的正确性： 确保需求描述清晰、准确，反映用户的真实需求。
2. 确保需求的一致性： 检查需求之间是否存在矛盾或冲突，确保所有需求协调一致。
3. 确认需求的可行性： 评估需求是否在技术上可行，是否在项目的时间和预算范围内可以实现。
4. 发现遗漏的需求： 确保所有必要的需求都已被捕获和记录，避免遗漏关键功能。
5. 改进需求文档： 提供反馈和建议，改进需求文档的质量，使其更加全面和易于理解。

1.6.2 需求评审的步骤

1. 准备阶段：
   • 组建评审小组： 评审小组通常包括需求分析师、开发人员、测试人员、项目经理和用户代表等。
   • 分发需求文档： 在评审会议之前，将需求文档分发给所有评审小组成员，确保他们有足够的时间阅读和准备反馈。
2. 评审会议：
   • 介绍背景和目标： 需求分析师或项目经理介绍项目的背景、目标和需求文档的结构。
   • 逐条讨论需求： 按照需求文档的顺序逐条讨论每个需求，评审小组成员提出问题、反馈和建议。
   • 记录问题和建议： 将评审过程中发现的问题和提出的建议记录下来，以便后续处理。
3. 评审结果整理：
   • 分类和分析问题： 将评审过程中记录的问题分类，分析每个问题的原因和影响。
   • 制定解决方案： 针对发现的问题，制定相应的解决方案或改进措施。
   • 更新需求文档： 根据评审结果，修改和更新需求文档，确保其准确性和完整性。
4. 评审结果确认：
   • 确认修改： 将更新后的需求文档分发给评审小组成员，确认修改是否符合评审要求。
   • 批准需求文档： 在评审小组成员一致同意后，正式批准需求文档，作为后续开发工作的基础。

1.6.3 需求评审的注意事项

1. 确保利益相关者的参与： 需求评审应包括所有主要利益相关者的参与，以确保需求的全面性和准确性。
2. 保持开放的沟通： 评审过程中应鼓励开放和诚实的沟通，确保所有问题和建议都能够被充分讨论和处理。
3. 注重细节： 需求评审应关注需求文档中的每个细节，确保没有遗漏或模糊之处。
4. 记录和跟踪： 评审过程中发现的问题和提出的建议应详细记录，并在后续工作中进行跟踪和落实。