Methodology Landscape — Idea to Documentation#

This is a broad survey of idea→documentation methodologies, conducted in service of building an AI-guided staged-pipeline tool (raw idea → full project documentation). RUP (Rational Unified Process) is one lineage among several surveyed here, not the default or the centerpiece — modern lean, agile, and continuous-discovery practice gets equal weight, since much of today's product work no longer runs through RUP-style artifacts at all. The goal is to catalog real methodologies/artifacts across the full span from fuzzy idea to buildable spec, so a pipeline can be designed deliberately rather than by copying one tradition.

How to read this#

Every methodology or artifact below is captured with three consistent hooks:

Input — what has to exist before this artifact/activity can start.
Output — what it produces.
Completeness — the exit/done criteria that justify moving on to whatever consumes this output next.

These three hooks are intentionally the join points our future pipeline will use to chain stages: one stage's Output becomes the next stage's Input, and a stage's Completeness criteria become the gate an AI-guided pipeline checks before advancing.

Confidence markers inherited from the source research are preserved inline: 🧩 = grounded in a directly-fetched primary/official source; 🤔 = grounded only via secondary sources or inference, flagged as weaker evidence. Where a partial did not mark individual claims, the claim is treated as 🧩 if it cites a directly-fetched primary/official source in the surrounding text, otherwise gaps are listed in the Grounding Caveats section rather than invented confidence.

1. RUP / Unified Process Artifacts#

RUP (Rational Unified Process) is IBM's iterative software-development process built around use-case-driven, architecture-centric, risk-managed delivery across Inception / Elaboration / Construction / Transition phases. As a full process it is widely regarded as too heavyweight for most teams today, but its artifact definitions (vision, actors, use cases, supplementary specs, traceability) remain a de-facto vocabulary still taught and used piecemeal inside Agile and hybrid methods.

Modern consensus on relevance: commentary through 2026 converges on "RUP-as-process is largely retired (IBM deprecated the Rational tooling push; OpenUP forked a lightweight Agile subset in 2006), but RUP-as-vocabulary survives" — teams still say "actor," "use case," "supplementary specification," and reuse the artifact templates without adopting the full phase/discipline machinery. It is explicitly recommended today mainly for complex, multi-team, regulated builds; for ordinary product work its ideas get absorbed into lighter processes. Sources: RUP (Rational Unified Process) in 2026, Rational unified process — Wikipedia.

Vision document#

Input: stakeholder interviews, business opportunity/problem statement, high-level feature wish-lists from customers and sponsors.
Output: a short stakeholder-facing document stating the product's key needs, features, and main constraints — written as a "contractual basis" that the later, more detailed Software Requirements Specification (SRS) is built from.
Completeness: considered done when it covers stakeholder needs and target features at a level sufficient to derive detailed requirements from it — it is explicitly positioned as an input to the SRS, not a final technical spec.
Sources: Artifact: Vision, Artifact: Vision (UHCL mirror).

Actors#

Input: the vision document plus a "common vocabulary" capture activity that identifies everyone/everything that interacts with the system (users, external systems, roles).
Output: a named, bounded list of actors (human roles and external systems) that participate in use cases — the entry point to the use-case model.
Completeness: an actor set is "done enough" when every role or external system that initiates or participates in a use case has been named and distinguished (no leftover unnamed "the user" placeholders feeding into use-case authoring).
Source: Artifact: Business Use-Case Model.

Use-case model#

Input: the actor list plus the vision document's feature/need statements (activity: "Find Actors and Use Cases").
Output: a structured package of use cases, actors, their relationships, and diagrams organizing system scope — the map that behavioral requirements hang off of.
Completeness: judged complete when it captures required system behavior from the end-user's goal-achieving perspective without extraneous content, and the model is internally consistent (relationships justified, no orphan actors/use cases).
Sources: Artifact: Use Case, Artifact: Business Vision.

Use-case specification#

Input: a single use case drawn from the use-case model, cross-referenced against "Capture a Common Vocabulary," "Detail the Software Requirements," "Design the User Interface," and "Define Test Details" activities — i.e. it gets refined iteratively by requirements, design, and test work, not written once.
Output: a textual description of what the system does for that use case: flow of events, preconditions, postconditions, special requirements, extension points, plus supporting UML diagrams.
Completeness: per RUP's own quality checklist, a use-case specification is "done enough" when (a) it accurately describes the relevant functionality without extraneous content, (b) the flow of events stays readable and purposeful, (c) diagrams/relationships are justified, consistent, and clear, and (d) preconditions/postconditions/special requirements meet quality standards. RUP also phases the order of completeness: major/architecturally-significant use cases get fully detailed during Elaboration; the remainder are detailed later, during Construction — i.e. "done enough to advance" is deliberately staged, not all-or-nothing.
Source: Artifact: Use Case.

