需求分析方法论

1. 需求管理的手段有哪些

本文梳理了什么是做需求分析与需求管理，以及为什么要做与如何去做。

01 概述

本文是梳理需求分析与需求管理方法-产品经理工作职责&工作核心技能之一，笔者写本文的目的一是把自己的知识体系做个输出，包含来自己的经验总结和最近学习到的知识总结，其二顺便分享。知识方法无定论，任何内容先看思路，实战为主。

在分析一个问题时，可以用一个通用的框架方法论，WWH法：是什么？为什么？怎么做？这样可以把思路理清晰。因此引出了本文的主要内容：什么是需求？为什么要做需求分析？什么时候做需求分析？怎么做需求分析？

说明：时间有限，本文的案例不代表实战解决方法案例，更为了快速说明和应用方法而举例。

02 需求定义

1. 什么是需求？

需是是用户在某种场景下的未被满足的期望。

为什么要明确需求的定义，需求很容易被误解，这里我们要区分下用户需求和产品需求。

我们的产品在未被定义之前，我们研究的需求是用户需求，我们通常也会叫作问题（没有明确的解决方案），当我们定义产品时，我们就要把用户需求转化为产品需求，提供具体的可落地的解决发难，才能实现产品。

我要吃饭睡觉打豆豆，这不是需求，这种需求对于产品没有任何价值。

看定义，用户需求是用户基于某种场景下的未被满足的期望，在这里提炼出需求的基本结构：用户+场景+期望。强调：需求不是独立存在的，是依附于用户+场景一起存在的。

用户需求案例： 小明（用户），每天早上起床后就要赶着去上班，没有也不想在家吃早餐，但是到了公司就要工作，所以常常没有早餐吃，又饿又不健康（场景），小明又想多睡会儿又想在上班前吃上早餐（期望）

2. 什么是需求分析？

需求分析，就是挖掘和提炼用户需求，解决用户痛点问题，即找到用户需求，并把用户需求转为产品需求（解决方案）的过程。

这里强调两点：

找到用户需求
解决用户问题
案例： 还是小明吃早餐的案例，目前小明希望在上班前能吃上早餐这个是用户需求，只找到用户需求，没有解决方案，等于0，我们还要帮小明解决问题。如，提供早餐外卖，小明可以提前在手机上预定早餐外卖，一起床就有早餐可以吃。这是一个较完整的产品需求。

03 为什么要做需求分析

产品首先要满足的就是用户需求，为用户产生价值，才能创造商业价值。满足用户需求是产生商业价值的本源。

04 在什么阶段做需求分析

需求分析贯穿在产品整个生命周期。

1. 产品概念期

这个阶段做需求分析，更强调需求调研，目的是定位目标用户群，做产品定位，市场研究并确认细分产品市场。提炼产品核心功能，解决目标用户群痛点问题。 交付物：BRD需求文档。（或类似的相关的文档，如需求调研报告、市场调研报告等）

2. 产品设计开发期

这个阶段的需求分析，目的是要设计一个可落地的解决用户痛点，满足用户需求的产品。设计一个目标用户可用好用的产品。深层次的挖掘和分析用户，描述需求，解决问题。实现用户如何通过一步步的使用产品满足其需求。该阶段交付物：产品原型+PRD操作文档。

3. 上线后-成长期

上线后的需求分析，目的是验证真实产品满足真实用户需求的结果，收集用户需求，优化产品。

4. 成熟运营期

本阶段需求分析，目的在为产品提供更好的运营方案，制定竞争策略。让产品持续更好的更多的为企业创造商业价值。

5. 产品衰退期

当产品进入衰退期时，需求分析重在研究市场发展趋势，以帮助决策是调整发展战略。

05 需求分析方法

需求分析可以分为三大步： 明确问题–拆解需求–提供解决方案。

1. 明确问题

明确问题之前，我们首先要从各方搜集需求，然后经过分析，提出真正的需求。

需求获取渠道

以下是我们常用的一手需求获取渠道：

收集到的一手需求还不是真正的需求，要先进行一个清洗过程，把一些无用的无根据的站不住脚的异常的等等都过滤掉。具体过程不做介绍啦。

明确问题（提出要解决的问题）

这里一定要注意，提问题的标准：提出的问题要聚焦，明确、开放。不能泛，模糊。要又用户、场景、问题。还要明确该需求带来的价值。需求最终是要交换成价值的。

正确的问题VS错误的问题：

明确需求的价值：

2. 拆解问题（需求）

拆解需求指的是把已经明确的问题，从多个维度进行拆解，目的就是为了找到更合适的解决方案。 该方法是某课程老师总结的拆解方法，笔者认为非常好，非常清晰和明确的一个方法，这里直接引用。（该方法也是老师对《六顶思考帽》里的解决问题方法做的灵活应用，同时书也推荐给大家）

拆解问题的5个维度：

积极层面：通常可以拆解出怎么做对用户来讲可以产生更积极的情感。
否定层面：通常可以拆解，即使不做什么，依然可以产生好的结果。
转移层面：转移指的是不直接单独解决当前用户的问题，通过转移法，用户转移、问题转移等。
拆解：把当前问题刨根问底的拆，挖掘更多的可能性、找到问题本质。
脑洞：这个更多的靠灵感、经验等进行头脑风暴，补充其他维度考虑不到的地方。
案例： 问题：某视频APP，用户次日留存率低于30%，需要提高次日留存率 拆解过程如下图：

注意在拆解问题的时候，不要去考虑能不能实现，先去拆解一切想到的问题，最后在分析解决方案的时候再来进一步筛选。

3. 提供解决方案

