Engineering method

Why and how we engineer

Local first. Global impact.

This is our mission: our why and our how. We work toward impact by prioritising real user needs and societal needs, the environment included. That also shaped how we develop our engineering methods: every part we build traces back to one of those needs.

Right now, we focus on keeping e-bikes alive as long as possible, even when their proprietary electronics fail. That keeps them affordable, saves resources and extends their range, contributing to better urban mobility and, with it, quality of life for all. Solving that takes careful engineering across hardware, firmware and software, and decisions we can still explain years later.

Using AI to design mixed hardware and software systems comes with a lot of trade-offs. We believe in the potential of AI, but its use must be safeguarded. We want to be able to explain why we build things, how we build them, and why they were built the way they were.

Behind the scenes

Sound familiar?

From here it gets a bit technical. These are the questions engineers face every day when they build something meaningful for the world. How well they can answer them decides whether a system stays reliable, for the people who depend on it.

  • A user asks why the system collects their location. Nobody can name the need.

  • The system changed. Which assumption moved, and who decided?

  • A new colleague asks why module B exists. Nobody remembers.

  • We asked an AI to extend the system. It rewrote three things nobody asked for.

This isn't a technical problem. It's a "we never wrote down what we're building and why" problem. And we are developing our own methods to solve these challenges, to build meaningful and reliable systems.

The principle

Every part links up to a reason

Four levels, each with one job. The example is a real chain from our work on the Sparta Ion, an e-bike family for which spare parts are no longer available.

  1. Stakeholder need

    Why we build it

    UN-001

    A rider wants to keep riding the Sparta Ion after the original battery ages out.

  2. Constraint

    What limits us

    TC-003

    The battery controls the bike's data bus. It is more than a power source.

  3. Requirement

    What the system must do

    SR-007

    The system shall take the controlling role on the bike's data bus when the original battery is absent.

  4. Design decision

    How we build it

    DR-001

    The send circuit shall transmit the microcontroller's messages onto the bike's data bus via its UART interface.

Based on ISO/IEC/IEEE 29148, reduced to the bare minimum. Needs say who wants what; requirements and design decisions say what the system shall do, one per statement.

Try it

Trace a requirement

A slice of our real e-bike requirements. Somewhere in it is a feature nobody asked for. Find it, and see why it doesn't belong.

  • Stakeholder need
  • Constraint
  • Requirement
  • Design decision

No requirement

Structure as a checklist

Four steps, and who may take them

  1. 1

    planned

    Agreed and linked to a need. Not built yet.

  2. 2

    implemented

    Built. The AI or a person can report this.

  3. 3

    verified

    Checked against the requirement. Only a person marks this.

  4. 4

    validated

    The stakeholder agrees it solves their need.

And anything with no link upward stands out at a glance. The question it raises is the useful one: why does this exist?

Structure as the AI's brief

One specification writer, many builders

Requirements chat

The only writer

Turns needs into requirements, links each one to its reason, proposes status changes.

only writer

Source of truth

requirements_db.json

The brief. All requirements and their links in one plain, versioned file. The viewer above reads this format.

never writes
read only: what to build

Implementation chats

Build against it

Firmware, circuits, models. Read-only. Every change names the requirement it implements.

report

Feedback channel

Progress logs

What was built, what was tested, open questions. New requirements are proposed here, never written directly.

reviewed on request

Human in the loop. The AI can report "built"; only a person marks it verified. Conflicts surface as questions instead of being fixed quietly. The chats share no memory; files are their only channel.

We don't prompt the AI ad hoc. We give it a brief, and the brief is versioned.

The whole rulebook

Five rules

These are the rules we work by on our own hardware and software projects. We share them openly, because sometimes simplicity wins and helps others.

  1. 1

    Every requirement links up

    Nothing exists without a reason above it.

  2. 2

    AI edits only what we discuss

    Conflicts are raised, not quietly fixed.

  3. 3

    Four status steps

    Planned, implemented, verified, validated. Verified: it does what it says. Validated: the stakeholder agrees.

  4. 4

    Requirement text stays stable

    Test results and findings go into notes, not into the requirement.

  5. 5

    Versions at milestones

    A dated copy per milestone, not per edit.

Beyond hardware

Same setup, any domain

Firmware, hardware or a model: the levels stay the same, only the labels change. We use circularity modelling to judge how significant a problem is before we solve it. For example: how big is the problem we are solving, from a material and waste point of view? Here is the same structure applied to such a model.

  1. SN-01

    Stakeholder need

    A public agency wants to predict raw material use and waste from e-bike batteries, to see where action pays off most.

  2. LR-01

    Logical requirement

    There shall be a semi-quantitative model uniting multiple formalisms to communicate between stakeholders.

  3. IR-01

    Implementation requirement

    The modelling system shall provide a web interface.

  4. IR-02

    Data requirement

    Battery lifetime data shall be available to all model modules.

  5. IR-03

    Interface requirement

    Battery lifetime data shall be exchanged with model modules via standardised JSON interfaces.

For a model like this one, it matters even more: every module, dataset and assumption links to a stakeholder need, so the agency can follow the reasoning without reading code.

Honest limits

What this doesn't solve

  • Validation is fuzzier outside hardware

    A circuit either works on the test bench or it doesn't. Whether a model answers the stakeholder's question is often a judgement call.

  • Human review doesn't scale for free

    If every status change needs a person, the risk is accepting requirements or changes without real human reasoning. That is why the file stays small and the levels stay few.

  • Traceability is not correctness

    It shows why something exists. It does not show that the reasoning was right. It helps a review; it doesn't replace one.

The human stays in charge, and can answer why it was built — and why this way.

Written by Marko Reinhard, reinwire, Hamburg. If you want to try this on your own project, or tell me where it breaks, write to marko@reinwire.com.

The method and the workshop material it comes from are licensed under CC BY 4.0: use and adapt it freely, with credit to Marko Reinhard, reinwire.