Business Analyst — Energy / EMS Platform

Our partner’s EMS platform sits between technical reality (PLCs, inverters, telemetry) and energy-market reality (DSO requirements, balancing, curtailment, billing). Today, this domain and business knowledge lives mainly in the heads of the CTO and product owner, creating a bottleneck as the team scales. This new role will own turning that knowledge into written, testable requirements using Spec-Driven Development (SDD) and AI-assisted pipelines — becoming the team’s primary bridge between the energy world and engineering.
 

Main Responsibilities

– Take over requirements intake from the CTO and product owner, converting discussions, DSO correspondence, and field feedback into a structured, prioritized backlog with written specs
– Specify energy-domain features end-to-end — curtailment orchestration, group energy-compensation logic, price-forecast handling — with acceptance criteria QA can test against
– Extend the existing requirements-traceability practice (BR/SR/SwR) from the PLC track to the whole platform, supporting audits and NIS2 compliance
– Document the domain: build a glossary and rulebook (market roles, settlement logic, sign conventions) so engineers stop relying on the CTO to explain the sector
– Own feature acceptance — verifying delivered work against specs and domain logic before it reaches dispatchers and clients
– Use AI tools to draft requirements and acceptance criteria from raw inputs (meeting notes, DSO correspondence); maintain specs as living, primary-source-of-truth documents; implement automated traceability
 

Mandatory Requirements

Must-have

– Strong, hands-on knowledge of the energy sector (the core requirement — interviews go deep here):

•  
  • Market structure: TSO/DSO roles, generators, suppliers, balancing responsibility
  • Renewables operations: PV generation profiles, curtailment, BESS use cases (peak shaving, self-consumption, balancing)
  • Metering and settlement: billing meters, imbalance, day-ahead/intraday pricing, forecast-to-financial-outcome logic

  • Grid-code and regulatory awareness: what a DSO can demand from a generator, and what evidence operators must provide

    – 3+ years as a Business Analyst (or equivalent) on software products
    – Requirements engineering craft — stakeholder elicitation, specs with acceptance criteria, epic decomposition, traceability
    – Comfortable working with technical teams — can read an API spec or data model, ask precise engineering questions
    – Data literacy — comfortable in Excel and basic SQL
    – Romanian + English B2

Missing energy-sector depth is an automatic disqualifier, regardless of BA experience.

Nice-to-have

– Experience with EMS/SCADA/energy-management products
– Moldova/Romania market specifics — local DSO/TSO landscape, ANRE regulations, regional balancing context
– Understanding of MILP optimizer capabilities/limits
– Formal requirements methods (BR/SR/SwR layering, traceability matrices, BPMN/UML)
– Exposure to NIS2 or regulated-industry documentation
– Jira/Confluence fluency
– Ru/UA language

Red flags

– Energy knowledge is purely theoretical — no real experience with a plant, meter, market process, or settlement dispute
– Past specs are meeting notes, not real requirements — no acceptance criteria or edge cases
– Can’t explain domain concepts simply; hides behind jargon
– Has never had a requirement proven wrong (i.e., never actually checked)
– Needs a PM as an intermediary to work with engineers
– Resistance to SDD or AI-augmented requirements engineering
 

We offer

– Format: Remote
– Search geography: Moldova, Romania, Ukraine, then rest of Europe
– Direct ownership of a critical, high-visibility function — the primary translator between energy-market reality and engineering
– Clear runway to shape and grow the BA craft at the company (energy-domain depth valued over years of BA title)
– Modern, AI-first workflow — leveraging SDD and AI tools rather than manual, ad hoc documentation