Product overview

Engineering records you can follow

Studio keeps what a team knows about a system as records rather than loose files: each one with a code, an owner, a lifecycle, a revision history and explicit links to the records around it. A Development gives them their scope.

Developments

A clear scope for every piece of context

A Development is the solution you engineer: a product, a release or a project. It has a responsible person, members, a process and a timeline. Its records, traces and references stay inside it, so its context has a boundary you can reason about.

  • Tabs for the business model, requirements, process, change requests, readiness, baselines, quality, knowledge, code and databases
  • Traceability gaps and missing work products on the overview
  • Visibility follows membership: people see the Developments they belong to
Overview of a Development with its lifecycle phases, readiness, next milestone and current iteration
Explicit records

Every record has a code and a history

Business actors and rules, use cases, requirements, decisions, risks, standards, evidence and work products are records with a code (REQ-0001, DEC-0003, RSK-0002), an owner, a state and revisions. Diagrams, test cases, tasks, repositories and databases are first-class records too.

  • Lifecycles with explicit transitions, from draft to approved
  • Every revision kept, with who changed it and a log message
  • Baselined content is never edited in place: a change creates a new revision
  • Write [[REQ-0001]] anywhere and it becomes a link, with “Mentioned in” on the other side
Requirements, system use cases and actors of a Development, each with its code and state
Traceability

Relationships are records too

A trace is an explicit, typed and directed link between two records, such as derives from, implements, verifies, mitigates or supersedes. It can carry a rationale and it has revisions of its own. Studio never infers traces, so you can rely on them in a review or an audit.

Typed

Two dozen trace types ship by default, each with an inverse label and rules about what may link to what.

Across modules

Requirements, decisions, diagrams, tests, tasks, articles, repositories and databases can all be ends of a trace.

Access-aware

A trace never reveals a record you are not allowed to see, not even its title.

Baselined

Baselines capture the exact revisions of records and of the traces between them.

History and accountability

Know what was agreed, and when

Revisions answer who changed what. Baselines answer what was in force: Studio takes one when a milestone is reached, and you can take your own at any time. A revision held by a baseline is never deleted, and change requests record who decided, when and why.

  • Decisions recorded with their rationale and the alternatives considered
  • Change requests linked to the records they impact
  • Evidence of verification attached to the run that produced it
Change requests of a Development with their states and target iterations
Conversations where they belong

Discuss any record, attach anything

Each record carries its own discussion panel with private attachments: the requirement, the test run, the database, the article. The conversation that led to a decision stays next to the record it is about, instead of in a chat thread nobody finds six months later.

  • Rich text with links to other records
  • Attachments stored privately, visible only to who can see the record
A knowledge article with links to requirements and use cases and its discussion panel
For the whole team

Each role gets the view it needs

Analysts

Capture business actors, use cases, rules and requirements, and see what is still unapproved.

Architects

Record decisions with their rationale, and keep BPMN and UML models next to the requirements they serve.

Process owners

Run Developments through phases and milestones with advisory readiness checks and change control.

Testers & QA leads

Design plans, execute runs step by step, record evidence, report issues, show coverage.

Team leads

Coordinate work on boards, split it into subtasks, follow time spent against estimates.

Developers

Find what a feature should do, why, how it is tested, and read the code and the schema next to it.

Your day

My work, my tasks, my runs

Everyone starts from their own queue: the activities assigned to them, the current iterations of their Developments, change requests waiting for a decision, their tasks, their timesheet and the test runs they have to execute.

People work in the Studio workspace, an interface designed for engineering work, not a CMS back office.

My work: assigned activities, current iterations and change requests waiting for a decision

See the parts in detail