需求确定是关于社会，沟通和管理的技能。它是系统开发中需要技术最少的一个阶段，但是如果该阶段没有充分完成，其结果将会比不能完成其他阶段来得更糟。由于不理解，忽略或者曲解客户需求付出的代价在软件过程的以后阶段将是不可承受的。一个当代自适应企业的业务前景要求是，对业务能力进行探索，并确定满足不断变化的解决方案。业务过程界定IT项目和系统的需要。很多情况，IT解决方案仅仅是解决业务问题。另外一些情况下，IT解决方案是业务创新的真正推动者，并产生新的经济理念。无论哪种情况，IT解决方案都是一种基础设施服务，可初步提供重要的竞争优势，但最终成为竞争对手也会有的商品。业务需要采取主动，然而 ，由于新技术的动态发展，包括准备到定制的预包装解决方案，IT专家越来越被看作是业务解决方案的提供者，而并不仅仅是系统开发者。业务策略和IT流程的调整是系统规划措施的目标，在is开发过程中，被认为是标准的和应遵守的框架。将经营理念联系到相应的IT解决方案，最大的困难在于：业务人员和IT专家之间缺乏良好的沟通渠道这些渠道具有重要的社会和组织层面的因素，但最初的困难必定与一个建模语言的存在相关，这种建模语言应为描述业务过程提供一种图形解决方案。
一旦需求中的矛盾和重叠已经解决，就产生了一组修正后的需求，需要对这些需求进行风险分析，并排列优先级。风险分析确认哪些很可能在开发阶段产生困难的需求，而排列优先级是为了在项目面临延迟的时候，方便地重新界定其范围。项目的可行性视项目具有的风险数量而异。风险是对项目计划的一种威胁。通过识别风险，项目经理能够尽力控制他们，需求可能由于各种因素而具有风险。需求可以按父子关系建立层次化结构。父级需求由子级需求组成，子级需求是父级需求有效的子需求。需求是变更的，在开发生命周期的任何阶段，需求都可能变更，可能删除已有需求或者增加新的需求。变更本身并不会导致困难，但没有管理的变更却会带来麻烦。开发越往前走，需求变更的开销越大。事实上，由于需求变更而将项目沿着开发轨迹向回拖的下游开销总是增大的，且总是呈指数增长的。改变一个刚创建的，还没和其他需求链接的需求仅仅是直接编辑的工作，而当同一个需求已经在软件中实现后再去改变它，就可能是令人望而却步的昂贵代价。变更可能与人为错误有关，但常常由于内部政策或外部因素而引起的，如竞争力，全球市场或技术进步。无论什么原因，需要强有力的管理政策来建立变更需求的文档，估计变更的影响，并实现变更。因为需求变更开销很大，每个变更需求必须建立一个规范化的业务用例，一个以前没有处理过的有效的需要从技术可行性对项目剩余部分的影响以及开销方面进行设计。需求变更一旦获得批准，就会被结合到相关的模型，并在软件中实现。
需求确定阶段捕获需求，并且以自然语言描述来定义需求采用UML进行形式化的需求建模实在以后的需求规格说明阶段进行的。然后，所收集需求的高层可视化表示通常在需求确定阶段完成。作为最低需求，高层可视化模型需要确定系统范围标示主要用例。系统开发中需要考虑到的主要问题也是由于需求变更引起的范围蠕变。在需求中的某些变更不可避免的时候，我们必须确保请求的变更不会超出项目可接受的范围。因此，系统范围可以通过识别外部实体以及在外部实体和我们系统之间的输入和输出数据流来确定。我们系统获得输入信息，进行必要的处理，产生输出信息。任何不能被系统内部处理所支持的需求都不在项目范围内。