Praxis Academy
Home › Business Analyst › Requirements

Business Analyst practice questions: Requirements

Requirements is 17% of the Salesforce Certified Business Analyst exam. It covers prioritization, traceability, non-functional requirements and change control. Try these 9 free questions, then open each answer to see why every option is right or wrong.

01

For a new Service Cloud case management process at a utilities company, stakeholders state two needs: every portal page must load in 2 seconds or less, and every login must require multi-factor authentication. How should the BA categorize these two requirements?

  1. Both are functional requirements, since they state what the system has to do.
  2. Page load time is a technical requirement, while MFA enforcement is a business requirement.
  3. Both are non-functional requirements, since they express performance and security quality attributes rather than specific system behaviors.
  4. Page load time is non-functional, while MFA enforcement is functional because the user performs an action.
Show answer

Answer: C

A. Both are functional requirements, since they state what the system has to do.Incorrect. Functional requirements describe specific features or behaviors (e.g., 'create a case when the form is submitted'). Load time and MFA are quality and security constraints, so they are non-functional.
B. Page load time is a technical requirement, while MFA enforcement is a business requirement.Incorrect. Load time is a performance requirement and MFA is a security requirement; both fall under non-functional. They are not split between a technical and a business category.
C. Both are non-functional requirements, since they express performance and security quality attributes rather than specific system behaviors. ✓Correct. NFRs describe how well the system works rather than which functions it offers. Page load time (performance) and MFA (security) are textbook NFRs that apply across the whole system.
D. Page load time is non-functional, while MFA enforcement is functional because the user performs an action.Incorrect. MFA is a security constraint set at the system or org level. It defines how authentication must behave, not a specific feature, so it is non-functional too.

Why: Non-functional requirements describe quality attributes such as performance, security, usability and scalability, not specific behaviors. A 2-second page load is a performance NFR; mandatory MFA is a security NFR. Classifying requirements correctly helps route them to the right technical teams.

02

A Salesforce implementation at an outdoor-gear company has 25 user stories. During sprint planning, the team is estimating in story points, but three stories have each been debated for 20 minutes with no agreed estimate. What is the MOST probable cause, and how should the BA respond?

  1. The developers need more technical training before they can size complex stories.
  2. The stories probably fail the Estimable criterion of INVEST - they may include ambiguous requirements, unknown technical dependencies or too much scope to size with confidence. The BA should clarify or split them before sending them back for estimation.
  3. Give all three stories a high story point value and move on to protect sprint planning velocity.
  4. Delete the three stories from the backlog for good because they can't be estimated.
Show answer

Answer: B

A. The developers need more technical training before they can size complex stories.Incorrect. Skill gaps can affect estimates, but the usual cause is unclear requirements, not lack of training. The BA should check requirement quality first.
B. The stories probably fail the Estimable criterion of INVEST - they may include ambiguous requirements, unknown technical dependencies or too much scope to size with confidence. The BA should clarify or split them before sending them back for estimation. ✓Correct. A story the team can't size usually breaks the Estimable criterion: ambiguous requirements, an unclear approach or excessive size. The BA works with the product owner and team to resolve the ambiguity, uncover dependencies or break the story into smaller, clearer pieces, then re-estimates.
C. Give all three stories a high story point value and move on to protect sprint planning velocity.Incorrect. Padding estimates distorts sprint capacity and just postpones the real issue. Unestimable stories need clarification or splitting before they're committed.
D. Delete the three stories from the backlog for good because they can't be estimated.Incorrect. Being hard to estimate signals a need for refinement, not removal. Deleting the stories risks losing genuine business needs.

Why: The 'E' in INVEST stands for Estimable. Stories that resist estimation after long discussion nearly always have requirement problems: vague wording, unclear scope, an unknown technical approach or hidden dependencies. The BA clarifies, surfaces dependencies or splits the story rather than guessing a number or dropping it.

03

A requirement in a Salesforce project at a home-appliance maker reads: 'The system must improve the customer experience.' The BA flags it as low quality. Which TWO flaws make it unfit for development? (Choose 2)

  1. It is vague - 'improve customer experience' is not precise enough to design, build or test a feature.
  2. It imposes a technical constraint that needs an extra security review.
  3. It is unmeasurable - no metric or criterion exists for the team to judge whether customer experience got better.
  4. It doesn't name which Salesforce cloud product will be used to address customer experience.
