# Project Scope and Requirements

> Chapter 4 of the Courseiva PROJECT-PLUS curriculum — https://courseiva.com/learn/project-plus/project-scope-and-requirements

**Official objective:** 1.4 — Define project scope and requirements, including gathering techniques and the scope statement.

## Introduction

Project scope and requirements. It is one of the most common reasons projects fail — because nobody agreed on what ‘done’ actually means before work started. For the PK0-005 exam, knowing how to write a clear scope statement and gather solid requirements will get you several questions right and help you avoid the traps the exam loves to set.

## The Sunday Dinner Party Analogy

Your best friend calls you on Wednesday and asks you to host a dinner party for 6 people this Sunday. You say yes. Now you need to define what 'dinner party' means. Do you mean a formal three-course meal with place cards and a cheese course, or do you mean ordering pizzas and opening a few bottles of wine? That’s the scope. You also need to know the requirements: Sarah is allergic to shellfish, Mark won’t eat mushrooms, and Jane is gluten-intolerant. You cannot just ‘make something nice’. You must plan a menu that avoids those three ingredients entirely. 

 You write a list: Main course must be shellfish-free, mushroom-free, and gluten-free. Dessert must be gluten-free. Guests arrive at 6pm, and everyone leaves by 11pm. That list is your scope statement. Without it, you might serve garlic bread and mushroom risotto with prawn starter — and three people go hungry. 

 This is exactly what a project manager does. The 'dinner party' is the project. The guest constraints (allergies, time, number of people) are the requirements. The written list you text your friend is the scope statement: a formal document that says exactly what you will and will not serve, so no one is disappointed and no money is wasted on the wrong ingredients.

## Core explanation

In the world of Project Management, 'scope' is everything that the project includes. Think of it as the boundary line. Inside the line is all the work you agree to do. Outside the line is everything else — the work you explicitly are NOT doing. The 'requirements' are the detailed list of what the final product, service, or result must do, how it must behave, and what constraints (like budget, time, or laws) it must follow.

 When you take on a project, the very first thing you need to understand is what your customer or sponsor wants. This process is called 'requirements gathering'. It is a set of techniques used to collect information from stakeholders — the people who have an interest in the project. Common techniques include:

 - **Interviews**: One-on-one conversations where you ask open-ended questions like 'What does the system need to do at the end of the day?'
 - **Surveys and questionnaires**: Written lists of questions sent to many people, especially useful when stakeholders are in different locations.
 - **Focus groups**: A facilitated discussion with a small group of stakeholders to explore their needs in depth.
 - **Document analysis**: Reading existing company policies, user manuals, or old project documents to find hidden requirements.
 - **Observation**: Watching people do their jobs to see what they actually need, rather than what they say they need.
 - **Prototyping**: Building a quick, rough version of the solution to show stakeholders, so they can say 'yes, that' or 'no, that's wrong' before you build the real thing.

 Once you have gathered all the requirements, you need to organise them. Requirements fall into two main categories:

 - **Functional requirements**: These describe what the product or service must DO. For example: 'The website must allow a user to reset their password using their email address.'
 - **Non-functional requirements**: These describe HOW the product or service should behave or perform. For example: 'The website must load in under two seconds.' or 'The data must be encrypted.'

 With your list of requirements ready, you then create the 'scope statement'. This is a formal document that says exactly what is in the project and what is out of it. It includes:

 - **Project justification**: Why are we doing this project?
 - **Product description**: A clear description of the final deliverable.
 - **Acceptance criteria**: The conditions the deliverable must meet for the customer to say 'I accept this as complete'.
 - **Project deliverables**: The specific things you will produce (documents, software, reports).
 - **Project exclusions**: What is explicitly NOT included (this prevents 'scope creep' — when people keep adding small requests until the project explodes).

 Why does this matter for PK0-005? The exam will ask you scenario-based questions. They will describe a messy situation — like a team starting work without a signed-off scope statement — and ask you to identify the problem or the best next step. They also test your memory of the requirement-gathering techniques and their best use cases.

 The old way of working was to start building immediately. That led to endless changes, arguments, and failed projects. Today, we use these formal techniques to make sure everyone is aligned before anyone writes a line of code or builds a single piece of hardware. It saves time, money, and relationships.

 One critical concept is 'requirements traceability'. This means every requirement is linked back to a business need or a stakeholder request. If a requirement cannot be traced back to a real need, it is probably unnecessary and should be removed. This keeps the project lean and focused.

 Another key point: requirements change. Projects rarely have perfect, fixed requirements from day one. The process of managing changes to requirements is called 'requirements management'. PK0-005 will test your understanding of how to handle a change request: evaluate the impact on scope, schedule, and budget, then get formal approval before making the change.

 Finally, remember that scope and requirements are the foundation of everything else in project management. If your scope statement is fuzzy, your schedule will be wrong, your budget will blow out, and your customer will be unhappy. That is why CompTIA devotes a full objective to it.

