Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userHigh-Level Requirements Management and Complexity Costs in Automotive Development Projects: A Problem Statement
312
0
0.0
(
0
)
Added by
Bernhard Rumpe
Publication date
2014
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
Effective requirements management plays an important role when it comes to the support of product development teams in the automotive industry. A precise positioning of new cars in the market is based on features and characteristics described as requirements as well as on costs and profits. [Question/problem] However, introducing or changing requirements does not only impact the product and its parts, but may lead to overhead costs in the OEM due to increased complexity. The raised overhead costs may well exceed expected gains or costs from the changed requirements. [Principal ideas/results] By connecting requirements with direct and overhead costs, decision making based on requirements could become more valuable. [Contribution] This problem statement results from a detailed examination of the effects of requirements management practices on process complexity and vice versa as well as on how todays requirements management tools assist in this respect. We present findings from a joined research project of RWTH Aachen University and Volkswagen
rate research
Read More
Agile processes are now widely practiced by software engineering (SE) teams, and the agile manifesto claims that agile methods support responding to changes well. However, no study appears to have researched whether this is accurate in reality. Requirements changes (RCs) are inevitable in any software development environment, and we wanted to acquire a holistic picture of how RCs occur and are handled in agile SE teams in practice. We also wanted to know whether responding to changes is the only or a main reason for software teams to use agile in their projects. To do this we conducted a mixed-methods research study which comprised of interviews of 10 agile practitioners from New Zealand and Australia, a literature review, and an in-depth survey with the participation of 40 agile practitioners world-wide. Through this study we identified different types of RCs, their origination including reasons for origination, forms, sources, carriers, and events at which they originate, challenging nature, and finally whether agile helps to respond to changes or not. We also found that agile teams seem to be reluctant to accept RCs, and therefore, they use several mitigation strategies. Additionally, as they accept the RCs, they use a variety of techniques to handle them. Furthermore, we found that agile allowing better response to RCs is only a minor reason for practicing agile. Several more important reasons included being able to deliver the product in a shorter period and increasing team productivity. Practitioners stated this improves the agile team environment and thus are the real motivators for teams to practice agile. Finally, we provide a set of practical recommendations that can be used to better handle RCs effectively in agile software development environments.
[Context & motivation] Driven by the need for faster time-to-market and reduced development lead-time, large-scale systems engineering companies are adopting agile methods in their organizations. This agile transformation is challenging and it is common that adoption starts bottom-up with agile software teams within the context of traditional company structures. [Question/Problem] This creates the challenge of agile teams working within a document-centric and plan-driven (or waterfall) environment. While it may be desirable to take the best of both worlds, it is not clear how that can be achieved especially with respect to managing requirements in large-scale systems. [Principal ideas/Results] This paper presents an exploratory case study at an automotive company, focusing on two departments of a large-scale systems company that is in the process of company-wide agile adoption. [Contribution] We present challenges related to requirements engineering that agile teams face while working within a larger plan-driven context and propose potential strategies to mitigate the challenges. Challenges relate to, e.g., development teams not being aware of the high-level requirement and dealing with flexibility of writing user stories. We found that strategies for overcoming most of these challenges are still lacking and thus call for more research.
In their seminal paper in the ACM Transactions on Software Engineering and Methodology, Zave and Jackson established a core ontology for Requirements Engineering (RE) and used it to formulate the requirements problem, thereby defining what it means to successfully complete RE. Given that stakeholders of the system-to-be communicate the information needed to perform RE, we show that Zave and Jacksons ontology is incomplete. It does not cover all types of basic concerns that the stakeholders communicate. These include beliefs, desires, intentions, and attitudes. In response, we propose a core ontology that covers these concerns and is grounded in sound conceptual foundations resting on a foundational ontology. The new core ontology for RE leads to a new formulation of the requirements problem that extends Zave and Jacksons formulation. We thereby establish new standards for what minimum information should be represented in RE languages and new criteria for determining whether RE has been successfully completed.
Context: Technical Debt requirements are related to the distance between the ideal value of the specification and the systems actual implementation, which are consequences of strategic decisions for immediate gains, or unintended changes in context. To ensure the evolution of the software, it is necessary to keep it managed. Identification and measurement are the first two stages of the management process; however, they are little explored in academic research in requirements engineering. Objective: We aimed at investigating which evidence helps to strengthen the process of TD requirements management, including identification and measurement. Method: We conducted a Systematic Literature Review through manual and automatic searches considering 7499 studies from 2010 to 2020, and including 61 primary studies. Results: We identified some causes related to Technical Debt requirements, existing strategies to help in the identification and measurement, and metrics to support the measurement stage. Conclusion: Studies on TD requirements are still preliminary, especially on management tools. Yet, not enough attention is given to interpersonal issues, which are difficulties encountered when performing such activities, and therefore also require research. Finally, the provision of metrics to help measure TD is part of this works contribution, providing insights into the application in the requirements context.
In industrial model-based development (MBD) frameworks, requirements are typically specified informally using textual descriptions. To enable the application of formal methods, these specifications need to be formalized in the input languages of all formal tools that should be applied to analyse the models at different development levels. In this paper we propose a unified approach for the computer-assisted formal specification of requirements and their fully automated translation into the specification languages of different verification tools. We consider a two-stage MBD scenario where first Simulink models are developed from which executable code is generated automatically. We (i) propose a specification language and a prototypical tool for the formal but still textual specification of requirements, (ii) show how these requirements can be translated automatically into the input languages of Simulink Design Verifier for verification of Simulink models and BTC EmbeddedValidator for source code verification, and (iii) show how our unified framework enables besides automated formal verification also the automated generation of test cases.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
