客户为产品的开发付费。客户可能是您的用户的管理者。客户也可能是您的市场部门。
顾客在产品开发完成后购买该产品，我们应该对客户有足够的了解，以定义一个他们会购买，并认为有用和方便的产品。在某种情况下，顾客和产品的最终用户是相同的人。
用户是最终操作产品的人。对组织内使用的产品来说，用户通常是为您的客户工作的人。对于对外销售的产品，用户和顾客可能是相同的人。确定用户的目的是让您能理解他们所做的工作。您的产品最终的目标是对工作有所帮助。您还需要知道用户的特点，以便能写出正确的易用性需求。不同的用户对您的产品将提出不同的要求。总是会存在很多的潜在用户，还有很多可能会被遗忘或没有被注意到。
这些角色与您的产品有关系：
可能使用您的产品的人的职业是什么？ -------医生、职员、工程师
人们还会有其他什么角色？ -------邻居、儿童、学生
人们使用您的产品时会在什么地方？ --------旅行者、登山者、正在沐浴
可能使用您的产品的人的国籍是什么？
是否有一些组织可能使用您的产品？ --------中央银行、护照管理办公室、超市连锁店
风险承担者是在产品中有既得利益的人------他们构建产品、管理产品、使用产品或以某种方式受到产品用途的影响。风险承担者是对产品有一些要求的人，因此在需求收集活动中必须向他们咨询。还有管理者、业务主题相关者、开发者、检查人员、市场力量、法律方面、反对者、专业团体、公众意见、政府、特殊利益团体、文化利益.........
需求限制条件是全局性的需求---它们影响您收集的全部需求，或者至少是绝大部分需求。限制条件指任何对产品生产的方式的限制。包括设计限制、开发时间限制、经费限制等等。产品的名称很重要。
在项目启动阶段感兴趣的范围是工作的范围。工作指的是用户需要产品来支持的业务活动。工作可能是商业活动、某种科学或技术工作，或者是任何事情。设定范围的方法是把一块工作（我们要研究的工作）与另一些工作（围绕我们的工作）分开。设定工作的范围意味着您决定在确定产品的需求之前有多少工作要研究。
设定工作上下文范围----工作上下文范围定义了您要研究的工作，以及您的工作周围的其他系统。我们通过创建一个上下文范围的模型来展示这种职责上的划分，上下文范围模型变现了工作和与之相连的工作。针对每个领域，问以下问题：
是否存在一个物理实体代表这个领域？
这个领域提供数据或政策，还是都提供？
我将从何处得到关于该领域的信息？是否存在外部的，或每提及的信息来源，需要参考以研究该领域？这不会影响工作的上下文范围。
工作上下文范围显示了工作的职责和相邻系统的职责起止之处。工作与相邻系统之间的数据流确定了哪些由我们的工作完成，哪些由相邻系统完成。围绕工作边界的数据流清除地指明了他的职责。
工作被分解为用况。用况是用户认为有用的一些工作单元。用况这个术语最先是Jacobson用来描述一定量的要完成的工作的。他选择将系统分解为较小的单元，因为他 感到对象模型不具备可扩展性。所以，为了 征服现代系统的复杂性和庞大，首先需要将系统划分为一些较方便的大块，这些大块的划分应该基于用户对系统的看法。
采取以下步骤来确定用况：
首先，建立工作的范围；
确定围绕工作的相邻系统；
确定工作与相邻系统之间的联系；
从联系开始，识别影响工作的业务事件；
研究对业务事件的响应；
确定组织对时间能做出的最好响应；
确定产品在响应中的角色；
确定产品的用况；
针对每个用况导出需求。
工作是您的客户的业务活动。您打算构建的自动化产品将是一个有助于工作的工具。产品将对一些现存的过程进行自动化或进行组织，或者它通过增加新的功能来改变工作。因此理解工作是势在必行的。工作的存在是为了为外界提供服务。展示工作与外界联系最方便、最有用的方法是使用一个上下文范围图。