需求工程资料

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