DigitableCourses
Portal settings
Русский
Show me around

Local and account-free. No account, no sign-up: whatever you type into the tools stays in this browser's localStorage and never reaches a server.

Our own counter records page opens and finishes: the address leaves, plus one tenth-of-the-text figure. No cookies, no outside trackers, your IP is not stored, Do Not Track is honoured. How to check that

The portal's own repository is not published, so we do not call it open source. What is open:

Digit flang Agent gate tools-core IT Tools Chat digitwm blender-mcp Hugging Face Licences

The portal lives on donations, paid consultations and requested write-ups, and on Workbench sales.

Support Order a write-up Workbench

There are no plans to make the courses paid.

Career

Systems and business analyst

Turns a vague 'we need this done' into requirements you can build a system from and check it against.

Roles and moves Self-assessment

Step 2 of 2 · Systems and business analyst

Which level inside the role?

Where people go from here: Product manager, Backend developer, Data and machine learning, QA engineer, Architect

Not sure — open the whole role card Pick another role

  1. Junior
  2. Middle
  3. Senior and beyond

Junior

Straight to the self-check

Compared with studying, the material changes: requirements are not handed over ready-made, they are pulled out of people who have not formulated them themselves.

Do now

  • I prepare questions for a meeting and leave it with decisions rather than with a retellingWhat is left after the meeting is a list of decisions and open questions.
  • I separate the business goal, the scenario and the constraint in a statement of workOne item does not mix up what for, how, and what limits us.
  • I draw the diagram in an agreed notation and test it on somebody who was not at the meetingThe person reads the diagram without my commentary.
  • I hand the document to a developer before the work startsThey do not come back asking what was meant here.

Where next

Middle

Sideways out of the role

Skills, pitfalls and learning materials

What this step asks of you

  • I pull requirements out of people who cannot state themWhat my meeting leaves behind is not a retelling but a list of decisions and open questions.
  • I tell the kinds of requirements apart and do not mix them upI do not blend a business goal, a user scenario and a technical constraint into one item.
  • I write a document that gets read and worked fromThe developer does not come back asking what was meant here.
  • I draw diagrams in a commonly accepted notation, not with arbitrary boxesMy diagram is understood by a person who was not at the meeting.

Common mistakes

  • Writing down everything that was said: the result is minutes you cannot build anything from.
  • Asking what do you need and believing the answer: people name a solution, not a problem.
  • Drawing boxes your own way: the diagram has to be explained again every time.

What to learn

  1. Junior
  2. Middle
  3. Senior and beyond

Middle

Straight to the self-check

Where your work ends changes: not at an agreed document but at a system that has been accepted.

Do now

  • I design the data model together with development rather than after itI understand what my entity turns into in the database.
  • I describe behaviour on errors in the contract, not only the happy pathThe integration does not stall on the first timeout.
  • I turn it must be fast into a requirement that can be checkedIt is written down at what load and with what response time.
  • I write acceptance criteria that a test can be written from without meThe tester does not ask what counts as success.

Where next

Senior and beyond

Sideways out of the role

Skills, pitfalls and learning materials

What this step asks of you

  • I design the data model together with developmentI understand what my entity turns into in the database and why that matters.
  • I describe integrations and contracts between systemsMy contract covers the behaviour on errors, not only the happy path.
  • I state non-functional requirements in numbersInstead of it should be fast I have written down at what load and with what response time.
  • I write acceptance criteria you can check the result againstA test can be written from my criteria without asking me anything.

Common mistakes

  • Leaving non-functional requirements for later: they are discovered on the load run just before the launch.
  • Agreeing the document but not the behaviour: the argument surfaces at acceptance.
  • Becoming the postman between the customer and the team: decisions stop being made anywhere at all.

What to learn

  1. Junior
  2. Middle
  3. Senior and beyond

Senior and beyond

Straight to the self-check

The measure of the work changes: not a document handed over but sides with opposing interests reaching an agreement that holds.

Do now

  • I learn the domain well enough to argue with the customer on the substanceI can challenge a requirement because I understand their work.
  • I run the analysis inside the iterations rather than as one big document up frontRequirements get refined as we go, and that is not counted as a failure of planning.
  • I bring a conflict of requirements down to the price of each optionThe argument moves from who outranks whom to what we pay.
  • I name the architectural consequences of my own requirementsI know which requirement has just made the system distributed.

Where next

Not another step — a fork

Sideways out of the role

Skills, pitfalls and learning materials

What this step asks of you

  • I work with the domain, not only with the wordingI can challenge a customer's requirement because I understand their business better than they described it.
  • I do the analysis inside the iterations, not as one big document up frontRequirements get refined along the way, and that is not counted as a failure of planning.
  • I bring the conflicting requirements of different parties to a decisionI can move an argument out of who outranks whom into what each option costs us.
  • I understand the architectural consequences of my own requirementsI know which requirement has just made the system distributed.

Common mistakes

  • Agreeing with every side in turn: the contradiction surfaces in the code.
  • Retreating into notations and tools: the diagram is beautiful and the decision is not made.
  • Treating only the wording as your job: an impossible requirement stays impossible.

What to learn

IT Tools source · GPL-3.0 Digitable Chat source · GPL-2.0-or-later Legal documents