{"id":1799,"date":"2026-06-12T08:00:00","date_gmt":"2026-06-12T06:00:00","guid":{"rendered":"https:\/\/datastorms.eu\/?p=1799"},"modified":"2026-07-08T10:01:36","modified_gmt":"2026-07-08T08:01:36","slug":"hoe-sluit-een-systems-engineering-plan-aan-op-bestaande-projectmethoden","status":"publish","type":"post","link":"https:\/\/datastorms.eu\/de\/2026\/06\/12\/hoe-sluit-een-systems-engineering-plan-aan-op-bestaande-projectmethoden\/","title":{"rendered":"Wie passt ein System-Engineering-Plan zu bestehenden Projektmethoden?"},"content":{"rendered":"<p>Ein Systems-Engineering-Plan schlie\u00dft an bestehende Projektmethoden an, indem er die technisch-inhaltliche Ebene eines Projekts neben der Planungs- und Steuerungsebene strukturiert, die Methoden wie PRINCE2 oder Agile ausf\u00fcllen. Der SE-Plan regelt <em>Was<\/em> ein System tun muss und wie das gezeigt wird; die Projektmethode regelt <em>Wie<\/em> Das Projekt wird organisiert und \u00fcberwacht. Die beiden erg\u00e4nzen sich, anstatt sich zu \u00fcberschneiden. In diesem Artikel beantworten wir die am h\u00e4ufigsten gestellten Fragen zu dieser Kombination: von den am h\u00e4ufigsten verwendeten Methoden bis hin zu konkreten Integrationspunkten und unterst\u00fctzenden Werkzeugen.<\/p>\n<h2>Welche Projektmethoden werden am h\u00e4ufigsten mit Systemtechnik kombiniert?<\/h2>\n<p>Systemtechnik wird in der Praxis am h\u00e4ufigsten mit PRINCE2, der Leitlinie Systemtechnik (LSE), Agile\/Scrum und in geringerem Ma\u00dfe mit IPMA-basierten Projektans\u00e4tzen kombiniert. Die Wahl einer bestimmten Kombination h\u00e4ngt stark vom Sektor ab: In der niederl\u00e4ndischen Infrastruktur- und Wasserwirtschaft dominiert die LSE, w\u00e4hrend softwaregesteuerte Projekte eher Agile mit SE-Prinzipien kombinieren.<\/p>\n<p>Was diese Methoden gemeinsam haben, ist, dass sie alle eine klare Beschreibung des zu realisierenden Systems ben\u00f6tigen. PRINCE2 bietet ein robustes Steuerungskonzept mit klaren Phasen, Go\/No-Go-Zeitpunkten und Berichtsstrukturen, sagt aber wenig dar\u00fcber aus, wie man technische Anforderungen verwaltet oder R\u00fcckverfolgbarkeit sicherstellt. Dort f\u00fcllt der System-Engineering-Plan die L\u00fccke.<\/p>\n<p>Die LSE wurde speziell f\u00fcr den niederl\u00e4ndischen Bausektor entwickelt und schlie\u00dft konzeptionell am engsten an die SE-Methodik an: Sie beschreibt objektorientierte Dekomposition, Anforderungsmanagement und Verifizierung auf eine Weise, die sich direkt in den Inhalt eines SE-Plans \u00fcbersetzt. In Projekten, in denen die LSE anwendbar ist, bildet der SE-Plan daher einen verpflichtenden oder dringend empfohlenen Bestandteil der Projektdokumentation.<\/p>\n<h2>Wie unterscheidet sich ein System-Engineering-Plan von einem Projektplan?<\/h2>\n<p>Ein Systems-Engineering-Plan beschreibt, wie der technisch-inhaltliche Ansatz eines Projekts gestaltet wird: welche SE-Prozesse verfolgt werden, wie Anforderungen verwaltet werden, wie Verifizierung und Validierung organisiert sind und wer daf\u00fcr verantwortlich ist. Ein Projektplan konzentriert sich auf Planung, Ressourcen, Risiken, Kommunikation und Steuerung des Projekts als Ganzes.<\/p>\n<p>Der Unterschied ist in der Praxis leicht zu merken: Der Projektplan beantwortet die Frage \u201cWie managen wir dieses Projekt?\u201d, w\u00e4hrend der SE-Plan beantwortet \u201cWie stellen wir sicher, dass das System alle gestellten Anforderungen erf\u00fcllt?\u201d Ein Projektmanager \u00fcberwacht Budget und Durchlaufzeit; der Systems Engineer \u00fcberwacht die technische Integrit\u00e4t und Nachweisbarkeit des Designs.<\/p>\n<p>In gr\u00f6\u00dferen Projekten sind beide Dokumente formell getrennt, aber sie verweisen aufeinander. Der SE-Plan legt beispielsweise fest, welche Verifikationsmeilensteine es gibt; der Projektplan nimmt diese Meilensteine in die Planung auf. Ohne diese Verkn\u00fcpfung entstehen blinde Flecken: Aktivit\u00e4ten, die inhaltlich notwendig sind, aber nie eingeplant werden.<\/p>\n<h2>Wo schlie\u00dft der SE-Plan konkret an einen bestehenden Projektplan an?<\/h2>\n<p>Der Systems-Engineering-Plan kn\u00fcpft an vier konkreten Punkten an einem Projektplan an: Meilensteine und \u00dcberpr\u00fcfungsmomente, Rollen und Verantwortlichkeiten, Risikomanagement und die Dokumentationsstruktur. An jedem dieser Punkte liefert der SE-Plan die technisch-inhaltliche Ausgestaltung, die das Projektplan ben\u00f6tigt, um vollst\u00e4ndig zu sein.<\/p>\n<ul>\n<li><strong>Meilensteine und Bewertungen<\/strong> Der SE-Plan definiert technische \u00dcberpr\u00fcfungspunkte wie eine System Requirements Review (SRR) oder eine Preliminary Design Review (PDR). Diese werden als Meilensteine in den Projektplan aufgenommen, damit sie auch tats\u00e4chlich eingeplant und finanziert werden.<\/li>\n<li><strong>Rollen und Verantwortlichkeiten:<\/strong> Der SE-Plan nennt die Verantwortlichen f\u00fcr Anforderungsmanagement, Verifikation und Konfigurationsmanagement. Diese Rollen werden im Projektplan an die Projektorganisation gespiegelt, damit keine \u00dcberschneidungen oder L\u00fccken entstehen.<\/li>\n<li><strong>Risikomanagement<\/strong> Technische Risiken, die aus dem SE-Prozess entstehen, wie unvollst\u00e4ndige Anforderungen oder nicht gesicherte Nachvollziehbarkeit, werden in das Risikoregister des Projekts eingebracht. So werden sie f\u00fcr den Projektmanager sichtbar und in die Steuerung einbezogen.<\/li>\n<li><strong>Dokumentationsstruktur:<\/strong> Der SE-Plan legt fest, welche technischen Dokumente wann geliefert werden. Diese Liefertermine werden als Liefergegenst\u00e4nde in den Projektplan aufgenommen, damit sie Teil der formellen Fortschritts\u00fcberwachung werden.<\/li>\n<\/ul>\n<p>Dieser Anschluss klingt selbstverst\u00e4ndlich, aber in der Praxis fehlt er regelm\u00e4\u00dfig. Die Folge ist, dass technische Aktivit\u00e4ten au\u00dferhalb der Projektkontrolle liegen und erst sichtbar werden, wenn es zu sp\u00e4t ist, um zu korrigieren.<\/p>\n<h2>Wie integriert man Systems Engineering in eine agile oder Scrum-Umgebung?<\/h2>\n<p>Systemingenieurwesen in Agile oder Scrum zu integrieren, erfordert die \u00dcbersetzung von SE-Aktivit\u00e4ten in die iterative Struktur von Sprints und Backlogs, ohne die systematische Sicherstellung von Anforderungen und R\u00fcckverfolgbarkeit aufzugeben. Der Kern des Ansatzes besteht darin, SE nicht als separate Phase zu behandeln, sondern als eine fortlaufende Aktivit\u00e4t, die parallel zu den Entwicklungsprints verl\u00e4uft.<\/p>\n<p>In der Praxis bedeutet dies, dass Anforderungen als strukturierte Backlog-Elemente mit expliziter R\u00fcckverfolgbarkeit zu h\u00f6heren Systemanforderungen verwaltet werden. Verifikationskriterien werden pro User Story oder Feature erfasst, sodass Abnahmetests direkt an der formalen Verifikationsmatrix ausgerichtet sind. Eine SE-Rolle, manchmal als Systemarchitekt oder technische Autorit\u00e4t bezeichnet, \u00fcberwacht den Zusammenhalt zwischen den iterativen Teil-L\u00f6sungen und dem \u00fcbergreifenden Systemdesign.<\/p>\n<p>Die gr\u00f6\u00dfte Herausforderung bei dieser Kombination ist die Wahrung der architektonischen Integrit\u00e4t. Agile arbeitet naturgem\u00e4\u00df inkrementell, was das Risiko birgt, dass lokale Entscheidungen in Sprints sp\u00e4ter mit systemweiten Anforderungen kollidieren. Ein guter SE-Plan bietet hier Halt: Er legt den stabilen Kern des Systems fest, w\u00e4hrend Agile den Raum gibt, die F\u00fcllung iterativ zu verfeinern. Dieses Gleichgewicht erfordert bewusste Absprachen und Werkzeuge, die beide Welten verbinden.<\/p>\n<h2>Welche Software unterst\u00fctzt die Verbindung zwischen SE-Plan und Projektmethoden?<\/h2>\n<p>Werkzeuge, die die Verbindung zwischen einem System-Engineering-Plan und Projektmethoden unterst\u00fctzen, m\u00fcssen mindestens drei Dinge k\u00f6nnen: Anforderungen und R\u00fcckverfolgbarkeit verwalten, den Verifizierungsstatus verfolgen und in die bereits verwendete Planungs- und Projektmanagementumgebung integrieren. Traditionelle Werkzeuge wie DOORS oder Cameo sind leistungsstark, aber f\u00fcr viele Teams zu teuer und zu komplex.<\/p>\n<p>In der Praxis arbeiten viele Teams noch mit einer Kombination aus Excel, Word und einem separaten Projektplanungssystem. Dieser Ansatz funktioniert bis zu einem gewissen Grad, bricht aber ab, sobald die R\u00fcckverfolgbarkeit manuell verfolgt werden muss oder wenn mehrere Disziplinen gleichzeitig an demselben System arbeiten. Audits und \u00dcberpr\u00fcfungen werden dann zu einer stressigen \u00dcbung anstatt eines selbstverst\u00e4ndlichen Schrittes.<\/p>\n<p><a href=\"https:\/\/datastorms.eu\/de\/\">Ons platform<\/a> biedt een toegankelijk alternatief dat specifiek is ontwikkeld voor systems engineers in de Nederlandse infra-, water- en maakindustrie. Vanuit \u00e9\u00e9n centrale omgeving beheer je eisen, leg je traceability vast, genereer je verificatiematrices en bewaak je de samenhang tussen systemen en deelsystemen. Via een uitgebreide API integreert het platform naadloos met de projectbeheerstools die jouw organisatie al gebruikt, zodat de aansluiting tussen SE-plan en projectmethoden niet alleen op papier bestaat, maar ook in de dagelijkse werkpraktijk werkt. Wil je zelf ervaren hoe dat werkt? Vraag een <a href=\"https:\/\/datastorms.eu\/de\/proeflicentie\/\">proeflicentie<\/a> aan en ontdek wat het platform voor jouw project kan betekenen.<\/p>\n<p>Die Wahl des Werkzeugs h\u00e4ngt letztendlich von der Skalierung des Projekts, dem Budget und den existierenden Arbeitsmethoden ab. W\u00e4hrend gro\u00dfe Programme von einer vollst\u00e4ndig integrierten Plattform profitieren, kann ein kleineres Projekt bereits viel mit einer strukturierten, zentralen Umgebung gewinnen, die Anforderungsmanagement und R\u00fcckverfolgbarkeit kombiniert. Das Wichtigste ist, dass das Werkzeug die Verbindung zwischen technischen und projektbezogenen Aktivit\u00e4ten sichtbar macht und nachverfolgt, anstatt diese Verbindung den Disziplinen einzelner Teammitglieder zu \u00fcberlassen.<\/p>\n        <div class=\"wp-block-seoaic-faq-block\">\n            <h2 class=\"seoaic-faq-section-title\">H\u00e4ufig gestellte Fragen<\/h2>\n                            <div class=\"seoaic-faq-item\">\n                    <h3 class=\"seoaic-question\">\n                        Wie ausf\u00fchrlich muss ein System-Engineering-Plan f\u00fcr ein kleines oder mittelgro\u00dfes Projekt sein?                    <\/h3>\n                    <p class=\"seoaic-answer\">\n                        Der Umfang eines SE-Plans skaliert mit der Komplexit\u00e4t und dem Risikoprofil des Projekts, nicht allein mit der Projektgr\u00f6\u00dfe. F\u00fcr ein kleines Projekt kann ein pr\u00e4gnanter SE-Plan von wenigen Seiten ausreichen, solange er die Kernbestandteile abdeckt: den SE-Ansatz, das Anforderungsmanagement, die Verifikationsstrategie und die wichtigsten Verantwortlichkeiten. Die Gefahr bei kleinen Projekten besteht darin, den SE-Plan ganz wegzulassen; das ist ein gr\u00f6\u00dferes Risiko als eine zu knappe Version.                    <\/p>\n                <\/div>\n                                <div class=\"seoaic-faq-item\">\n                    <h3 class=\"seoaic-question\">\n                        Was sind die h\u00e4ufigsten Fehler bei der Kombination eines SE-Plans mit PRINCE2?                    <\/h3>\n                    <p class=\"seoaic-answer\">\n                        Der am h\u00e4ufigsten gemachte Fehler ist, dass der SE-Plan und der Projektplan als vollst\u00e4ndig getrennte Dokumente behandelt werden, ohne explizite Verweise auf die Meilensteine, Rollen und Ergebnisse des jeweils anderen. Dies f\u00fchrt dazu, dass technische \u00dcberpr\u00fcfungsmomente wie ein PDR oder SRR niemals geplant oder finanziert werden. Ein zweiter h\u00e4ufiger Fehler ist, dass technische Risiken aus dem SE-Prozess nicht in das PRINCE2-Risikoregister aufgenommen werden, wodurch der Projektmanager ein unvollst\u00e4ndiges Bild der tats\u00e4chlichen Projektrisiken erh\u00e4lt.                    <\/p>\n                <\/div>\n                                <div class=\"seoaic-faq-item\">\n                    <h3 class=\"seoaic-question\">\n                        Wer ist verantwortlich f\u00fcr die Erstellung und Pflege des SE-Plans innerhalb eines Projekts?                    <\/h3>\n                    <p class=\"seoaic-answer\">\n                        Die Erstellung des SE-Plans liegt prim\u00e4r in der Verantwortung des leitenden Systemingenieurs oder des Systemarchitekten in Abstimmung mit dem Projektmanager. Die Pflege desselben ist eine geteilte Verantwortung: Der Systemingenieur wacht \u00fcber die technisch-inhaltliche Aktualit\u00e4t, w\u00e4hrend der Projektmanager sicherstellt, dass \u00c4nderungen an Zeitplan oder Umfang in den SE-Plan zur\u00fcck\u00fcbersetzt werden. In kleineren Teams werden diese Rollen manchmal kombiniert, aber es ist wichtig, dass die Verantwortung explizit zugewiesen ist und nicht implizit beim 'Team' liegt.                    <\/p>\n                <\/div>\n                                <div class=\"seoaic-faq-item\">\n                    <h3 class=\"seoaic-question\">\n                        Wie gehen Sie mit Anforderungs\u00e4nderungen w\u00e4hrend des Projekts um, ohne die R\u00fcckverfolgbarkeit zu verlieren?                    <\/h3>\n                    <p class=\"seoaic-answer\">\n                        \u00c4nderungen an Anforderungen sind unvermeidlich, aber sie werden beherrschbar, wenn Sie einen formellen \u00c4nderungsmanagementprozess als Teil des SE-Plans einrichten. Jede \u00c4nderung einer Anforderung muss erfasst, auf ihre Auswirkungen auf zugrunde liegende Anforderungen, das Design und die Verifizierung gepr\u00fcft und erst nach ausdr\u00fccklicher Genehmigung umgesetzt werden. Werkzeuge, die die R\u00fcckverfolgbarkeit automatisch verfolgen, machen diesen Prozess erheblich weniger arbeitsintensiv: Sie sehen sofort, welche Verifizierungsanforderungen und Systemkomponenten von einer Anforderungs\u00e4nderung betroffen sind, ohne manuell durch Matrizen suchen zu m\u00fcssen.                    <\/p>\n                <\/div>\n                                <div class=\"seoaic-faq-item\">\n                    <h3 class=\"seoaic-question\">\n                        Kann ein SE-Plan auch nachtr\u00e4glich erstellt werden, wenn das Projekt bereits gestartet ist?                    <\/h3>\n                    <p class=\"seoaic-answer\">\n                        Ja, das kann, aber es erfordert mehr Aufwand, als wenn der SE-Plan von Anfang an vorhanden ist. In der Praxis bedeutet ein nachtr\u00e4glicher SE-Plan, dass Sie zuerst die bestehenden Anforderungen, Designentscheidungen und Verifikationsaktivit\u00e4ten rekonstruieren und dokumentieren m\u00fcssen, bevor Sie den Ansatz formalisieren k\u00f6nnen. Der gr\u00f6\u00dfte Vorteil dieses Ansatzes ist, dass das Projekt f\u00fcr die verbleibenden Phasen, insbesondere f\u00fcr die Verifikation und die Auslieferung, immer noch eine strukturierte Grundlage erh\u00e4lt. Beginnen Sie in diesem Fall mit der Erfassung der Verifikationsstrategie und der R\u00fcckverfolgbarkeit, da diese den gr\u00f6\u00dften direkten Beitrag zu einem erfolgreichen Abschluss leisten.                    <\/p>\n                <\/div>\n                                <div class=\"seoaic-faq-item\">\n                    <h3 class=\"seoaic-question\">\n                        Wie stellen Sie sicher, dass der SE-Plan tats\u00e4chlich genutzt wird und nicht nur als Formalit\u00e4t in der Schublade verschwindet?                    <\/h3>\n                    <p class=\"seoaic-answer\">\n                        Ein SE-Plan wird erst dann wirklich genutzt, wenn er direkt mit der t\u00e4glichen Arbeit verkn\u00fcpft ist: Meilensteine sind in der Projektplanung enthalten, Rollen sind in der Projektorganisation anerkannt und Werkzeuge machen den Inhalt f\u00fcr alle, die damit arbeiten, zug\u00e4nglich. Regelm\u00e4\u00dfige SE-Reviews, bei denen der Status von Anforderungen und Verifizierung aktiv in Projektbesprechungen diskutiert wird, helfen, den Plan lebendig zu halten. Der Plan sollte als Arbeitsinstrument betrachtet werden, das mit dem Projekt mitw\u00e4chst, und nicht als einmalig zu lieferndes Dokument.                    <\/p>\n                <\/div>\n                                <div class=\"seoaic-faq-item\">\n                    <h3 class=\"seoaic-question\">\n                        Was ist der Unterschied zwischen Verifizierung und Validierung im Kontext eines SE-Plans und warum ist diese Unterscheidung praktisch wichtig?                    <\/h3>\n                    <p class=\"seoaic-answer\">\n                        Verifizierung beantwortet die Frage 'Bauen wir das System gem\u00e4\u00df den gestellten Anforderungen?' und wird durch Tests, Inspektionen, Analysen oder Demonstrationen nachgewiesen. Validierung beantwortet die Frage 'Bauen wir das richtige System f\u00fcr den beabsichtigten Benutzer?' und findet typischerweise im operativen Kontext oder mit Endbenutzern statt. Der Unterschied ist praktisch relevant, da Verifizierung und Validierung zu unterschiedlichen Zeitpunkten stattfinden, von verschiedenen Parteien durchgef\u00fchrt werden und separaten Planungs- und Budgetbedarf haben. Ein SE-Plan, der diesen Unterschied nicht explizit macht, f\u00fchrt in der Praxis bei der Abnahme zu Diskussionen dar\u00fcber, was genau nachgewiesen werden muss und von wem.                    <\/p>\n                <\/div>\n                        <\/div>\n        <h2>\u00c4hnliche Beitr\u00e4ge<\/h2><ul><li><a href=\"https:\/\/datastorms.eu\/de\/2026\/06\/28\/hoe-zorg-je-dat-een-systems-engineering-plan-begrijpelijk-blijft-voor-het-hele-team\/\">Wie stellt man sicher, dass ein Systemtechnikplan f\u00fcr das gesamte Team verst\u00e4ndlich bleibt?<\/a><\/li><li><a href=\"https:\/\/datastorms.eu\/de\/2026\/07\/22\/waarom-is-spreadsheetgebaseerd-eisenbeheer-een-risico-bij-complexe-projecten\/\">Waarom is spreadsheetgebaseerd eisenbeheer een risico bij complexe projecten?<\/a><\/li><li><a href=\"https:\/\/datastorms.eu\/de\/2026\/06\/27\/hoe-maak-je-een-systems-engineering-plan\/\">Wie erstellt man einen System-Engineering-Plan?<\/a><\/li><li><a href=\"https:\/\/datastorms.eu\/de\/2026\/06\/25\/hoe-weet-je-of-je-systems-engineering-plan-goed-genoeg-is\/\">Wie wei\u00dft du ob dein Systems-Engineering-Plan gut genug ist?<\/a><\/li><li><a href=\"https:\/\/datastorms.eu\/de\/2026\/07\/05\/hoe-gebruik-je-een-eisenregister-om-voortgang-inzichtelijk-te-maken-voor-opdrachtgevers\/\">Hoe gebruik je een eisenregister om voortgang inzichtelijk te maken voor opdrachtgevers?<\/a><\/li><\/ul>","protected":false},"excerpt":{"rendered":"<p>SE-plan en projectmethoden: hoe PRINCE2, Agile en LSE naadloos samenwerken met systems engineering.<\/p>","protected":false},"author":3,"featured_media":1880,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_improvement_type_select":"improve_an_existing","_thumb_yes_seoaic":false,"_frame_yes_seoaic":false,"seoaic_generate_description":"","seoaic_improve_instructions_prompt":"","seoaic_rollback_content_improvement":"","seoaic_idea_thumbnail_generator":"","thumbnail_generated":false,"thumbnail_generate_prompt":"","seoaic_article_description":"","neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","neve_meta_reading_time":"","_themeisle_gutenberg_block_has_review":false,"seoaic_article_subtitles":[],"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1799","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/posts\/1799","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/comments?post=1799"}],"version-history":[{"count":2,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/posts\/1799\/revisions"}],"predecessor-version":[{"id":2206,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/posts\/1799\/revisions\/2206"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/media\/1880"}],"wp:attachment":[{"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/media?parent=1799"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/categories?post=1799"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/datastorms.eu\/de\/wp-json\/wp\/v2\/tags?post=1799"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}