需求分析(一)概念、方法、实践步骤

需求分析(一)概念、方法、实践步骤

1．概念、方法、实践步骤

需求分析阶段主要通过收集、分析、导出的方法，将客户、业务、用户的需求转换为对应的（软件）系统需求的过程。典型的工作产品：软件需求说明(SｏｆtwarｅRｅｑuiremeｎts Specｉｆｉcaｔｉons，以下简称SRS)其主要包括系统基本概要、业务功能、系统功能(性能、安全性、信赖性、扩充性、移植性、多语言对应性等要求）、接口功能要求等内容。

１.1 需求分析阶段的主要活动

需求分析阶段的主要活动可以分为需求开发、需求管理2类:

?

需求开发通过对客户、业务、用户、原系统等调查获取原始的需求,经过需求分析逐步识别并使业务具体化,通过形成制作规格说明书(或SRS)使业务系统化,项目团队同客户、用户逐步达成共识对需求得以最终确认,其间可以通过系统建模、POＣ等方式评估需求的可实现性。

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

1.2 需求开发的主要概念以及核心步骤

业务需求反映了企业或组织对（软件)系统的业务要求，通常也包含问题或机会的定义。问题是指企业或组织运作过程中遇到的问题，例如物资供应脱节、用户投诉量大、客户流失率较高等。机会是指抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务、网上银行、基于即时通信的工作协同系统等。业务需求通常由管理人员提

出,业务需求的解决往往要结合制度、(人员）能力、系统功能等多方面综合解决。另外,业务需求也反映了企业或组织对（软件)系统的高层次目标要求,就是系统的建设的目的以及目标。

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

软件系统需求是在业务需求的指导下，对用户需求进行整理、分析、提炼,从而指导开发的、更精确的、规格化的需求。一般来说，软件需求可以作为软件验收依据与合同契约。软件系统需求可以分为业务功能需求、系统功能需求、设计约束等方面的内容。

?业务功能需求：（软件)系统必须完成的业务功能,即为了向它的用户提供有用的功

能，产品必须执行的动作。这部分工作将分散的用户零散的需求采用结构化的方

法去定义,以便支撑后续的设计、开发、测试。

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

速度、响应时间、恢复时间等等）、可靠性、易用性、安全性、移植、部署等方

面的内容需求。

?设计约束的需求:影响系统实现的各种设计约束，包括开发语言、数据完整性方

针、资源的限制、运行的环境的要求等等。

２.主要流程

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

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

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

3．需求验证环节主要通过原型（Prｏtotｙpｅ)、POC(Proof ｏf Concｅpｔ）、用例（Use Ｃａｓe)或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。

?原型（Ｐｒｏtotyｐe)模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样,有些原型可以模拟实际的操作,对关键的输入输出数据也可以

一定程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。

?POC(Pｒoof Ｏｆ Cｏnｃｅpt)原意是“为观点提供证据”。对于关键的技术或者业务模型,论证需求、设计的可实施性,评估和确认概念设计方案，PＯC

的评价可能引起需求和设计的调整。一般来说,进行ＰＯC的条件：1. 论证

业务中涉及到的模型或者算法的可行性。２. 论证技术模型实现的可行性、

成本等。

?用例(Ｕse Case)：对(软件)系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说

明了系统是如何同最终用户或其它系统交互(interact)的,也就是谁可以用系

统做什么,从而获得一个明确的业务目标。

4.需求规则说明(SRS)制作:通过需求调查和初步的需求验证后,可以建立需求制作的准则,包括确认需求规则说明（SRS）的内容、制作方法、制作工具、质量标准等等。根据需求制作的准则制作需求规格说明（SRS)，好的需求规格说明（SRS)应该遵循正确、无歧义、完备、一致、分级(重要性或稳定性)、可验证、可修改、可追踪的原则。

5.需求确认：通过组织各级评审对需求分析阶段的产物,尤其最重要的结果产物需求规格说明(SRS)进行确认,以确保相关人员理解一致。从评审方法来说，可以根据情况分为需求开发组组内评审、客户外部评审、关键关系人评审等等。

需求分析的流程往往因项目规模、作业人员、系统类型差异很大,因此必须根据实际的情况合理的裁减,以下举例几种不同情况下的具体流程：

例：简明的需求开发的流程

第1步:确定实现的目的、目标,基本业务需求、业务定义以及相关的评审。

