在这篇文章中，软件需求与分析工进行了三步。首先是软件需求调研然后是软件，需求分析最后是确认需求。
首先是调研阶段，这一个过程是最重要的，直接影响了接下来的两个过程。首先，我们要学会的是和多个部门的人谈，纵向划分层次，并且对相应层次的人一一询问。因此对与各层次的人应该谈的细节就要提前拟定，详细的分析使用者角色。制定好方案后就要一一拜访，在拜访过程中，表达出个人的意思，仔细分析客户人群的关系，建立占率合作伙伴关系。经过一番交往，我们将逐渐在客户中结识一批可以帮助我们的人。今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。
在和一部分人调研结束后，就要准备进行研讨会，当然这个研讨会应该灵活，根据实际情况合理与客户进行研讨会，才能为下一步需求调研进行准备。
在需求调研这个过程中，存在着许多问题，其中最突出的问题就是客户提不出正确的需求，客户搜描述的需求大多是凭借自己工作内容所说，并不能确定电脑是否可以完成，这就造成大多数情况下做出来的东西不能达到客户的满意，在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。什么是与业务实现有关的需求呢？比如要求做成什么界面，数据要求怎样处理，等等。为什么是无效的呢？因为客户毕竟是非专业，我们应当有这种自信，在理解客户真实意图以后，能够提出比客户更优的解决方案。我们所做的需求调研之后就要整理这些内容，需求整理，就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。然后，我们再在整体用例图的基础上，依次对每个用例绘制用例图。因此，需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
接下来就是要做需求分析了， 需求调研与需求分析工作应当是相辅相伴共同进行的。对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。运用用例视图对业务需求进行分析、抽象、整理、提炼，进而形成抽象模型的过程称之为用例建模，而这个模型就是用例模型。当模型做出来之后下一步就是业务流程分析，分析我们完成这个系统需要做的步骤，分析我们的软件能做什么事。需求分析下一步还要做的是用例说明，用文字描述我们已经画好的用例图，详细的描述其中的细节。除此之外，我还往往在每一个用例说明的后面与该用例相关的需求列表，便于需求跟踪。用例分析实质是需求人员的一份设计。既然是设计就可能出现偏差，最终偏离原始的需求。因此，将需求列表附在用例后面，便于日后的需求评审与确认。当每次需要升级时，则添加上新的需求，或对以往的需求进行更新。在一个用例下边还有子用例和扩展用例。用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。除用例图图之外还有uml建模中其他多种图都会用到。需求分析中还要知道非功能需求。我们在进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计，对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。
最后一步就是需求确认了，准备好需求列表，有了需求列表，当需求分析工作完成时，我们将一项一项检查用例模型是否满足需求列表的内容；当软件开发完成时，我们将一项一项检查软件功能是否满足需求列表的内容；当用户验收时，我们同样使用需求列表，一项一项检查我们的软件是否满足用户需求。接下来就是撰写软件需求规格说明书，最后签字确认，一个软件的需求分析就结束了。