Supplementary specification (non-functional requirements)#

Input: requirements that don't fit cleanly into a behavioral use case — legal/regulatory constraints, application standards, quality attributes, and environment/compatibility constraints, elicited alongside the use-case model.
Output: a single document capturing both functional "global" requirements (ones that cut across many use cases) and non-functional requirements, conventionally organized under the FURPS+ categories: Usability, Reliability, Performance, Supportability (+ Design constraints, Implementation, Interface, Physical).
Completeness: considered adequate when every FURPS+ category has been explicitly addressed (populated or explicitly marked not-applicable) and the attributes are stated in a form that can be verified/tested later (e.g., measurable performance/availability targets) rather than left as vague quality adjectives.
Sources: Artifact: Supplementary Specifications, Artifact: Software Requirements Specification.

2. Requirements-Engineering Standards#

ISO/IEC/IEEE 29148:2018#

Input: stakeholder/business needs and context from earlier lifecycle processes (ISO/IEC/IEEE 15288/12207 system/software life-cycle processes), captured through elicitation activities the standard itself scopes under "requirements processes."
Output: a defined family of information-item documents, each scoped to a different audience/technical level: Business Requirements Specification (BRS), Stakeholder Requirements Specification (StRS), System Requirements Specification (SyRS), and Software Requirements Specification (SRS) — the standard specifies expected content and the well-formed-requirement construct for each, while leaving section ordering flexible.
Completeness: the standard makes completeness measurable rather than subjective — it defines 9 quality characteristics that judge a single requirement (e.g., necessary, verifiable, unambiguous) and 5 further characteristics that judge the requirement set as a whole (e.g., complete, consistent). A document is "done enough" when its requirements individually and collectively satisfy these defined criteria, not merely when every known need has been transcribed.
Sources: ISO/IEC/IEEE 29148:2018 — iso.org, ISO 29148 Explained, ISO/IEC/IEEE 29148 Requirements Specification Templates — ReqView.

BABOK (Business Analysis Body of Knowledge, IIBA)#

Input: organizational/business context, stakeholder access, and an elicitation plan — BABOK treats "Business Analysis Planning and Monitoring" as the knowledge area that sets up what gets elicited and how.
Output: not a single document but a set of business-analysis information deliverables produced across six knowledge areas — elicitation results, requirements (business/stakeholder/solution/transition), process and data models, UI designs, solution options, and a defined solution scope.
Completeness: BABOK frames completeness procedurally rather than as a document checklist: it is reached via its "Requirements Life Cycle Management" knowledge area, which governs tracing, maintaining, prioritizing, and approving requirements until they are validated against the business need and approved for use — i.e. "done" = requirements have passed through elicitation, analysis/design definition, and life-cycle management with stakeholder sign-off, not just "written down."
Sources: BABOK — IIBA guide overview, Adaptive US, The 6 BABOK Knowledge Areas Explained.

Volere requirements template (incl. snow cards)#

Input: systematic discovery across stakeholder context (client, customers, end-users, personas), constraints (technology, schedule, budget, environment), current business processes, and actor capabilities/accessibility needs — Volere explicitly expects practitioners to gather this input rather than start from pre-formed requirements.
Output: a 27-section specification spanning strategic elements (purpose, goals, stakeholders), functional specs (use cases, functional requirements), non-functional properties (usability, performance, security, compliance), and planning documents (risks, cost, migration, training). The atomic unit is the "snow card" (Volere Requirements Shell): one requirement per card with Description, Rationale, Originator, Fit Criterion, Customer Satisfaction/Dissatisfaction, Priority, Conflicts, Supporting Materials, History, Requirement #, Requirement Type, and Event/Use-Case #.
Completeness: a requirement is "done" at the atomic level when it has a measurable fit criterion (making it testable) — Volere's stated philosophy is "start testing requirements as soon as you start writing them." At the specification level, completeness is treated as an iterative state, not a final gate: every one of the 27 sections should be addressed (even if marked not-applicable), every requirement should trace back to a business use case, and an explicit "open issues"/waiting-room section records what's still unresolved rather than blocking progress.
Sources: Volere Requirements Specification Template, Volere Atomic Requirements / Snow Cards, Volere Atomic Requirements Template — Modern Analyst.

IREB / CPRE (Certified Professional for Requirements Engineering)#

