在APP在开发过程中，最头疼、最麻烦的可能是开发需求的变化。在开发过程中，客户往往有新的想法，会覆盖或改变原来的想法。正常情况下，可能不会有大的变化，也可能需要大的变化。软件开发过程是渐进的，是产品UI在这个过程中，开发是一个项目着陆的过程，一个漫长的过程，客户的想法发生新的碰撞，产生新的火花，其实是正常的，有新的想法，需要改变，也是软件开发过程中常见的。
一、软件需求是什么？
(1)用户解决问题或达到目标所需的条件或权能(Capability)。 （2）系统或系统部件应满足合同、标准、规范或其他正式文件所需的条件或权力。 (3)反映上述(1)或(2)条件或权能的文件描述。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。
软件需求分为业务需求、用户需求和功能需求三个层次。
业务需求( business requirement)在项目视图和范围文件中，反映了组织机构或客户对系统和产品高层次的目标要求。
用户需求(user requirement) 文档描述了用户在使用实例时必须完成的任务(use case)文档或方案脚本(scenario)说明中说明。
功能需求(functional requirement)定义开发人员必须实现的软件功能，使用户能够完成其任务，从而满足业务需求。所谓的特性(feature)是指逻辑相关功能需求的集合，为用户提供处理能力，满足业务需求。
二、作为APP软件开发公司应该如何应对开发需求的变化？
1.有效管理软件需求
项目签订前，通过思维导图、功能列表等方式帮助客户梳理功能，最大限度地减少未来可能发生的需求变化。并将功能纳入合同，作为依据；
在项目开发过程中，要有效控制需求变化。一方面，在产品原型设计阶段，要与客户反复确认，避免进入后期开发的新变化。二是减少过滤不合理的需求，从产品功能和用户的角度给客户合理的建议；第三，对于UE在开发过程中，需要修改的需求、较小的需求变化、可接受的需求可以帮助客户实现，提高客户满意度；对于较大的变化和对整体开发影响较大的需求，需要重新评估软件，看看客户是否接受下一阶段的开发，或者这次需要开发，需要对新功能的情况进行评估。第四，一旦UE确定后，UE它将无法再次改变，因为后续开发将以此为基础。
2.系统开发完成后，客户再次提出新的需求
在这种情况下，基本上考虑的是约定以外的新的开发需求，分析客户需要改变的具体内容。如果是小需求，可以在下一个版本迭代中开发，在原来的基础上增加一些小修改。如果需要更改大的基本核心功能，可以在二期项目需要大升级或重构时重新评估，以满足客户的需求。此外，为了防止客户滥用提高需求的权的权力。对于一些不合理的需求，我们还应该引导客户了解该功能的不合理之处，以便重新修改或放弃需求。
一般来说，软件需求的变化并不可怕，最重要的是需要合理的控制和响应，小修改，满足客户，提高客户满意度，大修改，重新评估，客户也可以理解自己的需求变化。最无法控制的是早期需求不清楚，或者客户不承认需求的内容是新需求。因此，文档管理和早期协议是双方更好的保证。