Rohde & Schwarz Use Cases¶

Status: Customer evidence Validation status: Rohde & Schwarz-specific pains are customer-described by Robin; no requirement document, electrical diagram, material guideline, or paid pilot has been seen yet.

This page turns Robin's Rohde & Schwarz feedback into concrete use cases. The account should not be treated as a generic drawing-completeness lead. The stronger wedge is requirements-driven review: checking artifacts against guidelines, environment levels, material rules, and electrical intent.

Evidence Boundary¶

Evidence	Source	How to treat it
Design review is not only functional; it also needs review against requirements and guidelines	Robin / Rohde & Schwarz meeting notes	direct Rohde & Schwarz evidence
Example: which materials are used in which area and whether they are allowed	Robin / Rohde & Schwarz meeting notes	direct evidence
Example: qualification level such as sea level or air level	Robin / Rohde & Schwarz meeting notes	direct evidence
Requirements should be fed into the automation/review process	Robin / Rohde & Schwarz meeting notes	direct evidence
Component-purpose question: "What is this resistor used for?"	Robin / Rohde & Schwarz meeting notes	direct evidence
Some checks normally done in simulation tooling could be done through an electrical diagram	Robin / Rohde & Schwarz meeting notes	direct evidence, needs artifact
Action: approach again after about one month when product is more mature, ideally with requirement-check capability	Robin / Rohde & Schwarz meeting notes and customer discovery source	follow-up guidance

Priority Backlog¶

Priority	Use case	Owner signal	Why first
P0	RS-01 Requirement And Guideline Review Packet	Robin	captures the core ask
P0	RS-02 Material-By-Area Compliance Check	Robin	most concrete requirement example
P1	RS-03 Environment-Level Applicability Check	Robin	specific qualification framing
P1	RS-04 Electrical Component Purpose Explainer	Robin	ties review to design intent
P1	RS-05 Electrical Diagram Rule Check	Robin	powerful if artifact exists, but scope can grow
P2	RS-06 Requirement Traceability Gap Report	inferred from requirement-review direction	useful after source requirements are available

RS-01 Requirement And Guideline Review Packet¶

Persona: Systems engineer, requirements owner, design reviewer, or quality/compliance reviewer.

Trigger: A design artifact is ready for review and the team needs to check it against requirements and internal guidelines, not only functional behavior.

Current failure mode: Review is functional, but requirement/guideline compliance is not systematically checked at the artifact level.

Required inputs to request from Rohde & Schwarz:

one requirement or guideline document
one artifact connected to that requirement: drawing, BOM, electrical diagram, material list, or component list
one known missed or hard-to-check requirement
mapping from requirement scope to product area, environment level, or component group
expected pass/fail examples

RapidDraft behavior:

Ingest a small requirement/guideline set.
Extract checkable statements and classify them as material, environment, electrical, component, or process requirements.
Link each requirement to the available artifact evidence.
Show pass/fail/unknown with source references.
Keep the reviewer in control of final interpretation.

Output: Requirement-review packet with requirement ID, artifact evidence, status, uncertainty, and reviewer action.

MVP slice: One guideline, one artifact, one product area. Do not promise broad requirements management.

RS-02 Material-By-Area Compliance Check¶

Persona: Design reviewer, material owner, systems engineer, or compliance reviewer.

Trigger: A product area or assembly is being reviewed and material usage must comply with internal guidelines.

Current failure mode: The team needs to know which materials are used in which area and whether those materials are allowed there.

Required inputs:

material guideline with allowed/prohibited materials by area
drawing/BOM/material list
area or zone mapping
material naming normalization list

RapidDraft behavior:

extract material callouts from BOM/drawing/material list
map materials to the product area or component group
compare against allowed/prohibited guideline table
flag missing material data as "unknown", not pass
show source evidence for each material decision

Output: Area-by-material compliance table with pass/fail/unknown and evidence links.

MVP slice: One area and one guideline. Use structured material/BOM data if available; avoid OCR-heavy claims until artifact quality is known.

RS-03 Environment-Level Applicability Check¶

Persona: Requirements engineer or environmental qualification reviewer.

Trigger: A component or assembly is assigned to a product/application context such as sea-level or air-level operation.

Current failure mode: Requirements can vary by qualification level, but design review may not make those levels explicit.