Input: no fixed document input — IREB CPRE is a certification body of knowledge (syllabus), not a project artifact pipeline. Its "input" is a practitioner's existing requirements-engineering practice, assessed against a standardized curriculum.
Output: not a project deliverable but a competency framework and syllabus, covering (per the Foundation Level syllabus): introduction/foundations, systems and system context, requirements elicitation, requirements documentation (natural-language and model-based), requirements validation and negotiation, requirements management, and tool support.
Completeness: "done enough" is defined by certification, not by a document — a practitioner is considered to hold the competency once they pass the Foundation Level exam built on the published syllabus, which targets "advanced beginner" core knowledge reinforced through practical exercises. IREB does not itself prescribe when a given project's requirements set is complete; it trains the judgment used to apply other standards (like ISO 29148) to make that call.
Sources: IREB CPRE Foundation Level syllabus (gasq.org, PDF), International Requirements Engineering Board — Wikipedia.

3. Agile Requirements#

User Story (Connextra template: "As a… I want… so that…")#

Input: team/stakeholder conversation about who needs something and why; a role, a desired capability, a business reason. Origin: the "role-feature-reason" format was invented at Connextra (UK) in 2001 by Rachel Davies. Sources: Agile Alliance glossary, Mountain Goat Software.
Output: a short written artifact — "As a [role], I want [goal], so that [benefit]" — a placeholder for a future conversation, not a full spec.
Completeness: Agile Alliance frames the template as "training wheels" — it is complete enough once it names the user, the capability, and the value; it is explicitly NOT meant to carry full detail (detail is deferred to conversation and acceptance criteria). Source: Agile Alliance glossary.

INVEST Criteria#

Input: a drafted user story (any template).
Output: a pass/fail quality judgment against six dimensions: Independent, Negotiable, Valuable, Estimable, Small, Testable. Published by Bill Wake in 2003. Sources: Wikipedia — User story (cites Wake 2003), Medium — INVEST in Small User Stories.
Completeness: a story is "ready to estimate/build" when it satisfies all six letters; failing any one (e.g. not Small, not Testable) signals the story must be split or clarified before entering a sprint.

Acceptance Criteria#

Input: the user story plus domain/business rules that define "working as intended" for that story.
Output: a checklist or condition set (often Given/When/Then, see BDD/Gherkin below) attached to the story.
Completeness: the story cannot be called Done until every acceptance criterion is demonstrably met; acceptance criteria are the operational bridge between a one-line story and Definition of Done. Documented as standard practice in Mountain Goat Software and the Scrum Guide DoD framing below.

Jeff Patton — User Story Mapping#

