They ask: "How do you define the System Analyst role, and what does an SA actually do day to day?"
The title gets used loosely, so lead with the mandate: a System Analyst translates a business problem into a technical solution that a delivery team can build. That means eliciting and documenting requirements, but the "system" half of the title is the differentiator — an SA is expected to reason about architecture, data flow, integrations, and non-functional constraints (performance, security, scalability), not just business rules. Junior SAs work under supervision on a defined scope; the ownership of ambiguity grows with seniority.
Concretely: run elicitation sessions, write SRS/use-case documentation, model the system (UML/BPMN), define API and integration contracts, and stay the bridge between business stakeholders, architects, and developers for the life of the feature.
Say it: "A System Analyst turns a business need into a technical spec a team can build from — the 'system' half means I own architecture-level and NFR reasoning, not just business rules."
Red flag: Describing the role as "writing user stories." That's one artifact of many — leaving out modeling, integration design, and NFRs signals you're thinking BA, not SA.