业务需求一般由最终用户或者领域专家从业务的角度提出，具有以下特点：直觉，凌乱，片断，模糊，无条理，甚至是自相矛盾，主要内容涉及业务发起人，业务流程，业务实体，业务规则等。所谓业务，并不一定是指做生意，举个例子，编译系统的领域专家就是编译原理的专家。
系统需求一般由系统分析师或者架构师从软件系统的角度提出，依据业务需求以及系统其他涉众的需求，包括系统开发成本进度，系统环境的限制，法律法规的规定，业务数据量，系统管理和维护，系统安全性，易用性，维护性，扩展性，重用性，可靠性等等要求，系统分析师必须平衡所有这些需求，将业务需求涉及的业务发起人，业务流程，业务实体，业务规则有选择的映射到系统中，提出细化的，一致的，可追溯的，可测试的系统需求规范。 系统需求不是静止不变的，随着系统设计开发测试的进行，系统需求会不断完善，但这不能成为系统分析师逃避责任的借口，系统分析师必须掌握系统需求的主导权，想客户所未想，做好需求管理工作，否则开发人员就会有沦为码农之虞。 相对于系统需求，业务需求更稳定。
系统需求可进一步细分为用户需求，功能需求，非功能需求。用户需求从最终用户的角度描述系统行为，一个用户需求可能会涉及一个或多个功能需求，功能需求从开发人员的角度描述系统行为，一个功能需求支持一个或多个用户需求，非功能需求支持功能需求。
业务需求与用户需求之间不是一对一的关系，一个业务需求可能对应多个用户需求，一个用户需求可能满足多个业务需求。另外并不是所有用户需求都与业务需求有直接关系。
在实际的需求分析过程中，系统分析师必须清醒的认识到客户很难区分业务需求和用户需求的差别，搞清楚客户背后的真正的业务需求。