问题拆解完后，对所有提出的问题列出解决方案，这里注意，一开始思考解决方案的时候也不要去考虑实现的可行性，尽管去提供。等所有的解决方案都列出来之后，再进行方案分析、评估、排序。

06 需求管理

需求管理指的是如何安排已经明确产生的需求，工作中我们通常会遇到四面八方包括产品经理自己给的需求，但是资源和精力无法让做到有求必应，我们需要去把需求做一个分类和排序，尽可能的去做性价比高的需求开发。 这里我们介绍几种方法，帮助我们做需求分类和排序。

1. Kano 模型

KANO 模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

Kano模型把需求分为5类：

基本型需求

该类需求代表的用户的核心痛点，是产品的必备功能，如果没有该功能，用户会极度不满，甚至不用你的产品。但是如果有了该功能，用户并不会对你的产品的满意度增加。如微博的发布微博功能、社交APP的聊天功能、共享单车的开锁功能等。

期望型需求

这类需求代表的是用户的痒点，代表的是品质，对用户来讲是最好有的功能。好比我们的生活，我们都期望我的生活是有一定品质的。拥有此功能，用户满意度会明显提升（过的还可以），没有此功能，用户满意度会明显下降，但是凑合可以用户（过得下去）。这种需求一定要去努力挖掘和分析，并做好。代表了产品的竞争优势。如社交软件的语音聊天视频功能。

兴奋型需求

这类需求所在暗处，用户自己都想不到的需求。拥有此功能，即便表现的并不完善或完美，用户满意度也显着提升，但即便没有此功能，用户也并不会对产品对满意度降低。如，在微信刚刚推出红包功能的时候，这是一个非常典型的兴奋型需求。

无差异型需求

该功能对用户来讲，是不痛不痒的需求。可用可不用，有或者没有都不会影响用户的满意度。如，我们在设计某个按钮，是20px，还是22px，是第一个还是第二个位置。无论怎么做，对用户并无明显影响。我们就尽量不要去花精力在这上面，只需要执行任意一种即可。

反向型需求

该类需求提供对应的功能后，用户会对产品的满意度降低。该类需求，最好不做。如，前段时间上热搜的一款监测学生上课是否集中注意力的智能科技“紧箍咒”，得到的是网友几乎一边倒的差评和抵制。

Kano模型实施方法：

如何评估需求属于Kano模型中的哪一类需求，我们可以实施以下方法：

Kano模型问卷调研法 可以直接设计问卷调研，通过定量问卷调研得出需求属于哪一种：

按照上表的格式，对每一个功能做一个的调研，充分收集用户的数据并得出结果。

2. 时间管理四象限法

本方法可以快速帮助我们评估需求开发的时间优先级。从紧急重要程度两个维度比较合理的帮助产品有条理的安排开发秩序，避免盲目排序。

3. ICE排序法

ICE排序法也是一种比较严谨科学的需求排序方法，通过从几个维度考虑给需求打分，以总分高低去排序。

I（Impact）：影响范围
C（confidence）：对上线效果的自信程度评估
E（ease）：开发难易程度（工作量+技术难易程度）评估
应用实例：

本文由 @娟姐 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

2. 论文高手进：软件开发需求分析的认识和理解