从达到目的、目标的角度,重新评审业务定义，总结业务需求。（确认客户实施的业务要求)

第2步:使业务具体化，进行软件系统的定义(系统需求定义）。

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

第3步:一边定义业务需求、系统需求、一边对运行上的相关要求(非功能需求）进行总结

运行时间，安全应对、访问权限等系统需求以及设计约束在业务需求的基础之上、考虑系统上的限制条件之后逐步形成。

例：软件工程类的典型流程

主要特征:强调客户协同、提高运作效率、屏蔽技术风险、加强边界管控

?强调同客户协同,比如确定各种约定，包括截至时间、交流方式、成果物；

?强调计划管控,起目的确保进度和成本，人力资源合理使用；

?采用《问题回答管理票》的方式加强需求团队以及客户的协同作业,提高生产效率，确保质量；

?加强需求边界管理，控制项目整体成本;

?提前对技术关键环节（技术解决方案、技术构架）进行论证,控制技术风险，减少技术带来的成本损失；

?强调需求最终确认；

案例3:软件产品类的典型流程

主要特征:缩减开发周期、支撑跨部门运作、提高创造性、强调用户体验设计。

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

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

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

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

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

需求分析（二）内容

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

3．1 需求调查报告

通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对(软件）系统需求,分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。需求调查常作为一个中间过程成果,主要强调对业务、系统的现状进行归纳整理,同时对业务中的问题、各类期望以及优化方案进行记录和整理,通过初步分析形成结构化描述。一般需求调查报告包含目的、目标、范围、业务域概述、组织机构以及对应的岗位权限、业务现状、业务优化的期望、业务规则(算法、逻辑)、输入输出数据、其他系统的交互（如果有）等内容。

??

1.业务领域

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

例业务领域以及关联关系

2.业务现状

业务现状主要描述当前业务工作中的各种处理,可以通过业务流程描述(常见可以用泳道图描述）、逐个业务场景描述、对系统功能需求描述、相关输入输出信息以及优化分析的期望等几个方面进行描述。如果原业务有对应的（软件）系统，也可以收集原系统的对应的资料进行整理。

１）业务场景描述：对业务工作中的每个处理进行对应的描述,并通过记录和整理形成结构化的场景描述。场景描述一般包括定义场景的名称、场景相关的角色、场景的详细描述、结果产出以及当前的存在的问题以及对应的期望。需要注意的是任何系统的引入都会一定程度地改变当前的工作模式和工作方法,所以对当前的存在的问题以及对应的期望的支撑程度往往决定了系统的价值,也必然是今后(软件)系统的焦点。当然这些问题以及期望可以采用多种方式解决，比如通过管理制度的建设、人员能力的加强、计算模型的优化、系统化(计算机化)等等。其实需求分析阶段的主要工作就是识别、分析那些工作是可以系统化或计算机化的工作,并辅助制度化管理流程、提高人员能力等工作提高作业的效率和质量。例，一个移动终端希望提高购物的便利性，哪些是可以系统化的呢?比如支付可以系统化做到移动支付,同时第3方支付还需要法律的支撑等等。

2)业务功能需求描述:结合业务场景对系统的业务功能进行描述。一般包括前置条

件、输入、输出、业务规则、典型动作等。业务功能需求描述着眼于使业务具体化,进行（软件)系统的需求调查或定义，描述方法也更加的结构化。这一步骤中,业务规则是重要的核心，是业务场景中具体处理的细节要求，一般包括处理的详细流

程、关键数据的计算方法、样式要求等等内容。

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

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

4）其他:对业务现状整理过程，对一些过程性的资料比如原始的单据、表单通过扫描等方式进行收集汇总。对原系统可以通过收集设计资料、屏幕截图等方式汇集整理。

3.2 软件规格说明书(SＲS）

通过需求调查以及分析、需求验证环节等步骤,需求规格说明书使业务具体化,最终对软件以及硬件系统的功能进行明确定义。需求规格说明(ＳRS）对功能进行结构化的描述,以指导后续设计、开发、测试工作的开展。需求规格说明定义系统愿景、系统范围、业务功能、系统功能、约束条件等方面的需求。主要描述系统“Wｈaｔ to dｏ”,而后续的设计要描述系统“Hｏw ｔo do”。

??

1.项目目标&系统范围

项目目标&系统范围描述项目发起的背景、希望解决的问题、系统的目的和目标以及核定项目的范围。一般可以包含以下内容项目背景(Ｐrojｅct Ｂaｃkｇrouｎd)、现状（Cu ｒｒenｔSiｔuａtioｎ)、当前面临的问题（The ｉssueｓwｅaｒe fａcing ｎｏw)、项目目的以及目标（Oｂjectｉves ＆Ｇoａls）、项目范围(ProｊectＳｃｏｐe）、业务流程/功能范围(Ｂusinｅｓs Pｒｏcess/FunctｉoｎScoｐｅ)、涉及组织范围(Ｏｒgａnizａtion Sｃope）。

1)项目目的以及目标（Objｅctivｅs ＆Goalｓ）应着眼于（系统)未来的价值，它应该

是可以量化、可评价、可实现、有价值的。系统的设计、开发、测试、验证、发布、运行等工作都围绕项目目的以及目标而进行。

需要注意:

项目目的以及目标应该细化分解成一些核心的指标，这些指标今后是可以量化或评定。比如“节省人力和物理的投入同时提升客户满意度”可以设定为“原有维护人员规模可以缩减75％,物理投入减少80%”等。设定明确的指标可以更加有效的推动（软件）系统、人员、制度的有效的结合,这个也是项目成功的必要条件。很多软件项目到后期往往为了上线而上线，往往不能取得实际的效用，这个和前期目标不明确有关。实际上,当一个项目经过数人或数百人的数月或数年辛勤工作,经过了设计、开发、测试、反复的缺陷修正、上线以及运行后，也许值得欣慰的就是达成了项目目的以及目标。最悲剧的故事就是“不知道原来的目标是什么?”。

项目目的以及目标也可以是多方面的，比如对用户、操作员、管理人员、决策人员分别设定不同的目标,这些也是今后系统化以及设计的指导原则。

制定项目目的以及目标需要多方面的反复讨论和确认,尤其是项目的关键决策者。通过这些目的和目标，起码我们可以明确这个系统未来的价值。有些情况下,决策人员并不是这些方面的专家,需求开发人员应对需求及目标提出建议和解决方案,然后耐心等待决策环境的成熟,决策慢的一个好处就是可以减少决策失误。

2)范围可以包括项目范围、业务范围、功能范围、组织范围等等方面的内容,界定了那

些工作是需要做的,那些不需要做。在项目中对于预算、成本、WBS、计划等方面起决定性作用。

２. 业务功能需求

业务功能需求往往主体描述系统"Ｗhatｔo ｄｏ",不同类型的系统业务功能需求的侧重点也不太相同,那么描述的方法和内容也有差异。

不同类型系统业务功能需求的侧重点不同

?联机事务处理系统：主要的本质是流程的电子化,所以固化流程是主要工作,需求的描述也围绕着流程

进行。

?管理分析信息系统:主要的本质是数据信息化,需求的描述围绕着信息数据加工,即数据的输入、变换、

处理、输出,报表往往需求的关键线索。

监控系统：主要的本质是数据收集、状态控制等方面的内容，其本质往往是状态的管理、接口标准的处理。

这也是为什么在通过需求调查和初步的需求验证后，需要讨论并建立需求制作的准则,针对不同类型的系统，采用适合的方式、方法、工具来更有效的描述业务功能需求。无论采用什么方式、方法描述，那么业务功能需求的共性内容包括：业务领域、组织机构、岗位、权限、功能（用例)清单、用例说明、界面交互、数据实体、接口、规则模型等。

