{"id":817,"date":"2026-02-25T10:25:08","date_gmt":"2026-02-25T10:25:08","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/"},"modified":"2026-02-25T10:25:08","modified_gmt":"2026-02-25T10:25:08","slug":"dfd-requirements-analysis","status":"publish","type":"docs","link":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/","title":{"rendered":"Requirements Analysis Phase: DFD Context Diagrams"},"content":{"rendered":"<p>When a stakeholder team stops debating whether a process is &#8220;a function&#8221; or &#8220;an object,&#8221; and instead begins agreeing on what data moves between systems and who owns it, you\u2019ve crossed into true requirements clarity. That moment\u2014when ambiguity dissolves into shared understanding\u2014is the signal that DFD context diagrams have done their job.<\/p>\n<p>As someone who\u2019s led requirements workshops across banking, healthcare, and logistics systems, I\u2019ve learned that teams don\u2019t need object models to identify data boundaries. They need a simple, shared map of data flow. That\u2019s why DFD context diagrams are not just a starting point\u2014they\u2019re the most effective lens for early requirements analysis.<\/p>\n<p>For over two decades, I\u2019ve seen teams wrestle with premature UML modeling, only to realize they were trying to define behavior before they had even agreed on what data was being transformed. DFD context diagrams prevent that trap. They force focus on facts: what data is exchanged, between whom, and when. This clarity is non-negotiable in regulated environments like finance and healthcare.<\/p>\n<p>This chapter walks through how to run a context diagram workshop, transition from DFD to detailed UML modeling, and avoid common pitfalls in early system analysis.<\/p>\n<h2>Why DFD Context Before UML: The Strategic Advantage<\/h2>\n<p>At the start of any project, teams often default to UML use case diagrams. But use cases begin with actor goals\u2014which are meaningful only when data flow is already understood.<\/p>\n<p>DFD context diagrams operate at the level of data exchange. They show the system as a single process, surrounded by external entities that send or receive data. This abstraction is powerful because it strips away behavior, implementation, and object identity\u2014focusing purely on what moves.<\/p>\n<p>Consider a claims processing system. In a UML use case, you might start with \u201cSubmit Claim\u201d or \u201cApprove Claim.\u201d But without knowing what data is in the claim\u2014patient ID, diagnosis codes, dates, amounts\u2014you\u2019re modeling outcomes before inputs are defined. The risk? Misaligned expectations, duplicated work, and rework.<\/p>\n<p>By contrast, a DFD context diagram asks: What data flows in and out? Who sends it? Who receives it? This question leads to faster consensus. It\u2019s not about how the system works\u2014but who it works for and what it exchanges.<\/p>\n<h3>When DFD Wins the Early Phase<\/h3>\n<p>Use DFD context diagrams when:<\/p>\n<ul>\n<li>Stakeholders are from multiple departments (finance, operations, IT) and need a common language.<\/li>\n<li>The system is expected to integrate with external systems (e.g., insurance providers, tax authorities).<\/li>\n<li>Compliance or auditability is a primary concern (e.g., HIPAA, SOX, GDPR).<\/li>\n<li>Legacy systems are being modernized and the as-is flow must be captured first.<\/li>\n<\/ul>\n<p>In all these cases, DFD models the <strong>what<\/strong> before the <strong>how<\/strong>. They\u2019re ideal for uncovering gaps in data handoff, identifying undocumented exchanges, and surfacing interface mismatches early.<\/p>\n<h2>Facilitating a Context Diagram Requirements Workshop<\/h2>\n<p>Running a successful DFD workshop isn\u2019t about drawing diagrams\u2014it\u2019s about guiding a conversation. My rule: never give a template first. Start with a whiteboard and a simple question:<\/p>\n<p><em>\u201cWhat data does this system need to receive? What data does it send?\u201d<\/em><\/p>\n<p>Invite stakeholders from business, IT, compliance, and operations. Avoid technical jargon. Use plain language: \u201cWhat\u2019s in the file?\u201d \u201cWho sends it?\u201d \u201cWho checks it?\u201d<\/p>\n<p>Build the context diagram collaboratively in 4 steps:<\/p>\n<ol>\n<li><strong>Identify the system boundary.<\/strong> Define the system under study\u2014e.g., \u201cClaims Processing System.\u201d<\/li>\n<li><strong>Identify external entities.<\/strong> Who sends or receives data? (e.g., \u201cPatient,\u201d \u201cInsurance Provider,\u201d \u201cRegulatory Agency\u201d)<\/li>\n<li><strong>Map data flows.<\/strong> Draw arrows labeled with the data being exchanged. Use verbs: \u201cClaim Form,\u201d \u201cPayment Notice,\u201d \u201cAudit Report.\u201d<\/li>\n<li><strong>Validate and refine.<\/strong> Ask: \u201cDoes this reflect actual business behavior? Is anything missing?\u201d<\/li>\n<\/ol>\n<p>My experience shows that this process takes 60\u201390 minutes and produces a usable, stakeholder-validated model. The diagram becomes a reference point for all future modeling.<\/p>\n<h3>Common Pitfalls in DFD Workshops<\/h3>\n<p>Watch for these red flags:<\/p>\n<ul>\n<li><strong>Overloading the system.<\/strong> If the system box contains multiple processes, it\u2019s not a context diagram anymore\u2014it\u2019s Level 0. Save that for later.<\/li>\n<li><strong>Confusing data flows with control or messages.<\/strong> DFDs don\u2019t model messages or triggers\u2014only data. Avoid terms like \u201capproval,\u201d \u201crequest,\u201d or \u201cnotification.\u201d Use \u201cApproved Claim,\u201d \u201cPayment Request,\u201d \u201cReport File.\u201d<\/li>\n<li><strong>Ignoring data at rest.<\/strong> External entities may store data (e.g., a database or file). That\u2019s valid\u2014just label it \u201cClaims File\u201d or \u201cPayment Archive.\u201d<\/li>\n<\/ul>\n<p>When these errors appear, pause and reframe: \u201cWhat data is actually moving? What\u2019s the payload?\u201d<\/p>\n<h2>Transitioning from DFD to UML: When and How<\/h2>\n<p>Once the context diagram is stable, the next step is not to jump into UML class diagrams. You must first validate and refine the data flow model.<\/p>\n<p>Use a <strong>transition checklist<\/strong> to determine readiness:<\/p>\n<ol>\n<li>Stakeholders agree on all data flows and external entities.<\/li>\n<li>All data flows are unambiguous (e.g., \u201cClaim Form\u201d not \u201cSome data\u201d).<\/li>\n<li>There are no conflicting or missing data exchanges.<\/li>\n<li>Stakeholders can explain the model without referring to diagrams.<\/li>\n<\/ol>\n<p>Only when these criteria are met should you proceed to UML modeling. The transition is not linear\u2014it\u2019s strategic.<\/p>\n<h3>Mapping DFD to UML: Key Translation Patterns<\/h3>\n<p>Here\u2019s how DFD elements map to UML:<\/p>\n<table>\n<tbody>\n<tr>\n<th>DFD Element<\/th>\n<th>UML Equivalent<\/th>\n<th>Mapping Rule<\/th>\n<\/tr>\n<tr>\n<td>External Entity<\/td>\n<td>Actor<\/td>\n<td>Map to actor if the entity initiates a business goal. Use \u201cStakeholder\u201d if passive.<\/td>\n<\/tr>\n<tr>\n<td>Process (System)<\/td>\n<td>Use Case<\/td>\n<td>Each major data transformation corresponds to a use case. E.g., \u201cProcess Claim\u201d \u2192 \u201cSubmit Claim\u201d.<\/td>\n<\/tr>\n<tr>\n<td>Data Flow<\/td>\n<td>Input\/Output<\/td>\n<td>Flow into system = input parameter; flow out = output result.<\/td>\n<\/tr>\n<tr>\n<td>Data Store<\/td>\n<td>Class (with persistence)<\/td>\n<td>Store data? Model as class with \u201cpersistent\u201d stereotype.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>These mappings are not one-to-one. The goal is not precision\u2014<strong>it\u2019s alignment<\/strong>. A DFD process like \u201cValidate Claim\u201d may map to multiple UML use cases: \u201cVerify Patient Eligibility,\u201d \u201cCheck Diagnosis Code,\u201d \u201cConfirm Coverage.\u201d<\/p>\n<p>Use this mapping to build the UML use case diagram. Then, validate it with stakeholders: \u201cDoes this reflect the data flow we agreed on?\u201d If not, return to the DFD.<\/p>\n<h2>DFD Early Requirements Phase: Best Practices<\/h2>\n<p>Adopt these practices in your next DFD workshop:<\/p>\n<ul>\n<li><strong>Start with the business, not the system.<\/strong> Ask: \u201cWho does this system serve?\u201d<\/li>\n<li><strong>Use real-world data names.<\/strong> \u201cInvoice\u201d not \u201cData Set 3.\u201d<\/li>\n<li><strong>Label every data flow.<\/strong> No blank arrows.<\/li>\n<li><strong>Limit external entities to 6\u20138.<\/strong> More than that, and the system is too complex to model at this level.<\/li>\n<li><strong>Document assumptions.<\/strong> Note: \u201cAssumes all claims are submitted electronically.\u201d<\/li>\n<\/ul>\n<p>These habits prevent over-complexity and ensure the model remains usable for business stakeholders.<\/p>\n<h2>Frequently Asked Questions<\/h2>\n<h3>Can I use DFD context diagrams for web applications?<\/h3>\n<p>Yes\u2014especially when the app integrates with third-party APIs, payment gateways, or user data. The DFD focus on data exchange makes it ideal for identifying integration points and audit trails.<\/p>\n<h3>Should I use DFD or UML first in agile projects?<\/h3>\n<p>Always start with DFD in the early discovery phase. It helps define scope and data needs before sprint planning. Use UML during sprint refinement for detailed modeling.<\/p>\n<h3>What if stakeholders don\u2019t understand DFD?<\/h3>\n<p>Start with a simple example: \u201cThink of the system as a box. What data goes in? What comes out?\u201d Use analogies like \u201cmail carrier\u201d or \u201cbank teller.\u201d The model becomes intuitive once they see how data moves.<\/p>\n<h3>How detailed should a context diagram be?<\/h3>\n<p>Keep it simple: 1 system, 4\u20138 entities, 6\u201312 data flows. The goal is clarity, not completeness. Add detail in Level 1 DFDs after the context is validated.<\/p>\n<h3>Can DFDs replace use case diagrams?<\/h3>\n<p>No\u2014they serve different purposes. DFDs show data movement. Use case diagrams show business goals. Use both: DFD for analysis, use case for planning.<\/p>\n<h3>Is there a risk of over-relying on DFD in early phases?<\/h3>\n<p>Yes\u2014only if you skip validation. DFDs must be reviewed by stakeholders. If they can\u2019t explain what a flow means, you haven\u2019t achieved shared understanding. Always validate with \u201cWhat if this flow doesn\u2019t exist?\u201d<\/p>\n<p>When you see a team stop arguing about object behavior and start debating what data is exchanged, you know they\u2019re ready. That\u2019s when DFD context diagrams have done their job. The rest\u2014UML modeling, detailed design, and validation\u2014follows naturally.<\/p>\n<p>Master the <strong>context diagram requirements workshop<\/strong>, and you\u2019ve already solved half the project\u2019s complexity before writing a single line of code.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>When a stakeholder team stops debating whether a process is &#8220;a function&#8221; or &#8220;an object,&#8221; and instead begins agreeing on what data moves between systems and who owns it, you\u2019ve crossed into true requirements clarity. That moment\u2014when ambiguity dissolves into shared understanding\u2014is the signal that DFD context diagrams have done their job. As someone who\u2019s [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":816,"menu_order":0,"template":"","meta":{"_acf_changed":false,"inline_featured_image":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"doc_tag":[],"class_list":["post-817","docs","type-docs","status-publish","hentry"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>DFD Context Diagrams for Requirements Analysis<\/title>\n<meta name=\"description\" content=\"Use DFD context diagrams in the early requirements phase to model stakeholder data exchange clearly, avoid premature OO modeling, and support effective workshops.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/\" \/>\n<meta property=\"og:locale\" content=\"id_ID\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"DFD Context Diagrams for Requirements Analysis\" \/>\n<meta property=\"og:description\" content=\"Use DFD context diagrams in the early requirements phase to model stakeholder data exchange clearly, avoid premature OO modeling, and support effective workshops.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/\" \/>\n<meta property=\"og:site_name\" content=\"Visual Paradigm Skills Indonesia\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Estimasi waktu membaca\" \/>\n\t<meta name=\"twitter:data1\" content=\"7 menit\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/\",\"name\":\"DFD Context Diagrams for Requirements Analysis\",\"isPartOf\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#website\"},\"datePublished\":\"2026-02-25T10:25:08+00:00\",\"description\":\"Use DFD context diagrams in the early requirements phase to model stakeholder data exchange clearly, avoid premature OO modeling, and support effective workshops.\",\"breadcrumb\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/#breadcrumb\"},\"inLanguage\":\"id\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/skills.visual-paradigm.com\/id\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Data Flow Diagrams vs. UML: When to Use Each\",\"item\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Practical Implementation Patterns\",\"item\":\"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"Requirements Analysis Phase: DFD Context Diagrams\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#website\",\"url\":\"https:\/\/skills.visual-paradigm.com\/id\/\",\"name\":\"Visual Paradigm Skills Indonesia\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/skills.visual-paradigm.com\/id\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"id\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#organization\",\"name\":\"Visual Paradigm Skills Indonesia\",\"url\":\"https:\/\/skills.visual-paradigm.com\/id\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"id\",\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/skills.visual-paradigm.com\/id\/wp-content\/uploads\/sites\/7\/2026\/02\/favicon.svg\",\"contentUrl\":\"https:\/\/skills.visual-paradigm.com\/id\/wp-content\/uploads\/sites\/7\/2026\/02\/favicon.svg\",\"width\":70,\"height\":70,\"caption\":\"Visual Paradigm Skills Indonesia\"},\"image\":{\"@id\":\"https:\/\/skills.visual-paradigm.com\/id\/#\/schema\/logo\/image\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"DFD Context Diagrams for Requirements Analysis","description":"Use DFD context diagrams in the early requirements phase to model stakeholder data exchange clearly, avoid premature OO modeling, and support effective workshops.","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:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/","og_locale":"id_ID","og_type":"article","og_title":"DFD Context Diagrams for Requirements Analysis","og_description":"Use DFD context diagrams in the early requirements phase to model stakeholder data exchange clearly, avoid premature OO modeling, and support effective workshops.","og_url":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/","og_site_name":"Visual Paradigm Skills Indonesia","twitter_card":"summary_large_image","twitter_misc":{"Estimasi waktu membaca":"7 menit"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/","url":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/","name":"DFD Context Diagrams for Requirements Analysis","isPartOf":{"@id":"https:\/\/skills.visual-paradigm.com\/id\/#website"},"datePublished":"2026-02-25T10:25:08+00:00","description":"Use DFD context diagrams in the early requirements phase to model stakeholder data exchange clearly, avoid premature OO modeling, and support effective workshops.","breadcrumb":{"@id":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/#breadcrumb"},"inLanguage":"id","potentialAction":[{"@type":"ReadAction","target":["https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/dfd-requirements-analysis\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/skills.visual-paradigm.com\/id\/"},{"@type":"ListItem","position":2,"name":"Data Flow Diagrams vs. UML: When to Use Each","item":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/"},{"@type":"ListItem","position":3,"name":"Practical Implementation Patterns","item":"https:\/\/skills.visual-paradigm.com\/id\/docs\/dfd-vs-uml-when-to-use-each\/practical-implementation-patterns\/"},{"@type":"ListItem","position":4,"name":"Requirements Analysis Phase: DFD Context Diagrams"}]},{"@type":"WebSite","@id":"https:\/\/skills.visual-paradigm.com\/id\/#website","url":"https:\/\/skills.visual-paradigm.com\/id\/","name":"Visual Paradigm Skills Indonesia","description":"","publisher":{"@id":"https:\/\/skills.visual-paradigm.com\/id\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/skills.visual-paradigm.com\/id\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"id"},{"@type":"Organization","@id":"https:\/\/skills.visual-paradigm.com\/id\/#organization","name":"Visual Paradigm Skills Indonesia","url":"https:\/\/skills.visual-paradigm.com\/id\/","logo":{"@type":"ImageObject","inLanguage":"id","@id":"https:\/\/skills.visual-paradigm.com\/id\/#\/schema\/logo\/image\/","url":"https:\/\/skills.visual-paradigm.com\/id\/wp-content\/uploads\/sites\/7\/2026\/02\/favicon.svg","contentUrl":"https:\/\/skills.visual-paradigm.com\/id\/wp-content\/uploads\/sites\/7\/2026\/02\/favicon.svg","width":70,"height":70,"caption":"Visual Paradigm Skills Indonesia"},"image":{"@id":"https:\/\/skills.visual-paradigm.com\/id\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/docs\/817","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":0,"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/docs\/817\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/docs\/816"}],"wp:attachment":[{"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/media?parent=817"}],"wp:term":[{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/skills.visual-paradigm.com\/id\/wp-json\/wp\/v2\/doc_tag?post=817"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}