Computer Science · Class 12

Active learning ideas

Problem Identification and Requirements Gathering

Active learning works for problem identification and requirements gathering because students must engage directly with messy, real-world data before designing solutions. When they step out of the classroom to observe local kirana stores or interview librarians, they see firsthand how abstract concepts like 'scope' and 'stakeholders' shape project success.

• CBSE Learning Outcomes
• CBSE: Project Work - System Design - Class 12

• 25–45 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Carousel Brainstorm
• 35 min · Small Groups

Brainstorm Session: Local Problems

In small groups, students list five everyday problems in their community, like school fee tracking, that suit database solutions. They assess feasibility using criteria such as data volume and tech access, then select one and pitch it to the class. Vote on the most promising.

Explain effective techniques for identifying a suitable problem for a software project.

Facilitation Tip

During the Brainstorm Session, gently steer groups toward problems that generate enough data to justify a database, using your own observations as examples when needed.

What to look for

Provide students with a brief scenario of a local problem (e.g., managing a community garden's resources). Ask them to list two functional and two non-functional requirements for a potential app to solve this problem. Also, ask them to identify one potential stakeholder.

• Remember
• Understand
• Analyze
• Relationship Skills
• Social Awareness

Activity 02

• Carousel Brainstorm
• 40 min · Pairs

Role-Play: Stakeholder Interviews

Pairs act as analyst and user; the analyst asks open questions to gather needs for a sample project like hospital records. Switch roles after 10 minutes. Groups compile and classify requirements as functional or non-functional.

Differentiate between functional and non-functional requirements in software development.

Facilitation Tip

In the Role-Play activity, circulate with a timer to ensure every student gets at least two turns as interviewer and interviewee so shy participants don’t hide.

What to look for

Present students with a list of requirement statements. Ask them to classify each as either 'Functional' or 'Non-Functional'. For example: 'The system must allow users to search for books by title.' (Functional) or 'The system must load search results within 2 seconds.' (Non-Functional).

• Remember
• Understand
• Analyze
• Relationship Skills
• Social Awareness

Activity 03

• Carousel Brainstorm
• 25 min · Small Groups

Sorting Cards: Requirement Types

Provide cards with sample requirements; small groups sort them into functional and non-functional piles, justifying choices. Discuss edge cases as a class to refine understanding.

Analyze how user feedback can refine project requirements.

Facilitation Tip

For Sorting Cards, prepare two sets of cards—one functional and one non-functional—so students can physically separate them before debating edge cases like 'system backup every night'.

What to look for

Students work in pairs to define the scope for a hypothetical project (e.g., a school event management system). They then exchange their scope documents. Each student reviews their partner's document and provides feedback on clarity and completeness, answering: 'Are the project boundaries clearly defined?' and 'Are the main objectives understandable?'

• Remember
• Understand
• Analyze
• Relationship Skills
• Social Awareness

Activity 04

• Carousel Brainstorm
• 45 min · Small Groups

Feedback Rounds: Refine Specs

Groups draft requirements for their chosen problem, present to class for feedback. Incorporate suggestions in two revision rounds, noting changes. Reflect on iteration value.

Explain effective techniques for identifying a suitable problem for a software project.

Facilitation Tip

In Feedback Rounds, hand out sticky notes in two colours so students can mark additions and deletions on each other’s requirement lists without erasing original ideas.

What to look for

Provide students with a brief scenario of a local problem (e.g., managing a community garden's resources). Ask them to list two functional and two non-functional requirements for a potential app to solve this problem. Also, ask them to identify one potential stakeholder.

• Remember
• Understand
• Analyze
• Relationship Skills
• Social Awareness

A few notes on teaching this unit

Experienced teachers treat requirements gathering as a detective game rather than a compliance task. They start with concrete, local problems so students feel ownership, then layer in structured techniques like stakeholder interviews and feasibility grids. Avoid rushing to 'solutions'; instead, repeat the mantra 'The problem defines the project, not the other way around.' Research shows that students who iterate on messy, real-world data internalise the fluid nature of requirements better than those who begin with neat textbook examples.

Successful learning looks like students confidently distinguishing between functional and non-functional requirements while justifying their choices with clear examples from their brainstorming and role-plays. They should also demonstrate adaptability by refining requirements based on peer feedback without treating them as rigid rules.

---

Watch Out for These Misconceptions

• During Brainstorm Session, watch for students assuming any real-world problem suits a software project.

  After the Brainstorm Session, hand each group a feasibility checklist (data volume, user count, update frequency) and ask them to discard two problems that don’t meet at least two criteria, explaining why to the class.

• During Sorting Cards, watch for students treating non-functional requirements as optional extras.

  During Sorting Cards, ask students to physically remove any 'non-functional' card they label as 'extra' and then justify its removal to a partner using cost or user impact arguments.

• During Feedback Rounds, watch for students treating requirements as fixed once written down.

  During Feedback Rounds, require each student to propose at least one addition or deletion to their partner’s list and defend it using evidence from stakeholder interviews or feasibility data gathered earlier.

---

Methods used in this brief

• Carousel Brainstorm