通过分析这个图，我们发现，假如在需求获取的时候付出一个单位时间，那么相应的，那在设计阶段需要进行5个单位时间，编码消耗10个单位时间，测试消耗20-50个单位时间，运营维护消耗200个单位时间。由此我们可以看出，在一个项目中，假如我们在需求分析阶段减少时间，那么相应的会对后边的一些阶段造成影响。需求分析做的不好，会加大后期的运行维护时间。
相应的我感觉我们应该做的是反过来，增加需求阶段的时间，这样运营维护阶段的时间就会减少。这样开发出的软件才能更符合用户的需求。软件需求分析特别重要。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中的一个简单步骤，但在过去十多年中越来越多的人认识到它是整个过程中最关键的一个过程。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。许多大型应用系统的失败，最后均归结到需求分析的失败：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
软件需求分析的一般方法如下
⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有：
⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。
⑶请专人介绍。
⑷询问 对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。 通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
当我们掌握好这些方法后，并加以利用自然会减少后边活动的压力。做好需求阶段，磨刀不误砍柴工。