## Real-world context

Imagine you work as a junior project coordinator at a mid-sized retail company. The marketing director comes to you and says: 'We need a new customer loyalty app by the end of the quarter. Make it happen.' 

 Your first step is NOT to call a developer. Your first step is to start requirements gathering. You schedule one-on-one interviews with the marketing director, the head of customer service, two store managers, and the IT director. You ask each person: 'What does the app absolutely need to do? What is a nice-to-have? What must it not do?' You take careful notes.

 Next, you send a short survey to 500 of the company's most loyal customers. You ask them: 'What would make you use a loyalty app more often?' 200 customers reply. You analyse the responses and find that 80% want push notifications for special offers, 60% want to see their points balance immediately, and 40% want to be able to redeem points directly from the app without going to the till.

 You then run a focus group with five store employees who use the current paper-based loyalty system. They tell you that the biggest problem is customers forgetting their loyalty cards. They suggest a digital barcode on the phone. You document this as a new functional requirement.

 With all this information, you write a draft scope statement. It lists three main deliverables: (1) a mobile app for iOS and Android, (2) a backend system that connects to the existing point-of-sale system, and (3) a user manual for the app. The scope statement also lists exclusions: the app will not include a payment feature, it will not support multiple languages, and it will not be integrated with social media accounts initially.

 You present the scope statement to the project sponsor (the marketing director) and the key stakeholders. They review it, make a few small changes, and sign it. This signature is gold — it means everyone has agreed on what the project will deliver.

 Throughout the project, when someone comes to you and says 'Hey, can we also add a chatbot to answer questions about the app?' you can politely say: 'That is outside our current scope. Let me process a change request so we can evaluate the impact on our timeline and budget.' This stops the project from spiralling out of control.

 At the end of the project, you test the app against the acceptance criteria in the scope statement. If it meets every single one, the customer accepts the deliverable. If not, you fix the gaps before claiming the project is done.

 This entire process — from unstructured request to signed scope statement to controlled delivery — is what separates professional project management from chaos. In your PK0-005 exam, you will be the person who knows exactly what to do first.

## Exam focus

CompTIA PK0-005 tests your understanding of Project Scope and Requirements in several specific ways. Expect approximately 8-12 questions on this topic across the exam. These questions are often the foundation of later scenario-based questions about schedule, cost, and risk.

 Here are the exact concepts they test and the traps they set:

 - **Requirements gathering techniques**: You MUST know the six main techniques (interviews, surveys/questionnaires, focus groups, document analysis, observation, prototyping). The exam will give you a scenario and ask which technique is BEST for a given situation. Trap: They will describe a technique that sounds similar but is wrong — for example, suggesting 'prototyping' when the stakeholders are in different time zones and a survey would be more practical.

 - **Functional vs Non-functional requirements**: You will get a list of five requirements and must classify each one as functional or non-functional. Trap: They include ambiguous statements like 'the system must be easy to use' which is a non-functional requirement (usability), not a description of a specific feature.

 - **Scope statement components**: They will ask what MUST be in a scope statement. Trap: They list things like 'project budget' which is not in the scope statement (budget is in the project charter or cost management plan). The scope statement contains the product description, acceptance criteria, deliverables, and exclusions.

 - **Scope creep**: The exam loves this concept. They describe a situation where a stakeholder keeps adding small requests without formal approval. The correct answer is always 'process a change request' or 'evaluate the impact on scope, schedule, and budget'. Trap: A wrong answer might say 'just add it since it is small' or 'tell the stakeholder no immediately'. The correct approach is always formal change control.

 - **Acceptance criteria**: These are specific, measurable conditions. The exam will give you a vague acceptance criterion (e.g., 'the system should work well') and ask you to identify the problem. The correct answer is that it is not measurable. Criteria must be objective, like 'the system must handle 1,000 concurrent users without crashing'.

 - **Requirements traceability**: They might ask about a requirements traceability matrix (RTM). An RTM links each requirement to its source (who requested it) and to the test case that will verify it. Trap: They might describe an RTM as a 'to-do list' or a 'schedule' — both are wrong.

 - **Project exclusions**: A scope statement includes what is NOT in the project. The exam tests why this is important: to prevent misunderstandings and scope creep. They might ask: 'Which document helps prevent a stakeholder from claiming the project was supposed to include X?' Answer: the scope statement, specifically the exclusions section.

 The biggest trap in the entire exam is that they will describe a project where scope was never formally defined and then ask 'What is the MOST likely problem?' The answer is always 'scope creep' or 'unclear requirements'. Do not overthink it. If they mention that the project team started work immediately without documentation, the correct answer is almost certainly about missing requirements or undefined scope.

 Memorise this acronym for requirement-gathering techniques: I F D O S P (Interviews, Focus groups, Document analysis, Observation, Surveys, Prototyping). The exam does not give you mnemonics, but you can create your own: 'I Felt Disappointed Over Soggy Pizza' to remember the six.

 Finally, know that the PK0-005 exam uses the term 'stakeholder' frequently. A stakeholder is anyone with an interest in the project — not just the paying customer, but also the users, the team, the regulatory bodies, and even people who are against the project. Every question about requirements will involve identifying the correct stakeholder(s) to involve.