应用软件开发中的需求分析及方法 软件工程一般具有以下基本活动：软件描述：软件的功能以及软件操作上的约束定义；软件设计和实现：软件要按照描述来设计；软件有效性验证：软件要被确定是有效的，能完成预期的应用；软件进化：软件按应用需要的变更来进化。其中，软件描述的目标是，确定软件系统需要哪些服务以及开发和运行期间受到哪些约束，对服务和约束的发现、分析、建立文档、验证活动，现在常称为需求工程。为此，笔者谈谈如何进行需求分析及方法。 一、 需求的过程 需求工程对于软件过程是一个特别关键的阶段，这个阶段的错误将不可避免地带到后续的系统设计和实现阶段中。需求工程阶段的独特之处在于很少有现成模式或特制的文档可供参考。后续阶段可以建立在前期所做工作基础上（各种相关模型至少在一定程度上可以衍生导出），而需求工程阶段的成果却是靠创建而来的。 需求工程本身就是一个过程，这个过程将产生用以描述系统的需求文档。通常需求在这个文档中被分成两个层次描述：最终用户需要高层次的需求描述；而系统开发人员需要比较详细的系统描述。 （一）需求过程的四个主要阶段 1、可行性研究：指明现有的软件、硬件技术能否实现用户对新系统的要求。从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。可行性研究是初步的，结果就是要得出结论，该系统是否值得进行更细致的分析。 2、需求的导出和分析：这是一个通过对现有系统分析、与潜在用户讨论、进行任务分析等导出系统需求的过程。也可能需要开发一个或多个不同的系统模型和原型。这些都会帮助分析员了解所要描述的系统。 3、需求描述：需求描述就是把在分析活动中收集的信息以文档的形式确定下来。在这个文档中有两类需求。用户需求是从最终用户对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。 4、需求有效性验证：这个活动检查需求实现、一致和完备。在这个过程中，可发现需求文档中的错误，并加以修正。 当然，需求过程中的各项活动并不是严格按顺序进行的。在定义和描述期间，需求分析继续进行，这样在整个需求工程过程中不断有新的需求出现。因此，分析、定义和描述是交替进行的。 （二）需求的进一步认识 1、软件系统需求 常常分为功能需求、非功能需求和领域需求。 功能需求：包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需要明确申明系统不应该做什么。理论上，系统的功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述。一致性意味着需求描述不能前后矛盾。在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。一方面是因为系统固有的复杂性，另一方面是因为观点不同，需求也会发生矛盾。 非功能需求：对系统提供的服务或功能给出的约束。包括时间约束、开发过程约束、标准等。非功能需求源于用户的限制，包括预算上的约束、机构政策、与其他软硬件系统间的相互操作，还包括如安全规章、隐私权利保护等外部因素。 领域需求：这是来自系统的应用程序领域的需求，反映了该领域的特点。他们也可能是功能需求或非功能需求。 2、软件需求文档 也称软件需求描述（SRS），是对系统开发者要求的正式陈述。IEEE标准为需求文档提出了以下结构：引言（目的、范围、缩略词等），一般描述（产品透视、功能、用户特征、约束等），专门需求（功能、非功能、接口），附录，索引。 二、方法 （一）问题域（应用领域） 是指问题所存在的现实世界中的那个部分。问题域是需求分析员所要研究的首要对象。例如，对一个电梯控制系统来说，它将包含任何现存的硬件（电梯、指示器、传感器、按钮等）、建筑物特征（楼层和电梯井的数目）、预期的使用模式、用户特征、使用约束（如限制短途搭乘）等等。在这个问题域内，问题可以确定为“让电梯在建筑物中更有效使用的控制系统”。为了解决问题，‘解系统’显然有必要在问题域内产生某些效果，构成软件需求的正是这些想要获得的效果，也就是为何做软件需求的原因和目的。 到现在为止，我们得到初步论点。在构建一个新软件系统之前，最好先决定它应当能够做些什么又不要做些什么；从问题域的研究入手，获得问题的描述，以及新的解系统在其中将产生效果的陈述（即需求）；确定新系统所需的行为，以便让它在问题域内产生所需要的效果。 （二）需求分析 通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。需求分析旨在揭示一个现有的系统（问题域）的结构，而内部设计则是要创建出一个尚未存在的软件系统（解系统）的结构。对于这一重要任务其特性如下： 分析关注问题域及对其建立的模型，而不是解系统； 主要目标是要获得对问题域及存在于其中的问题本质的理解； 分析在本质上先于解系统行为的规格说明（尽管有重叠和反复的过程）。 （三）方法论 方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。任何分析方法，要使它得到很好的利用，都应当要求并且做到便于描述以下几个方面： 问题域的结构，根据其子域及其相互间的关系； 问题域数据，语法和语义方面 问题子域的内在属性和行为； 问题域中的重要事件及现象； 需求，解系统在问题域中应产生的效果。 具体有以下三个方法： 1、结构化分析（SA） 结构化分析（SA）是一种具有相当长历史的分析方法，其演化的方式既微妙又显得很重要。如同结构化编程一样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模。建模主要包括数据流模型（DFD），数据字典（DD），实体关系图（ERD）。 结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模是对实现理解问题域这一基本的分析目标的有力支持。 结构化分析方法和人们的思维方式很相似，注重的是事物的过程和方面。利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。 2、 面向对象分析（OOA） 面向对象方法最初只是一种系统的结构进行建模的方式，后来扩展到了内部设计，如今也已经开始广泛应用于分析阶段。面向对象分析基本思想是：如果把对象类的建模限定在需求问题域，那么面向对象的基本原理、模型以及表示法均可以用于分析。 OOA（面向对象分析）算不上一种真正的需求方法，OOA的起点是一份原有的需求文档，或者甚至是一份行为规格说明，并且OOA隐含的假设问题域分析已经完成，即分析员已经了解了所要研究的事物。OOA的真正本质意义是作为解系统的高层体系结构的设计，并且有利于系统的下一步开发设计（如果是OOD开发的话）。 OOA的大致方法是：标识出问题域中的对象类；定义这些类的属性和方法；定义这些类的行为；对这些类间的关系建模。 3、 面向问题域分析（PDOA） 面向问题域的分析（PDOA）是一种新技术。PDOA更多的强调描述，而较少的强调建模。描述大致划分为两个部分：一部分关注于问题域，而另一部分关注于解系统的待求行为。一般建议同时有两个单独文档：第一文档含有对问题域相关部分的描述以及一个需求在该域中求解的问题列表（即需求）；第二文档（规格说明书）包含的是对解系统的待求行为的描述以解决需求。其中第一文档才是通过做分析产生的；第二文档推迟到后续的规格说明任务中。 PDOA整个方法过程的基本步骤： 搜集基本的信息并开发问题框架（一种模型），以建立问题域的类型 在问题框架类型的指导下，进一步搜集详细信息并给出一个问题域相关的特性描述 基于以上两点，收集并用文档说明新系统的需求问题框架。问题框架是将问题域建模成一系列互相关联的子域。一个子域可以是那些可能算是精选出来的问题域的任一部分。问题框架的目标就是大量地捕获更多有关问题域的信息。基于不同问题子域的本质及存在于问题子域间的关系，可以把问题框架分类为： 工件系统——系统必须完成针对只存在于系统中的这些对象的直接操作。 控制系统——系统控制部分问题域的行为，包括待求行为框架和受控行为框架。 信息系统——系统将提供有关的问题域的信息，包括信息是自动提供的和信息只在响应具体的请求时提供。 转换系统——系统必须将某种特定格式的输入数据转换成相应的、另一种特定格式的输出。 连接系统——系统必须维持那些相互没有直接连接的子域间的通信。 问题框架法在应用时，建议采用直截了当的策略： 抽象问题域：标识子域；标识子域间的交互；刻画每个子域的特征；生成一个上下文图识别出相关的标准框架；调整框架，尽可能使之适用于问题；使用关于相关框架的内容技术表来指导进一步的分析与文档编制任务。 问题域的描述与必须满足的需求二者之间有着明显的区别，对新的解系统的行为创建与定义应单独处理并且推迟到下一步的规格说明阶段。 4、方法的对比 结构化分析（SA）及其相应的派生方法，曾一度风行了许多年。它最初的版本主要是围绕对数据流以及问题域的数据结构进行建模，而现代的SA则直接将重点放在开发解系统的模型。描述问题域的SA可以算是想当不错的，所产生的功效可见一斑。然而，它对其他方面的支持却不够完善，在处理一些其他类型问题时显得有些笨拙。 面向对象分析（OOA）是当今主流的方法。OOA要求所有的系统均可以按照对象的特点来建模。它也继承了很多结构化分析的思想体系。OOA不能对问题域有个清楚的了解，因而它的起点若是有一份原需求文档，便可大大简化问题域的分析。OOA并不区分问题域描述与解系统描述之间的差异，而是直接交付出新的解系统的高层设计。 SA和OOA还有几点相同特性：主要模型是结构模型；通常焦点集中在对解系统的建模上；两中方法都较少地应用于需求获取领域；分析与内部设计之间没有明显差异。 面向问题域分析（PDOA）被认为是一种较为理想的方法。PDOA特点是重新将重点定位在问题域及需求上，通过对问题域的分类，向分析人员提供具体问题的相关指南。并且它将规格说明作为另行的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了现今的“分析”方法，然而人们对它的了解和掌握还有一定距离。 因地制宜的应用三种方法，不仅能够如实的认识问题域，创建出健全的解系统，还能够向用户和设计人员都提供满意的需求文档。 三、 总结 在做软件需求的时候，我们完全没必要去限定要用或将要使用何种方法。我们的目的在于分析软件的需求，通常情况是都用到了所介绍的三种方法。首先我们用面向问题域的方法把问题分成几个部分。接下来用面向结构或面向对象的方法对各个部分进行逐步分析细化。在逐步分析过程运用各种建模技术对问题各部分建立合适的模型来细化需求。随着需求的进一步进行，我们越来越清晰的认识了软件系统的需求。 虽然应用方法使我们能够清楚地去了解软件需求，但是，大部分的需求文档和规格说明书都是以文本的形式记录的，因此，如何去表达我们所了解的需求也是很值得注意的。

