需求分析(一)概念、方法、实践步骤1.概念、方法、实践步骤需求分析阶段主要通过收集、分析、导出的方法，将客户、业务、用户的需求转换为对应的（软件）系统需求的过程。

典型的工作产品：软件需求说明（Software Requirements Specifications，以下简称SRS）其主要包括系统基本概要、业务功能、系统功能（性能、安全性、信赖性、扩充性、移植性、多语言对应性等要求）、接口功能要求等内容。

1.1 需求分析阶段的主要活动需求分析阶段的主要活动可以分为需求开发、需求管理2类：需求开发通过对客户、业务、用户、原系统等调查获取原始的需求，经过需求分析逐步识别并使业务具体化，通过形成制作规格说明书（或SRS）使业务系统化，项目团队同客户、用户逐步达成共识对需求得以最终确认，其间可以通过系统建模、POC等方式评估需求的可实现性。

需求管理在需求开发过程中，通过需求范围认定、需求形式化记录、需求数据库建立、需求状态跟踪、需求变更分析和波动评估、需求评审控制等活动，通过使用需求管理工具等手段，实现对系统需求按基线进行控制和管理。

其核心内容变更管理、版本管理以及需求跟踪。

1.2 需求开发的主要概念以及核心步骤业务需求反映了企业或组织对（软件）系统的业务要求，通常也包含问题或机会的定义。

问题是指企业或组织运作过程中遇到的问题，例如物资供应脱节、用户投诉量大、客户流失率较高等。

机会是指抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务、网上银行、基于即时通信的工作协同系统等。

业务需求通常由管理人员提出，业务需求的解决往往要结合制度、（人员）能力、系统功能等多方面综合解决。

另外,业务需求也反映了企业或组织对（软件）系统的高层次目标要求，就是系统的建设的目的以及目标。

用户需求是指描述用户使用（软件）系统需要完成什么任务，怎么完成的需求，通常是在问题定义（业务需求）的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。

解决如何使用（软件）系统完成具体工作。

软件系统需求是在业务需求的指导下，对用户需求进行整理、分析、提炼，从而指导开发的、更精确的、规格化的需求。

一般来说，软件需求可以作为软件验收依据与合同契约。

软件系统需求可以分为业务功能需求、系统功能需求、设计约束等方面的内容。

⏹业务功能需求：（软件）系统必须完成的业务功能，即为了向它的用户提供有用的功能，产品必须执行的动作。

这部分工作将分散的用户零散的需求采用结构化的方法去定义，以便支撑后续的设计、开发、测试。

⏹系统功能需求：（软件）系统必须具备的功能、性能、属性。

包括系统性能（功能速度、响应时间、恢复时间等等）、可靠性、易用性、安全性、移植、部署等方面的内容需求。

⏹设计约束的需求：影响系统实现的各种设计约束，包括开发语言、数据完整性方针、资源的限制、运行的环境的要求等等。

2.主要流程需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。

1．制定及修改需求开发计划包括建立需求团队的组织并授权、对需求分析阶段的WBS 进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。

2．需求调查以及分析的过程，主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。

需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。

3．需求验证环节主要通过原型（Prototype）、POC（Proof of Concept）、用例（Use Case）或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。

•原型（Prototype）模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定程度的模拟。

对于用户体验为主的系统往往可以起到很好的效果。

•POC（Proof Of Concept）原意是“为观点提供证据”。

对于关键的技术或者业务模型，论证需求、设计的可实施性,评估和确认概念设计方案，POC的评价可能引起需求和设计的调整。

一般来说，进行POC的条件：1. 论证业务中涉及到的模型或者算法的可行性。

2. 论证技术模型实现的可行性、成本等。

•用例（Use Case）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。

每个用例提供了一个或多个场景，该场景说明了系统是如何同最终用户或其它系统交互(interact)的，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

4.需求规则说明(SRS)制作：通过需求调查和初步的需求验证后，可以建立需求制作的准则，包括确认需求规则说明(SRS)的内容、制作方法、制作工具、质量标准等等。

根据需求制作的准则制作需求规格说明（SRS）,好的需求规格说明（SRS）应该遵循正确、无歧义、完备、一致、分级（重要性或稳定性）、可验证、可修改、可追踪的原则。

5.需求确认：通过组织各级评审对需求分析阶段的产物，尤其最重要的结果产物需求规格说明（SRS）进行确认，以确保相关人员理解一致。

从评审方法来说，可以根据情况分为需求开发组组内评审、客户外部评审、关键关系人评审等等。

需求分析的流程往往因项目规模、作业人员、系统类型差异很大，因此必须根据实际的情况合理的裁减，以下举例几种不同情况下的具体流程：例：简明的需求开发的流程第1步:确定实现的目的、目标，基本业务需求、业务定义以及相关的评审。

从达到目的、目标的角度，重新评审业务定义，总结业务需求。

（确认客户实施的业务要求）第2步:使业务具体化，进行软件系统的定义（系统需求定义）。

