从用户、客户和其他涉众那里生成系统需求的活动。
可行性研究结束后，我们进入下一个阶段;抽取和分析。
需求捕获和分析
它是一个与客户和最终用户交互的过程，以查明领域需求、系统应该提供什么服务以及其他约束。
领域需求反映了系统运行的环境，因此，当我们谈到应用领域时，我们指的是诸如列车运行、医疗记录、电子商务等环境。
它也可能涉及不同类型的股东;终端用户、管理人员、系统工程师、测试工程师、维护工程师等。
涉众是对需求有直接或间接影响的任何人。
需求抽取和分析有4个主要过程
我们通常从收集需求开始，这可以通过一般性的讨论或与涉众的访谈来完成，也可能涉及到一些图形符号。
然后，您将相关的需求组织成子组件并对它们进行优先级排序，最后，您通过删除任何可能从一些冲突中产生的不明确的需求来细化它们。
以下是需求捕获和分析的4个主要过程。
需求捕获和分析的过程
它表明这是一个迭代过程，每个活动都有反馈。过程周期从需求发现开始，到需求文档结束。当需求文档完成时，周期结束。
1. 发现需求
它是与涉众交互并从涉众那里收集需求的过程，这些涉众是关于所需要的系统和已存在的系统(如果存在的话)的。
这可以通过一些技巧来完成，比如面试、场景、原型等等，这些可以帮助股东了解这个系统将会是什么样的。
收集和理解需求是一个困难的过程
这是因为涉众可能不知道他们想要软件做什么，或者他们可能给出不现实的需求。
它们可能会给出不同的需求，这将导致需求之间的冲突，因此我们必须发现并解决这些冲突。
也可能有一些因素会影响利益相关者的决策，例如，公司的经理或大学的教授想要对管理系统有完全的控制权。
访谈
在访谈中，需求工程团队向涉众提出关于当前使用的系统和将要开发的系统的问题，因此他们可以从答案中收集需求。
问题分为两类:
- 封闭式问题:预先定义的一组问题。
- 开放式问题:没有预先定义的预期答案，更多的是一般性问题。它是用来探索不清楚的问题，以一种不那么结构化的方式。
在实践中，面试通常是两者的结合。通常，以开放式问题开始，然后使用封闭式问题来更具体地说明一些还不清楚的需求。
访谈有助于全面了解涉众需要什么，他们如何与新系统交互，以及他们在当前系统中面临的困难。
然而，面试对于理解领域需求并不是很有帮助。这有两个原因:
- 领域需求可能使用特殊的领域术语来表达，软件工程师经常发现很难理解，并且很容易产生误解。
- 有时候，涉众不会告诉你一些需求，因为他们认为这是非常基本的，不值得提及，或者他们发现很难解释，这在需求中是不被考虑的。
用例和场景
用例和场景是两种不同的技术，但是它们通常是一起使用的。
用例识别系统和它的用户甚至其他外部系统之间的交互(使用图形符号)，而场景是一个或多个这些交互的文本描述。
用例包括一些符号来描述系统:
用例图符号和示例
现在，我们将使用场景来描述每个用例中的交互。它们应该有一个格式，包括以下内容:
下面是上面用例示例的场景示例。
场景
用例和场景是引出需求的有效技术。但是，由于它们关注于与系统的交互，因此对于引出高级业务、非功能或领域需求来说，它们是无效的。
接下来的两个阶段是关于分析需求的:确定所陈述的需求是否清晰、完整、一致和明确，将相关的需求分组并将其组织成相关的组件，以及解决任何明显的冲突。
2. 需求分类和组织
组织系统的整体结构非常重要。
将相关需求放在一起，并将系统分解为相关需求的子组件。然后，我们定义这些组件之间的关系。
我们在这里所做的将帮助我们确定最合适的架构设计模式。
3.需求优先级划分和协商
我们之前解释了为什么引出和理解需求不是一个简单的过程。
其中一个原因是不同利益相关者的参与可能导致冲突。为什么?因为要让各方都满意是很难的，如果不是不可能的话。
该活动关注的是确定需求的优先级，并通过协商发现和解决需求冲突，直到您达到一些涉众可以妥协的情况。
我们不应该达到这样一种情况，即涉众因为没有考虑到他的需求而不被满足。
确定需求的优先级将帮助您稍后关注系统的基本特性和核心特性，这样您就可以满足用户的期望。它可以通过赋予每个功能的优先级来实现。因此，具有更高优先级的功能需要更多的关注和关注。
4. 需求规范
然后将需求记录下来。我们将在“需求工程—需求规格说明”中更详细地讨论需求规格说明（ “Requirements Engineering — Requirements Specification”）。