A Case Study on a Specification Approach Using Activity Diagrams in Requirements Documents

Beckmann, Martin J.; Vogelsang, Andreas; Reuter, Christian

doi:10.1109/re.2017.28

Cited by 6 publications

(7 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In a previous work, we defined and analyzed different types of quality issues that arise when activity diagrams are used in requirements documents for the specification of functions [14]. One of the quality issues, we identified, are redundant elements.…”

Section: Redundant Elements In Activity Diagramsmentioning

confidence: 99%

Removal of Redundant Elements within UML Activity Diagrams

Beckmann

Michalke

Schlutter

et al. 2017

2017 ACM/IEEE 20th International Conference on Model Driven Engineering Languages and Systems (MODELS)

Self Cite

View full text Add to dashboard Cite

Abstract-As the complexity of systems continues to rise, the use of model-driven development approaches becomes more widely applied. Still, many created models are mainly used for documentation. As such, they are not designed to be used in following stages of development, but merely as a means of improved overview and communication. In an effort to use existing UML2 activity diagrams of an industry partner (Daimler AG) as a source for automatic generation of software artifacts, we discovered, that the diagrams often contain multiple instances of the same element. These redundant instances might improve the readability of a diagram. However, they complicate further approaches such as automated model analysis or traceability to other artifacts because mostly redundant instances must be handled as one distinctive element. In this paper, we present an approach to automatically remove redundant ExecutableNodes within activity diagrams as they are used by our industry partner. The removal is implemented by merging the redundant instances to a single element and adding additional elements to maintain the original behavior of the activity. We use reachability graphs to argue that our approach preserves the behavior of the activity. Additionally, we applied the approach to a real system described by 36 activity diagrams. As a result 25 redundant instances were removed from 15 affected diagrams.

show abstract

Section: Redundant Elements In Activity Diagramsmentioning

confidence: 99%

Removal of Redundant Elements within UML Activity Diagrams

Beckmann

Michalke

Schlutter

et al. 2017

2017 ACM/IEEE 20th International Conference on Model Driven Engineering Languages and Systems (MODELS)

Self Cite

View full text Add to dashboard Cite

show abstract

“…1. In a former study, we investigated these issues in detail [13]. While some of these issues can be resolved [14], some of the other issues originate from the currently used textual representation.…”

Section: /mentioning

confidence: 99%

“…Also we received only a relatively small number of answers. We combined our survey with another study on quality issues that arise from using activity diagrams and their textual representations side by side [13]. Thus, all participants of this survey also participated in the previous study.…”

Section: Threats To Validitymentioning

confidence: 99%

“…The transformation of the activity diagrams into textual representations is done manually (i.e., not generated by a tool). This manual process is error-prone and labor intensive on the one hand [13] but, on the other hand, provides some flexibility to create a textual representation that best fits its purpose. Since graphical and textual representations serve different purposes, it is not obvious how textual representations of activity diagrams should be structured.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

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

Beckmann¹,

Vogelsang²

2017

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

Self Cite

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

“…In previous work, we have shown that this is a potential source for inconsistencies and quality issues in the requirements specifications [7]. Moreover, best practices and guidelines for when and how to use graphical or textual representations are missing.…”

Section: Introductionmentioning

confidence: 99%

Coexisting Graphical and Structured Textual Representations of Requirements: Insights and Suggestions

Beckmann

Reuter

Vogelsang

2018

Requirements Engineering: Foundation for Software Quality

Self Cite

View full text Add to dashboard Cite

Abstract. [Context & motivation] Many requirements documents contain graphical and textual representations of requirements side-byside. These representations may be complementary but oftentimes they are strongly related or even express the same content. [Question/problem] Since both representation may be used on their own, we want to find out why and how a combination of them is used in practice. In consequence, we want to know what advantages such an approach provides and whether challenges arise from the coexistence. [Principal ideas/results] To get more insights into how graphical and textual representations are used in requirements documents, we conducted eight interviews with stakeholders at Daimler. These stakeholders work on a system that is specified by tabular textual descriptions and UML activity diagrams. The results indicate that the different representations are associated with different activities.[Contribution] Our study provides insights into a possible implementation of a specification approach using mixed representations of requirements. We use these insights to make suggestions on how to apply the approach in a way that profits from its advantages and mitigates potential weaknesses. While we draw our conclusions from a single use case, some aspects might be applicable in general.

show abstract

A Case Study on a Specification Approach Using Activity Diagrams in Requirements Documents

Cited by 6 publications

References 18 publications

Removal of Redundant Elements within UML Activity Diagrams

Removal of Redundant Elements within UML Activity Diagrams

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

Coexisting Graphical and Structured Textual Representations of Requirements: Insights and Suggestions

Contact Info

Product

Resources

About