Dennis Woyke
ERNI Switzerland

When building a software system, requirements form the bridge between the stakeholders involved and the development team. According to IREB, a requirement is defined in this case as a perceived need by stakeholders, the capability or property that a system shall have or a documented representation of a need, capability or property. Requirements are the link between the problem and the solution and must be communicated to stakeholders and the development team. Vocal communication between the people involved is possible, but this form is hardly persistent or consistent in daily business. Therefore, requirements are documented in different forms.

Broadly, requirements can be written down in three different ways within the IREB standard:

  • Natural language | The requirements engineer uses their native or a foreign language for documentation.
  • Templates | The requirements engineer uses a structured template to note the requirements.
  • Models | The requirements engineer uses a pre-defined modelling language, e.g. UML 2.5, for documenting the requirements.

Out of the three methods listed above, natural language is most widely used for documenting requirements. According to a study by Zhao et al. (2021), at least 61% of the participants asked said they use natural language to document requirements within their software development projects.

Natural language has various advantages and is one of the favourite techniques for documenting requirements. On the one side, natural language is used by everyone daily. Everyone speaks at least one language as their native language that can be used for requirements documentation. Moreover, natural language can be learned quickly and adapted to specific topics and surroundings. This flexibility makes natural language one of the most preferred techniques for requirements documentation within software development projects.

However, natural language is prone to misinterpretation. It has evolved over millennia and is still changing today. The usage and understanding of natural language depend on different aspects. Spoken natural language is used in a defined context, where every speaker or listener can ask questions or provide feedback for clarification. Moreover, when using the language in a face-to-face conversation, the participants build a knowledge base of implicit knowledge that helps them understand the context. Unfortunately, these aspects are not available if the natural language is used in its written form for documenting requirements. In that case, we often find faulty written texts with different connotations causing people to understand the documented requirements differently. Most of the time, natural language is used because it is easy to learn. However, if the structure of the requirements gets more complex, other documentation techniques, such as graphic models, should be preferred in order to reduce complexity. Natural language is just one way to document requirements, but it is also often used because the knowledge of other documentation techniques is unavailable within the project.


But how can a requirements engineer address this issue?

The International Requirements Engineering Board (IREB e.V.) provides several pieces of advice that we have been using for years to deal with the rising challenges of using natural language for documenting requirements. One recommendation for a requirements engineer when writing requirements in natural language is to write short sentences. The rule of thumb is to have just one requirement per sentence. Additionally, the requirements engineer should pay attention to the document’s overall structure. By using a standardised template and design for documenting requirements, the reader can recognise the stated requirements more effectively. A requirements engineer can also use phrase templates for structuring written requirements. The user story template is a well-known example of a phrase template often used in agile surroundings. To avoid inconsistency concerning the terminology used, the development team – the requirements engineer in particular – should define the terminology within glossaries. Moreover, the requirements engineer should avoid vague, ambiguous phrases when documenting requirements. Finally, the requirements engineer needs to review the documented requirements to identify common linguistic pitfalls such as incomplete comparisons, using the passive voice, etc.

Our experience shows that even if a requirements engineer learns this advice in a structured training programme, much more practice is needed until it is internalised in daily requirements documentation activities. Especially the work of inexperienced requirements engineers needs to be reviewed and verified by trained requirements engineers with several years of requirements documentation experience in writing consistent and effective requirements for the development process. However, this statement should not be seen as a prerequisite for reasonable requirements engineering; it only emphasises that effective requirements documentation in natural language can only be achieved by constant training and the willingness to self-improve one’s writing skills.

At ERNI, we have several years of experience documenting and managing requirements throughout their development life cycle. Besides structured training programmes, we are ready to support your development team in writing effective requirements. We cover all aspects of requirements documentation and management necessary for your development project’s success and for effective stakeholder communication within your development endeavour. As a platinum partner of IREB e.V., we are competent in all state-of-the-art requirements techniques and know how to address your challenges accordingly.


If you’d like to receive more information, feel free to contact us. Dennis Woyke and Urs Koepfli are available for your requests and questions.



Zhao, L., Alhoshan, W., Ferrari, A., Letsholo, K.J., Ajagbe, M.A., Chioasca, E.V. and Batista-Navarro, R.T., (2021) Natural language processing for requirements engineering: A systematic mapping study. ACM Computing Surveys (CSUR)54(3), pp.1-41.

News from ERNI

In our newsroom, you find all our articles, blogs and series entries in one place.

  • 27.09.2023.

    Unveiling the power of data: Part III – Navigating challenges and harnessing insights in data-driven projects

    Transforming an idea into a successful machine learning (ML)-based product involves navigating various challenges. In this final part of our series, we delve into two crucial aspects: ensuring 24/7 operation of the product and prioritising user experience (UX).

  • 13.09.2023.

    Exploring Language Models: An overview of LLMs and their practical implementation

    Generative AI models have recently amazed with unprecedented outputs, such as hyper-realistic images, diverse music, coherent texts, and synthetic videos, sparking excitement. Despite this progress, addressing ethical and societal concerns is crucial for responsible and beneficial utilization, guarding against issues like misinformation and manipulation in this AI-powered creative era.

  • 01.09.2023.

    Peter Zuber becomes the new Managing Director of ERNI Switzerland

    ERNI is setting an agenda for growth and innovation with the appointment of Peter Zuber as Managing Director of the Swiss business unit. With his previous experience and expertise, he will further expand the positioning of ERNI Switzerland, as a leading consulting firm for software development and digital innovation.

  • data230.08.2023.

    Unveiling the power of data: Part II – Navigating challenges and harnessing insights in data-driven projects

    The second article from the series on data-driven projects, explores common challenges that arise during their execution. To illustrate these concepts, we will focus on one of ERNI’s latest project called GeoML. This second article focuses on the second part of the GeoML project: Idea2Proof.

  • 16.08.2023.

    Unveiling the power of data: Part I – Navigating challenges and harnessing insights in data-driven projects

    In this series of articles (three in total), we look at data-driven projects and explore seven common challenges that arise during their execution. To illustrate these concepts, we will focus on one of ERNI’s latest project – GeoML, dealing with the development of a machine learning algorithm capable of assessing road accident risks more accurately than an individual relying solely on their years of personal experience as a road user, despite limited resources and data availability.


  • 09.08.2023.

    Collaborative robots revolutionising the future of work

    The future of work involves collaboration between robots and humans. After many years of integrating technology into work dynamics, the arrival of collaborative robots, or cobots, is a reality, boosting not only safety in the workplace but also productivity and efficiency in companies.

  • 19.07.2023.

    When the lid doesn’t fit the container: User Experience Design as risk minimisation

    Struggling with a difficult software application is like forcing a lid onto a poorly fitting container. This article explores the significance of user experience (UX) in software development. Discover how prioritising UX improves efficiency and customer satisfaction and reduces risks and costs. Join us as we uncover the key to successful software applications through user-centric design.

  • 21.06.2023.

    How does application security impact your business?

    With the rise of cyber threats and the growing dependence on technology, businesses must recognize the significance of application security as a fundamental pillar for protecting sensitive information and preserving operational resilience.