An industry-academia, multidisciplinary and expertise-heterogeneous design approach: a case study on designing for mobility

Trabalho apresentado na: "DIGICOM 2021 – 5th International Conference on Design and Digital Communication", 4-6 November 2021, Teatro Gil Vicente, Barcelos, Portugal.The purpose of this article is to provide a better understanding of how to effectively develop design projects that simultaneously leverage industry and academic partners, participants from various disciplinary backgrounds, and vari- ous levels of expertise to solve complex problems. The article reports a single case of an ongoing project focused on designing smart and connected devices for mobility, which integrates the dimensions of interest. Our findings highlight the importance of careful planning of the collaborative process, contemplating of- fline and real-time communication opportunities, identifying cross-boundary roles, and considering the development of shared expertise and knowledge within the team. By confronting these findings with key literature, we offer five recom- mendations to inform similar future projects.This work is supported by European Structural and Investment Funds in the FEDER component, through the Operational Competitiveness and Internationalization Pro- gramme (COMPETE 2020) [Project no 039334; Funding Reference: POCI-01-0247- FEDER-039334]. This work has additional financial support from Project Lab2PT - Landscapes, Heritage and Territory laboratory - AUR/04509, with financial support from FCT/MCTES through national funds (PIDDAC) and co-financing from the Eu- ropean Regional Development Fund (FEDER) POCI-01-0145-FEDER-007528, in line with the new partnership agreement PT2020 through COMPETE 2020 – Compet- itiveness and Internationalization Operational Program (POCI)

Improving the Requirements Engineering Process: a process oriented approach

The Requirements Engineering (RE) process plays an important role in the software development process. In order to produce quality software greater attention must be given to the improvement of RE process. In this paper five key process areas (KPAs) have been identified from the research literature in order to improve the RE process. Firstly to support a goal-based approach in the RE process; secondly to support the incremental and cyclical behaviours in the RE process; thirdly to encourage stakeholders involvement in the RE process; fourthly, to support the management of RE process and fifthly to define a planning phase for the RE process. This research project aims to show that better results will follow when the RE process supports these five KPAs. To address these KPAs, a requirement elicitation, analysis and validation method (REAVM) is proposed. A case study has been conducted in order to test and evaluate the REAVM in the real world environment

Requirements engineering current practice and capability in small and medium software development enterprises in New Zealand

This paper presents research on current industry practices with respect to requirements engineering as implemented within software development companies in New Zealand. A survey instrument is designed and deployed. The results are analysed and compared against what is internationally considered "best practice" and previous New Zealand and Australian studies. An attempt is made to assess the requirements engineering capability of New Zealand companies using both formal and informal frameworks.Comment: Proceedings of the 9th ACIS Conference on Software Engineering Research, Management & Applications (SERA 2011

Industry-academia collaborations in software testing: experience and success stories from Canada and Turkey : Special Issue Industry Academia Collaborations in Software Testing

Collaboration between industry and academia supports improvement and innovation in industry and helps to ensure industrial relevance in academic research. However, many researchers and practitioners believe that the level of joint industry–academia collaborations (IAC) in software engineering (SE) is still relatively very low, compared to the amount of activity in each of the two communities. The goal of the empirical study reported in this paper is to characterize a set of collaborative industry–academia R&D projects in the area of software testing conducted by the authors (based in Canada and Turkey) with respect to a set of challenges, patterns and anti-patterns identified by a recent Systematic Literature Review study, with the aim of contributing to the body of evidence in the area of IAC, for the benefit of SE researchers and practitioners in conducting successful IAC projects in software testing and in software engineering in general. To address the above goal, a pool of ten IAC projects (six completed, two failed and two ongoing) all in the area of software testing, which the authors have led or have had active roles in, were selected as objects of study and were analyzed (both quantitatively and qualitatively) with respect to the set of selected challenges, patterns and anti-patterns. As outputs, the study presents a set of empirical findings and evidence-based recommendations, e.g.: it has been observed that even if an IAC project may seem perfect from many aspects, one single major challenge (e.g., disagreement in confidentiality agreements) can lead to its failure. Thus, we recommend that both parties (academics and practitioners) consider all the challenges early on and proactively work together to eliminate the risk of challenges in IAC projects. We furthermore report correlation and interrelationship of challenges, patterns and anti-patterns with project success measures. This study hopes to encourage and benefit other SE researchers and practitioners in conducting successful IAC projects in software testing and in software engineering in general in the future

Requirement Culture at a Large Scale Medical Device Developer: A Case Study

This case study explores requirements evolution of a multimillion-dollar medical device under development for cancer therapy. The study focuses on the analysis of requirements across a twelve month window via interviews with involved parties and document analysis of the company\u27s design requirements. Three engineering directors (mechanical, software, and systems) were interviewed contemporaneously with the analysis of eight revisions to the design functional specifications, consisting of over 1,000 total design requirements. Significant requirement change was observed and associated with 1) change in requirements leadership, 2) market strategy including scope towards regulatory approval, and 3) requirement learning curve with respect to writing testable requirements. From analysis of the interview transcripts and company requirement evolution, a requirements culture emerged highlighting a need for greater understanding of company requirements cultures in situ. Further, analysis of the company\u27s biomedical requirement behavior align with those found in the avionics and automobile industries suggesting requirements evolution, and therefore problem understanding, occur similarly irrespective of domain or problem size

