Requirements & Elicitation
Requirement types, quality criteria, elicitation techniques, the analyst role, and the requirement lifecycle from business need to verified delivery.
22 questions
JuniorTheoryVery commonWho is a systems analyst and whom do they interact with in the team?
Who is a systems analyst and whom do they interact with in the team?
A systems analyst bridges business and development: they elicit and analyze requirements, do functional decomposition, design integrations, and set concrete tasks for developers. They interact with virtually everyone — the customer, project manager, other analysts, testers, and developers — translating business needs into a technical specification and keeping all sides aligned.
Common mistakes
- ✗Limiting the analyst's contacts to only the customer or only developers
- ✗Confusing the systems analyst with a tester or a pure business analyst
- ✗Omitting integration design and task-setting from the role
Follow-up questions
- →How does a systems analyst differ from a business analyst?
- →How do the analyst's tasks change in Agile versus Waterfall?
JuniorTheoryVery commonWho are stakeholders, how do you identify them, and which groups does an analyst work with?
Who are stakeholders, how do you identify them, and which groups does an analyst work with?
Stakeholders are anyone the system affects or can influence it — customer, users, sponsor, PM, developers, and testers. Identify them by role, by who funds or signs off, and by tracing processes. The analyst works most with the customer, users, and team.
Common mistakes
- ✗Limiting stakeholders to those who pay or sign the contract
- ✗Forgetting internal roles — support, testers, legal — as stakeholders
- ✗Believing stakeholders can only be found after release
Follow-up questions
- →How do you handle a stakeholder who was identified late in the project?
- →How do you separate a decision-maker from an influencer among stakeholders?
JuniorTheoryVery commonWhat types of requirements do you know and how do they differ?
What types of requirements do you know and how do they differ?
Business requirements (BR) are the high-level goals and scope the customer needs and that justify the project. Functional requirements (FR) describe what the system must do — its features. Non-functional requirements (NFR) describe how it must work — its qualities (performance, security). User requirements describe the goals a user must be able to achieve with the product.
Common mistakes
- ✗Confusing functional (what the system does) with non-functional (how well it does it)
- ✗Treating business requirements as low-level detail rather than scope and goals
- ✗Ignoring user requirements as a distinct level of intent
Follow-up questions
- →Give an example of each requirement type for an online store.
- →How does a business requirement differ from a functional one?
MiddleTheoryVery commonWhat requirements-elicitation techniques do you know, and how does the approach change for internal versus external customers?
What requirements-elicitation techniques do you know, and how does the approach change for internal versus external customers?
Core elicitation techniques are interviewing stakeholders, questionnaires/surveys, and analysis of input documents; you start by identifying the stakeholders and sources. For an external customer (a project or product customization) communication is formal and contract-bound; for an internal customer it is more direct and iterative. The mix is chosen by context, not applied blindly.
Common mistakes
- ✗Naming only interviews and forgetting document analysis or questionnaires
- ✗Assuming the approach is identical for internal and external customers
- ✗Skipping stakeholder identification before eliciting
Follow-up questions
- →When is a questionnaire better than an interview?
- →How does gathering requirements for an internal customer differ from a project for an external one?
JuniorTheoryCommonHow do you prepare for a requirements-elicitation interview, and what do you do with the notes after?
How do you prepare for a requirements-elicitation interview, and what do you do with the notes after?
Before: study the domain and existing docs, learn who you interview and their goals, and prepare an agenda of open questions, general to specific. Afterwards, promptly structure the notes into draft requirements, send a written summary for the interviewee to confirm, and log any open questions that remain.
Common mistakes
- ✗Walking in with no agenda or domain study
- ✗Leaving notes raw and never confirming them with the interviewee
- ✗Delaying processing until the details are forgotten
Follow-up questions
- →Why send a written summary back to the interviewee after the meeting?
- →How do you structure an agenda that goes from general to specific?
JuniorTheoryCommonTurn 'the system must be fast' into a testable non-functional requirement — what do you add?
Turn 'the system must be fast' into a testable non-functional requirement — what do you add?
'Fast' is not testable — you add a metric, a target value, load conditions, and a percentile. For example: '95% of catalog searches return in under 300 ms at 1000 concurrent users.' Naming the metric, the threshold, and the measurement conditions makes the requirement verifiable pass-or-fail.
Common mistakes
- ✗Restating 'fast' with stronger adjectives instead of a metric
- ✗Giving a threshold but no load conditions or percentile
- ✗Treating speed as a functional (feature) rather than non-functional requirement
Follow-up questions
- →Why is a percentile better than an average for a response-time target?
- →What load conditions must accompany a performance target?
JuniorTheoryCommonHow does verification of a requirement differ from validation, and who performs each?
How does verification of a requirement differ from validation, and who performs each?
Verification asks 'did we build it right?' — checking a requirement against quality criteria, done by the analyst and team in review. Validation asks 'did we build the right thing?' — checking it against the real business need, confirmed by the customer and users on the delivered result.
Common mistakes
- ✗Swapping the two — treating verification as the business-need check
- ✗Assuming only QA does either, with no analyst or customer role
- ✗Thinking requirements themselves cannot be verified, only the code
Follow-up questions
- →Give an example of a requirement that passes verification but fails validation.
- →Who signs off on validation, and against which artifact?
MiddleTheoryCommonWhat are business rules, why document them separately from functional requirements, and where do they live?
What are business rules, why document them separately from functional requirements, and where do they live?
Business rules are policies the business enforces regardless of any system. They are documented separately from functional requirements because one rule drives many features and changes independently. They live in a rules catalog, referenced by ID.
Common mistakes
- ✗Treating a business rule as identical to a functional requirement
- ✗Embedding a rule inside one feature instead of a shared catalog
- ✗Assuming rules are owned by developers, not the business
Follow-up questions
- →How does referencing a rule by ID help when the rule changes?
- →When would you move business rules into a dedicated rules engine?
MiddleTheoryCommonHow do you manage a requirements change that arrives after the sprint has started?
How do you manage a requirements change that arrives after the sprint has started?
Route it through change control, not a quiet edit — log the request, run impact analysis on scope, effort, and timeline, then take it to the product owner or change board. If accepted, it enters the backlog for a future sprint; the current sprint stays protected. Each step is logged.
Common mistakes
- ✗Slipping the change into the running sprint with no impact analysis
- ✗Skipping the record, so the change is untraceable
- ✗Letting one developer accept a change without a board or product owner
Follow-up questions
- →What does impact analysis assess before a change is accepted?
- →How does protecting the sprint differ from refusing the change?
MiddleTheoryCommonWhat lifecycle does a requirement go through from a business task to verification of its implementation?
What lifecycle does a requirement go through from a business task to verification of its implementation?
A requirement is elicited from a business need, analyzed and decomposed, formalized and reviewed, then implemented and verified. Requirements are tested in layers: the analyst checks quality criteria, the team reviews understanding, QA validates the build.
Common mistakes
- ✗Skipping analysis/decomposition between intake and implementation
- ✗Believing requirements cannot be tested — only the code can
- ✗Limiting verification to QA and omitting analyst and team review
Follow-up questions
- →How does a tester verify the requirement itself rather than the code?
- →Where in the lifecycle can a requirement «get stuck» the longest, and why?
MiddleTheoryCommonWhat non-functional requirements have you had to set?
What non-functional requirements have you had to set?
Non-functional requirements describe how the system must behave rather than what it does: availability and response time, reliability, security, performance, scalability, and health metrics. They also cover design constraints (screen forms, reusability of UI) and external constraints such as legal and compliance rules. Each must be measurable so it can be verified.
Common mistakes
- ✗Listing features (functional) instead of qualities (non-functional)
- ✗Stating an NFR without a measurable target so it cannot be verified
- ✗Forgetting legal/compliance constraints as non-functional requirements
Follow-up questions
- →How do you make a performance requirement measurable?
- →How does availability differ from reliability?
MiddleTheoryCommonBy what quality criteria do you evaluate a requirement?
By what quality criteria do you evaluate a requirement?
A good requirement is correct, unambiguous (one reading only), complete, and consistent with the others. It is prioritized by importance and stability, verifiable (you can test that it is met), modifiable (changeable without ripple), and traceable (linked to its source and to design/tests). These are the BABOK/IEEE-830-style quality attributes a reviewer checks against.
Common mistakes
- ✗Naming only completeness and forgetting verifiability or traceability
- ✗Confusing unambiguous with merely detailed or long
- ✗Treating prioritization and modifiability as out of scope for requirement quality
Follow-up questions
- →How do you make an ambiguous requirement verifiable?
- →Why does a requirement need traceability?
MiddleTheoryCommonWhat is requirements traceability, what goes into a traceability matrix, and what breaks without one?
What is requirements traceability, what goes into a traceability matrix, and what breaks without one?
Traceability is following a requirement forward and back — from business source through design and code to the tests. A matrix links each requirement ID to its source, design, and test cases. Without one you cannot assess change impact, prove test coverage, or spot orphan requirements.
Common mistakes
- ✗Tracing forward to code only, not back to source and across to tests
- ✗Thinking nothing breaks without a matrix — losing change-impact analysis
- ✗Confusing traceability with time or task tracking
Follow-up questions
- →How does a traceability matrix speed up change-impact analysis?
- →What is an orphan requirement, and how does the matrix reveal it?
MiddleTheoryCommonWhat is a User Story Map, and what does it give you that a flat backlog does not?
What is a User Story Map, and what does it give you that a flat backlog does not?
A user story map lays stories in two dimensions — a horizontal backbone of activities in workflow order, with stories by priority beneath each. It shows the end-to-end journey a flat backlog hides and lets you slice an MVP across all activities, not the top of a list.
Common mistakes
- ✗Seeing it as a re-sorted flat backlog with no second dimension
- ✗Missing the horizontal activity backbone that shows the user journey
- ✗Thinking you slice an MVP off the top of a list, not across activities
Follow-up questions
- →How does the horizontal backbone map to the user's workflow?
- →How do you cut a walking-skeleton release from a story map?
SeniorDesignCommonTwo senior stakeholders give you directly contradictory requirements for the same screen: the head of sales wants every lead saved even with empty required fields so nothing is lost, while the head of compliance wants the form to hard-block submission until every required field is validated. Both are adamant, the screen ships next sprint, and picking one silently will make the other feel overruled. Describe exactly how you resolve the conflict — how you surface it, whose goals and constraints you dig into, how you drive them to a single agreed decision, what options you might propose, and what you record so the resolution and its rationale stay traceable.
Two senior stakeholders give you directly contradictory requirements for the same screen: the head of sales wants every lead saved even with empty required fields so nothing is lost, while the head of compliance wants the form to hard-block submission until every required field is validated. Both are adamant, the screen ships next sprint, and picking one silently will make the other feel overruled. Describe exactly how you resolve the conflict — how you surface it, whose goals and constraints you dig into, how you drive them to a single agreed decision, what options you might propose, and what you record so the resolution and its rationale stay traceable.
Make the conflict explicit — both positions can't hold as stated. Find the real goal behind each, bring the stakeholders together to own the trade-off, and propose a reconciling option. Escalate only if they can't agree, then record the decision.
Common mistakes
- ✗Silently picking the more senior stakeholder without surfacing the conflict
- ✗Trying to build both contradictory behaviours instead of reconciling them
- ✗Resolving it but recording no decision, rationale, or sign-off
Follow-up questions
- →How do you dig out the real goal behind each stated position?
- →When should you escalate rather than keep driving consensus?
MiddleTheoryOccasionalWhich quality model do you classify non-functional requirements by — FURPS+ or ISO 25010 — and give a measurable NFR per category?
Which quality model do you classify non-functional requirements by — FURPS+ or ISO 25010 — and give a measurable NFR per category?
I classify by a standard model — FURPS+ (Functionality, Usability, Reliability, Performance, Supportability) or ISO 25010. Each category gets one measurable NFR — Performance '95th percentile under 300 ms', Reliability 'uptime ≥ 99.9%'.
Common mistakes
- ✗Naming a model but giving unmeasurable, adjective-only targets
- ✗Confusing the quality-model categories with functional features
- ✗Using no classification, so whole NFR categories are forgotten
Follow-up questions
- →What does the '+' in FURPS+ add beyond the five letters?
- →How does ISO 25010 differ from the older FURPS model?
MiddleTheoryOccasionalWhat are transitional (переходные) requirements, and on what kind of project do they appear?
What are transitional (переходные) requirements, and on what kind of project do they appear?
Transitional requirements are temporary capabilities for moving from the old system to the new — data migration, parallel running, cutover. They are not in the target system and drop away after the switch, on migration and legacy-replacement projects.
Common mistakes
- ✗Confusing transitional (move-to-new) requirements with target-system features
- ✗Forgetting data migration, training, and cutover as transitional requirements
- ✗Assuming they persist after the switch instead of dropping away
Follow-up questions
- →Why is parallel running of the old and new system a transitional requirement?
- →How do transitional requirements shape the cutover and rollback plan?
SeniorDesignOccasionalYou inherit a 40-page legacy ТЗ for a system that has run in production for years. The original analysts and stakeholders are gone, the document mixes outdated and still-valid rules, and nobody remembers why many of its clauses say what they say. New change requests keep arriving, but you cannot safely change anything without knowing the real current behaviour. You cannot trust the ТЗ at face value, and you cannot rewrite it from scratch blindly. Describe exactly how you reconstruct the current-state AS-IS picture and validate it — how you mine the document, the running system, and the data; whom you talk to; how you separate what is still true from what is stale; and how you confirm your reconstructed model actually matches reality before proposing any change.
You inherit a 40-page legacy ТЗ for a system that has run in production for years. The original analysts and stakeholders are gone, the document mixes outdated and still-valid rules, and nobody remembers why many of its clauses say what they say. New change requests keep arriving, but you cannot safely change anything without knowing the real current behaviour. You cannot trust the ТЗ at face value, and you cannot rewrite it from scratch blindly. Describe exactly how you reconstruct the current-state AS-IS picture and validate it — how you mine the document, the running system, and the data; whom you talk to; how you separate what is still true from what is stale; and how you confirm your reconstructed model actually matches reality before proposing any change.
Don't trust the ТЗ at face value. Reconstruct AS-IS from sources — the doc, the running system, logs, data, and user interviews. Where they disagree, the system wins. Mark each clause valid, stale, or unknown, then validate by replaying scenarios.
Common mistakes
- ✗Trusting the legacy ТЗ at face value as still-valid
- ✗Rewriting from scratch without examining actual behaviour
- ✗Reconstructing from one person's memory with no cross-check
Follow-up questions
- →Why does the running system usually win when the sources disagree?
- →How do you validate that your reconstructed AS-IS matches reality?
SeniorDesignOccasionalA customer briefs you with a single sentence — «just make it like the competitor's app» — pointing at a well-known product and nothing else. There is no feature list, no priorities, and no budget stated beyond «the same but ours». The competitor has hundreds of features built over years, most of which this customer neither needs nor can afford, and «like it» hides very different unstated expectations. You cannot copy the whole app, and you cannot push back with a flat «that's not a requirement». Describe exactly how you turn this vague reference into a structured, prioritized requirement set — what you do with the competitor as a reference, what questions you ask, how you separate the real business goal from surface features, and how you reach something buildable and agreed.
A customer briefs you with a single sentence — «just make it like the competitor's app» — pointing at a well-known product and nothing else. There is no feature list, no priorities, and no budget stated beyond «the same but ours». The competitor has hundreds of features built over years, most of which this customer neither needs nor can afford, and «like it» hides very different unstated expectations. You cannot copy the whole app, and you cannot push back with a flat «that's not a requirement». Describe exactly how you turn this vague reference into a structured, prioritized requirement set — what you do with the competitor as a reference, what questions you ask, how you separate the real business goal from surface features, and how you reach something buildable and agreed.
Treat the competitor as a reference, not a spec. Find the business goal behind 'like them'. Do a feature teardown, then with the customer split true must-haves from what they just noticed. Turn the agreed set into prioritized requirements and an MVP.
Common mistakes
- ✗Cloning the competitor feature-for-feature instead of finding the goal
- ✗Refusing the vague ask instead of mining it for the real need
- ✗Skipping prioritization and an MVP, treating scope as unbounded
Follow-up questions
- →How do you separate a must-have from a feature the customer merely noticed?
- →How does the competitor teardown feed your prioritization?
SeniorTheoryOccasionalWhat artifacts must a requirements-management system support?
What artifacts must a requirements-management system support?
A requirements-management system tracks: a stable requirement identifier; requirement attributes (status, priority, source, version); reports over the set; slices/views (e.g. by release or component); a traceability matrix linking requirements to sources, design, and tests; and a requirement template enforcing a consistent structure. Together these make a large requirement set navigable, auditable, and traceable through change.
Common mistakes
- ✗Naming only a document store and omitting identifiers or the traceability matrix
- ✗Forgetting requirement attributes (status, priority, version)
- ✗Treating slices/reports as out of scope for requirements management
Follow-up questions
- →What exactly does a traceability matrix link, and why?
- →Which requirement attributes would you make mandatory?
SeniorDesignOccasionalMid-sprint, a key stakeholder demands that a feature your team already finished and merged in this very sprint be reworked to behave differently. Three days remain, the feature is covered by tests and demoed internally, and two other in-progress stories depend on its current behaviour. The stakeholder insists it is urgent and 'obviously how it should have been from the start'. You cannot silently absorb the rework without risking the sprint goal, and you cannot simply refuse a key stakeholder. Walk through exactly what you do — how you handle the request, what analysis you run, who you involve, how you decide whether it enters this sprint or the next, and what you record so the decision and its impact stay traceable.
Mid-sprint, a key stakeholder demands that a feature your team already finished and merged in this very sprint be reworked to behave differently. Three days remain, the feature is covered by tests and demoed internally, and two other in-progress stories depend on its current behaviour. The stakeholder insists it is urgent and 'obviously how it should have been from the start'. You cannot silently absorb the rework without risking the sprint goal, and you cannot simply refuse a key stakeholder. Walk through exactly what you do — how you handle the request, what analysis you run, who you involve, how you decide whether it enters this sprint or the next, and what you record so the decision and its impact stay traceable.
Don't absorb it silently or flat-refuse. Log a change request, then run impact analysis — rework effort, dependent stories, and the sprint goal. Decide priority with the product owner and stakeholder: usually it defers to the next sprint; record it.
Common mistakes
- ✗Silently absorbing the rework and blowing the sprint goal
- ✗Flat-refusing a key stakeholder instead of routing through change control
- ✗Deciding without impact analysis on the two dependent stories
Follow-up questions
- →How does the dependency on two in-progress stories change your analysis?
- →When is it right to renegotiate the current sprint rather than defer?
SeniorDesignRareA customer tells you: «I need a digitized phone book». That is all you have as input. Run the whole process as a systems analyst: how you would gather requirements in an interview (the interviewer plays the customer), process them, model the process in BPMN, identify entities and build an ER model, and carry the requirements through the lifecycle all the way to verifying the implementation is correct. Describe the steps and which interaction points you would need.
A customer tells you: «I need a digitized phone book». That is all you have as input. Run the whole process as a systems analyst: how you would gather requirements in an interview (the interviewer plays the customer), process them, model the process in BPMN, identify entities and build an ER model, and carry the requirements through the lifecycle all the way to verifying the implementation is correct. Describe the steps and which interaction points you would need.
Run the full analyst loop. Interview the customer to clarify fields, search, who edits, and scale. Turn the answers into structured requirements checked for quality. Model the to-be flow in BPMN and build an ER model with keys. Then carry each requirement to acceptance testing, keeping traceability.
Common mistakes
- ✗Jumping to modeling or coding before eliciting and clarifying scope
- ✗Skipping entity/ER modeling and storing everything in one flat table
- ✗Ending at development without testing requirements or keeping traceability
Follow-up questions
- →What entities and relationships would you build into the ER model of the phone book?
- →How would you verify that the implementation matches the original requirement?