3. 企业在制定培训计划之前为什么要进行培训需求分析,如何进行需求分析

这样的问题最好不要问，就像问 人为什么要吃饭，该如何吃饭一样~不如问该如何做到需求分析和老师课程的直线对接，就好像你问吃点什么可以保持苗条身材一个道理。真想了解可以加QQ：把三四五三三四期六 资深心理实战培训师王家辉老师的助理

4. 什么叫调查方法论

一、何谓调查

调查系指有系统性地针对某类事物进行观察及测量，其目的无非是希望借由简单且标准的程序，而对整体结构有初步的了解。当我们对于一件事情无法由表面看出整体的时候，通常就会借由调查来进行了解。而调查的项目无奇不有，例如：大家早餐吃什么？晚上几点睡觉？某项产品的销售量好不好？哪个候选人的支持度高？某项政策民众支持否？那个人是谁杀的？小至个人的生活琐事需要问卷调查，大至国家的问题都还要成立调查局来专门做调查，几乎所有的问题都需要调查。更何况复杂的生态问题，需要更严谨的科学调查方法。

以生物资源调查为例，我们想要知道某地区有哪些生物？这些生物随着季节的消长？哪些生物近年来逐渐减少？种种的问题都必需经过一连串的调查来获得结果，随着目的的不同，就必须选用适当的调查方法。通常整个调查过程中，几乎不只调查一次而已，所以为了使得每次的调查结果都能够进行比较，研究者必须选定一标准的调查方式，从一而终的采用相同方法，并且具体的描述方法过程，以便后人能够依循此法进行重复。

因此，任何调查活动都必须注意到：(1)对象、目的为何；(2)选用方法标准否；(3)结果是否具有代表性。在此，我们的调查活动不外乎是：了解某地区的某类生物组成。所以，我们必须知道调查范围的大小，是要进行整个区域的搜查，还是针对特定区域的抽查；其次，决定调查的对象，而慎选使用的调查方法；最后，再将所调查的资料加以分析，然后讨论此结果是否能解答先前的问题。

二、取样方法

一般调查过程鲜少采用全时全区的地毯式搜索，因为这样的过程耗时耗力，且相当没有效率，所以多选取特定时段（调查频度）、特定地点（调查样区）及特定方法（取样方法），借由系统性的标准方法，研究者才能将每次调查的结果进行比较。由于调查方法众多，仅介绍一些常用的方法，研究者需明确知道自己的研究目的，慎选调查方法，以免进行结果分析时，才发现一切白做工。

˙调查频度

就是每次调查之间隔，如：每天、每周、每月、每季或每年，依据不同研究目的，需慎选不同调查频度。

若想要针对短期的特殊行为，进行密集的观察，如求偶、产卵、觅食、竞争等行为，则需安排较密集的观察频度，必要时得每天观察，但不用太多天。若想要知道某物种在繁殖季的数量变化，或者针对某短期干扰的影响，则每周进行一次观察即可，通常维持数月即可。如想要了解该生物的年活动周期，或者该地点的生物组成，则建议每月观察一次，连续观察一年。倘若调查范围大、样区多，或者仅想要有各概略性的了解，则每季调查一次，最少调查一年，亦可连续调查数年。如果要了解某物种近年来的数量变化，或者针对一大区域内各地的相对数量调查（如：于同一时段于全国各地同时进行蛙类普查），则一年一次即可，但这种调查至少要进行好几年，甚至成为百年的传统。

