1.概念定义
2.需求层次
3.需求工程
4.实际需求工作
需求在wikipedia中的基本意义讲是需要与欲求的意思，也可以解释为了达到某一目标/诉求的欲望，而在软件工程当中软件需求可以定义为
用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能
需求分析（Requirement Analysis）可以理解为调查用户对实现某一需要和要求，结合实际的目标、现状、实力和技术等因素，通过深入分析，确定出可行性计划/实施方案，并且完整描述出来的一个过程。现实中目前更多应用在软件工程学科上（但不仅限于软件工程）。
软件需求主要包含三个不同的层次：
- 业务需求(Business Requirement)
反映了组织机构或客户对系统、产品高层次的目标要求 - 用户需求(User Requirement)
描述了用户使用产品必须要完成的任务 - 功能需求(Functional Requirement)
定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求
用一张图来区分三者的区别。
需求层级
在软件项目生命周期中，需求分析前期重要的一环，尤其是在一些瀑布流式开发模型的项目中，前期更要投入大量时间和精力。
在需求工程中主要分为：
- 需求调研/获取
由分析人员通过座谈、走访、问卷、召开座谈会、脑暴、场景和用例分析等形式，深入了解用户对建立信息系统的需要和要求。
关键词：计划 沟通
根据需求的层次不同，需求的主要调研对象和需求可以是
- 业务代表、公司组织机构高层对系统所实现的愿景和目标的描述
- 一线员工、用户对系统实现的功能，达到的效果的描述
- 为满足市场而实现的主要需求
- 竞品所具备而不可或缺的需求
在同业务方/用户进行调研前，建议首先构建好调研的计划及主要内容框架，建议（但不限于）可以采用5W2H方法，开始可以主要明确几方面
（1）目前业务实际情况是怎么样？主要的业务流程？
（2）需要产品/系统实现哪些业务目标？
（3）涉及的用户角色都有哪些？用户有什么特点？
（4）具体的业务场景？
（5）是否存在上下游系统对接等情况
（6）……
业务方/用户对自己理解的业务描述过程中，往往与自己实际需求方面有很大的差异，提供（陈述、表达）的需求往往不是真是的需求，所以在在调研前，建议首先熟悉下目标用户的业务，这样在调研过程中能够对需求有个整体方向的把握，结合己方当前实力、技术等方面，启发和引导用户发现实际业务中存在并要解决的问题，发现潜在需求，也能够使需求人员尽可能的用更少的精力对更全面的需求进行获取。
需要注意的是，这一阶段从用户获取的一定是最原始、不经过个人加工的需求。
- 需求分析
需求分析是对获取的用户需求，通过综合考虑组织目标、现状、技术条件、投资能力等因素，从信息系统目标、结构、功能、性能、风险等方面进行深入分析，最终确定出合理、可行的信息系统需求。
关键词：完备 合理
需求分析阶段需要针对调研和获取的需求进行分析匹配，把抽象的业务具象化，提出一个可行性的方案，可以针对总体目标对需求进行拆解，由大结构出发，自上而下进行分析
目标拆解
针对产品/软件，可以从以下几个角度进行：
（1）总体目标
（2）业务流程
（3）功能点
（4）数据要求
（5）用户角色
（6）用例
（7）……
实际情况中，来自用户的第一手需求往往是不明确、片面的信息，需求分析阶段就是对需求进行合理化加工的过程，这一阶段通常和需求调研阶段是并行或往复的，对用户需求修改、补充的阶段会发现需要再次调研确认的情况，如果这一阶段需求出现了缺陷和漏洞，在后续的开发阶段问题可能会被放大，解决问题的代价成本也会增加，所以及时与业务方/用户进行沟通，以便于对需求有一个全面完备的了解，在前期尽可能的给出一个全面合理的可行性方案。
- 需求定义
建立信息系统的需求说明文档，把需求分析的结果采用规范的形式描述出来，形成需求规格说明，作为下面开发工作的依据。
针对文档面向的用户不同，在编写会区别为客户需求文档供给客户/业务方，软件需求文档供给与开发人员，或是PRD等等形式，主要针对不同的人群在编写的侧重点和描述上有所差异。
- 需求确认
由分析人员通过一定手段对初步确定的信息系统需求的正确性和可行性进行验证，以确定正确和可行的需求，排除不可行的需求。也可称作需求检验，需求人员如果在前期可以针对存在的问题进行纠正，就可以避免后期问题被放大的风险。
常体现在三种情况进行这一环节工作，
（1）自查
（2）需求评审
（3）用户审查
总结：在进行需求调研、分析时，要考虑到实际的业务场景，考虑到业务方具体的业务复杂程度，对于产品/业务系统来说，对业务的熟悉学习是开展需求的良好基础，所以在实际需求工作规划前，对业务进行充分的深入是开展需求工作的第一步。
网友评论