1)业务领域范围：主要描述业务、功能的分类以及对应的范围。

２)组织机构、岗位、权限:主要包含系统涉及的组织、岗位、权限的要求。一般内容包括组织体系图、岗位说明、业务以及系统相关的权限要求。

系统功能以及数据相关的权限要求,往往会贯穿整个需求规格书的各个章节。这种情况下，我们可以将权限要求汇集在一个单独的章节中,以便其他章节引用。另外,权限相关的内容在系统实际导入的时候,还需要更具体的需求，比如哪些人、哪些功能等等。

３)功能（用例）清单:根据需求分析的结果,对业务逐步进行分类,对每个分类进行细化梳理功能,形成用例清单。功能(用例）清单一般包括分类、功能概要说明、功能编号等等方面的内容。

4）用例说明: 一般包含用例对应的编号、名称、场景概要描述、前置条件、流程、前置条件、业务规则等内容。对于复杂的流程，也可以用流程图的方式描述对应的流程5)界面交互:界面交互往往是关注的重点，在需求分析阶段可以通过原型的方法同客户

沟通并验证业务需求。对于界面交互比较重要的项目，可以详细描述页面的需求，一般包括以下内容:界面的迁移、界面原型或式样（可以采用高保真图或线框图)、界面元素(输入、输出)、界面动作等等。