此外，研究者已可针对特殊需求而自订频度，如：每月两次、每阴历月一次、夏冬季各一次、乾湿季各一次、特殊气象前后各一次（台风、豪雨、干旱、寒流）、人为干扰前后各一次...等。

当然，除了目的导向外，人力安排也很重要。研究者需考量团队的时间，确保在整个调查期间内都能如期进行，避免虎头蛇尾。另外也需注意，避免过高的调查频度造成生物的干扰，别让研究者的美意成为生物的负担。

˙调查样区

调查的区域固然越大越好，这样才能尽量包含所有的状况。不过，样区的规划就像调查频度一样，太少—不具有代表性；太多—浪费资源，劳心劳力。所以，样区的选择一样要考虑到研究目的，以及调查人力资源，透过适当的样区选择，才能达到两全其美。

一般来说，样区的规划需要注意到每个样区大小、数量以及代表性。样区的数量与大小比较相关，主要系考量调查所需之人力时间。很多个小样区—会浪费许多交通时间；很少个大样区—不易进行不同栖地类型之比较。另外考量的因素就是样区代表性，若规划许多样区却无法涵盖整体区域的各栖地类型，那似乎不具有完整性。所以，一般在进行样区规划前，会先将全区内的各栖地类型逐一列出，如：森林、溪流、池塘、耕地、果园、建筑物...，再依此规划样区地点与数量，若各栖地类型能有重复为佳，最后在考量人力与调查频度，规划适当的样区大小数量。期望以最少的调查量，获得最大的代表性。

˙取样方法

因为两栖类的习性多样化，为因应不同研究目的，遂发展出许多调查取样的方式，以下就几种常见的取样法进行介绍，并比较各法之优劣。当然取样法只是概念，各法之间并不相互排斥，选定适合的数种方法来进行，方能契合研究之目的。

1. 彻底资源清查法（Complete species inventories）：
本法主要针对一特定样区，进行地毯式搜索，将样区内所有可能的种类与数量全数调查出来；其间，调查时间密集、调查人力众多，能彻底有效地了解该样区之蛙类组成。对研究者来说，若能获得此详细资料当然是最好的，但有时考量研究目的、调查人力与时间，以及彻底资源调查法过程中对生物造成的干扰，是否需要花费如此多的资源来获取此资料，倘若仅需要“相对数量”即可达到原先设定的研究目的时，研究者大可不用费力地采用此法，而选择后续诸法来进行。

2. 目视遇测法（Visual encounter surveys）：
此法系指研究人员在一特地时间内，有系统地走过一特定路线或区域，将眼睛所看到的所有种类与数量记录下来。此法广泛应用于蛙类的调查与监测，可获得族群的相对数量。但有些时候仅看到某蛙逃离的一瞬间，而无法进行辨识，此时宁可不纪录此资料，也不要误判种类；但如果调查数量为零或甚少，则补纪录“未确认种，一只”。

3. 鸣叫计数法（Audio strip transects）：
本法遂利用蛙类独特的求偶鸣叫行为，在特定穿越线中将两侧所听到的种类数量记录下来。用以了解物种组成、估算雄性成蛙的相对数量，进而估计族群相对数量；亦可针对繁殖行为与栖地或天气之关系。但本法受限于调查人员对鸣叫声音之辨识、听力与辨析数量的能力；再加上各物种繁殖季节不同，且鸣叫的音频与音量差异甚大，例如：相距100m处有两蛙同时鸣叫，其中一蛙鸣叫大声而听得到；另一蛙却鸣叫小声而听不到，这样情况下则会低估后者的数量。所以，一般调查鲜少单独使用此法，多与其他方法配合。

方块取样法（随机挑选调查区块）

穿越线取样法（A.横越马路、B.沿着溪流、C.特定方向）

4. 方块取样法（Quadrat sampling）：
将欲调查之均质区域以特定距离划设网格，将各方块给予一编号，再随机挑选数个方块，并仔细调查各方块内之生物组成。可获得物种名录、相对丰度、密度。而划设方格的大小与选取的数量则需考量调查人力与统计的可信度来判定。此法可免除人为挑选样区时的误差；但有些选取的方块并不易到达，而增加调查的困难度。

5. 穿越线取样法（Transect sampling）：
本法系指样区或调查路线为线型，而样区类型主要有二类：其一，通过连续渐变的环境，例如为调查不同海拔的蛙类分布，则选取一条由低至高海拔之穿越线为样区，于穿越线中选取部分片段进行调查，通常适用较大尺度之调查。其二，通过均值或类似之环境，选取多条穿越线，每一条穿越线为一样区，通常适用于小尺度的调查。

6. 丛块取样法（Patch sampling）：
许多生物通常会有特别偏好某种微栖地或群体聚集的行为，所以我们常常会在这类地方观察到较多之个体，例如：倒木、石块、蓄水池...。本法就是以这些高密度的栖地为单位（即一个样区，称为一个丛块），当调查丛块数量达到一定程度后，便可进行统计分析，通常适用于“微栖地利用”之研究。

掉落式陷阱配置图

掉落式陷阱近观图

7. 陷阱法（Pitfall traps）：

