需求分析活动解决软件开发"做什么"的问题。客户对于需求的认知并不清晰，且经常同时包含了几个层次的需求概念，提交给软件项目组，要求按需求实现。需求分析活动的目标，是为后续各活动提供一个稳定的需求文档，作为软件开发的"输入"。
一、需求的层次
需求通常分为3个层次：业务需求、用户需求、功能需求。业务需求即客户希望通过该系统实现的业务目标，例如通过该系统运行某种业务获得收入，以及与其它应用系统在概念层次上的分工等。业务需求描述的是业务领域的问题，应当向客户方负责人或业务专家收集获得。业务需求一般最稳定，不会发生显著变更。
用户需求是指具体的"用户"希望如何使用该系统。行业应用系统都有很多类别的用户，例如：采编录入信息的采编员、面向公众客户的业务受理员、班组长、使用报表的各级领导。可以通过向各个用户走访获取用户需求，汇总成文档后，再向客户负责人进行确认。由于各个用户对于系统应当如何使用系统的想法是不同的，有时甚至是冲突的，因此，用户需求比较容易发生变更。
功能需求是指软件系统应实现的功能。功能需求的视角不是用户，而是软件开发者。确保功能需求尽可能不发生变更，是需求分析的目标之一。
二、需求分析活动
纵观50年软件工程史，无数失败的项目与需求的不确定有关。在项目之初，确定了一个需求范畴，而当项目深入，需求的反复变更耗尽了所有人的心力，最终草率收场或是不了了之。软件开发是对真实世界的模拟，行业应用软件则模拟了客户企业的业务流程。这就需要一个先抽象，再具象的过程。需求分析，是将客户企业实际运作的流程，以及各个用户所希望运作的流程抽象出来，成为软件开发者可以理解的文本。之后，再由软件开发者通过设计、编码实现等活动，将其具体化，成为可操作的软件系统。
因此，需求分析活动，重在分析。客户口头或书面提出的需求文本，可能包括业务需求，也包括用户需求，甚至还会对功能模块的查询条件、作出指定。这些不同层次的需求应当分类整理。对于业务需求，应当充分理解，勾勒出客户的业务流程图，尽管这个业务流程可能超出了本系统的范围。对于用户需求，应仔细鉴别，各个用户的要求是否存在冲突，是否与业务需求冲突?对于功能需求，应当理清用户到底想要什么，实际上，他们并不真的关心功能需求，而只是在表述时将其表达为功能需求。例如，对于报表需求，可能表述为需要哪几张报表，报表的格式是什么。实际上，他们真正想要的，是那些特点列的业务数据能够被方便的获得。
三、需求的概念完整性
一份完整的需求，应是一个完整的体系，即《人月神话》一书中反复出现的一个词汇：概念完整性。业务需求，体现了客户高层对系统的目标和定位;从业务需求层次看来，系统与周边系统的关系清晰，使用一张数据流图，能够清晰的看到数据从周边系统如何流入该系统，如何加工，再如何流出到周边系统。如果一类数据不是由本系统录入的，也没有其他数据来源，却能够直接流向周边系统，那么一定是哪里遗漏了。系统能够表述的很简单，这就是业务需求层面的概念完整性。
在用户需求层次，各个用户使用系统的方式都被充分表述，同一个业务功能被多个用户使用，在操作权限上或有不同，但不存在明显冲突。用户需求与业务需求一致，也可以认为用户需求是业务需求的一种实现(具体化)。业务需求的各个数据流都在各个用户节点上充分表达，即体现为具体用户对业务数据的操作。
功能需求是软件开发者视角的需求，由于功能需求的侧重点在于系统功能，而非业务属性，因此对概念完整性的要求是：不丢失用户需求信息。由于大多数开发者不可能直接接触用户，因此