《需求工程复习资料》由会员分享，可在线阅读，更多相关《需求工程复习资料（7页珍藏版）》请在金锄头文库上搜索。
1、14 个上下文刻面：主体、使用、IT 系统、开发3 类需求制品：目标、场景、面向方案的需求3 个核心活动：获取、文档化、分析2 个横切活动：确认、管理软件工程（Software Engineering）：对于软件开发、操作以及维护的系统化、规范化和可量化的应用方法。需求工程（requirement engineering）：是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应，需求工程是软件工程关于现实世界的目标、功能和软件系统约束的一个分支，它也关注着上述因素之间的关系来精确软件行为的规格说明和它们随时间随产品族的演
2、化。需求（Requirements ）：用户解决某个问题或者达到某个目标所需要的条件或能力；一个系统或系统组件为了实现某个契约、标准、规格说明（规约）或其他需要遵循的文件而必须满足的条件或拥有的能力；对或中所描述的条件或能力的文档化表示。需求制品（requirement artifacts）：需求制品是文档化的需求。需求类型（requirement types）：domain, applicationsystem, software, userfunction, quality(nonfunctional, performance), constraints目标需求、商业需求用户需求（User
3、 requirement）：用户或其他涉众期望系统实现的目标或功能。系统需求（System Requirement）：系统作为一个整体所实现的需求。功能性需求（Functional Requirement）：是关于系统应提供的服务、系统针对特定输入如何响应，以及系统在特定情况下的行为的陈述。在某些情况下，功能性需求还会陈述系统不应做什么。非功能性需求（Non-Functional Requirements ）：是一个不明确的功能性需求或者是一个质量需求。质量需求（Quality Requirement）：定义了一个整个系统或一个系统组件、服务或功能的质量特性。质量属性（quality attr
4、ibutes）：系统完成工作的质量，如可靠性等。约束（Constraints ）：一种限制了系统开发方式的组织或技术要求。涉众（stakeholder）：涉众是与待开发系统有利益关系的人员或组织。涉众对于系统通常有着他们自己的需求。一个人可以代表不同涉众（人和/或组织）的利益，即一个涉众可以有多个角色并代表多个涉众。上下文（Context ）：是系统所处的环境中与定义、理解和解释系统需求相关的那些部分。上下文刻面（Context Facets）：系统上下文被结构化为在需求工程阶段针对软件密集型系统需要考虑的 4 个上下文刻面，包括主体刻面、使用刻面、IT 系统刻面以及开发刻面。上下文方面（Co
5、ntext Aspects）：是系统上下文中的各种物质和非物质的对象，如人、技术与非技术性系统、过程、物理规律等。2系统边界（System Boundary）：将待开发系统和系统上下文分割开来。系统边界将属于系统之内、在开发过程中可以被改变的那些部分和那些在开发过程中不可改变、属于系统上下文的部分分隔开。上下文边界（Context Boundary）：上下文边界将系统环境划分为相关部分和无关部分。换言之，它将系统上下文和那些在系统开发中无需考虑的无关环境区分开。目标（Goal）：目标是系统的目的、属性或者使用的意图。软目标（soft goal）：在 i*中，软目标是参与者希望达成的现实世界中的
6、某种条件。在KAOS 中，软目标用来描述在多个可替换的系统行为之间的偏好。场景（Scenario）：场景描述了一个目标（或者一组目标）被满足或者未被满足的一个实例。面向方案的需求（Solution-oriented requirement）：定义了一个软件密集型系统上的数据视图、功能视图和行为试图。此外，面向方案的需求还包括（面向方案的）质量需求以及（面向方案的）约束。项目前景（Project vision）： 描述产品是什么，它可能最终成为什么。特征（features）：按照系统的特征来组织需求，这些特征在不同的系统接口上表现为可见的服务形式。项目范围（Project scope）： 确定当
7、前项目对于某些长期的项目前景的定位。可行性分析（Feasibility Analysis）：现行的组织系统、现存系统的问题、新系统的目标和需求、需要哪些改变、约束、可能的替换、替换的优缺点。原型（Prototype）：原型是一个软件系统的初始版本，用于演示概念，尝试设计方案，通常用于找到更多的问题及其可能的解决方案。领域模型（domain model）：对领域内的概念类或现实世界中对象的可视化表示。数据字典（Data Dictionary）：数据字典(Data Dictionary)作为描述工具,对于 DFD 中出现的所有被命名的图形元素(数据流、数据项、数据存储、加工) 在 DD 中作为一个
8、词条加以定义,使得每一个图形元素的名字都有一个确切的解释。用例模型（Use case model）：从用户的角度获取功能需求，用用例模型表示。用例（Use case）：对于一个系统、子系统或者类可以与外部对象交互执行并提供某种有价值的服务的动作序列的规约，包括变体序列和错误序列。需求规格说明（Requirement specification）：是一个包含特定需求的文档，即符合已定义的规约规则和指南的需求。是在需求分析过程中系统地组织系统需求，并正确地为这些需求建立需求文档过程，需求规格说明树清晰且准确的描述软件系统的每条必需的需求以及外部接口，包括软件功能、性能、设计约束和质量属性。四变量模
9、型（Four Variable Model）：监视变量：表示将会影响系统行为的，能衡量的环境属性控制变量：系统将能够控制的环境属性输入数据项：输入设备（比如：感应器）度量被检测的属性，输入设备读取的变量被称为输入数据项输出数据项：输出设备设置被控制硬件属性，输出设备写入的变量被称为输出数据项需求验证（Requirement verification）：确定正在正确的建立产品，软件应当符合用例规格说明书，也就意味着研发的每一步都应遵循过程和标准，质量是需求验证的目标。需求确认（Requirement validation）：确认是指检查需求工程核心活动的输入、执行的活动后所创建的输出（需求制品）
10、是否符合所定义的质量准则。确认的执行需要将相关涉众、其他需求来源（标准、法律等纳入进来） ，如有必要还需将外部评审者纳入进来。3需求配置（Requirement configuration）：配置基本版本，用于管理需求制品的不断演化，配置相关的各种需求不同版本的组合。需求基准（线） （Requirement baseline）：需求制品的基线是一个被选择的需求制品配置。术语“需求基线”是指一个稳定的需求制品版本的配置。通常，在一个特定的系统发布版本中实现需求基线。需求状态（Requirement status）：状态也就是一种事物或实体在某一时刻或点所处的情况，此处要讲的需求状态是指用户需求的
11、一种变换过程。 （8 个状态值：已批准、已建议、已设计、已实现、已验证、已提交、已删除、已拒绝）需求追踪（Requirement traceability）：需求的可追踪是指在前向与后向两方面描述并密切注意一个需求的生命能力。愿景（Vision）：系统愿景描述了对当前现实情况的一种大规模的所期望的改变。1、质量需求包含哪些类别？非功能性需求、性能需求。用户关心的：可用性、效率、灵活性、完整性、互操作性、可靠性、健壮性、易用性开发者关心的：可维护性、可移植性、可复用性、可测试性2、优良的需求定义应具备哪些特性？精确性、完整性、一致性。3、优良的需求文档应具备哪些特征？完整、可追踪、正确、明确、可
12、理解、一致性、可验证、评级、更新、原子的4、系统上下文包含的四个刻面有哪些？主体：包含了系统上下文中与系统相关的对象与事件；使用：包含了与人或其他系统对本系统的使用相关的所有方面；IT 系统：由系统部署环境中的操作环境和技术环境的所有方面组成，还涉及 IT 策略与规则；开发：包含了与系统开发过程相关的上下文方面，包括准则与约束、开发工具、质量保障方法等。5、需求工程包含哪些核心活动？抽取：抽取活动的目标是要改进对需求的理解，即在内容维度上取得进展；文档化：是根据所定义的文档和规约规范，将所抽取的需求进行文档化和规约描述；分析：必须满足不同涉众的要求和期望，不同涉众观点之间的冲突都必须识别并且明
13、确表示出来，应当尽量解决所有的冲突。6、需求制品有哪些？目标：场景：面向方案的需求：7、什么是 AND 目标父目标 G 到一组子目标 G1，G 2，G n（n2）的分解是一个 AND 分解，当且仅当为满足父目标 G 所有的子目标 G1，G 2，G n 都必须满足。8、什么是 OR 目标父目标 G 到一组子目标 G1，G 2，G n（n2）的分解是一个 OR 分解，当且仅当G1，G 2，G n 中任意一个子目标得到满足就能使父目标 G 得到满足。9、i*4i*框架是一种全面的、用于目标和目标依赖分析及描述的方法。i* 的基本思想是：一个参与者（actor）依赖于其他参与者来实现自己的目标。10、
14、KAOS一个 KAOS 模型包含 6 个互补的视图或子模型：目标模型、障碍模型、对象模型、主体模型、操作模型和行为模型。所有这些子模型通过追踪关系连接相互关联。11、场景的类别当前状态场景和期望状态场景：正面场景和负面场景：不当使用场景：描述性场景、探索性场景和解释性场景：实例场景和类型化场景：系统内部场景、交互场景和上下文场景：主场景、可替换场景和例外场景12、刻画场景的方法有哪些？叙述性场景：即用自然语言进行场景描述针对场景结构化描述的参考模板针对用例的结构化描述的参考模板11 条规则利用 UML 顺序图描述场景的交互序列利用 UML 活动图描述场景和用例的控制流利用用例图描述用例之间以及
15、用例与参与者之间的关系13、解决方案需求包含哪三方面的内容？数据视图：关注于定义需要由软件密集型系统管理的数据/信息；功能视图：定义了系统需要提供的处理过程（功能） 、每一个处理过程中对于数据的操纵、处理过程之间的输入输出关系（信息流） ；行为视图：关注于定义系统的总体行为。14、Mealy 有限自动机工作原理Mealy 自动机，自动机的输出依赖于当前状态和输入符号，即输出函数将当前状态和一个输入符号作为自变量。15、Moore 有限自动机工作原理Moore 自动机的输出只依赖于当前的状态。16、可能的需求来源有哪些？涉众（定义参考上面）现有文档：包含定义系统需求所需的大量信息。相关文档包括通
16、用文件（如法律、标准） 、特定组织文件（如开发指南、组织内的通用指南）或描述同类开发制品或原有系统的文档（如用户手册、系统体系结构文档、需求规格说明、测试文档等） 。现有系统：遗留系统和原有系统、竞争对手的系统、类似系统17、需求冲突(conflicts)是否可避免？不能过程是指活动、任务、目标和主要想法1、需求工程过程（Requirement engineering process）：5主要目标是在上下文中建立愿景，在内容、共识和文档化三个维度上取得进展。包括 5 项活动：需求获取是指从人、文档或者环境中获取需求信息；需求分析主要工作是通过建模整合各种信息，使人们更好地理解问题；需求规格说明将上一阶段的结果形成文档。需求验证为了保证 SRS 的正确性，需要相关人员对其进行严格地验证；需求管理在开发活动结束之后，还需要一种力量保证需求作用的持续、稳定和有效的发挥，需求管理就是这样的一个管理活动。2、需求工程的重要性：对于项目成功的影响不充分的需求工程导致需求中的缺陷需求缺陷导致
