Computer Science · Grade 10 · Collaborative Software Development · Term 4

Requirements Gathering and Specification

Learn to translate user needs and problem statements into clear, actionable software requirements.

• Ontario Curriculum Expectations
• CS.HS.D.2
• CS.HS.D.3

About This Topic

Requirements gathering and specification build the groundwork for effective software development. Students translate user needs and problem statements into clear, actionable requirements, distinguishing functional ones that outline specific features and behaviors, such as data input forms or search functions, from non-functional ones addressing performance, usability, security, and scalability. This process directly supports Ontario Curriculum expectations in collaborative software development, where students construct unambiguous specs and evaluate them for completeness and consistency.

These skills extend beyond coding to essential practices like stakeholder communication and iterative design, mirroring professional agile methodologies. By practicing requirement elicitation through interviews and analysis, students develop critical thinking to spot gaps, conflicts, or ambiguities, preparing them for team-based projects and real-world problem-solving in computer science.

Active learning excels with this topic because students conduct mock interviews, collaborate on spec drafts, and critique peers' work. These approaches make abstract concepts concrete, encourage questioning assumptions, and reveal how poor requirements lead to project failures, boosting retention and practical application.

Key Questions

1. Differentiate between functional and non-functional requirements.
2. Construct a set of clear and unambiguous requirements for a software project.
3. Evaluate the completeness and consistency of a given set of requirements.

Learning Objectives

• Differentiate between functional and non-functional software requirements, providing specific examples for each.
• Construct a set of clear, unambiguous, and testable requirements for a given software problem statement.
• Evaluate a set of software requirements for completeness, consistency, and feasibility.
• Analyze user needs and problem statements to identify implicit and explicit software requirements.

Before You Start

Introduction to Software Development

Why: Students need a basic understanding of what software development entails before learning how to specify requirements for it.

Problem Solving and Algorithmic Thinking

Why: The ability to break down problems and think logically is foundational to translating user needs into structured requirements.

Key Vocabulary

Functional Requirement	A description of a specific function or behavior the software must perform. These define what the system does, such as 'The system shall allow users to reset their password.'
Non-Functional Requirement	A description of a quality or constraint of the software, such as performance, security, or usability. These define how the system performs, like 'The login page shall load within 2 seconds.'
Requirement Elicitation	The process of gathering information about user needs and system constraints from stakeholders. This can involve interviews, surveys, or analyzing existing systems.
Ambiguity	Uncertainty or inexactness in meaning, which can lead to misinterpretation. Requirements must be stated clearly to avoid ambiguity.
Testability	The degree to which a requirement can be verified through testing. Requirements should be written in a way that allows for objective validation.

Watch Out for These Misconceptions

Common Misconception

Requirements only include features the software must have, ignoring quality aspects.

What to Teach Instead

Functional requirements detail actions like user authentication; non-functional cover speed and accessibility. Sorting activities in small groups help students categorize examples and spot missing qualities, building comprehensive specs.

Common Misconception

Vague descriptions like 'user-friendly interface' count as clear requirements.

What to Teach Instead

Requirements must be precise, measurable, and testable to avoid misinterpretation. Peer review stations let students identify vagueness in samples and rewrite them, practicing unambiguous language through discussion.

Common Misconception

Requirements are fixed once written and do not evolve.

What to Teach Instead

Software needs change, so specs require iteration. Mock project simulations with changing client demands show this, as groups adapt specs collaboratively and learn the value of flexibility.

Active Learning Ideas

Role-Play: Stakeholder Interviews

Assign pairs: one as developer, one as client with a vague app idea like a school event planner. The developer asks targeted questions to uncover needs, then drafts initial requirements. Pairs switch roles and compare specs for clarity.

30 min·Pairs

Small Groups: Spec Building Workshop

Provide a problem statement, such as designing a grade tracker app. Groups brainstorm and categorize functional and non-functional requirements, then write a complete spec document. Share one key requirement per group with the class.

45 min·Small Groups

Whole Class: Requirements Review Walkabout

Students post their specs on posters. Class members rotate, noting issues in completeness, consistency, or ambiguity using a checklist. Debrief as a group to refine originals.

35 min·Whole Class

Individual: Iterative Refinement

Students revise their specs based on peer feedback and class discussion. Add test cases to verify each requirement, then self-assess against criteria for unambiguity.

20 min·Individual

Real-World Connections

• Software developers at Google use detailed requirement specifications to build new features for products like Google Maps, ensuring that user needs for navigation and location services are met accurately and efficiently.
• Video game designers at Ubisoft meticulously document functional requirements for character abilities and non-functional requirements for game performance to create immersive and stable gaming experiences for millions of players.
• Financial technology companies, such as Wealthsimple, define strict security and performance requirements for their trading platforms to ensure user data is protected and transactions are processed without delay.

Assessment Ideas

Quick Check

Present students with a scenario, e.g., 'Design a simple online library catalog.' Ask them to list two functional requirements and two non-functional requirements for this system. Review responses for clarity and correctness.

Peer Assessment

In pairs, students draft a set of 3-5 requirements for a hypothetical app (e.g., a task manager). They then swap documents and use a checklist to evaluate their partner's requirements for clarity, testability, and potential ambiguity. The checklist includes questions like: 'Is each requirement specific?' 'Can this requirement be tested?'

Exit Ticket

Provide students with a poorly written requirement, such as 'The app should be fast.' Ask them to rewrite it as a clear, testable non-functional requirement and explain why their revision is better.

Frequently Asked Questions

How do you teach functional vs non-functional requirements in grade 10 computer science?

Start with real app examples: functional like 'allow user login with email', non-functional like 'load pages in under 2 seconds'. Use sorting cards where students classify statements into categories, then justify choices in pairs. This builds differentiation skills while connecting to project specs, ensuring students grasp both for complete designs. Follow with group creation of balanced requirement sets.

What are effective activities for requirements gathering in Ontario CS curriculum?

Role-play interviews simulate stakeholder talks, helping students practice questioning techniques. Group workshops turn problem statements into specs, emphasizing clarity. Peer gallery walks evaluate completeness. These align with CS.HS.D.2 and D.3, fostering collaboration and critical evaluation in 40-45 minute sessions suitable for Term 4 units.

How to evaluate student requirements specifications for completeness?

Use rubrics checking unambiguity, testability, functional/non-functional balance, and consistency. Have students self-assess first, then peer review with checklists. Look for SMART criteria: specific, measurable, achievable, relevant, time-bound. Provide models of strong vs weak specs. This process mirrors industry practices and supports curriculum standards.

How can active learning help students understand requirements gathering?

Active methods like pair interviews and group critiques make the process experiential, as students uncover ambiguities firsthand rather than just reading theory. Collaborative spec-building reveals team dynamics and iteration needs, while review walks build evaluation skills. These approaches increase engagement, retention, and confidence, turning abstract concepts into practical tools for software projects.