152 research outputs found
An Empirical Study on Decision making for Quality Requirements
[Context] Quality requirements are important for product success yet often
handled poorly. The problems with scope decision lead to delayed handling and
an unbalanced scope. [Objective] This study characterizes the scope decision
process to understand influencing factors and properties affecting the scope
decision of quality requirements. [Method] We studied one company's scope
decision process over a period of five years. We analyzed the decisions
artifacts and interviewed experienced engineers involved in the scope decision
process. [Results] Features addressing quality aspects explicitly are a minor
part (4.41%) of all features handled. The phase of the product line seems to
influence the prevalence and acceptance rate of quality features. Lastly,
relying on external stakeholders and upfront analysis seems to lead to long
lead-times and an insufficient quality requirements scope. [Conclusions] There
is a need to make quality mode explicit in the scope decision process. We
propose a scope decision process at a strategic level and a tactical level. The
former to address long-term planning and the latter to cater for a speedy
process. Furthermore, we believe it is key to balance the stakeholder input
with feedback from usage and market in a more direct way than through a long
plan-driven process
Requirements Quality Assurance in Industry: Why, What and How?
Context and Motivation: Natural language is the most common form to specify
requirements in industry. The quality of the specification depends on the
capability of the writer to formulate requirements aimed at different
stakeholders: they are an expression of the customer's needs that are used by
analysts, designers and testers. Given this central role of requirements as a
mean to communicate intention, assuring their quality is essential to reduce
misunderstandings that lead to potential waste. Problem: Quality assurance of
requirement specifications is largely a manual effort that requires expertise
and domain knowledge. However, this demanding cognitive process is also
congested by trivial quality issues that should not occur in the first place.
Principal ideas: We propose a taxonomy of requirements quality assurance
complexity that characterizes cognitive load of verifying a quality aspect from
the human perspective, and automation complexity and accuracy from the machine
perspective. Contribution: Once this taxonomy is realized and validated, it can
serve as the basis for a decision framework of automated requirements quality
assurance support.Comment: Conference proceedings of Requirements Engineering: Foundation for
Software Quality (REFSQ) 2017: 77-8
Process Improvement Archaeology: What Led Us Here, and What's Next?
While in every organization corporate culture and history change over time,
intentional efforts to identify performance problems are of particular interest
when trying to understand the current state of an organization. The results of
past improvement initiatives can shed light on the evolution of an organization
and represent, with the advantage of perfect hindsight, a learning opportunity
for future process improvements. The opportunity to test this premise occurred
in an applied research collaboration with the Swedish Transport Administration,
the government agency responsible for the planning, implementation, and
maintenance of long-term rail, road, shipping, and aviation infrastructure in
Sweden. This article is part of a theme issue on Process Improvement
Software Engineering Knowledge Areas in Startup Companies: A Mapping Study
Background - Startup companies are becoming important suppliers of innovative
and software intensive products. The failure rate among startups is high due to
lack of resources, immaturity, multiple influences and dynamic technologies.
However, software product engineering is the core activity in startups,
therefore inadequacies in applied engineering practices might be a significant
contributing factor for high failure rates. Aim - This study identifies and
categorizes software engineering knowledge areas utilized in startups to map
out the state-of-art, identifying gaps for further research. Method - We
perform a systematic literature mapping study, applying snowball sampling to
identify relevant primary studies. Results - We have identified 54 practices
from 14 studies. Although 11 of 15 main knowledge areas from SWEBOK are
covered, a large part of categories is not. Conclusions - Existing research
does not provide reliable support for software engineering in any phase of a
startup life cycle. Transfer of results to other startups is difficult due to
low rigor in current studies.Comment: Proceedings 6th International Conference on Software Business (ICSOB
2015), Braga, Portugal, 245-25
A Taxonomy for Requirements Engineering and Software Test Alignment
Requirements Engineering and Software Testing are mature areas and have seen
a lot of research. Nevertheless, their interactions have been sparsely explored
beyond the concept of traceability. To fill this gap, we propose a definition
of requirements engineering and software test (REST) alignment, a taxonomy that
characterizes the methods linking the respective areas, and a process to assess
alignment. The taxonomy can support researchers to identify new opportunities
for investigation, as well as practitioners to compare alignment methods and
evaluate alignment, or lack thereof. We constructed the REST taxonomy by
analyzing alignment methods published in literature, iteratively validating the
emerging dimensions. The resulting concept of an information dyad characterizes
the exchange of information required for any alignment to take place. We
demonstrate use of the taxonomy by applying it on five in-depth cases and
illustrate angles of analysis on a set of thirteen alignment methods. In
addition, we developed an assessment framework (REST-bench), applied it in an
industrial assessment, and showed that it, with a low effort, can identify
opportunities to improve REST alignment. Although we expect that the taxonomy
can be further refined, we believe that the information dyad is a valid and
useful construct to understand alignment
Which Requirements Artifact Quality Defects are Automatically Detectable? A Case Study
[Context] The quality of requirements engineering artifacts, e.g.
requirements specifications, is acknowledged to be an important success factor
for projects. Therefore, many companies spend significant amounts of money to
control the quality of their RE artifacts. To reduce spending and improve the
RE artifact quality, methods were proposed that combine manual quality control,
i.e. reviews, with automated approaches. [Problem] So far, we have seen various
approaches to automatically detect certain aspects in RE artifacts. However, we
still lack an overview what can and cannot be automatically detected.
[Approach] Starting from an industry guideline for RE artifacts, we classify
166 existing rules for RE artifacts along various categories to discuss the
share and the characteristics of those rules that can be automated. For those
rules, that cannot be automated, we discuss the main reasons. [Contribution] We
estimate that 53% of the 166 rules can be checked automatically either
perfectly or with a good heuristic. Most rules need only simple techniques for
checking. The main reason why some rules resist automation is due to imprecise
definition. [Impact] By giving first estimates and analyses of automatically
detectable and not automatically detectable rule violations, we aim to provide
an overview of the potential of automated methods in requirements quality
control.Comment: 2017 25th International Requirements Engineering Conference Workshops
(REW) (pp. 400-406
Connecting the Dots of Knowledge in Agile Software Development
This article discusses the importance of managing knowledge as a resource due
to its great potential to create economic value. We detail the types of
knowledge resources, the challenges associated with their management, and
potential solutions to maximise their utility. Our contribution is based on
empirical studies performed in an industry context.Comment: 8 page
On the requirements engineer role
The requirements engineer role is defined differently within most organizations.This work gas been partially supported by the GENESIS project, TIN2016-79269-R. Tony Gorschek’s work has been supported by KKS Funded Software Engineering ReThought (SERT) Research Profile @ SERL-SWEDEN, BTH.Peer ReviewedPostprint (author's final draft
On Understanding the Relation of Knowledge and Confidence to Requirements Quality
Context and Motivation: Software requirements are affected by the knowledge
and confidence of software engineers. Analyzing the interrelated impact of
these factors is difficult because of the challenges of assessing knowledge and
confidence.
Question/Problem: This research aims to draw attention to the need for
considering the interrelated effects of confidence and knowledge on
requirements quality, which has not been addressed by previous publications.
Principal ideas/results: For this purpose, the following steps have been
taken: 1) requirements quality was defined based on the instructions provided
by the ISO29148:2011 standard, 2) we selected the symptoms of low qualified
requirements based on ISO29148:2011, 3) we analyzed five Software Requirements
Specification (SRS) documents to find these symptoms, 3) people who have
prepared the documents were categorized in four classes to specify the
more/less knowledge and confidence they have regarding the symptoms, and 4)
finally, the relation of lack of enough knowledge and confidence to symptoms of
low quality was investigated. The results revealed that the simultaneous
deficiency of confidence and knowledge has more negative effects in comparison
with a deficiency of knowledge or confidence.
Contribution: In brief, this study has achieved these results: 1) the
realization that a combined lack of knowledge and confidence has a larger
effect on requirements quality than only one of the two factors, 2) the
relation between low qualified requirements and requirements engineers' needs
for knowledge and confidence, and 3) variety of requirements engineers' needs
for knowledge based on their abilities to make discriminative and consistent
decisions.Comment: Preprint accepted for publication at the 27th International Working
Conference on Requirement Engineering: Foundation for Software Qualit
- …