{"id":4315,"date":"2020-02-27T09:42:41","date_gmt":"2020-02-27T07:42:41","guid":{"rendered":"https:\/\/blog.iese.fraunhofer.de\/?p=4315"},"modified":"2024-01-12T14:09:33","modified_gmt":"2024-01-12T13:09:33","slug":"requirements-specification-1-5-why-should-you-perform-requirements-documentation","status":"publish","type":"post","link":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/","title":{"rendered":"Requirements Specification (1\/5): Why Should You Perform Requirements Documentation?"},"content":{"rendered":"

In requirements engineering (RE), the documentation of requirements and related artifacts plays a central role. However, practitioners often experience challenges in this particular RE activity. This blog post is the first in a five-part series of articles on requirements documentation. In part 1, we explore why requirements are documented at all.<\/p>\n

The Role of Documentation in Requirements Engineering<\/h3>\n

The definition of RE by IREB [1] highlights how the documentation \/ specification of requirements lies at the heart of RE:<\/p>\n

A systematic and disciplined<\/strong> approach to the specification<\/strong> and management of requirements with the following goals: <\/em><\/p>\n

    \n
  1. Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting<\/strong> them according to given standards, and managing them systematically;<\/em><\/li>\n
  2. Understanding and documenting<\/strong> the stakeholders\u2019 desires and needs;<\/em><\/li>\n
  3. Specifying<\/em><\/strong> and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders\u2019 desires and needs.<\/em><\/li>\n<\/ol>\n

    RE typically comprises the four core activities shown in the figure below, with some sources considering \u201crequirements analysis\u201d a fifth activity, separate from validation and negotiation.<\/p>\n

    \"Fraunhofer<\/p>\n

    This figure reveals much about the aspects and contribution of documentation within RE from a procedural point of view:<\/p>\n

      \n
    • Documentation is logically the step where the elicited requirements are held in a particular form. Without requirements documentation, a requirement may get lost or be grossly misinterpreted.<\/li>\n
    • Documentation provides a solid basis for requirements validation and a source for revealing conflicts that need to be resolved through requirements negotiation. Validation requires clearly documented requirements to provide a basis for discussion.<\/li>\n
    • Documentation is a source for requirements elicitation. Instead of using only survey-based techniques (such as interviews, focus groups, and questionnaires) or observation techniques, many (good) requirements for a system can be obtained from requirements specifications of previous versions and predecessor systems, or through reuse of requirements from other projects.<\/li>\n
    • Documentation supports requirements management, which focuses on handling requirements over time, in key aspects like planning, prioritization, monitoring, and change management. Without documentation, many aspects of requirements management cannot be performed properly.<\/li>\n<\/ul>\n

      The Role of Requirements Documentation in the System Lifecycle<\/h3>\n

      In addition to requirements documentation playing a central role within RE itself, the RE phase is not an end in itself, but focuses on what lies beyond, by providing a base for all subsequent activities within the system lifecycle (cf. [1]). In particular:<\/p>\n

        \n
      • Documented requirements elaborated to the right degree of detail enable more precise estimates for the planning<\/strong> of resources.<\/li>\n
      • The requirements documentation specifies many of the constraints and key aspects that inform the architectural design <\/strong>of the system.<\/li>\n
      • The requirements documentation contains the system features that must be implemented<\/strong> and the quality these features must meet.<\/li>\n
      • Based on the documented requirements, test<\/strong> cases can be derived or even (automatically) generated and the correct system behavior can be specified.<\/li>\n
      • With proper traceability within the requirements documentation, change management <\/strong>can determine whether a requested change is permissible, and what the impact and costs of a change will be.<\/li>\n
      • The requirements documentation is a valuable source of information during system usage and system maintenance<\/strong>, and can be a basis for the user manual and for developer documentation.<\/li>\n
      • The requirements documentation supports contract management<\/strong> in the early stages of a project, throughout the project as changes occur, and during renegotiations.<\/li>\n<\/ul>\n

        Key Contributions of Requirements Documentation<\/h3>\n

        Managing complexity: <\/strong>Requirements documentation plays a role in terms of efficiently dealing with content. It is important to understand that a requirements document is not merely a collection of requirements, but that it also involves all the related artifacts. Each requirement can have many different types of artifacts, including those that form the basis for its existence (e.g., interview protocols), products from working with the requirement (e.g., agreement activity reports, change requests), and material created based on requirements (e.g., validation reports, code snippets). Together, these can form vast amounts of information. Moreover, most artifacts relate to several requirements, so these need to be referenced rather than stored together with a single requirement. When the requirements, the relationships between them, and their associated artifacts are structured properly, the documentation allows this complexity to be managed.<\/p>\n

        Achieving legal compliance: <\/strong>Requirements documents can have a legal impact in two ways. First, in a descriptive<\/em> sense, a requirements document can specify which laws, regulations, or standards need to be complied with, and include requirements that operationalize the consequences of these legal aspects. This ensures that the system will intrinsically be legally compliant, and the documentation serves as evidence that facilitates the accreditation or review process. Second, in a prescriptive<\/em> sense, a requirements document can be part of a legally binding contract between the customer specifying the requirements and the party taking on the development of a system. The requirements then serve as the criteria to determine whether the system is built as specified.<\/p>\n

        Assuring knowledge management: <\/strong>Over extended periods of time, requirements documentation serves as a fallback to the original purposes of the system, a reminder of the intended or envisioned use cases, and a history of the decisions made throughout development [2]. The documentation can be consulted during a (long-standing) project as well as retrospectively after a project has been concluded.<\/p>\n

        Supporting stakeholder communication:<\/strong> Requirements documentation facilitates communication between stakeholders in several ways. It provides a strong basis for discussions and allows for alignment even in the case of distributed teams. For example, it defines the role of the Product Owner much more clearly for the development team. Documented requirements additionally support a common understanding, especially when they include diagrams or clear language. Stakeholders can also reread the information at a later time to refresh their memory. This becomes especially important when the information is complex.<\/p>\n

        Facilitating iterative thinking:<\/strong> The documentation of thoughts and ideas supports the person writing them down in their creative process. Writing something down puts this person in a particular mindset that helps them uncover gaps. These notes can also be revisited to make further improvements when new ideas arise. In this case, the documentation is already serving a purpose before a decision is made on whether or not to include it in the requirements documentation, namely that the author was able to explore their knowledge of and ideas for the system.<\/p>\n

        Introducing and Following a Documentation Process<\/h3>\n

        Only having a structure for the requirements specification in place does not suffice. The motivation of team members to document requirements systematically by following a process that involves guidelines and rules is also required. Without such a process in place, the specification is likely to have many quality defects. A requirements documentation process must fit the organizational structure and culture, but should at least address the following aspects:<\/p>\n

        Involve stakeholders:<\/strong> Functional requirements and quality requirements are elicited in a structured way through interactions with stakeholders, i.e., all noteworthy persons who can provide requirements, including end-users, team members, and other parties. The documented requirements and any questions about them are again discussed with the stakeholder(s) who provided the requirements in order to uncover and resolve any misunderstandings [3].<\/p>\n

        Use requirements templates:<\/strong> When we talk about the quality of requirements specifications, we mean aspects such as unambiguity, consistency, clarity of structure, and completeness. Prior to validation, the requirements documentation is the stage where these qualities are either achieved or low quality is produced. Adhering to a standardized structure or template for each type of text-based requirement can greatly contribute to well-written requirements.<\/p>\n

        Document artifacts:<\/strong> Requirements can serve as a basis through which additional information and artifacts are added in a constructive and pragmatic way. One recommended approach is to gather all artifacts created during the process and attach them to the requirement in order to facilitate knowledge sharing and to have more fine-grained information available that can serve as a basis for discussion. This makes the requirements specification an even better source of information on design decisions and boosts traceability.<\/p>\n

        Elaborate and plan requirements:<\/strong> An efficient approach to requirements documentation is to systematically refine requirements. This addresses two key aspects of requirements: the fact that they exist at different levels of granularity, and the notion that requirements are subject to change. At each stage, requirements are best elaborated only to the necessary level of abstraction, and through communication: from a project leader, who assures that the goals are approved by the executive board, down to a team leader, who presents the task to the team and discusses questions with developers individually.<\/p>\n

        Lock requirements for implementation:<\/strong> To assure a clear-cut approach, a clear distinction should be made between requirements that are still fluid and those that are fixed for a particular iteration. Requirements should only be planned for implementation after conceptualization has been completed, and after that, it should be governed by a clear and closely observed change management process. This also protects the development team from being overloaded with unqualified requirements [2].<\/p>\n

        Establish a glossary:<\/strong> In a development project, a glossary is an important clarification tool. It is a collection of term definitions that can contain aspects such as context-specific technical terms, business terms and jargon, abbreviations and acronyms, everyday terms that have a specific meaning in a particular context, synonyms (different terms with the same meaning, of which only one should be used), and homonyms (similar terms with different meanings) [1].<\/p>\n

        Perform quality assurance:<\/strong> Quality should be safe-guarded, which includes validating requirements before implementation and performing post-hoc verification of said implementation. Validation assures that the requirements are placed in the correct location, contain the necessary attributes, have been versioned, are written consistently, meet the quality criteria of well-written requirements, and can be tested.<\/p>\n

        \n

        Fraunhofer IESE Can Help<\/h3>\n

        If you need support with your requirements documentation, our RE experts at Fraunhofer IESE can support you. We rely, among other things, on our long-standing experience with RE spanning more than two decades, our proven RE frameworks such as ReqMan and TORE, and our extensive body of research on RE in order to support you in:<\/p>\n

          \n
        • Assessing improvement potential in your existing RE landscape<\/li>\n
        • Selecting and introducing appropriate tooling<\/li>\n
        • Reviewing your requirements specifications and advising you on how to improve the way they are written<\/li>\n
        • Designing and introducing a requirements documentation process<\/li>\n<\/ul>\n

          Contact us to learn more about what we can do for you!<\/p>\n<\/div>\n

           <\/p>\n

          references<\/h4>\n

          [1] Rupp, C. & Pohl, K. (2015). Requirements Engineering fundamentals: A study guide for the Certified Professional for Requirements Engineering exam – Foundation Level – IREB compliant (2nd Ed.). San Rafael, CA: Rocky Nook.<\/p>\n

          [2] Baumann, L., Hruschka, P., Lauenroth, K., Meuten, M., Reis, Rogers, G. et al. (2017). IREB Certified Professional for Requirements Engineering \u2013 RE@Agile Primer: Syllabus and Study Guide (Version 1.0.2). Karlsruhe, Germany: International Requirements Engineering Board e.V. Available online: https:\/\/www.ireb.org\/content\/downloads\/28-cpre-re-agile-primer-syllabus\/ireb_cpre_re%40agileprimersyllabusandstudyguide_en_v1.0.2.pdf (last accessed 11 June 2019).<\/p>\n

          [3] Schmitt, H., Rost, D., & Weitzel., B. (2015). PQ4Agile AP 2.2 Best Practices: Kundenanforderungen dokumentieren. Sulzbach, Germany: HK Business Solutions GmbH. Projekt \u201ePQ4Agile \u2014 Produktqualit\u00e4t f\u00fcr Agile Softwareentwicklung\u201c, BMBF-F\u00f6rderkennzeichen 01IS13032. Available online: http:\/\/www.pqwiki.de\/index.php\/Kundenanforderungen_dokumentieren (last accessed 11 June 2019).<\/p>\n

           <\/p>\n","protected":false},"excerpt":{"rendered":"

          In requirements engineering (RE), the documentation of requirements and related artifacts plays a central role. However, practitioners often experience challenges in this particular RE activity. This blog post is the first in a five-part series of articles on requirements documentation….<\/p>\n","protected":false},"author":46,"featured_media":4365,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[211],"tags":[235,198,127],"coauthors":[80,74,265],"class_list":["post-4315","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-digitale-transformation","tag-agile","tag-english","tag-requirements-engineering"],"yoast_head":"\nRequirements Specification (1\/5): Why Should You Perform Requirements Documentation? - Blog des Fraunhofer IESE<\/title>\n<meta name=\"description\" content=\"Why is requirements documentation so important? Fraunhofer IESE shows why it plays a central role in requirement engineering.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Requirements Specification (1\/5): Why Should You Perform Requirements Documentation? - Blog des Fraunhofer IESE\" \/>\n<meta property=\"og:description\" content=\"Why is requirements documentation so important? Fraunhofer IESE shows why it plays a central role in requirement engineering.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/\" \/>\n<meta property=\"og:site_name\" content=\"Fraunhofer IESE\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/FraunhoferIESE\/\" \/>\n<meta property=\"article:published_time\" content=\"2020-02-27T07:42:41+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-12T13:09:33+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2019\/10\/Doc_Requirement_Eddy_Blogbeitrag1.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1138\" \/>\n\t<meta property=\"og:image:height\" content=\"572\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Dr. Eddy Groen, Dr. Matthias Koch, Phil St\u00fcpfert\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@FraunhoferIESE\" \/>\n<meta name=\"twitter:site\" content=\"@FraunhoferIESE\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Dr. Eddy Groen\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"11\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Dr. Eddy Groen, Dr. Matthias Koch, Phil St\u00fcpfert\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/\"},\"author\":{\"name\":\"Dr. Eddy Groen\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#\\\/schema\\\/person\\\/b184e099b02c6e1e095b3ed382561ecb\"},\"headline\":\"Requirements Specification (1\\\/5): Why Should You Perform Requirements Documentation?\",\"datePublished\":\"2020-02-27T07:42:41+00:00\",\"dateModified\":\"2024-01-12T13:09:33+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/\"},\"wordCount\":1833,\"publisher\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/10\\\/Doc_Requirement_Eddy_Blogbeitrag1.jpg\",\"keywords\":[\"Agile\",\"English\",\"Requirements Engineering\"],\"articleSection\":[\"Digitale Transformation\"],\"inLanguage\":\"de\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/\",\"url\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/\",\"name\":\"Requirements Specification (1\\\/5): Why Should You Perform Requirements Documentation? - Blog des Fraunhofer IESE\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/10\\\/Doc_Requirement_Eddy_Blogbeitrag1.jpg\",\"datePublished\":\"2020-02-27T07:42:41+00:00\",\"dateModified\":\"2024-01-12T13:09:33+00:00\",\"description\":\"Why is requirements documentation so important? Fraunhofer IESE shows why it plays a central role in requirement engineering.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/10\\\/Doc_Requirement_Eddy_Blogbeitrag1.jpg\",\"contentUrl\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/10\\\/Doc_Requirement_Eddy_Blogbeitrag1.jpg\",\"width\":1138,\"height\":572,\"caption\":\"Fraunhofer IESE - Teil 1 Anforderungsdokumentation\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Startseite\",\"item\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Requirements Specification (1\\\/5): Why Should You Perform Requirements Documentation?\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/\",\"name\":\"Fraunhofer IESE\",\"description\":\"Blog des Fraunhofer-Institut f\u00fcr Experimentelles Software Engineering\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#organization\",\"name\":\"Fraunhofer IESE\",\"url\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2016\\\/08\\\/fhg_iese_logo.png\",\"contentUrl\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2016\\\/08\\\/fhg_iese_logo.png\",\"width\":183,\"height\":50,\"caption\":\"Fraunhofer IESE\"},\"image\":{\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/FraunhoferIESE\\\/\",\"https:\\\/\\\/x.com\\\/FraunhoferIESE\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/fraunhoferiese\\\/\",\"https:\\\/\\\/www.youtube.com\\\/c\\\/FraunhoferIESE\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/#\\\/schema\\\/person\\\/b184e099b02c6e1e095b3ed382561ecb\",\"name\":\"Dr. Eddy Groen\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2024\\\/07\\\/eddy_groen_C97A0141_web-96x96.jpgf5109aab11ebae41dacba69a72f8164f\",\"url\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2024\\\/07\\\/eddy_groen_C97A0141_web-96x96.jpg\",\"contentUrl\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/wp-content\\\/uploads\\\/2024\\\/07\\\/eddy_groen_C97A0141_web-96x96.jpg\",\"caption\":\"Dr. Eddy Groen\"},\"description\":\"Dr. Eduard C. Groen ist Senior Requirements Engineer & Projektleiter am Fraunhofer IESE und er koordiniert die Digitale Nachhaltigkeit. Seine Arbeit ist dom\u00e4nen\u00fcbergreifend und fokussiert sich auf das Digital Design komplexer Systeme (z. B. digitale \u00d6kosysteme oder das Internet of Things) und darauf, wie diese die Herausforderungen der Nachhaltigkeit bew\u00e4ltigen k\u00f6nnen. Neben beratenden T\u00e4tigkeiten in der Industrie \u00fcbernahm er u. a. leitende Funktionen in der Beratung von Bundesministerien zu digitalen Datenplattformen f\u00fcr die Landwirtschaft (BMEL), in der Weiterentwicklung der Forschung zu dynamischen Systems-of-Systems (\u00bbDynaSoS\u00ab; BMBF) sowie in Projekten im Bereich Usable Security & Privacy (\u00bbTrUSD\u00ab, \u00bbD\u2018accord\u00ab). Am Fraunhofer IESE ist er seit \u00fcber 10 Jahren Themenverantwortlicher f\u00fcr \u00bbCrowd-Based Requirements Engineering\u00ab. Neben seiner Arbeit am Fraunhofer IESE ist er beim International Requirements Engineering Board (IREB) Leiter der Special Interest Group on Sustainability. Er hat ein Master in der Psychologie von der Universit\u00e4t Twente und absolvierte 2025 seine Doktorarbeit an der Universit\u00e4t Utrecht, betreut von Prof. Dr. Sjaak Brinkkemper, Prof. Dr. Fabiano Dalpiaz und Prof. Dr.-Ing. J\u00f6rg D\u00f6rr. Als Wissenschaftler decken seine \u00fcber 25 Publikationen Themen wie Qualit\u00e4tsanforderungen, Nutzerfeedbackklassifikation, Digitale \u00d6kosysteme, gebrauchstauglicher Datenschutz, IoT und Nachhaltigkeit ab. Er ist u.a. Mitglied in den Hauptprogrammkomitees der Konferenzen REFSQ und RE, leitet den Industry-Innovation-Track der RE\u201926, leitete den Posters- und Tools-Track der REFSQ\u201920 und den Workshops-Track der REFSQ\u201925 und erhielt den Best Reviewer Award der REFSQ\u201923.\",\"sameAs\":[\"https:\\\/\\\/www.linkedin.com\\\/in\\\/eddygroen\\\/\"],\"url\":\"https:\\\/\\\/www.iese.fraunhofer.de\\\/blog\\\/author\\\/eddy-groen\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Requirements Specification (1\/5): Why Should You Perform Requirements Documentation? - Blog des Fraunhofer IESE","description":"Why is requirements documentation so important? Fraunhofer IESE shows why it plays a central role in requirement engineering.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/","og_locale":"de_DE","og_type":"article","og_title":"Requirements Specification (1\/5): Why Should You Perform Requirements Documentation? - Blog des Fraunhofer IESE","og_description":"Why is requirements documentation so important? Fraunhofer IESE shows why it plays a central role in requirement engineering.","og_url":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/","og_site_name":"Fraunhofer IESE","article_publisher":"https:\/\/www.facebook.com\/FraunhoferIESE\/","article_published_time":"2020-02-27T07:42:41+00:00","article_modified_time":"2024-01-12T13:09:33+00:00","og_image":[{"width":1138,"height":572,"url":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2019\/10\/Doc_Requirement_Eddy_Blogbeitrag1.jpg","type":"image\/jpeg"}],"author":"Dr. Eddy Groen, Dr. Matthias Koch, Phil St\u00fcpfert","twitter_card":"summary_large_image","twitter_creator":"@FraunhoferIESE","twitter_site":"@FraunhoferIESE","twitter_misc":{"Verfasst von":"Dr. Eddy Groen","Gesch\u00e4tzte Lesezeit":"11\u00a0Minuten","Written by":"Dr. Eddy Groen, Dr. Matthias Koch, Phil St\u00fcpfert"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/#article","isPartOf":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/"},"author":{"name":"Dr. Eddy Groen","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#\/schema\/person\/b184e099b02c6e1e095b3ed382561ecb"},"headline":"Requirements Specification (1\/5): Why Should You Perform Requirements Documentation?","datePublished":"2020-02-27T07:42:41+00:00","dateModified":"2024-01-12T13:09:33+00:00","mainEntityOfPage":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/"},"wordCount":1833,"publisher":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#organization"},"image":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/#primaryimage"},"thumbnailUrl":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2019\/10\/Doc_Requirement_Eddy_Blogbeitrag1.jpg","keywords":["Agile","English","Requirements Engineering"],"articleSection":["Digitale Transformation"],"inLanguage":"de"},{"@type":"WebPage","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/","url":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/","name":"Requirements Specification (1\/5): Why Should You Perform Requirements Documentation? - Blog des Fraunhofer IESE","isPartOf":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/#primaryimage"},"image":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/#primaryimage"},"thumbnailUrl":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2019\/10\/Doc_Requirement_Eddy_Blogbeitrag1.jpg","datePublished":"2020-02-27T07:42:41+00:00","dateModified":"2024-01-12T13:09:33+00:00","description":"Why is requirements documentation so important? Fraunhofer IESE shows why it plays a central role in requirement engineering.","breadcrumb":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/#primaryimage","url":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2019\/10\/Doc_Requirement_Eddy_Blogbeitrag1.jpg","contentUrl":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2019\/10\/Doc_Requirement_Eddy_Blogbeitrag1.jpg","width":1138,"height":572,"caption":"Fraunhofer IESE - Teil 1 Anforderungsdokumentation"},{"@type":"BreadcrumbList","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/requirements-specification-1-5-why-should-you-perform-requirements-documentation\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Startseite","item":"https:\/\/www.iese.fraunhofer.de\/blog\/"},{"@type":"ListItem","position":2,"name":"Requirements Specification (1\/5): Why Should You Perform Requirements Documentation?"}]},{"@type":"WebSite","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#website","url":"https:\/\/www.iese.fraunhofer.de\/blog\/","name":"Fraunhofer IESE","description":"Blog des Fraunhofer-Institut f\u00fcr Experimentelles Software Engineering","publisher":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.iese.fraunhofer.de\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#organization","name":"Fraunhofer IESE","url":"https:\/\/www.iese.fraunhofer.de\/blog\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2016\/08\/fhg_iese_logo.png","contentUrl":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2016\/08\/fhg_iese_logo.png","width":183,"height":50,"caption":"Fraunhofer IESE"},"image":{"@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/FraunhoferIESE\/","https:\/\/x.com\/FraunhoferIESE","https:\/\/www.linkedin.com\/company\/fraunhoferiese\/","https:\/\/www.youtube.com\/c\/FraunhoferIESE"]},{"@type":"Person","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/#\/schema\/person\/b184e099b02c6e1e095b3ed382561ecb","name":"Dr. Eddy Groen","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2024\/07\/eddy_groen_C97A0141_web-96x96.jpgf5109aab11ebae41dacba69a72f8164f","url":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2024\/07\/eddy_groen_C97A0141_web-96x96.jpg","contentUrl":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2024\/07\/eddy_groen_C97A0141_web-96x96.jpg","caption":"Dr. Eddy Groen"},"description":"Dr. Eduard C. Groen ist Senior Requirements Engineer & Projektleiter am Fraunhofer IESE und er koordiniert die Digitale Nachhaltigkeit. Seine Arbeit ist dom\u00e4nen\u00fcbergreifend und fokussiert sich auf das Digital Design komplexer Systeme (z. B. digitale \u00d6kosysteme oder das Internet of Things) und darauf, wie diese die Herausforderungen der Nachhaltigkeit bew\u00e4ltigen k\u00f6nnen. Neben beratenden T\u00e4tigkeiten in der Industrie \u00fcbernahm er u. a. leitende Funktionen in der Beratung von Bundesministerien zu digitalen Datenplattformen f\u00fcr die Landwirtschaft (BMEL), in der Weiterentwicklung der Forschung zu dynamischen Systems-of-Systems (\u00bbDynaSoS\u00ab; BMBF) sowie in Projekten im Bereich Usable Security & Privacy (\u00bbTrUSD\u00ab, \u00bbD\u2018accord\u00ab). Am Fraunhofer IESE ist er seit \u00fcber 10 Jahren Themenverantwortlicher f\u00fcr \u00bbCrowd-Based Requirements Engineering\u00ab. Neben seiner Arbeit am Fraunhofer IESE ist er beim International Requirements Engineering Board (IREB) Leiter der Special Interest Group on Sustainability. Er hat ein Master in der Psychologie von der Universit\u00e4t Twente und absolvierte 2025 seine Doktorarbeit an der Universit\u00e4t Utrecht, betreut von Prof. Dr. Sjaak Brinkkemper, Prof. Dr. Fabiano Dalpiaz und Prof. Dr.-Ing. J\u00f6rg D\u00f6rr. Als Wissenschaftler decken seine \u00fcber 25 Publikationen Themen wie Qualit\u00e4tsanforderungen, Nutzerfeedbackklassifikation, Digitale \u00d6kosysteme, gebrauchstauglicher Datenschutz, IoT und Nachhaltigkeit ab. Er ist u.a. Mitglied in den Hauptprogrammkomitees der Konferenzen REFSQ und RE, leitet den Industry-Innovation-Track der RE\u201926, leitete den Posters- und Tools-Track der REFSQ\u201920 und den Workshops-Track der REFSQ\u201925 und erhielt den Best Reviewer Award der REFSQ\u201923.","sameAs":["https:\/\/www.linkedin.com\/in\/eddygroen\/"],"url":"https:\/\/www.iese.fraunhofer.de\/blog\/author\/eddy-groen\/"}]}},"jetpack_featured_media_url":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2019\/10\/Doc_Requirement_Eddy_Blogbeitrag1.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/posts\/4315","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/comments?post=4315"}],"version-history":[{"count":13,"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/posts\/4315\/revisions"}],"predecessor-version":[{"id":4392,"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/posts\/4315\/revisions\/4392"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/media\/4365"}],"wp:attachment":[{"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/media?parent=4315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/categories?post=4315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/tags?post=4315"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.iese.fraunhofer.de\/blog\/wp-json\/wp\/v2\/coauthors?post=4315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}