【需求抽取过程的目的】
理解利益相关者所做的事情以及他们会如何使用一个新系统来支持他们的工作。在需求抽取过程中，软件工程师与利益相关者一起工作来搞清楚应用领域、工作活动、利益相关者想要的服务和系统特征、系统要达到的性能、硬件约束等。

从系统利益相关者哪里抽取和理解需求是一个困难的过程，原因如下：
1.利益相关者经常不知道他们想从一个计算机系统中得到什么。除了一些非常泛泛的说法；他们可能会觉得很难表达他们想让系统做的事情；他们可能会提出一些不切实际的要求，因为他们不知道哪些可行哪些不可行。
2.一个系统中的利益相关者会很自然地用他们自己的话来表达需求，其中隐含着一些关于他们自己工作的知识。需求工程师对于客户的业务领域没有经验，可能无法理解这些需求。
3.不同的利益相关者有各种不同的需求。他们会以不同的方式表达他们的需求。需求工程师必须发现所有潜在的需求来源并且发现共性和冲突。
4.政治性因素可能影响系统的需求。管理人员可能会出于增加自己在组织中的影响力的原因而要求某些特定的系统需求。
5.进行需求分析时所处的经济和业务环境是动态的，不可避免地会在分析过程中发生变化。特定需求的重要性可能变化。新的需求可能会从此前没有咨询过的新利益相关者那里涌现出来。

【抽取和分析过程的过程模型】
每个组织都可以再这个通用模型基础上，基于人员经验、所开发的系统类型、所使用的标准等本地因素定义自己的过程。

其中的过程活动
1.需求发现和理解。在此过程中与系统利益相关者进行交互以发现他们的需求。来自利益相关者和文档的领域需求也在此活动中发现。
2.需求分类和组织。在此过程中处理所收集的未整理需求，将相关的需求进行分组并将它们组织为内聚的聚类。
3.需求优先级排序和协商。当涉及多个方面的利益相关者时会不可避免地发生需求冲突。该活动关注对需求进行优先级排序，找出并通过协商解决需求冲突。通常，利益相关者必须一起协商以解决分歧并做出妥协、达成一致。
4.需求文档化。对需求进行文档化并提供下一轮螺旋。该阶段可以产生一个软件需求文档的早期草稿，或者直接通过白板、Wiki 或者其他共享空间等非正式的方式保存需求。
如图显示需求抽取和分析是一个迭代和过程，包含从一个活动到其他活动的持续反馈。过程循环开始于需求发现，结束于需求文档化。分析人员对需求的理解经过每次循环后都会得到改进。当需求文档产生后，该循环结束。

为了简化需求的分析，对利益相关者的信息进行组织和分组是很有帮助的。其中一种方式是，将每个利益相关者组考虑为一种视角（是一种收集和组织需求的方式，这些需求来自具有某些共性的一组利益相关者。因此，每个视角包括一组系统需求。视角可能来自于最终用户、管理人员或其他人，帮助识别可以提供需求信息的人以及组织需求用于分析。），并且将从该组中收集的所有需求作为该视角的内容。还可以用视角来表示领域需求以及来自其他系统的约束。此外，也可以使用一个系统体系结构模型来识别子系统，并将需求与每个子系统相关联。不可避免地，不同的利益相关者对需求的重要性和优先级有不同的观点，有时候这些观点会相互冲突。如果一些利益相关者感到他们的观点没有得到适当的考虑，那么他们可能试图去故意阻碍需求工程过程。因此，组织日常的利益相关者会议是很重要的。利益相关者应该有机会表达自己的关注点并就需求折中取得一致意见。在需求文档化阶段，使用简单的语言和图形来描述需求是很重要的。这使得利益相关者可以理解这些需求并发表评论。为了让信息共享更容易，最好使用所有感兴趣的利益相关者都能访问的共享文档（例如使用 Google Docs 或者 office 365）或者 Wiki。

【故事和场景】
人们发现，与抽象描述相比，与现实生活中的例子相联系要容易得多。他们不善于告诉你系统需求。但是，他们也许可以描述他们如何处理特定的情形，或者想象他们可能以一种新的工作方式做事情。故事和场景是捕捉此类信息的手段。因此，可以在与利益相关者组访谈，或者与其他利益相关者讨论系统以及开发更特定的系统需求时，使用故事和场景。从本质上看，故事和场景是一样的东西，它们描述了系统可以如何用于一些特定的任务故事和场景描述了人们做什么，他们使用和产生什么信息，以及在此过程中他们可以使用的系统。故事和场景的区别在于描述的组织方式以及所呈现的抽象层次。
•故事被描述为叙述性的文本，并且呈现一种关于系统使用的高层描述；
•场景通常按照所收集的特定信息（例如，输入和输出）进行组织；
故事对于设定系统的"概貌"很有效；故事的一些部分可以接下来被细化并表示为场景：一个故事的例子：这个例子可以用于理解某数字化学习环境系统需求。这个故事描述了一所小学中的情形，其中教师使用该环境来支持学生关于渔业的项目。可以看到这是一个高层的描述。其目的是便于讨论 iLeam 系统可以如何使用，以及作为抽取该系统需求的一个起始点。

iLearn 系统的一个用户故事

故事的好处是每个人都可以很容易建立联系。我们发现与现实中的访谈相比，这一方法对于从范围更广的社群中获取信息尤其有用。我们把故事放到 Wiki 上，并邀请来自全国的教师和学生在上面做评论。
这些高层的故事没有进入到系统的细节，但是它们可以被进一步细化为更加特定的场景。场景是对示例性的用户交互会话的描述。我认为最好以一种结构化的方式而不是叙述性文本的方式呈现场景。极限编程等敏捷方法中使用的用户故事实际上是描述性的场景，而不是帮助抽取需求的一般性的故事。

一个场景开头是对交互的概览。在抽取过程中增加细节以创建一个完整的交互描述。一个场景通常可以包括：
1.场景开始时对系统及用户所期望的条件的描述；
2.对场景中常规的事件流的描述；
3.关于哪些可能出错以及如何解决问题的描述；
4.关于可能同时进行的其他活动的信息；
5.场景结束时对系统状态的描述。
作为一个场景的例子，描述了当一个学生上传照片到 KidsTakePics 系统时，如所解释的发生的事情。该系统与其他系统的关键差别是，教师监管所上传的照片以检查照片是否适合分享。