需求工程的资料.docxVIP

4个上下文刻面：主体、使用、IT系统、开发3类需求制品：目标、场景、面向方案的需求3个核心活动：获取、文档化、分析2个横切活动：确认、管理软件工程（Software Engineering）：对于软件开发、操作以及维护的系统化、规范化和可量化的应用方法。需求工程（requirement engineering）：是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应，需求工程是软件工程关于现实世界的目标、功能和软件系统约束的一个分支，它也关注着上述因素之间的关系来精确软件行为的规格说明和它们随时间随产品族的演化。需求（Requirements）：⑴用户解决某个问题或者达到某个目标所需要的条件或能力；⑵一个系统或系统组件为了实现某个契约、标准、规格说明（规约）或其他需要遵循的文件而必须满足的条件或拥有的能力；⑶对⑴或⑵中所描述的条件或能力的文档化表示。需求制品（requirement artifacts）：需求制品是文档化的需求。需求类型（requirement types）：⑴domain, application⑵system, software, user⑶function, quality(nonfunctional, performance), constraints⑷目标需求、商业需求用户需求（User requirement）：用户或其他涉众期望系统实现的目标或功能。系统需求（System Requirement）：系统作为一个整体所实现的需求。功能性需求（Functional Requirement）：是关于系统应提供的服务、系统针对特定输入如何响应，以及系统在特定情况下的行为的陈述。在某些情况下，功能性需求还会陈述系统不应做什么。非功能性需求（Non-Functional Requirements）：是一个不明确的功能性需求或者是一个质量需求。质量需求（Quality Requirement）：定义了一个整个系统或一个系统组件、服务或功能的质量特性。质量属性（quality attributes）：系统完成工作的质量，如可靠性等。约束（Constraints）：一种限制了系统开发方式的组织或技术要求。涉众（stakeholder）：涉众是与待开发系统有利益关系的人员或组织。涉众对于系统通常有着他们自己的需求。一个人可以代表不同涉众（人和/或组织）的利益，即一个涉众可以有多个角色并代表多个涉众。上下文（Context）：是系统所处的环境中与定义、理解和解释系统需求相关的那些部分。上下文刻面（Context Facets）：系统上下文被结构化为在需求工程阶段针对软件密集型系统需要考虑的4个上下文刻面，包括主体刻面、使用刻面、IT系统刻面以及开发刻面。上下文方面（Context Aspects）：是系统上下文中的各种物质和非物质的对象，如人、技术与非技术性系统、过程、物理规律等。系统边界（System Boundary）：将待开发系统和系统上下文分割开来。系统边界将属于系统之内、在开发过程中可以被改变的那些部分和那些在开发过程中不可改变、属于系统上下文的部分分隔开。上下文边界（Context Boundary）：上下文边界将系统环境划分为相关部分和无关部分。换言之，它将系统上下文和那些在系统开发中无需考虑的无关环境区分开。目标（Goal）：目标是系统的目的、属性或者使用的意图。软目标（soft goal）：在i*中，软目标是参与者希望达成的现实世界中的某种条件。在KAOS中，软目标用来描述在多个可替换的系统行为之间的偏好。场景（Scenario）：场景描述了一个目标（或者一组目标）被满足或者未被满足的一个实例。面向方案的需求（Solution-oriented requirement）：定义了一个软件密集型系统上的数据视图、功能视图和行为试图。此外，面向方案的需求还包括（面向方案的）质量需求以及（面向方案的）约束。项目前景（Project vision）：描述产品是什么，它可能最终成为什么。特征（features）：按照系统的特征来组织需求，这些特征在不同的系统接口上表现为可见的服务形式。项目范围（Project scope）：确定当前项目对于某些长期的项目前景的定位。可行性分析（Feasibility Analysis）：现行的组织系统、现存系统的问题、新系统的目标和需求、需要哪些改变、约束、可能的替换、替换的优缺点。原型（Prototype）：原型是一个软件系统的初始版本，用于演示概念，尝试设计方案，通常用于找到更多的问题及其可能的解决方案。领域模型（domain model）：对领域内的概念类或现实世界中对象的可视化表示。数据字典（Dat