需求分析
单项选择题
1、软件生产中产生需求问题的最大原因在于对应用软件的（）理解不透彻或应用不坚决。（C）模拟性
2、需求分析的目的是保证需求的（）。
（B）完整性和一致性
3、系统需求开发的结果最终会写入（）。（D）系统需求规格说明
4、现实世界中的（）构成了问题解决的基本范围，称为该问题的问题域。
（B）实体和状态
5、功能需求通常分为三个层次，即业务需求、用户需求和（）。
（D）系统需求
6、比较容易发现的涉众称为初始涉众，又称为（），通常包括客户、管理者和相关的投资者。（B）涉众基线
7、如果在最终的物件（Final Artifact）产生之前，一个中间物件（Mediate Artifact）被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的（）。
（C）原型
8、按照使用方式进行分类，原型可分为：演示原型、（）、试验原型和引示系统原型。
（D）严格意义上的原型
10、按照开发方法进行分类，原型可分为：演化式原型和抛弃式原型，其中抛弃式原型又被细分为（）。
（C）探索式原型和实验式原型
11、原型的需求内容可以从三个纬度上分析：即（）。
（A）外观、角色和实现
13、以下（）不是情景性的重要性质？
（C）完善
14、以下（）是情景性的重要性质？
（B）开放
16、下列（）属于定量硬数据？
（C）统计报表
17、下列（）属于定性硬数据？
（D）规章手册
18、功能目标可以分为 ( )。
（B）满足型目标和信息型目标
19、在表达软目标的分解和细化时使用的AND Contribution 链接和OR Contribution 链接，Contribution 的作用是（）。
（C）积极的或消极的
20、AND 链接将一个父目标连接到一系列细化的子目标，意思是如果能够满足所有细化的子目标，那么将（）父目标。
（D）足以满足
22、下列选项中，（）不是在目标模型中使用的其他模型元素。
（D）概念
23、面向目标方法的目标分析阶段的主要任务是（）。
（C）建立目标模型
24、场景的分类框架将场景方法从场景的（）4 个方面进行了分类和描述。
（A）形式、目的、内容和生命周期
25、场景的形式是指场景的表达模式，从形式上分为两个方面：（）
（C）描述和外观
26、描述场景所使用的表示法要符合正规性要求，一般可使用非形式化语言、半形式化语言和形式化语言。在实践中，（）是主要的描述方式。
（B）非形式化的自然语言
28、场景的内容是指场景所表达的知识类型。它被分为6 个不同的方面。下列（）不是场景的内容。
（C）目的
29、需求工程利用场景的目的可能有三种：即：（）。
（A）描述、探索和解释
30、使用解释性场景在需求分析时能够（），或者被用于进行需求的验证。
（B）降低模型的复杂性
31、下列（）不是场景方法在需求工程中的应用。
（B）编写系统需求规格说明
32、下列（）是组织场景时可用的场景关系。（A）合取关系
33、与其他的场景方法相比，用例最大的特点是采用了（）的描述方式。
（C）静态结构化文本
34、用例之间的关系主要有（）三种。
（D）包含、扩展和泛化
35、分析的活动主要包括识别、定义和结构化，
它的目的是获取某个可以转换为知识的事物的信息，这种分析活动被称为（）。
（D）建立需求分析模型
36、（）是建模最为常用的两种手段。
（B）抽象和分解
37、抽象通过强调本质的特征，（）了问题的复杂性。
（D）减少
38、需求分析仅仅需要描述解决方案，不需要探索实现细节的情况下，分析模型又是（）的，尤为适用。
（B）半形式化
39、上下文图描述系统与环境中外部实体之间的界限和联系。它从现实世界的角度说明
了系统的（），并确定了所有的输入和输出。（C）边界和环境
40、（）是结构化分析方法的核心技术，它表明系统的输入、处理、存储和输出，以及它们如何在一起协调工作。
（A）数据流图DFD
41、结构化、信息工程和面向对象三种方法学下的需求分析技术都是（）的。
（B）面向解系统
42、使用面向问题的技术对问题世界的建模就被称为（）需求阶段的分析。
（A）前期
43、使用面向解系统的技术对软件系统解决方案的描述称为（）需求阶段的分析。
（C）后期
44、需求分析活动的一个重要任务是进行（），明确用户需求的隐含信息，展开为明确的对软件系统的行为期望，即系统需求。
（B）需求细化
45、在分层结构中，DFD 定义了三个层次类别的DFD 图：（）、0 层图和N 层图。
（C）上下文图
46、因为数据存储是系统内部的功能实现，所以在将系统视为黑盒的情况下，上下文图中不会出现（）
（B）数据存储实例
47、数据建模技术能够弥补过程建模在（）方面的缺陷，它描述数据的定义、结构和关系等特性。
（C）数据说明
48、。概念实体是一种抽象概念，不考虑概念背后的物理存在，所以通常不包含与之相
关联的其他（）。（B）特征（即属性）
49、在ERD 建模中，实体通常所指的就是（）。（A）逻辑实体
50、ERD 中属性是实体的特征，不是数据。属性会以一定的形式存在，这种存在才是数据，被称为属性的（）。
（D）值
52、ERD 中关系的基数分为最大基数和最小基数。最大基数又被称为（）。
（A）键约束
53、在实体之间建立关系时，可能会产生一些附带的实体，被称为关联实体，最常见的形式是（）。
（B）进程实体
56、系统边界是指一个系统所包含的系统成分与系统外事物的分界线。用例模型使用一个（）来表示系统边界，以显示系统的上下文环境。（D）矩形框
57、UML 使用的行为模型有三种，即：（）。（C）交互图、状态图和活动图
58、项目的前景和范围文档、用户需求文档都被视为属于（），重点都是用户的现实世界。（D）用户文档
59、系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口需求规格说明文档和人机交互文档一起被用于系统开发的目的，都被认为是()。
（A）开发文档
填空题
1、传统的需求分析方法都是从设计领域转入分析领域的。
2、面向专业用户的纯工具型软件分析阶段的主要目的是为充分利用创新优势而进行巧
妙的功能安排。
3、面向普通用户的纯工具型软件进行分析的主要目的是进行方案权衡，寻找一套切实有效的功能配置。
6、软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为，
产生软件需求规格说明。
7、约束是不受解系统影响，却会给解系统带来极大影响的问题域特性。
8、优秀的需求应该具备 7 个特性，即完整性、正确性、精确性、可行性、必要性、无
歧义和可验证。
11、演示原型主要被用在项目启动阶段。
12、演示原型都是被用来展示用户想象中的系统视图，所以它要能够表现用户界面的重
要特征。
13、，如果一个问题的技术解决方案是不清晰的，演示原型也可以被用来展现相应的细
节功能以使用户确信该问题解决的可能性。17、实现是指原型物件完成功能的细节技术和方法。
18、使用演化式原型方法，在开发时就需要注意原型的健壮性和代码的质量。
19、使用实验式开发方法，需要实现多种技术方案，考察重要的系统的质量属性。
22、航空调度、证券交易、医疗手术控制等复杂的协同问题都具有突现的情景性。
23、民族志的一个主要应用目的就是研究和解决复杂的协同问题。
24、复杂的工作总会同时存在着正常流程和异常流程，异常流程大多是一些特殊情况下
的处理，限定了异常处理的上下文环境，即异常处理具有局部的情景性。
27、时间采样允许需求工程师建立指定的时间间隔来观察用户的活动情况。
28、文档审查主要获取对象包括相关产品的需求规格说明、硬数据和客户的需求文档。
29、文档分析通常是数据建模方法的一个基础部分，它是通过检查采集的硬数据来确定潜在的需求。
32、模型驱动方法的模型是在前期需求阶段的分析中建立的。
33、目标模型的一个核心要素是元素之间的关系，称为链接。
34、目标模型的链接有两类：一类是目标之间的链接；另一类是目标与其他模型元素之间的链接。
37、场景具有重点描述真实世界的特征，它利用情景、行为者之间的交互、事件随时间
的演化等方式来叙述性地描述系统的使用。38、静态外观的场景被展现为一个或者数个描述性的文本或者图片。
39、动态外观的场景会被以动态的方式展现出来，人们可能会要求按时序向前或者向后
浏览场景，也可能会要求跳转到场景的某一个时刻进行观察。
42、抽象场景，又称为类型场景，是以经验中的类别和抽象概念来描述事实。
43、探索性场景可以用来进行需求获取和需求建模与分析。
44、每个用例是对相关场景集合的叙述性的文本描述，这些场景是用户和系统之间的交
互行为序列，帮助实现用户的目的。
47、单个用例描述了系统的功能片段，系统的所有用例基于一定的关系组织起来，建立
用例模型，就可以描述整个系统的功能。
48、原有用例和新建立的抽象用例的关系即为包含关系。
49、在需求工程中，主要产生三类重要的文档：项目前景和范围文档、用户需求文档以及需求规格说明。用例文档通常被用来代替用户需求文档，起到记录、交流领域信息和用户期望的作用。
52、分解将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子问题之间的联系。
53、基于软件构建单位及其之间的关系建立的模型，用来说明软件逻辑上的构建方式和实现方式，由于它使用的组元及其关系都是软件的元素，因此它是来自于软件的模型，称为计算模型。
54、模型语言的三要素：语法、语义、语用。其中语用给出了一个模型元素描述的更宽广的上下文，以及影响该模型元素意义的约束和假定。
57、信息工程和结构化方法的本质差别在于解决问题的策略不同。
58、前期需求阶段分析的重点是理解问题世界，因此它关注的是整个问题世界，注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等等，软件系统只是整个背景下的一个要素。
59、后期需求阶段分析关注的是解系统解决方案的建立，因此它以软件系统为中心，注重于分析系统的内部功能以及它与环境的互动，是对系统功能的详细信息的分析。
62、微规格说明被用来描述DFD过程分解结构中最底层过程的处理逻辑。
63、DFD中所有的外部实体联合起来构成了软件系统的外部上下文环境，它们与软件系统的交互流就是软件系统与其外部环境的接口，这些接口联合起来定义了软件系统的系统边界。64、数据流是指数据的运动，它是系统与其环境之间或者系统内两个过程之间的通信形式。
67、为了保证DFD图的可理解性，0 层图应该被描述的简洁、清晰，所以在描述复杂的系统时，0 层图中不应出现太过具体的过程和数据存储。
68、DFD中对 0 层图的过程分解产生的子图称为1 层图。
69、数据建模建立的模型称为数据模型，是问题域和解系统共享的知识集合，通常能够反映企业业务的核心知识。
72、ERD的逻辑实体是对概念实体的细化，拥有完整的特征描述。
73、数据建模中对行为和事件的建模需要是为了了解它们在某些时刻的快照或者运行环境信息，而不是它们所体现出来的功能和达成的效果，所以称这类实体为进程实体。
77、一个实体可能有多个键，这些键都被称为候选键。
78、通常人们从多个候选键中选择和使用固定的某一个键来进行实例的标识，这个被选中的候选键被称为主键，没有被选做主键的候选键被称为替代键。
81、关系是存在于一个或多个实体之间的自然业务联系。
82、只有一个实体参与的关系存在于实体的不同实例之间，称为一元关系，又称为递归关系。
83、ERD中关系的基数分为最大基数和最小基数。最小基数又被称为参与约束。
86、ERD中被关系影响的实体主要是弱实体和关
联实体。
87、用例模型的基本元素有四种：用例、参与者、关系和系统边界。
88、UML行为模型是用例模型的实现，以更加详细的方式说明用例所描述的系统行为。
92、优秀的需求规格说明文档应该具备：正确性、无歧义、完备性、一致性、根据重要性和稳定性分级、可验证、可修改、可跟踪等特性。
93、需求验证常见方法有：需求评审、原型与模拟、测试用例开发、用户手册编制、利用跟踪关系和自动化分析。
94、评审又被称为同级评审，是指由作者之外的其他人来检查产品问题的方法。
97、需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力。
98、从需求向后回溯（前向跟踪的两种联系之一）说明软件需求来源于哪些涉众的需要和目标。
99、后向跟踪是指需求被定义到软件需求规格说明文档之后的演化过程。
判断题
1、需求工程包括需求获取和需求开发两个方面。（×）
2、需求验证是需求工程中最后一个活动。（×）
3、软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问
题域中的某些部分具有模拟特性。（√）
8、按照构建技术进行分类，原型可分为：水平原型和垂直原型。（√）
9、严格意义上的原型主要被用在需求分析阶段。（√）
10、要完成相同的功能，构建抛弃式原型比构建演化式原型所花费的代价要大得多。（×）15、原型修正主要依据评估人员的反馈，可以忽略事先的原型调整计划。（×）
16、文档审查是一种传统的需求获取方法，是专门针对文档进行的需求获取活动。（√）
21、AND 和 OR 链接用于描述目标的分解和细化关系。（√）
22、目标的发现并是一个自上而下分解的过程，也就是一个不断发现和细化的过程。×）
23、对系统的现状和背景进行分析往往能够发现重要的目标，得到一些明确的问题和缺陷，它们的反面就是系统需要实现的目标。（√）28、描述性场景的目的是为了记录已经得到的需求，即整理每次需求获取行为中得到的信息。（√）
29、UML 就是以用例来捕获系统所有的系统需求的。（×）
30、用例的内容只能包含有正常流程，而不能包含有异常流程。（×）
35、抽象一方面要求人们关注重要的信息，同时又不能忽略次要的内容。另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节。（×）
36、由于计算模型的形式化特征不适合于需求工程阶段，因此计算模型不适合用于需求分析中的建模。（√）
37、具有形式化特征的计算模型是用户和开发者共同理解的模型。（×）
42、上下文图是 DFD 的一个特定层次，被用来说明系统的上下文环境，确定系统的边界。（√）43、外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统，但它们要受系统的控制，开发者可以以任何方式操纵它们。（×）
44、上下文图以黑盒看待和描述系统的方式使它非常适合描述系统的应用环境、定义系统的边界，这正是 DFD 在层次结构中将其置于最高层的原因。（√）
50、发起或触发用例的外部用户以及其他软件系统等角色被称为参与者。（√）
51、交互图是对单个用例的典型场景的实现，适合于事务性业务工作的表示。（√）
52、UML 行为模型的状态图是以状态机模型的方式进行的用例实现。状态图只能用来实现单个用例。（×）
55、软件需求规格说明文档是对部分系统功能分配给软件部分的详细描述。（×）
56、硬件需求规格说明文档是对整个系统功能当中分配给硬件部分的详细描述。（√）
57、人机交互文档是对整个系统功能中需要进行人机交互部分的详细描述。（√）
58、验证活动同样普遍存在于需求分析过程中。（×）
60、前向跟踪是指需求在被获取到软件需求规格说明文档之前的演化过程。（×）
名词解释
1、需求工程：需求工程是软件工程的一个分支，它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
3、需求分析：需求分析是利用建模与分析技术对获取笔录的内容进行明确、整理、汇总，建立一个综合考虑问题域特性和需求的系统模型，然后根据系统模型将用户需求转化为系统需求的需求工程活动。
8、结构化面谈：结构化面谈指在面谈的过程中，会见者会完全按照事先的问题和结构来控制面谈。结构化面谈通常被用来获取一些比较确定或者选择空间比较有限的信息，一些统计性倾向信息的获取也可以使用结构化面谈。
9、半结构化面谈：半结构化面谈指在面谈的过程中，事先需要根据面谈内容准备面谈的问题和面谈结构。但在面谈过程中，会见者可以根据实际情况采取一些灵活的策略。半结构化面谈是在需求获取中应用最多的一种面谈类型，
能够处理大部分的需求获取任务。
11、头脑风暴（Brainstorming）：是一种特殊的群体面谈方式，它的目的不是发现需求，而是“发明”需求，或者说是发现“潜在”需求。它鼓励参与者在无约束的环境下进行某些问题的自由思考和自由讨论，以产生新的想法。它是需求获取中用于“发明”需求的方法，但它会增加需求的数量。
14、场景：场景是对系统和环境行为的局部描述，或者说场景是对行为或者事件序列的描述，序列中的行为和事件是系统需要完成的一个任务的特殊示例。
16、民族志：民族志是由人类学家最早提出来的，用来理解原始社会（Primitive Societies）的社会机制。它要求人类学家花费长期的时间（通常是数年）在被研究的社会中生活并且仔细观察该社会中的实际活动，得到第一手的观察数据。对这些观察数据的分析可以揭示被研究社会的社会结构、组织方法和具体活动。
18、用例驱动法：用例是一种场景的文本化表现方式，使用叙述性的文本来描述场景。以用例为核心，围绕用例开展活动的软件开发方法被称为用例驱动的软件开发方法。
20、过程建模：过程建模是结构化分析方法的典型技术。过程建模将系统看做是过程的集合，其中一些由人来执行，另一些由软件系统来执行。过程建模使用的主要技术有上下文图、数据流图、微规格说明和数据字典等。
21、上下文图：上下文图是DFD 最高层次的图，是系统功能的最高抽象，它将整个系统看做是一个过程，这个过程实现系统的所有功能。上下文图中存在且仅存在一个过程，表示整个系统。这个单一的过程通常编号为0。
27、OCL（语言）：OCL（Object Constraint Language）称为对象约束语言。OCL 不是编程语言而是一种建模语言，它在保证一定表达能力的前提下，注重于语言的简洁性和抽象性。但它无法被用来描述程序的控制逻辑和工作流程，而且它的表达式定义也无法在程序中得到直接的执行。
29、需求基线：需求基线（Requirements Baseline）就是被明确和固定的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合。
问答题
3、简要说明需求获取活动的过程。
答：（1）收集和应用背景资料，建立初始的知识框架。分析涉众的高层次问题，总结出系统的业务需求。
（2）设计一个高层次的解决方案，并确定解决方案需要具备的系统特性。高层次的解决方案和系统特性定义了项目的前景和范围。
（3）在项目的业务范围内，需求工程要寻找相关的涉众，并分析和涉众选择。
（4）对组织里存在大量的表格、单据等与业务相关的硬数据进行采样，它们是需求获取活动中一个重要的信息来源。
（5）针对某一次具体的需求获取活动，要依据项目范围确定主题和内容，涉众特征和硬数据，从而确定信息来源。获取方法通常只有综合内容、来源和系统环境三者才能做出正确的决定。在内容、来源和方法都确定之后，需求工程师就可以开展具体的获取活动，获取用户需求和问题域特性。获取得到的具体信息要记录下来，以获取笔录的形式进行保存。
13、下图描述了火车管理系统的目标模型片段，试分析该目标模型关系。
答：图中，火车管理系统主要有三个高层的软目标：服务更多的旅客（ServeMorePassengers）、尽可能降低成本（Costs，类型Min）和安全运输（SafeTransport）。对ServeMorePassengers 的工作可以同时从增加新班次(NewTracksAdded)和提高原有班次效率上着手。提高原有班次效率则可以通过提高列车运行速度（TrainSpeed，类型Max）或者缩短班次间隔（DistanceBetweenTrains，类型Min）来实现。降低成本的实现可以考虑降低新投资（DvlptCosts，类型Min）或者降低运营成本（OperationCosts，类型Min）。而增加新班次（NewTracksAdded）的目标要求可能会增加降低新投资目标的实现困难。在实现安全运输的措施中，有三个是必须达到的：
①要保持安全的车距（WCS—DistBetweenTrains，类型Maintain）。
②列车的速度要保持在轨道能够承受的范围内（TrackSegmentSpeedLimit ，类型Maintain）。
③列车不要进入已经关闭的站台（TrainEnteringClosedGate，类型Avoid）。14、下图是为一个会议安排系统建立的目标模型，请分析说明该目标模型。
答：图中所示的目标模型。系统有两类行为者，一类是会议的发起人Meeting Initiator，另一类是会议的参加者Meeting Participant。在会议的参加者中，又有一些比较特殊的人员，它们的参加与否对会议的成败有着至关重要的影响，因此被单独列为一类行为者Important Participant。Meeting Initiator 成功安排会议的目标是让Meeting Participant （尤其是Important Participant）出席会议（Attends Meeting）。而且为了保证会议的成功，Meeting
Initiator 要相当程度上能够确信Important Participant 会出席会议（Assured（Attends Meeting））。会议应该安排在一个所有Meeting Participant 都空闲的时间，也就是说不能安排在Meeting Participant抽不出身来的时间（Exclusion Dates）。在了解所有Meeting Participant 的空闲时间之后，Meeting Initiator 可以提出一些可能的会议时间（Proposed Dates）。然后，Meeting Participant 从中选择一个自己倾向的时间（Preferred Dates）。在对所有会议参与者的倾向时间进行协调之后，可以确定最终的会议安排情况Agreement。
22、请说明如何快速有效地判定一个DFD图是否为原始DFD图？
答：功能分解的过程需要持续进行，直至最终分解产生的子图都是原始DFD图，关键问题是如何快速有效地判定一个DFD图是否是原始DFD 图。在分解产生的子图为下述情景之一时，可以判定其为原始DFD图，此时应该停止持续的功能分解活动：
①所有过程都已经被简化为一个选择、计算或者数据库操作。
②所有数据存储都仅仅表示了一个单独的数据实体。
③用户已经不关心比子图更为细节的内容，或者子图的描述已经详细的足以支持后续的开发活动。
④每一个数据流都已经不需要进行更详细的切分，以展示对不同数据的不同处理方式。
⑤每一个业务表单、事务、计算机的屏幕显示（Computer On-line Display）和业务报表都已经被表示为一个单独的数据流。
⑥系统的每一个最低层菜单选项都能在子图中找到独立的过程。
28、简述需求管理的主要作用。
答：在实践中发现的需求管理的作用有：
①增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解。
②增进了项目涉众之间的交流。
③减少了工作量的浪费，提高了生产力。
④准确反映项目的状态，有助于项目决策。
⑤改变项目文化，使得需求的作用得到重视和有效发挥。
30、简述如何进行需求变更控制？
答：需求开发是一个获取、明确并定义需求的过程，但需求并不是在需求开发结束之后就会恒定不变的。首先要认识到在很多情况下，需求的变化是正当和不可避免的：
①问题发生了改变。软件被创建的目的在于解决用户的问题，可是随着时间的发展，形势可能会发生变化，导致用户的问题也发生了变化。②环境发生了改变。软件是通过与其周围环境进行交互的方式来解决用户的问题的。
③需求基线存在缺陷。需求开发的理想结果当然是建立一个完全无缺陷的需求基线，但这是不可能达到的目标。因为需求工程的复杂性，需求开发得到的需求基线总是或多或少的会遗留下一些缺陷。
④用户变动。在开发和使用中，软件产品的用户可能发生的人员更替，这时新的用户就可能会提出和原有用户不同的要求。
⑤用户对软件的认识变化。随着对软件开发和使用的直接参与，用户会对软件领域有越来越多的了解，这时他们也往往会提出越来越多、越来越具体的需求，其中就夹杂着对原有需求的修改要求。在一个全新的领域或者为一个没有软件经验的企业开发软件时，这种情况非常常见。
⑥相关产品的出现。在产品开发的过程中，可能会有竞争产品、类似产品或者需要交互的其他产品等相关产品出现，这时往往需要开发者根据相关产品的新鲜知识，变更原有的软件需求和开发计划。
31、在功能分解过程中，最重要的是要保证分解过程的平衡性（Balance）。平衡性是保证功能分解不会导致需求内容出现偏差的方法，它要求 DFD 子图的输入流、输出流必须和父过程的输入流、输出流保持一致。请对下图的平衡性做出分析。
答：在上图所描述的功能分解中，父过程 P 的输入流是 a，输出流是 b。在 P 分解后产生的
子图当中，a 是唯一从子图范围之外进入子图的数据流，所以 a 是子图唯一的输入流。同样b 是唯一从子图流向范围之外的数据流，所以b 是子图唯一的输出流。这样，P 的输入流、输出流就和子图的输入流、输出流保持了一致，对 P 的功能分解就满足了平衡性。
32、在功能分解过程中，最重要的是要保证分解过程的平衡性（Balance）。平衡性是保证功能分解不会导致需求内容出现偏差的方法，它要求DFD 子图的输入流、输出流必须和父过程的输入流、输出流保持一致。请对下图的平衡性做出分析。
答：上图所表示的功能分解中，父过程的输入流为 a，父过程输出流为 b，子图的输入流为a 和 c，子图的输出流为 b。这样，虽然父过程和子图的输出流保持一致，但它们的输入流却存在差异，于是图所描述的功能分解破坏了平衡性，是一个错误的功
案例分析
1、请按下列描述，用 DeMarco-Yourdon 和 Gane-Sarson 表示法分别画出“食物订货系统”的过程模型图（DFD ）。
图 1 用 DeMarco-Yourdon 表示法表示的 DFD
图 2 用 Gane-Sarson 表示法表示的 DFD
3、从下面的事件中，你可以替 Jeannine 总结出哪些教训? 答：（1）她没有仔细认真地分析问题：
（2）她没有及时跟相关人员交流信息，没能把握住有价值信息：
（3）她没能及时跟公司员工交流，引用过时的文件结构；
（4）她没有仔细研究分析新引进的系统的性能需求是否满足：
（5）她没有仔细研究新引进的系统的功能需求是否满足；
（6）她没有仔细研究引进的系统的质量属性，对外接口是否满足。
5、你被任命为替换学生财务资助项目的项目经理。财务资助部门的主管坚持要你 15 个月、600 000 美元的预算内替换他现有的系统就可
以了。他说这就是你需要知道的全部，不需要浪费时间开发一个工作陈述了。省略工作陈述的风险是什么?你将如何说服主管?
答： 省略工作陈述的风险是不能明确项目的前景和范围。如果省略了工作陈述的话，你就不能和用户进行很好的沟通与交流，这样，项目的问题也就不能明确，即，开发人员无法与涉众对问题达成共识；无法明确问题，也就无法发现正确的业务需求，无法定义良好的解决方案及系统特性，继而无法明确项目的前景和范围，这样就会造成项目的不稳定甚至失败！ 13、下面是系统分析团队的一名成员提出的第一份面谈报告：在我看来，面谈进行的很好。我和他就这个问题聊了一个半小时。他告诉我有关公司的所有历史。他也提到，自他来到该公司的16年间，公司没有任何变化。我们不久将再次举行会面，以及结束这次面谈，因为我们还没有深入研究我准备的问题。”
（1）试评论这个面谈报告。假设你要团队成员使用下图提供的报表，那么他漏了什么主要信息？
（2）什么信息对面谈报告来说是无关紧要的？ （3）如果真的发生了报告中提及的情况，则必须向队友提出哪3个建议，以帮助他更好地举行下一次面谈。 答：（1）面谈时间稍长，而且控制不佳。遗漏了关于“最新建议的系统的观点” （2）有关公司的所有历史
（3）参考面谈过程一一面谈主体阶段： ①控制面谈的过程。面谈开始的时候可以通过例如谈公司历史来酝酿一下交流的气氛，
但是不能偏离主题。如果长时间的谈论不相关的信息的时候。需求分析人员就可以委婉的提 醒面谈对象。并重新切回正题。 ②注意保持面谈的主题。针对每个面谈的目标，要在面谈的过程中安排合适的提示。 逐一引导面谈对象对各个主题的叙述。 ③总结面谈的要点，注意此次面谈过程的成功和失误，明确下次的目标。以便为下次 面谈做充分的准备
需求调研报告(多篇)
需求调研报告(精选多篇) 莆田晚报社人才需求情况调研报告 为了了解当代媒体及企业对与人才的需求，更好的了解自己的汉语言文学专业，了解单位人才需求的渠道，为更好的学习自己的专业打下良好的基础，我在xx年的暑假的认识实习期间，以提问的形式，对莆田晚报社的同事以及一些领导以提问的方式进行调查。 一．媒体对新闻人才的需求及对大学生的要求 （一）对人才的需求 我在莆田晚报社见到了林总编。莆田晚报社隶属于《莆田晚报》是中共莆田市委主管、湄洲日报社主办的一份综合类报纸，是莆田市最有影响力的媒体之一。在被问及对人才的需求时，林总编首先表示，媒体。尤其是平面媒体，对于人才的要求是在变化的。在过去，报社所要的记者，是综合性的人才，有扎实的文字功底，负责对消息的采集和报导，报纸的版面内容，也大都是新闻事实。而现在，随着报纸内容的多样化，版面的专业化，专栏专刊不断增多，报社所需要的，更多的是专业性的人才。 林总编谈到，由于报纸具有深层次报导的能力，报纸为受众所展现的，更多的是综合分析之后的结果，平常的生活琐事后面也许有着经济纠纷或者法律问题，这就需要经济或者法律方面的人才。 （二）是否招聘应届毕业生 在谈到是否招聘应届毕业生的问题时，林总编表示，莆田晚报社会招收应届大学毕业生。他提供了一些数据：05年，招聘一个浙大
新闻系的毕业生，一个浙师大的，还有一个湖南师范大学的；03年，招聘安徽大学毕业生2个；02年，招聘武汉的大学毕业生1个。林总编谈到，报社找人的范围是文科类专业或是与新闻类专业有关的大学毕业生，如文秘历史经济法律等。林总编认为现在的报纸越来越贴近人民生活，语言亲切，口语化，所以报社对记者的文字要求并不是很高，最主要的还是一种新闻的敏感性。所以报社非常欢迎经济或是法律类的人才，“当然了，要是新闻学士学位，又有法律或经济硕士的学位，我们是大大的欢迎了。”林总编幽默的说 （三）对毕业生具体的要求 关于现在大学毕业生的工作能力问题，林总编认为确实并不突出，缺乏经验和 实践能力是最主要的缺点。他认为这是一个应知和应会的问题。学校的教材有些理论方面的知识与现实并不合拍，造成大学毕业生面临实践时的困扰。林总编还指出锻炼需要一个过程，刚走上工作岗位，实践不够，很难做出成绩，所以在大学期间，大学生应加大实践，锻炼自己的能力。 关于这个问题，赵书记的看法是一样的。可见实践能力是大学生在校要注意锻炼的。而有些实习生往往实习的时候很勤快，一旦被录用就开始懒散，这是非常不好的。另外，赵书记还补充，工作主动性不够也是大学生的缺点，总要领导布置了任务再去完成它。
怎样做需求分析之五：调研之需求研讨.
怎样做需求分析之五:调研之需求研讨 作者 : fangang 发布时间 : 2012-02-08 00:20 前面我们探讨了业务研讨会应当怎样组织, 下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底, 那么讨论业务需求就是需求分析人员的功底。 以往我们常常认为, 需求分析是一件最简单的事情。客户说他们需要做一个什么软件, 有些什么功能, 我们照着做就可以了,所谓的需求分析员就是需求的记录员。我要说, 这是一个极大的错误,许多失败的软件项目, 或者说软件项目中的需求问题,大多都源于此。经过人们多年的研究发现, 在需求分析过程中, 客户存在的最大问题就是提不出正确的需求, 这表现为几种形式: 1. 由于对软件不了解,客户提不出需求,不知道软件最终会做成什么样子。这类客户在需求讨论过程中,往往只能描述目前自己手工管理的方式是怎样的,不知道计算机会怎样管理。 2. 能提出一些业务需求,但当软件做出来摆在自己面前时,需求就变了。这类客户,他们能熟练使用电脑, 对信息化管理是清楚的。他们提出的业务需求从整体上应当是八九不离十的。但是,由于没有实物,在软件中的一些具体操作并没有完全想清楚。因此,当软件真正做出来摆在自己面前时, 甚至经过一系列流程操作以后, 会对一些操作提出变更需求。他们正如那句经典的话说的:“I have changed when it saw it.” 3. 能非常详细地提出业务需求,甚至有时候该怎么做的提出来了。这类客户,参与过很多软件信息化建设, 甚至有些还是软件开发的半专业人士。但是他们提出的业务需求过于具体, 甚至怎样实现都说出来了, 但这些有时候不是最佳设计方案、可能在技术上难于实现, 甚至有些就是过于理想化而不可实现。 因此, 我在进行需求研讨的时候, 首先跟客户探讨的不是软件功能, 而是客户现有的业务知识,用专业的话叫“ 业务领域分析” 。客户现有的业务流程是什么样的,
软件需求分析说明书模板
保密级别：S 资料编号：SRS-[产品代号] -[序列号] 版本：V[*].[*] [产品型号名称（二号字体）] [部件型号名称（可选、小二号字体）] 软件需求分析说明书 共11页 编制： 审核： 审定： 会签： 批准： XXXXXXXXXX公司 [****]年[**]月[**]日
文档修改记录
目录 1引言 (2) 1.1编写目的 (2) 1.2范围 (2) 1.3定义、首字母缩写词和缩略语 (2) 1.4参考资料 (2) 2项目概述 (3) 2.1产品描述 (3) 2.2产品需求 (3) 2.2.1功能需求 (3) 2.2.2性能需求 (4) 2.2.3可服务性需求 (4) 2.3用户及用户特点 (4) 2.4一般约束 (5) 2.5假设和依据 (5) 3用例描述 (5) 3.1用例1 (5) 3.2用例2 (6) 3.3用例n (6) 4外部接口需求 (7) 4.1用户接口 (7) 4.2硬件接口 (7) 4.3软件接口 (7) 4.4通信接口 (8) 5设计约束 (8) 5.1其他标准的约束 (8) 5.2硬件的限制 (8) 6属性 (8) 6.1可用性 (8) 6.2安全性 (9) 6.3可维护性 (9) 6.4可转移＼转换性 (9) 6.5警告 (9) 7其他需求 (9) 7.1数据库 (9) 7.2操作 (10) 7.3场合适应性需求 (10) 8附录 (10)
[说明：本模板中的蓝色字体与橙色字体为说明性文字，在最终提交的文档中请删除这些说明性的文字。] 1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。 1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义、首字母缩写词和缩略语 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
如何进行管理信息系统需求调研分析
如何进行管理信息系统需求调研分析 摘要：本文是在管理信息系统需求调研实践和学习中的一些经验总结，有些是自己的体会，有些来自专家的书本或文章，希望与大家分享，并起到一个抛砖引玉的作用，如有不妥之处欢迎指正。 一、软件需求的定义 IEEE软件工程标准词汇表（1997年）中定义的需求为： （1）用户解决问题或达到目标所需的条件或能力； （2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力； （3）一种反映上述条件和能力的文档说明。 二、需求分析的几个方面 需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段，包括以下几个方面：确定软件所期望的用户类；获取每个用户的需求；了解实际用户任务和目标以及这些任务所支持的业务需求；分析员与用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息；将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件；了解相关质量属性的重要性；讨论得出实施优先级；将所收集的用户需求编写成需求规格说明和模型；评审需求规格说明，确保与用户达成共识。 软件需求的各组成部分如下图所示：
三、需求文档规范 A、三种编写方法 1、用好的结构化和自然语言编写文本型文档； 2、建立图形化模型，这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系； 3、编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 多种编写方法可在同一个文档使用，根据需要选择，或互为补充，以能够把需求说明白为目的。 B、应有成果 1、各业务手工办理流程文字说明； 2、各业务手工办理流程图； 3、各业务手工办理各环节输入输出表单、数据来源；
需求分析：需求调研的七种方法
需求分析：需求调研的七种方法要想给人做管理软件，首要的事情自然是把人家现在的业务内容、管理方式弄清楚。即使你是这个领域的业务专家，也要明白一点，无论业务内容是否相同，管理方式一定是不同的，业务可以复制，技术可以复制，管理不能复制。例如，要给仓库做管理系统，需要先了解这个仓库是怎么管理的，怎么出库，怎么入库，怎么盘点，怎么核算；需要给采购部做管理系统，需要先了解采购部是怎么运作的，怎么制定采购计划，怎么下采购单，怎么签订采购合同，等等。 开发信息管理系统，首当其冲的需求来源就是如何将现在的手工业务电子化，没有这一步，说什么资源整合，说什么提高效率，说什么降低成本，说什么智能决策，都是浮云。对于管理软件来说，需求获取重点在如何理解客户业务，这是需求获取阶段最重要，也是最困难的事情，当然，对于需求分析者来说，理解业务与需求获取往往是交错进行的，很难割裂开来。 需求获取一般包括这几种方式：观察法、体验法、单据分析法、报表分析法、问卷调查法、访谈法、需求调研会法。这是需求调研的“七种武器”，它们各有优缺点，无论你想要了解的是什么需求，都需要将这些方式组合应用，针对你想要了解的内容，以及需要了解的对象的工作特点，采用不同的方式。学会并坚持使用这七种武器后，我想你很快就会成为需求调研的真正高手。 观察法 观察法，就是你自己跑到工作现场，看！这个看上去相当简单，貌似走马观花，有些不在行的兄弟会弄得跟公费旅游一般，车间里走走散散心，撩撩HR妹子，就认为是观察法调研了，其实不然。这种方法，关键是要看人家是怎么工作的，拿了什么，干了什么，用了什么工具，送出去什么，什么时候填写了什么单据，制作了什么报表，等等。 体验法 体验法，就是你自己亲自到相关部门去顶岗，做一段时间的业务工作，有了亲身体验自然更容易理解这个岗位的工作。这种方法，最大的优点就是理解业务比较深刻。一旦你几乎成了某岗位的一员后，想想，还有什么比自己帮自己做软件更能够把握需求呢？要给超市收银员写个软件，先到超市卖几天东西，要给仓库做软件，先到仓库发两天货，你的软件偏离用户需求的可能性会大幅度降低。
需求分析说明书
《人力管理系统-需求计划》 需求分析说明书 1.引言 1.1编写目的 能够为系统分析师设计完成概要设计提供资料。 1.2背景 1）《人力资源管理系统-需求计划》； 2）参与者：系统分析员，软件工程师，测试工程师。 3）使用者：人力资源部门员工和部门高级管理人员。 1.3专门术语的定义 岗位本职：该岗位的工作职责范围。 岗位任职资格核心要求：指该岗位上的员工所要具备的资格和技能。 1.4参考资料 《需求调研报告》 《面向对象设计思想》 《UML设计思想》 1.5阅读对象 本文档的读者是参与《人力资源管理系统开发》的软件工程师和测试工程师，本系统的使用将极大提高工作效率，简化手工作业流程，降低手工工作量和错误率。 2任务概述 2.1 目标 提高人力资源部门的工作人员和高级管理人员完成“人员需求计划”工作的效率，以软件系统的灵活的处理方式来简化繁琐的人工操作工程。
2.2 用户特点 1) 熟悉基本的计算机操作； 2) 熟悉人力资源管理工作的内容和流程； 3) 高级管理人员； 2.3 假定和约束 开发的期限为1个月。 开发的人员为N人 2.4总体需求描述 1)通过组织管理中有关管理模块或人事管理模块相关信息，提醒：出现岗位空缺（向用人 部门主管、负责人，人力资源部招聘中心负责人、部长提示）。 2)提示用人部门负责人该岗位的需求信息，形成需求计划。 3)确定是否执行需求计划，若选定为“暂不需要”，则待约定日期到期后再提醒，若选定为“需 要”则自动转入待批准需求类计划列表当中。 4)人力资源部人力规划与招聘中心审批待批准需求计划，进行一次审核。 5)人力资源部长进行二次审核，若审核通过（列明可选理由并附文字说明）进入三次审核， 若不通过（列明可选理由并附文字说明）则将该记录保留并抄转至用人部门负责人，并 予以提醒。 6)分管副总进行三次审核，若审核通过（列明可选理由并附文字说明）则在招聘计划板块 生成招聘需求，若不通过（列明可选理由并附文字说明）则将该记录保留并抄转至用人 部门负责人，并予以提醒。 7)最后向招聘中心负责人、人力资源部长、分管副总、用人部门负责人提醒：用人部门已 经提交两周后未及时处理的需求计划。
需求分析调研报告(共6篇)
需求分析调研报告（共6篇） 需求分析调研报告（共6篇） 第1篇需求分析之需求调研报告XX系统需求调研报告键入文字XX系统需求调研报告1 引言 1.1 编写目的//为什么要编写本文档 1.2 调研背景//简述调研过程，参与人等 1.3 专业术语//解释本文档中用到的专业术语 1.42 概述 2.1 项目目标//希望对企业管理改善达成的目标 2.2 期待解决的问题//希望通过本项目解决的管理问题XXX1编写人XX系统需求调研报告键入文字 2.3 项目范围//本项目的工作边界 2.4 双方约定//澄清双方理解上可能产生冲突的地方 2.53 相关资料//经过整理的对以后阶段有用的资料 3.1 组织结构 3.2 用户名单 3.3 重要业务规则 3.4 XXX2编写人XX系统需求调研报告键入文字编写人XXX4 需求//整理所有需求，这是本文档的核心内容，可以以业务领域为维度，也可以以软件功能为维度 4.1 财务部
4.2 计划部 4.35 数据//整理本系统需要处理的所有数据 5.1 销售合同 5.2 采购单 5.36 相关系统//可能跟本项目有关系的其它软件系统3 XX 系统需求调研报告键入文字 6.1 系统A 6.2 系统B 6.37 其它 7.1 注意事项//注意点 7.2 待定问题//没有定论，还需要继续讨论的问题 7.3 ** 省略号表示编写者可以自由添加内容** 各章节编写注意点请参见书籍清华大学出版社实战需求分析编写人XXX4第2篇客户需求调研分析报告客户需求调研分析报告本阶段是销售的基础阶段，评估的准确细致与否对于项目的成败影响很大。需要评估客户的真正需求.客户的决策链.资金预算.信用状况.招标方式.竞争对手等等情况。包含下述部分。客户现状分析（1）调查客户组织结构.建立组织关系层次图；（2）分析信息技术对客户业务的潜在影响；（3）与企业中高层管理人员讨论，对所得信息和分析进行补充和确认；（4）客户现有信息系统分析（现有系统和数据存储的清单.信息结构的范围.信息需求列表.组织.技术环境）；客户业务需求分析分析业务过程细节.分解业务过程.
需求分析说明书、详细设计说明书、概要设计说明书样例
以下是需求分析说明书、详细设计说明书、概要设计说明书样例 需要详细资料的去 https://www.wendangku.net/doc/917341373.html,/BBS/view.asp?ID={CA9329C0-93C5-4417-9170-452FF61E8C DB}&page=1下载 XX系统概要设计说明书 目录 1. 文档介绍1 1.1 文档目的1 1.2 文档范围1 1.3 读者对象1 1.4 参考文献1 1.5 术语与缩写解释1 2. 系统概述2 3. 设计约束2 3.1需求约束2 3.2隐含约束2 4. 设计策略3 4.1扩展策略3
4.2复用策略3 4.3折衷策略3 5．系统总体结构3 5.1、系统总体结构3 5.2、子系统功能及接口4 6. 子系统的结构与功能5 6.1、TERMSERV 5 7. 功能需求追溯5 8. 环境的配置5 9．其它6 附录 6 A、与主机接口6 B、与终端接口6 1. 文档介绍 1.1 文档目的 编写该文档的目的在于从总体设计的角度明确xxxx系统的功能和处理模式，明确与银联的接口，使系
统开发人员和产品管理人员明确产品功能，可以有针对性的进行系统开发、测试、验收等各方面的工作。 1.2 文档范围 1.3 读者对象 该文档的读者为用户代表、软件分析人员、开发管理人员和测试人员。 1.4 参考文献 《xxxx系统需求说明书》 1.5 术语与缩写解释 无 2. 系统概述 XX系统是以触摸屏为主要交互工具，帮助用户以自助方式做业务查询。本系统的主要功能包括：话费 查询、新业务介绍、网点分布查询、自助终端分布查询、电信新闻、交易监控、设备维护和监控等。本系 统的设计目标是保证系统可以7*24小时安全、高效无故障运行；业务人员可以轻松完成设备和交易的监控 、管理工作；报表种类齐全，可以满足业务人员各种帐务需求。 3. 设计约束
培训需求分析的六种模型
一、Goldstein三层次模型 二十世纪八十年代，I·L·Goldstein、E·P·Braverman、H·Goldstein三人经过长期的研究将培训需求评价方法系统化，构建了Goldstein三层次模型。 Goldstein三层次模型是培训需求分析的重要理论基础，它最大的特点就是将培训需求分析看成了一个系统，进行了层次上的分类，通过将组织、任务、人员的需求进行整合，使得培训需求更加全面化，分析结果更加科学化。该模型将培训需求分析分成了三个部分：组织分析、任务分析和人员分析。 Goldstein三层次模型图如图2-2所示： 图2-2 Goldstein三层次模型图 1、组织分析 组织层次的分析将组织的长期目标和短期目标作为一个整体来考察，同时考察那些可能对组织目标发生影响的因素。组织的需求分析由人力资源分析、效率指标分析和组织气氛分析三部分组成。 人力资源分析将组织目标表现为人力资源的需求、技术的需求以及为满足这些需求而制定的计划。培训将在实现需求与供给之间的匹配方面发挥重要的作用。 效率指标分析针对目前组织的效率状况。常用的效率指标包括工资成本、产出的数量和质量、、设备利用情况等。首先确定这些指标的标准，然后评估实际的组织效率状况，就可以得到相应的培训需求。 组织气氛分析用于描述组织气氛是否适宜，员工各方面的工作感受如何。如果通过分析发现差距很大并且影响到大部分员工时，就有必要引进培训来解决。 2、工作分析 组织分析旨在从全局上把握整个组织与工作群体的培训需求，属于较为全局性的层面，而针对每项具体工作的具体培训需求，必须通过工作层次的分析才能加以识别。
进行工作分析时，首先应掌握以下三方面的信息：每项工作所包含的任务；完成这些任务所需要的知识、技能、经验、个人特质等；衡量该工作的可接受的绩效标准。 这些信息可以从国家有关部门制定的一些规范、标准中得到，也可以通过观察、记录分析、跟踪等手段从企业内部获得一手资料，从中识别和收集。 接着对工作岗位上的人员工作现状进行评价。评价手段包括资料调查、行为观察、表现记录分析、舆论调查、访谈、典型事件分析、技能考核等。 通过现状与标准的比较，识别差距、分析原因，就可以确认相应的培训需求。 3、人员分析 个人层次的分析针对每一位员工个体进行，最终落实到“谁需要培训”以及“需要哪些培训”上。个人分析的内容包括：员工实际工作绩效与该工作可接受绩效标准的差距及其原因（当前培训需求）；员工对每项技术的熟练程度与该项技术所需熟练程度的差距及其原因（将来的培训需求）。 分析手段可采用观察、记录分析、资料调查、技能考核等。此外，员工的自我评价也是收集个人需求信息的重要来源。 Goldstein三层次模型在培训需求分析中的运用存在以下几方面的不足： 1、模型虽然考虑了企业战略、组织资源对培训需求的影响，但是忽略了行业政策、国家政策等外部环境的影响。 2、模型对人员进行分析主要集中在员工绩效现状与理想水平的差距上，关注的是员工“必须学什么”以缩小差距，而没有重视“员工想学什么”。 3、模型很难找到具体可操作的分析方法，缺乏简单有效的识别工具。 二、培训需求差距分析模型 美国学者汤姆·W·戈特将“现实状态”与“理想状态”之间的“差距”称为缺口，并依此确定员工知识、技能和态度等培训内容，这就是培训需求差距分析模型。 培训需求差距分析模型有三个环节： 1、发现问题所在。理想绩效与实际绩效之间的差距就是问题，问题存在的地方，就是需要通过培训加以改善的地方。 2、进行预先分析。一般情况下，需要对问题进行预先分析和初步判断。
需求调研报告
实施技术文档 目录 1 客户基本情况调研 2 1.1 客户公司介绍 2 1.2 组织结构 2 1.3 权限关系 2 2 企业配置需求调研 3 2.1 角色相关配置 3 2.2 员工信息配置 4 2.3 业务配置 4 3 客户CRM业务需求调研 5 3.1 市场部分 5 3.1.1 线索管理 5 3.2 客户/联系人管理 5 3.2.1 客户管理 5 3.2.2 联系人管理 6 3.3 销售管理7 3.3.1 机会管理7 3.3.2 报价管理8 3.3.3 销售合同管理8 3.3.4 收款管理9 3.4 服务管理10 3.4.1 服务请求10 3.4.2 服务收费11 3.5 产品管理12 3.6 活动管理12 3.7 竞争管理12 3.8 知识库管理13 3.9 报表与分析13 文档签收错误！未定义书签。
1客户基本情况调研 1.1客户公司介绍 公司简介： 1.2组织结构 此处填写公司组织部门结构，如下图： 说明：组织结构图反应公司职能部门分布以及上下级关系。 组织结构图 1.3权限关系 此处添加公司各部门的职位上下级关系图，如下图： 说明：以管理层次图方式描述公司的上下级关系，此关系涉及到上级对下级数据的可视性。系统默认上级可以查看下级数据，平级之间数据互不可见。
职权图 2企业配置需求调研 说明：该部分主要调研CRM系统中的角色权限配置和员工的角色分配、数据共享信息和审核流程等 2.1角色相关配置 此处由Crm工程师根据企业需求来共同填写企业各使用帐户的权限分配。角色配置定义的是各角色的使用模块和操作权限。 角色配置表
2.2员工信息配置 此表描述的是客户使用CRM 系统的帐户信息，职权、部门和角色对应职权图、组织结构图和角色分配表。 员工信息表 2.3业务配置 编码规则 采用手动编码或自动编码 数据共享 1.销售的机会、报价、合同、应收款、客户信息等销售模块除总经理、副总经理、销售部和市场部外， 其他部门均无无权查看以上信息（销售共享或分配的信息除外） 2.售后支持组：商务部的客户资产管理需共享给技术支持部。 3.工程部经理可以看到实施项目模块的信息；财务经理可以看到销售中涉及金额的模块信息，包括： 合同、应收款、实施项目、服务收费模块；技术部经理能看到实施项目模块信息。 4.各销售人员能看到其他部门在系统中记录的关于自己负责项目的相应信息，而其他销售人员是不能 看到的。在销售人员未主动共享前其他部门是不能看到销售部人员的系统记录信息的。 5.销售人员的共享操作说明： a.当销售人员在销售过程中的某次销售需要售前技术支持的时候，需要销售人把对应的客户资 料共享给受理支持的技术人员。 b.工程部的所有实施项目需要共享的销售经理。 备注：所有共享信息都是针对某一个模块进行共享，而不能针对某模块中的某些字段进行共享。 审核流程 审核流程定义表
软件需求分析说明书
软件需求分析说明书集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
学生信息管理系统 需求分析说明书 1.引言 编写目的 确定学生信息管理系统功能的有效性需求；以供本系统的开发人员参考。 项目背景 开发软件名称：学生信息管理系统。 用户：教学办公室 项目和其他软件：系统的关系。 本项目采用客户机/服务器原理，客户端程序是建立在window NT系统上以 Java为开发软件的应用程序，服务器端采用Linux为操作系统的工作站，是采用Oracle 的为开发软件的数据库服务程序。 定义 学号：学校给学生的编号，用来区分各个学生的信息的中介。 课程名：学校开设课程的名字 Java+SQL：编写该系统的面向对象的开发语言和数据库语言。
参考资料 ⑴《Oracle从入门到精通》 ⑵《JAVA程序设计项目教程》 ⑶《数据库原理及应用》 ⑷《软件工程案例教程》 2．任务概述 目标 ⑴开发意图：由于学校的不断招生，现有的系统空间小，运行速度缓慢，操作过于复 杂，有的操作还不能执行，所以要开发本系统。 ⑵应用目标：学生信息管理系统将解决现有系统的空间不足，运行缓慢，操作复杂，操 作无效等问题。 运行环境 本系统采用C/S体系结构 操作系统：Microsoft Windows xp 支持环境：IIS 数据库：Oracle 软件设备：eclipse 内存：512 M以上 硬盘空间：40G以上 CPU: 233MHZ以上
内存：256M以上 硬盘空间：以上 假定与约束 使用本系统的用户群集中在 22-35 岁的年轻人，用来做学生信息的存储，对计算机的操作一般比较熟练。根据他们对本程序的认可、方便操作的程度，结合他们日常工作的频繁程度，系统每天操作完成一个功能点应该在 2- 10 次之间。用户对界面的友好性，有非常高的要求。本系统的规模比较小，并且将提供操作手册进行操作项的详细说明 （1）、Client/Server结构总体设计方案对它的约束：本系统做为Client/Server 结构的一个应用系统，不可避免的要受到Client/Server结构的约束。在其实施的各个阶段都要服从它的一些规划，包括功能设计、系统配置和计划。同时，由于信息的共享，机票预订系统还受到其它系统的信息约束。 （2）、人力、时间的约束：本系统开发过程中也要考虑到人力、资金和时间的约束。 （3）、技术发展规律的约束：计算机技术和产品的发展日新月异，将会给信息处理带来更多的手段，同时也会带来更加丰富的信息表达形式。例如图象和语音技术的进步，多媒体技术的发展，这些都要求系统在设计时考虑技术变化的可能性，为可能的变化预留一定的系统处理能力。 3．需求规定 对功能的规定 系统流程图：系统流程图是用户操作此系统的流程和各个用户能够操作的功能，如A-1就是一个系统流程图；用户有系统管理员，教师和学生，每个用户要进入此系统都要登录。每个用户有不同的功能，系统管理员有查询，增加，修改，删除，修改密码，设置权限等功能；教师有查询，修改密码和输入学生成绩的功能；学生只有查询和修改密码的功能。 A-1系统流程图 用例图：用例图是用来表示用户能使用的功能和权限。如图A-2表示系统管理员可以运用的功能，像修改密码，管理学生信息、成绩信息、课程信息、班级信息并且设置权
需求调研报告
水利厅档案管理系统 需求调研报告 版权所有不得复制 Copyright ? BroadenGate Technologies, Co., Ltd. All Rights Reserved
Revision Record 修订记录
Catalog 目录 1需求调研流程 (4) 1.1调研整体流程 (4) 1.2组成部分关系 (6) 1.3分析过程 (7) 2需求调研和分析的方法、策略和步骤 (7) 2.1如何调研 (8) 2.2如何分析 (8) 2.3调研方法 (9) 2.4基本策略 (9) 2.5结构化方法分析步骤 (10) 2.6UML方法分析步骤 (10) 3需求调研相关要求 (11) 3.1文档规范 (11) 3.2需求管理 (12) 3.3调研成果 (13)
1需求调研流程 1.1 调研整体流程
●问题识别：解决目标系统做什么，做到什么程度。需求包括：功能、性能、环境、 可靠性、安全性、保密性、用户界面、资源使用、成本、进度。同时建立需求调查 分析所需的通信途径。 ●分析与综合：从数据流和数据结构出发，逐步细化所有的软件功能，找出各元素之 间的联系、接口特性和设计上的限制，分析它们是否满足功能要求并剔除不合理部 分，综合成系统解决方案，给出目标系统的详细逻辑模型。[常用的分析方法有面 向数据流的结构化分析方法SA（数据流图DFD、数据词典DD、加工逻辑说明）、 描绘系统数据关系的实体关系图ERD、面向数据结构的Jackson方法JSD、面向对 象分析方法OOA（主要用UML）、对于有动态时序问题的软件可以用形式化技术， 包括有穷状态机FSM的状态迁移（转换）图STD、时序图、Petri网。每一种分析 建模方法都有其优势和局限性，可以兼而有之以不同角度分析，应该避免陷入在软 件需求方法和模型中发生教条的思维模式和派系斗争，一般来说结构化方法用于中 小规模软件、面向对象方法用于大型软件。] ●编制需求分析文档 ●需求评审 1.2 组成部分关系 需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段，包括以下几个方面：确定软件所期望的用户类；获取每个用户的需求；了解实际用户任务和目
研发需求分析报告模板
研发需求分析报告 注：括号内容为输出要求和建议。 原则：开发人员拿到此文档就可以开始工作，不用再次跟市场人员反复沟通确认。 一、产品描述 1、产品（项目）名称 （软、硬件须注明产品型号；产品型号符合命名规范） 2、实现方案描述 （详细、全面地对产品进行描述，让参与产品开发的人员都可以无歧义地知道产品的最终形态；硬件平台及核心模块的选型，如sensor等） （1）在XXXX基础上，集合XXXX，兼容XXXX，后续产品升级支持XXXX。 （2）输出接口：XXXX。 二、研发需求 （按优先级从高到低排列，硬件产品明确规格、性能，作为最终产品是否达到设计要求和质量等级的依据；注明符合国际标准或客户要求的环保标准。） 三、研发需求分析 （以部门为单位，用研发语言列出可行的需求，对和项目任务书不一致的部分作出解释）备注：软件UI需求分析设计专用如下 功能结构图 (---操作与跳转流程、结构、布局、信息和其他元素、详细的结构流程图文档---) 使用场景分析 (----使用人群、时间、地点---) 交互流程分析 (---交互流程---) 界面原型 （---提供界面草图---） 要点说明 (-------)
四、研发人力投入和分工 1、涉及部门： 网络实验室：负责网络穿透…… 设计部：负责UI和包材设计…… BU研发：…… ……：…… 2、预估工作量： A投入50人天。 B投入30人天。 五、预期价格成本 1、预期价格 （注明市场建议销售价格，说明是否含税等。） 2、硬件成本 （硬件BOM含税价格，包含包装，不包含人工费用） 3、运营成本（带宽、维护成本等） 六、开发周期及产品质量要求和预估 （对发布周期的要求；对产品质量等级的要求。） 期望： （1）明确TR点； （2）产品质量为A级。 七、产品风险及措施 （根据以往常见的风险或产品成功所需要的条件，有何种应对措施。）（1）需求是否明确； （2）实现方案选择；
培训需求调研分析报告
培训需求调研分析报告集团文件版本号：（M928-T898-M248-WU2669-I2896-DQ586-M1988）
培训需求调研分析 一、本期培训需求调研的主要目的 掌握承包公司管理干部对培训的实际需求； 找到培训工作的主要矛盾，并准备相应的解决办法； 规划下一阶段培训主导方向、时间安排及培训方式。 二、本期培训需求调研统计情况 本次培训调研主要以公司全员为主，根据2月26日培训调研资料收集显示，参与人数合计50人。 1、影响培训效果的因素,如下图： 分析： 影响培训效果因素的前三项： 1)时间安排不合适（66%）。 2)形式太单调（62%）； 3)员工培训意识未跟上（50%）； 现有培训主要以周末时间为主，且培训时间过长，员工意识薄弱，从个人的工作压力和劳动强度考虑，是存在一定的负面情绪。公司内部高层管理人员面对面授课为主，授课方向与培训内容选定存在差距，现根据新的培训调研将在内容、形式、时间控制方面尽量做到最好。培训工作初步开展，未引起员工的重视程度，意识上跟不上。因此影响培训效果，建议后期逐步考虑，结合实际情况改进培训时间的安排。 （二）公司的培训重点 1、公司员工培训需求重点培训方向是，如下图：
分析： 公司员工培训需求培训方向排序; 1)团队建设（74%）； 2)管理技能（68%）； 3)职场人际关系（56%）； 4)执行力（54%）； 5)企业管理（40%）； 6)压力管理（32%）； 7)企业制度（20%）。 从分级看 从调查前三项来看，管理干部在管理过程中发现现员工对个人职业规划很模糊，现员工急需的培训的方向是团队协作、执行力、职场人际关系等。 从调查前三项来看，管理干部现在急需的培训是团队建设、人员管理技能和职场人际关系的处理等。根据此次调研制定新的培训计划，并实施。2、员工个人感觉在工作中存在困惑，需要培训相结合 分析： 1）工作压力大，有时或经常因工作原因情绪低落（46%） 2）工作任务个人感觉多，总是感觉忙不过来（44%）； 3）个人感觉工作已经努力，但目标仍无法完成，或领导有时感到不满意（38%）； 4）日常活动中，个人的有些行为不知是否恰当，是否合乎礼仪要求（36%）；
研究生科研信息管理系统需求分析
研究生科研信息管理系统需求分析 研究生科研信息管理系统功能要求 研究生科研信息管理系统的总目标是：在计算机网络，数据库和先进的开发平台上，利用现有的软件，配置一定的硬件，开发一个具有开放体系结构的、易扩充的、易维护的、具有良好人机交互界面的研究生科研信息管理系统，实现为导师和研究生提供充分的管理信息和快捷的查询。根据可行性研究的结果和客户的要求，分析现有情况及问题。 管理员 1．客户端系统： 在客户端系统的功能实现上，可以分为以下几个部分： [1]科研信息文件的输入和统计
管理员把科研相关信息输入。这部分功能是客户端子系统的基本部分，这个功能是以后各个部分的基础。系统要求做到即能够从其它子系统中共享一部分信息，又有方便的操作界面手工输入旅客信息。这部分要求对输入的数据进行简单的统计，供研究生以及导师进行查询。 [2]在客户端系统的功能实现上，可以分为以下几个部分： 1、该题目主要以高校应该为导师和研究生提供充分的管理信息和快捷的查询，如对导师信息、研究生信息、科研项目、论文、学术交流、专利申请、培养经费支出管理等研究生综合信息进行管理业务为背景，通过调研、分析现有的管理模式和已有的管理软件，建立系统模型；完成软件结构设计和数据库设计；完成软件开发，撰写设计说明书； 2、“研究生科研信息管理系统”主要包括研究生基本信息、导师信息、论文信息、项目信息、学术交流、专利信息、培养经费支出、统计分析等模块； 3、利用“抽象”设计原理，对系统设计并实现满足多种条件的统计分析功能，有些统计数据要采用图表（直方图、圆饼图、折线图、表格等）的格式呈现； 4、系统开发可采用C#.net技术或JSP技术和数据库（数据库可选MySQL或MS SQL Server 或 Oracle）； 5、系统所涉及的信息有： ●导师信息：教工编号、姓名、身份证号、年龄、性别、职称、导师类型(0-硕士生导师，1-博士生导师)、拟招专业、主要研究方向、科研项目、发表论文情况、办公地址、联系电话、E-mail、QQ号、在研学生人数等； ●研究生信息：学号、姓名、导师名、身份证、年龄、性别、政治面貌、学生类别(0-硕士，1-博士)、专业、家庭地址、宿舍住址、发表论文、参加科研项目、联系电话、E-mail、QQ号、备注等； ●科研项目信息：项目编号、项目名称、项目负责人、项目来源、本人排名、项目类型、项目等级、所在单位、项目总经费、承担的主要任务； ●学术论文信息：论文编号、论文名称、第一作者、第二作者、作者所在部门、是否编入教材、备注、刊物名称、卷号、页码范围、日期、期号、是否基金资助、资助金额、检索类型(SCI/EI/ISTP/CSCD)、检索编号等； ●教材专著信息：教材编号、论著名称、主编姓名、所在部门、出版社、出版时间、总字数、编写字数、发行版本、是否基金资助、资助金额、发行册数等； ●用户信息：用户名、用户密码、用户权限、邮箱； ●专业信息：专业编号、专业名称； ●培养方案：课程类别、序号、课程编号、课程名称、学时、学分、开课学期、考核方式、开课学院； ●研究生支出台账信息：学号、学生姓名、导师姓名、培养经费总额、支出时间、支出金额、余额。 ●专利信息：专利名称、专利所属学院、专利类型(0-发明专利，1-实用新型，2-外观
需求分析规格说明书
软件需求说明书 软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下： 1 引言 1．1编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 1．2背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1．3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1．4参考资料 列出用得着的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 任务概述 2．1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各
部分的联系和接口。 2．2用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束2．3假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 3 需求规定 3．1对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。 3．2对性能的规定 3．2．1精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。 3．2．2时间特性要求 说明对于该软件的时间特性要求，如对： a．响应时间； b．更新处理时间； c．数据的转换和传送时间； d．解题时间；等的要求。 3．2．3灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a．操作方式上的变化； b．运行环境的变化； c．同其他软件的接口的变化； d．精度和有效时限的变化； e．计划的变化或改进。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
第三章 需求分析习题及答案
第三章需求分析 一. 填空题 1.需求分析的步骤, , , 。 2.需求分析阶段需编写的文档有，，。 3.系统规格说明，数据要求，， ,这四份文档资料是在书写文档阶段必需完成的。 4.在书写文档阶段，数据要求主要包括通过需求分析建立起来的，以及描绘数据结构的层次方框图。 5.对于计算机程序处理的数据，其数据域应包括, , 和数据结构。 6.数据内容即是。 7.把一个功能分解成几个子功能，并确定, 就属于横向分解。 8.软件需求的逻辑视图给出, 而不是实现的细节。 9. 功能一般用, 来表示。 10.结构化分析方法是, 进行需求分析的方法. 11.描述结构化分析方法的工具有，，，判定表，判定树。 12. SA方法中自顶向下的分析策略主要是和。 13.数据流图的基本组成部分有，，，。 14.数据流图的特性，，，。 15.数据流图和数据字典共同构成了系统的模型，是需求规格说明书的主要组成部分。 16.分析员通过需求分析，逐步细化对软件的需求，描述软件主要处理的，并给软件开发提供一种可转化为，和的数据与功能表示。 17．需求分析阶段研究的对象是软件项目的。 18．数据流图的基本符号包括，，，。19．在需求分析阶段常用的图形工具有，，。20．需求分析应交付的主要文档是。 二. 选择题 1. 需求分析中开发人员要从用户那里了解（） A．软件做什么B．用户使用界面C．输入的信息D．软件的规模 2. 需求分析阶段的任务是确定（） A．软件开发方法 B．软件开发工具C．软件开发费 D．软件系统的功能 3. 需求分析阶段最重要的技术文档之一是非曲直（）。 A．项目开发计划 B．设计说明书 C．需求规格说明书 D．可行性分析报告
需求调研的方法
需求调研方法及实战 概述 需求调研和需要分析，可以说是软件工程中极为重要的一环。据统计，失败的项目中有70%以上都是由需求引起的，例如：需求不完整、需求变更等等。在这方面是有着血和泪的教训的。 那么如何才能做好需求？其原则也很简单，就是从外到内、从粗到细、从浅到深。具体的说，就是从公司级、部门级、操作级三个层次进行需求调研和需求分析。 需求开发的具体流程如下： 1.根据合同确定项目目标和范围 2.确定系统干系人 3.选择用户代表 4.熟悉业务领域，建立词汇表 5.做好访谈计划、访谈问题大纲 6.获取每类用户的需求 7.分析用户工作流程 8.确定用例 9.建立领域模型 10.确定非功能需求 11.确定设计约束 12.划分需求优先级 13.编写需求规格说明书 下面将举例说明需求调研的三个层次（本文中的例子取材于笔者亲身参与的一个项目）。公司级 在对客户的业务知识、项目背景有一定的了解后，开始访谈客户公司的高层领导，了解他们对项目的期望、目标（要符合SMART的原则）、及该项目的投资回报率。这些信息可用于对需求的把握和对需求优先级的排序。 在这个阶段中，还需要将业务分解成大的业务模块，定义每个业务模块之间的接口。这样的好处是可以将一个大的系统分解为多个小的系统，降低系统的复杂度。例如：
部门级 在这个阶段中，将上个阶段分解的业务模块落实到具体的业务部门中，访谈该部门经理。获取该部门的业务流程。流程建模的方法如下： 1.找出业务事件 2.识别一个业务事件的相关业务活动 3.确定业务活动之间的关系 4.业务活动的输入、输出信息 5.负责业务活动的部门、岗位 流程建模后，将流程中的每个节点进行分析，判断其是否在系统的范围内。如在系统范围内，将其定义为用例。同时了解部门经理的管理需求，找到业务流程的管控点，生成报表。下面是一个流程建模的实例：