由于做正确的事远比正确的做事重要，一个软件项目从立项开始，为确定项目的边界，首先就是要搞清楚软件需求，所有的工作都是围绕着需求而展开，只有搞清楚了需求才能使项目不迷失方向。但是甲方不同层次的用户对需求的关注点是不一样的，越是高层的用户，越是关注系统解决所能解决问题和痛点，在理解用户高层次需求的时候，更应该以问题驱动，搞清楚用户面临的实际问题？然后在分析过程中再去思考怎么用技术手段解决他们面临的问题。对于团队内部，项目管理人员，需求分析人员，软件开发人员，测试人员对需求的理解层次也有差异的，为了提高沟通效率，需采取不同的语言将需求进行不同层级的抽象。
对于开发者而言，所有软件功能的开发都应该一一征求用户的意见，分清楚哪些是业务需求、哪些是用户需求、哪些是功能性需求和非功能性需求，对整个软件的开发有着重大的指导意义；只有当开发人员对整体需求有了明确的目标后，才可以按部就班快速有效地进行功能项开发，以避免系统开发偏离需求。
按照一般的分类方法，需求有以下分类方法：
1、业务需求（Business requirement）：这个也许是项目最原始，最高级的需要。项目中大部分的操作或过程都要围绕解决业务需求而展开。业务需求表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（ vision and scope ）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。
2、用户需求（user requirement）：用户需求描述的是用户能使用系统来做些什么或用户要求系统必须能完成的任务。通常用用例、场景描述和事件――响应表来进行表达。
3.干系人需求（Stakeholder requirement）：项目的干系人既可能是公司内部也可能来自甲方单位的人员，公司内部高层管理者可能为了项目的远期愿景提出一些额外的需求，对现有需求做一些补充，这些都需要统一考虑。
4、解决方案需求（resolution requirement）：一般我会叫它为“系统需求”或“技术需求”。它是为了满足业务需求和干系人需求，我们提供的产品、服务或成果必须具备的特性、功能和特征。解决方案可以分解为功能需求和非功能需求：
功能需求（functional requirement）：是关于产品能开展的行为。比如流程，数据，以及与产品的互动。功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
功能需求通常记录在软件需求规格说明（SRS）中。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。
非功能需求（non-functional requirement）：是对功能需求的补充，是产品正常运行所需的环境条件或质量，从不同方面描述了产品的各种特性。比如移植性、完整性、效率，健壮性，安全性、性能、可扩张性、服务水平等。系统与外部世界的外部界面，以及对设计与实现的约束。
约束（constraint）：限制了开发人员设计和构建系统时的选择范围，如局限于软件工程学科。
一个具体的例子：
业务需求：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。
用户需求：可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。
功能需求：可能包括以下几个部分，错误定义，错误查找，错误发现，错误高亮，错误列表显示，错误替换等。
