How would you write a requirement so that a developer and a tester both read it the same way?

What the interviewer is looking for

• This question tests documentation & user stories. Writes clear, testable requirements and acceptance criteria that developers and testers interpret the same way.
• Strong answers: Uses clear, specific, testable language, includes acceptance criteria and examples, avoids vague words, and reviews it with both roles.
• Likely follow-up: Give me an example of a vague requirement and how you would rewrite it.

Another way it may be asked: You need to describe a password reset feature. How would you write it so nobody misunderstands it?

A structure to follow: Answer, explain, example, limits

1. Step 1

   Answer

   Give your direct answer in the first sentence so the interviewer knows where you are going.

2. Step 2

   Explain

   Say how it works or why you would do it that way, in plain words before jargon.

3. Step 3

   Example

   Anchor it in something you have actually done or seen, with the detail that shows hands-on experience.

4. Step 4

   Limits

   Say when your approach would not be the right one. It shows judgement.

This is guidance on shape, not a script. Use your own real experience and facts; never invent details to fill a gap. See the STAR guide and answer frameworks.

Common slips

• Reciting a definition without showing you have applied it.
• Using terms you cannot explain if asked a level deeper.
• Claiming experience beyond what you can discuss in detail.

How to practise it

Say the answer in 90 seconds, then answer the follow-up as if it were a new question.

Related questions

• How do you write acceptance criteria, and how do you know a user story is ready for the team to start building?
• If a manager says their team's reporting process is too slow, what questions would you ask first?
• Tell me about a time you had to understand a process or business area you knew nothing about. How did you learn it?
• Walk me through how you would map how a process works today and how it should work in future, and which tools you would use.
• Tell me about a time stakeholders gave you conflicting requirements. How did you resolve it?

Browse all questions