BoardSnap is an iOS app that reads whiteboard photos and produces clean summaries and action items in about ten seconds. This requirements gathering template structures a collaborative session where product, engineering, and stakeholders align on what to build — before anyone writes a line of code.
Run this at the start of any feature or project where ambiguity about what to build would be costly. The whiteboard session is most valuable when: multiple stakeholders have different expectations, the technical constraints are not yet understood by the business, or the feature is complex enough that a shared visual model helps.
Budget 60–90 minutes. Bring product, engineering lead, and at least one stakeholder who owns the outcome. Don't invite observers — everyone at the board should have a role in the requirements.
Write the problem being solved in one to two sentences — not the solution, the problem. 'Users can't find their boards from two weeks ago' is a problem statement. 'Add a search bar' is a solution. The requirements follow from the problem, not the other way around.
Write the user stories in standard format: 'As a [user type], I want to [action] so that [outcome].' Write every story that defines the feature's scope. Stories that aren't written don't exist — they become scope creep later.
For each user story: write two to four acceptance criteria. These are the specific, testable conditions that define when the story is done. 'Search results appear within 500ms' is an acceptance criterion. 'Search is fast' is not.
Performance, security, accessibility, platform constraints, and integration requirements. Write the ones that are non-negotiable. If a feature must work offline, write it here — not in a comment on a ticket two weeks into engineering.
Explicit list of what this feature does not include. This section prevents the sprint from expanding. If someone requests something mid-build that's not in the user stories and not in out-of-scope, it should go to the next sprint — not this one.
Agree on the problem before any discussion of solutions. If the group can't agree on the problem statement, the requirements session isn't ready to happen — there's a more fundamental alignment issue to resolve first.
Ask each stakeholder to write their most important user story. Get them all on the board. Then prioritize: which three stories are must-haves for the first version? The others go to a 'future' column.
For each story: ask 'How would a tester verify this is done?' Write the answer as an acceptance criterion. Stories that can't produce a testable acceptance criterion are underspecified — rewrite the story until you can.
Ask the engineering lead: 'What technical constraints should the business know about?' Ask the stakeholder: 'Are there compliance or performance requirements that aren't obvious?' Write everything that surfaces.
For every story that didn't make the top three: write it in the out-of-scope column explicitly. This is the single best tool for scope control — items that exist on the board in the out-of-scope column are much harder to argue back into the sprint.
BoardSnap reads all five sections — problem statement, user stories, acceptance criteria, non-functional requirements, out-of-scope. The output is a clean requirements brief ready to drop into Linear, Jira, or Notion.
Requirements written in isolation in a Confluence doc get misread. Requirements written together on a whiteboard get debated — and the debated version is the version everyone actually understands.
BoardSnap converts the collaborative board into a formatted requirements brief before the room disperses. The user stories, acceptance criteria, and out-of-scope items are structured and ready to become tickets.
Requirements gathering defines what to build and why — before engineering estimates. Sprint planning takes the requirements and breaks them into work to do in the next sprint. Requirements gathering is product and stakeholder work; sprint planning is product and engineering work. They shouldn't happen in the same meeting.
Some change is inevitable — requirements are not contracts. But the whiteboard session should produce a stable baseline. Changes after the session should go through a formal change request: what's the new requirement, what does it replace, and what does it cost in terms of timeline? The change discipline prevents requirements from becoming a moving target.
Yes. BoardSnap reads text on sticky notes placed on the board. If you write user stories on sticky notes and arrange them spatially, BoardSnap will read each note individually. Label the section clearly so BoardSnap knows the sticky notes are user stories.
The free tier gives you one project and 30 boards. Pro is $9.99/month or $69.99/year for unlimited boards and AI chat on every project.
No exporting, no transcription. Snap the board, get the action plan.