Industry needs and research directions in requirements engineering for embedded systems

Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus

doi:10.1007/s00766-011-0144-x

Cited by 75 publications

(44 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…In addition, Uusitalo et al (2008) found that poor quality of requirements was a hindrance to maintaining traces from test cases. Sikora et al (2012) found that requirements reviews is the dominant practice applied to address quality assurance of the requirements for embedded systems and that industry need additional and improved techniques for achieving good requirements quality. Furthermore, requirements quality is related to involving, not only requirements engineers in the requirements engineering, but also VV roles in early stages.…”

Section: Discussionmentioning

confidence: 99%

Challenges and practices in aligning requirements with verification and validation: a case study of six companies

et al. 2013

View full text Add to dashboard Cite

Weak alignment of requirements engineering (RE) with verification and validation(VV) may lead to problems in delivering the required products in time with the right quality. For example, weak communication of requirements changes to testers may result in lack of verification of new requirements and incorrect verification of old invalid requirements, leading to software quality problems, wasted effort and delays. However, despite the serious implications of weak alignment research and practice both tend to focus on one or the other of RE or VV rather than on the alignment of the two. We have performed a multi-unit case study to gain insight into issues around aligning RE and VV by interviewing 30 practitioners from 6 software developing companies, involving 10 researchers in a flexible research process for case studies. The results describe current industry challenges and practices in aligning RE with VV, ranging from quality of the individual RE and VV activities, through tracing and tools, to change control and sharing a common understanding at strategy, goal and design level. The study identified that human aspects are central, i.e. cooperation and communication, and that requirements engineering practices are a critical basis for alignment. Further, the size of an organisation and its motivation for applying alignment practices, e.g. external enforcement of traceability, are variation factors that play a key role in achieving alignment. Our results provide a strategic roadmap for practitioners improvement work to address alignment challenges. Furthermore, the study provides a foundation for continued research to improve the alignment of RE with VV.

show abstract

Section: Discussionmentioning

confidence: 99%

Challenges and practices in aligning requirements with verification and validation: a case study of six companies

et al. 2013

View full text Add to dashboard Cite

show abstract

“…how a complex situation can benefit from cues, indicating the state of the system, or suggestions towards the recommended action. The requirement engineers are trying to address complexity, with a problem being the management of the implementation of a large or otherwise complex embedded system (Sikora, Tenbergen & Pohl, 2012). In our opinion, both Norman and Sikora essentially describe the need for understanding and managing the information, where the focus is on how that information is represented.…”

Section: On Complexitymentioning

confidence: 99%

On The Teachers Role in Interactive Prototyping

Mikkonen

2017

The Design Journal

View full text Add to dashboard Cite

Abstract:The industrial design students are increasingly involved with the development of functional interactable prototypes. There is complexity in both the concept generation and the implementation, something that the design students need to be able to cope with. We approach the prototyping in the light of representing a design idea, moving from concept towards a physical manifestation, and discuss the concept-imposed minimum towards the complexity of a prototype. While a combination of methods, such as cardboard-mockups, and wizard-of-oz can be used to evaluate simpler design ideas, they simply fall short with a complex device, as there are too many things happening. Thus, an approach is needed for developing complex prototypes. We examine five different prototypes, and discuss the role of the teacher in each. Drawing from the concept, prototyping practice, and the required complexity, we suggest stages of complexity for the development, and a more active participation from the teacher.

show abstract

“…Related work has shown the need for a continuous systems engineering environment, where referring or constitutive documents are essential to work on complex software systems [4]. Also, the combined use of graphical diagrams and textual descriptions is considered beneficial for the requirements management process [5], [6]. In addition, for industrial applications, model exchange for graphical models is still not properly supported by tool vendors.…”

Section: Introductionmentioning

confidence: 99%

“…As a result, the handover between manufacturers and suppliers is still performed based on textual documents. This is especially important since these textual documents often serve as the basis for legal considerations between the contractors [6], [7]. Another reason why graphical models are usually accompanied by textual descriptions is the background of different stakeholders-not everyone is capable of understanding the graphical models [8], [9].…”

Section: Introductionmentioning

confidence: 99%

What is a Good Textual Representation of Activity Diagrams in Requirements Documents?

Beckmann¹,

Vogelsang²

2017

2017 IEEE 25th International Requirements Engineering Conference Workshops (REW)

View full text Add to dashboard Cite

Abstract-The use of graphical models has become a widely adopted approach to specify requirements of complex systems. Still, in practice, graphical models are often accompanied by textual descriptions to provide more detail, because of legal considerations, and to enable stakeholders with different backgrounds to understand a requirements document. One of our industry partners (Daimler AG) uses activity diagrams to specify vehicle functions in combination with a textual representation thereof in their requirements documents. Since graphical and textual representations serve different purposes, it is not obvious how textual representations of activity diagrams should be structured. In this paper, we present different textual representations of activity diagrams for use in requirements documents. The representation currently in use is presented as well as four alternatives. For each representation, we discuss advantages and disadvantages. To evaluate the representations, we asked five stakeholders of one system to create a preference ranking of the representations. The resulting ranking showed that the currently used representation is not considered to be the best possible option. The stakeholders' favorite textual representation emphasizes structural similarity with the activity diagram, which however does not resemble the diagram's structure exactly.

show abstract

Industry needs and research directions in requirements engineering for embedded systems

Cited by 75 publications

References 25 publications

Challenges and practices in aligning requirements with verification and validation: a case study of six companies

Challenges and practices in aligning requirements with verification and validation: a case study of six companies

On The Teachers Role in Interactive Prototyping

What is a Good Textual Representation of Activity Diagrams in Requirements Documents?

Contact Info

Product

Resources

About