Show answer

Answer: A, C

A. It is vague - 'improve customer experience' is not precise enough to design, build or test a feature. ✓Correct. Vagueness is the main flaw: the phrase could mean faster case resolution, better self-service, more personalized communication or countless other things. Without specifics, nothing can be built or verified.
B. It imposes a technical constraint that needs an extra security review.Incorrect. The requirement contains no technical constraint or security aspect; this flaw simply doesn't apply.
C. It is unmeasurable - no metric or criterion exists for the team to judge whether customer experience got better. ✓Correct. Without a measurable criterion (e.g., 'raise CSAT from 3.8 to 4.2' or 'cut average case resolution time by 20%'), nobody can confirm after go-live that the experience improved.
D. It doesn't name which Salesforce cloud product will be used to address customer experience.Incorrect. Choosing a Salesforce cloud is a solution design decision, not a requirement flaw. Requirements state business needs; the design decides which product meets them.

Why: A sound requirement is specific (states exactly what the system must do) and measurable (has a criterion for verifying success). 'Improve customer experience' fails on both counts, so the BA must go back to the stakeholder to define a specific, measurable improvement.

04

An outdoor-gear company is launching Salesforce Field Service. The BA has gathered 80 requirements from 12 stakeholder groups, and the product owner asks the BA to explain how a 'business requirement' differs from a 'functional requirement' so the team can categorize the backlog properly. Which explanation is correct?

  1. Business requirements describe specific system behaviors; functional requirements describe the organization's high-level goals.
  2. Business requirements describe the high-level organizational goals and motivations for the project; functional requirements describe the specific behaviors or features the system must deliver to reach those goals.
  3. Business and functional requirements are both written as user stories and are interchangeable at the backlog level.
  4. Functional requirements describe what users want to do; business requirements describe the technical implementation needed to meet those needs.
Show answer

Answer: B

