IREB Roundtable - How to Write good Requirements

Requirements Engineering is a major task when creating high quality software products - without requirements it will be hard to develop a product that is accepted by its stakeholders or customers.
But what does that mean? How can I identify the relevant stakeholders? What is a good requirement? What are quality criteria for requirements? What are work products and structures to document requirements? When do I have reached a proper level of detail with my requirements? This and more questions will be discussed in our IREB-Roundtable by Karolina Zmitrowicz and Sylwia Kopczyńska as discussants.

[@Walery1024]

I had traveled on my projects, experienced the requirements written in different human languages. Not surprisingly, what I have observed is that speech difference is not the main problem in achieving clarity. The need to negotiate flavors of semantics and the need to work on convergence of understandings suggest that the semantics of requirements is context dependent. Often the verbatim requirement remains the same after all the discussions, but it is actually the context that has been clarified. Does it make sense for you to give certain levels of formalization to document the context of the requirement? Could there be an obligation imposed to append definitions of terms used in the requirement? I see on some projects that the requirements are stated as a set of Gherkin statements. This could actually be seen as a solution to the problem described above. But is this the case? Don't we confuse a context with a syntax? For a dessert: let me admit that I, for a short time, expressed requirements in Yoda's tongue. It forced me to think about what I am saying. I was serious, but everyone was laughing. Were they cruel?