需求确定是关于社会、沟通和管理的技能。它是系统开发中需要技术最少的一个阶段，但如果该阶段没有充分完成，其结果将会比不能完成其它阶段来的更糟。由于不理解、忽略或者曲解客户的需求而付出的代价在软件过程的以后阶段是不可承受的。
需求确定的目标是在实现和部署的系统中，提供满足利益相关者期望的功能性需求和其它需求的叙述性定义。如果对需求进行分类的话，将这些需求分成能够通过软件实现的和需要人工处理或者其它人工干涉的不同类需求。
功能性需求可以分为：系统的范围、必要的业务功能和所需的数据结构。 非功能需求：系统的“外观和感受”、性能、安全性等
功能性需求需要从客户处获得，这是由业务分析人员完成的需求引导活动。从传统的客户谈到构建软件模型，以此来发现更多的需求，有许多技术可以利用。 收集到的需求必须进行仔细地分析以消除重叠和矛盾，这个过程总会导致需求评审和与客户的再一次协商。对于已经达成一致的功能性需求，可以利用图形表示法进行建模，并在文本中进一步定义。
非功能性需求本质上不是行为的，而是系统开发和实现过程中的约束。遵守这些约束的程度决定了软件的质量。非功能性需求被分为以下几种：
可用性可复用性可靠性性能效率适应性（可支持性）其它约束 可用性定义使用系统的容易程度。文档和帮助设施，为高效使用提供必要的培训，用户界面的美观和一致性，错误处理等等，都决定了可用性。 可复用性定义新系统开发中，重复使用之前已实现的软件构件的容易程度。软件构件可以宽泛的理解为被重复使用的已实现软件的任何一部分，甚至是思想，复用适用于界面、类、包、框架等。 适应性包括3个约束–可理解性、可维护性、可扩展性。适应性定义了胸痛被理解、修改、完善和扩展的容易程度。需求一旦被客户接受，就需要在需求文档中进行定义、分类、编号，并被赋予不同的优先级。按组织选定的文档模板来组织需求文档。
客户需求是一个变化的目标。为了处理多变的需求，我们需要能够管理变更。需求管理包含诸如估计变更对需求和系统其它部分的影响等活动。
这些都是简单的、符合成本效益的方法。但这些传统方法的效果与项目的风险程度是反比的。高风险意味着系统难以实现，甚至高层的需求也非常不清楚。
面谈 大多数面谈过程都是与客户一起进行，如果业务分析员没有足够的领域知识的话，可以邀请领域专家面谈。与领域专家面谈是一个知识转化的过程，也是一个学习过程。
结构化面谈：需要提前准备，许多问题都预先确定，明确的日程非结构化面谈：用来补充结构化面谈，更新非正式的会议，没有预定义或设计的问题，非结构化面谈的目的是鼓励用户讲出自己的想法。 一次成功的面谈有很多要素：最为重要的或许是沟通和人际交往技巧。和面谈者提问并且控制局面一样重要的还有他的仔细倾听和保持耐心，以使得面谈者不再拘束。为了维持良好的人际关系并获得额外的反馈，面谈的记录应当在一两天内被送到面谈对象那里，并要求给出评论。调查表 作为面谈的补充形式，而不是要替代它。一般而言，调查表没有面谈有效，因为无法澄清问题和可能得到的响应。调查表是被动的，即使他的优点也是缺点，回答者有时间考虑如何回答，回答也可以是匿名的。 调查表的设计应该避免开放式的问题，大多数问题应是封闭式的。可以采用如下3种形式：
多项选择问题评价问题（回答者必须表述一段陈述观点，强烈同意/同意/中立/不同意）排序问题 （所提供的答案应该用序数、百分比或类似的排序方式给出）观察 观察的3种形式：
被动观察：业务分析院观察业务活动而不干扰或者不直接干预它。主动观察：业务分析员参与到活动中，并且有效地成为团队的一部分解释观察：用户向观察者说明他进行的活动文档和软件系统的研究 要研究的组织文档包括：业务表格、工作过程、职位描述、政策手册、技术文档、业务计划、组织图、财务报表等。
原型法：构造软件原型是为了使整个系统或系统的一部分对用户可视化，以便获得他们的反馈。
头脑风暴：放下公正、社会禁忌和规则来产生新思想或者发现专业问题解决方案的一种会议技术。通常头脑风暴不是为了分析问题或者做出决定，而实产生新思想或者可能的解决方案。
联合应用开发：将所有利益相关者带到了一起，如领导、文书、客户、开发人员。JAD利用了群体动力优势。"群体协同“很可能得到问题更好的解决方案。
快速应用开发：快速交付系统解决方案。
