Incomplete Software Requirements and Assumptions Made by Software Engineers

Albayrak, Özlem; Kurtoglu, Hülya; Biçakçi, Mert

doi:10.1109/apsec.2009.39

Cited by 14 publications

(9 citation statements)

References 31 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Developers working on complex embedded systems are consciously and unconsciously making assumptions early in the project about properties and behavior of other components in the system [1,17,21]. For example, a developer might make the implicit assumption that the velocity signal from one component is supposed to be in km/h, but it is in fact provided as m/s.…”

Section: Introductionmentioning

confidence: 99%

Agile Model-Driven Engineering in Mechatronic Systems - An Industrial Case Study

Eliasson

Heldal

Lantz

et al. 2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Model-driven engineering focuses on structuring systems as well as permitting domain experts to be directly involved in the software development. Agile methods aim for fast feedback and providing crucial knowledge early in the project. In our study, we have seen a successful combination of MDE and agile methods to support the development of complex, software-driven mechatronic systems. We have investigated how combining MDE and agile methods can reduce the number of issues caused by erroneous assumptions in the software of these mechatronic systems. Our results show that plant models to simulate mechanical systems are needed to enable agile MDE during the mechatronic development. They enable developers to run, verify, and validate models before the mechanical systems are delivered from suppliers. While two case studies conducted at Volvo Car Group confirm that combining MDE and agile works, there are still challenges e.g. how to optimize the development of plant models.

show abstract

Section: Introductionmentioning

confidence: 99%

Agile Model-Driven Engineering in Mechatronic Systems - An Industrial Case Study

Eliasson

Heldal

Lantz

et al. 2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…As mentioned earlier, the phenomenon of confirmation bias with complete specifications may not have a deleterious impact. Yet, it may become problematic due to the prevalence of incomplete requirements specifications in the SE industry that fail to elicit every functionality, especially for large and complex systems (Albayrak et al 2009;Paetsch et al 2003). Software testers design test cases based on their understanding of (often incomplete) requirements specifications, which may lead to the incomplete coverage of exceptional cases: inconsistent test cases.…”

Section: Discussionmentioning

confidence: 99%

“…If we relate the completeness of our object's (MusicFone) specifications to the Leventhal et al's (1994), it is closer to a positive only specification document. We cannot classify MusicFone into the third category because the specifications stated the required behaviours but contained less information on handling the non-required behaviour of the application, thus qualifying our object as having a realistic level of specifications (Davis et al 1993;Albayrak et al 2009).…”

Section: Experimental Objectmentioning

confidence: 99%

A controlled experiment on time pressure and confirmation bias in functional software testing

2018

View full text Add to dashboard Cite

Context Confirmation bias is a person's tendency to look for evidence that strengthens his/her prior beliefs rather than refutes them. Manifestation of confirmation bias in software testing may have adverse effects on software quality. Psychology research suggests that time pressure could trigger confirmation bias. Objective In the software industry, this phenomenon may deteriorate software quality. In this study, we investigate whether testers manifest confirmation bias and how it is affected by time pressure in functional software testing. Method We performed a controlled experiment with 42 graduate students to assess manifestation of confirmation bias in terms of the conformity of their designed test cases to the provided requirements specification. We employed a one factor with two treatments between-subjects experimental design. Results We observed, overall, participants designed significantly more confirmatory test cases as compared to disconfirmatory ones, which is in line with previous research. However, we did not observe time pressure as an antecedent to an increased rate of confirmatory testing behaviour. Conclusion People tend to design confirmatory test cases regardless of time pressure. For practice, we find it necessary that testers develop self-awareness of confirmation bias and counter its potential adverse effects with a disconfirmatory attitude. We recommend further replications to investigate the effect of time pressure as a potential contributor to the manifestation of confirmation bias.

show abstract

“…Ambiguity, vagueness and contradicting information can further be misleading. Developers, often, tend to make assumption for such missing or contradicting information at the time of development as reported in [10]. Such knowledge has been referred to as implicit or tacit knowledge [11] in requirements study.…”

Section: B Business Rules and Requirementsmentioning

confidence: 98%

Automated identification of business rules in requirements documents

Sharma

Bhatia

Biswas

2014

2014 IEEE International Advance Computing Conference (IACC)

View full text Add to dashboard Cite

Business Rule identification is an important task of Requirements Engineering process. However, the task is challenging as business rules are often not explicitly stated in the requirements documents. In case business rules are explicit, they may not be atomic in nature or, may be vague. In this paper, we present an approach for identifying business rules in the available requirements documentation. We first identify various business rules categories and, then examine requirements documentation (including requirements specifications, domain knowledge documents, change request, request for proposal) for the presence of these rules. Our study aims at finding how effectively business rules can be identified and classified into one of the categories of business rules using machine learning algorithms. We report on the results of the experiments performed. Our observations indicate that in terms of overall result, support vector machine algorithm performed better than other classifiers. Random Forest algorithm had a higher precision than support vector machine algorithm but relatively low recall. Naïve Bayes algorithm had a higher recall than support vector machine. We also report on evaluation study of our requirements corpus using stop-words and stemming the requirements statements.

show abstract

Incomplete Software Requirements and Assumptions Made by Software Engineers

Cited by 14 publications

References 31 publications

Agile Model-Driven Engineering in Mechatronic Systems - An Industrial Case Study

Agile Model-Driven Engineering in Mechatronic Systems - An Industrial Case Study

A controlled experiment on time pressure and confirmation bias in functional software testing

Automated identification of business rules in requirements documents

Contact Info

Product

Resources

About