软件工程|需求获取

需求引出 可能是最困难、最容易出错和最需要通信的软件开发。只有通过有效的客户-开发商合作关系，才能取得成功。需要知道用户真正需要什么。

需求获取活动： 需求获取包括后续活动。以下列出了其中的几项：

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

需求获取方法： 有许多需求获取方法。以下列出了其中的几项：

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. 用例图- 用例图以图形方式表示参与者与系统交互时发生的情况。它捕获了系统的功能方面。
   • 木棍是用来代表演员的。
   • 椭圆形用于表示用例。
   • 线条用于表示参与者和用例之间的关系。

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