Required inputs:

environment-level taxonomy
requirement table by level
product/component assignment to level
artifact evidence: material, component, enclosure, electrical rating, or other relevant fields

RapidDraft behavior:

identify the intended level for the artifact
retrieve applicable requirements for that level
check whether required evidence is present
flag missing or contradictory level assumptions

Output: Environment-level review card showing applicable requirement set and missing evidence.

MVP slice: Treat as a checklist/traceability problem first, not a physics validation problem.

RS-04 Electrical Component Purpose Explainer¶

Persona: Electrical reviewer, systems engineer, or design reviewer asking why a component is in the circuit.

Trigger: A reviewer asks a component-purpose question such as "What is this resistor used for?"

Current failure mode: The component's functional role may be obvious to the circuit designer but hard for reviewers or downstream teams to reconstruct from schematic symbols alone.

Required inputs:

electrical schematic or diagram export
component list/BOM
net labels and local circuit context
any design notes or requirement references
examples of accepted component-purpose explanations

RapidDraft behavior:

identify the component and local circuit neighborhood
retrieve connected nets, nearby components, and requirement references
draft a concise purpose hypothesis with evidence
mark uncertainty and ask for human confirmation

Output: Component-purpose explanation with diagram evidence and confidence/unknown flags.

MVP slice: One schematic section and one component class. Keep the language as "review aid", not final electrical design authority.

RS-05 Electrical Diagram Rule Check¶

Persona: Electrical engineer or reviewer who would otherwise use a simulation tool or manual reasoning for selected checks.

Trigger: The team wants to catch some issues directly from the electrical diagram before running deeper simulation or review.

Current failure mode: Some checks that might require simulation-tool workflows could be approximated or pre-screened through the electrical diagram, but the exact check family is not yet captured.

Required inputs:

one electrical diagram
one check currently done manually or in simulation tooling
expected result on the example diagram
rules for acceptable simplification

RapidDraft behavior:

parse the relevant diagram structure
apply the explicit rule or checklist
show which nodes/components support the finding
distinguish "pre-screen warning" from simulation result

Output: Diagram-based review finding with source evidence and "requires engineer confirmation" label.

MVP slice: One explicit rule on one diagram. Do not generalize to "simulation replacement."

RS-06 Requirement Traceability Gap Report¶

Persona: Requirements owner or systems engineering lead.

Trigger: Requirements exist, but the team needs to know which artifacts show evidence for each requirement.

Current failure mode: Requirements may be in documents while evidence is in drawings, BOMs, schematics, material lists, or review notes.

Required inputs:

requirement list
artifact set
expected trace links for a small subset
reviewer acceptance criteria

RapidDraft behavior:

list each requirement and linked artifacts
identify missing evidence
mark evidence as direct, inferred, or unknown
create review questions for gaps

Output: Traceability gap table for a small review scope.

Recommended Demo Sequence¶

Start with RS-01 Requirement And Guideline Review Packet using one guideline and one artifact.
Make RS-02 Material-By-Area Compliance Check the first concrete check because Robin gave this example directly.
Add RS-03 Environment-Level Applicability Check if they provide the level taxonomy.
Use RS-04 Component Purpose Explainer as a second demo path if electrical diagrams are available.
Keep RS-05 Electrical Diagram Rule Check narrow and explicitly not a simulation replacement.

Validation Assets To Ask For¶

one material guideline by area
one requirement/guideline document
one material list, BOM, drawing, or schematic connected to the guideline
one sea-level/air-level style qualification rule
one electrical diagram section and component-purpose question
one check they currently wish could be done before simulation/tool review
expected pass/fail or expected answer for each example

Open Questions¶

Which role owns this pain: systems engineering, requirements, electrical, quality, or compliance?
Are the requirements in DOORS, Jama, Polarion, Excel, Word/PDF, or another system?
Are material-by-area rules already structured or only in documents?
Which first artifact is easiest to share: BOM, drawing, material list, or electrical diagram?
What accuracy is acceptable for a pre-review assistant if humans approve every finding?
Is the follow-up still best timed after a requirement-check demo is mature?

Sources¶

docs_pivot/_sources/usecases-erpdrawing/rapiddraft-usecases-scenarios.md
docs_pivot/_sources/usecases-erpdrawing/meeting minutes June-July.rtf