## Step by step

1. **Identify Stakeholders** — List everyone who has an interest in the project: the sponsor, end users, IT team, legal, regulatory bodies, and even suppliers. You cannot gather requirements without knowing who to ask. This step happens before any scope or requirements work.
2. **Gather Requirements from Stakeholders** — Use the appropriate technique (interviews, surveys, focus groups, etc.) to collect what each stakeholder needs. Document everything, including conflicting needs. This step ensures you do not miss critical input early.
3. **Analyse and Prioritise Requirements** — Review all collected requirements. Remove duplicates, resolve conflicts through negotiation, and classify each as functional or non-functional. Prioritise them (e.g., must-have vs nice-to-have) so the scope statement reflects what is essential.
4. **Draft the Scope Statement** — Write the formal document that includes the project justification, product description, acceptance criteria, deliverables, and exclusions. This step transforms the raw requirements into a clear, agreed-upon boundary for the project.
5. **Validate and Obtain Sign-off** — Present the draft scope statement to key stakeholders and the project sponsor. Allow them to review, suggest changes, and then formally approve it by signing. This sign-off is the official agreement that the scope is correct, and work can begin.
6. **Manage Changes to Scope** — Once work starts, any request to add, change, or remove scope must go through a formal change control process. Evaluate the impact on time, cost, and quality before approving. This step prevents uncontrolled scope creep.

## Comparisons

### Project Charter vs Scope Statement

**Project Charter:**
- Authorises the project to begin
- Names the project manager and gives them authority
- Created in the initiating process group (before detailed planning)

**Scope Statement:**
- Describes exactly what the project will deliver
- Lists exclusions, acceptance criteria, and deliverables
- Created in the planning process group (after requirements gathered)

### Functional Requirement vs Non-Functional Requirement

**Functional Requirement:**
- Describes a specific behaviour or feature
- Example: 'The system must send a confirmation email after purchase.'
- Is directly testable by checking if the feature exists

**Non-Functional Requirement:**
- Describes a quality attribute or constraint
- Example: 'The system must load in under 2 seconds.'
- Is testable by measuring performance, security, or usability

### Interviews vs Surveys

**Interviews:**
- One-on-one, in-depth conversation
- Best for complex, exploratory needs
- Time-consuming with small numbers of stakeholders

**Surveys:**
- Written questions sent to many people
- Best for gathering quantitative data from large groups
- Quick and efficient but lacks depth and follow-up

### Scope Creep vs Approved Change

**Scope Creep:**
- Uncontrolled addition of work without formal approval
- Often happens gradually, via small requests
- Leads to budget overruns and missed deadlines

**Approved Change:**
- Formally requested, evaluated, and approved by change control
- Documented with a change request form
- Project plan is updated to reflect the change

## Diagram

_This flowchart shows the sequential process from identifying stakeholders through to managing approved changes to the project scope._

```mermaid
flowchart TD
    A[Project Start] --> B[Identify Stakeholders]
    B --> C[Gather Requirements]
    C --> D{Classify Requirements}
    D --> E[Functional Requirements]
    D --> F[Non-Functional Requirements]
    E --> G[Draft Scope Statement]
    F --> G
    G --> H[Validate with Stakeholders]
    H --> I{Approved?}
    I -- Yes --> J[Signed Scope Statement]
    I -- No --> K[Revise Scope Statement]
    K --> H
    J --> L[Execute Project]
    L --> M{Change Request?}
    M -- Yes --> N[Evaluate Impact]
    N --> O{Approved?}
    O -- Yes --> P[Update Scope Statement]
    P --> L
    O -- No --> Q[Reject Change]
    Q --> L
    M -- No --> L
```

## Common misconceptions

