当用户有一个问题能够用计算机系统来解决，而开发者開始帮助用户解决问题，沟通就開始了。
需求获取可能是软件开发中最困难、最关键、最易出错及最须要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求。仅仅要问用户系统的目标特征，什么是要完毕的，什么样的系统能适合商业须要就能够了，可是实际上需求获取并非想象的这样简单。这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是非常难明白的，用户不了解技术实现的细节，这样造成了系统目标的混淆。
其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解。不论什么一个系统都会有非常多的用户或者不同类型的用户。每一个用户仅仅知道自己须要的系统。而不知道系统的总体情况，他们不知道系统作为一个总体怎么样工作效率更好。也不太清楚那些工作能够交给软件完毕，他们不清楚需求是什么。或者说怎样以一种精确的方式来描写叙述需求。他们须要开发者的协助和指导，可是用户与开发者之间的交流非常easy出现障碍，忽略了那些被觉得是"非常明显"的信息。最后是需求的确认，由于需求的不稳定性往往随着时间的推移产生变动，使之难以确认。
为了克服以上的问题，必须有组织的运行需求的获取活动。
需求获取活动建议要完毕的11个任务或者说步骤各自是确定需求过程、编写项目视图和范围文档、用户群分类、选择用户代表、选择用户代表、建立核心队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查问题报告和需求重用。
当然应该依据组织和项目的具体情况进行适当的裁减。比方依据项目和用户情况把需求获取会议改成问卷调查或者座谈等等。
系统的需求包含四个不同的层次：业务需求、用户需求和功能需求、非功能性需求。
业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求文档描写叙述了用户使用产品必须要完毕的任务。这在使用实例文档或方案脚本说明中予以说明。功能需求定义了开发者必须实现的软件功能，使得用户能完毕他们的任务，从而满足了业务需求。
非功能性需求是用户对系统良好运作提出的期望。包含了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是依据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描写叙述系统的业务需求，应该包含高层的产品业务目标。评估问题解决方式的商业和技术可行性,全部的使用实例和功能需求都必须遵从的标准。
而范围文档定义了项目产品所包含的全部工作及产生产品所用的过程。
项目相关人员对项目的目标和范围能达成共识,整个项目组都应该把注意力集中在项目目标和范围上。
系统用户在非常多方面存在着差异。比如：使用系统的频度和程度、应用领域和计算机系统知识、所使用的系统特性、所进行的业务过程、訪问权限、地理上的布局以及个人的素养和喜好等等。依据这些差异，你能够把这些不同的用户分成不同的用户类。与UML中Usecase的Actor概念一样，用户类不一定都指人，也能够包含其它应用系统、接口或者硬件，这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点。并具体描写叙述出它们的个性特点及任务状况，将有助于需求的获取和系统设计。
3、选择用户代表
不可能对全部的用户都进行需求获取。这样做时间不同意效果也不一定好，所以要识别出能够确定需求和了解业务流程的用户作为每类用户的代表。每类用户至少选择一位能真正代表他们需求的人作为代表而且能够作出决策，用户代表往往是本类用户中三类人：对项目有决定权的领导、熟悉业务流程的专家、系统终于用户。
每一个用户代表者代表了一个特定的用户类。并在那个用户类和开发者之间充当基本的接口，用户代表从他们所代表的用户类中收集需求信息。同一时候每一个用户代表又负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。
4、建立核心队伍
通经常使用户和开发者不自觉的都有一种"我们和他们"的想法，产生一种对立关系。把彼此放在对立面，每一方都定义自己的"边界"。仅仅想自己的利益而忽略对方的想法。他们通过文档、记录和对话来沟通，而不是作为一个合作的总体去识别和确定需求完毕任务。实践证明这个方案是不对的，不会给两方带来一点益处,良好的沟通关系没有建立导致了误解和忽略重要的信息。仅仅有当两方參与者都明白要成功自己须要什么，同一时候也知道要成功对方须要什么时。才干建立起一种合作关系。
为了建立合作关系通常採取一种组队的方式来获取需求，建立一个由用户代表和开发者组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方式和协商分歧，小组成员能够採用会议、电子邮件、综合办公系统等方式进行交流，但交流时应注意下面原则：小组会议应该由中立方来组织和主持。用户和开发者都要參加；交流预先要确定准备和參与的规则。议题要明白并覆盖全部关键点，但信息来源应该自由；交流目标要明白。并告知全部的成员。
5、确定使用实例
从用户代表处收集他们将使用系统完毕所需任务的描写叙述。讨论用户与系统间的交互方式和对话要求，这就是使用实例。一个单一的使用实例可能包含完毕某项任务的很多逻辑相关任务和交互顺序。
使用实例方法给需求获取带来的优点来自于该方法是用以任务为中心和以用户为中心的观点，比起使用以功能为中心和以开发者为中心的方法，使用实例方法能够使用户更清楚地理解和认识到新系统同意他们做什么和怎么做。描写使用实例的时候要注意使用简洁直白的表述，尽量使用主动语态，用"系统"或者"用户"作为主语，比方"用户提交用户password，系统验证用户password是否正确"，另一点在描写叙述中不要设计界面细节，比方"用户从下拉框中选择产品类型"。
使用实例为以后写用例场景描写叙述中的基本路径和扩展路径提供了素材。
6、召开联合会议
最常见的需求获取方法是召开会议或者面谈。联合会议是范围广的、简便的讨论会，也是核心队伍成员之间一种非常好的沟通方法。该会议通过紧密而集中的讨论得以将用户代表与开发者间的合作伙伴关系付诸于实践并能由此拟出需求文档的底稿。
联合会议的第一个议题就是系统的必要性和合理性。必须全部成员都同意系统是必要的而且合理的。
接下来就能够讨论使用实例清单，清单能够打印成大纸挂在墙上、写在黑板上或做成演示材料。
对每一个清单合并去掉反复项，加上补充内容就能够得到一份总的清单，注意避免採用负面的"太差""不可行"去否定用户的想法，这些想法都应该保留下来作为被评议的清单项，这样保护了小组成员开放的思维。最后对清单进行讨论，会议成员必须检查每一个使用实例，在把它们纳入需求之前决定其是否在项目所定义的范围内。形成终于的需求报告。
在进行讨论时，也应该避免受不成熟的细节的影响。在对系统需求取得共识之前，用户能非常easy地在一个报表或对话框中列出某些精确设计，假设这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制，应确保用户參与者将注意力集中在与所讨论的话题适合的抽象层上，重点就是讨论做什么而不是怎么做。这里有一点非常重要就是要让用户理解对于某些功能的讨论并不意味着即将在系统中实现它，更不要做暗示或者承诺什么时候完毕需求。
在讨论之后，记下所讨论的条目，并请參与讨论的用户评论并更正，由于仅仅有提供需求的人才干确定是否真正获取需求。当最后拿到了一份具体准确的需求报告书的时候。会议就算成功完毕了。可是要清楚需求过程本身就是一个迭代的过程。在以后的过程活动中不可避免的将要改动和完好这份报告。
7、分析用户工作流程
分析用户工作流程观察用户运行业务任务的过程，通过分析使用实例得到系统的用例图。
编制用例图文档将有助于明白系统的使用实例和功能需求，统一建模语言的使用有助于与用户进一步交流。每一个用例的描写叙述应包含：编号,为每一个用例分配一个唯一的编号，为需求的追溯提供了方便；參与者，与这个用例交互的actor；前置条件。開始用例前所必须具备的系统状态；后置条件，用例完毕后系统达到的状态。基本路径，用例完毕的关键路径，也是用户期望的路径；扩展点，基本路径的分枝，表示意外情况；字段说明。路径中名称的进一步分讲解明。对以后类属性的定义和数据库字段设计起作用。设计约束，实现用例的非功能约束。写基本路径时应该使用主动语句；句子以actor或者系统作为主语；一句表示一个actor动作，一句表示系统动作。交叉表现交互；不要涉及界面细节，比方"用户在文本框输入名称，下拉框选择类型"。
| 用例：用户注冊。用户注冊成为系统会员 | |
| 编号 | UC1 |
| 參与者 | 用户 |
| 前置条件 | 用户訪问系统。系统运行正常 |
| 后置条件 | 系统记录用户注冊信息 |
| 基本路径 | 1. 用户请求注冊。
|
| 扩展点 | 4a. 用户提供的信息不对： 4a1. 系统提示输入正确信息 4a2. 返回3 |
| 补充说明 | 注冊信息包含＝用户实名＋电话＋传真＋Email＋联系地址联系地址＝省份＋城市＋街道＋邮编 |
| 设计约束 | 注冊反应时间不能超过3秒 |
8、确定质量属性
在功能需求之外再考虑一下非功能的质量特点，以及确定由于特殊的商业应用环境对系统提出的功能或性能上的约束，这会使你的产品达到并超过客户的期望。对系统怎样能非常好地运行某些行为或让用户採取某一措施的陈述就是质量属性，这是一种非功能需求。
听取那些描写叙述合理特性的意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。
你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义，而且要将质量属性分配到每一个用例的设计约束中去。
9、检查问题报告
通过检查当前已经运行系统的问题报告来进一步完好需求客户的问题报告及补充需求为新系统或新版本号提供了大量丰富的改进及添加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。
10、需求重用
假设客户要求的功能与已有的系统非常类似。则可查看需求是否有足够的灵活性以同意重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法。像分析模式和设计模式一样。需求也有自己的模式。