User Stories, Acceptance Criteria & Requirements Docs

From Conversation to Buildable Work

Module 3 taught you to elicit needs. This module teaches you to write them down so a team can build from them. That translation, from a stakeholder's spoken frustration to a precise, testable work item, is arguably the single most marketable skill a BA has.

Documentation on a typical project flows like this:

1. The Statement of Work (SOW) and early Jobs to Be Done framing give a high-level picture of what the project is and why.
2. Discovery notes and transcripts capture everything elicited in workshops and interviews: the raw material.
3. From that raw material you distill business requirements: the high-level objectives the project must achieve.
4. Business requirements feed the Requirements Traceability Matrix (RTM), which connects each requirement to the user stories, features, and test cases that fulfill it.
5. Requirements are decomposed into user stories with acceptance criteria: the units of buildable, testable work.
6. The Solution Design Document (owned by the Solution Architect, with BA contribution) addresses the deeper-level requirements and describes how the solution will actually be built.

Keep this pipeline in your head. Every artifact in this module has a place in it, and when a stakeholder asks "where did this user story come from?", the pipeline is your answer: it traces back through the RTM to a business requirement to a discovery conversation.

User Stories

A user story is a short description of a piece of functionality, written from the perspective of the person who needs it. The canonical format:

As a [specific type of user], I want [what], so that [why].

Each of the three parts earns its place:

1. Who: which specific users need this functionality. Not "the user" in the abstract: a sales rep, a volunteer coordinator, a case manager. The who determines permissions, training, and design choices.
2. What: the specific task the functionality should allow the user to complete.
3. Why: why this task matters to the user, and what the overall value to the business is. The why is the part teams are most tempted to skip and the part that most often prevents building the wrong thing. If you cannot articulate the why, you have not finished discovery on that story.

A user story is deliberately not a technical specification. It describes the need from a user-centric perspective and leaves the how to design conversations. This is the same solution-agnostic discipline you learned with Jobs to Be Done in Module 3, applied at the feature level. (Recall the distinction: a job story frames the broader challenge; user stories specify the solution features. One job story often spawns many user stories.)

INVEST in Good User Stories

Well-written user stories and high-quality acceptance criteria lay the foundation for a successful build. The industry-standard quality checklist is the acronym INVEST. A good user story is:

• Independent: each story (and each acceptance criterion) is clearly identifiable and separate from the others. Independent stories can be prioritized, built, and tested without dragging a tangle of other work along.
• Negotiable: stories are open to discussion and client approval before finalization. A story is an invitation to a conversation, not a contract carved in stone.
• Valuable: each story serves an identifiable purpose toward the overall project. If nobody can say who benefits, the story should not exist.
• Estimable: the team can determine a story's level of effort. If a story cannot be estimated, it is usually too vague or too big, and either way it cannot be scheduled responsibly.
• Small: sized appropriately to the project's context: typically something a team can complete within a sprint. Big stories hide surprises; small stories surface them early.
• Testable: a QA or UAT tester can clearly identify what needs to be tested. If you cannot imagine the test, you cannot claim the story is done.

Use INVEST as a review pass on every story you draft. Most weak stories fail on Small (it is really three stories), Testable (no measurable outcome), or Valuable (the why is missing).

Acceptance Criteria

A user story tells you what the user needs. Acceptance criteria (AC) define, in measurable terms, what a successful implementation looks like: the definition of done for that story. A story without acceptance criteria is a wish; a story with them is a work item.

Three principles govern good AC:

1. Measurable and specific. Acceptance criteria provide a more technical and testable definition of success than the story itself, ensuring the completed product aligns with the client's requirements. Every criterion should be something a tester can check and mark pass or fail.

2. Solution agnostic. Write AC in terms of what the user can do and what the system does in response, not in terms of Salesforce internals. Do not specify "create a custom field" or "update the flow": describe the observable outcome instead. Two reasons. First, the focus stays on the user's needs and desired outcomes rather than prescribing a technical approach, which keeps the product adaptable to better designs and future enhancements. Second, stakeholders must approve these criteria, and you want sign-off conversations in plain business language, not Salesforce jargon that confuses the people whose approval you need.

3. Written with the story, not after the build. AC drafted after development merely describe what got built. AC drafted before development direct what gets built. The difference is the whole point.

Acceptance Criteria Formats

Several formats are in common use. Choose per criterion; a single story can mix them.

Given / When / Then (scenario format):

Given [precondition or context], When [specific action or event], Then [expected outcome].

Example: Given the user is logging into their account, when the user clicks "Forgot Password," then they receive an email with a password reset link.

Rule-based format:

If [condition], Then [outcome], Else [alternative outcome].

