对于特定的招标型项目，用户需求一般会体现在SOW工作说明书或招标相关文件里面。用户需求是从用户期望角度出发，提出的为了解决用户实际问题而提出的产品在功能或非功能上应该具备的各种特性。对于IT项目，最好是在项目启动阶段就已经确定好了用户需求，用户需求是软件项目范围的重要输入，在项目计划阶段或执行阶段还在确定用户需求必然会存在范围蔓延或镀金的问题。项目范围不明确和不受控是导致IT项目频繁变更和延期的重要原因。
1.用户需求和产品需求的关系
用户需求是从特定用户角度出发，而产品需求则是从推出通用化的产品出发，这是两者最重要的区别。不考虑产品需求，不从产品通用性出发会导致项目最终产品只能满足特定用户需求，完全是一单子买卖，首先是导致产品营销范围狭隘，同时也不利于推出通用化的产品，形成企业的核心竞争力。
用户需求需要向产品需求转换，转换的重点就是考虑用户需求的共性，考虑如何使产品每具备一个功能特性就能够满足更多的用户需求。用户需求收集->分析和归类->该需求的根源->抽取共性->形成产品需求，通过这种方式形成的产品需求有利于后期产品的通用化。我们在软件产品开发过程中使用一些框架，公用组件，分层等各种架构要素目的正是为了满足产品的可扩展性和配置性，而不是单单满足当前的用户需求，虽然这样在软件开发过程中可能会花更多的工作量，但投入的成本是完全值得的。
2.用户需求和软件需求的关系
用户需求通过分析，开发和挖掘后形成软件需求。用户需求和产品需求就已经确定了产品范围，软件需求开发属于项目执行阶段的工作，其重要的输入就是产品的范围。用户需求是从用户角度，而软件需求更多是从系统实现角度考虑。用户需求回答我要什么，而软件需求回答系统通过什么方式，途径提供给用户你需要的。
需求挖掘和开发是软件需求要解决的重要事情，用户需求提出的需要什么背后隐藏着用户所面临的问题，要什么仅仅是用户从自身角度提出的解决方案。因此软件需求不能拿着用户要的就去做开发，而是搞清楚问题和根源，从软件系统的角度来考虑是否有更好的方法能够解决用户说面临的问题，这也正是软件工程强调的系统分析的重要性。
用户一般对软件系统或软件开发并不清楚，因此用户需求本身并不会更多的考虑功能的易用性，性能和安全等问题。而在软件需求开发中这也是需要重要考虑的非功能性需求，一个功能如果开发出来了不易用或不好用，用户是无法满意的。
3.用户需求收集和调研
用户的业务场景，业务流程，业务规则，组织结构和岗位角色是重要的用户需求调研内容。调研的目的是为了搞清楚用户的业务现状和问题，而不是简单的问到用户要什么，必须要通过用户想要的东西去挖掘用户实际面临的问题。一个耕地的农夫可能告诉你的是他想要一头不吃不喝，每天还能干24h的耕牛，如果拿着这个需求回去开发产品是必然失败的。这个时候需要的是顾问和需求人员多年的经验积累，业务先进的管理方式和模式的积累。有了这些你会告诉农夫他需要的可能是一台比牛还便宜的自动耕土机。
收集用户需求->发现用户问题->通过业务流程和规则的分析挖掘根源->提出更佳的解决方案。只有通过这种方式开发出来的产品才可能真正解决用户问题，提高效率。软件产品创造客户价值才可能实现。
4.不切实际的需求
用户都有攀比心理，提出的需求有时候往往并不是自己真正需要。也有可能是我们在做需求分析的时候盲目的引入他人的最佳实践，以为最佳实践就是万能的可以解决问题。这些都是极端无效的做法，在我们开发用户需求过程中应该本着切合实际的做法，开发能够解决用户实际问题又最少投入的方案。
如果你是销售笔记本电脑的，如果来了一个用户仅告诉你给我最贵的笔记本电脑的时候，该如何做？是否为了眼前的获利就去开发这种最贵的电脑，为了少数用户群的获利而损失了更多主流的用户往往使我们得不偿失。
