24 research outputs found

    Systematic reviews in requirements engineering: A tertiary study

    Full text link
    © 2014 IEEE. There has been an increasing interest in conducting Systematic Literature Reviews (SLR) among Requirements Engineering (RE) researchers in recent years. However, so far there have been no tertiary studies conducted to provide a comprehensive overview of these published SLR in RE. In this paper we present a tertiary study of SLR that focus solely on RE related topics by following the guidelines of Evidence Based Software Engineering. We have conducted both automated search of major online sources and manual search of the RE and SLR related conferences and journals. Our tertiary study has identified 53 distinct systematic reviews published from 2006 to 2014 and reported in 64 publications. We have assessed the resulting SLR for their quality, and coverage of specific RE related topics thus identifying some gaps. We have observed that the quality of SLR in RE has been decreasing over the recent years. There is a strong need to replicate some of these SLR to increase the reliability of their results for future RE research

    Enhancing Context Specifications for Dependable Adaptive Systems: A Data Mining Approach

    Get PDF
    Context: Adaptive systems are expected to cater for various operational contexts by having multiple strategies in achieving their objectives and the logic for matching strategies to an actual context. The prediction of relevant contexts at design time is paramount for dependability. With the current trend on using data mining to support the requirements engineering process, this task of understanding context for adaptive system at design time can benefit from such techniques as well. Objective: The objective is to provide a method to refine the specification of contextual variables and their relation to strategies for dependability. This refinement shall detect dependencies between such variables, priorities in monitoring them, and decide on their relevance in choosing the right strategy in a decision tree. Method: Our requirements-driven approach adopts the contextual goal modelling structure in addition to the operationalization values of sensed information to map contexts to the system’s behaviour. We propose a design time analysis process using a subset of data mining algorithms to extract a list of relevant contexts and their related variables, tasks, and/or goals. Results: We experimentally evaluated our proposal on a Body Sensor Network system (BSN), simulating 12 resources that could lead to a variability space of 4096 possible context conditions. Our approach was able to elicit subtle contexts that would significantly affect the service provided to assisted patients and relations between contexts, assisting the decision on their need, and priority in monitoring. Conclusion: The use of some data mining techniques can mitigate the lack of precise definition of contexts and their relation to system strategies for dependability. Our method is practical and supportive to traditional requirements specification methods, which typically require intense human intervention

    DREQUS: an approach for the Discovery of REQuirements Using Scenarios

    Get PDF
    ABSTRACT: Requirements engineering is recognized as a complex cognitive problem-solving process that takes place in an unstructured and poorly-understood problem context. Requirements elicitation is the activity generally regarded as the most crucial step in the requirements engineering process. The term “elicitation” is preferred to “capture”, to avoid the suggestion that requirements are out there to be collected. Information gathered during requirements elicitation often has to be interpreted, analyzed, modeled, and validated before the requirements engineer can feel confident that a complete set of requirements of a system have been obtained. Requirements elicitation comprises the set of activities that enable discovering, understanding, and documenting the goals and motives for building a proposed software system. It also involves identifying the requirements that the resulting system must satisfy in to achieve these goals. The requirements to be elicited may range from modifications to well-understood problems and systems (i.e. software upgrades), to hazy understandings of new problems being automated, to relatively unconstrained requirements that are open to innovation (e.g. mass-market software). Requirements elicitation remains problematic; missing or mistaken requirements still delay projects and cause cost overruns. No firm definition has matured for requirements elicitation in comparison to other areas of requirements engineering. This research is aimed to improve the results of the requirements elicitation process directly impacting the quality of the software products derived from them

    Identification of Software Features in Issue Tracking System Data

    Get PDF
    The knowledge of Software Features (SFs) is vital for software developers and requirements specialists during all software engineering phases: to understand and derive software requirements, to plan and prioritize implementation tasks, to update documentation, or to test whether the final product correctly implements the requested SF. In most software projects, SFs are managed in conjunction with other information such as bug reports, programming tasks, or refactoring tasks with the aid of Issue Tracking Systems (ITSs). Hence ITSs contains a variety of information that is only partly related to SFs. In practice, however, the usage of ITSs to store SFs comes with two major problems: (1) ITSs are neither designed nor used as documentation systems. Therefore, the data inside an ITS is often uncategorized and SF descriptions are concealed in rather lengthy. (2) Although an SF is often requested in a single sentence, related information can be scattered among many issues. E.g. implementation tasks related to an SF are often reported in additional issues. Hence, the detection of SFs in ITSs is complicated: a manual search for the SFs implies reading, understanding and exploiting the Natural Language (NL) in many issues in detail. This is cumbersome and labor intensive, especially if related information is spread over more than one issue. This thesis investigates whether SF detection can be supported automatically. First the problem is analyzed: (i) An empirical study shows that requests for important SFs reside in ITSs, making ITSs a good tar- get for SF detection. (ii) A second study identifies characteristics of the information and related NL in issues. These characteristics repre- sent opportunities as well as challenges for the automatic detection of SFs. Based on these problem studies, the Issue Tracking Software Feature Detection Method (ITSoFD), is proposed. The method has two main components and includes an approach to preprocess issues. Both components address one of the problems associated with storing SFs in ITSs. ITSoFD is validated in three solution studies: (I) An empirical study researches how NL that describes SFs can be detected with techniques from Natural Language Processing (NLP) and Machine Learning. Issues are parsed and different characteristics of the issue and its NL are extracted. These characteristics are used to clas- sify the issue’s content and identify SF description candidates, thereby approaching problem (1). (II) An empirical study researches how issues that carry information potentially related to an SF can be detected with techniques from NLP and Information Retrieval. Characteristics of the issue’s NL are utilized to create a traceability network vii of related issues, thereby approaching problem (2). (III) An empirical study researches how NL data in issues can be preprocessed using heuristics and hierarchical clustering. Code, stack traces, and other technical information is separated from NL. Heuristics are used to identify candidates for technical information and clustering improves the heuristic’s results. The technique can be applied to support components, I. and II

    A Requirements Measurement Program for Systems Engineering Projects: Metrics, Indicators, Models, and Tools for Internal Stakeholders

    Get PDF
    Software engineering (SE) measurement has shown to lead to improved quality and productivity in software and systems projects and, thus, has received significant attention in the literature, particularly for the design and development stages. In requirements engineering (RE), research and practice has recognized the importance of requirements measurement (RM) for tracking progress, identifying gaps in downstream deliverables related to requirements, managing requirements-related risks, reducing requirements errors and defects, and project management and decision making. However, despite the recognized benefits of RM, research indicates that only 5\% of the literature on SE measurement addresses requirements. This small percentage is reflected in the lack of well-defined and ready to use requirements metrics, approaches, tools, and frameworks that would enable the effective implementation and management of a RM program. Such a program would, in turn, provide the various internal stakeholders with various quantitative requirements-driven information (e.g., measures, indicators, and analytics, etc.) in order for them to better manage, control, and track their respective process activities. This shortage makes the process of RM, at best, complicated and, at worst, non-existent in most projects. The RM process is further complicated in large systems engineering projects due to large project sizes, numerous internal stakeholders, time pressure, large numbers of requirements, other software artifacts, to name a few. This integrated-article thesis aims to address the aforementioned problem through the following main contributions that have been researched and validated within the context of a large systems engineering project in the rail-automation domain: (i) an empirically derived and validated structured requirements metric suite; (ii) an approach for deriving and organizing requirements metrics and related information; (iii) a requirements-centric, measurement-based health assessment framework; (iv) a meta-model for managing requirements -driven information for internal stakeholders; (v) a prototype requirements dashboard that builds upon and automates the concepts in i, ii, iii, and iv. These contributions have implications for research on RM through extending the body of work on RM and promulgating further research. For practice, the results of this thesis are anticipated to facilitate the implementation and management of RM programs in real-world projects

    Agile Processes in Software Engineering and Extreme Programming: 18th International Conference, XP 2017, Cologne, Germany, May 22-26, 2017, Proceedings

    Get PDF
    agile software development; lean development; scrum; project management; software developmen

    Sustainability in design: now! Challenges and opportunities for design research, education and practice in the XXI century

    Get PDF
    Copyright @ 2010 Greenleaf PublicationsLeNS project funded by the Asia Link Programme, EuropeAid, European Commission

    Designing Debate: The Entanglement of Speculative Design and Upstream Engagement

    Get PDF
    This thesis offers a critical reflection of a design practice in which a speculative approach to design became entangled with upstream engagement with biotechnology research. Given that both practices claim to enable a public discussion about emergent technology, what is the nature of their mixing, and how should an analytical account of such a design practice be made? I start with separate reviews of the respective features of these two approaches, considering practitioner accounts and histories along with analytical literature where those practices are objects of research. Then I take the case of the public engagement project Material Beliefs to develop an empirical account of their confluence. Initially I discuss labs as sites where designers, scientists, and non-experts come together to discuss and to problematize accounts of biotechnology research. Next, I examine the process of making speculative designs, and here I emphasise the ways in which issues, materials and practices become compiled as exhibitable prototypes. Finally I consider the circulation and reception of these designs in public settings, including exhibitions, workshops, and online formats. I argue that speculative designs’ move on upstream PEST is an imbroglio that goes beyond mixing the formal features of practice, and requires a discussion concerning the actions of the designer in relation to a broader set of accountabilities. Authorship of the processes that lead to design outcomes, the description of design outcomes, and the effects of those outcomes become distributed and negotiated by an extended set of commitments coming from researchers, policymakers, educators, curators and promoters. Ultimately, I contend that this mixing provides an opportunity to foster a reflexive and empirical account of speculative practice, to engage in analysis of the organisations and settings that support a speculative approach, and to provide a critique of upstream engagement
    corecore