Getting Started With the SPES System Modeling Framework

We observe that numerous cyber-physical systems are rapidly gaining functionality and thus development gets more and more complex. Innovations are made possible in many areas by a complex interaction of sensor systems and software. Consider the development of autonomous driving, in which a multitude of different system functions must interact safely with one another in order to make complex decisions with the highest quality in order to transport people safely. In order to master the complexity, the classical, document-centered approaches of system engineering are no longer sufficient and are increasingly being replaced by model-based systems engineering (MBSE) approaches.

The SPES modeling framework provides a comprehensive, tool- and modeling language-independent method for MBSE. It offers a whole range of concrete models, modeling techniques and activities. In this blog post, I will introduce you gently to SPES. I will explain the basic principles of SPES and give some pointers where to find more.

Continue reading Getting Started With the SPES System Modeling Framework

Detect more Quality Defects in your Requirements

How we investigated whether our Qualicen Scout is a useful tool for companies in the domains of software and systems engineering.

Why we wanted to answer this question

As science showed, the quality of the requirements documentation influences the subsequent activities of the software engineering process. Detecting errors late in a software engineering process leads to very expensive changes of parts of every pre-executed activity. Accordingly, we at Qualicen help our customers to assure the quality of requirements specifications before they are used in other activities.
Continue reading Detect more Quality Defects in your Requirements

How to automate Test-Design with Specmate – Part 2: End-to-End Testing of Business Processes

This article is a sequel to our blog post Structured Test-Design With Specmate – Part 1: Requirements-Based Testing published by my colleague Maximilian. So far, Maximilian introduced you to our tool Specmate –  a tool that helps you to automate your test-design. He explained how to model requirements using cause-effect-models and how to automatically generate test specifications based on them.

However, Maximilian told you only half the story (I’m sure you were already guessing that based on the Part 1 in the title. 😉 ): Not all requirements are like the ones in his examples. Many requirements are of a different nature and can’t be specified easily using cause-effect models.

In this post, I’ll demonstrate the second way of modeling requirements in Specmate: Business processes. Furthermore, I show how to generate automatically end-to-end tests based on these business processes.

Continue reading How to automate Test-Design with Specmate – Part 2: End-to-End Testing of Business Processes

Structured Test-Design with Specmate – Part 1: Requirements-based Testing

In this blog post  I am going to introduce Specmate, the result of a research project I have been involved into. It is an open-source tool to automate test-design, among others. This is the first post of a series in which I am going to show you some of the ideas behind Specmate.

What is test-design and why does it matter?

Test-Design is the activity to come up with the right test-cases for a piece of functionality. But what are the right test-cases? There are many criteria, depending on your focus. For me, there are two main points:

  • First, they should test the right content. That means, they relate to the requirements for this functionality and cover every aspect that the requirements talk about. They should hence be able to find faults: deviations of the implementation with respect to the specification.
  • Second, they should be feasible. That means, it should be possible to execute the test-cases without wasting resources.

Continue reading Structured Test-Design with Specmate – Part 1: Requirements-based Testing

How to Awake Your Glossary From Zombie Mode

When we look at requirements documents that are new to us, we often need some help on terms and abbreviations. Creating a glossary to explain these imporant domain terms and abbreviations is a fine idea. It helps new team members to get going, improves the readability of a requirements specification and helps to avoid misunderstandings. The main problem with glossaries is that we create them once and update them only rarely. In consequence, the majority of glossaries are not particulary useful. In this article, Qualicen consultant Maximilian Junker shows how you can get more out of your glossary and keep it always up-to-date.

Continue reading How to Awake Your Glossary From Zombie Mode