Understanding Project Scope & Defining Clear Requirements

Every successful project starts with two questions: what are we actually building, and how will we know when it's done? This tutorial covers understanding project scope and defining clear requirements — the foundation of the FDE project lifecycle.

Table of Contents

• Understanding Project Scope
• Defining Project Requirements

Understanding Project Scope

Scope is the boundary around a project — everything you have agreed to deliver, plus everything you have agreed not to. It defines what is in, what is out, and under what conditions the work happens.

Why it is useful: Without a clear boundary, small requests quietly become big projects. Scope gives you the authority to say no (or "let's plan that separately") when someone asks to add work mid-project.

The Constraint Triangle

Every project juggles three forces:

Change any one and at least one other must move. If the customer adds scope but refuses to move the deadline, quality is the only thing left to give — and that's a conversation worth having early, not discovering late.

Example: Scope Statement

## Scope Statement — Customer Management Dashboard

**In scope**
- Customer list with search, filter, and pagination
- Add / edit / deactivate customer records
- CSV export of the filtered view
- Roles: Admin and Viewer

**Out of scope**
- Billing and invoicing features
- Mobile app
- Historical audit trail
- Self-service portal for customers

**Assumptions**
- Data comes from the existing customers table (SQL Server)
- No more than 500k rows in the table
- Admins are already managed by the company's SSO

This statement prevents most scope arguments before they start. The out of scope list is just as important as the in scope list — it is the written record of "we discussed it and chose not to."

Simple explanation: The scope statement lists the agreed boundaries in one place. The assumptions section is the sneaky part: you never wrote them down, and then a hidden constraint (like "500k rows only") blows up later.

Best Practices

• Write the scope statement down and get the customer to sign off before building
• Separate work into must / should / could / won't (MoSCoW) so trade-offs are visible
• Explicitly list out-of-scope items — don't make people guess
• State assumptions and constraints, even the obvious ones

Common Mistakes

• Keeping the scope only in your head ("I know what they meant")
• Vague scope language like "improve UX" with no measurable detail
• Treating scope as frozen forever — scope changes exist and are covered in a later tutorial

Defining Project Requirements

Requirements are the specific, testable conditions the deliverable must meet. Where scope sets the boundary, requirements define the details inside that boundary.

Why it is useful: Requirements are the contract between you and the customer. A well-written requirement says "we'll know we're done when..." — so development, testing, and acceptance all run off the same document.

Functional vs Non-Functional

• Functional requirements describe behavior: what the system must do.
• Non-functional requirements describe quality: how fast, how secure, how available it must be.

Example: User Story with Acceptance Criteria

As an admin, I want to deactivate a customer account
so that inactive customers no longer appear in searches.

**Acceptance criteria**
- Given I am an admin, when I open a customer and click "Deactivate",
  the customer's status changes to Inactive.
- Given a customer is Inactive, when I search, they do not appear in results.
- Given a customer is Inactive, when a Viewer opens their profile,
  they see "Account deactivated" instead of editable fields.

Simple explanation: "As a… I want… so that…" states who needs it, what they need, and why — so the work has context, not just a feature name. The acceptance criteria are written as given / when / then conditions a tester can check with a yes or no.

Example: Requirements Table

Tracking requirements in a table with IDs makes them referenceable. "Fix REQ-002" is unambiguous; "make the search better" is not.

Best Practices

• Give every requirement a unique ID so it can be referenced in tasks, tests, and demos
• Write acceptance criteria that produce a clear yes/no answer
• Separate functional and non-functional requirements — they are tested differently
• Have the customer review the requirements; this is the start of your feedback cycle