Input: the end-to-end user journey (activities a user performs) plus the backlog of candidate stories.
Output: a two-dimensional map — backbone of user activities/tasks arranged left-to-right by narrative flow, with stories stacked vertically beneath each activity by priority/release slice. Three guiding principles: "plan to build less, plan to learn faster, plan to finish on time." Sources: Agile Alliance — User Story Mapping, corroborated by TheScrumMaster.co.uk book summary.
Completeness: 🤔 the map is usable once it has a full backbone (whole journey represented, not just one slice) and at least one horizontal "walking skeleton" release slice identified beneath it — the exit criterion is "whole story told," not exhaustive detail at every step. (Exact "walking skeleton" wording comes from secondary book-summary sources, not a direct fetch of Patton's own text — see Grounding Caveats.)

BDD / Gherkin (Given-When-Then)#

Input: an acceptance criterion or business rule in natural language, scoped to one Feature.
Output: a Gherkin document — Feature containing one or more Scenarios, each built from Given (precondition) / When (action) / Then (expected outcome), optionally And/But/Background/Scenario Outline + Examples for data-driven cases. This is an executable specification: input to Cucumber, which runs it as a test. Source: Cucumber Gherkin Reference.
Completeness: a scenario is well-formed when it follows the Given→When→Then order, recommended at 3–5 steps, and contains no duplicate step text; a Feature is complete when its scenarios collectively cover the business rule's stated behaviors (🤔 the canonical source gives no numeric or formal completeness threshold beyond style rules — see Grounding Caveats).

Definition of Ready (DoR) / Definition of Done (DoD)#

Input (DoR): a raw Product Backlog Item.
Output (DoR): a team-agreed checklist marking a PBI "ready for Sprint Planning" — e.g. sized, dependencies known, acceptance criteria attached. Not part of the official Scrum Guide — it is an optional/community practice. Source: Scrum.org.
Input (DoD): a completed Increment / set of PBIs worked during a Sprint.
Output (DoD): "a formal description of the state of the Increment when it meets the quality measures required for the product" — a shared checklist (tests pass, code reviewed, documented, etc.). This IS formally part of the Scrum Guide. Sources (2020 Scrum Guide language, quoted via): MeisterTask, Atlassian.
Completeness: DoD is a binary gate — "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review." DoR has no such formal enforcement; it is a team heuristic, not a release gate. 🤔 The 2020 Scrum Guide primary text itself could not be fetched directly in this pass — these claims rest on secondary sources quoting it (see Grounding Caveats).

4. Customer Development & Lean#

Steve Blank — Customer Development (4 steps)#

Input: founders' initial vision, expressed as a set of business-model hypotheses (not yet facts).
Output: validated/invalidated hypotheses progressing through four steps — (1) Customer Discovery: turn vision into hypotheses, test via customer conversations; (2) Customer Validation: test whether the business model is repeatable and scalable, prove people will buy; (3) Customer Creation: build end-user demand and drive it into the sales channel; (4) Company Building: transition from startup structure to a company executing a validated model. Sources: Wikipedia — Customer development, cross-checked via Driverless Crocodile.
Completeness: exit from Discovery/Validation requires facts (paying customers, repeatable sales process), not opinions; Blank notes most startup failure comes from skipping or skimping on these first two steps — i.e., the explicit exit criterion is "model unarguably repeatable and scalable" before proceeding to Creation.

Eric Ries — Lean Startup (Build-Measure-Learn, MVP, Validated Learning)#

Input: a leap-of-faith hypothesis about customers/product.
Output: an MVP ("the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort") built to generate actionable metrics; the loop cycles Build → Measure → Learn, producing a pivot-or-persevere decision. Source: Lean Startup: Build-Measure-Learn, MVP, concept canonical to Ries's 2011 "The Lean Startup."
Completeness: a learning cycle is complete when it produces "validated learning" — evidence-backed knowledge about what customers want — not merely something shipped; "any work that does not produce validated learning is considered waste," making the explicit exit criterion evidence, not output volume.

Lean Canvas (Ash Maurya)#

Input: a startup idea with an unproven customer/problem fit (explicitly for founders who have "not found their customer yet").
Output: a one-page, nine-block canvas: Problem, Customer Segments, Unique Value Proposition, Solution, Channels, Revenue Streams, Cost Structure, Key Metrics, Unfair Advantage. Adapted from the Business Model Canvas by replacing 4 "running-a-business" blocks with 4 "starting-a-business" blocks. Sources: Koji — Lean Canvas Guide, Black Ventures — The Lean Canvas.
Completeness: Maurya's own ordering treats the canvas as complete for a first pass once every block has at least one entry, starting with Customer Segments+Problem and ending with Key Metrics+Unfair Advantage last — explicitly a fast, falsifiable first draft, not a finished business plan.

Business Model Canvas (Alexander Osterwalder / Strategyzer)#

Input: an existing or planned business model to document/analyze (not restricted to pre-customer startups).
Output: a one-page, nine-block canvas: Customer Segments, Value Propositions, Channels, Customer Relationships, Revenue Streams (value-capture side) + Key Resources, Key Activities, Key Partnerships, Cost Structure (value-creation side). Published in Business Model Generation (Osterwalder & Pigneur, 2010), developed from Osterwalder's 2004 doctoral thesis. Sources: Strategyzer — Business Model Generation summary, Linden Innovation.
Completeness: 🤔 the canvas is complete when all nine blocks are populated and mutually consistent (e.g. cost structure/revenue streams reconcile with activities/resources needed to deliver the stated value propositions) — sources describe this as structural completeness, not a validated/proven state (BMC carries no built-in validation step, unlike Lean Canvas's Key Metrics block — see Grounding Caveats).

5. Continuous Discovery#

Teresa Torres — Opportunity-Solution Tree + Continuous Discovery Habits#

Input: a single desired (business) outcome at the root, plus ongoing customer-interview evidence — Torres recommends 3–4 story-based interviews before starting a first tree. Source: Product Talk — Opportunity Solution Tree.
Output: a four-level tree: Desired Outcome → Opportunities (customer needs/pains/desires surfaced from interviews) → Solutions (candidate responses to a chosen opportunity) → Assumption Tests (experiments validating a solution). The "five continuous discovery habits": weekly customer interviews, opportunity mapping, surfacing/testing assumptions, continuous small experiments, whole product-trio involvement (PM/design/engineering). Sources: Product Talk, Great Question — Continuous Discovery Habits.
Completeness: explicitly NOT a one-time completion gate — the opportunity space is refreshed "every three to four customer interviews"; a target opportunity is selected after a "first draft" rather than a perfected tree; a tree's life ends (new tree started) only when the root outcome itself changes. Exit criterion for a solution branch is risk tolerance being met via assumption tests, not certainty.

Jobs-To-Be-Done (JTBD) — Christensen theory / Ulwick Outcome-Driven Innovation (ODI)#

Input: customer behavior/context around a recurring task; Ulwick's ODI formalizes this as a "core functional job" stated in a single solution-free sentence (e.g., "cut a piece of wood in a straight line") plus customer-defined desired-outcome statements (a market typically yields 50–150 measurable outcomes). JTBD theory itself: Clayton Christensen, The Innovator's Solution (2003), crediting Ulwick's prior ODI work (Ulwick began applying this in 1990, named ODI in 1999). Sources: Strategyn — Jobs-to-be-Done, Strategyn — History of JTBD.
Output: a Job Map (the job's 8 universal steps: define, locate, prepare, confirm, execute, monitor, modify, conclude) plus quantified Outcome Data (importance × satisfaction ratings per desired outcome) and outcome-based customer segments.
Completeness: ODI's explicit exit/scoring mechanism is the "Opportunity Algorithm" (opportunity score = importance + max(importance − satisfaction, 0)) which flags under-served (high-importance/low-satisfaction) outcomes as validated innovation opportunities; Ulwick cites an 86% success rate for ODI-driven innovation vs. ~17% industry average as the claimed real-world validation of the method. Source: Strategyn.

6. Design Process & UX#

Design Thinking (Stanford d.school, 5 modes)#

Input: a problem space / design challenge and access to real users or stakeholders to observe and interview.
Output: the d.school "Bootleg Deck" of methods/cards organized into 5 non-linear modes — Empathize, Define, Ideate, Prototype, Test — each producing its own intermediate artifact (research notes, a point-of-view/problem statement, a shortlist of concepts, a prototype, test feedback).
Completeness: 🧩 the d.school explicitly frames the 5 modes as non-linear and iterative, not a strict waterfall — teams run them in parallel, out of order, and repeat as needed; there is no single terminal "done" gate per mode, completion is judged by whether the mode's intermediate artifact (empathy data, problem statement, concept set, prototype, validated/invalidated feedback) is sufficient to proceed. Source: Stanford d.school Design Thinking Bootleg (landing page confirms the 5 modes and "start wherever you'd like" framing; the bootleg PDF itself could not be parsed directly in this research pass — see Grounding Caveats).

Empathize#

Input: target user population, context of use.
Output: field observations, interview notes, qualitative data about what users think/feel/do.
Completeness: 🧩 enough first-hand observation to ground a problem statement (general framing per secondary sources summarizing d.school content, e.g. Rikke Friis Dam — secondary source, see Grounding Caveats).

Define#

Input: empathy-stage research data.
Output: a synthesized, human-centered problem statement (point-of-view).
Completeness: 🧩 problem statement is specific, actionable, and user-centered enough to drive ideation.

Ideate#

Input: the problem statement.
Output: a wide, judgment-free set of candidate solution concepts.
Completeness: 🧩 breadth of divergent ideas achieved before converging on candidates to prototype.

Prototype#

Input: selected concept(s) from ideation.
Output: a quick, low-cost representation of the idea (sketch, paper prototype, mockup).
Completeness: 🧩 prototype is cheap/fast enough to be disposable and is ready to elicit real user reactions.

Test#

Input: prototype + real users.
Output: feedback that validates, invalidates, or refines the concept; often loops back to Empathize/Define.
Completeness: 🧩 feedback is specific enough to decide iterate vs. advance vs. discard.

The Double Diamond (UK Design Council)#

Official source fetched directly: designcouncil.org.uk. Four phases across two diamonds (divergent → convergent, twice): problem space (Discover, Define) then solution space (Develop, Deliver).

Discover#

Input: an initial problem assumption that needs validating.
Output: insights from engaging with people affected by the issue (user research, stakeholder input).
Completeness: 🧩 sufficient understanding gathered to reframe the challenge.

Define#

Input: Discover-phase insights.
Output: a redefined, clearer statement of the challenge/problem.
Completeness: 🧩 a clear, agreed problem statement is established.

Develop#

Input: the defined problem statement.
Output: multiple candidate solution concepts/prototypes, generated via ideation and co-design.
Completeness: 🧩 candidate solutions exist and are ready for evaluation.

Deliver#

Input: candidate solutions from Develop.
Output: small-scale tested, refined, validated solution(s) ready for production/launch.
Completeness: 🧩 viable solution(s) validated at small scale and ready for implementation; Design Council explicitly notes "no idea is ever finished" — teams may cycle back to Discover. Source: designcouncil.org.uk.

Core UX Artifacts#

Personas#

Input: user research (interviews, behavioral data, surveys) about a target user segment.
Output: a fictional-but-realistic composite representation of a user cluster sharing goals/behaviors/attitudes — a named profile document.
Completeness: 🧩 persona is grounded in real research (not invented), represents a meaningful cluster of target users, and is specific enough to "design with a real customer in mind." Sources: NN/g — Personas Make Users Memorable, NN/g UX Deliverables Glossary.

Empathy Maps#

Input: raw qualitative observation/interview data about a user type.
Output: a four-to-six-quadrant visual (Says/Does/Thinks/Feels, sometimes + Pains/Gains) structuring what is known about that user.
Completeness: 🧩 functions as a fast, rough precursor to a full persona; feeds forward into Journey Maps and Service Blueprints as their input. 🤔 Specific W3C/standards-body grounding not found — this is industry-consensus practice documented across UX vendor sources (e.g., Xtensio, UXPressia), not a single canonical authority — see Grounding Caveats.

Customer / User Journey Maps#

Input: persona(s) + empathy-map data + the sequence of touchpoints a user has with a product/service.
Output: a timeline/visual mapping stages of interaction, user actions, thoughts, emotions, and pain points at each stage.
Completeness: 🤔 map covers the full relevant journey (awareness through post-use) and surfaces actionable pain points; precise authoritative completeness criteria not independently grounded in this pass — industry sources only, e.g. UXPressia — see Grounding Caveats.

User Flows#

Input: defined user goals/tasks and the product's information architecture.
Output: a diagram of the path(s) a user takes through screens/steps to complete a task (nodes = screens/decisions, edges = actions).
Completeness: 🤔 every primary task has a flow from entry point to goal completion, including decision/branch points; drawn from general UX practice descriptions (e.g., frusia.pro) — no single canonical standard found, see Grounding Caveats.

Wireframes (lo-fi / hi-fi)#

Input: user flows + information architecture for a given screen.
Output: a static layout of a screen: lo-fi = rough placeholder shapes/sketches of structure only; hi-fi = detailed, close-to-final layout with real text/icon placement and sizing.
Completeness: 🧩 lo-fi is "done" once layout/IA intent is communicable without visual distraction; hi-fi is "done" once layout is precise enough to hand to visual/prototype stage. General UX industry consensus (e.g., Moqups); NN/g fidelity-dimension framing (interactivity/visuals/content) referenced via secondary summary — see Grounding Caveats for primary NN/g article not independently confirmed.

Prototypes (lo-fi / hi-fi)#

Input: wireframes + intended interaction model.
Output: lo-fi = paper/sketch or click-through with minimal fidelity; hi-fi = interactive, clickable mockup simulating real product behavior ("hotspots", transitions).
Completeness: 🧩 Nielsen Norman Group research finding (reported via secondary source, not independently fetched this pass — see Grounding Caveats) that hi-fi prototype testing surfaces ~85% of usability issues found in the final product vs. ~45-60% for lo-fi — used as the empirical basis for choosing fidelity level relative to remaining confidence needed before build.

Design Systems & Design Tokens#

Input: an organization's accumulated UI components, visual style decisions (color, type, spacing), and brand constraints.
Output: (a) a design system — a governed library of reusable components + usage guidelines; (b) design tokens — the atomic, named values (e.g., color.brand.primary) that back those components, expressed in a platform-agnostic format.
Completeness: 🧩 As of the first stable release (2025.10, Oct 28 2025) the W3C Design Tokens Community Group (DTCG) format requires every token to be an object with at minimum a $value and a $type, and supports token references via dot-path alias — this is now a cross-vendor interoperability bar (backed by Adobe, Figma, Google, Microsoft, Shopify, Salesforce). Sources: DTCG GitHub, W3C mailing list announcement. 🤔 A design system is "complete enough" when its token set + component library can satisfy the product's current screen designs without ad hoc one-off values — this threshold criterion is a reasonable inference, not a quoted standard — see Grounding Caveats.

7. Technical Spec Layer#

C4 Model (Simon Brown)#

Official source fetched directly: c4model.com. Four hierarchical diagram levels, notation/tool independent, vocabulary = Person, Software System, Container, Component, Relationship.

Level 1 — System Context#

Input: the software system under design and its environment (users, other systems).
Output: a System Context diagram showing what the system is, who uses it, and how it fits among neighboring systems.
Completeness: 🧩 diagram answers "what is this system, who uses it, what does it talk to" at a glance, deliberately excluding internal structure. Source: c4model.com.

Level 2 — Container#

Input: the system context + knowledge of deployable units (web app, API, database, etc.).
Output: a Container diagram showing the high-level, separately-deployable/runnable building blocks and how they communicate.
Completeness: 🧩 every independently deployable unit and its inter-communication is represented. Source: c4model.com.

Level 3 — Component#

Input: the internal structure of one container.
Output: a Component diagram showing the major functional units inside that container and their interactions.
Completeness: 🤔 Brown's own stated recommendation (surfaced via secondary coverage of his book) is that teams should focus primarily on the top two levels (Context, Container) because component and code diagrams have low shelf-life — they "change with nearly every commit and become outdated quickly" — so Component/Code diagrams are explicitly optional/lower-priority, not a mandatory exit gate. This specific framing was not independently re-fetched from c4model.com text in this pass, but is directionally consistent with the official site's emphasis on Context+Container as the primary pair — see Grounding Caveats.

Level 4 — Code#

Input: one component's internals.
Output: a Code diagram (e.g., UML class diagram) showing implementation detail — typically auto-generated from code rather than hand-drawn.
Completeness: 🧩 per above, treated as optional / generate-on-demand rather than a required deliverable.

Supporting diagrams noted on the official site but not part of the core 4: System Landscape, Dynamic, and Deployment diagrams (c4model.com).

Architecture Decision Records (ADR — Michael Nygard)#

Primary source fetched directly: Nygard's original 2011 post, "Documenting Architecture Decisions".

Input (trigger): an "architecturally significant" decision — one materially affecting structure, non-functional characteristics, dependencies, interfaces, or construction techniques; typically arises when the team faces a fork in technical direction.
Output (artifact): a short document (1-2 pages) with five fixed sections: Title (short noun phrase, sequential number, numbers never reused), Status (proposed / accepted / deprecated / superseded), Context (the forces at play, written neutrally, not yet advocating), Decision (active voice, "We will...", unambiguous), Consequences (ALL downstream effects — positive, negative, and neutral — in one section, specifically to discourage one-sided advocacy writing).
Completeness: 🧩 an ADR is "accepted" once project stakeholders agree with it; it is then treated as immutable — never edited after acceptance. If circumstances change, the old ADR is marked superseded and a reference points to its replacement; it is never deleted, preserving institutional memory of what was decided and why it changed. Each ADR covers exactly one decision. Source: cognitect.com.

API Contracts (OpenAPI / Swagger)#

Input: the intended set of API operations, resources, request/response shapes, auth scheme — i.e. the service's intended external behavior, decided before or alongside implementation ("design-first" / "contract-first").
Output: a machine-readable API description document (YAML/JSON) conforming to the OpenAPI Specification (OAS) — currently OAS 3.1, which fully aligns with JSON Schema draft 2020-12 as its schema language (replacing OAS 3.0's custom JSON-Schema subset), adds top-level webhook description, SPDX license identifiers, and makes the paths object optional for reusable component libraries.
Completeness: 🧩 the contract is a complete, standalone artifact once a human or machine can discover and understand the API's full capabilities from the document alone — "without requiring access to source code, additional documentation, or inspection of network traffic." Sources: OpenAPI Initiative / Linux Foundation FAQ, official OAS 3.0.3 spec text; OAS 3.1 changes per Learn OpenAPI — Introduction.

Data Models / Entity-Relationship Diagrams (ERD)#

Input: the business/domain requirements describing what entities (objects) exist and how they relate.
Output: a diagram built from three core components — entities, attributes, relationships — annotated with primary keys, foreign keys, and cardinality/participation constraints; produced at increasing levels of detail: conceptual (entities + relationships only, no implementation detail), logical, then physical (actual tables/columns/types).
Completeness: 🧩 the ERD is reviewed and validated to ensure the data model is well-structured, efficient, and meets business requirements before it becomes the blueprint for the actual database schema. 🤔 Source quality note: grounded via Atlassian's ERD explainer rather than an academic/standards primary source (e.g., Chen's original 1976 ER model paper) — see Grounding Caveats.

Frontend Component Specifications (Component-Driven Design, Storybook)#

Input: a design (wireframe/hi-fi mockup or design-system spec) decomposed into reusable UI pieces, following Atomic Design's five levels — atoms, molecules, organisms, templates, pages (Brad Frost's framework, referenced via bradfrost.com).
Output: for each component, a Storybook "story" set — isolated, buildable/testable specifications of every meaningful state (e.g., for a Button: default, hover, active, disabled, loading, each size/color variant) — plus auto-generated documentation that stays in sync with the component code.
Completeness: 🧩 a component's story set is complete when every meaningful visual/interactive state the component can be in is represented and demonstrable in isolation, independent of the full app; Storybook then functions as the living, continuously-verified documentation layer bridging design intent and implementation. 🤔 No single canonical/standards-body source defines "component specification completeness" — this is community/tooling convention (Brad Frost, Storybook's own marketing-adjacent content), not a standards-body definition — see Grounding Caveats.

Sources#

RUP / Unified Process

Requirements-Engineering Standards

Agile Requirements

Customer Development & Lean

Continuous Discovery

Design Process & UX

Technical Spec Layer

Grounding caveats & gaps#

RUP's official templates (ar_vsion.htm, ar_uc.htm, ar_sspec.htm, etc.) are mirrored on third-party academic sites (uhcl.edu, defcon.no, iscte-iul.pt) because IBM's original Rational Method Composer site is no longer live — content is treated as grounded since multiple independent mirrors agree, but there is no single current IBM-hosted canonical URL to cite.
Could not fetch iso.org's own abstract page directly (403 Forbidden on WebFetch); the ISO 29148 scope/content described here is grounded via secondary sources (ModernRequirements, ReqView) that summarize the official standard, not the ISO abstract text itself. The official purchasable standard text was not accessed.
BABOK v3's own formal completeness criteria for "Requirements Life Cycle Management" (approval/traceability states) are described here only via secondary commentary (ModernRequirements, AdaptiveUS) — the canonical IIBA BABOK Guide text is paywalled/membership-gated and was not directly fetched, so no direct iiba.org citation could be grounded.
IREB CPRE syllabus version cited (v3.0.1) may not be the latest; did not cross-check against the current IREB.org canonical syllabus page for version currency.
Gherkin's canonical reference (cucumber.io) gives style guidance (3–5 steps, no duplicate step text) but states no numeric or formal completeness threshold for "Feature coverage" — could not ground a stronger claim without inventing one.
Business Model Canvas has no built-in validation/completeness test comparable to Lean Canvas's Key Metrics block or JTBD's Opportunity Algorithm; secondary sources describe only structural completeness (all nine blocks populated and internally consistent), not a sourced quantitative exit test — flagged rather than invented.
Could not fetch the 2020 Scrum Guide text directly (fetch returned empty); DoR/DoD claims above are grounded via secondary sources quoting the Scrum Guide (scrum.org, Atlassian, MeisterTask) rather than the primary document itself — 🤔 treat as one level removed from the primary source.
Jeff Patton's exact "walking skeleton" completeness wording comes from secondary book-summary sources, not a direct fetch of Patton's own site/book text — primary-source confirmation not obtained in this pass.
🤔 d.school's per-mode (Empathize/Define/Ideate/Prototype/Test) input-output-completeness detail was NOT independently confirmed from the primary Bootleg PDF itself (only the landing page was fetchable in this pass); per-mode claims rest on secondary summaries of d.school material, not the primary deck content.
🤔 Empathy Map and Customer/User Journey Map completeness criteria have no single canonical standards-body source — grounded only in UX-vendor blog consensus (Xtensio, UXPressia), not an authoritative methodology owner akin to d.school or Design Council.
🤔 User Flow completeness criteria likewise rest on general UX-practice description, not a canonical named methodology/standard.
🤔 The NN/g empirical claim that hi-fi prototype testing surfaces ~85% of usability issues vs. ~45-60% for lo-fi was relayed via a secondary aggregator search result, not independently re-fetched from an NN/g URL in this pass — the specific NN/g article URL for this statistic was not captured.
🤔 C4 model's "focus on Context+Container, Component/Code are low-value and change often" guidance was surfaced via a secondary summary of Simon Brown's book content, not re-confirmed against verbatim c4model.com text (the direct WebFetch of c4model.com returned only the top-level structural description, not this guidance explicitly).
🤔 ERD/data-model grounding used a general explainer (Atlassian) rather than a primary academic or standards-body source (e.g., Peter Chen's original entity-relationship model paper) — no such primary source was independently located/fetched in this pass.
🤔 Storybook/component-specification "completeness" criterion is community/tooling convention (Brad Frost, Storybook's own marketing-adjacent content), not a standards-body definition — flagged as the weakest-grounded claim in Area 7.
🤔 Design system "complete enough" threshold (token set + component library satisfies current screen designs without ad hoc values) is a reasonable inference by the original researcher, not a quoted standard.