沟通
软件工程最基本的原则是：在你开始解决问题之前，先理解问题，同时确保你所构想的解决方案是人们真正想要的。沟通活动为WebE团队提供了一个有组织的方法，用于从利益相关者那里引出需求。本质上来说，在创建每一个WebApp增量的时候，它建立了团队的目的地。
沟通活动
WebE过程从沟通活动开始，沟通作为过程流的入口。Web工程师和利益相关者在这里开展一系列WebE动作：
1）询问并回答关于WebApp和其业务环境的一系列基本问题。 2）提取需求将作为所有后续活动的基础。 3）协商对实际时间、资源和技术需求。 这些动作分别称为规划、提取（也叫需求获取）和协商规划
沟通对象
在为将要问的规划问题担忧之前，需要确定利益相关者。总的来说，利益相关者包括：业务经理、产品经理、市场营销人员、内部和外部的客户、最终用户、顾问、产品工程师、Web工程师以及支持和维护人员。
沟通技术
除非WebApp相当简单同时最终用户资料是可预测的，否则使用只从一两个人那里收集的信息作为规划或者分析的基础是不可取的，应当考虑更多的人（和更多的观点以及视角）。
- 传统焦点组：一个经过训练的主持人和一小组（通常少于10个人）具有代表性的最终用户（或者是担任最终用户角色的内部利益相关者）会面。目的是讨论将要开发的WebApp，通过讨论来更好地理解系统的需求。
- 电子焦点组：同一组有代表性的最终用户和利益相关者进行适当的电子形式的讨论。参与的人员可以更多一些。因为所有的用户可以同时参与进来，所以可以在更短是时期内就能收集到更多的信息。由于所有的讨论都是基于文本的，所以可以自动产生同期讨论的记录。
- 迭代调查：使用一系列简明的调查，通过一个Web站点或者电子邮件发送给具有代表性的用户，要求他们回答一些关于WebApp的特定问题。对反馈加以分析，并用于调整后面的调查。
- 探索性调查：一种基于Web的调查，是关于一个或多个WebApp的，这些WebApp拥有和将要开发的WebApp很相似的一些用户。用户链接到这个调查，并回答一系列的问题（参与的用户通常会收到一些报酬）。
- 场景创建：通过对被选择的最终用户（或者其他扮演最终用户角色的内部利益相关者）进行咨询，来创建用于描述与系统特定交互的使用场景。
每个利益相关者对于WebApp都有不同的视角，当WebApp被成功部署的时候获得不同的利益，同时在部署工作失败的时候都会遭受不同的风险。当收集了多个视角的信息之后，出现的需求可能相互不一致或者可能彼此有冲突。有一种方法能够解决相互冲突的需求，同时更好地理解所有需求的相对重要性，那就是使用基于优先级点的投票策略。给所有利益相关者提供一定数量的优先级点，这些优先级点可以用于一个或多个需求（在这个阶段，由信息目标和应用目标表示），数量可以不同。列出一系列的需求，然后每一个利益相关者通过在每个需求上面分配一个或多个优先级点来表示该需求的相对重要性（从他或她的视角）。优先级点不能重复使用。以一旦某个利益相关者的优先级点用完，他就不能再对需求实施进一步的操作。所有的利益相关者在每项需求上的优先点总数就表明了这个需求的总体重要性。协作并非意味着全体人员来定义需求。很多情况下，利益相关者通过各自对WebApp需求设定优先级来进行协作。可以由一个强势的“项目优胜者”（例如，一个业务经理或者一个资深的技术专家）来最终决定选择哪些需求。
提取需求
基础原则
- 会议由所有利益相关者共同举办和参与。
- 指定准备和参与会议的原则
- 建议拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的重要点，但也不能太正式，以鼓励思想的自由交流。
- 由一个主持人（可以是一个客户、一个Web工程师或者一个局外人）对会议进行控制。
- 使用某种定义机制（可以是工作表、活动挂图、不干胶贴纸、电子公告牌、聊天室或者虚拟论坛）。 目的是识别一系列需求，这些需求处理WebApp的内容、功能、用户交互，以及和存在的业务系统及数据库的互操作性
任务
- 在规划期间，基本问题和问题的答案建立了WebApp的范围，提供了对WebApp特性的一些理解。如果范围显示开发工作相对较重，那么在需求收集（提取）之前进行准备是很明智的。如果时间允许，写一页的WebApp描述，作为需求收集的基础。WebApp描述把从规划会议中已经得到的信息进行组合。选择一次会议的地点、时间和日期，以及一个会议主持人。邀请所有的利益相关者出席。至少比会议时间提前24个小时把WebApp描述分发给所有的利益相关者。
- 每个利益相关者都被告知在需求收集会议之前检查WebApp描述，同时列出一个“内容对象”列表，包括：1）系统周围的环境部分；2）由系统生成；3）被系统使用来完成系统的功能。另外，每一个出席者都要给出一个功能列表，这些功能控制内容对象或者与这些内容对象进行交互。最后，也应当开发出约束（例如，影响所提供特性的业务规则）列表和性能标准（例如，速度、精确性、隐私性和安全性）。出席者被告知列表不需要很全面，但是应当反映每个人对系统的认知。
- 当需求获取会议开始后，讨论的第一个主题就是需求和（推出）新产品的理由——每个人都应当赞同产品的合理性。一旦达成了共识，主持人指出大家必须完成如下4个任务：1、定义用户种类。同时给出每一类的描述。2、使用每个人准备的列表对内容和功能进行精化。3、考虑特殊的约束和性能问题。4、为每一类用户写场景。 并非所有的这些任务都要在一个简单需求获取会议期间内进行，但是它们都必须在WebE过程继续进行之前实现。
协商
- 现实情况下，Web工程师和其他利益相关者往往进入一个协商的过程。此时，利益相关者也许需要考虑成本和交付时间，平衡功能、性能和其他的产品或者系统特性。这个协商的目的是建立增量需求，来满足客户的需求，同时反应WebE团队所处的现实世界的限制（例如，时间、人员和预算）。
- 最好的协商是力求一个双赢的结果。即客户“赢”在获得满足大多数需要的WebApp，WebE团队“赢”在按照实际情况在可实现的时间线内完成工作。
- 在任何协商开始之前，一个很好的主意就是确定每一个利益相关者的“赢的条件”，并指定一个策略，以把所有的利益相关者融合于对所有参与者（包括WebE团队）来说都是“双赢”的条件之中。