注：本文重的需求探索确切的指Requirements Elicitation
本文信息来自geeksforgeeks的翻译和备注，以提供信息供参考。
又及，本文中的利益相关者 1，在本站点中，专业的术语为涉众。两者表示同一个概念：stackholder，只是利益相关者更口语化一些，这里保留利益相关者的翻译，如果使用SRSInsight的话，则需要注意他的专业性术语涉众。
需求探索是收集和定义软件系统需求的过程。需求探索的目标是确保软件开发过程基于对客户需求的清晰全面理解。本文将详细讨论需求探索。
1 什么是需求探索？
需求探索是从用户、客户和其他利益相关者那里调查和了解系统需求的过程。在软件工程中，需求探索可能是软件开发中最困难、最容易出错且沟通密集度最高的环节。
只有通过有效的客户-开发伙伴关系，需求探索才能成功。它需要了解用户的需求。
需求探索包括对软件系统需求的识别、收集、分析和细化。
需求探索是软件开发生命周期的关键部分，通常在项目初期进行。
需求探索涉及组织不同领域的利益相关者，包括企业主、最终用户和技术专家。
需求探索过程的输出是一组清晰、简洁且定义明确的需求，这些需求将作为软件系统设计和开发的基础。
需求探索之所以困难，是因为仅向用户和客户询问系统需求可能无法收集到所有相关需求，尤其是在安全性 2和可靠性方面。
访谈、调查、用户观察 3、研讨会、头脑风暴、用例、角色扮演和原型设计都是获取需求的方法。
2 需求探索的重要性
- 符合业务目标：需求探索过程确保软件开发工作与更广泛的公司目标和宗旨保持一致。了解业务背景有助于开发为公司创造价值的解决方案。
- 用户满意度：当最终用户参与需求探索过程时，更容易开发出满足他们需求和期望的软件。这会提高用户对成品的满意度和接受度。
- 节省时间和金钱：拥有精确且定义明确的规范有助于防止开发阶段的误解和返工。从而节省成本并确保项目按时完成。
- 合规性和法规要求：对于受监管行业的项目，需求探索对于确保软件符合适用的法律和规范至关重要。这在医疗、金融和航空航天等行业尤为重要。
- 可追溯性和文档化：整个软件开发过程中的可追溯性基于良好的需求文档 4。可追溯性通过确保软件的每个部分都能与特定需求关联，有助于测试、验证和维护。
3 需求探索活动
需求探索包括以下活动，其中一些列举如下：
- 了解系统应用的整体领域。
- 理解系统将要应用的具体客户问题的细节。
- 系统与外部需求的交互。
- 详细调查用户需求。
- 定义系统开发的约束条件。
4 需求探索方法
有几种需求探索方法，其中一些列举如下：
4.1 访谈
- 目标：了解客户对软件的期望。
- 实施方式：由于无法采访每个利益相关者，因此根据其专业知识和信誉选择各组的代表。访谈 5可以是开放式或结构化的。
- 开放式访谈：没有预设议程，可以提出无上下文问题以了解问题。
- 结构化访谈：准备一个包含相当开放式问题的议程，有时会设计专门的问卷。
4.2 头脑风暴会议
- 目标：这是一种群体技术，旨在产生大量新想法，为分享观点提供平台。
- 实施方式：需要一名训练有素的主持人来处理群体偏见和冲突。记录每个想法以便所有人可见。最后，编写一份文档，列出需求及其优先级 6（如有可能）。
4.3 促进式应用规范技术
- 目标：弥合期望差距——开发人员认为应构建的内容与客户认为将获得的内容之间的差异。开发一种团队导向的需求收集方法。
- 实施方式：要求每位参与者列出以下对象：
- 系统周围环境的一部分。
- 系统产生的。
- 系统使用的。 每个参与者准备自己的列表，然后合并不同的列表，消除重复项，将团队分成更小的子团队来制定迷你规范，最后根据会议的所有输入编写规范草案。
4.4 质量功能展开
- 目标：以客户满意度为首要关注点，因此强调对客户有价值的需求。
- 实施方式：识别三种类型的需求：
- 正常需求：与客户讨论拟议软件的目标和目的。例如，成绩管理系统的正常需求可能包括成绩录入、成绩计算等。
- 期望需求：这些需求非常明显，客户无需明确说明。例如，防止未经授权的访问。
- 兴奋需求：包括超出客户预期的功能，存在时会非常令人满意。例如，检测到未经授权的访问时，应备份并关闭所有进程。
4.5 用例方法
- 目标：结合文本和图片以更好地理解需求。
- 实施方式：用例描述系统的“是什么”，而不是“如何”。因此，它们仅提供系统的功能视图。
- 组件：用例设计包括三个主要部分——参与者、用例和用例图。
- 参与者：是位于系统外部但以某种方式与系统交互的外部代理。参与者可以是人、机器等，用简笔人物表示。参与者可以是主要参与者或次要参与者。
- 主要参与者：需要系统的帮助来实现目标。
- 次要参与者：系统需要其帮助的参与者。
- 用例：描述参与者与系统之间的交互顺序。它们捕获参与者（角色 7）与系统进行的交互（操作）。一整套用例规定了使用系统的所有可能方式。
- 用例图：用图形表示参与者与系统交互时发生的情况，捕获系统的功能方面。
- 用简笔人物表示参与者。
- 用椭圆表示用例。
- 用线条表示参与者与用例之间的关系。
- 参与者：是位于系统外部但以某种方式与系统交互的外部代理。参与者可以是人、机器等，用简笔人物表示。参与者可以是主要参与者或次要参与者。
- 组件：用例设计包括三个主要部分——参与者、用例和用例图。
5 需求探索步骤
需求探索的步骤如下：
- 识别所有利益相关者，例如用户、开发人员、客户等。
- 列出客户的所有需求。
- 为每个需求分配一个表示重要程度的值。
- 最终将需求列表分类为：
- 可以实现的。
- 应推迟并说明原因的。
- 无法实现应放弃的。
6 需求探索的特点
- 利益相关者参与：需求探索涉及与客户、最终用户、项目发起人和主题专家等利益相关者互动，以了解他们的需求。
- 信息收集：需求探索涉及收集有关待开发系统、其将支持的业务流程以及将使用它的最终用户的信息。
- 需求优先级 8排序：需求探索涉及根据需求对项目成功的重要性对其进行优先级排序。
- 需求文档化：需求探索涉及清晰、简洁地记录需求，以便开发团队易于理解和沟通。
- 验证和确认：需求探索涉及与利益相关者验证和确认需求，以确保它们准确反映其需求。
- 迭代过程：需求探索是一个迭代过程，涉及根据利益相关者的反馈不断细化和更新需求。
- 沟通与协作：需求探索涉及与利益相关者、项目团队成员和其他相关方进行有效沟通和协作，以确保需求得到清晰理解和实施。
- 灵活性：需求探索需要灵活性，以适应不断变化的需求、利益相关者需求 9和项目约束。
7 需求探索的优势
- 明确的需求：有助于澄清和细化客户需求。
- 改善沟通：改善利益相关者之间的沟通与协作。
- 提高软件质量：增加开发满足客户需求的软件系统的机会。
- 避免误解：避免误解并帮助管理期望。
- 支持潜在风险识别：支持在开发周期早期识别潜在风险和问题。
- 促进准确计划的制定：促进制定全面准确的项目计划。
- 增加用户信心：增加用户和利益相关者对软件开发过程的信心。
- 支持新业务机会识别：支持识别新的业务机会和收入流。
8 需求探索的劣势
- 耗时：可能耗时且成本高昂。
- 需要技能：需要专业技能和知识。
- 受需求变化影响：可能受到不断变化的业务需求 10的影响。
- 受其他因素影响：可能受到政治和组织因素的影响。
- 利益相关者缺乏承诺：可能导致利益相关者缺乏认同和承诺。
- 受优先级冲突影响：可能受到优先级冲突和利益竞争的影响。
- 需求可能不准确：如果管理不当，可能导致需求不完整或不准确。
- 增加开发成本：如果需求定义不明确，可能导致开发成本增加和效率降低。