需求工程复习资料(共7页).docx

精选优质文档-倾情为你奉上4个上下文刻面：主体、使用、IT系统、开发3类需求制品：目标、场景、面向方案的需求3个核心活动：获取、文档化、分析2个横切活动：确认、管理软件工程（Software Engineering）：对于软件开发、操作以及维护的系统化、规范化和可量化的应用方法。需求工程（requirement engineering）：是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应，需求工程是软件工程关于现实世界的目标、功能和软件系统约束的一个分支，它也关注着上述因素之间的关系来精确软件行为的规格说明和它们随时间随产品族的演化。需求（Requirements）：用户解决某个问题或者达到某个目标所需要的条件或能力；一个系统或系统组件为了实现某个契约、标准、规格说明（规约）或其他需要遵循的文件而必须满足的条件或拥有的能力；对或中所描述的条件或能力的文档化表示。需求制品（requirement artifacts）：需求制品是文档化的需求。需求类型（requirement types）：domain, applicationsystem, software, userfunction, 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）：对领域内的概念类或现实世界中对象的可视化表示。数据字典（Data Dictionary）：数据字典(Data Dictionary)作为描述工具,对于DFD中出现的所有被命名的图形元素(数据流、数据项、数据存储、加工)在DD中作为一个词条加以定义,使得每一个图形元素的名字都有一个确切的解释。用例模型（Use case model）：从用户的角度获取功能需求，用用例模型表示。用例（Use case）：对于一个系统、子系统或者类可以与外部对象交互执行并提供某种有价值的服务的动作序列的规约，包括变体序列和错误序列。需求规格说明（Requirement specification）：是一个包含特定需求的文档，即符合已定义的规约规则和指南的需求。是在需求分析过程中系统地组织系统需求，并正确地为这些需求建立需求文档过程，需求规格说明树清晰且准确的描述软件系统的每条必需的需求以及外部接口，包括软件功能、性能、设计约束和质量属性。四变量模型（Four Variable Model）：监视变量：表示将会影响系统行为的，能衡量的环境属性控制变量：系统将能够控制的环境属性输入数据项：输入设备（比如：感应器）度量被检测的属性，输入设备读取的变量被称为输入数据项输出数据项：输出设备设置被控制硬件属性，输出设备写入的变量被称为输出数据项需求验证（Requirement verification）：确定正在正确的建立产品，软件应当符合用例规格说明书，也就意味着研发的每一步都应遵循过程和标准，质量是需求验证的目标。需求确认（Requirement validation）：确认是指检查需求工程核心活动的输入、执行的活动后所创建的输出（需求制品）是否符合所定义的质量准则。确认的执行需要将相关涉众、其他需求来源（标准、法律等纳入进来），如有必要还需将外部评审者纳入进来。需求配置（Requirement configuration）：配置基本版本，用于管理需求制品的不断演化，配置相关的各种需求不同版本的组合。需求基准（线）（Requirement baseline）：需求制品的基线是一个被选择的需求制品配置。术语“需求基线”是指一个稳定的需求制品版本的配置。通常，在一个特定的系统发布版本中实现需求基线。需求状态（Requirement status）：状态也就是一种事物或实体在某一时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种变换过程。（8个状态值：已批准、已建议、已设计、已实现、已验证、已提交、已删除、已拒绝）需求追踪（Requirement traceability）：需求的可追踪是指在前向与后向两方面描述并密切注意一个需求的生命能力。愿景（Vision）：系统愿景描述了对当前现实情况的一种大规模的所期望的改变。1、质量需求包含哪些类别？非功能性需求、性能需求。用户关心的：可用性、效率、灵活性、完整性、互操作性、可靠性、健壮性、易用性开发者关心的：可维护性、可移植性、可复用性、可测试性2、优良的需求定义应具备哪些特性？精确性、完整性、一致性。3、优良的需求文档应具备哪些特征？完整、可追踪、正确、明确、可理解、一致性、可验证、评级、更新、原子的4、系统上下文包含的四个刻面有哪些？主体：包含了系统上下文中与系统相关的对象与事件；使用：包含了与人或其他系统对本系统的使用相关的所有方面；IT系统：由系统部署环境中的操作环境和技术环境的所有方面组成，还涉及IT策略与规则；开发：包含了与系统开发过程相关的上下文方面，包括准则与约束、开发工具、质量保障方法等。5、需求工程包含哪些核心活动？抽取：抽取活动的目标是要改进对需求的理解，即在内容维度上取得进展；文档化：是根据所定义的文档和规约规范，将所抽取的需求进行文档化和规约描述；分析：必须满足不同涉众的要求和期望，不同涉众观点之间的冲突都必须识别并且明确表示出来，应当尽量解决所有的冲突。6、需求制品有哪些？目标：场景：面向方案的需求：7、什么是AND目标父目标G到一组子目标G1，G2，Gn（n2）的分解是一个AND分解，当且仅当为满足父目标G所有的子目标G1，G2，Gn都必须满足。8、什么是OR目标父目标G到一组子目标G1，G2，Gn（n2）的分解是一个OR分解，当且仅当G1，G2，Gn中任意一个子目标得到满足就能使父目标G得到满足。9、i*i*框架是一种全面的、用于目标和目标依赖分析及描述的方法。i*的基本思想是：一个参与者（actor）依赖于其他参与者来实现自己的目标。10、KAOS一个KAOS模型包含6个互补的视图或子模型：目标模型、障碍模型、对象模型、主体模型、操作模型和行为模型。所有这些子模型通过追踪关系连接相互关联。11、场景的类别当前状态场景和期望状态场景：正面场景和负面场景：不当使用场景：描述性场景、探索性场景和解释性场景：实例场景和类型化场景：系统内部场景、交互场景和上下文场景：主场景、可替换场景和例外场景12、刻画场景的方法有哪些？叙述性场景：即用自然语言进行场景描述针对场景结构化描述的参考模板针对用例的结构化描述的参考模板11条规则利用UML顺序图描述场景的交互序列利用UML活动图描述场景和用例的控制流利用用例图描述用例之间以及用例与参与者之间的关系13、解决方案需求包含哪三方面的内容？数据视图：关注于定义需要由软件密集型系统管理的数据/信息；功能视图：定义了系统需要提供的处理过程（功能）、每一个处理过程中对于数据的操纵、处理过程之间的输入输出关系（信息流）；行为视图：关注于定义系统的总体行为。14、Mealy有限自动机工作原理Mealy自动机，自动机的输出依赖于当前状态和输入符号，即输出函数将当前状态和一个输入符号作为自变量。15、Moore有限自动机工作原理Moore自动机的输出只依赖于当前的状态。16、可能的需求来源有哪些？涉众（定义参考上面）现有文档：包含定义系统需求所需的大量信息。相关文档包括通用文件（如法律、标准）、特定组织文件（如开发指南、组织内的通用指南）或描述同类开发制品或原有系统的文档（如用户手册、系统体系结构文档、需求规格说明、测试文档等）。现有系统：遗留系统和原有系统、竞争对手的系统、类似系统17、需求冲突(conflicts)是否可避免？不能过程是指活动、任务、目标和主要想法1、需求工程过程（Requirement engineering process）：主要目标是在上下文中建立愿景，在内容、共识和文档化三个维度上取得进展。包括5项活动：需求获取是指从人、文档或者环境中获取需求信息；需求分析主要工作是通过建模整合各种信息，使人们更好地理解问题；需求规格说明将上一阶段的结果形成文档。需求验证为了保证SRS的正确性，需要相关人员对其进行严格地验证；需求管理在开发活动结束之后，还需要一种力量保证需求作用的持续、稳定和有效的发挥，需求管理就是这样的一个管理活动。2、需求工程的重要性：对于项目成功的影响不充分的需求工程导致需求中的缺陷需求缺陷导致高成本因为问题总是新的问题，所以软件工程师常常需要将工作中很大的一个部分用来定义问题，然后再为其设计一个新的解决方案。定义问题就是需求工程的任务，所以除了一些特殊情况之外，在软件开发当中进行需求工程是非常必要的。3、需求启动的过程（Requirement inception process）需求启动过程是需求过程的起始点，有时作为需求获取的一部分。任务：确定商业需求：包括业务背景、商业机会、商业目标和成功的关键、业务风险。定义涉众：和系统有关联的人员或组织；取得一致的问题定义：得到项目前景，了解哪些是根本元素，决定工程的范围和边界；确定约束和风险：分别从经济、政治、技术、系统、环境、计划表和资源等方面确定；执行可行性分析：（定义）。生成项目前景和范围文档4、需求获取的过程（Requirement elicitation process）需求获取是从人、文档或者环境中获取需求的过程，完成需求获取和给出需求定义。需求获取的目标：识别相关的需求来源；从所识别的来源中抽取现有需求；开发新的创新性需求。子活动：识别相关的需求来源，抽取现有需求，开发新的创新型需求。4.1、需求获取的技术（Choosing RE elicitation techniques）访谈、头脑风暴、原型、观察、问卷调查、基于视角的阅读（阅读文档、分析已有系统、访谈、头脑风暴、原型、用例）分析已有的系统开发已有系统的升级版头脑风暴需要提出一种新的实现方式或者没有太多的信息可以参考调查问卷组织成员分散，许多成员和项目有关，需要考察工作原型在需求模糊和不确定性较大的情况下模型驱动其有一个定义明确的模型。4.2、面谈过程要求工程师或分析师讨论了系统与不同涉众建立一个理解他们的需求。其三个主要目的是：记录信息作为输入到需求分析和建模；从被访问者处得到精确可靠的信息；让被访问者理解已经被探究和评价的主题。主要过程分为4步：计划和准备、见面会、资信整合、后续行动4.3、用例开发的过程（Use case development process）用例方法把系统视为一个黑盒，描述外部用户的他们之间发生的相互作用和系统。对于每个用户，用例模型描述了服务所提供的系统或系统如何使用的用户。用例模型描述系统的一个总体印象。4.4、结束获取的时机（When to end elicitation）用户想不出任何新的用例用户提出的新用例，是已经推导出其他相关用例的功能需求用户重复之前讨论过的问题用户提出的新功能超出范围新的需求都是低优先级的5、需求分析的过程（Requirement analysis process）目标：在获取的需求中发现问题、不完整和不一致，将这些返回给涉众通过协商解决这些问题。子活动：识别冲突、分析冲突、解决冲突、记录冲突解决方案需求分析的技术：5.1, 5.25.1、结构化分析过程：从经过它的数据流来看待系统，系统的功能通过数据流转换的过程来描述。5.1.1数据建模E-R（接5.3）5.1.2过程建模上下文图，DFD（接5.4）5.2、面向对象的分析方法：认为系统是对象的集合，这些对象之间互相协作，共同完成系统的任务。与结构化分析方法有不同的建模思路，前者以对象为基础，后者以功能和数据为基础。5.2.1领域建模类图5.2.2功能建模用例图5.2.3行为模型顺序图，活动图，状态图（接5.5）5.3、数据建模过程：是创建数据模型的过程。相当于逻辑数据的设计。分为三个部分，数据对象，属性和对象之间的关系。通常用E-R图表示。5.4过程建模过程：是一种典型的结构化分析技术。是分析以获取的需求、发现系统功能和与外部世界的交互、建立系统分解结构的过程。用交互图、DFD表示。5.5行为模型：描述对象之间的交互行为，顺序图，状态图，协作图。5.6、功能性需求建模过程：功能分解图。5.7、非功能性需求建模过程：非功能需求是全局约束在一个软件系统。6、需求规范说明过程（Requirement specification process）：（与名词解释的第二定义一致）在需求分析过程中系统地组织系统需求；并正确地为这些需求建立需求文档；SRS是清晰且精确地描述软件的每条需求以及外部接口包括软件的功能、性能、设计约束和质量属性；将需求及其软件解决方案进行定义和文档化；传递给开发人员的需求工程活动。6.1需求规格说明的描述方法非形式化描述自然语言（易写易读，不需要特殊能力和技巧；不严谨，易产生歧义，表述能力差）半形式化描述UML（直观，聚焦；要求编写者和读者一直地理解图表；存在不宜用图形化表示的信息）形式化描述E-R, SM（状态机），四变量，表格表示（严谨，精确；难于编写和阅读）非功能的需求模型7、需求确认的过程（Requirement validation process）目标：检查活动的输出（输入）是否满足所定义的质量规则，检查活动的执行是否遵循了过程定义和活动准则。（SRS的正确性）子活动：上下文考虑的确认，活动执行的确认，需求制品的确认。确认的技术：审查书面材料的质量提升过程；桌面检查、走查、原型和仿真、测试用例、用户手册（验证和确认的技术：审查、模型检查、测试、原型、用户手册）7、需求管理过程（Requirement managements process）目标： 观察系统上下文来检测环境的变化；管理需求工程活动的执行；管理需求制品。子活动：管理需求制品、观察系统上下文、管理需求工程活动7.1、版本控制过程（version control process）统一制定每个需求文档的版本保证每个成员能够获得当前需求文档的最新版本将变更清晰地写入文档中并及时通知项目组人员为了尽量减少冲突，应允许指定人更新需求7.2、变更控制过程(change control process)对提出的变更做评估挑选合适的人选对变更做出决定变更及时通知到所有涉及的人根据变更处理流程来采纳需求变更控制项目范围扩大7.3、需求追踪过程(Requirement tracing process)跟踪一个需求使用期限全过程，编制每个需求同系统元素之间的联系文档。提供由需求到产品实现整个过程范围的明确查阅能力。建立维护“需求-设计-编码-测试”之间的一致性，确保所有工作成果符合用户需求。7.3.1跟踪关系类型：条件，内容，抽象，演化，其它7.3.2跟踪记录：验收，变更管理，质量保证，维护，修理，再工程，重用，风险管理，过程改进7.4、需求状态追踪过程（Requirement status tracking process）跟踪整个开发过程中每个功能需求的状态，更加准确地衡量项目进度，并帮助评估需求变化的影响。可靠性和有效性：Reliability: 系统在一定时间，一定条件下执行指定功能的能力。用以下几个指标表示：MTTF，defect rate, Degree of precision for computationsAvailability: 系统正常运行时间的百分比。Availability = MTBF/(MTBF+MTTR)确认和验证确认：是否在构造正确的系统，满意是目标。验证：是否在正确地构造系统，验证的任务是检查一个系统需求模型表述的正确性。质量是目标。专心-专注-专业