您的位置: 首页  >  文章  >  软件工程之需求工程

软件工程之需求工程

分类: 文章 • 2023-11-15 08:45:34

文章链接:https://codemouse.online/archives/2020-03-13-111624

需求工程概述

  • 需求获取:系统分析员与用户交流

    1. 观察分析:现有系统,任务
    2. 系统描述:限制范围,技术环境
    3. 导出列表:与系统有关的人员及特征,系统功能
    4. 应用场景:不同条件下,系统使用状况
    5. 任意原型:为定义需求开发

  • 需求分析与协商

    • 需求获取结束后，分析活动对需求进行分类组织，分析每个需求和其它需求的关系，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。

    • 在需求获取阶段，经常出现以下问题：

      1. 用户提出的要求超出软件系统可以实现的范围或实现能力；
      2. 不同的用户提出了相互冲突的需求

  • 系统建模

    • 建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。
    • 常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。

  • 需求规约

    • 软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
    • 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。

  • 需求验证

    • 作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。
    • 在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。

软件工程之需求工程

  • 需求管理
    • 需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。
    • 需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。

需求获取

  • 软件需求包括:

    1. 功能需求
    2. 性能需求
    3. 用户或人的因素
    4. 环境需求
    5. 界面需求
    6. 文档需求
    7. 数据需求
    8. 资源使用需求
    9. 安全保密要求
    10. 可靠性需求
    11. 软件成本消耗与开发进度需求
    12. 其他非功能性要求

  • 需求获取方法与策略

    1. 建立顺畅通信途径:保证能顺利地对问题进行分析。
      软件工程之需求工程

    2. 访谈调查

      • 通常采用折衷的方法，即适当地计划好面谈，不要过于详细，允许有一定的灵活性。

      • 一般按照如下原则进行准备：

        1. 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；

        2. 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；

        3. 提问和回答在汇总后应能够反映用户需求的全貌。

      • 举例

        软件工程之需求工程

    3. 观察用户操作流程

      • 到用户的实际工作环境
      • 了解用户实际的操作环境、过程和要求
      • 观察用户工作流程
      • 对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识

    4. 组成联合小组

      • 便利的应用规约技术(Facilitated Application Specification Techniques):
        打破用户和开发者界限，组成一个联合小组，发挥各自长处，共同负责项目推进，有助于增进解和协调
      • FAST基本原则
        1. 在中立地点举行由开发者和用户出席的会议
        2. 建立准备和参与会议的规则
        3. 建议一个足够正式的议程进行*交流
        4. 一个协调者来控制会议
        5. 使用一种定义机制
        6. 目标是标识问题提出解决方案要素商议不同的方法刻画出初步的需求
      • FAST会议步骤
        1. 初步访谈后，确定会议的时间地点
        2. 要求每个出席者会前列出一组围绕系统环境的对象的约束列表和性能标准列表
        3. 会议时每个成员提出单个列表后，创建组合的列表，开始讨论
        4. 分为更小的小组讨论
        5. 小规约完成后将列表提交给团队为需求分析和建模提供基础信息

    5. 用况(Use Case)

      • 创建用况模型的主要步骤：

        1. 确定谁会直接使用该系统，即执行者（Actor）

        2. 选取其中一个执行者

        3. 定义该执行者希望系统做什么，执行者希望系统作的每件事成为一个用况

        4. 对每件事来说，何时执行者使用系统，通常发生什么，为用况的基本过程

        5. 描述该用况的基本过程

需求分析、协商与建模

分析

  1. 能够表示理解问题的信息域

    • 信息内容:目标软件所有处理的信息集合
    • 信息流:数据和控制在系统中流动时的变化方式
    • 信息结构:各种数据和控制项的内部组织

  2. 能够定义软件将完成的功能

  3. 能够表示软件的行为

  4. 划分描述数据功能和行为的模型

  5. 分析过程该从要素信息移向细节信息

    • 问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。

    • 较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析

    • 分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分

      软件工程之需求工程

协商

  • 协商的过程是讨论需求冲突，找出每个人都满意的折衷方案 ，不是简单的逻辑或技术上的争论，要注意组织和行政方面的因素。

    1. 不一致的目标
    2. 责任丧失或转移
    3. 组织文化
    4. 组织管理态度和士气
    5. 部门差异

  • 通常会议是解决冲突最快的方式:开会

    参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员

  • 通常会议分三个阶段：叙述阶段,讨论阶段,决策阶段

建模

  • 在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做，目标软件的模型不应涉及软件实现细节
  • 三种分析方法:
    1. 面向数据流的结构化分析方法(重点)
    2. 面向数据结构的分析方法
    3. 面向对象的分析方法

需求规约与验证

规约原则

1．从现实中分离功能，即描述要“做什么”而不是“怎样实现”。
2．要求使用面向处理的规约语言，来定义一个行为模型，从而得到“做什么”的规约。
3．如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。
4．规约必须包括系统运行环境。
5．规约必须是一个认识模型，而不是设计或实现的模型。
6．规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。
7．规约必须允许不完备性并允许扩充。
8．规约必须局部化和松散耦合。

规约书写概述:

软件工程之需求工程

需求验证

  • 目的是要检验需求是否能够反映用户的意愿
  • 评审人员评审时往往需要检查以下内容：
    1. 系统定义的目标是否与用户的要求一致；
    2. 系统需求分析阶段提供的文档资料是否齐全；
    3. 被开发项目的数据流与数据结构是否确定且充足；
    4. 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
    5. 设计的约束条件或限制条件是否符合实际；
    6. 开发的技术风险是什么；
    7. 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。

需求管理

  • 正向跟踪：以用户需求为切入点，检查《需求规约》中的每个需求是否都在后继工作产品中找到对应点

  • 逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在《需求规约》中找到出处

相关推荐