从目的的角度，进行业务定义（功能，步骤），对系统结构进行讨论、对所要进行系统化或计算机化的功能、流程进行定义。

第3步:一边定义业务需求、系统需求、一边对运行上的相关要求（非功能需求）进行总结运行时间，安全应对、访问权限等系统需求以及设计约束在业务需求的基础之上、考虑系统上的限制条件之后逐步形成。

例：软件工程类的典型流程主要特征：强调客户协同、提高运作效率、屏蔽技术风险、加强边界管控✓强调同客户协同，比如确定各种约定，包括截至时间、交流方式、成果物；✓强调计划管控，起目的确保进度和成本，人力资源合理使用；✓采用《问题回答管理票》的方式加强需求团队以及客户的协同作业，提高生产效率，确保质量；✓加强需求边界管理，控制项目整体成本；✓提前对技术关键环节（技术解决方案、技术构架）进行论证，控制技术风险，减少技术带来的成本损失；✓强调需求最终确认；案例3：软件产品类的典型流程主要特征：缩减开发周期、支撑跨部门运作、提高创造性、强调用户体验设计。

✓∙强调计划性以加快研发进程，缩减产品开发周期。

✓强调跨部门协调组织，建立统一的需求团队。

✓强调行业学习、创新以及交流。

✓分版本制作以适应产品的创造、快速变化、市场需求的适应性、进程以及成本控制。

✓强调交互原型的重要性，加强用户体验性设计。

需求分析(二)内容需求分析阶段产物可以包括需求调查报告、需求规格说明、可行性报告等多方面的内容，但是一般来说需求规格说明（硬件、软件）是最终的产物。

过程中的关键产物还包括需求调查报告。

3.1 需求调查报告通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。

需求调查常作为一个中间过程成果，主要强调对业务、系统的现状进行归纳整理，同时对业务中的问题、各类期望以及优化方案进行记录和整理，通过初步分析形成结构化描述。

一般需求调查报告包含目的、目标、范围、业务域概述、组织机构以及对应的岗位权限、业务现状、业务优化的期望、业务规则（算法、逻辑）、输入输出数据、其他系统的交互（如果有）等内容。

1.业务领域业务领域主要梳理并整理项目的作业范围，同时在业务上进行梳理了解并描述各领域间的关联。

例业务领域以及关联关系2.业务现状业务现状主要描述当前业务工作中的各种处理，可以通过业务流程描述（常见可以用泳道图描述）、逐个业务场景描述、对系统功能需求描述、相关输入输出信息以及优化分析的期望等几个方面进行描述。

如果原业务有对应的（软件）系统，也可以收集原系统的对应的资料进行整理。

1)业务场景描述: 对业务工作中的每个处理进行对应的描述，并通过记录和整理形成结构化的场景描述。

场景描述一般包括定义场景的名称、场景相关的角色、场景的详细描述、结果产出以及当前的存在的问题以及对应的期望。

需要注意的是任何系统的引入都会一定程度地改变当前的工作模式和工作方法，所以对当前的存在的问题以及对应的期望的支撑程度往往决定了系统的价值，也必然是今后（软件）系统的焦点。

当然这些问题以及期望可以采用多种方式解决，比如通过管理制度的建设、人员能力的加强、计算模型的优化、系统化（计算机化）等等。

其实需求分析阶段的主要工作就是识别、分析那些工作是可以系统化或计算机化的工作，并辅助制度化管理流程、提高人员能力等工作提高作业的效率和质量。

例，一个移动终端希望提高购物的便利性，哪些是可以系统化的呢？比如支付可以系统化做到移动支付，同时第3方支付还需要法律的支撑等等。

2)业务功能需求描述：结合业务场景对系统的业务功能进行描述。

一般包括前置条件、输入、输出、业务规则、典型动作等。

业务功能需求描述着眼于使业务具体化，进行（软件）系统的需求调查或定义，描述方法也更加的结构化。

这一步骤中，业务规则是重要的核心，是业务场景中具体处理的细节要求，一般包括处理的详细流程、关键数据的计算方法、样式要求等等内容。

3)业务数据描述：对业务场景、业务功能需求中的输入和输出数据进行结构化整理的过程。

多数新建系统，业务数据往往是分散和凌乱的，通过这个过程需要对相关的数据进行结构化的整理，并为后续的规格定义提供基础。

4)其他：对业务现状整理过程，对一些过程性的资料比如原始的单据、表单通过扫描等方式进行收集汇总。

对原系统可以通过收集设计资料、屏幕截图等方式汇集整理。

3.2 软件规格说明书(SRS)通过需求调查以及分析、需求验证环节等步骤，需求规格说明书使业务具体化，最终对软件以及硬件系统的功能进行明确定义。

需求规格说明（SRS）对功能进行结构化的描述，以指导后续设计、开发、测试工作的开展。

需求规格说明定义系统愿景、系统范围、业务功能、系统功能、约束条件等方面的需求。