Project Scope Exercise

Course Project

System: Online Ticket Sales System

Objective: Decide which stakeholder statements define the project scope (what’s in, what’s out, assumptions, boundaries, and future phases).

Scoring

This exercise is worth 10 points. Your score is based on whether your reasoning is aligned with practical scope definition.

Background

This is the second exercise in the course project. In real projects, scope is clarified by separating:

In-scope requirements (what the system must do now)
Out-of-scope items (explicitly excluded)
External dependencies (other teams/systems you rely on)
Assumptions & constraints (what you’re taking as given)
Future phases (valuable ideas intentionally deferred)

Instructions

Read the problem statement and the stakeholder statements. For each stakeholder statement, label it as one of: In Scope, Out of Scope, Dependency, Assumption/Constraint, or Future Phase. Then provide 1–2 sentences explaining why.

Hints

Boundaries: What functionality belongs in this project vs another team/system?
Phasing: What’s explicitly deferred (Phase 2 / “eventually”)?
Manual vs automated: What remains a human process for now?
Constraints: Who is allowed to perform sensitive actions (promotions, approvals)?
Integration points: Where will you interface with external systems (legal contracts, shipping, existing DB)?

Problem Statement

Online Ticket Sales System

Our company needs a system to support the sale of tickets for shows at our venue. The venue is a single-auditorium facility. Seats are organized by section, row, and seat number so each seat can be uniquely identified.

We present a variety of events (plays, concerts, sporting events). Some events run multiple times per week; some have a single show. Each show uses a pricing strategy made up of one or more price tiers (levels). Each price tier defines prices for price types (adult, student, child, etc.). Every seat for a show is priced by associating it with a price tier for that show.

A pricing strategy may include an optional volume discount. The same pricing strategy can be reused across multiple shows (for example, all Saturday matinees).

Most tickets are sold through agents. Agents must have a legal contract with us before doing business. After a contract exists, the facilities manager sets up a sales agreement that allows an agent to sell certain seats for a period of time. Agents can sell tickets for assigned seats for shows occurring during that period.

Customers can also buy tickets directly from us, but they can access only seats not assigned to agents. Both customers and agents view available seats through a seating chart. Selecting a seat places a temporary hold so others cannot select it until the seat is released or purchased. When purchased, a ticket is issued and mailed to the customer.

Stakeholder Statements

We do not keep track of what agency the agents work for. They move around too often, and it really does not affect their relationship with us.
We already have a database that is working really well for us.
Only the venue manager can set up promotions.
The legal department sets up the agent contracts in their system.
Mailing rates and methods are handled in the mailroom.
Tickets will include the seat location, price, applied discount, and date and time of the event.
We would like eventually to offer season tickets, but we should wait until we have the rest of the system working.
When agents sell the tickets, they basically use the same features as customers would use. The only difference is in what seats they see as available for sale.
Events can be set up without entering any of the performance dates and times.
In phase 2, we plan to let agents see their commissions during each sale.

Your Response

For each numbered statement, write: (Label) + a brief explanation. Example format:

1) Out of Scope — We are intentionally not modeling agencies; we only manage agents and their agreements.
2) Assumption/Constraint — We assume an existing DB will be reused or integrated, which shapes design choices.