陷阱法主要借由目标生物的生态习性，并利用相关的设施来圈捕。在诱捕因素方面主要分为“主动诱捕”以及“被动捕捉”两大类。前者多利用食物或激素来作为引诱的物质，将标的生物引入陷阱中；后者则没有诱饵，多利用繁殖与活动习性，在该生物的移动路径中作拦截。
至于陷阱本身则分为致死与非致死的装置，前者系为了某必要之研究因素，利用酒精、福马林或其他固定溶液来将掉入陷阱的生物予以固定；后者则仅作暂时的禁锢，不会牺牲该生物之生命，所以此法在设置期间必须定时巡逻，以免遭捕获的生物饿死或被捕食。
一般常用的底栖蛙类（赤蛙、蟾蜍）陷阱法为“掉落式陷阱”，并同时配合围篱的设置，来增加捕捉的面积。陷阱本身主要系将塑胶水桶埋设于样区地下，桶高至少30㎝，桶口与地面同高，桶底钻小孔以利排水，免得下雨盛水造成捕获生物淹死或逃脱；亦可于桶上方加设盖子，防止雨水或树枝掉落至桶中；桶内可放置水果吸引昆虫来作为诱饵，增加捕获的机会。
围篱的用处主要是借由生物活动时，在接触阻隔物之后，经常沿着阻隔物边缘移动的特性，将生物诱导入陷阱当中。掉落式陷阱法的设置期间至少要连续3～7天，并且1～ 2天巡逻一次。非调查期间，可将盖子将陷阱紧密盖住，待下次调查期间再将陷阱打开，直至调查研究完全结束后，将所有装置移除，并将空洞填补回去。样区的选择可采随机选取的方式，或者设置于蛙类迁徙的路径中，如：繁殖场所与非繁殖场所间、溪流池塘的周围。

5. 计算机方法论中最基本的三个概念是

是学科形态，核心概念，学科方法。

1、学科形态：抽象，理论，设计。

2、核心概念：

⑴绑定Binding，

⑵大问题的复杂性Complexing of Large Problems，

⑶概念和形式模型Concentual and Format Models，

⑷一般性和完备性Consistency and Completeness，

⑸效率Efficiency，

⑹演化Evolution，

⑺抽象层次Levels of Abstraction，

⑻按空间排序Ordering in Space，

⑼按时间排序Ordering in Time，

⑽重用Reuse，

⑾安全性Security，

⑿折衷和结论Tradeoff and Consequences。

3、学科方法：相关的数学方法与系统科学方法。如递归，系统论，信息论等。

(5)需求分析方法论扩展阅读：

1、抽象形态包括以下4个步骤的内容。

① 形成假设。

② 建造模型并坐车预测。

③ 设计实验并收集数据。

④ 对结构进行分析。

2、理论形态包括下面4个步骤的内容。

① 表述研究对象的特征（定义和公理）。

② 假设对象之间的基本性质和对象之间可能存在的关系（定理）。

③ 确定这些关系是否为真（证明）。

④ 结论。

3、设计形态包括以下4个步骤的内容。

① 需求分析。

② 建立规格说明。

③ 设计并实现该系统。

④ 对系统进行测试和分析。

6. 软件需求分析4个步骤

一、需求分析理论

软件需求涉及功能性问题非常广，我们用抽象化理论分析，可以划分各个功能域，用不同的数字代替，软件——S，功能域——A1、A2……An

S＝{A1、A2、……An}

但是功能域B又存在若干问题P1、P2……Pm组成，并且每个功能对应于子系统中的一个软构件，可以表示为-B＝{P1、P2、……Pm}

功能G有若干个行为F1、F2、……Fj，每个行为对应于软件构件中的实现方法

G＝{F1、F2……Fj}

一个软件包含了所有功能的集合，同时包含了实现所以功能的所有方法和算法描述。需求分析是依据用户动机，经过需求问题识别，进行分析、消除分驰和综合，编写用户故事，评审；形成用户需求与设计同步，设计满足用户需求目标。

需求开发方法贯穿这个产品生命周期，利用不同的开发方法论进行挖掘需求，帮助用户找到问题，梳理问题，判断产品实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前进行周密的、全面的思考软件产品功能，用商业化行为解决需求与现实中存在的矛盾，解决用户需求与商业化产品功能融合，解决规范和个性化需求。
二、软件需求开发的目标

1、对实现的软件做一个全面的描述，帮助用户找到问题矛盾解决用户场景痛点，帮助用户在进行产品规划时做到周密，全面产品定位需求

2、了解和描述软件实现所需的全部信息，为产品设计、确认和验证提供一个基准

3、为软件产品管理人员进行软件产品成本评估和编辑软件开发计划书提供保障

需求开发-软件功能需求、软硬接口、非功能性需求、设计约束、反向需求、阅读支持信息。

软件需求分析尽量提供软件实现功能需求的全部信息，使软件设计人员和测试人员不在需要和需求方进行接触，保证需求分析的一致性和完整性。

三、软件功能需求

描述软件功能实现注意——

1、功能需求的完整性和一致性

2、功能描述的无异议和可追踪

3、功能描述清洗和功能可测试

四、软硬接口

1、人机接口

2、硬件接口

3、软件接口

4、通讯接口
五、非功能性需求

1、运行环境

2、时间需求

3、处理容限、精度、异常处理机制等

4、可靠性要求、可维护性、安全性

7. 如何进行需求分析

项目需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。 在原则上，需求阶段监理应尊重承建方的项目管理和项目分析能力；在具体的任务开展上，以不深入、不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，监理方必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用承建方的软件。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、开发范围上有发言权。 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。 2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设时，客户方的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建设方面的专家和知识。此时，用户就会要求软件系统分析人员替他们设想需求。工程的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 需求自身经常变动 根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。 分析人员或客户理解有误 软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作劳而无功。记得一则笑话，有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”所以分析人员知识的专一性也会造成需求分析的误解和失败。这时，咨询监理公司就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度和注重沟通技巧。 需求分析方法论 根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。 第一阶段：“访谈式”（Visitation） 这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式”（Incement） 这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。 实现手段：拜访（诱导）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式”（Afirm） 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档） 整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。