例, 界面的迁移:描述画面以及处理间的关系。

例，界面线框图:用来描述界面的式样，一般可以用一些简单快捷的工具制作。

６)数据实体:记录业务过程中的输入、输出数据的详细内容。

7）接口说明:本系统内部以及其他系统间的接口,接口需求因不同业务功能差异很大，通常接口需求涉及模块对象、处理流程(时序)、性能以及容量、数据传输、数据格式、安全等方面的内容。

8)规则模型：在业务处理中的专用的规则模型，比如核心的预算预估模型、各类精算模

型、成本归集模型、图像处理识别模型、温度控制模型、GIＳ中犯罪轨迹追踪模型等等。规则模型往往建立在一定的专业基础上，在理论模型的基础根据实际情况进行修

正优化。规则模型的需求内容要根据实际的情况进行确定。常见的内容有基本模型、优化模型、配置调优等方面的内容。

3. 系统功能需求

系统功能需求指除了业务功能外，系统本身根据项目目标、目的以及支撑业务功能的实现,(软件）系统本身应该具有的功能需求,一般来说系统功能包含质量、性能等方面的属性。一般有性能（运行速度、响应性、在线用户量等）、安全和保密、可靠性、运行、移植、维护、部署、数据容量等方面的系统功能需求。常见的系统功能需求种类有：

常见的系统功能需求种类经验汇总

1)系统功能性需求:工作流功能、系统离线功能、版本发布管理功能、搜索功能、日志管理、配置管

理、系统异常处理以及通知机制、报表生成以及定制机制等等。

2)易用性需求:多设备支持、多语言支持、多浏览器支持、自适应界面调整、系统超时数据自动保存、

用户操作易用性（包括易理解性、易学习性、易操作性)。

3）可靠性需求：架构可靠性、数据及操作可靠性、操作以及数据容错处理需求（比如系统应有全面、完善的检验和明确的错误提示信息,系统界面被破坏或系统发生故障，系统仍能给予操作者必要的提示,使其按照相关提示退出系统，并最大程度保留用户的工作成果。)

4)性能需求:用户数量、页面(接口)访问性能要求、数据同步性能要求、各应用场景（比如模块、网

络、数据库、Web、应用、接口及业务场景）的性能以及容量要求、超长时间操作处理需求。

5)可扩展性、兼容性需求:系统在技术架构上、各类功能、接口、标准以及系统部署上支持可扩展性需

求。对软件、硬件等环境的兼容性。

6)安全性需求:多重组织架构体系安全支撑、权限控制（用户组、用户、角色)及设置、安全构架集成、

应用安全控制、数据以及传输安全、数据备份安全、数据操作安全等

７）维护需求:系统上线以及更新需求、数据管理／数据迁移/数据维护需求,包括数据同步、数据管理工具、数据清洗、数据补采、数据补录等方面的需求。

8)灾难备份需求：硬件、软件、数据、网络等对应自然、病毒等灾难的处理需求。

9)可配置性需:用户界面及系统功能配置需求、系统基础数据配置需求、系统后台配置需求等。

10)系统环境需求:在开发、测试、生产、培训等环境的数据以及应用多种环境应用需求，服务器在各种

温度、湿度、磁场、能耗下的环境需求。

11)用户文档及帮助系统需求：业务操作相关、系统开发相关各类学习、培训、实践需求。

12）支持性/服务性需求:系统日志功能、系统配置、状态监控、数据异常处理(工具)等需求。

4．约束条件

约束条件一般指由其他标准、硬件局限等引发的设计约束。常见的约束条件有:网络带宽以及环境约束、客户端选型约束、服务器端操作系统约束、数据库选型约束、开发环境选型约束（比如开发语言)、开发的结构（比如B/S，C/S结构导致的设计差异)、法律法规、各类业务标准、运行环境(比如设备能耗、内存、ＣＰU使用率)等等。

