需求分析(一)概念、方法、实践步骤
需求分析(一)概念、方法、实践步骤
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）对功能进行结构化的描述，以指导后续设计、开发、测试工作的开展。需求规格说明定义系统愿景、系统范围、业务功能、系统功能、约束条件等方面的需求。主要描述系统“What to do”，而后续的设计要描述系统“How to do”。
1.项目目标&系统范围
项目目标&系统范围描述项目发起的背景、希望解决的问题、系统的目的和目标以及核定项目的范围。一般可以包含以下内容项目背景（Project Background）、现状（Current Situation ）、当前面临的问题（The issues we are facing now）、项目目的以及目标（Objectives & Goals）、项目范围（Project Scope）、业务流程/功能范围（Business Process/Function Scope）、涉及组织范围（Organization Scope）。
1)项目目的以及目标（Objectives & Goals）应着眼于（系统）未来的价值，它应该是可以
量化、可评价、可实现、有价值的。系统的设计、开发、测试、验证、发布、运行等工作都围绕项目目的以及目标而进行。
需要注意：
项目目的以及目标应该细化分解成一些核心的指标，这些指标今后是可以量化或评定。比如“节省人力和物理的投入同时提升客户满意度”可以设定为“原有维护人员规模可以缩减75%，物理投入减少80%”等。设定明确的指标可以更加有效的推动（软件）系统、人员、制度的有效的结合，这个也是项目成功的必要条件。很多软件项目到后期往往为了上线而上线，往往不能取得实际的效用，这个和前期目标不明确有关。实际上，当一个项目经过数人或数百人的数月或数年辛勤工作，经过了设计、开发、测试、反复的缺陷修正、上线以及运行后，也许值得欣慰的就是达成了项目目的以及目标。最悲剧的故事就是“不知道原来的目标是什么？”。
项目目的以及目标也可以是多方面的，比如对用户、操作员、管理人员、决策人员分别设定不同的目标，这些也是今后系统化以及设计的指导原则。
制定项目目的以及目标需要多方面的反复讨论和确认，尤其是项目的关键决策者。通过这些目的和目标，起码我们可以明确这个系统未来的价值。有些情况下，决策人员并不是这些方面的专家，需求开发人员应对需求及目标提出建议和解决方案，然后耐心等待决策环境的成熟，决策慢的一个好处就是可以减少决策失误。
2)范围可以包括项目范围、业务范围、功能范围、组织范围等等方面的内容，界定了那
些工作是需要做的，那些不需要做。在项目中对于预算、成本、WBS、计划等方面起决定性作用。
2. 业务功能需求
业务功能需求往往主体描述系统"What to do"，不同类型的系统业务功能需求的侧重点也不太相同，那么描述的方法和内容也有差异。
不同类型系统业务功能需求的侧重点不同
?联机事务处理系统：主要的本质是流程的电子化，所以固化流程是主要工作，需求的描述也围绕着流程
进行。
?管理分析信息系统：主要的本质是数据信息化，需求的描述围绕着信息数据加工，即数据的输入、变换、
处理、输出，报表往往需求的关键线索。
监控系统：主要的本质是数据收集、状态控制等方面的内容，其本质往往是状态的管理、接口标准的处理。
这也是为什么在通过需求调查和初步的需求验证后，需要讨论并建立需求制作的准则，针对不同类型的系统，采用适合的方式、方法、工具来更有效的描述业务功能需求。无论采用什么方式、方法描述，那么业务功能需求的共性内容包括:业务领域、组织机构、岗位、
权限、功能（用例）清单、用例说明、界面交互、数据实体、接口、规则模型等。
1)业务领域范围：主要描述业务、功能的分类以及对应的范围。
2)组织机构、岗位、权限：主要包含系统涉及的组织、岗位、权限的要求。一般内容包
括组织体系图、岗位说明、业务以及系统相关的权限要求。
系统功能以及数据相关的权限要求，往往会贯穿整个需求规格书的各个章节。这种情况下，我们可以
将权限要求汇集在一个单独的章节中，以便其他章节引用。另外，权限相关的内容在系统实际导入的时候，还需要更具体的需求，比如哪些人、哪些功能等等。
3)功能（用例）清单：根据需求分析的结果，对业务逐步进行分类，对每个分类进行细
化梳理功能，形成用例清单。功能（用例）清单一般包括分类、功能概要说明、功能编号等等方面的内容。
4)用例说明: 一般包含用例对应的编号、名称、场景概要描述、前置条件、流程、前置条
件、业务规则等内容。对于复杂的流程，也可以用流程图的方式描述对应的流程
5)界面交互：界面交互往往是关注的重点，在需求分析阶段可以通过原型的方法同客户
沟通并验证业务需求。对于界面交互比较重要的项目，可以详细描述页面的需求，一般包括以下内容：界面的迁移、界面原型或式样（可以采用高保真图或线框图）、界面元素（输入、输出）、界面动作等等。
例, 界面的迁移：描述画面以及处理间的关系。
例，界面线框图：用来描述界面的式样,一般可以用一些简单快捷的工具制作。
6)数据实体：记录业务过程中的输入、输出数据的详细内容。
7)接口说明：本系统内部以及其他系统间的接口，接口需求因不同业务功能差异很大，
通常接口需求涉及模块对象、处理流程（时序）、性能以及容量、数据传输、数据格式、安全等方面的内容。
8)规则模型：在业务处理中的专用的规则模型，比如核心的预算预估模型、各类精算模
型、成本归集模型、图像处理识别模型、温度控制模型、GIS中犯罪轨迹追踪模型等等。
规则模型往往建立在一定的专业基础上，在理论模型的基础根据实际情况进行修正优化。
规则模型的需求内容要根据实际的情况进行确定。常见的内容有基本模型、优化模型、配置调优等方面的内容。
3. 系统功能需求
系统功能需求指除了业务功能外，系统本身根据项目目标、目的以及支撑业务功能的实现，（软件）系统本身应该具有的功能需求，一般来说系统功能包含质量、性能等方面的属性。一般有性能（运行速度、响应性、在线用户量等）、安全和保密、可靠性、运行、移植、维护、部署、数据容量等方面的系统功能需求。常见的系统功能需求种类有：
常见的系统功能需求种类经验汇总
1)系统功能性需求：工作流功能、系统离线功能、版本发布管理功能、搜索功能、日志管理、配置管理、
系统异常处理以及通知机制、报表生成以及定制机制等等。
2)易用性需求:多设备支持、多语言支持、多浏览器支持、自适应界面调整、系统超时数据自动保存、用
户操作易用性（包括易理解性、易学习性、易操作性）。
3)可靠性需求：架构可靠性、数据及操作可靠性、操作以及数据容错处理需求（比如系统应有全面、完
善的检验和明确的错误提示信息，系统界面被破坏或系统发生故障，系统仍能给予操作者必要的提示，使其按照相关提示退出系统，并最大程度保留用户的工作成果。）
4)性能需求:用户数量、页面（接口）访问性能要求、数据同步性能要求、各应用场景（比如模块、网络、
数据库、Web、应用、接口及业务场景）的性能以及容量要求、超长时间操作处理需求。
5)可扩展性、兼容性需求：系统在技术架构上、各类功能、接口、标准以及系统部署上支持可扩展性需
求。对软件、硬件等环境的兼容性。
6)安全性需求：多重组织架构体系安全支撑、权限控制（用户组、用户、角色）及设置、安全构架集成、
应用安全控制、数据以及传输安全、数据备份安全、数据操作安全等
7)维护需求：系统上线以及更新需求、数据管理/数据迁移/数据维护需求，包括数据同步、数据管理工
具、数据清洗、数据补采、数据补录等方面的需求。
8)灾难备份需求：硬件、软件、数据、网络等对应自然、病毒等灾难的处理需求。
9)可配置性需：用户界面及系统功能配置需求、系统基础数据配置需求、系统后台配置需求等。
10)系统环境需求：在开发、测试、生产、培训等环境的数据以及应用多种环境应用需求，服务器在各种
温度、湿度、磁场、能耗下的环境需求。
11)用户文档及帮助系统需求：业务操作相关、系统开发相关各类学习、培训、实践需求。
12)支持性/服务性需求：系统日志功能、系统配置、状态监控、数据异常处理（工具）等需求。
4. 约束条件
约束条件一般指由其他标准、硬件局限等引发的设计约束。常见的约束条件有：网络带宽以及环境约束、客户端选型约束、服务器端操作系统约束、数据库选型约束、开发环境选型约束（比如开发语言）、开发的结构（比如B/S,C/S结构导致的设计差异）、法律法规、各类业务标准、运行环境（比如设备能耗、内存、CPU使用率）等等。
需求分析(三)关键点
4.关键点（Know-How）、运用技巧
4.1作业准则以及管理准则
需求分析的流程往往因项目规模、作业人员、系统类型差异很大，因此必须根据实际的情况合理的裁减。从软件工程的角度来说，需求分析阶段可以将需求开发的各种活动，形成对应的“作业准则”比如定义阶段控制目标（过程目标、质量目标、生产效率目标）、阶段入口准则、阶段执行的相关准则、阶段过程定义（输入、执行步骤、出口准则、输出）、定义质量保证点、成果物等。除围绕需求开发的各种活动外，还有围绕着需求变更管理、版本管理、需求跟踪、进度、成本管控等各种需求管理活动。比如常见的有评审管理流程、（文件）版本管理、需求变更管理、问题跟踪管理、（需求）跟踪矩阵管理、决策管理、风险管理、会议管理、工作汇报管理、考勤请假管理、非正式交付物管理、正式交付物管理、需求调查准入标准等等多方面的流程，这些可以形成需求分析阶段的“管理准则”。通过“作业准则”以及“管理准则”可以控制整个需求开发阶段的进程、质量以及成本。
4.2 需求验证
1. Q&A管理
软件开发的过程实际上是个学习的过程，在学习中每个人（包括客户、用户、设计、开发、测试人员）理解以及学习的速度是不同的，软件工程的过程从某种意义上就是协同团队中的每个人学习进度。既然是学习那么就会有多种多样的问题，快速解答问题显然是非常重要的环节。Q&A(问题&回答)的管理实际贯穿整个工程的生命周期，在需求分析阶段，Q&A(问题&回答)的管理可以加快项目团队内部的学习以及加速项目团队同客户、用户的沟通。Q&A(问题&回答)的管理过程并不复杂，主要就是提出问题、内部知识共享解决、外部确认解决、监控并管理整个过程。Q&A(问题&回答)经常可以简单地采用EXCEL表的形式（也可以项目组、客户、用户共同使用专门的系统来共享），定期发送给相关人员，这样可以非实时的处理，不影响正常的工作。另外，Q&A(问题&回答)可以在固定的时期，集中的进行处理，以加快确认的过程。
2. 原型
原型模型本身是一个迭代的模型，是为了解决在产品或系统开发的早期阶段存在的不确定性、二义性和不完整性等问题。原型是（软件）系统一个早期可以运行的版本，它反映了系统的部分重要的特性，用于试验和评价，以指导后续的设计、开发、测试等工作。通过建立产品原型使相关人员更易理解系统未来的功能。原型只是真实系统的一部分或一个模型，部分实现了产品或系统的功能。比如，在一些交互性系统中，可以模拟实际的操作，甚至对关键的输入输出数据也可以一定程度的模拟。这样用户可以感受到今后系统的功能。一般通过原型可以更快的确认系统的交互部分，比如系统的操作、画面的迁移、画面（风格外观、动作、要素等）等多方面的内容，所以在以交互为主的系统需求开发的早期就可以开展原型制作的工作。
原型的开发要根据情况制定一些策略，一般考虑的要点如下：
1) 原型是抛弃型还是进化型。原型中哪些内容可以在后续工程中复用。
2) 原型设计、开发过程中是否要验证技术的可行性、是否要验证工作效率以及工作方法的可用性。
3) 设计团队中是否配置了原型的开发所需要的设计、开发、测试人员。
4) 系统中哪些部分需要采用原型的方式，加强同客户、用户的验证。比如关键或复杂的部分功能进行原型制作，或将业务归纳成几种模式，对不同的模式制作对应的原型等等。
5) 制作原型所需要的预算、时间、成本等。有些原型的制作也需要不少的工作量，有些情况下原型制作本身就是一个单独的项目。比如，有些方案供应商就预先开发原型，以便争取项目的合同。同时有些项目在招标的时候，就要求必须对核心功能提供必要的原型等等。
6) 制作原型的所采用的快速工具，比如WEB站点的原型，如何有开发人员的参与的情况下，可以直接用HTML制作原型，不然也可以用PPT或其他工具“画”出原型。
7) 原型除能确认系统的操作、画面的迁移、画面（风格外观、动作、要素等）等方面的内容外，也可以对关键数据进行确认，所以有些情况下，还需要考虑对原型所涉及的数据（尤其业务数据）进行专门的制作。
从工作实践中经验证明，对于一些较为业务复杂或更关注交互的系统来说，需求分析阶段在规划的时候，就应考虑制作原型并配置对应的原型开发队伍（设计、开发、测试），对原型的目标建立、功能选择、构造确认、评价等过程进行合理管理，可以降低整理项目的技术、业务、人员、过程中的风险。
3. POC验证
POC（Proof Of Concept）原意是“为观点提供证据”，本质上是一种重要的评估技术。对于系统中的关键技术或者业务模型，论证团队和客户的设计，评估和确认概念设计方案，POC的评价可能引起需求和设计的调整。为屏蔽系统存在的业务或技术风险，在系统需求、设计的早期，我们可以设定POC来评估和确认这些业务或技术的模型，以减少项目的风险。对软件系统的研发而言，POC 的目的是为系统确定合适的业务模型（流程、方法等）、核心功能对应的实现方法、系统构架、系统或软件产品版本、有效技术方案以及运行维护等服务的方案等内容，或者验证建议的方案可行性。POC的最大价值在于在正式设计或规模实施以前，选择最优的方案。比如POC 在核心技术上的验证内容可以有：消息中间件、工作流、数据库、浏览器、跨设备、UI控件、报表、共通组件、系统集成等等方面的内容。
POC作为一种重要的评估技术，过程上可以归纳为以下几步：
1. 收集并识别来自业务、技术等方面的风险。
2. 评估、决策那些内容实施POC。POC的实施往往需要花费不少的时间和资源，应合理控制POC的范围。
3. 制定POC的目标、内容、实施方法、评估方法等要素，合理安排计划。
4. POC的实施以及POC报告：POC报告是POC的核心产出，它一般包含POC的目标、过程、方案、结果数据等关键的信息，实际上POC的整个实施都是围绕着POC报告而进行的。
5. POC评价和验证：评价和验证过程就是风险承担者讨论、评价、评估POC 报告并最终给出结论的过程。通过POC评价，可能提出调整规格和设计的要求。通常，在评价和验证过程结束时，有关设计的承诺、评审组的意见都将记录在文档中，这往往是系统开发的生命周期中一个重要的里程碑。
POC作为一个实用的评估技术不仅仅应用在需求验证方面，其实在实际的项目中，往往项目一开始就识别项目中的各类风险，其中业务、技术、人员技能等方面的风险，可以通过实施POC获得最优的方案。实际上当你参加有个项目时，就应该首先问“有什么样的风险？业务的？技术的？自己担心什么。”这时POC 就已经开始了。
4.4共性需求整理
从牛顿第一定律到万有引力，都说明世界万物是有规律性的。在写这篇文章时，好奇号火星探测器已经登陆到火星，我常想这真是一件神奇的事情，好奇号火星探测器从地球出发经过各种历程，竟然能飞到火星这个球上降落成功，而且还能拍拍照片。所有的这一切，都是因为人类掌握了相关的规律。我们所想所做就是找到规律、证实规律并合理的运用规律。针对任何软件系统也是有规律的，发现运用这些规律是一种乐趣，共性需求整理就是寻找这些乐趣的过程。通过共性需求整理我们可以发现业务、技术领域的各种规律，通过建立共性模型可以简化工作量，提高工作效率，发挥并创造价值。
概要设计、详细设计(四)心得体会
1. 设计一般来说是个学习迭代的过程、通过不断的评审&确认&改善达到成熟. 但是前提必须写出设计文档，而不能仅仅停留在脑袋里。
2. 分层、抽象、归纳、汇总是设计的主要方法。其中分层是最最基本的，而是绝大数设计人员不能掌握的（这个有点悲剧），归纳是常见的方法。
3.交互的设计往往是人们关注的重点，所以也要特别注意、特别设计。对于画面的风格、操作等我的理解是“美的事物，任何人都觉得美”。
4. 设计的完整性、严密性、可用性是成功的主要因素。
5.设计不等同于创造和创新，但是好的设计一定包含各种创新。
6. 多看看其他的系统，功能、交互方法、实现方式等，才会有思路，有想法。比如，画面色彩、布局等可以参考日本的网站，交互参考欧美站。多看才有比较！
7.系统/产品研发就是群体学习活动，什么时候学会什么完成。需求、概要设计、详细设计中如何描述、粒度如何划分，是要在前期就要思考的，这些是研发人员的“教材”。
软件需求分析的详细流程
第一阶段：总体把握，了解概况 接手一个项目，不要着急去了解需求，这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门，最好能指定本次项目的接口人。 该阶段的主要工作方法：客户访谈 输出成果：业务流程报告/调查报告（对客户方的组织业务概况和企业现状的一些总结） 第二阶段：详细了解业务，梳理业务流程 通过第一阶段的调研，了解客户业务概况的前提下，经过充分的业务调研准备，开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构，尽可能多的与相关基层人员进行诱导式的访谈，与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作，发现问题，提出改进的意见和建议。 该阶段的主要工作方法：访谈、业务分析、原型设计演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：需求细化和确认 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）
岗位分析方法与步骤
岗位分析方法与步骤 在我国，现在的大多数企业都施行了岗位责任制。在许多企业中，你都可以查阅到厚厚的一本岗位责任手册，在手册中有企业每个部门的部门职能和每个职位的岗位职责，书写得非常细致和系统。 岗位责任制的实施对企业来说应该是管理上的一个提高，但就现实情况而言，在多数企业里，岗位责任手册只是一套形式上的文件，并没有得到认真的落实。没有人根据岗位职责的内容来规范自己的工作，更没有将它作为真正的依据进行绩效考评。 岗位分析的方法 一、 观察法 观察法是指职位分析人员通过对员工正常工作的状态进行观察，获取工作信息，并通过对信息进行比较、分析、汇总等方式，得出职位分析成果的方法。观察法适用于对体力工作者和事务性工作者，如搬运员、操作员、文秘等职位。 由于不同的观察对象的工作周期和工作突发性所有不同。所以观察法具体可分为直接观察法、阶段观察法和工作表演法。 1．直接观察法 职位分析人员直接对员工工作的全过程进行观察。直接观察适用于工作周期很短的职位。如保洁员，他的工作基本上是以一天为一个周期，职位分析人员可以一整天跟随着保洁员进行直接工作观察。 2．阶段观察法 有些员工的工作具有较长的周期性，为了能完整地观察到员工的所有工作，必须分阶段进行观察。比如行政文员，他需要在每年年终时筹备企业总结表彰大会。职位分析人员就必须在年终时再对该职位进行观察。有时由于间阶段跨度太长，职位分析工作无法拖延很长时间，这时采用"工作表演法"更为合适。 3．工作表演法 对于工作周期很长和突发性事件较多的工作比较适合。如保安工作，除了有正常的工作程序以外，还有很多突发事件需要处理，如盘问可疑人员等，职位分析人员可以让保安人员表演盘问的过程，来进行该项工作的观察。
需求分析方法论
需求分析方法论 原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题： 1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能
职位分析的方法和步骤
职位分析的方法和步骤
在我国，现在的大多数企业都施行了岗位责任制。在许多企业中，你都可以查阅到厚厚的一本岗位责任手册，在手册中有企业每个部门的部门职能和每个职位的岗位职责，书写得非常细致和系统。岗位责任制的实施对企业来说应该是管理上的一个提高，但就现实情况而言，在多数企业里，岗位责任手册只是一套形式上的文件，并没有得到认真的落实。没有人根据岗位职责的内容来规范自己的工作，更没有将它作为真正的依据进行绩效考评。一、问题的根源 每家企业出现这类问题的原因各不相同。归纳起来，可以总结出以下几个根源： 1．没有职位分析 一些企业从来没有进行过职位分析，岗位责任手册中的内容都是原模原样地照搬其他企业的职位职责内容，有些可能会进行一些修改，但这种修改大多是基于管理者的主观意愿进行的调整。这样草率的做法，肯定不会的作出符合企业实际情况的岗位职责。2．职位分析没有更新 有些企业也曾经做过职位分析，但"一稿定终身"，企业并没有根据企业的变化来重新进行职位分析，修订岗位职责的内容，造成岗位职责的内容与实际工作不相符合。职位职责当然不会起到它的作用了。3．缺乏认真的工作态度 一些企业在进行职位分析时，起初可能充满了热情，但由于工作烦琐，职位量大，渐渐对职位分析失去了认真的态度。这样就使职位分析职位变得形式化了，并没有真实地反映出职位内容的信息，定出了不符合实际的职位描述和职位资格要求。4．缺乏一定的技术和经验 职位分析并不是一件简单的事务性职位，它要求职位分析人员有一定的专业素质和专业背景。这样工作并不是光靠工作热情就能做好。目前，我国企业现有的职位职责描述的质量都不是很高，比如有些岗位责任中只有工作内容，而没有工作责任。5．缺乏对职位资格要求的使用
需求分析主要流程
1.1主要流程 需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。1.1.1制定及修改需求开发计划 包括建立需求团队的组织并授权、对需求分析阶段的WBS进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。 1.1.2需求调查以及分析的过程 主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。1.1.3需求验证环节 主要通过原型（Prototype）、POC（ProofofConcept）、用例（UseCase）或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。 （1）原型（Prototype）模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 （2）POC（ProofOfConcept）原意是“为观点提供证据”。对于关键的技术或者业务模型，论证需求、设计的可实施性,评估和确认概念设计方案，POC的评价可能引起需求和设计的调整。一般来说，进行POC的条件：1.论证业务中涉及到的模型或者算法的可行性。2.论证技术模型实现的可行性、成本等。 （3）用例（UseCase）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场
软件需求分析重点-
软件需求分析重点 第1 章软件需求基础知识 返工的成本占了总开发成本的30%-50%，而对于返工的情况，70%-80%是国需求错误引起的。（11） 在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。（13-14）造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时，应该提供范围（最好的情况，最可能的情况和最糟的情况）或把握程度（“我有九成把握在三个月内完成”）。（14） 从产品的实际用户处收集需求这一过程是不可替代的。（18） 第2 章客户眼中的需求 某些需求问题源于混淆了不同层次的需求（业务需求、用户需求和功能需求）。（19） 要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。（20）不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。（22） 需求审阅是最有价值的保证软件质量的活动之一。（25） 需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。（25） 不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化。（26） 第3 章需求工程的推荐方法 熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和沟通能力，理解产品应用领域，并且掌握丰富的需求工作技术。（29）为每类用户选择代言人（31）
观察用户工作的过程（31） 跨项目重用需求（32） 过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。（37）38图表 不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。（38） 第4 章需求分析员 相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。（42） 优秀的需求分析员应同时具备出色的交流、引导和人际交待能力，具备技术和业务领域的丰富知识，以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。（44） 需求分析员必须研究可能出错的情形。（44） 第5 章确定产品前景与项目范围 第6 章获取客户的需求 能否让开发人员更准确地了解用户需求，将决定软件需求工作能否取得成功，进而影响到软件开发的成功。（62） 项目伊始就应确定谁来担任问题的决策人。（72） 第7 章聆听客户的需求 需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。（75） 需求获取的参与者在理解问题之前要抵制住诱惑，不要急于设计系统。 要强调用户任务，而不是用户界面，要强调根本需要，而不是用户表达出来的期望，这样有助于项目团队避免过早是制定设计的细节。 在软件开发中，需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。（76）
《Web项目测试实战》性能测试需求分析章节样章
5.1.2性能测试需求提取 复习了一些常见的理论概念后，我们开始性能测试需求的提取。这个过程是非常重要的，往往测试失败，就是因为在这个过程中不知道如何得到确切的性能指标，而导致测试无法正常开展。性能测试需求提取一般的流程如图5- 1所示。 图5- 1性能测试需求提取流程 分析提取指标 在用户需求规格说明书中，会给出系统的功能、界面与性能的要求。规范的需求规格说明书都会给出明确的性能指标，比如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，这些指标都会以可量化的数据进行说明。如果，实际项目并没有这些正规的文档时，项目经理部署测试任务给测试组长时，一般就会说明是否要对项目的哪些业务模块进行性能测试，以及测试的要求是什么的。最麻烦的就是项目经理或者客户要求给出一个测试部门认为可以的数据，这样非常难做的。可是“甲方”往往都是提要求的，“乙方”只能“无条件”接受！ 表5- 1需求规格说明书中的性能要求 表5- 1给出的指标非常明确，在测试过程中，我们只需收集用户登录模块的响应时间、登录成功率、并发数、CPU使用率、内存使用率的数据，然后与表5- 1的指标进行比较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。 大多数是没有明确的需求，需要我们自己根据各种资料、使用各种方法去采集测试指标。以OA系统为例，假设《OA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试工程师自己分析被测系统及采集性能衡量指标。 分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终用户经常使用的业务点，那么我们的重点应该在放在该模块上。一般我们可以从下面三个方面来确定性能测试点： 第一、用户常用的功能。常用的功能一旦性能无法满足，比如登录功能，从输入用户名与密码点击登录按钮到显示成功登录信息，花了5分钟，这样的速度是 人无法忍受的。而对于用户不常用的，比如年度报表汇总功能，三个季度甚 至是一年才使用，等个10分钟也是正常的，这些是跟用户的主观感受相关 的，得根据实际情况区分。
职位分析的方法和步骤
职位分析的方法和步骤 在我国，现在的大多数企业都施行了岗位责任制。在许多企业中，你都可以查阅到厚厚的一本岗位责任手册，在手册中有企业每个部门的部门职能和每个职位的岗位职责，书写得非常细致和系统。 岗位责任制的实施对企业来说应该是管理上的一个提高，但就现实情况而言，在多数企业里，岗位责任手册只是一套形式上的文件，并没有得到认真的落实。没有人根据岗位职责的内容来规范自己的工作，更没有将它作为真正的依据进行绩效考评。 职务分析的方法 一、观察法 观察法是指职位分析人员通过对员工正常工作的状态进行观察，获取工作信息，并通过对信息进行比较、分析、汇总等方式，得出职位分析成果的方法。观察法适用于对体力工作者和事务性工作者，如搬运员、操作员、文秘等职位。 由于不同的观察对象的工作周期和工作突发性所有不同。所以观察法具体可分为直接观察法、阶段观察法和工作表演法。 1．直接观察法 职位分析人员直接对员工工作的全过程进行观察。直接观察适用于工作周期很短的职位。如保洁员，他的工作基本上是以一天为一个周期，职位分析人员可以一整天跟随着保洁员进行直接工作观察。 2．阶段观察法 有些员工的工作具有较长的周期性，为了能完整地观察到员工的所有工作，必须分阶段进行观察。比如行政文员，他需要在每年年终时筹备企业总结表彰大会。职位分析人员就必须在年终时再对该职位进行观察。有时由于间阶段跨度太长，职位分析工作无法拖延很长时间，这时采用"工作表演法"更为合适。 3．工作表演法 对于工作周期很长和突发性事件较多的工作比较适合。如保安工作，除了有正常的工作程序以外，还有很多突发事件需要处理，如盘问可疑人员等，职位分析人员可以让保安人员表演盘问的过程，来进行该项工作的观察。 在使用观察法时，职位分析人员应事先准备好观察表格，以便随时进行记录。条件好的企业，可以使用摄象机等设备，将员工的工作内容记录下来，以便进行分析。另外要注意的是，有些观察的工作行为要有代表性，并且尽量不要引起被观察者的注意，更不能干扰被观察者的工作。 二、问卷调查法 职位分析人员首先要拟订一套切实可行、内容丰富的问卷，然后由员工进行填写。问卷法适用于脑力工作者、管理工作者或工作不确定因素很大的员工，比如软件设计人员、行政经理等。问卷法比观察法更便于统计和分析。要注意的是，调查问卷的设计直接关系着问卷调查的成败，所以问卷一定要设计得完整、科学、合理。 国外的组织行为专家和人力资源管理专家研究出了多种科学的，也很庞大的问卷调查方法。其中比较著名的有： 1．职位分析调查问卷PAQ 职位分析调查问卷是美国普渡大学Purdue University的研究员麦考米克等人研究出一套数量化的工作说明法。虽然它的格式已定，但仍可用之分析许多不同类型的职位。PQA有194个问题，计分为六个部分：资料投入、用脑过程、工作产出、人际关系、工作范围、其他工作特征。 2．阀值特质分析方法TTA 劳普兹Lopez等人在1981年设计了"阈值特质分析"TTA问卷。特质取向的研究角度是试图确定那些能够预测个体工作成绩出色的个性特点。TTA方法的依据是：具有某种人格特性的个体，如果职位绩效优于不具有该种特制者，并且特质的差异能够通过标准化的心理测验反映出来，那么就可以确定该特质为完成这一工作所需的个体特质之一。
需求分析方法主要步骤
1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。 在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。 此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。
遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。
软件需求分析方法
需求分析方法 一需求分析概括 需求分析应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S＝｛D1，D2，D，…Dn｝ 问题域Di由若干问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di＝｛P1，P2，P3，…Pn｝ 问题Pi有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj＝｛F1，F2，F3，…Fk｝ 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适 的技术来实现此需求 2.需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分 析此需求。 二需求分析方法论 第一阶段：“访谈式”
第一阶段是和具体用户方的领导层、业务层人员的访谈沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式” 结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。 实现手段：诱导（拜访）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式” 此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归到需求分析报告中）
岗位分析分类法的具体操作步骤
?分类法 ?排列法 ?点数法 ?配对比较法 ?点数加权法 ?工资市场调查 分类法 分类法是排列法的改革，又称归级法。它是在岗位分析基础上，采用一定的科学方法，按岗位的工作性质、特征、繁简难易程度、工作责任大小和人员必须具备的资格条件，对企业全部（或规范范围内）岗位所进行的多层次的划分，即先确定等级结构，然后再根据工作内容对工作岗位进行归类。 这种方法中，最关键的一项工作是确定等级标准。各等级标准应明确反映出实际上各种工作在技能、责任上存在的不同水平。在确定不同等级要求之前，要选择出构成工作基本内容的基础因素，但如何选择因素或选取多少则依据工作性质来决定。在实际测评时，应注意不能把岗位分解成各构成要素，而是要作为整体进行评定。岗位分类同企业单位以外的职业分类标准存在密切的联系。各类职业分类标准是以企业单位、国家机关岗位分类为基础制定的。一旦这类标准建立之后，企业单位在进行岗位分类时，便可依据、参照或执行这类标准。 （一）分类法的具体操作步骤 1、岗位分析。和其他方法一样，岗位分析是基础的准备工作。由企业内专门人员组成的评定小组，收集各种有关的资料、数据，写出调查报告。 2、岗位分类。按照生产经营过程中各类岗位的作用和特征，首先将全部岗位划分为若干个大类。然后在划分大类的基础上，再进一步按每一大类中各种岗位的性质和特征，划分为若干中类。最后，再根据每一种类中反映岗位性质的显著特征，将岗位划分为若干小类。 3、建立等级结构和等级标准。由于等级数量、结构与组织结构有明显的关系，因此这一步骤比较重要和复杂。它包括以下三个方面： （1）确定等级数量。等级的数量取决于工作性质、组织规模、功能的不同和有关人事政策。不同企业根据各自的实际情况，选择一定的等级数量，并没有同一的规定和要求。但无论是对单个的职务还是对组织整体都要确定等级数量。 （2）确定基本因素。通过这些基本因素测评每一职位或工作岗位的重要程度。当然，不同的机构选择的因素也不同，应根据实际情况灵活处理。 （3）确定等级标准。因为等级标准为恰当的区分工作重要性的不同水平以及确定工作评价的结果提供了依据，所以它是这一阶段的核心。在实际操作中，一般是从确定最低和最高的等级标准开始的。 4、岗位测平和列等。等级标准确定后，对岗位的测评和列等就根据这些标准，将工作说明书与等级标准逐个进行比较，并将工作岗位列入相应等级，从而也评定出不同系统、不同岗位之间的相对价值和关系。 对小企业来说分类法的实施相当简单，若应用到由大量工作人员的大企业，则会变
软件项目需求分析通用模板
1. 引言 1.1 目的 说明编写这份报告的目的，指出预期的读者。 1.2 背景 指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。 1.4 术语 列出本报告中用到的专门术语的定义。
2. 任务概述 2.1 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。3. 假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4. 需求规定 4.1 软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2 对功能的一般性规定
软件需求分析方法
欢迎阅读 软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整?性，促 使用户在软件设计启动之前周密地、全面地思考软件需求； 2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；
3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据； 需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外，为保证软件设计质量，便于软件功能的休整和验证，软件需求表达无岔意性，具有可追踪性和可修改性。2.1、????? 软件功能需求 1 不 （5）??? 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不是完整的文件，如果出现待定的部分，必须进行待定部分内容说明，落实负责人员、落实实施日期。 2）功能描述的无岔意性和可追踪性 需求功能描述的无岔意性、可追踪性和规范化： （1）??? 功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输出描述应对应有数据流描述、控制流描述图，这些描述必须与其它地方描述一致；
（2）??? 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果选用语言描述必须使用结构化的语言，描述前必须说明该步骤（或子功能）的执行是顺序，选择， 重复，还是并发，然后说明步骤逻辑。整个描述必须单入单出。 （3）??? 描述时，每一个功能名称和参照编号必须唯一，且不要将多个功能混在一起进行描述，这样便于功能的追踪和修改。 （4）??? 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软件的功能设计，它给出软件运行的的外部功能描述，以及为了实现这一外部功能必须做哪些事情（采 2.2、 2.3、 （2）??? 处理容限、精度、采样参数的分辨率，误差处理等； （3）??? 可靠性的MTBF要求，可维护性、安全性要求等。（对可能的不正常的输入给以正常响应是可靠性的重要内容，这属于功能性需求。） 2.4、????? 软件反向需求 软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一种情况：某些用户需求适宜采用反向形式说明，如数据安全性要求属于这类形式。第二种情况：对一些可靠性和安全性要求较高的软件，有些必须描述软件不能做些什么。如控制点火时序，我们必须交代清楚在那些情况下不能点火，否则会造成故障。
有关软件需求分析的步骤以及所需
有关软件需求分析的步骤以及所需文档一、需求分析的几个方面 ○ 需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段，包括以下几个方面： 1、确定软件所期望的用户类；获取每个用户的需求 2、了解实际用户任务和目标以及这些任务所支持的业务需求 3、分析员与用户的信息以区别用户任务需求、功能需求、业务规则、质量 属性、建议解决方法和附加信息 4、将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件 5、了解相关质量属性的重要性 6、讨论得出实施优先级 7、将所收集的用户需求编写成需求规格说明和模型 8、评审需求规格说明，确保与用户达成共识 二、需求分析的任务与过程 ○ 需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素）导出目标系统的逻辑模型（只描述系统要完成的功能和要处理的数据），解决目标系统“做什么”的问题。
所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，通过逐步细化对软件的要求描述软件要处理的数据，并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据与功能表示。 必须全面理解用户的各项要求，但不能全盘接受，只能接受合理的要求；对其中模糊的要求要进一步澄清，然后决定是否采纳；对于无法实现的要求要向用户作充分的解释。 最后将软件的需求准确地表达出来，形成软件需求说明书SRS。 实现步骤： （1）获得当前系统的物理模型 首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体的模型来反映自己对当前系统的理解。此步骤也可以称为“业务建模”，其主要任务是对用户的组织机构或企业进行评估理解他们的需要及未来系统要解决的问题，然后建立一个业务USECASE模型和业务对象模型。当然如果系统相对简单，也没必要大动干戈区进行业务建模，只要做一些简单的业务分析即可。 （2）抽象出当前系统的逻辑模型 在理解当前系统“怎样做”的基础上，取出非本质因素，抽取出“做什么”的本质。
如何进行软件需求分析
软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关的机构分析结果表明，我们设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功能域，可以用D1、D2、… Dn表示，那么，我们可以用一个表达式描述为S={D1，D2，D3，…Dn} 但是，功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成，并且每个功能对应于子系统中的一个软构件，我们可以表示为 Di={P1，P2，P3，…Pm} 同样，功能Pj有若干个行为F1、F2、F3、… Fk，每个行为对应于软构件中的实现方法 Pj={F1，F2，F3，…Fk} 一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求，经过需求问题识别，进行分析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标： 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需
软件测试之测试需求分析与测试计划
软件测试之测试需求分析与测试计划 在项目启动之后，就要着手软件项目的计划，包括软件测试计划。软件测试计划是整 个开发计划的组成部分，同时，它又依赖于软件组织过程、项目的总体计划、质量文化和 方针。在测试计划活动中，首先要确认测试目标、范围和需求，其中“测试需求分析”是 关键任务，然后在测试需求基础上制定测试策略，并对测试任务、时间、资源、成本和风 险等进行估算或评估。 无论何时进行估算，我们都是在预测未来，并会接受某种程度的不确定性。软件项目 计划的目标是提供一个框架，不断收集信息，对不确定性进行分析，将不确定性的内容慢 慢转化为确定性的内容，该过程最终使得项目测试负责人能够对资源、成本及进度进行越 来越合理、准确的估算。这些估算是软件项目开始时在一个限定的时间框架内做出的，并 且随着项目的进展而不断更新。所以，测试计划强调的是一个过程，计划（Planning）的过程，而不仅仅是为了一个文档——“测试计划书”（Test Plan）。 测试计划活动过程伴随着需求文档的审查，而需求文档的评审反过来也有利于测试计 划的制定。而且，测试计划必须建立在软件需求定义之上，为软件的质量需求验证和确认 活动的开展进行规划和指导。 1.1软件测试的目标和基本需求 在分析测试需求之前，先要确定测试目标，而测试目标的确定，取决于质量要求。虽 然在理论上，对软件质量的要求是比较明确的，但对不同的软件开发项目，其质量要求是 不一样的。根据特定的质量要求，确定测试目标。然后再根据测试目标，来分析测试需求。 1.1.1质量要求 关于什么是软件质量，包括软件产品的质量属性，如功能性、易用性、性能、安全性、兼容性、可用性、可维护性、扩展性等。但是，仅仅根据这些质量属性不够，还要参考业 务领域专业知识、行业标准、地方标准或其他规范等，才能明确特定产品的质量要求。只 有明确质量要求，才能明确测试目标。让我们先讨论特定软件产品的质量要求。 对质量的具体要求，可以参考国际标准ISO/IEC 25030的相关描述，质量不仅局限于最终用户的需求（通常指外部质量要求、软件使用质量），还要考虑产品或项目的干系人（Stakeholders）的质量要求，包括组织的管理层、系统运维等，对软件内部质量也有具体要求，包括软件的可维护性、可扩充性等。从质量来看，用户的需求会显得更重要，我 们会在使用质量（Quality in Use）上有更多的关注，使用质量的具体要求见图2-1。 手机也是大家熟悉的产品，不同的用户群对一部智能手机的要求也是不同的，如低档 手机和高档手机有着不同的质量要求、老年人和年轻人对手机也有不同的期望，商务人士 对手机也有一些特定的需求（如Blackberry的实实在在的全键盘）。低档手机的质量要求如下。 ·通话正常、稳定。 ·通话质量要有一定保障。 ·待机时间长。
软件需求分析习题大全
软件需求分析习题大全 Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】
习题集 一、单项选择题 1、需求分析最终结果是产生（）。 A．项目开发计划 B．可行性分析报告 C．需求规格说明书 D．设计说明书答案：C 2、需求分析中，开发人员要从用户那里解决的最重要的问题是（）。 A．让软件做什么 B．要给软件提供哪些信息 C．要求软件工作效率怎样 D．让软件具有何种结构 答案：A 3、需求规格说明书的内容不应包括对（）的描述。 A．主要功能 B．算法的详细过程 C．用户界面和运行环境 D．软件性能答案：B 4、需求规格说明书的作用不应包括（）。 A．软件设计的依据 B．用户与开发人员对软件要做什么的共同理解 C．软件验收的依据 D．软件可行性研究的依据 答案：D 5、下面关于面向对象方法中消息的叙述，不正确的是（）。 A．键盘、鼠标、通信端口、网络等设备一有变化，就会产生消息 B．操作系统不断向应用程序发送消息，但应用程序不能向操作系统发送消息 C. 应用程序之间可以相互发送消息 D．发送与接收消息的通信机制与传统的子程序调用机制不同 答案：B 6、面向对象技术中，对象是类的实例。对象有三种成份：（）、属性和方法(或操作)。 A. 标识 B. 规则 C. 封装 D. 消息 答案：A 7、软件需求分析阶段的工作，可以分成以下四个方面：对问题的识别、分析与综合、 制定规格说明以及（）。 A．总结 B．实践性报告 C．需求分析评审 D．以上答案都不正确 答案:C 8、软件需求规格说明书的内容不应包括对（）的描述。 A．主要功能 B．算法的详细过程 C．用户界面及运行环境 D．软件的性能 答案:B 9、产品特性可以称为质量属性，在众多质量属性中，对于开发人员来说重要的属性有哪些（B ） A 有效性、效率、灵活性、互操作性 B 可维护性、可移植性、可重用性、可测试性 C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性
需求分析与测试的重要性
需求分析与测试的重要性 读《软件工程案例教程》有感 对于学习软件工程这门课程，我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。 整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。对于这本书我主要对需求分析和测试比较感兴趣，在这我要着重的谈一些自己的心得体会以及自己的看法。 一．需求分析 1.1需求分析的重要性 一款成功的软件是建立在成功的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。由此我们可以看出需求分析的重要性。 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。 其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。 1.2需求分析的原则 （1）需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域反映上述3方面的控制信息。 （2）需求分析要把一个复杂问题按功能进行分解并逐层细化。通常，软件系统要处理的问题如果太大、太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体的功能。在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。 （3）需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。 1.3需求分析的注意事项
软件产品需求分析过程思考
软件产品需求分析过程思考 很多人认为,软件的需求过程只有在做企业的软件时才用的上,因为要和客户打交道,要定需求才开发系统,原则上这样去做企业软件是没有问题,需求的过程管理,更多的是为了界定需求的边界防止客户扯皮的问题,也为以后的系统现实阶段奠基石.而网站,互联网的产品更多的好像没有这个需求的过程,我做的那个JJY 的产品,基本上需求是是大家凑出来,过程基本上没有,需求的过程控制的很一般.没有内功,不知道以后在产品需求发生变化或扩大时会有什么问题发生. 以下是做企业软件的需求过程管理以作为参考: 众所周期，软件需求分析是软件生命周期的第二阶段，主要对前期软件定义及计划阶段提到的任务及计划进行概要的补充，需求分析的主要任务不是确定将来的系统怎么完成某项工作，这是设计阶段的事情，而是明确系统将要完成什么功能，对目标系统将要完成的功能提出完整、准确的描述等;在我们国内很多软件公司里，需求分析阶段与设计阶段没有明确的界线，需求分析阶段的很多工作，都会放到设计阶段来做或干脆不做，一般很少严格按照软件工程的方法来执行(通过CMM认证的软件公司还好些)，大多数人理解下的需求分析阶段的任务主要还是分三部分：需求的收集、需求整理与编写及最终的评审，在此就这几个阶段中经常遇到的问题作一下大体描述。 一、需求的收集 无论是老产品的改造还是新产品的开发，都需要收集大量的需求作为改造的重点对象，需求的收集也可笼统的分二大部分：内部需求与外部需求;内部需求一般包括软件在维护过程中客户反馈的未处理的需求、公司内部其它各部门在实施软件过程中反馈的需求及设计或研发人员在工作当中总结的对软件易用性、效率等方面的需求，还包括研究竞争对手的软件而得出的需求等;外部需求一般包括软件实施人员或代理商对产品提出的改造建议、设计人员直接到客户现场调研、通过与客户沟通而得到的需求等。在收集需求的过程中常会遇到以下几方面的问题： 1、误解客户需求，一般情况下需求分析人员与客户在业务术语表达上有所不同，交流过程中可能会理解有误，特别对于有二义性的需求，会导致分析人员误解客户的需求，也可以理解为需求表达比较模糊，不同的人有不同的理解。 2、需求的不确定性，一是分析人员对需求把握不准，有些从各个渠道反馈回来的需求有些失真，不能完全表达客户的意愿;二是客户需求的变动较大，不确定，不到真正实用很难表达清楚要实现的功能。 3、对时间的合理规划，收集过程中经常感觉时间太紧，无法完整的收集到客户的需求，这一点主要还是跟事先没有计划好有关，需求的收集是一个长期的过程，而不是在某一时间段内就能收集完的，好的需求在于平时的积累，是在日常维护工作中逐渐收集形成的。