软件工程 |需求获取

需求获取可能是最困难、最容易出错和沟通最密集的软件开发。只有通过有效的客户-开发者伙伴关系，它才能成功。需要知道用户真正需要什么。

需求启发活动：
需求获取包括后续活动。下面列出了其中的几个——

• 了解系统应用的整个领域。
• 必须了解系统将要应用的确切客户问题的细节。
• 系统与外部需求的交互。
• 详细调查用户需求。
• 定义系统开发的约束。

需求获取方法：
有许多需求获取方法。下面列出了其中的几个——

1. 采访
2. 头脑风暴会议
3. 促进应用规范技术（FAST）
4. 质量函数展开 (QFD)
5. 用例方法

所使用的启发技术的成功取决于分析师、开发人员、用户和相关客户的成熟度。

1. 面试：
进行访谈的目的是了解客户对软件的期望。
不可能采访每个利益相关者，因此根据他们的专业知识和可信度选择团体代表。

面试可能是开放式的或结构化的。

1. 在开放式访谈中，没有预先设定的议程。可能会询问上下文无关的问题来理解问题。
2. 在结构化面试中，准备了相当开放的问题议程。有时会为面试设计适当的问卷。

2. 头脑风暴会议：

• 这是一种集体技术
• 它旨在产生许多新想法，从而提供一个分享观点的平台
• 处理群体偏见和群体冲突需要训练有素的促进者。
• 每个想法都记录在案，以便每个人都可以看到。
• 最后，准备一份文件，其中包括需求列表及其优先级（如果可能）。

3. 促进应用规范技术：
它的目标是弥合期望差距——开发人员认为他们应该构建的内容与客户认为他们将获得的内容之间的差异。

为需求收集开发了一种面向团队的方法。
每位与会者都被要求列出一份物品清单，这些物品是——

1. 系统周围环境的一部分
2. 系统出品
3. 系统使用

每个参与者准备他/她的清单，然后组合不同的清单，消除多余的条目，将团队分成较小的子团队以开发小型规范，最后使用会议的所有输入写下规范草案。

4、质量函数展开：
在这种技术中，客户满意度是首要关注点，因此它强调对客户有价值的要求。
确定了 3 种类型的要求——

• 正常要求——
  在此与客户讨论所提议软件的目标和目的。示例 – 结果管理系统的正常要求可能是分数输入、结果计算等
• 预期要求——
  这些要求非常明显，客户无需明确说明。示例 – 防止未经授权的访问。
• 令人兴奋的要求——
  它包括超出客户期望的功能，并且在出现时被证明是非常令人满意的。示例——当检测到未经授权的访问时，它应该备份并关闭所有进程。

此过程涉及的主要步骤是 -

1. 确定所有利益相关者，例如。用户、开发者、客户等
2. 列出客户的所有要求。
3. 为每个要求分配一个表示重要程度的值。
4. 最后，要求的最终清单分类为 -
   • 有可能实现
   • 它应该被推迟和它的原因
   • 这是不可能实现的，应该放弃

5.用例方法：
这种技术结合了文本和图片，以更好地理解需求。
用例描述了系统的“什么”，而不是“如何”。因此，它们仅给出系统的功能视图。
用例设计的组件包括三个主要的东西——参与者、用例、用例图。

1. 演员——
   它是位于系统之外但以某种方式与之交互的外部代理。演员可能是人、机器等。它被表示为一个简笔画。演员可以是主要演员或次要演员。
   • 主要参与者——它需要系统的帮助才能实现目标。
   • 次要参与者——系统需要帮助的参与者。
2. 用例 -
   它们描述了参与者和系统之间的交互顺序。他们捕获谁（参与者）与系统做什么（交互）。一套完整的用例指定了使用系统的所有可能方式。
3. 用例图——
   用例图以图形方式表示参与者与系统交互时发生的情况。它捕获了系统的功能方面。
   • 简笔画用于代表演员。
   • 椭圆形用于表示用例。
   • 一条线用于表示参与者和用例之间的关系。

有关用例图的更多信息，请参阅 – 为项目设计用例