Gathering, agreeing and tracking the evolving stakeholder requirements — and keeping a customer-supplier communication channel — with a baseline and change control.
ASPICE SYS.1 Requirements Elicitation gathers, processes and tracks evolving stakeholder needs and requirements throughout the product life cycle, establishes an agreed stakeholder-requirements baseline, and maintains a customer-supplier communication mechanism so requests and their status are visible and changes are managed.
SYS.1 is the very top of the V — where the customer's needs enter. Get the elicitation and the communication channel right and everything downstream traces to something the customer actually agreed to.
Purpose (per the ASPICE PAM): gather, process and track evolving stakeholder needs and requirements throughout the product life cycle and establish a requirements baseline that serves as the basis for the work products.
The process is achieved when these outcomes hold:
Elicit needs, requirements, expectations and constraints.
Ensure a shared understanding of each requirement.
Reach and record agreement with stakeholders.
Formalize and baseline the agreed set.
Evaluate and manage changes (ties to SUP.10).
A channel for requests, status and disposition.
The output work products SYS.1 asks for (named per the standard):
This is where the standard meets reality. Each work product and outcome has a concrete home — an issue type, work-item type, or model element — in the tools you already run. Types are configurable, so treat this as the typical ASPICE setup:
| Work product / outcome | Jira | Polarion | Codebeamer | DOORS Next | Enterprise Architect | Confluence |
|---|---|---|---|---|---|---|
| WP: stakeholder requirement | 'Stakeholder/Customer Requirement' issue type | Stakeholder Requirement work item | Customer Requirements tracker | stakeholder-req module object | Requirement (stakeholder) element | intake / requirements page |
| WP: customer request / communication record | customer-request issue + comments | linked discussion / record | tracker item + comments | attribute / discussion | — | meeting notes / query log |
| WP: stakeholder requirements baseline | fix-version snapshot of the req set | Baseline of the stakeholder space | Baseline | module Baseline | package baseline | signed-off page version |
| Outcome: request status / disposition visible | workflow status + customer portal (JSM) | workflow state + dashboard | workflow + report | status attribute | — | status page |
| Outcome: change management of requirements | linked Change Request + suspect | linked Change Request + suspect | linked CR | link module | — | change log |
The trap isn't the tools — it's that the links between them are maintained by hand and decay the moment a requirement changes. (See best ASPICE tools.)
Here is the part almost everyone misses. SYS.1 can never reach a mature capability level (CL2+) on its own — it can only be as mature as the configuration-management data model underneath it. SUP.8 Configuration Management is the secret enabling layer: the shared data model of items, versions, baselines and links that is the basis on which every other process group becomes provable. Scatter that data model across a Jira project, a Polarion space, a DOORS module, an EA model and a Confluence tree, and the model is fragmented by construction — the traceability that SYS.1 depends on decays the moment anything changes, and no amount of process ceremony fixes it.
What actually unlocks maturity is a headless ALM — an API-first, tool-agnostic configuration-management data model that is the single source of truth for every work product and every link, readable and writable by both humans and agents — plus an agent/human workflow definition, coordination and traceability platform on top of it, so every change is planned, assigned (to a human or an agent), executed and traced against that one model. That is the layer that lets SYS.1 be mature instead of theatrical.
ASPICE deliberately gives you no blueprint. So we wrote one. This SYS.1 guide is part of The Blueprint — our free, open template QMS for ASPICE: every VDA-scope process area, its outcomes and work products, mapped to concrete artifacts in your tools and grounded in one configuration-management data model. Take it, use it, no cost.
Agents keep the stakeholder-requirements baseline and its downstream traceability current, and surface the impact of a changed customer need across the V — so elicitation stays connected to what actually got built. And we offer to implement The Blueprint for you: our agentic solutions (Vera generates SYS.1's work products and traceability as a byproduct of the build, each with a confidence score and audit trail) running on a partner headless ALM — the API-first configuration-management data model that makes the whole thing provable.
SYS.1 Requirements Elicitation gathers, agrees and tracks evolving stakeholder requirements, establishes a baselined stakeholder-requirements set, and maintains a customer-supplier communication mechanism with visible request status.
Stakeholder requirements, customer request/communication records, a stakeholder-requirements baseline, and change records for evolving needs.
Stakeholder requirements as a dedicated issue/work-item type (Jira/Polarion/Codebeamer) or DOORS module, baselined; communication via comments/portal (Jira Service Management) or Confluence; change managed through linked change requests.
SYS.1 captures and agrees the stakeholder's needs; SYS.2 transforms those into analysed, verifiable system requirements with traceability back to SYS.1.
Grounded in the standard, honest about the theater: All VDA-scope process areas · SYS.2 System Requirements · SUP.10 Change Requests · SUP.8 CM