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.
Hear us speak at REConf 2018
Falls Ihr/Sie nächste Woche in München seid, kann man fast gar nicht über die REConf 2018 laufen ohne uns zu begegnen:
Keynote: "Vom Design Thinking zum Requirements Engineering: Vom Warum und Wieso zum Was und Wie"
Prof. Dr. h.c. Manfred Broy wird am Dienstag um 9 Uhr die Eröffnungs-Keynote zum Thema Design Thinking und RE halten: Requirements Engineering ist vielleicht der wichtigste Teil der Software-Evolution. Falls es uns nicht gelingt, die Funktionalität, die der Endnutzer benötigt, korrekt zu spezifizieren, und falls es uns nicht gelingt, die geforderte Qualität korrekt zu identifizieren, besteht die Gefahr, dass ein System entwickelt wird, das nur teilweise oder vielleicht sogar völlig nutzlos ist. Im Prinzip gibt es zwei wichtige Schritte im Prozess des Requirements Engineerings. Die größte Herausforderung ist, die benötigte Funktionalität zu finden. Das ist eine schwierige Aufgabe und Techniken wie Design Thinking können hier helfen. Design Thinking ist ganz darauf ausgerichtet, Lösungen für Probleme zu finden und diese durch die Konstruktion eines Prototyps konkret zu machen. Dies ist ein kreativer Prozess, um Ideen zu entwickeln, wie die richtige Funktionalität eines Softwaresystems ausschauen könnte. Jedoch, wenn ein Prototyp vorliegt, ist man noch weit entfernt davon, einen guten Satz von Anforderungen zu besitzen. Deshalb ist es notwendig, eine Brücke zu finden von den Resultaten des Design Thinking-Prozesses zum Requirements Engineering, um alle Details einer Anforderungsspezifikation auszuarbeiten. Dieser Prozess ist beeinflusst von dem gewählten Entwicklungsmodell, wie etwa agiles oder konventionelles dokumentationsorientiertes Vorgehen. Design Thinking und Requirements Engineering ergänzen sich perfekt, um die kreative Identifikation der Funktionalität und der detaillierten Beschreibung der Funktionen, aber auch der Qualität von softwareintensiven Systemen sicher zu stellen.
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.
Three Perspectives on Requirements Quality: Authors, Reviewers, QA-Engineers
Several roles are concerned with requirements quality. Of course, there is the requirements author, writing the requirements. But there is also the reviewer, who proof-reads and validates the requirements. And finally, there is the QA-Engineer, responsible for the overall quality of all artifacts created during the engineering process. Each of these roles needs a different view on requirements and different tools in order to do their work efficiently and achieve a high requirements quality. In this article I am going to show you how the Qualicen products specifically support authors, reviewers and QA-engineers in their work to keep requirements quality high.
Requirements quality is quality-in-use
I've worked quite some time on understanding and detecting quality defects in requirements documents and requirements quality in general. All the time, I was very dissatisfied with the current state in both research and practice on this topic. I think, the problem behind this is that there is no guidance: In times of rapid change and delivery, where every project looks different, we still have no good rule of what a good requirements document is. A few years ago, we came up with such a rule, and tried it in various applications. And - so far - it seems to work! We've collected this experience and are now ready to tell you about it, because we really believe this should change how you view requirements engineering, and this should change what you consider good requirements documents.
Efficiently control requirements quality: the best of two worlds
For high requirements quality we need quality assurance. In a previous post, I explained why automatic methods cannot replace manual methods. Instead I suggested to combine both worlds. And the ugly truth is, in both system testing and requirements engineering, we need both manual and automatic quality assurance to control requirements quality and test quality. Now you wonder, how? I got you covered. In this brief post, I want to point out how you can combine the two worlds and how you benefit from the combination.
Requirements Traceability with Microsoft Word
Why use Word for Requirements Documentation?
... you might ask. Usually, I strongly encourage our customers to use suitable tools for managing their requirements. There are plenty of reasons why I recommend using professional tools for requirements management, but an important reason is to ensure requirements traceability. For example, of the six sources of RE project failures identified by Michelle Boucher, at least three have to do with traceability. While we do recommend other tools, Word is available in most companies, documents are easy to exchange, the review mode is pretty good and sometimes using other tools is simply not an option for different reasons. Hence, many people do use Word to create requirements documents. My own experience in using Word for authoring a requirements document is that it seems to work well in the beginning, but as soon as already documented requirements begin to change things start to get nasty. Especially if there is not just one requirements document, but several.The ugly truth about automatic methods for requirements engineering quality.
Ok, after I publish this blog post, I will probably get some angry calls from my sales department... Well, truth must be told. There are many crazy defects in requirements, and, as I wrote in my last post, you can detect quite a bunch of them automatically (and you should do so!). When I present our automatic methods for natural language requirement smells or automatic methods for detecting defects in tests to our customers, I'm proud to say that they are usually very excited. Sometimes they are too excited and then this can turn into a problem. What I mean is that I explain all the amazing things that you can detect with tools and suddenly people think that the tool will solve all the problems that they face. Spoiler alert: It doesn't. And because we're a company that is interested in happy customers, I want to briefly summarize all the problems (*that come into my mind) that a tool can't solve. And because I don't want to leave you in despair, I will also suggest some solutions, how I personally would suggest to work on that problem.
Which quality defects can you automatically detect in system tests and requirements?
I am a strong advertiser of modern, automatic methods to improve our day to day life. And so I really don't want to check by hand whether my tests and requirements fit my template, or whether my sentences are readable. So quality assurance and defect detection, for example reviews or inspections, should use automation as far as possible. BUT: When I speak to clients, sometimes people get so hooked up by the idea of automatic smell detection, that I need to slow them down. Therefore, this post tries to give a rough overview: What is possible to detect automatically? The answer basically depends on two questions:
- How much syntax (or structure) do your artifacts and tests have?
- Which language do you use?