Many tools. One thread.
Our goal: Mirador is meant to support the whole product lifecycle end to end and connect the tools you already use – without manual export and import.
Anything beyond today’s Mirador is our goal – not a commitment to features, scope or dates. What Mirador can do today is shown under Features.
Where time is lost today
A specification arrives as a document, is transferred into one tool, broken down, exported into a second for testing and into a third for mechanical design. Every hand-over takes time, and with each one, something can get lost.
Anyone who wants to know whether a design still matches the requirement has to search across several systems.
Today, goal and long-term goal
Today:Requirements end to end
In Mirador you capture requirements or bring them in via ReqIF, and work with Excel out and back in. Mirador detects interfaces, suggests features and classifies requirements – only what you approve goes into the specification.
Across up to ten levels you trace every requirement to its test, and when something changes, Mirador can mark the affected links as suspect. Baselines freeze versions, reviews check them in rounds, and any baseline becomes a document from your own template. Mirador syncs requirements with Jira and Jama in both directions; you connect further tools through your own adapters or the REST API.
Goal:The whole lifecycle
Reading in specifications that arrive as documents and structuring them; planning test runs and recording their results against the requirement; connecting other vendors’ tools out of the box, as is already the case for Jira and Jama, and so making manual export and import unnecessary.
Long-term goal:From requirement to first draft
From reviewed requirements, Mirador is meant to drive the engineering tools so that they create first drafts and design studies – as a starting point, not a result:
- test cases and test specifications,
- a first CAD model of a part from design space, loads and material,
- a schematic draft with component selection and, from the identified interfaces, signal and connector lists for wiring and the cable harness,
- a first hardware description in VHDL or Verilog for a chip or an FPGA, with a testbench,
- a skeleton of interfaces and tests for the software, embedded software included,
- architecture and simulation models that let you compare solution variants early,
- first hazard and failure analyses for your safety team to review and complete.
Reviewing, changing and approving remain up to you. Every draft is meant to stay traceable to its requirement: just as today Mirador can mark links as suspect after a change, it is then meant to show which draft is affected.
A draft is no substitute for engineering design, calculation or verification – it is meant to spare you starting from a blank page.
Workflows you define yourself
Some things already run on their own in Mirador: changes from Jira and Jama arrive on a schedule or on notification, and links can be marked as suspect after a change.
Our goal is workflows that you describe yourself and that Mirador is then meant to carry out – with you at every point that needs a decision. For example:
A requirement changes.
Today: Mirador can mark the links to dependent requirements and tests as suspect.
Goal: also mark affected drafts and documents, notify those responsible, prepare a review round.
A new version of the customer specification arrives.
Today: If it arrives as ReqIF, you import it as a new data set.
Goal: read it, structure it, set it against the previous state and lay out the differences for review.
A version is approved.
Today: Every review runs on a frozen baseline; in the next round only what has changed is assessed again, and you generate documents from any baseline.
Goal: on approval, create the baseline and documents and start the sync with connected tools, with no further steps.
Test results come back.
Today: Mirador shows which requirement has no test.
Goal: record results from the test environment against the requirements they verify, and show what is untested or has failed.
Every workflow is meant to stay traceable: what triggered it, what it did and who approved it – just as today every change from an AI suggestion carries the name of the person who approved it.
What holds throughout
You decide.
Mirador is meant to suggest and draft; you approve – just as with the AI suggestions today.
Open, not closed.
Connect existing tools rather than replace them.
Traceable.
Every step with evidence and a way back to the requirement.
Anything beyond today’s Mirador is our goal – not a commitment to features, scope or dates. What Mirador can do today is shown under Features.
Start with what works today.
In a demo we show you what Mirador can do today – and would be glad to hear what you need for your development work.