Posted on

The QDAcity-RE Method for Structural Domain Modeling Using Qualitative Data Analysis

Abstract: The creation of domain models from qualitative input relies heavily on experience. An uncodified ad-hoc modeling process is still common and leads to poor documentation of the analysis. In this article we present a new method for domain analysis based on qualitative data analysis. The method helps identify inconsistencies, ensures a high degree of completeness, and inherently provides traceability from analysis results back to stakeholder input. These traces do not have to be documented after the fact, but rather emerge naturally as part of the analysis process. We evaluate our approach using four exploratory studies.

Keywords: Domain modeling, Domain model, Requirements engineering, Requirements elicitation, Qualitative data analysis

Reference: Kaufmann, A., & Riehle, D. (2017). The QDAcity-RE method for structural domain modeling using qualitative data analysis. Requirements Engineering, 1-18.

The paper is available as a PDF file.

Posted on

CeBIT Forum on “Open Source und Smart Services”

Today, I’ll be at the CeBIT Forum on open source and smart services to discuss business models based on open source and review a few examples, together with always fabulous Peter Ganten, CEO of Univention, a German Linux distributor. Catch me at 1pm today (2018-06-13) in room München (Munich) on the (CeBIT) Hannover Messegelände (i.e. the convention center).

Posted on

Why are There Only Two Research Groups Working on Inner Source?

I got asked the other day why there are only two research groups working on inner source world-wide. Inner source is the use of open source best practices within companies, and it is a hot topic with many companies who want to go beyond agile. There was varied research around the world in the past 15 years, but only two groups really have been consistently working on this: Brian’s group at LERO and my research group at FAU.

Continue reading “Why are There Only Two Research Groups Working on Inner Source?”

Posted on

Code of Conduct for Code Reviews

On Twitter, @arkwrite suggested that a code review should always say something nice and @chaos_monster commented that we need a code of conduct for code reviews. All of this makes sense to me, however, I suggest that we first have a general code of conduct of productive discussions (and most companies have something like it). The two main rules that come to my mind are:

  1. Separate the person from the issue
  2. Praise liberally, criticize specifically

Separating a person from the issue makes sure that you focus on the technical problem, not the person. Praising liberally is just good practice, showing how you value a person’s contribution. If you have to criticize for good reason, be specific so that the underlying technical issue is clear and provides a chance to respond.

Continue reading “Code of Conduct for Code Reviews”

Posted on

On the Misuse of the Terms Qualitative and Quantitative Research

Researchers often use the term “qualitative research” to mean research without substantial empirical data, and use “quantitative research” to mean research with substantial empirical data. That doesn’t make sense to me, as most “qualitative researchers” will quickly point out, because qualitative research utilizes as much data in a structured way as it can. Everything else would not be research.

Continue reading “On the Misuse of the Terms Qualitative and Quantitative Research”

Posted on

Why “Soft” Research is “Hard”

Some of my colleagues like to talk about how research that involves programming is “hard”, while research that involves human subjects is “soft”. Similarly, some colleagues like to call exploratory (qualitative) research “soft” and confirmatory (quantitative) research “hard”. Soft and hard are often used as synonyms for easy and difficult, and this is plain wrong.

Pretty much any research worth its salt is difficult in some way, and working with human subjects makes it even more difficult. I find research methods like qualitative surveys, involving interview analyses, for example, much harder than the statistical analysis of some data or some algorithm design. The reason is the lack of immediate feedback.

While you can (and should) put quality assurance measures in place for your interview analyses, ranging from basic member checking to complex forms of triangulation, it might take a long time until you learn whether what you did was any good. So you have to focus hard in your analysis without knowing whether you are on the right track. It doesn’t get more difficult than this.

Posted on

Who Writes and Prioritizes User Stories?

I updated this post after I realized that it is more about prioritizing user stories than it is about writing them well.

In Scrum, a product owner writes user stories to capture requirements and prioritizes them in a product backlog as the upcoming work queue for developers. The main question on my mind is:

Who has the capabilities and competencies to write good user stories and prioritize them in a product backlog?

The INVEST criteria list quality measures (of sorts) that determine what a good user story is. It should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. While fundamentally correct, there is much more to say. For example, in a product backlog, user stories should use a consistent vocabulary, based on a shared domain model (or glossary, at a minimum).

Continue reading “Who Writes and Prioritizes User Stories?”

Posted on

Product Manager vs. Product Owner

Alistair Cockburn pointed us to an excellent article by Melissa Perri about the differences between a product manager and (Scrum) product owner. The article clarifies some confusion. I’d like to repeat and emphasize some points that have been omitted (and where I also disagree).

Foremost, a product manager works on products for a market (i.e. many customers). I have never seen a product manager work on a project with one customer. For a product owner this is undefined; they could be working on a product for a market or on a project for a specific customer.

Continue reading “Product Manager vs. Product Owner”

Posted on

Professors and Startups

My primary goal in becoming a professor was to turn my (hoped-for excellent) research and teaching into startups. For that reason I created the Startupinformatik program and set-up my teaching to support it. Sadly, I’ve been noticing over the years that things don’t seem to get easier but harder. Specifically, “the system” (I’ll explain below) seems to view professors with mistrust rather than as the natural allies they should be when it comes to leading students to create a startup.

Let me illustrate this using two experiences:

Continue reading “Professors and Startups”