8. 需求分析,系统分析应该看什么书

瀑布模型：需求调研--调研报告--需求分析--概要设计--差异化分析--详细设计（接口规范、数据库设计）--系统开发--单元测试--联合测试--SIT--UAT--上线；
根据如上的软件工程方法论，不同的项目有不同的文档和过程方法，所以需求分析，我觉的没有固定的模式，也没有固定的某类教材，具体项目具体分析！
非要看书的话，可以看看软件过程！

9. 陪训需求分析报告包括什么

1．需求分析实施的背景，即产生培训需求的原因或培训动议。 3．概述需求分析实施的方法和过程。说明分析方法和实施过程可使培训组织者对整个评估活动有一个大概的了解，从而为培训组织者对分析结论的判断提供一个依据。 4．阐明分析结果。结果部分与方法论部分是密切相关的，撰写者必须保证两者之间的因果关系，不能出现牵强附会的现象。 6．附录。包括收集和分析资料用的图表、问卷、部分原始资料等。加附录的目的是让别人可以鉴定研究者收集和分析资料的方法是否科学，结论是否合理。 7．报告提要。提要是对报告要点的概括，是为了帮助读者迅速掌握报告要点而写的，要求简明扼要。有的评估报告根据需要也可以把提要置于评估报告的开头。 撰写评估报告时，在内容上要注意主次有别，详略得当，构成有机联系的整体。为此，在撰写前应当认真草拟写作提纲，按照一定的主题及顺序安排内容。

10. 软件系统分析与设计的目录

