Misunderstandings in requirements engineering
Table of Contents
What’s a misunderstanding?
Causes and countermeasures
An appeal
- The specialist side speaks, for example, insurance jargon or medical language, possibly also BPMN or ARIS.
- The technical staff speak UML, Java, ABAP, XML and things like that.
In addition to linguistic differences, there are cultural differences, such as different communication styles and implicit knowledge. Various models are available for collaboration:
- The specialist side is trained as computer scientists so that it can adapt to the development team. This option is unusual. The customer does not have to adapt to the service provider, but vice versa.
- The technical team learns the technical language and communicates with the technical side in its idiom. We find this model in long-term partnerships or when a software company specializes in a certain industry.
- Both sides find and learn a common language, or develop one. This investment is also only worthwhile in a long-term cooperation.
- There is one translator: the requirements engineer or consultant or analyst or product owner. This person must speak both languages fluently, be at home in both cultures and be able to translate back and forth correctly.
What’s a misunderstanding?
The following are misunderstandings that, in my experience, occur regularly between the two peoples in translation. As Requirements Engineer or Product Owner you have to pay attention to this. First of all: What is a misunderstanding? A speaker says (or writes) something and a listener (or reader) understands something. The following table shows the four possibilities that can occur:
- The ideal case is that the listener has actually understood the right thing and is aware of it.
- If the listener thinks he has not understood something, regardless of whether it is true or not, he can track and clarify the issue. If there is a problem, it can be uncovered and solved.
- A misunderstanding occurs when the listener thinks he has understood something correctly, even though it is not true. It can take more or less a long time for this to be discovered.
Misunderstandings in requirements engineering are followed by errors in the software, which then have to be resolved again at great expense. Misunderstandings can be avoided (not all, but many), and therefore such avoidable additional efforts are always a pity.
Causes and countermeasures
The best way to tackle problems is to get to the root of them. That is why in the following we will look at some important causes of misunderstandings and how to avoid this kind of talking at cross purposes.
- The meaning of requirements engineering is unclear. Hardly any lecturer requires students or trainees to correct their own mistakes. Or the specification can be created as post-implementation documentation. In the course, this behavior is relatively uncritical, since the document and software are discarded after evaluation. This learned behavior is often continued in professional practice. However, this misses the chance to seriously consider what requirements the software should meet before implementation, i.e. to identify real requirements. What do users need? Underestimating the importance of requirements engineering often leads to the fact that too few or the wrong people are assigned. The job beginner should familiarize himself with requirements engineering, the end users should not be kept away from work by workshops. The expert is needed elsewhere. Therefore, the importance of requirements engineering for the rest of the project cannot be sufficiently emphasized. Binding procedures for implementation are defined here, or at least this should be the case.
- Different words for the same thing or the same word for different things: This happens regularly with speakers of different languages. A glossary that is extended and updated every time a further difference in terminology is discovered helps. This glossary can be a dictionary of terms in both languages. However, only one language should be used in the specification, usually the known terminology in the requirements specification and the technical language in the functional spec.
- Lack of knowledge from the domain: If the technical side is not familiar with the technology, this causes less difficulties than vice versa, if the technical side misunderstands requirements and cannot guess implicit assumptions. Forgotten basic features and non-functional requirements can be proposed and specifically inquired by an industry-conscious requirements engineer. He is therefore well advised to familiarize himself with the application domain in general: Read technical literature, test state-of-the-art products on the market.
- Different or different amounts of information can lead to implicit assumptions that the other person cannot guess. It cannot be avoided that not all details are documented, otherwise the specifications become unwieldy. The only thing that helps here is regular communication between the technical side and the domain side or with the translator!
- Wrong expectations: At trade fairs and in science fiction films, excessive expectations are raised on the part of the specialist side as to what is technically feasible. Again: Communicate a lot with each other and create a prototype early to validate your design and to recognize and dampen utopian expectations.
- Vague, general formulations: The specification of requirements demands mathematical precision and a high degree of discipline. A “must” has to mean exactly that, requirements have to be testable. The good requirements engineer is trained to write and model to avoid misunderstandings.
- Lack of knowledge and experience in requirements engineering: Requirements must be specified by a professional. All others find it difficult to put even those facts on paper according to the rules of the art which they can formulate orally, not even as free text. Requirements engineering is learned through training, practice and feedback. Feedback on the quality of the requirements is provided by the acceptance test at the latest. At an earlier stage, it is possible to ensure regular quality assurance of the requirements. Consistency checks between different chapters, abstraction levels or between text and image are also productive.
- Optimal form of specification: There is not one optimal form for the specification. I have specified differently in every project. The form follows the content and the needs of the participants. It is even unnecessary that all requirements are presented in the same detail and in the same form. The specification is ready when all ambiguities and misunderstandings have been cleared up!
- Intention and tactics: Misunderstandings are often caused intentionally. One can deliberately formulate vaguely in order to allow different interpretations, e.g. because one does not want to commit oneself or cannot yet do so, or because the facts of the case are not clear.
An appeal
I recommend that requirement specifications be drawn up just as carefully as contract texts. It is a bad habit that, in practice, requirements are often treated as non-binding scribbles to which no one has to feel bound.
Notes:
Dr Andrea Herrmann regularly blogs about requirements engineering and software engineering at https://herrmann-ehrlich.over-blog.com.
Here in the t2informatik Blog you can find more articles from her, including
Dr Andrea Herrmann
Dr Andrea Herrmann has been a freelance trainer and consultant for software engineering since 2012. She has more than 28 years of professional experience in practice and research.
Dr Herrmann was most recently a deputy professor at Dortmund University of Applied Sciences and Arts, she has published more than 100 specialist publications and regularly gives conference presentations. She is an official supporter of the IREB Board and co-author of the IREB syllabus and handbook for the CPRE Advanced Level Certification in Requirements Management.