73 research outputs found

    Risk and Business Goal Based Security Requirement and Countermeasure Prioritization

    Get PDF
    Companies are under pressure to be in control of their assets but at the same time they must operate as efficiently as possible. This means that they aim to implement “good-enough security” but need to be able to justify their security investment plans. Currently companies achieve this by means of checklist-based security assessments, but these methods are a way to achieve consensus without being able to provide justifications of countermeasures in terms of business goals. But such justifications are needed to operate securely and effectively in networked businesses. In this paper, we first compare a Risk-Based Requirements Prioritization method (RiskREP) with some requirements engineering and risk assessment methods based on their requirements elicitation and prioritization properties. RiskREP extends misuse case-based requirements engineering methods with IT architecture-based risk assessment and countermeasure definition and prioritization. Then, we present how RiskREP prioritizes countermeasures by linking business goals to countermeasure specification. Prioritizing countermeasures based on business goals is especially important to provide the stakeholders with structured arguments for choosing a set of countermeasures to implement. We illustrate RiskREP and how it prioritizes the countermeasures it elicits by an application to an action case

    The i* framework for goal-oriented modeling

    Get PDF
    The final publication is available at Springer via http://dx.doi.org/10.1007/978-3-319-39417-6i* is a widespread framework in the software engineering field that supports goal-oriented modeling of socio-technical systems and organizations. At its heart lies a language offering concepts such as actor, dependency, goal and decomposition. i* models resemble a network of interconnected, autonomous, collaborative and dependable strategic actors. Around this language, several analysis techniques have emerged, e.g. goal satisfaction analysis and metrics computation. In this work, we present a consolidated version of the i* language based on the most adopted versions of the language. We define the main constructs of the language and we articulate them in the form of a metamodel. Then, we implement this version and a concrete technique, goal satisfaction analys is based on goal propagation, using ADOxx. Throughout the chapter, we used an example based on open source software adoption to illustrate the concepts and test the implementation.Peer ReviewedPostprint (author's final draft

    Using a foundational ontology to investigate the semantics behind the concepts of the i* language

    Get PDF
    In the past few years, the community that develops i* has become aware of the problem of having so many variants, since it makes it difficult for newcomers to learn how to use the language and even to experts to efficiently exchange knowledge and disseminate their proposals. Moreover, this problem also delays the transfer of the i* framework to industrial settings. Our work is one of the current attempts to promote interoperability among the existing variants, and it does that by investigating the semantics behind the i* core concepts. For that, we apply a foundational ontology named UFO, which is used as a semantically coherent reference model to which the language should be isomorphic. In this paper, we report on the steps we have pursued, what we have accomplished so far, also setting the context for the work ahead

    Using a foundational ontology to investigate the semantics behind the concepts of the i* language

    Get PDF
    In the past few years, the community that develops i* has become aware of the problem of having so many variants, since it makes it difficult for newcomers to learn how to use the language and even to experts to efficiently exchange knowledge and disseminate their proposals. Moreover, this problem also delays the transfer of the i* framework to industrial settings. Our work is one of the current attempts to promote interoperability among the existing variants, and it does that by investigating the semantics behind the i* core concepts. For that, we apply a foundational ontology named UFO, which is used as a semantically coherent reference model to which the language should be isomorphic. In this paper, we report on the steps we have pursued, what we have accomplished so far, also setting the context for the work ahead.Peer ReviewedPostprint (author’s final draft

    RiskREP: Risk-Based Security Requirements Elicitation and Prioritization

    Get PDF
    Companies are under pressure to be in control of their assets but at the same time they must operate as efficiently as possible. This means that they aim to implement "good-enough security" but need to be able to justify their security investment plans. In this paper, we present a Risk-Based Requirements Prioritization method (RiskREP) that extends misuse case-based methods with IT architecturebased risk assessment and countermeasure definition and prioritization. Countermeasure prioritization is linked to business goals to achieve and based on cost of countermeasures and their effectiveness in reducing risks. RiskREP offers the potential to elicit complete security countermeasures, but also supports the deliberate decision and documentation of why the security analysis is focused on certain aspects. We illustrate RiskREP by an application to an action case

    Selection of indicators for a report

    Get PDF
    Dissertation presented as the partial requirement for obtaining a Master's degree in Information Management, specialization in Information Systems and Technologies ManagementThis dissertation is aimed at helping organizations that implemented a Business Intelligence (BI) system without documenting to identify the reasons for the indicators choice either in the conception phase of the project or other. The example taken to present the methodology is a fictitious case study of an organization named BestBread. The aim of this dissertation is to demonstrate not only the necessary indicators in a report but also to describe why they are needed through a business goal representation. This dissertation approach focus mainly in using two methodologies, a simplified notation of the Business Intelligence model (BIM) and a systematic approach that aims to justify BI indicators through modelling report goals. This approach provides guidance to organizations that already implemented a BI tool by presenting a method to compare intuitive and systematic selection of indicators with the BI system existing indicators. The approach is applicable to define in a report its significant indicators. The steps needed to be executed are the following: 1- Model business goals; 2- Select indicators through an intuitive perspective; 3- Verify the indicators existence identified in the intuitive perspective; 4- Select indicators through a systematic perspective; 5- Verify the indicators existence identified in the systematic perspective; 6- Make a global comparison. The dissertation approach allowed an easier way to identify and explain the purpose of indicators to be used in a report. Also, the methodology presented could help the BI deployment phase to be quicker since users would be able to visualise through the representations the evaluation that the indicators could evoke in their business goals. Therefore, it could improve the use of the BI tool, its acceptance and maybe even users’ satisfaction with the tool

    Requirement modeling for data warehouse using goal-UML approach: the case of health care

    Get PDF
    Decision makers use Data Warehouse (DW) for performing analysis on business information. DW development is a long term process with high risk of failure and it is difficult to estimate the future requirements for the decision-making. Further, the current DW design does not consider the early and late requirements analysis during its development, especially by using Unified Modeling Language (UML) approach. Due to this problem, it is crucial that current DW modeling approaches covered both early and late requirements analysis in the DW design. A case study was conducted on Malaysia Rural Health Care (MRH) to gather the requirements for DW design. The goal-oriented approach has been used to analyze the early requirements and later was mapped to UML approach to produce a new DW modeling called Goal-UML (G-UML). The proposed approach highlighted the mapping process of DW conceptual schema to a class diagram to produce a complete MRH-DW design. The correctness of the DW design was evaluated using expert reviews. The G-UML method can contribute to the development of DW and be a guideline to the DW developers to produce an improved DW design that meets all the user requirement

    Subconjuntos Mínimos de Corrección para explicar características muertas en Modelos de Líneas de Productos. El caso de los Modelos de Características

    No full text
    Aprovechar los beneficios que ofrecen las líneas de productos depende, entre otros aspectos, de la calidad de los modelos que representan cada línea de productos. Una parte de la calidad consiste en asegurar que los Modelos de Líneas de Productos (MLPs) se encuentran libres de defectos. Un tipo de defecto de los MLPs son las características muertas, ellas son elementos reutilizables que no están presente en ningún producto configurado a partir del MLPs. Cuando las características muertas aparecen, quien crea los MLPs necesita herramientas que le permitan identificar por qué se presentan las características muertas y cómo podría corregirse el modelo. Sin embargo, aunque muchos trabajos en la literatura identifican características muertas, pocos explican por qué se originan o lo explican de manera incompleta. En este artículo se propone un nuevo método para explicar por qué se presentan características muertas en un MLP expresado con la notación modelos de características. Nuestra explicación consiste en identificar diferentes subconjuntos de elementos que podrían ser modificados para corregir el modelo cada que se presente una característica muerta. Esta explicación ofrece al modelador información completa sobre cómo corregir el modelo para cada característica muerta encontrada
    corecore