软件行业需求工作主要由需求分析师负责，需要完成对用户需求的调研、分析、整理，从而将用户需求转换为可供开发的功能需求。但随着互联网思维的普及，软件行业也越来越强调产品经理的作用，或许并不是互联网思维的关系，而是随着公司的发展，必须寻求由项目盈利模式向产品盈利模式转变，从而催生出产品经理的角色，以及对其的重视。
对于软件行业的产品经理来说，最核心的职责还是跟需求分析师一样，是从需求到产出原型的过程。在这个过程中主要使用的需求分析方法是面向对象需求分析方法。
面向对象需求分析方法
面向对象需求分析方法是通过统一建模语言 UML对用户需求进行调研和分析，并整理出功能需求的分析方法。
需求分析过程
前面已经讲到需求分析过程就是要将用户需求转换为可供开发的功能需求，为了达到这目的需要开展一系列需求活动。
收集并分析问题
在开展一项需求工作之前，都会从任务提出人哪里得到客户的想法（任务提出人不一定是客户，可能是销售同事、项目经理或维护经理）。但任务描述可能会比较粗糙，也较为含糊，还不足以指导后续的需求工作。
因此当你收到一项任务时，如果不了解情况，那么必须向任务提出人咨询清楚，客户为什么提出这项任务，需要达到什么目的，也就是尽量了解任务提出的背景。如果你不了解客户所提要求涉及的业务背景，或不了解前因后果，将对后续的梳理疑问和用户访谈造成很大的影响。
接下来就要有针对性的补充相关的知识背景，例如户政客户需要建设一项重户人员注销的功能，那就需要了解一下是不是最近有新的政策出来，或是不是最近公安部有检查，查出本省的重户人员较多而被通报了。这对后续功能实现可能起作用，也可能不起作用，但一定会对后续用户访谈的交流带来极大的好处。
在搞懂用户要求的过程中，你会产生很多疑问，这时需要将疑问分类整理好，为下一步用户访谈提供基础。梳理疑问需要以用户场景为指导，可沿着“谁要什么功能，达到什么目的”这一思路进行整理。
虽然在需求调研阶段不应该过多地思考功能实现，不过绝大部分情况都是在原有功能的基础上提出新的需求，全新的系统建设反而较少。这种情况下很难不基于现有功能思考新需求的实现。我认为无需太严格区分需求的每个阶段，在现有的功能基础上先构思解决方案是没有问题的，只要能基于用户场景，最终能满足用户需要即可。因此这时可以基于大概地功能实现的解决方案为出发来梳理细节问题，例如考虑到实现某个功能或操作时会有什么问题，就把问题记下来。但需要跟客户核实的问题应该还是以业务问题为主，如果只是些交互或操作层面上的问题，大可等到原型设计时，再进一步细化，或内部讨论解决。
用户访谈
用户访谈不是简单的将问题清单拿出来一个个问，问题清单只是辅助，主要是你自己要明白自己想要搞懂的是什么。可以将问题进行分类，整理每类问题的核心，然后基于核心向外发散。
最先要明确的是从大的范围来看，整个需求需要实现的功能是给谁用的，达到什么目的。再对细分的小需求进行确认，还是给谁用，达到什么目的。最终理出每个用户场景的角色和目的，方便后续需求分析及功能验证。
用户访谈时，很重要的一项技能是挖掘客户原话背后的真实需求，以及通过一定的提问技巧来帮助你完成访谈。下面是关于用户访谈时的一些提问技巧，以某项目客户提出报表需要导出为PDF为例。
1、用各种角色的身份进行提问
例：谁需要这个PDF文档？高层领导、档案管理员、部门经理？
2、进行反向提问（逆向提问）
例：不做这个功能会有什么影响？（体现该功能的重要性）
3、进行外延（发散、深入）提问
例：PDF文档有什么格式要求？
例：为什么需要做这个功能？
4、对原话的每一部分进行提问
例：什么报表需要导出为PDF？
根据用户访谈的结果，形成一个个的用户场景，最后将用户场景组装成一个完整的故事，这个故事就是整个业务过程。
结构建模
每个系统或功能都会涉及到不同角色、业务概念和物品等，这些事物之间会有很多关系，发生很多事情。特别是当我们刚接触新的业务时，最急迫需要解决的问题就是理清楚这些业务概念以及他们之间的关系。
类图能帮助我们识别出这些角色、业务概念、物品等，并理清他们的关系，这个过程就是机构建模。类图除了分析业务需求作用外，还起来指导原型设计的作用。一方面是在设计时能理清每个实体有哪些项目；另一方面是功能与功能之间的关系，一对一和一对多的设计方式是完全不一样的。
行为建模
行为建模是通过活动图描述业务活动流程的过程。在梳理用户场景时会得到具体的业务事件，也对业务事件的办理过程有了大概的了解。接下来需要通过活动图对业务事件的过程进行明确，尽量使用泳道图明确各个活动的使用角色，即使是单角色的流程也应该明确标出角色名称。
业务流程分为生产性流程、管理性流程和支持性流程。生产性流程是流程中最重要的部分，是企业/组织价值体现的核心；管理性流程是对生产性流程的管控，通常是有管理层发现的，对一些质量、效率进行监督的控制性流程；支持性流程是对生产性流程的一种补充，通常是由协作部门、本部门员工执行的工作。如果拿软件开发过程来比喻的话，需求分析、软件设计、软件编码、软件测试是生产性流程；项目管理、质量保证是管理性流程；而文档配置等属于支持性流程。通常生产性流程是最容易标识的，而管理性流程和支持性流程比较容易忽略，因此在需求分析时要特别注意。
功能建模
用例图的作用主要是将活动图中不在系统范围内的部分过滤掉，只保留可以通过系统实现的活动。对于每一个人机交互的活动，需要细化分析其事件流，也就是当前活动里人机交互的详细过程，这个过程也可以通过活动图绘制。
用例中的事件流是原型设计的重要输入来源，另一个输入来源是类图中的对象属性及对象间的关系。
用例图示例如下图所示：
在完成用例图后，需要进一步细化用例说明：
经过一系列建模分析后，基本的功能都已经明确，这时需要对功能进行有效地组合，聚合成有机的整体。一般会以业务和角色两个维度进行分析。