Introducing requirements engineering into product development : towards systematic user requirements definition

Without knowing the requirements of customers and users, it is difficult to build the right product. Although requirements engineering (RE) is considered a critical activity in product development, the state of RE practices seems to be immature in many organizations. For several years, researchers have tried to understand why so many companies have informal RE processes and why it is so difficult to introduce RE technology into mainstream practice. This thesis investigates how RE can be introduced into organizations that develop market-driven products. The results are based on the experiences gathered from four Finnish organizations that considered it essential to improve their product development processes by investing in RE. To gain a deep understanding of RE process improvement in real product development contexts, we conducted four longitudinal case studies using an action research approach. One of our main findings is that introducing RE into product development appears to involve a cultural change. By this we mean that development personnel need to adopt a new way of thinking and working when defining requirements systematically from the customers' and users' points of view. Furthermore, this cultural change involves such human factors as beliefs, attitudes, motivation, and commitment of development engineers and managers. One way of supporting the cultural change is to define a simple RE process model that links business goals to technical requirements via user needs and user requirements. The purpose of the process model is to give an overview of RE, support communication by providing common terminology, and emphasize the importance of systematic user requirements definition. On the basis of the lessons learned from the four case studies, we also recommend a set of RE practices that support the systematic definition of user requirements. Furthermore, the thesis provides a model of factors that affect organization-wide implementation of RE practices and describes challenges organizations may face when introducing RE into product development. The main conclusion drawn from this work is that changing the perspective from technical requirements to user requirements can be difficult for product development personnel. Furthermore, it can take several years for the cultural change towards systematic user requirements definition to spread throughout the whole product development organization. However, the experiences from the case studies show that the organization-wide adoption of RE practices can be enhanced by offering Just-in-Time training and an RE expert's assistance for development teams when they are defining user requirements for the first time.reviewe

Aus Fehlern in der Softwareentwicklung lernen. Wie durch Fehleranalysen die Prozesse der Anforderungsanalyse und der Qualitätssicherung verbessert werden können

Softwarefehler existieren, seit Menschen Software entwickeln. Fehler können mitunter zu erheblichen wirtschaftlichen Verlusten und im schlimmsten Fall zum Verlust von Leben führen. Viele Fehler können auf Mängel im Prozess der Anforderungsanalyse zurückgeführt werden. Je später ein Anforderungsfehler entdeckt und behoben wird, desto aufwändiger wird die Korrektur. Die vorliegende Arbeit beschreibt, wie aus Fehlern in der Softwareentwicklung gelernt werden kann. Sie beschreibt ein Verfahren zu Fehleranalyse, auf dessen Basis insbesondere Prozesse der Anforderungsanalyse und der Qualitätssicherung verbessert werden können. Ziel der Verbesserungen ist es, Anforderungsfehler und mögliche Folgefehler im Entwurf und der Implementierung zu vermeiden oder zumindest früher zu finden. In dieser Arbeit wird zunächst ein Modell hergeleitet, das erklärt, warum Anforderungsfehler entstehen. Für bestimmte Typen von Anforderungsfehlern werden auf der Grundlage empirische Befunde konkrete Ursachen im Prozess der Anforderungsanalyse aufgezeigt. Dieses Erklärungsmodell ist Bestandteil eines Verfahrens zur Fehleranalyse, das den Anspruch erhebt, über die Auswertung von Fehlern Rückschlüsse über mögliche Ursachen im Prozess zu ziehen. Das Verfahren ist eine Weiterentwicklung der Orthogonal Defect Classification, kurz ODC. ODC wird in der Arbeit ausführlich dargestellt und auf der Grundlage empirischer Befunde kritisch gewürdigt. Das weiterentwickelte Verfahren zur Fehleranalyse wurde im Rahmen einer einjährigen Fallstudie bei dem IT-Dienstleister einer großen deutschen Versicherung erfolgreich angewandt. Hierbei wurden nachträglich reale Fehler von zwei Softwareentwicklungsprojekten einer geschäftskritischen Anwendungssoftware klassifiziert und analysiert, um Verbesserungspotenziale zu identifizieren. Das in der Arbeit entwickelte Verfahren zur Fehleranalyse leistet einen unmittelbaren Beitrag zur Lösung des aufgezeigten Praxisproblems: sie ist ein Instrument, um Prozessmängel der Anforderungsanalyse zu identifizieren, die systematisch Anforderungsfehler und Folgefehler verursachen