FIT2002 Chap.3 Scope, Requirements and Stakeholders
Scope, Requirements and Stakeholders
Scope management defines what the project will deliver and where responsibility stops. Requirements turn stakeholder needs into statements that can guide design, planning and acceptance. A useful requirement is specific, necessary, feasible, testable and traceable to a source.
The scope statement, requirements records and acceptance criteria must agree; otherwise the team may build work that cannot be verified or omit an obligation that stakeholders expect.
Stakeholder management is not a mailing list. It identifies interests, influence, impact and preferred engagement, then adjusts actions as the project changes.
Conflicting requests should be tested against authorised value and handled through agreed change control. The strongest assessment responses link a stakeholder claim to a requirement, the requirement to delivery work, and the delivered result to acceptance evidence. That chain makes both inclusion and rejection defensible.
What this chapter covers
- 01
Scope statements containing deliverables, boundaries and exclusions
- 02
Functional and quality requirements expressed in testable language
- 03
Acceptance criteria as the bridge from requirement to verification
- 04
Requirements traceability from source through work and evidence
- 05
Stakeholder identification using interest, influence and impact
- 06
Engagement choices matched to stakeholder needs and decision rights
- 07
Change control for requests that alter authorised scope or constraints
Worked example · free
Repair an ambiguous accessibility requirement
- +2Separate desired behaviour from quality. A functional requirement could state that a user can register for an event and receive confirmation without staff assistance.
- +2Create a usability criterion, such as at least 85% of representative test participants completing the registration flow without help in a moderated test.
- +2Create an accessibility criterion tied to an agreed standard and automated plus human verification across named assistive technologies.
- +2Consult representative users, accessibility specialists and service staff so the criteria reflect actual contexts rather than the project team's assumptions.
- +2Give each requirement an identifier and link it to its source, WBS work package, test case, result and acceptance decision.
Key terms
- Scope Statement
- The description of authorised deliverables, boundaries, exclusions, assumptions and acceptance context. It provides a baseline for deciding whether later requests are included or require change approval.
- Functional Requirement
- A statement of behaviour or capability that the solution must provide. It should identify the relevant actor, action and observable result without prematurely prescribing an unnecessary design.
- Quality Requirement
- A measurable condition describing how well a solution must perform, such as usability, reliability, security or accessibility. It turns an adjective into a verifiable threshold or condition.
- Acceptance Criterion
- A specific condition used by an authorised evaluator to determine whether a deliverable or requirement is satisfactory. It should make the evidence and decision rule clear.
- Traceability Matrix
- A structured record linking requirements to sources, planned work, design elements, tests and acceptance outcomes. It reveals omissions, unauthorised additions and downstream effects of change.
- Stakeholder Register
- A maintained record of stakeholders, interests, influence, impact, expectations and planned engagement. It should change as new parties or concerns emerge rather than remain a one-time list.
Scope, Requirements and Stakeholders FAQ
How do scope and requirements differ?
Scope sets the authorised boundary of the project and its deliverables. Requirements describe capabilities and qualities that work inside that boundary must satisfy. A requirement may clarify scope, but not every scope statement is a requirement. Keep them consistent by tracing requirements to deliverables and treating additions outside the baseline through formal change control.
What makes a requirement testable?
A testable requirement identifies an observable behaviour or quality condition and enough context to decide whether it has been met. Replace vague adjectives with a threshold, scenario, standard or decision rule. Also record the evidence source and authorised acceptor. Testability is lost when a statement mixes several needs or uses terms that different stakeholders interpret differently.
Should a high-influence stakeholder always receive the most attention?
Influence matters, but impact, legitimacy, expertise and vulnerability also shape engagement. A group with little formal power may experience the largest consequence and hold essential usability evidence. Choose engagement from the decision and information need, then revisit it as the project changes. Stakeholder analysis supports ethical and effective action; it is not permission to ignore low-power voices.
Assessment move
Practise turning vague stakeholder sentences into a small linked set: one need, one or more requirements, acceptance criteria and an evidence source. Use verbs that can be observed and circle every adjective that still needs a definition.
Build a traceability table with columns for identifier, source, deliverable, work package, test and acceptance result; populate it from a familiar scenario until the connections feel automatic. For stakeholder questions, avoid memorising a single grid as the answer. State the person's interest, influence and impact, then choose an engagement action that supports a specific decision.
Add a change request to each practice case and trace its consequences through scope, schedule, cost, quality and risk. This prepares you to justify either inclusion or rejection without relying on personal preference.
Working through Scope, Requirements and Stakeholders in FIT2002? Sia is AskSia’s AI Project Management tutor — ask any FIT2002 Scope, Requirements and Stakeholders question and get a clear, step-by-step explanation grounded in how FIT2002 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
