Requirements

The second stage of the pipeline, run by the Analyst. This page explains what a generated requirement carries and how generation is grounded. Requirements themselves are a standard Virtuoso feature: once created they are managed, linked to journeys and reported on as described in Requirements, which covers the feature rather than how Touchstone generates them.

TIP

Part 3 of the step-by-step guide generates a set from selected sources.

Requirements define what to test. From your selected sources, Touchstone proposes requirements, each carrying:

• a generated name (editable),
• a risk level: critical, high, medium or low,
• tags, aligned to how your project already organises work,
• a description following your template (configurable via Directives),
• source traceability. The documents each requirement was derived from.

Unless you've supplied a template, the default description structure covers scope (what's in and what's out), rationale, pre- and post-conditions, coverage, acceptance criteria, test data inputs and outputs, constraints, and alignment to project goals. Each requirement is expected to be specific, measurable, achievable, relevant and time-bound, and to cite the source it came from.

Choosing the sources. Every requirements generation starts with one decision: pick the sources yourself, or let Touchstone choose them. Selecting manually gives you exact control and is the better option when you know which documents describe the feature. Auto-select works from your prompt instead. It searches the Knowledge Base, scores what it finds for relevance, and pulls in the best-matching handful of documents or extracts. Use it when you're exploring, or when you're not sure which sources cover the area; use manual selection when you are.

Generation is grounded in two things at once: the sources in play, and what already exists in the project. Before proposing anything, Touchstone loads the project's existing requirements, reviews them against your request, and proposes only what's missing or needs updating, explaining its reasoning rather than producing a parallel set that duplicates work you've already done.

You refine the set by submitting further Agent Instructions in the Chat: extending it, tightening scope, removing what doesn't apply. Because requirements are versioned and linked in both directions (to sources and to journey structures), the pipeline can stand in for a separately maintained requirements-traceability matrix.

Requirements are only generated when you ask for them. General questions about your documentation can also be answered in the Chat, without producing proposals. Each request remains an Agent Instruction whether or not it produces a proposal.