文档2阅读报告-Requirements Interdependencies- Moulding the State.docx

Requirements Interdependencies- Moulding the State of Research into a Research Agenda摘要。定义：相互依赖关系（interdependent），即需求量相关，并相互影响的一种关系。（Requirements relate to and affect each other, i.e. they are interdependent.）一、 简介：大多数的需求量不能独立处理，因为它们是相关的，并且以复杂的方式相互联系、相互影响1, 2。基于一个需求量的执行操作可能会不经意或意料之外的方式影响到其他需求量。需求之间的依赖关系（Dependencies）也可能会影响开发过程中的很多决定和活动，如需求变更管理3，4，发布规划2，5，需求管理6，要求重用7和要求的执行情况8。这意味着在开发过程中有必要对相互依赖关系（interdependencies）进行考虑，以作出合理的决定（例如，见3.1节）。尽管如此，很少有人知道的需求相互依赖关系（requirements interdependencies）的性质，需要进一步研究，以更好地理解这一现象5，9,10。我们研究的总体目标，是要明确在具体开发情况下哪些需求的相互依赖关系类型是要重点考虑的。比如：在发布计划或需求管理。同时，我们的目标也包括根据具体情况，提出管理依赖关系（dependencies）的有效方法。这里提供了为实现这一目标的首要步骤：通过提供需求相互依赖关系（requirements interdependency）研究现状的概述，通过在书面上讨论、开发一种基于基本依赖关系类型的集成分类系统，（by developing an integrated classification offundamental interdependency types discussed in the literature）以及为了进一步的研究而制订新的研究现状。解决需求依赖关系（requirements interdependencies）的文献数量相当小。而且不同的地方有不同的研究角度。（it approaches the area from different perspectives.）pohl4以及Ramesh和Jarke 6讨论主题中需求跟踪部分，重点放在需求管理以及变更管理上。需求依赖关系对需求的选择以及发布计划的影响由Karlsson等人讨论5，Carlshamre和Regnell 9和Carlshamre等人2 负责需求的互动管理（requirements interaction management），这是为了处理识别需求间如何影响彼此的结果。（which deals with identifying how requirements may affect each others achievement）二、可跟踪性：理解需求相互依赖关系（Requirements Interdependencies）的基础需求跟踪被公认为是软件和信息系统开发的重要组成部分4，11，12，支持一个软件系统生命周期的多项活动。因此，需求跟踪被认为是正确解决相互依赖关系的前提。（We view the area as a basis for addressing requirements interdependencies.）这种观点，在理论和实证研究上，都经过大量文献描述并证实了（见如4，13，11，14，15，16，17。Ramesh和Jarke 6 基于数年的研究，扩展了该领域上当前的研究概述状况。文献中有几个关于长期可追溯性的定义见6，18，19，4，在这里我们将需求跟踪定义为：理想情况下，在整个系统的生命周期里，可以在向前和向后两个方向上描述、跟踪需求的生命状况。（"ability to describe and follow the life of a requirement, in both forward and backward direction, ideally through the whole system life cycle"）20, pp. 32, based on 14。这个定义表明，需求跟踪可以分为两个主要类型：预先-跟踪性和后期-跟踪性（图1）。预先-跟踪性指需求的生命周期开始之前该需求的各方面信息，列入到需求规范中14（those aspects of a requirements life before it is included in the requirements specification 14 and is focused on enabling a better understanding of the requirement.），主要为了更好地理解需求。后期-跟踪性指需求的生命周期中实时反应该需求的各方面信息，列入到需求规范中14，（those aspects of a requirements life from the point in time when it has been included in the requirements specification）主要是为了能更好地理解、验收当前的系统/软件。Figure 1: Different types of traceability因此，需求的预先-跟踪性关注需求的结果（requirements production），将焦点放在域（domain），并当需求发生或系统安装时，进行交付工作。（Requirements pre-traceability is hence concerned with requirements production and focuses on the domain with which we interact when the requirements are developed and in which the systems is to be installed.）需求的后期-跟踪性关注的是需求的部署（requirements deployment），将焦点放在以需求为基础的软件（software）开发上。（Requirements post-traceability is concerned with requirements deployment and is focused on the software that is developed based on the requirements.）预先-跟踪性和后期-跟踪性也可分为四跟踪类型，这是在21表述的。根据文献6关于跟踪性的信息，为需求工程设计、系统演变和测试程序提供了重要的支持。图1给出了需求跟踪链接的各种类型，在软件系统的开发和维护时支持不同的情况和活动。这一切都不会单独支持需求跟踪（见3）。不同利益相关者通常也对不同类型的需求跟踪信息感兴趣。尽管如此，目前的文献和规章很少有指导方针关于在上下文中哪些类型的信息应该捕获和使用6。（current literature and standards provide few guidelines regarding which type of information should be captured and used in what context 6）需求跟踪关注的是各种跟踪对象之间的跟踪关系，例如要求、合理、文件、处理阶段等。在本文中，我们重点放在跟踪对象为特定种类之间的关系，即明确规定的需求（explicitly stated requirements）（图1的阴影部分）。不同的作者以许多不同的方式使用长期的依赖关系。（The term dependency is used in fairly different manners by different authors）Pohl 4用广义的术语，确定了18种不同类型的依赖关系（Pohl 4 has a broad view of the term and has defined 18 different dependency types ）（见图2）。另一方面，Ramesh 和Jarke6使用更有具体（specific sense）的术语，区分了相互依赖关系（dependencies）和其他的关系（relationships）类型。这意味着，术语“相互依赖关系”（dependency）可以被看作是术词“关系”（term relationship）的代名词，或在这两个对象之间形成一种强大的关联，彼此以某种方式相互影响。例如在变化的情况下。在这里，我们不区分依赖关系（dependency）和关系（relationships）。我们将探索需求量以哪些不同的方式可以联系到其他需求量，这也可能意味着他们同时也在相互影响。（We are interested in exploring the different manners by which requirements can relate to each other, which may mean that they affect each other as well.）我们也选择使用相互依赖关系（interdependency）这一术语来强调我们关注的、存在于同类跟踪对象之间的关系（relationships）。（We have also chosen to use the term interdependency to emphasise that the relationships that we focus on are those that exist between trace objects of the same type.）三、需求相互依赖关系的研究现状 本节旨在提供需求依赖关系（requirements interdependencies）研究现状的概述，通过发现和概括那些关注需求依赖关系类型、关注影响开发情况的文献，以及对正在进行的调查访问作概括。（This section aims at providing an overview of the current state of research on requirements interdependencies by outlining findings from the literature concerning requirements interdependency types and affected development situations as well as findings from an ongoing interview survey.）完整的需求依赖关系类型集合在文献22中提出。3.1、需求依赖关系（Requirements Interdependencies）-文献的综述（a Literature Review）需求的相互依赖关系在相当的程度上，属于尚未开发的领域。很少数量的文献对它进行讨论及评审。不过，在这方面的研究领域内也有一些里程碑。在需求跟踪研究的初期，波尔4开发一个跟踪踪的框架，其中包括了一个依赖关系模型，定义了可能存在的18个不同类型的依赖关系链接（图2）。波尔4的模型描述了在任何需求工程过程中，所有跟踪对象类型之间的依赖关系类型。我们专注于需求的相互依赖关系（requirements interdependencies,），但仍然有在一般依赖关系（general dependencies）和需求相互依赖关系（requirements interdependencies）之间已确定的关系（correlations），这激励着为什么这种依赖模型仍然应用于我们的投资中。(but there are most certain some correlations between these general dependencies and requirements interdependencies, which motivate why this dependency model is relevant for our investigation.)-表示不理解。Figure 2: The dependency model 4可是，Pohl的依赖关系模型必需有所调整，使之能适用于我们研究的需求依赖关系。因为Pohl模型里一些需求依赖关系显然不适用于需求量之间。（参见22类别的描述和模型中的依赖关系类型）。这些种类“文件”（ Documents）和种类“比较”（Compare），因此这是进一步讨论有关依赖模型时排除在外的。在其他情况下，相互依赖关系类型（dependency types）里描述的“跟踪对象”（trace object）这一术词会被“需求”(requirement)这一词替用，并将之后的讨论中使用。尽管对我们的研究来说，Pohl的模型是一个有价值的开始，其模型的类别和依赖关系的种类有时很难明确区分彼此。另外的需求依赖关系类型将在随后的文献中提到。因此有必要修改和调整这种模型，为了发展一种模型专门用于需求依赖关系（requirements interdependencies），同时也为了合并最先的研究。Pohl提到需求如何演化的知识，因此在处理变化和变化的一体化时，彼此相互的关系是重要的。（and hence relate to each other, is considered to be important when dealing with changes and change integration.）Kotonya和Sommerville 3同意这种说法，并表示在变化管理（change management）的角度上，需求相互依赖关系（requirements interdependency）的概念是需求跟踪中最重要的一点。这些依赖关系（dependency）的类型在Pohl模型也是考虑的部分。（包括抽象和进化的）Pohl还明确了需求相互依赖关系作为明确可重用软件组件（reusable software component）的推动角色。如果被声明的需求(stated requirements)对比于现行的需求(existing requirements)时，检测到的需求是相似的，这表明这是一个可重用组件。依赖型的“相似”（Similar）是包含在模型中。 Karlsson等人5需求这部分开发了一种解决办法，通过成对的对比（pair-wise comparison）。他们指出，需求的优先级处理办法必须包括需求相互依赖关系管理，这是为了充分支持开发者。（They state that requirements prioritisation approaches must include means for managing requirements interdependencies in order to fully support developers.）由于这种相互依赖关系（interdependencies），需求不会被视为独立的个体（stand-alone artefacts.）。例如，如果您选择执行一个高优先级、低成本的需求量，您可能还必须执行一个低优先级、成本高的需求量。因此选择需求时，不可以单单考虑优先级。Karlsson等人5的结论是：当存在一个缺少支持的需求相互依赖关系，特定条件是，需求所包含或排除在外的影响都可以观察到。他们已经确定了一套初步的相互依赖关系的类型，且他们被认为在需求选择的前后过程中是有关的（见22）。（这个结论我表示不理解。）Carlshamre和Regnell 9 同意5，并作出结论：由于需求的相互依赖关系，发布计划是一个非常复杂的任务。需求相互依赖关系的管理被认为是特别重要的，当需求是“培养异步生命周期模型”（fostered asynchronously in a life cycle model）时。因为他们连接着需求的片段（requirements fragments.）。对未来的研究，有必要关注需求之间存在着的、不同类型的相互依赖关系。Carlshamre和Regnell 9描述了一些的相互依赖关系的类型（见22）。Carlshamre等人2继续了5和9 的工作，并进行一个用于发布计划的需求依赖关系的工业调查。确定了六种不同类型的相互依赖关系（见22），部分以5提出的类型作基础；并分析五个不同公司之间20个高优先级的需求量。从这个调查结果表示，很少有单独的需求量，即需求量与其他需求量没有关系。有时，研究中的受访者很难去选择两个需求量之间的关系（relationship）要使用何种依赖类型（interdependency type），因为多于一种类型的相互依赖可以使用。因此，有必要优化相互依赖的类型。另外，需求依赖关系很少有明确的定义，理由如下：大量的相互依赖关系会导致明确和管理需求的困难、需求相互依赖关系本身比较模糊，意味着其所描述的关系（relationship）或多或少会比较重要。（meaning that the relationship they describe can be more or less critical）。如果R1因为R2而增加了执行成本，R1的成本也有可能会发生大的增加又或者变化甚微。（If R1 increases the implementation cost of R2, it could be a large increase or an insignificant.）这个问题在6中讨论到，6中表示很难去明确一个相互依赖关系的联系强度（strength of an interdependency link）。尽管需求量的成对分析也支持需求的其他问题，但它需要很多时间。所以找到减少评估时间的方法相当重要。Ramesh和Jarke 6采取的第一步指向需求跟踪的参考模型（reference models）。他们的焦点不在于需求的相互依赖关系，但是，正如我们上面所说，需求的相互依赖是一个跟踪性问题。根据文献6中公司所用的简化跟踪做法也是需求之间的一种“文件”（document）跟踪性链接，为了给跟踪的需求量建模。（According to 6 companies with a simplistic traceability practice also document traceability links between requirements in order to model requirements traceability需求之间的跟踪是文档跟踪）前面讨论过的依赖关系类型大多数都涉及需求管理和需求的演变（参见22）。Ramesha和Jarke6也指出，将高层次的需求分解成更具体的需求，这对于保持需求的跟踪来说非常重要。例如，在为了管理需求数量的爆炸式增长以及为了更容易去理解需求通过映射关系找回源头。（in order to manage the explosion in the number of requirements as well as facilitating understanding of the requirements by mapping them back to their sources.）Ramesha和Jarke6也强调，保持所有相关的需求和开发过程中产生的输出之间的链接（Link）是既不可行，也不可取的。（it is neither feasible nor desirable to maintain links between all related requirements and output produced during the development process）因为保持跟踪性链接所涉及到的开销过大。相反，更可行的方法是去识别那些关键的需求，并专注于储存那些与跟踪性相关的信息。Robinson等人8对需求的交互管理（requirements interaction management）这一领域做报告。这个领域专注于那些可能会影响彼此成果的需求之间的关系（relationships）管理，想法是为了识别那些不能同时满足的需求（The idea is to identify requirements that cannot be satisfied simultaneously.）。Robinson等人基于此，执行了对需求相互依赖关系的实施或以实现为导向的想法。（Robinson et al has hence taken an implementation or realization oriented view on requirements interdependencies.）其主要目的是管理需求之间的矛盾(conflicts)，并在需求定义的时间上，确认能满足需求的问题。（identify the problems with satisfying requirements at requirements definition time.）Robinson等人也确定了很多不同类型的需求依赖关系（见22）。3.2、正在进行的访谈研究的一些发现（略）这项研究着重于当前的实践和需求工程关注的挑战。一般而言，大多数研究中的受访者都承认，需求联系并影响着彼此。而且，参与访谈的公司并不是都使用“文件”（documented）需求依赖关系类型。相反，在实践中需求会聚集，通常会绑定在一起执行。（the requirements were clustered, usually with respect to which requirement that should be implemented together.）这可能取决于需求是否关注系统的同一个部分：如果在同一时间执行需求能有效地利用成本、或者这些需求由同一个人执行。需求的矛盾管理主要是关于权衡如何实施不同需求。执行开销（Cost of implementation）应注意去识别那些可以/应该在同一时间内执行的需求，因为这可以降低执行时的开销。（Cost of implementation is concerned with identifying requirements that can/should be implemented at the same time, since this decreases the implementation cost）有时已经确定的相互依赖关系，其结果可能是很难理解的。通常，是因为这种相互依赖关系之间存在非功能性需求（non-functional requirements）。四、建立基本依赖关系类型的模型在深入地解决不同情况下如何管理需求相互依赖关系类型之前。我们首先需要将之前文献中不同的观点编译成一个综合模型，即中立的发展情况。（which is neutral with regard to development situation.）这句话理解不了：(One identified problem is to choose between different types of interdependencies and Pohls dependency model alone comprises 18 types)此外，通过文献中需求相互依赖关系类型之间的差异，仍然有一些未完成的工作。从本质上讲，依赖关系的分类似乎受利益相关者的想法影响，并成为开发过程的一部分。如需求选择或发布计划。此外，不同类别的重叠和用明确术语表示类型的条款的含义，在不同的地方也有不同的表述。（various classifications overlap and the meaning of certain terms, which denote the types, not clear in the area as a whole.）例如所谓“时间依赖性”（temporal dependency），不同的作者给出了不同的含义。基于我们的分析可以在22中找到相互依赖关系类型的完整列表。根据文献、正在进行的访谈研究以及一些中间结果，我们制定了一个分类（图4），这可以被认为是总体开发和建立需求中立的基本依赖关系类型（fundamental requirements interdependencies）模型的第一步。这种分类将来有可能需要进一步阐述和验证，例如用大量不同的需求集。由于我们关注几种迄今为止我们认为是基本的依赖关系类型，这些以后可能需要进行调整或扩充，以适应在软件开发过程的不同需求，例如：需求选择或发布计划。Figure 4: The new classification根据这一分类，我们可以明确基本且中立的相互依赖关系的两个类别。我们暂时称之为结构相互依赖关系（STRUCTURAL）和成本/价值相互依赖关系（COST/VALUE）。4.1结构性相互依赖关系（Structural Interdependencies）Structural Interdependencies关注的是，给定一组以结构化方式组织而成的需求，这些结构中存在的关系是：层次关系以及交叉结构关系。往往高层次的业务需求会逐渐分解成更具体的软件需求。另外，不同层次间的需求可能会经由整体层次（overall hierarchy）而相互影响。我们发现这一类的相互依赖关系类型，如下：Requires一个需求的落实取决于另一个需求的落实。这种类型可以用来描述两个要求之间的层次关系（hierarchical relation），而且这种关系可以穿过结构化的层次。（but also relations across hierarchical structures.）这种相互依赖关系类型是由相互依赖关系类型“requires” 2、“and” 2、“logical” 9 和“must-exist”5派生出来。这种关系在相反方向也成立。（This relationship can also be viewed in the opposite direction）换句话，R1的执行需要R2，即R2是R1的先决条件2。（i.e. instead of R1 requires R2, R2 is a prerequisite for R1 2）(这是一种条件的！)依赖类型(dependency)“or” 2是很难归类的(可选的，其实这是有条件的！)，因为它与不同类型的相互依赖关系有关。（since it can be related to different interdependency types.）依赖类型”or”可以作为其他依赖关系的替代方案，例如需要另一个需求时，即R1需要其他的需求量R2，R3，R4的。（The “or” dependency relates alternative solutions to each other, which e.g. may be required by another requirement i.e. R1 requires some of the following requirements R2, R3, or R4.）显然，这种需求类型需要更多的研究，以便更好的理解。依赖类型“Satisfy”4和“positive correlation”8可以看作为需求类型的较弱的依赖关系。（a weaker dependency of the type require.）他们都关注那些用以支持另一需求落实的需求链接（linking requirements）。在这种情况下，当为了执行R2，必需（must）执行R1，或当依赖关系“Satisfy”4和“positive correlation”较弱的时候，执行R1对R2的执行有积极影响，就要使用这种需求依赖类型（require dependency type）。Explains一个高级别的需求是可以由许多更加具体的需求来解释。Explains这种依赖关系类型是用来描述比依赖关系类型Requires具有更弱特点的层次结构，而且为源需求提供更多详细细节信息的需求。（This dependency type is used to describe hierarchical structures of a weaker nature than Requires and relates more detailed requirements to their source requirements）如果一个具体的需求是派生于一个高层次的需求，但它不是这个需求的先决条件，（If a detailed requirement is derived from a high level requirements, but it is not a prerequisite for this requirement）则该关系（relation）是依赖关系类型Explains。这种依赖关系类型包括Ramesha和Jarke6中 提到的“elaborate”、“part_of”、“is_a” and “derive”，Pohl 4中提到的“elaborate”、“formalize”、“replaces”、“generalizes”、“refines”和“based_on”，还有von Knethen等人在7提到的“refinement”。如上所述，我们寻找确定基本相互依赖关系类型（basic interdependency types）的方法，而这些关系类型是非常的相似，很难分辨。因此，将他们归纳成一个整体的依赖关系类型。Similar_to一个被声明的需求或多或少会与一个或多个其他需求相似。这种相互依赖关系类型对应于“similar“4和“structure”8。这种相互依赖关系类型也在访谈研究中提到。Natt och Dag 25发表了一种可行性的评估方法，即用自然语言的处理技术来识别需求集中的重复量。Conflicts_with一个需求与另一个需求发生冲突时，如果他们不是在同一时间存在，或者当增加一个需求满意度，则会降低了另一个需求的满意度，则称之为“Conflicts_with”。这种相互依赖关系类型（interdependency type）包括上述两种情况，而且在上述情况下，其需求均不可能同时执行，还会对彼此的需求结果有负责影响，而且必需权衡两个需求各自的解决方法。因此，它包括“constraint” 4、“negative correlation” 8、“conflict” 4和“cannot_exist” 5。冲突在访谈调查中也是最经常被提到相互依赖关系类型（interdependency types）之一。Robinson等人8强烈地关注依赖关系的冲突，并提出了一些关系（relations），这可以作为解释冲突的理由，例如“resource”、“tasks”和“causality”。Influences一个需影响另一个需求。这是在文献中指出，一个需求可能会影响其他的需求，以相对于“requires”、“explains”和 “conflicts”的方式。6和7中有一个相当普遍的相互依赖关系的类型，称为“depend_on”和“dependency”。我们的假设是，越来越多依赖关系可以被识别，特别是通过在遵守不同的开发活动和情况而进一步阐述中。然而，在现阶段，当两个相关需求之间的关系（relationship）不是“requires”、“explains”和 “conflicts”时。我们会选择使用一个包括总的相互依赖关系类型。4.2、成本/价值相互依赖关系（Cost/value Interdependencies）Cost/value interdependencies关注的执行与价值相关的需求时的成本开销，而这个需求的履行将提供给对需求有所领会的客户/用户。（Cost/value interdependencies are concerned with the costs involved in implementing a requirement in relation to the value that the fulfilment of that requirement will provide to the perceived customer/user.）实现一个需求的成本与实现另一个需求的价值相关，而这个需求的实现是提供给有所领会的(或译成：指定的或有想法的)客户。这一类的相互依赖类型包括：Increases/Decreases_cost_of如果选择执行一个需求，会增加或减少另一个需求执行的成本。这种相互依赖关系的类型包括有：“icost”2、“positive cost”和“negative cost”5以及“value-related”9. Increases/Decreases_value_of如果选择执行一个需求，会增加或减少另一个需求对消费者的价值。 这种相互依赖关系的类型包括有：“cvalue”2和“positive value”以及“negative value”5。4.3、研究的现状 除了开发基本需求相互依赖关系类型的参照模型，和扩展该参考模型以应付在软件开发过程中的特定需要，我们要明确需求相互依赖关系研究领域中的三个主要问题： How can we identify requirements interdependencies?如何识别依赖关系？识别即发现、记录依赖关系。需求的相互依赖关系（requirements interdependencies）的问题，不仅涉及如何记录和保持相关需求间的联系，也必须能通过一些方式来识别那些关系（relationships）。当分析需求集时，可能很容易发现一些相互依赖关系，但也有一些相互依赖关系，是很难确认的(所以需要明确定义，特别是形式化的定义！)。此外，需求之间的相互影响也是难以确认的，特别是关于非功能性需求（non-functional requirements）。我们需要研究的是如何确认需求的相互依赖关系，以及探讨需求之间是如何相互影响的。Pohl 4中提出了一种自动记录跟踪链接的方法。 Carlshamre等人2描述了如何使用需求成对的分析去发现相互依赖关系，他们还讨论了关于如何降低这种分析方法所需的时间。但上述这两种方法都是假设开发人员知道需求之间是如何影响彼此的。然而，这是有必要找到一种方法，可以探索相互依赖关系是何种结果，即能探索需求之间是如何相互影响。(正因为没有准确的和形式化的需求依赖关系的定义，所以然才导致把需求依赖关系建立在