需求工程部分考试知识点

1. 常见的IEEE1998，将需求分为5类：功能需求、性能需求、质量需求、对外接口和约束。
2. 优秀需求的特征：完整性、正确性、精确性（确定性）、可行性、必要性、无歧义、可验证、一致性、可追踪。
3. SRS（Software Requirements Specification）是软件需求规格说明书
4. 高质量的SRS需要满足：完整性、一致性、可追踪行、可修改性。
5. 涉众：与待开发系统有利益关系的人员或组织。其本身并不一定与系统开发有直接利益关系。
6. 需求获取信息的来源可能有哪些：涉众、硬数据、相关产品（现有系统等）、重要文档、相关技术标准和技术法规。
7. 需求获取的方法：面向目标（面向对象）、基于场景、面向方面、面向视点、基于知识。
8. 三类与需求获取相关的现有系统：遗留系统和原有系统、竞争对手的系统、以及类似系统。
9. 需求获取的常用方法：传统方法、集体获取方法、原型、模型驱动方法、认知方法、基于上下文的方法。
10. 文档审查的三种方法：需求重用、文档分析、需求剥离。
11. 数据流图（DFD）的基本元素：外部实体、过程、数据流和数据存储。
12. 涉众分析包含的活动：涉众识别、涉众描述、涉众评估、涉众选择。
13. 需求工程原型方法步骤：确定原型需求、原型开发、原型评估、原型修正。
14. 需求工程的方法分四类：面向对象、面向数据、面向控制、面向工程。
15. 常见的需求定义错误：没有反应用户真实需求、模糊和歧义的需求、信息遗漏、不必要的需求、不切实际的期望。
16. 微规格说明是一些被用来描述过程处理的技术，主要有三种技术：结构化英语、行为图、决策树。
17. 用例模型的四种基本元素：用例、参与者、关系、系统边界。
18. 面谈中相关问题的组织结构：金字塔结构、漏斗结构、菱形结构。
19. 数据流图（DFD）层次结构建立步骤：创建上下文图、发现并建立DFD片段、根据DFD片段组合产生层图、产生N层数据流图。
20. 需求跟踪的实现方法有：矩阵、实体联系模型和交叉引用。
21. 通用的跟踪模型有：在系统定义领域跟踪需求、在实现领域跟踪需求、在测试领域跟踪需求。
22. 软件需求包括不同层次分别是：业务需求、用户需求、功能需求、非功能需求。
23. 功能需求三个体现层次：业务需求、用户需求、系统需求。
24. 面向对象建模中用到的技术包括：对象模型、用例模型、行为模型、状态机模型和对象约束语言。
25. 需求规格说明活动就是将需求和软件解决方案进行定义和文档化，并传递给开发人员的需求工程活动。
26. 业务需求、高层解决方案、系统边界都因该定义到项目前景与范围文档。
27. 系统愿景通常定义了系统的高层目标。
28. 功能需求说明了系统向用户提供的功能。质量需求定义了待开发的质量属性，即系统的性能、可靠性、稳定性等。约束是对开发或待开发系统属性的限制。
29. 系统分析包括在对一个现有系统或过程进行分析的基础上定义一个新系统（发布版本）需求的各种不同方法。
30. 通常，新的系统实现了对现有系统和过程的自动化，并因此取代现有系统和过程。
31. 传统的系统按照功能、数据和行为来定义一个系统所期望实现的功能方面。
32. 结构化分析使用数据流图来描述系统功能以及每个功能的输入输出。
33. 结构化分析方法一般会区分物理模型和逻辑模型。首先开发出一个物理的当前状态模型，然后去掉其中的物理特性后就得到了当前状态的模型。为了定义系统需求，需要将所期望的变更集成到逻辑状态模型中，从而定义出逻辑的期望状态模型。结构化分析方法没有为逻辑模型的导出提供方法指导，本质系统分析方法很好地填补了这个缺失。
34. 需求制品来指代一个被文档化的需求，因此一个需求制品使用特定的文档格式来刻画一个需求。
35. 用况聚集了同一个目标相关联的多个场景。用况将一个主场景与相应的可替换场景和例外场景组织在一起，它包括上下文信息、主场景、可替换场景、例外场景。
36. 活动图侧重于描述在多个场景（例如属于同一用况的场景）之间的控制流，及不同参与者的活动以及这些活动的可能顺序，它是一种控制流图。
37. 用例图不适合用来描述系统参与者的交互（序列）。但特别适合用于系统中不同用况以及用况之间的可视化描述。
38. 需求开发的一般过程分为需求获取、需求建模、需求规格说明、需求验证4个阶段。
39. 评审类型：评审、走查、审查。
40. 需求变更的原因：对需求理解存在分岐、系统实施时间过长、用户业务需求变更、正常升级。
41. 软件需求的目标是充分、清晰、无歧义的表达。
42. 功能模型的构成要素主要有处理、数据流、动作对象、数据存储四个方面。
43. 统一建模语言（UML）是一种面向对象的建模语言，它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。主要应用与基于对象的面向对象方法。
44. 鱼骨图（又名因果图、石川图、Ishikawa），指的是一种发现问题“根本原因”的分析方法。可以用来挖掘出问题背后的问题。分为整理问题型鱼骨图、原因型鱼骨图、对策型鱼骨图。其特点是简捷实用，深入直观。它看上去有些像鱼骨，问题或缺陷（即后果）标在“鱼头”外。在鱼骨上长出鱼刺，上面按出现机会多寡列出产生问题的可能原因，有助于说明各个原因之间是如何相互影响的。
45. 需求管理体系包括：需求人员管理、需求工具管理、需求文档管理、需求变更管理。
46. 主要的软件过程模型：瀑布模型、演化模型（原型模型、增量模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。
47. 评价场景应该使用：正确性、完整性、简单性、适应性、集成性、理解性、实现性准则。
48. 数据流图有变换型和事务性两种类型。
49. 软件设计的原则：抽象与逐步求精、模块化、信息隐藏等。
50. 软件生命周期包括需求、设计、编码、单元测试、验收测试、维护六个阶段。
51. 软件的六个质量标准：功能性、可靠性、可用性、有效性、可维护性、可移植性。
52. 软件工程三要素：方法、工具、过程。
53. 主要的软件开发方法有：结构化开发方法、原型化开发方法、面向对象开发方法。
54. 需求分析的步骤：调查研究、分析与综合、书写文档、需求分析评审。
55. 需求分析阶段需要编写的文档：软件需求规格说明书（SRS）、初步用户使用手册、确认测试计划。
56. 统一软件开发过程（RUP）：核心工作流：分为6个核心过程工作流：商业建模、需求、分析和设计、实现、测试、部署。3个核心支持工作流：配置和变更管理、项目管理、环境。四个阶段：初始阶段、细化阶段、构造阶段、交付阶段。十大要素：开发一个前景、达成计划、标识和减小风险、分配和跟踪任务、检查商业理由、设计组件构架、构建和测试、验证和评价结果、管理和控制变化、提供用户支持。六大经验：迭代式开发、管理需求、使用基于构件的体系架构、软件的可视化建模、验证软件质量、控制软件变更。
57. 需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
58. 需求配置管理的好处：1、避免需求在未授权的情况下变更，或在有潜在破坏性的情况下不受限制的随意变更；2、保护对需求文档的修正；3、方便对文档以前版本的检索或重建；4、支持系统以增量的方式改进基线；5、避免对文档的同时更新和冲突。
59. 实体-联系图(ERD)的基本构建有：基本要素（数据对象（实体）、属性、关系）和各种类型指示符。ERD提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。
60. gantt图（甘特图、横道图）它是以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。其内在思想简单，基本是一条线条图，横轴表示时间，纵轴表示活动(项目)，线条表示在整个期间上 计划和实际的活动完成情况。它直观地表明任务 计划在什么时候进行，及实际进展与计划要求的对比。由于 甘特图形象简单，在简单、短期的项目中， 甘特图都得到了最广泛的运用。
61. 需求过程应建立3种模型：数据模型、功能模型、行为模型。数据流图（DFD）属于功能模型，实体-联系图（ERD）属于数据模型，状态转移图（STD）属于行为模型。
62. 面谈的类别：结构化面谈、半结构化面谈、非结构化面谈。
63. CRC (Class,Responsibility,and Collaboration)类，责任和交互，简称CRC卡片。 在面向对象程序设计中，用来阐述类、类的行为和类的责任的一个非常好的途径。
64. 原型的种类：探索式、实验式、演化式。探索式和实验式又称作抛弃型原型。这两种方法产生的原型往往是经历了很多次错误的尝试之后才产生的。这些错误的尝试过程会在最终的原型产品当中留下痕迹，它们会使原型产品的质量很差。不能因为抛弃型原型花费了成本和人力就将它整合到最终的产品中，这样是得不偿失的。因为抛弃型原型是要被最终丢弃的，所以在构建时应该以最小的代价，争取最快的速度。为此，开发者可能会使用一些简易的开发工具和不成熟的构造技术，也可能忽略或简化一些和原型目标不相关的功能特征。与抛弃型原型相反，演化式原型要求原型产品作为资产沿着开发过程向后传递，并可能被后继过程修改和增强，最后成功系统或产品的一个部分，因此演化模型必须具有健壮性，需要采用好的体系架构和设计原则，利用成熟的技术和熟练的工具构建。
65. 原型构建技术：水平构建原型（水平型原型）、垂直构建原型（垂直型原型）。 水平构建原型法：该方法仅仅实现选定功能所有层次中的某些特定层次，例如用户界面层，他能够处理较大范围的功能，建立的原型产品成为水平原型。垂直原型法：该方法会触及选定功能实现的所有层次，处理的功能范围较小，建立的原型产品成为垂直原型。