需求分析最重要的是思维方式，要站在用户的视角展开，即“业务驱动”思想，关注问题而非方案。
以变更/优化型需求为例，针对用户提出的需求，首先要判断是方案（直接告诉你做什么）还是问题（告诉你他实际想解决的问题）。第一步就是澄清问题，2W1H，明确谁的，什么问题，并知道遇到该问题当事人目前是怎样解决的，若有概念的不确定，需明确；第二步了解该需求具体的使用情况，2W1H（谁，什么时候，怎样做），业务术语澄清，并了解该需求的使用频率及满足不了的后果，涉及到哪些人；第三步，提出建议，分别列出可行方案，成本比较，提出建议，对用户而言的优缺点等，并可简单问一下有无其它类似需求。
识别业务场景，目的是让用户产生共鸣，实现“用户为中心”的需求获取与理解，具体技术表现为用例和用户故事。
用例即业务场景、使用场景，比如同样是增删改查，不同的用户就会有不同的使用场景，比如图书管理员需要新增图书时可能有两种情况：办理图书入库、办理遗失图书返库，那我们如果简单定义成新增图书就不如定义成办理图书入库、办理遗失图书返库更容易被使用者接受。
用例也是有边界的，那么多大才算是合适的用例呢？我们把这个边界称为粒度。实际上一个用例就是一个完整的业务场景，应该是独立的、可汇报的、可暂停的单元。在一个信息系统中，业务流程是指不同岗位之间通过协作满足外部服务请求的过程；而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动。因此，从某个角度而言，粒度是由组织分工决定的。
用户故事，就是让用户或用户代表使用固定格式描述其需求，具体格式为：“作为xxx（角色），希望通过系统xxx（解决方案、功能要求），以便达成xxx业务目的、要解决的业务问题”。如果用户故事过大，还需要明确粒度的标准，对故事进行拆分。