第1章系统计划
1.1系统项目的提出与选择
1.1.1系统项目的立项目标和动机
1.1.2各种项目立项的价值判断
1.1.3系统项目的选择和确定
1.1.4系统项目提出和选择的结果
1.2可行性研究与效益分析
1.2.1可行性研究的意义
1.2.2可行性研究的内容
1.2.3效益分析
1.2.4可行性分析报告的标准
1.3定义问题与归结模型
1.3.1定义问题和归结模型的意义
1.3.2定义问题和归结模型的方法论模型
1.3.3定义问题和归结模型的步骤
1.3.4定义问题和归结模型的若干手段
1.4系统方案的制定、评价和改进
1.5新旧系统的分析和比较
1.5.1新旧系统比较的目的
1.5.2新旧系统比较的原则和方式
1.6所需资源的估汁
1.6.1资源评估的意义
1.6.2描述资源
1.6.3项目实施所需要的可能资源
1.7现有软件、硬件和数据资源的有效利用
1.7.1意义
1.7.2手段
1.8流行的系统分析方法论
第2章需求分析与定义
2.1软件需求与需求过程
2.1.1什么是软件需求
2.1.2需求工程
2.2需求调查与问题定义
2.3可行性研究
2.4现有系统的分析
2.5需求分析
2.5.1需求分析的工作任务
2.5.2需求建模
2.6确认测试计划
2.7流行的需求分析方法论
2.7.1结构化分析
2.7.2面向对象分析
2.7.3面向问题域的分析
主要参考文献
第3章系统设计
3.1概论
3.2处理流程设计(工作流设计)
3.3系统人机界面设计
3.4系统的文件设计
3.5数据库管理系统的选择和数据库设计
3.5.1数据组织的分类
3.5.2数据库选择实例
3.6网络环境下的计算机应用系统的设计
3.7简单分布式计算机应用系统的设计
3.8系统运行环境的集成与设计
3.9系统过渡计划
主要参考文献
第4章软件设计
4.1软件设计基本原则
4.1.1信息隐蔽
4.1.2模块独立性
主要参考文献
4.2结构化设计方法
4.3面向对象设计
4.3.1面向对象的概念
4.3.2面向对象分析方法
4.3.3面向对象设计
4.4用户界面设计
4.5设计评审
主要参考文献
第5章软件测试
5.1软件测试的定义和目的
5.2测试用例设计
5.2.1黑盒测试
5.2.2白盒测试
5.2.3逻辑覆盖
5.3软件测试的策略
5.3.1单元测试
5.3.2集成测试
5.3.3确认测试
5.3.4系统测试
5.3.5测试和测试
5.4软件测试种类
5.5软件测试自动化工具
5.5.1软件测试自动化概述
5.5.2白盒测试工具——NuMegaDevPartnerStudio
5.5.3黑盒测试工具——QACenter
5.6面向对象的软件测试
5.6.1面向对象分析的测试
5.6.2面向对象设计的测试
5.6.3面向对象编程的测试
5.6.4面向对象的单元测试
5.6.5面向对象的集成测试
5.6.6面向对象的系统测试
主要参考文献
第6章软件维护
6.1软件的可维护性
6.2软件维护的分类
6.3软件维护的工作量
6.4软件维护作业的实施和管理
6.5预防性维护
6.6软件再生工程
主要参考文献
第7章系统的可靠性分析与设计
7.1可靠性概述
7.2系统的故障模型和可靠性模型
7.2.1系统的故障模型
7.2.2系统的可靠性模型
7.3系统的可靠性分析和可靠度计算
7.3.1组合模型
7.3.2马尔柯夫模型
7.4提高系统可靠性的措施
主要参考文献
第8章系统的安全性和保密性设计
8.1信息安全内容
8.1.1信息安全概念的发展
8.1.2信息安全研究的目标
8.1.3信息安全的常用技术
8.2访问控制技术
8.2.1访问控制的实现方法
8.2.2访问控制策略
8.2.3Bell-Lapala模型
8.3数据机密性
8.3.1对称密钥加密与AES
8.3.2非对称密钥加密与RSA
8.3.3门限密码学
8.3.4PKI
8.4数据完整性
8.4.1Biba完整性模型
8.4.2杂凑函数与消息摘要
8.5通信与网络的安全性
8.5.1网络环境下危及安全的因素
8.5.2网络安全层次模型
8.5.3通信与网络的信息安全技术
8.5.4防火墙技术
8.6系统安全管理与安全工程
8.6.1安全管理的必要性
8.6.2系统安全管理
8.6.3系统安全工程
主要参考文献
第9章文档编制
9.1软件文档
9.1.1文档的作用
9.1.2文档的分类
9.1.3文档编制的要求
9.1.4文档标准
9.1.5文档的管理与分发
9.2可行性研究报告
9.2.1可行性研究报告的作用
9.2.2可行性研究报告编写指南
9.2.3其他相关说明
9.3项目开发计划
9.3.1项目开发计划的作用
9.3.2项目开发计划编写指南
9.3.3其他相关说明
9.4需求规格说明书
9.4.1需求规格说明书的作用
9.4.2需求规格说明书编写指南
9.4.3其他相关说明
9.5数据要求规格说明书
9.5.1数据要求规格说明书的作用
9.5.2数据要求规格说明书编写指南
9.5.3相关技术
9.6用户手册
9.6.1用户手册的作用
9.6.2用户手册编写指南
9.6.3其他相关说明
9.7操作手册
9.7.1操作手册的作用
9.7.2操作手册编写指南
9.7.3其他相关说明
9.8测试计划、测试分析报告
9.8.1测试计划与测试分析报告的作用
9.8.2测试计划编制指南
9.8.3测试分析报告编制指南
9.8.4其他相关说明
9.9技术报告
9.9.1技术报告的作用
9.9.2技术报告编制指南
9.9.3其他相关说明
9.10开发进度记录
9.10.1开发进度记录的作用
9.10.2开发进度记录编制指南
9.10.3其他相关说明
9.11项目开发总结报告
9.11.1项目开发总结报告的作用
9.11.2项目开发总结报告编制指南
9.11.3其他相关说明
主要参考文献
第10章项目管理
10.1项目及项目管理的基本概念
10.1.1项目
10.1.2项目管理
10.2项目计划
10.3进度管理
10.4人员管理
10.5费用管理
10.5.1费用计划
10.5.2费用控制
10.6软硬件和数据资源的计划与管理
10.7项目环境管理
10.8与用户的协作
10.9标准化管理
10.10配置管理
10.11项目管理工具
10.12项目信息管理
10.13项目风险管理
10.14项目管理体制
10.14.1美国UCC公司项目管理体制
10.14.2IBM集成产品开发(IPD)体系
主要参考文献
第11章软件质量管理
11.1软件质量概述
11.2软件质量保证体系
11.2.1软件质量保证活动
11.2.2软件质量保证计划
11.2.3软件质量保证的实施
11.3软件质量保证标准
11.3.1标准的层次
11.3.2国家标准
11.3.3ISO标准
11.3.4CMM
11.3.5CMMI
11.4全面质量管理
11.4.1全面质量管理简介
11.4.2全面质量管理的实施
11.5六西格玛管理
11.5.1六西格玛管理的概念
11.5.2六西格玛管理的理念
主要参考文献
第12章实时系统分析与设计
12.1实时系统分析与设计方法
12.1.1有限状态机
12.1.2Petri网
12.2实时系统内核的设计
12.2.1实时系统调度算法
12.2.2实时任务管理和调度
12.2.3定时器和中断管理
12.2.4存储器管理
12.2.5I/O与文件系统
12.2.6网络通信
12.3实时系统分析与设计实例分析
12.3.1测控设备控制计算机实时系统分析与设计
12.3.2WindowsNT与Multibus系统实时串行通信软件的设
12.3.3全数字仿真计算机实时系统应用
主要参考文献
第13章嵌入式系统分析与设计
13.1嵌人式系统概述
13.1.1嵌入式系统的应用领域
13.1.2典型的嵌入式系统结构
13.1.3嵌入方式
13.2嵌人式系统开发的特点和要求
13.3嵌入式系统开发流程
13.4嵌人式系统开发的硬、软件资源
主要参考文献
第14章信息化基础知识
14.1信息与信息化
14.1.1信息的定义及其特性
14.1.2信息化
14.1.3信息化对组织的意义
14.1.4组织对信息化的需求
14.2政府信息化与电子政务
14.2.1政府信息化的概念、作用及意义
14.2.2我国政府信息化的历程和策略
14.2.3电子政务的概念、内容和技术形式
14.2.4电子政务的应用领域
14.2.5电子政务建设的过程模式和技术模式
14.3企业信息化与电子商务
14.3.1企业信息化的概念、目的、规划、方法
14.3.2企业资源规划(EfuP)的结构和功能
14.3.3客户关系管理(CRM)在企业的应用
14.3.4企业门户
14.3.5企业应用集成
14.3.6供应链管理(SCM)的思想
14.3.7商业智能(BI)
14.3.8电子商务的类型、标准
14.4信息资源管理
14.5信息化的有关政策、法规和标准
主要参考文献
第15章信息系统基础知识
15.1信息系统
15.1.1信息系统的概念
15.1.2信息系统的功能
15.1.3信息系统的类型
15.1.4信息系统的发展
15.2信息系统建设
15.2.1信息系统建设的复杂性
15.2.2信息系统的生命周期
15.2.3信息系统建设的原则
15.2.4信息系统开发方法
主要参考文献
……