Dejan Vukadinovic

Thought process

How I move from client conversations to clear requirements.

This is the part of the site closest to how I naturally work. I enjoy interviewing clients and customers, understanding how they think about the problem, and helping turn that into features a team can build without guessing.

Requirements loop

Listen, clarify, model, define, revise.

Nothing mystical here. Just a repeatable way to avoid building the wrong thing confidently.

  1. 01

    Interview the people

    Ask how the work happens now, who is involved, what breaks, and which decisions are harder than they look.

  2. 02

    Clarify the feature

    Separate wishes from needs, name assumptions, and turn vague requests into scenarios that can be discussed.

  3. 03

    Model the workflow

    Make roles, states, deadlines, data, handoffs, and exceptions visible before committing to implementation details.

  4. 04

    Define and revise

    Write requirements clearly enough to build, then update them when real feedback shows a better path.

Principles

Small habits that make requirements useful.

These are not rules for every situation. They are defaults I reach for when a project is still unclear.

Ask twice

First for the feature, then for the situation that created it.

The second answer usually tells you what the software really needs to support.

Write it down

If a decision matters, it should survive the meeting.

A short note often prevents a long misunderstanding later.

Prefer examples

Concrete customer examples reveal hidden rules faster than abstract agreement.

“What happens when...” is one of the most useful engineering questions.

Keep room

A first version should teach you something.

Good structure helps the system change without pretending we know everything upfront.