Back to Requirements Analysis and Documentation

Use Cases and User Stories

5 minutes 5 Questions

Use Cases and User Stories are essential techniques for capturing and documenting functional requirements from the user's perspective. They provide narratives that describe how users interact with a system to achieve specific goals, helping ensure that the system delivers real value. A Use Case is a detailed description of a system’s behavior as it responds to requests from an actor, which can be a human user or another system. It outlines the interactions between the actor and the system, including main success scenarios, alternative paths, and exception conditions. Use Cases are often accompanied by Use Case Diagrams, visually representing the relationships between actors and the system's functionalities. User Stories, originating from Agile methodologies, are short, simple descriptions of a feature told from the perspective of the end user. They are typically formatted as: "As a [user role], I want to [goal] so that [benefit]." User Stories focus on the value delivered to the user and facilitate iterative development and prioritization based on stakeholder needs. Both Use Cases and User Stories help in understanding user requirements and expectations, promoting user-centric design, and ensuring that the development team has a clear understanding of what needs to be built. They serve as communication tools between stakeholders and the project team, aiding in the identification and clarification of functional requirements. In PMI's Business Analysis framework, utilizing Use Cases and User Stories enhances the requirements analysis process by providing clarity, fostering stakeholder engagement, and enabling traceability from requirements to design and implementation. They support the delivery of solutions that meet users' actual needs, increasing customer satisfaction and the likelihood of project success.

Test mode:
Start practice test
PMI-PBA - Requirements Analysis and Documentation Example Questions

Test your knowledge of Amazon Simple Storage Service (S3)

Question 1

What is the key difference between a Use Case and a User Story in terms of their level of detail?

Correct Answer: Use Cases provide detailed step-by-step scenarios while User Stories capture high-level requirements

Use Cases are formal documents that provide comprehensive, detailed step-by-step descriptions of system interactions, including main flows, alternative flows, pre/post conditions, and exceptions. User Stories, in contrast, are shorter, high-level descriptions that capture requirements in a simple format: 'As a [user], I want to [action] so that [benefit].' The incorrect options contain several misconceptions: User Stories (not Use Cases) are the ones focusing on business value, as they explicitly state the benefit in their format. Both Use Cases and User Stories are written from the user's perspective, not the system's perspective. Use Cases are detailed (not brief) documents, while User Stories are the concise format. User Stories typically have acceptance criteria but do not contain extensive technical specifications.

Question 2

What is the primary characteristic of an 'actor' in a Use Case model?

Correct Answer: A role played by a person or system that interacts with the system under development

In Use Case modeling, an actor represents a role played by a person or system that interacts with the system under development. This is the fundamental definition used in UML and systems analysis. The other options are incorrect because: Specifying an individual user who performs tasks according to their job description is too specific - actors represent roles, not specific individuals. A detailed representation of internal processes and technical specifications describes system architecture or process flows, not actors. A visual element showing sequence of actions and database operations describes a sequence diagram or data flow diagram, not an actor in Use Case modeling. The correct answer captures the essential nature of an actor as a role (which can be played by different entities) that interacts with the system, aligning with standard UML modeling principles.

Question 3

When developing acceptance criteria for a user story, what is the recommended approach for ensuring clarity and testability?

Correct Answer: Use the INVEST criteria to validate the acceptance criteria structure

The INVEST criteria is the recommended approach for acceptance criteria because it ensures they are: Independent - can be developed in any order Negotiable - allows room for discussion Valuable - delivers value to stakeholders Estimable - can be sized appropriately Small - fits within an iteration Testable - clear success/failure criteria The other options are incorrect because: Including all technical specifications and system dependencies makes acceptance criteria too complex and moves away from the business value focus. Documenting system architecture and database schema is too technical and belongs in technical documentation, not acceptance criteria. Spanning multiple sprints violates the 'Small' principle of good acceptance criteria - they should fit within a single iteration to maintain focus and enable rapid feedback.

Go Premium

PMI Professional in Business Analysis Preparation Package (2024)

  • 3015 Superior-grade PMI Professional in Business Analysis practice questions.
  • Accelerated Mastery: Deep dive into critical topics to fast-track your mastery.
  • Unlock Effortless PMI-PBA preparation: 5 full exams.
  • 100% Satisfaction Guaranteed: Full refund with no questions if unsatisfied.
  • Bonus: If you upgrade now you get upgraded access to all courses
  • Risk-Free Decision: Start with a 7-day free trial - get premium features at no cost!
More Use Cases and User Stories questions
9 questions (total)
Start 9 question test