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.

  • 06.12.2023.

    Streamlining software development: The journey from multiple to unified requirements management tools

    Productivity in software development is slowed down by managing specifications across various requirements management (RM) tools. Although moving to a single, updated RM tool involves an upfront investment, the long-term benefits are considerable. These include increased process efficiency, enhanced collaboration, superior traceability, improved software specification quality, cost reductions, scalability and better integration with other RM tools, among others.

  • 22.11.2023.

    Recognising trends: An insight into regression analysis

    Data plays a very important role in every area of a company. When it comes to data, a distinction is made primarily between operational data and dispositive data. Operational data play an important role, especially in day-to-day business. However, they are not nearly as relevant as dispositive data. This is because these data are collected over a longer period of time and provide an initial insight into the history or the past.

  • 08.11.2023.

    Why do we need digital transformation for medical devices?

    For hospitals, it is not up for discussion as to whether they want to digitalise. The increasing age of the population in western countries and the progressive shortage of medical professionals mean that without digitalisation, the healthcare system will not be able to provide the quality that patients want in the future.

  • 25.10.2023.

    Mastering the challenges of mobile app testing: Strategies for efficient quality assurance

    Discover the unique challenges faced in testing mobile applications and learn how to overcome them effectively. From selecting suitable devices and operating systems to leveraging cloud-based test platforms, test automation and emulators, this article provides seven essential strategies for optimising your mobile app testing process.

  • 11.10.2023.

    Incorporating classical requirements engineering methods in agile software development for a laboratory automation system

    Traditional agile methodologies can sometimes struggle to accommodate the complexity and regulatory requirements of laboratory automation systems, leading to misalignment with stakeholder needs, scope creep, and potential delays. The lack of comprehensive requirements documentation can result in ambiguous expectations and hinder effective communication among cross-functional teams.

  • 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.