Natural language

I call natural language the language people use for speaking and writing in everyday life. First, I contrast it with artificial languages. For example, programmers use programming languages. In contrast, I use natural language for daily communication. Therefore, I often write requirements in English, German, or Spanish. Moreover, I rely on its expressiveness and flexibility. Consequently, I can state almost any conceivable requirement in natural language.

However, I also see limits. Human evolution shaped natural language for spoken, interactive exchange. Thus, people detect and correct misunderstandings quickly in conversation. In contrast, written documents lack that instant feedback. As a result, ambiguities, omissions, and inconsistencies hide in texts. Furthermore, finding those problems later costs time and money. For that reason, I handle natural-language requirements carefully.

First, I write short and well-structured sentences. For instance, I try to express a single requirement in one sentence. Second, I use terms consistently. Therefore, I define key terms in a glossary. Next, I structure work products clearly. For example, I choose standard structures and templates. In addition, I decide early which work products shall record requirements. Consequently, I plan resources better and avoid major reshuffling later.

Moreover, I caution against common linguistic pitfalls. For example, I avoid universal quantifiers when they do not truly apply. Otherwise, I might exclude valid exceptions. Similarly, I handle “either-or” clauses with care. In addition, I avoid nominalizations when they hide processes. For example, the noun “authentication” may hide steps that I must specify. Therefore, I write the procedure when needed.

I also choose between natural-language-based and model-based representations. Natural language works well for broad, expressive descriptions. However, models often reduce ambiguity. Therefore, I use both when required. For instance, I combine prose with phrase templates. Moreover, I use structuring templates and form templates. As a result, I produce clearer and more maintainable work products.

When I write requirements in natural language, I follow proven rules. First, I keep sentences short. Second, I use active voice. Third, I avoid complex syntax that hinders automatic translation. In addition, I prefer simple words and direct structure. Consequently, translators and tools perform better. Furthermore, I review texts to find ambiguities and omissions. Then, I revise until stakeholders agree.

I also involve stakeholders early and often. For example, I validate requirement texts with users and developers. Therefore, I detect misunderstandings early. Likewise, I record which abstraction levels I need. Next, I decide how much detail each level requires. Finally, I ensure that notation choices match project needs.

In short, I value natural language for its accessibility and expressiveness. However, I respect its risks. Therefore, I apply clear writing rules, consistent terminology, structured templates, and stakeholder review. By doing so, I keep requirements understandable, testable, and maintainable.