- **Misconception:** Requirements are just a wish list that the customer gives you, and you just write them down as they are said. **Reality:** Requirements gathering is an active, analytical process. You must interview, observe, analyse documents, and ask clarifying questions to uncover hidden needs that the customer did not think to mention. (Beginners think customers know exactly what they want. In reality, customers often describe symptoms instead of root needs. A skilled project manager must dig deeper.)
- **Misconception:** The scope statement is the same thing as the project charter. **Reality:** The project charter authorises the project and names the project manager. The scope statement describes what the project will deliver and what is excluded. They are separate documents created at different stages of the project. (Both documents deal with high-level project information, so beginners confuse them. The exam deliberately tests this distinction.)
- **Misconception:** Once the scope is signed off, it cannot change at all. **Reality:** Scope can change, but only through a formal change control process. Changes must be evaluated for impact on schedule, cost, and quality before approval. No unapproved changes are allowed. (This misunderstanding comes from over-emphasising the importance of a fixed baseline. In the real world, changes happen, but they must be managed, not ignored.)
- **Misconception:** Non-functional requirements are optional or 'nice-to-haves'. **Reality:** Non-functional requirements (like performance, security, and usability) are often mandatory. A system that is fast but insecure may be completely unacceptable, regardless of how well it meets functional requirements. (Because non-functional requirements don't describe a specific feature, beginners think they are less important. But a slow, insecure system fails just as surely as one that does not do its core job.)
- **Misconception:** You only need to gather requirements from the person paying for the project. **Reality:** You must gather requirements from all key stakeholders, including end users, operators, regulators, and even opponents. Ignoring a key group leads to missed requirements and project rejection later. (In everyday life, the person paying often has the most say. But in IT projects, the people who will use the system daily have critical needs that the sponsor might not know about.)

## Key takeaways

- Scope defines what is IN the project and what is OUT, creating a clear boundary that all stakeholders agree on before work begins.
- Requirements are gathered using six main techniques: interviews, focus groups, document analysis, observation, surveys, and prototyping.
- Functional requirements describe what the system DOES, while non-functional requirements describe how it PERFORMS, like speed, security, or usability.
- The scope statement must include the product description, acceptance criteria, deliverables, and exclusions — but NOT the budget or schedule.
- Scope creep occurs when unapproved changes are added to the project; the only proper response is to process a formal change request.
- Acceptance criteria must be specific and measurable — 'the system must work well' is too vague, but 'the system must handle 1,000 concurrent users' is acceptable.
- A requirements traceability matrix (RTM) links every requirement back to a real stakeholder need, preventing unnecessary features from being included.
- Without a signed scope statement, the project has no agreed definition of 'done', making it nearly impossible to finish on time and budget.

## FAQ

**What is the difference between a requirement and a scope statement?**

A requirement is a single need or condition that the project must meet. The scope statement is a formal document that summarises all the agreed requirements, describes the deliverables, and lists what is out of scope. Think of requirements as ingredients and the scope statement as the full recipe.

**How do I handle a stakeholder who keeps adding new requests after the scope is signed?**

You must redirect them to the formal change request process. They need to submit a written request, then you evaluate the impact on schedule, budget, and resources. If approved, the scope is updated. Never add work without this process — otherwise you guarantee scope creep.

**Are functional requirements more important than non-functional requirements?**

No, both are essential. Functional requirements define what the system does, and non-functional requirements define how well it does it. A system that does everything you want but crashes every 10 minutes is useless. Prioritise based on the specific project needs.

**Why does the scope statement need to list what is NOT in scope?**

Listing exclusions prevents assumptions. Without them, a stakeholder may assume something is included — like international shipping for a local app — and complain later. Exclusions make the boundaries absolutely clear for everyone.

**Which requirement gathering technique should I use first?**

There is no single 'first' technique — it depends on the project. If you have access to stakeholders, interviews are a great start because they allow deep exploration. If stakeholders are remote or numerous, start with a survey. Often, document analysis is done early to understand existing systems.

**How do I know if a requirement is good enough to include in the scope statement?**

A good requirement is specific, measurable, achievable, relevant, and time-bound (SMART). It should also be traceable to a real business need. If you cannot test it or if nobody can say whether it is met, it is not a good requirement.

## Check your understanding

1. **A project manager receives a request from a stakeholder to add a new feature after the scope has been signed off. What is the FIRST thing the project manager should do?**

   Answer: Process the request through the formal change control process, including evaluating the impact on schedule, budget, and resources before making any decision.

2. **What is the difference between a functional requirement and a non-functional requirement?**

   Answer: A functional requirement describes what the system must DO (e.g., 'send an email'), while a non-functional requirement describes how the system should BEHAVE (e.g., 'load in under 2 seconds').

3. **Name any three of the six primary requirements gathering techniques recognised in the PMBOK guide.**

   Answer: Interviews, focus groups, document analysis, observation, surveys/questionnaires, and prototyping (any three are correct).

4. **Why is it important to include project exclusions in the scope statement?**

   Answer: Exclusions prevent misunderstandings by clearly stating what is not part of the project, which helps avoid scope creep and unrealistic stakeholder expectations.

5. **A requirement states: 'The system must be user-friendly.' Is this a well-written requirement? Why or why not?**

   Answer: No, it is poorly written because it is not specific or measurable. A better requirement would be: 'A new user must be able to complete the registration process within three minutes without assistance.'

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/project-plus/project-scope-and-requirements