A. Business requirements describe specific system behaviors; functional requirements describe the organization's high-level goals.Incorrect. This flips the definitions. Business requirements are the goals and motivations (the 'why'); functional requirements are the system behaviors (the 'what').
B. Business requirements describe the high-level organizational goals and motivations for the project; functional requirements describe the specific behaviors or features the system must deliver to reach those goals. ✓Correct. Business requirements answer 'why are we doing this?' (e.g., cut technician scheduling time by 30%). Functional requirements answer 'what must the system do?' (e.g., auto-assign the nearest available technician when a work order is created).
C. Business and functional requirements are both written as user stories and are interchangeable at the backlog level.Incorrect. The two types are distinct. Business requirements state organizational objectives and aren't written as user stories; functional requirements may become user stories, but the types aren't interchangeable.
D. Functional requirements describe what users want to do; business requirements describe the technical implementation needed to meet those needs.Incorrect. Functional requirements describe what the system must do, not what users want (that's a user need). Technical implementation details belong in technical/system requirements, not business requirements.

Why: Business requirements capture organizational goals and motivations - why the project exists. Functional requirements capture the specific system behaviors that fulfill those goals - what the system must do. Both differ from non-functional requirements (how well it performs) and technical requirements (how it is built). Correct classification routes each item to the right team and level of detail.

05

While documenting requirements for a Sales Cloud CPQ rollout at an industrial-equipment dealer, the BA hears a stakeholder say: 'We need the system to be fast.' How should the BA treat this requirement?

  1. Record 'the system must be fast' as a non-functional requirement and continue.
  2. Ask the stakeholder to define 'fast' in measurable terms, such as a target page load time or quote generation time, then record it as a non-functional performance requirement.
  3. Put it in the backlog as a user story: 'As a user, I want the system to be fast, so that I can work efficiently.'
  4. Disregard it, because performance tuning belongs to the development team and can't be captured as a business requirement.
Show answer

Answer: B

A. Record 'the system must be fast' as a non-functional requirement and continue.Incorrect. Recording a vague statement as-is gives developers nothing actionable and can't be tested. An NFR needs a measurable threshold.
B. Ask the stakeholder to define 'fast' in measurable terms, such as a target page load time or quote generation time, then record it as a non-functional performance requirement. ✓Correct. 'Fast' is meaningless without a threshold. The BA asks what response time is acceptable and what isn't; the answer (e.g., 'quote pages load within 2 seconds') becomes the measurable performance NFR.
C. Put it in the backlog as a user story: 'As a user, I want the system to be fast, so that I can work efficiently.'Incorrect. Wrapping an unmeasurable need in user story format doesn't improve it; the story still has no testable acceptance criteria. It must be made measurable first.
D. Disregard it, because performance tuning belongs to the development team and can't be captured as a business requirement.Incorrect. Performance is a legitimate NFR the BA must capture with stakeholder input. Ignoring it risks a slow system, poor adoption and unhappy stakeholders.

Why: For vague statements like 'fast', 'easy to use' or 'flexible', the BA asks follow-up questions until there is a measurable, testable specification. 'Fast' needs a number (e.g., 'quotes generate within 3 seconds') before it can be documented as an NFR and tested in UAT. Untestable requirements should never be signed off into the baseline.

06

A BA at a footwear company is reviewing documentation from an earlier project that used the V2MOM framework for organizational alignment, and explains it to a new colleague. Which description MOST accurately states how V2MOM relates to requirements documentation?

  1. V2MOM is a Salesforce configuration tool that automatically produces requirements from business process data.
  2. V2MOM (Vision, Values, Methods, Obstacles, Measures) is Salesforce's organizational alignment framework. BAs use it to make sure requirements are anchored in the organization's vision and strategic priorities, not just tactical feature requests.
  3. V2MOM is a user story template that replaces the standard 'As a / I want / So that' format.
  4. V2MOM is used in UAT to confirm the delivered solution meets every documented requirement.
Show answer

Answer: B

A. V2MOM is a Salesforce configuration tool that automatically produces requirements from business process data.Incorrect. V2MOM isn't a configuration tool; it's a framework for business planning and goal setting.
B. V2MOM (Vision, Values, Methods, Obstacles, Measures) is Salesforce's organizational alignment framework. BAs use it to make sure requirements are anchored in the organization's vision and strategic priorities, not just tactical feature requests. ✓Correct. Vision (what we want), Values (what matters), Methods (how we'll get there), Obstacles (what could block us), Measures (how we'll know we succeeded). BAs use it so requirements trace back to strategy instead of becoming disconnected wish lists.
C. V2MOM is a user story template that replaces the standard 'As a / I want / So that' format.Incorrect. User stories use 'As a / I want / So that'. V2MOM works at the organizational strategy level, well above individual stories.
D. V2MOM is used in UAT to confirm the delivered solution meets every documented requirement.Incorrect. UAT relies on acceptance criteria, test cases and the requirements traceability matrix, not V2MOM.

Why: V2MOM (Vision, Values, Methods, Obstacles, Measures) is Salesforce's alignment framework. On the BA exam, BAs use it to keep requirements aligned with the organization's vision and strategy. Requirements that can't be traced to any V2MOM element may signal scope creep or tactical asks that don't serve strategic goals. V2MOM supplies the 'why' above the requirements.

07

A footwear company is wrapping up a large Salesforce implementation, and the BA wants requirements formally closed out. Which activities belong to requirements closure? (Choose 2)

  1. Confirm the requirements traceability matrix is complete, showing every business requirement was delivered and verified by passed test cases.
  2. Archive the requirements backlog and all related documents in the version-controlled repository for future reference and audit.
  3. Delete all requirement documentation from the backlog tool to avoid confusing future projects.
  4. Hand every unfinished user story to the next available development team without prioritization.
Show answer

Answer: A, B

A. Confirm the requirements traceability matrix is complete, showing every business requirement was delivered and verified by passed test cases. ✓Correct. A complete RTM at closure proves each business requirement was delivered and tested, confirming the scope was fully addressed.
B. Archive the requirements backlog and all related documents in the version-controlled repository for future reference and audit. ✓Correct. Archiving keeps the requirements history available for future enhancement work that needs the original baseline, for audits or compliance reviews, and for lessons learned. It is a standard closure deliverable.
C. Delete all requirement documentation from the backlog tool to avoid confusing future projects.Incorrect. Deleting documentation destroys valuable history that future projects modifying these features will need. Archive it instead.
D. Hand every unfinished user story to the next available development team without prioritization.Incorrect. Unfinished stories should be reviewed, deprioritized or formally moved to a post-launch maintenance backlog with stakeholder agreement, not blindly reassigned.

Why: Requirements closure includes (1) confirming the RTM is complete - every requirement delivered and tested - to prove scope was covered, and (2) archiving all requirements documentation in the version-controlled repository. Together they give formal evidence of completion and preserve knowledge for future enhancements, audits and lessons learned.

08

A BA at an outdoor-gear company is about to hand the completed requirements to the development team for sprint one. What should the handoff contain so the developers can start right away and build correctly? (Choose 2)

  1. Sprint-ready user stories, each with complete and specific acceptance criteria.
  2. All source code from earlier projects as reference examples for the developers.
  3. A short context document explaining the business objectives behind the sprint's stories, so developers understand the 'why' of what they're building.
  4. A list of every future-phase requirement outside the current sprint, so developers can design for future extensibility.
Show answer

Answer: A, C

A. Sprint-ready user stories, each with complete and specific acceptance criteria. ✓Correct. Stories with full acceptance criteria are the core BA handoff artifact; they tell the team exactly what to build and what 'done' looks like for each story.
B. All source code from earlier projects as reference examples for the developers.Incorrect. Old source code may be a technical reference, but it isn't a requirements handoff artifact or a BA deliverable.
C. A short context document explaining the business objectives behind the sprint's stories, so developers understand the 'why' of what they're building. ✓Correct. Knowing why a feature is needed helps developers make technical choices aligned with business intent, especially where acceptance criteria leave room for interpretation.
D. A list of every future-phase requirement outside the current sprint, so developers can design for future extensibility.Incorrect. Handing over future-phase requirements now invites over-engineering. Developers should build what the current sprint needs, not extend for unconfirmed future scope.

Why: A solid BA-to-development handoff includes (1) sprint-ready stories with complete, specific acceptance criteria - what to build and what 'done' means - and (2) business context explaining why the sprint's work matters. Together they let the team build accurately and make aligned technical choices. Future requirements and old source code are not suitable handoff items.

09

A Sales Cloud project at a regional bike retailer reached requirements sign-off, and its requirements are kept under version control in Confluence. Two weeks after sign-off, a stakeholder asks for a new field on the Account object. Which steps must the BA take before touching the requirements document? (Choose 2)

  1. Analyze the impact of the new Account field on related processes, reports, and downstream user stories.
  2. Edit the requirements document in Confluence right away to include the new field.
  3. Route the change through the formal change request process and get approval from the project sponsor or change control board before the requirements are updated.
  4. Have the developers build the new field at once to show the stakeholder the team is responsive.
Show answer

Answer: A, C

A. Analyze the impact of the new Account field on related processes, reports, and downstream user stories. ✓Correct. A new Account field can ripple into related objects, validation rules, flows, reports, and user stories. Without an impact analysis the BA cannot explain the true size of the change to the team and sponsor.
B. Edit the requirements document in Confluence right away to include the new field.Incorrect. A versioned requirements baseline is not edited before the change is reviewed and approved; doing so skips change control and slips unapproved scope into the official record.
C. Route the change through the formal change request process and get approval from the project sponsor or change control board before the requirements are updated. ✓Correct. Submitting a change request and obtaining sponsor or change control board approval makes sure the change is evaluated, prioritized, and authorized before it joins the scope.
D. Have the developers build the new field at once to show the stakeholder the team is responsive.Incorrect. Building an unapproved change sidesteps change control completely. Developers should not start on scope that has not been approved, however simple it looks.

Why: Once requirements are signed off, any change follows a controlled path: first an impact analysis to see everything the change touches, then a formal change request approved by the sponsor or change control board. Only after both does the requirements baseline get updated, which keeps the versioned document and the project scope trustworthy.

Find out if you're ready to pass

Take the free Business Analyst diagnostic: 20 questions, no account needed. Then unlock all 180 questions, full practice exams and the study guide.

Start the free diagnosticSee plans

Other sections of this exam