272,317 research outputs found
Requirements Prioritization Based on Benefit and Cost Prediction: A Method Classification Framework
In early phases of the software development process, requirements prioritization necessarily relies on the specified requirements and on predictions of benefit and cost of individual requirements. This paper induces a conceptual model of requirements prioritization based on benefit and cost. For this purpose, it uses Grounded Theory. We provide a detailed account of the procedures and rationale of (i) how we obtained our results and (ii) how we used them to form the basis for a framework for classifying requirements prioritization methods
What Works Better? A Study of Classifying Requirements
Classifying requirements into functional requirements (FR) and non-functional
ones (NFR) is an important task in requirements engineering. However, automated
classification of requirements written in natural language is not
straightforward, due to the variability of natural language and the absence of
a controlled vocabulary. This paper investigates how automated classification
of requirements into FR and NFR can be improved and how well several machine
learning approaches work in this context. We contribute an approach for
preprocessing requirements that standardizes and normalizes requirements before
applying classification algorithms. Further, we report on how well several
existing machine learning methods perform for automated classification of NFRs
into sub-categories such as usability, availability, or performance. Our study
is performed on 625 requirements provided by the OpenScience tera-PROMISE
repository. We found that our preprocessing improved the performance of an
existing classification method. We further found significant differences in the
performance of approaches such as Latent Dirichlet Allocation, Biterm Topic
Modeling, or Naive Bayes for the sub-classification of NFRs.Comment: 7 pages, the 25th IEEE International Conference on Requirements
Engineering (RE'17
How do software architects consider non-functional requirements: an exploratory study
© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft
Boundary Objects and their Use in Agile Systems Engineering
Agile methods are increasingly introduced in automotive companies in the
attempt to become more efficient and flexible in the system development. The
adoption of agile practices influences communication between stakeholders, but
also makes companies rethink the management of artifacts and documentation like
requirements, safety compliance documents, and architecture models.
Practitioners aim to reduce irrelevant documentation, but face a lack of
guidance to determine what artifacts are needed and how they should be managed.
This paper presents artifacts, challenges, guidelines, and practices for the
continuous management of systems engineering artifacts in automotive based on a
theoretical and empirical understanding of the topic. In collaboration with 53
practitioners from six automotive companies, we conducted a design-science
study involving interviews, a questionnaire, focus groups, and practical data
analysis of a systems engineering tool. The guidelines suggest the distinction
between artifacts that are shared among different actors in a company (boundary
objects) and those that are used within a team (locally relevant artifacts). We
propose an analysis approach to identify boundary objects and three practices
to manage systems engineering artifacts in industry
- …