IREB Roundtable: From boring written requirements to exciting visual requirements, UX, Digital Design – Summary

To reflect the interdisciplinarity and breadth of Software Engineering, our roundtable brought together a diverse panel of experts. With Martina Beck 's background in computer science and linguistics, Craig Errey 's expertise in organisational psychology, and Kim Lauenroth 's experience as an RE and Digital Design lecturer, we discussed written requirements and the importance of giving them what they deserve - visuals.?

Our conversation started with a fundamental question: Why criticize written requirements? Since the start of the Requirements Engineer role, written requirements have been a staple, so there shouldn't be any reason to change them, right? Craig quickly dismantled this romanticization by sharing an interesting observation: while architects rely on floor plans, chemists visualize the shape of molecules, and civil engineers use 3D models, Requirements Engineers don't have visual aids on that level. Kim emphasized how this absence complicates software development, especially in today's integrated and business-focused landscape.?

Martina interjected with a linguistic perspective, mentioning that while words are a good and most common way of communication, they leave a lot of room for misunderstandings. Any term has a plethora of different meanings depending on the person. Here, visuals could come in as an important tool, as Craig put it: "Have you ever heard an engineer say that a thousand words are better than one picture?"?

This discussion emphasized the need to standardize visual requirements for more precise documentation, which would result in the development of better products. While there are some visuals for RE, they are few and far between, not enough for the establishment of a standardized approach. Craig suggests that the closest thing to visual representation would be UML. However, with 14 distinct diagrams, employing them all becomes both time-consuming and expensive. Additionally, they are crafted to be understood by Software Engineers, making them less comprehensible for people across different contexts.?

At this point, one might wonder: if visual requirements can make software engineering better, why aren't they more common? At the roundtable, we looked at civil engineering for answers. Kim pointed out that civil engineers and architects have a long history of knowing exactly what they're building, unlike in software engineering, where things are still evolving and continuously getting more complex, especially with developments such as in Artificial Intelligence, as we can see most recently. The huge variety of different fields and the constant changes in technology make it hard to come up with standardized visuals for RE.?

Martina wrapped up the discussion by noting another crucial point: there is still a lack of a holistic view of things, which might hinder the jump from written to standardized visual requirements.??

So, there's still much ahead of us. However, we ended on a positive note with Kim reminding us that these conversations, and our willingness to discuss how to change, reflect the community's readiness to learn and grow. 'We're not perfect, but we're getting better', Kim concluded.??