需求分析(三）关键点

4.关键点(Ｋｎow-Ｈow）、运用技巧

4.1作业准则以及管理准则

需求分析的流程往往因项目规模、作业人员、系统类型差异很大,因此必须根据实际的情况合理的裁减。从软件工程的角度来说，需求分析阶段可以将需求开发的各种活动,形成对应的“作业准则”比如定义阶段控制目标（过程目标、质量目标、生产效率目标)、阶段入口准则、阶段执行的相关准则、阶段过程定义(输入、执行步骤、出口准则、输出）、定义质量保证点、成果物等。除围绕需求开发的各种活动外，还有围绕着需求变更管理、版本管理、需求跟踪、进度、成本管控等各种需求管理活动。比如常见的有评审管理流程、(文件）版本管理、需求变更管理、问题跟踪管理、（需求)跟踪矩阵管理、决策管理、风险管理、会议管理、工作汇报管理、考勤请假管理、非正式交付物管理、正式交付物管理、需求调查准入标准等等多方面的流程,这些可以形成需求分析阶段的“管理准则”。通过“作业准则”以及“管理准则”可以控制整个需求开发阶段的进程、质量以及成本。

４.２需求验证

1. Q&A管理

软件开发的过程实际上是个学习的过程，在学习中每个人（包括客户、用户、设计、开发、测试人员)理解以及学习的速度是不同的，软件工程的过程从某种意义上就是协同团队中的每个人学习进度。既然是学习那么就会有多种多样的问题,快速解答问题显然是非常重要的环节。Q&A(问题&回答)的管理实际贯穿整个工程的生命周期,在需求分析阶段, Ｑ&A（问题&回答)的管理可以加快项目团队内部的学习以及加速项目团队同客户、用户的沟通。Ｑ&A（问题&回答)的管理过程并不复杂，主要就是提出问题、内部知识共享解决、外部确认解决、监控并管理整个过程。Q＆Ａ(问题&回答）经常可以简单地采用EＸCEL 表的形式（也可以项目组、客户、用户共同使用专门的系统来共享）,定期发送给相关人员，这样可以非实时的处理，不影响正常的工作。另外,Ｑ&A(问题＆回答)可以在固定的时期,集中的进行处理,以加快确认的过程。

2. 原型

原型模型本身是一个迭代的模型，是为了解决在产品或系统开发的早期阶段存在的不确定性、二义性和不完整性等问题。原型是（软件)系统一个早期可以运行的版本，它反映了系统的部分重要的特性,用于试验和评价,以指导后续的设计、开发、测试等工作。通过建立产品原型使相关人员更易理解系统未来的功能。原型只是真实系统的一部分或一个模型,部分实现了产品或系统的功能。比如，在一些交互性系统中,可以模拟实际的操作,甚至对关键的输入输出数据也可以一定程度的模拟。这样用户可以感受到今后系统的功能。一般通过原型可以更快的确认系统的交互部分，比如系统的操作、画面的迁移、画面(风格外观、动作、要素等）等多方面的内容,所以在以交互为主的系统需求开发的早期就可以开展原型制作的工作。

原型的开发要根据情况制定一些策略，一般考虑的要点如下：

1）原型是抛弃型还是进化型。原型中哪些内容可以在后续工程中复用。

2) 原型设计、开发过程中是否要验证技术的可行性、是否要验证工作效率以及工作方法的可用性。

3）设计团队中是否配置了原型的开发所需要的设计、开发、测试人员。

4) 系统中哪些部分需要采用原型的方式，加强同客户、用户的验证。比如关键或复杂的部分功能进行原型制作,或将业务归纳成几种模式，对不同的模式制作对应的原型等等。

5) 制作原型所需要的预算、时间、成本等。有些原型的制作也需要不少的工作量,有些情况下原型制作本身就是一个单独的项目。比如，有些方案供应商就预先开发原型,以便争取项目的合同。同时有些项目在招标的时候,就要求必须对核心功能提供必要的原型等等。

6) 制作原型的所采用的快速工具，比如ＷEB站点的原型，如何有开发人员的参与的情况下,可以直接用HTML制作原型,不然也可以用PPT或其他工具“画”出原型。

7）原型除能确认系统的操作、画面的迁移、画面（风格外观、动作、要素等）等方面的内容外,也可以对关键数据进行确认,所以有些情况下,还需要考虑对原型所涉及的数据（尤其业务数据）进行专门的制作。

