Specifications & Documentation
The documentation artifacts an analyst writes — SRS, ТЗ/ЧТЗ, ГОСТ 19/34, use-case flows, INVEST user stories, Gherkin acceptance criteria, DoR/DoD, and story splitting.
11 questions
JuniorTheoryVery commonWhat does INVEST stand for, and how do you spot a bad user story?
What does INVEST stand for, and how do you spot a bad user story?
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable. A good story is a small, independent slice with clear user value and testable criteria. A bad one has no user value, is too big for a sprint, or is untestable — you cannot tell when it is done.
Common mistakes
- ✗Writing stories as technical tasks with no user value
- ✗Making a story too big to finish in one sprint
- ✗Omitting testable acceptance criteria so 'done' is unclear
Follow-up questions
- →Which INVEST letter is most often violated in practice?
- →How does the 'Negotiable' property change how you write the story?
JuniorTheoryCommonWhat documents does a systems analyst produce, and who consumes each one?
What documents does a systems analyst produce, and who consumes each one?
An analyst produces requirements artifacts — an SRS or ТЗ, use-case and user-story specs, API contracts, data models, and BPMN/UML diagrams. Developers build from the specs, QA derives tests from acceptance criteria, the customer signs off the ТЗ, and the PM tracks scope.
Common mistakes
- ✗Naming only the ТЗ and forgetting contracts, data models, and diagrams
- ✗Assuming every document has the same audience
- ✗Thinking QA works from source code instead of acceptance criteria
Follow-up questions
- →Which of these artifacts is signed off by the customer?
- →How does the document set shrink on an Agile team?
JuniorTheoryCommonWhat are DoR, DoD, and acceptance criteria, and who owns each?
What are DoR, DoD, and acceptance criteria, and who owns each?
DoR (Definition of Ready) is the checklist a story must meet before the team pulls it into a sprint; DoD (Definition of Done) is the checklist for calling work complete. Both are team-owned. Acceptance criteria are per-story conditions the analyst or PO writes and QA verifies.
Common mistakes
- ✗Confusing the team-wide DoD with per-story acceptance criteria
- ✗Assigning DoR/DoD ownership to the customer instead of the team
- ✗Swapping when DoR versus DoD is checked
Follow-up questions
- →Why is DoD defined for the whole team but acceptance criteria per story?
- →What happens in the sprint if a story enters without meeting DoR?
MiddleDesignCommonA user story is too big to finish in one sprint — 'As a user, I can manage my orders.' The team wants to split it, but a bad split creates fragments that deliver no value on their own or that cannot be tested. Which splitting patterns do you apply — by workflow step, by business rule, by CRUD operation, by happy-path-then-alternatives, by data variation — and which splits are wrong? Explain how you keep each slice vertical and independently valuable, and why splitting by architectural layer (a UI story, then a backend story, then a DB story) is the classic mistake.
A user story is too big to finish in one sprint — 'As a user, I can manage my orders.' The team wants to split it, but a bad split creates fragments that deliver no value on their own or that cannot be tested. Which splitting patterns do you apply — by workflow step, by business rule, by CRUD operation, by happy-path-then-alternatives, by data variation — and which splits are wrong? Explain how you keep each slice vertical and independently valuable, and why splitting by architectural layer (a UI story, then a backend story, then a DB story) is the classic mistake.
Split so each slice is vertical and delivers value alone — by workflow step, CRUD, or rule variation. Keep each slice small, independent, testable. The wrong split is horizontal — UI, backend, DB as separate stories — no layer ships or tests alone.
Common mistakes
- ✗Splitting by layer into separate UI, backend, and DB stories
- ✗Producing slices that deliver no standalone user value
- ✗Dropping testability or independence to make a story smaller
Follow-up questions
- →How does splitting by business rule differ from splitting by CRUD?
- →How small is too small when slicing a story?
MiddleTheoryCommonWhat is ТЗ, what is ЧТЗ, and how do they differ in audience and depth?
What is ТЗ, what is ЧТЗ, and how do they differ in audience and depth?
ТЗ (техническое задание) is the top-level customer–contractor agreement for the customer and management. ЧТЗ (частное техническое задание) is a per-subsystem spec for developers, with algorithms and screens. ЧТЗ runs deeper and more technical.
Common mistakes
- ✗Swapping which document is deeper — ЧТЗ, not ТЗ, holds the detail
- ✗Assuming ТЗ and ЧТЗ share one audience
- ✗Treating ТЗ or ЧТЗ as a test or change-log document
Follow-up questions
- →Who signs the ТЗ, and who signs the ЧТЗ?
- →On a small product, when can you skip the ЧТЗ?
MiddleDesignCommonYou must write the постановка задачи for a brand-new UI screen — a customer profile page. Developers will build it and QA will test it straight from your document, and you want zero clarifying questions back. Which sections do you include so both roles have everything they need? Consider the screen's purpose and the actor; the layout and every field with its type, validation, and default; the screen states (empty, loading, error, filled); each action and where it leads; access rights; the data source for each field (an API or an entity); non-functional limits; and the acceptance criteria QA will check. State what you deliberately leave out and why.
You must write the постановка задачи for a brand-new UI screen — a customer profile page. Developers will build it and QA will test it straight from your document, and you want zero clarifying questions back. Which sections do you include so both roles have everything they need? Consider the screen's purpose and the actor; the layout and every field with its type, validation, and default; the screen states (empty, loading, error, filled); each action and where it leads; access rights; the data source for each field (an API or an entity); non-functional limits; and the acceptance criteria QA will check. State what you deliberately leave out and why.
Cover the purpose and actor; every field with its type, validation, and default; the screen states; each action's target; access rights; and its data source. Add the acceptance criteria QA verifies. Behavior detail, not visuals, removes questions.
Common mistakes
- ✗Handing over a mockup with no field, validation, or state rules
- ✗Specifying only the happy state and omitting error and empty states
- ✗Leaving the data source or acceptance criteria for others to guess
Follow-up questions
- →How do you specify a field's validation without dictating the UI?
- →Which screen state is most often forgotten in a spec?
MiddleTheoryCommonWhat are the main, alternative, and exception flows of a use case, and how do you know you found them all?
What are the main, alternative, and exception flows of a use case, and how do you know you found them all?
The main flow is the happy path where all works. Alternative flows are other valid routes to it, like card or wallet. Exception flows handle blocking failures, like a declined card. Confirm coverage by walking each step, asking what else can happen.
Common mistakes
- ✗Calling failure paths 'alternative' instead of 'exception' flows
- ✗Documenting only the happy path and skipping the rest
- ✗Assuming a use case always has exactly three flows
Follow-up questions
- →Where does a precondition belong relative to these flows?
- →How do exception flows map onto negative test cases?
MiddleTheoryOccasionalHow do you write acceptance criteria in the Gherkin notation, and when is Given/When/Then the wrong format?
How do you write acceptance criteria in the Gherkin notation, and when is Given/When/Then the wrong format?
Gherkin writes each criterion as a scenario — Given a precondition, When an action, Then an outcome — one scenario per behavior, with concrete data. It is the wrong format for non-behavioral criteria like performance numbers or plain constraints, where Given/When/Then only adds noise.
Common mistakes
- ✗Bundling several behaviors into one Given/When/Then scenario
- ✗Forcing non-functional or layout criteria into Gherkin
- ✗Writing scenarios with abstract data instead of concrete examples
Follow-up questions
- →How does a Scenario Outline reduce repetition across similar cases?
- →Where do non-functional criteria live if not in Gherkin?
MiddleTheoryOccasionalWhat is an SRS, what sections does it contain, and when do you write one instead of a story backlog?
What is an SRS, what sections does it contain, and when do you write one instead of a story backlog?
An SRS (Software Requirements Specification) is one document of all requirements — scope, functional and non-functional requirements, external interfaces, and constraints. You choose it over a story backlog for fixed-scope, contract- or ГОСТ-bound work that must be signed up front.
Common mistakes
- ✗Equating an SRS with a plain exported backlog
- ✗Thinking an SRS holds only non-functional requirements
- ✗Using an SRS for volatile Agile scope instead of fixed-scope work
Follow-up questions
- →Which SRS section captures external interface requirements?
- →How do you keep an SRS from going stale after sign-off?
SeniorDesignOccasionalYour specification for a screen keeps generating developer questions sprint after sprint — every few hours someone pings you to clarify a field, a rule, or an edge case, and QA files bugs that turn out to be unstated requirements. You decide to rework how you write specs, not just this one document. What do you add, what do you cut, and how do you restructure the spec so the questions stop? Address the root causes of ambiguity, how you make each requirement testable and traceable, which detail is signal versus noise, and how you validate the spec is complete before handing it off.
Your specification for a screen keeps generating developer questions sprint after sprint — every few hours someone pings you to clarify a field, a rule, or an edge case, and QA files bugs that turn out to be unstated requirements. You decide to rework how you write specs, not just this one document. What do you add, what do you cut, and how do you restructure the spec so the questions stop? Address the root causes of ambiguity, how you make each requirement testable and traceable, which detail is signal versus noise, and how you validate the spec is complete before handing it off.
Attack ambiguity at the root — swap vague prose for concrete rules, states, field validation. Add testable acceptance criteria and cover all flows incl. errors. Cut restated background and non-requirements. Walk it with a dev and QA before handoff.
Common mistakes
- ✗Answering ambiguity with more prose instead of concrete rules
- ✗Blaming developers instead of fixing the spec's gaps
- ✗Skipping the pre-handoff walkthrough with dev and QA
Follow-up questions
- →How do you make a requirement traceable back to its source?
- →What signals that a detail is noise rather than a requirement?
JuniorTheoryRareWhat are ГОСТ 19 and ГОСТ 34, and which one applies to what?
What are ГОСТ 19 and ГОСТ 34, and which one applies to what?
ГОСТ 19 (ЕСПД) covers documents about the program itself — its description plus the operator and programmer manuals. ГОСТ 34 covers the whole automated system — its техническое задание and explanatory notes. Use ГОСТ 34 for a full AS, ГОСТ 19 for a standalone program.
Common mistakes
- ✗Swapping which standard covers the program versus the whole system
- ✗Treating ГОСТ 19 and ГОСТ 34 as interchangeable
- ✗Confusing them with ISO or modern API standards
Follow-up questions
- →Which document does ГОСТ 34 call the техническое задание?
- →When would you skip ГОСТ entirely for a modern product?