Example: If the user enters valid payment information, then the payment is processed successfully; else the user is shown an error message.

Checklist format: a plain list of verifiable statements. Example: Users can sign up using their email. An email verification link is sent upon sign-up. An invalid email shows an error message. Passwords must meet complexity criteria.

Edge case / negative scenario format: explicitly capture what happens when things go wrong. Example: Given an invalid email address, when the user tries to submit the registration form, then an error message is displayed.

That last format deserves emphasis. Inexperienced BAs write only the happy path. Experienced BAs ask: what if the input is invalid, the record already exists, the user lacks permission, or the network drops? Negative scenarios are where production incidents are born, and where good AC prevent them.

Worked Case Study: WellCare Solutions

Time to put the pieces together, end to end. This scenario mirrors real consulting work closely.

Scenario: You are the BA for a subscription-based HealthTech company, WellCare Solutions (a fictional company), which needs a Salesforce CRM implementation to improve sales tracking and renewals.

The Requirements Traceability Matrix (RTM)

With dozens of requirements and hundreds of stories on a real project, how do you guarantee nothing slips through the cracks? The Requirements Traceability Matrix is the BA's answer: a document that catalogs every requirement and tracks it through the project lifecycle, ensuring each one is addressed by the project's deliverables and validated by testing.

An RTM is typically a spreadsheet with columns for: Requirement ID, Requirement Description, Source, Associated Feature, User Stories, Test Cases, and Status.

A worked example:

Read the matrix vertically and horizontally. Vertically: every requirement decomposes into features, stories, and tests. Horizontally: any requirement's health is visible at a glance (REQ-001 is nearly done; REQ-002 has work outstanding). Notice too that one requirement maps to several stories, and one story to several test cases, including negative tests like TC002 and TC007.

Building and Using an RTM

1. Identify all requirements, giving each a unique ID for easy reference.
2. Create the matrix (a spreadsheet is fine) with the columns above.
3. Fill it in. Record each requirement's source (stakeholder, regulatory standard, business document), the features and user stories that address it, and the test cases that validate it. Track status: Proposed, Approved, In Progress, Completed, or Deprecated.
4. Update it continuously. When a status changes or a test case is written, update the matrix. An out-of-date RTM is worse than none, because people trust it.
5. Review and use it to track implementation, confirm every requirement is met, and report progress to stakeholders.

The RTM is a living document that traces the life of a requirement from conception through delivery and verification. When a stakeholder asks mid-project, "whatever happened to that renewal-alerts requirement?", the RTM answers in ten seconds. When UAT begins (Module 12), the RTM's test-case column becomes the test plan's backbone. And when scope disputes arise, the RTM shows exactly what was agreed and when. Few artifacts repay their maintenance cost so generously.

The Requirements Document Family

User stories and the RTM live inside a broader family of documents. Different firms emphasize different ones, but you should be able to define each and know its place.

Business Requirements Document (BRD). A formal, detailed document outlining the business needs and objectives for a project, product, or system: the requirements, stakeholders, objectives, and constraints the project must address. The BRD is the foundation from which functional and non-functional requirements are defined later. It answers what the business needs and why.

Functional Requirements Document (FRD). A detailed document outlining the specific functions, behaviors, and features the solution must provide, often in technical terms: how the system should work. The FRD is derived from the BRD and serves as a blueprint for design and development teams.

Requirements Traceability Matrix (RTM). Covered above; listed here because it belongs to the family: it is the connective tissue among all the others.

Practice Scenario: Mega Corp

Now it is your turn, with a second fictional client. No answer key this time: this is practice, and in live cohort sessions we will critique drafts together.

Scenario: Mega Corp, a mid-sized company, currently uses a combination of spreadsheets, email, and an outdated CRM to manage sales. They want to transition to Salesforce Sales Cloud to streamline lead management, improve sales forecasting, and improve collaboration across the sales team. You are the BA leading discovery with stakeholders from Sales, Marketing, and IT.

Mega Corp also runs a customer-facing commerce flow. Customers need to be able to: browse and search for products, view product details, add items to a cart, check out and pay, track orders and shipping status, manage their account information, and contact customer service.

Your task:

1. Draft at least six user stories covering the capabilities above, in proper format, with distinct personas where appropriate (customer, sales rep, service agent, manager).
2. Run each story through INVEST and refine.
3. Write acceptance criteria for at least three of your stories, using at least two different formats, and include at least one negative scenario.
4. List five follow-up questions you would ask Mega Corp's stakeholders before calling these stories ready.
5. Sketch the first three rows of an RTM connecting a business requirement ("customers can purchase products online") to your stories and hypothetical test cases.

If you can do those five things comfortably, you have the core hard skill of the BA role in hand.