从工作实践中经验证明，对于一些较为业务复杂或更关注交互的系统来说，需求分析阶段在规划的时候,就应考虑制作原型并配置对应的原型开发队伍(设计、开发、测试),对原型的目标建立、功能选择、构造确认、评价等过程进行合理管理,可以降低整理项目的技术、业务、人员、过程中的风险。

3. ＰOＣ验证

ＰＯC(ProofＯf Concept)原意是“为观点提供证据”,本质上是一种重要的评估技术。对于系统中的关键技术或者业务模型，论证团队和客户的设计,评估和确认概念设计方案,PＯＣ的评价可能引起需求和设计的调整。为屏蔽系统存在的业务或技术风险,在系统需求、设计的早期，我们可以设定PＯC来评估和确认这些业务或技术的模型，以减少项目的风险。对软件系统的研发而言,POC

的目的是为系统确定合适的业务模型(流程、方法等)、核心功能对应的实现方法、系统构架、系统或软件产品版本、有效技术方案以及运行维护等服务的方案等内容,或者验证建议的方案可行性。POＣ的最大价值在于在正式设计或规模实施以前,选择最优的方案。比如POＣ在核心技术上的验证内容可以有：消息中间件、工作流、数据库、浏览器、跨设备、UI控件、报表、共通组件、系统集成等等方面的内容。

POC作为一种重要的评估技术,过程上可以归纳为以下几步:

1．收集并识别来自业务、技术等方面的风险。

2. 评估、决策那些内容实施POC。POC的实施往往需要花费不少的时间和资源，应合理控制POＣ的范围。

3. 制定POC的目标、内容、实施方法、评估方法等要素,合理安排计划。

4. PＯC的实施以及POC报告：PＯC报告是POC的核心产出,它一般包含POC的目标、过程、方案、结果数据等关键的信息，实际上ＰＯC的整个实施都是围绕着POC报告而进行的。

5. POC评价和验证：评价和验证过程就是风险承担者讨论、评价、评估POC报告并最终给出结论的过程。通过PＯC评价，可能提出调整规格和设计的要求。通常，在评价和验证过程结束时,有关设计的承诺、评审组的意见都将记录在文档中，这往往是系统开发的生命周期中一个重要的里程碑。

POC作为一个实用的评估技术不仅仅应用在需求验证方面,其实在实际的项目中，往往项目一开始就识别项目中的各类风险,其中业务、技术、人员技能等方面的风险,可以通过实施POC获得最优的方案。实际上当你参加有个项目时,就应该首先问“有什么样的风险?业务的？技术的?自己担心什么。”这时POC就已经开始了。

4.4共性需求整理

从牛顿第一定律到万有引力,都说明世界万物是有规律性的。在写这篇文章时，好奇号火星探测器已经登陆到火星,我常想这真是一件神奇的事情,好奇号火星探测器从地球出发经过各种历程，竟然能飞到火星这个球上降落成功,而且还能拍拍照片。所有的这一切，都是因为人类掌握了相关的规律。我们所想所做就是找到规律、证实规律并合理的运用规律。针对任何软件系统也是有规律的，发现运用这些规律是一种乐趣,共性需求整理就是寻找这些乐趣的过程。通过共性需求整理我们可以发现业务、技术领域的各种规律,通过建立共性模型可以简化工作量，提高工作效率,发挥并创造价值。

概要设计、详细设计(四)心得体会

??

１. 设计一般来说是个学习迭代的过程、通过不断的评审&确认&改善达到成熟．但是前提必须写出设计文档，而不能仅仅停留在脑袋里。

2. 分层、抽象、归纳、汇总是设计的主要方法。其中分层是最最基本的，而是绝大数设计人员不能掌握的（这个有点悲剧），归纳是常见的方法。

3.交互的设计往往是人们关注的重点,所以也要特别注意、特别设计。对于画面的风格、操作等我的理解是“美的事物，任何人都觉得美”。

４．设计的完整性、严密性、可用性是成功的主要因素。

５．设计不等同于创造和创新，但是好的设计一定包含各种创新。

6. 多看看其他的系统，功能、交互方法、实现方式等,才会有思路，有想法。比如,画面色彩、布局等可以参考日本的网站,交互参考欧美站。多看才有比较!

7.系统/产品研发就是群体学习活动,什么时候学会什么完成。需求、概要设计、详细设计中如何描述、粒度如何划分,是要在前期就要思考的,这些是研发人员的“教材”。