Requirements18% of the exam
Scope vs requirements vs user stories
How the scope statement, requirements and user stories differ in purpose, point of view and timing, and how a business need flows down through them without losing business rules.
Understand the differences between scope, requirements and user stories.
~8 min read · 15 practice questions ·
What the exam expects
- Classify a stakeholder statement as a business objective, a scope boundary, a requirement, a non-functional constraint, a user story or an implementation request.
- Explain why a scope statement names what is out of scope, and how that lets the team recognise a later request as a change.
- Distinguish a functional requirements specification from a system requirements specification, and a use case from a user story.
- Turn an approved requirement into one or more user stories, and decompose a requirement too large for one sprint.
- Explain when each artifact is produced and why stories alone lose business rules.
Key terms:
- Scope statement specification: the clear definition of what the project must achieve and the work needed to deliver it.
- Requirement: something a stakeholder needs, stated so it is quantifiable and verifiable.
- User story: a simple description of a feature told from the user's point of view (who, what, why).
- Functional requirements specification (FRS): requirements defined from an end user or business perspective.
- System requirements specification (SRS): how the complete system should function, including hardware, software and behaviour.
- Epic: a requirement too large for one sprint, split into stories (an exam convention; no Salesforce page defines it).
Key facts
Scope statement specification
- Detail
- Most fundamental deliverable: what must be achieved and the work to deliver it
Scope states exclusions
- Detail
- Describes precisely what is and is not included
Scope creep
- Detail
- Unauthorized changes included without approval
FRS
- Detail
- Requirements from an end user or business perspective; expected outcomes
SRS
- Detail
- Complete system: hardware, software, functional and behavioural requirements
User story format
- Detail
- As a < who >, I want < what > so that < why >
A story is a synopsis
- Detail
- It does not outline the entire requirement
A valid requirement
- Detail
- Quantifiable and verifiable; owned by the stakeholder
Backlog contents
- Detail
- Includes nonfunctional requirements; owned and prioritized by the product owner
Sources for this section (5)
- Documentation Typestrailhead.salesforce.com (opens in a new tab)
- Gather Requirementstrailhead.salesforce.com (opens in a new tab)
- Learn About User Storiestrailhead.salesforce.com (opens in a new tab)
- BA Detectiveadmin.salesforce.com (opens in a new tab)
- Scrum Workflowtrailhead.salesforce.com (opens in a new tab)
- Why does a scope statement list what the project will not deliver?
- Which document describes requirements from an end user or business perspective?
- Why can user stories alone lose business rules?
- When should a backlog item carry the most detail?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Business Analyst pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 22 lessons of the Business Analyst guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (15 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams