Search: onr:"swepub:oai:DiVA.org:bth-22551" >
How Do Practitioner...
How Do Practitioners Interpret Conditionals in Requirements?
-
- Fischbach, Jannik (author)
- Qualicen GmbH, DEU
-
- Frattini, Julian, 1995- (author)
- Blekinge Tekniska Högskola,Institutionen för programvaruteknik
-
- Mendez, Daniel (author)
- Blekinge Tekniska Högskola,Institutionen för programvaruteknik
-
show more...
-
- Unterkalmsteiner, Michael (author)
- Blekinge Tekniska Högskola,Institutionen för programvaruteknik
-
- Femmer, Henning (author)
- Qualicen GmbH, DEU
-
- Vogelsang, Andreas (author)
- University of Cologne, DEU
-
show less...
-
(creator_code:org_t)
- 2021-11-23
- 2021
- English.
-
In: Lecture Notes in Computer Science. - Cham : Springer Science and Business Media Deutschland GmbH. - 9783030914516 ; , s. 85-102
- Related links:
-
https://arxiv.org/ab...
-
show more...
-
http://arxiv.org/pdf...
-
https://urn.kb.se/re...
-
https://doi.org/10.1...
-
show less...
Abstract
Subject headings
Close
- Context: Conditional statements like “If A and B then C” are core elements for describing software requirements. However, there are many ways to express such conditionals in natural language and also many ways how they can be interpreted. We hypothesize that conditional statements in requirements are a source of ambiguity, potentially affecting downstream activities such as test case generation negatively. Objective: Our goal is to understand how specific conditionals are interpreted by readers who work with requirements. Method: We conduct a descriptive survey with 104 RE practitioners and ask how they interpret 12 different conditional clauses. We map their interpretations to logical formulas written in Propositional (Temporal) Logic and discuss the implications. Results: The conditionals in our tested requirements were interpreted ambiguously. We found that practitioners disagree on whether an antecedent is only sufficient or also necessary for the consequent. Interestingly, the disagreement persists even when the system behavior is known to the practitioners. We also found that certain cue phrases are associated with specific interpretations. Conclusion: Conditionals in requirements are a source of ambiguity and there is not just one way to interpret them formally. This affects any analysis that builds upon formalized requirements (e.g., inconsistency checking, test-case generation). Our results may also influence guidelines for writing requirements. © 2021, Springer Nature Switzerland AG.
Subject headings
- NATURVETENSKAP -- Data- och informationsvetenskap -- Datavetenskap (hsv//swe)
- NATURAL SCIENCES -- Computer and Information Sciences -- Computer Sciences (hsv//eng)
- NATURVETENSKAP -- Data- och informationsvetenskap -- Programvaruteknik (hsv//swe)
- NATURAL SCIENCES -- Computer and Information Sciences -- Software Engineering (hsv//eng)
Keyword
- Descriptive survey
- Formalization
- Logical interpretation
- Requirements engineering
- C (programming language)
- Surveys
- Core elements
- Down-stream
- Formalisation
- Logical formulas
- Natural languages
- Requirement engineering
- Software requirements
- Test case generation
Publication and Content Type
- ref (subject category)
- kon (subject category)
Find in a library
To the university's database