RDRA Development Method (Requirements / Visualization) — SKILL

When to use

• •When requirements definition for a new build or improvement tends to diverge, loses consistency, or the scope becomes ambiguous
• •When you want to visualize a legacy system quickly (for rebuild/maintenance-quality improvement) even with limited documentation

Goals

• •Start from “for whom / for what purpose (value)” and build requirements that are both comprehensive and consistent
• •Produce outputs that directly support explanation, agreement, estimation, and specification

RDRA essentials (key points)

• •RDRA is a model-based method to visualize business and system structure
• •It works for both To-Be (requirements definition) and As-Is (legacy system visualization)
• •Because models depend on each other, tracing relationships helps you discover what’s missing and improve consistency

Inputs (what to gather first)

• •Purpose (for whom / for what) and success criteria (what you must know to decide)
• •Background and constraints (deadline, budget, regulations/operations, existing assets, NFR assumptions)
• •Stakeholders (actor candidates) and external systems that are tied to value
• •Existing materials (screen list, interface list, DB schema/ERD, reports, contracts, ops runbooks, incident/inquiry logs, source folder structure)

Typical deliverables (choose based on your situation)

• •Artifacts that capture needs/direction (e.g., requirement model)
• •Artifacts that structure scope hierarchically (e.g., business use cases (BUC))
• •Artifacts that align multiple use cases (e.g., UC composite diagram)
• •Artifacts that drive detail (e.g., information model, state model, conditions/variations)

How to proceed (3 phases / 9 steps: iterate to improve accuracy)

Important: Don’t try to finish in one pass. Use short cycles to improve “whole → consistency → precision”.

Phase 1: Build a baseline for discussion (whole picture over precision)

1. •Clarify the starting point
   • •List the people/roles involved as actors
2. •Understand the scope
   • •Roughly list business areas / BUC / activities and align on the systemization scope
3. •Make the information explicit
   • •Identify “business ID-level” information (e.g., Order No., Invoice No.)
4. •Make the states explicit
   • •Identify changes in information as “states” (rough is fine)

Phase 1 outputs (minimum)

• •Candidate list of actors/external systems (speed over completeness)
• •Rough hierarchy from business → BUC (enough to agree on the whole picture)
• •Key information (business IDs) and key states (state names are sufficient)

Phase 2: Shape requirements (assemble through connections)

1. •Build requirements top-down
   • •Review business/BUC/activities and connect UCs to the systemized parts
   • •Clarify UC inputs/outputs (e.g., screens/events, participating actors/external systems)
2. •Review using information and state
   • •Iterate UC ↔ information and UC ↔ state to fill gaps and improve consistency
   • •Repeat steps 5/6 until UC/information/state granularity and scope are solid

Phase 2 outputs (usable for alignment and estimation)

• •UC list (verb-object style such as “Do X” / “Update Y”) and participating actors/external systems
• •Candidate UC inputs/outputs (screens/events, etc.)
• •Mappings UC ↔ information and state transitions ↔ UC (including gap discovery)

Phase 3: Make it spec-ready via business rules (clarify conditions and change points)

1. •Identify conditions (business rules) linked to UCs
2. •Identify variations that form the axes for conditions
3. •Make condition/variation elements concrete
   • •Bring them down to implementation/specification granularity

Phase 3 outputs (entry point to specification)

• •Conditions (business rules) and the UCs they affect
• •Variations (categories/types) and candidate values
• •Coverage viewpoints for condition × variation (and state if needed) to prevent missing cases

Run fast with Spreadsheet-style RDRA

Goal: Focus on definitions and consistency without getting stuck on diagram layout.

Sheet design (minimal set)

• •Functional requirements / Non-functional requirements
• •Actors / External systems
• •BUC hierarchy (Business → BUC → Activity → UC)
• •Information (business IDs, relationships between information)
• •State (state transitions and the UCs involved)
• •Conditions (including related variations/states)
• •Variations (categories/types; organize change points)

Suggested fill order

1. •Rough out actors/external systems (get initial scope)
2. •Fill business → BUC → activity → UC once (UC naming: verb-object style)
3. •Link UC inputs/outputs (screens/events) and information
4. •Fill information and state; use UC consistency checks to fill gaps
5. •Add conditions/variations and raise precision to spec-ready

Tips (speed first)

• •Don’t aim to “complete” each sheet
• •Even if inaccurate, fill all sheets once early
• •Use relationships (e.g., if an actor operates a UC, a screen likely exists) to iterate back and forth and improve accuracy

Practical workflow (Input → Work → Output)

1) Convert inputs into RDRA shape (rough is OK)

Input

• •Stakeholders (roles), customer value, existing materials

Work

• •Fill actors/external systems → business → BUC → activities → UCs first
• •In parallel, fill information (business IDs) and state (changes in information)

Output

• •First “connected whole picture” (gaps become visible)

2) Fill gaps via connections and improve consistency

Input

• •Provisional models from step 1

Work

• •Iterate UC ↔ information and UC ↔ state to add missing UCs/information/states
• •Add UC inputs/outputs (screens/events) to reflect how the system is actually used

Output

• •Requirements skeleton (granularity that supports agreement/estimation)

3) Move toward specification with conditions/variations

Input

• •UCs are mostly identified

Work

• •Identify conditions (rules) and map them to affected UCs
• •Organize change points (categories/types) as variations and enumerate values

Output

• •Spec-ready discussion points (conditions, exceptions, branching, coverage viewpoints)

Using RDRA for legacy system visualization (As-Is)

Decide up front

• •Purpose (e.g., understand current state for rebuild / improve maintenance quality and do impact analysis)
• •What you must know to make decisions (avoid over-analysis)

Basic approach

• •Fit available artifacts into RDRA and clarify/fill missing pieces
• •Top-down: infer and connect UCs/information from screens/events/interfaces/DB schemas, etc.
• •Bottom-up: index folder structure and source code into a mapping to UCs/screens/events/information

Done criteria (minimum acceptance)

• •Actors/external systems, key UCs, key information (business IDs), and key states are “connected”
• •When change requests arrive, you can explain the impact path logically (UC/information/state/condition/variation)

Failure signals (course-correct early)

• •The “for whom / for what (purpose/value)” is unclear and only feature discussions progress
• •UCs exist, but links to inputs/outputs (screens/events) and information are weak
• •Information devolves into a list of DB table names (go back to business IDs and domain terms)

Checklist (minimum quality bar)

• •Purpose (for whom / for what) and scope are expressed in words everyone can agree on
• •Key UCs are reliably linked to at least one of: actors/external systems, inputs/outputs, information
• •Information is expressed as business concepts with IDs, not DB table names
• •You can explain state transitions as “what changes, by which UC, and how”
• •When changes come, you can trace impact logically via UC/information/state/condition/variation

LLM usage (optional)

• •LLMs are useful for progressively filling the sheets when you provide inputs such as “company/business/needs/terms/constraints/existing materials”
• •Prioritize improving input data quality (requirements/context) over prompt tricks