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.

• Class 12
• Computer Science
• 4 activities
• 25 min–45 min

Learning Objectives

1. Identify a specific real-world problem suitable for a database management system capstone project, justifying its relevance.
2. Differentiate between functional and non-functional requirements for a proposed software project, providing at least three examples of each.
3. Analyze user feedback to refine and prioritize functional and non-functional requirements for a given project scope.
4. Design a preliminary project scope document outlining the boundaries and objectives of a software solution.
5. Critique a set of user requirements for clarity, completeness, and feasibility.

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.

Prepare & details

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.

Setup: Requires 4-6 station surfaces — chart paper on walls, columns on the blackboard, or A3 sheets taped to windows. Works in standard Indian classrooms if benches are shifted to create a rotation path; a school corridor or courtyard is a practical alternative where furniture is fixed.

Materials: Chart paper or A3 sheets (one per station), Sketch pens or markers — one distinct colour per group for accountability, Cello tape or Blu-tack for mounting sheets on walls or the blackboard, A whistle or bell for rotation signals audible above classroom noise

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

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.

Prepare & details

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.

Setup: Requires 4-6 station surfaces — chart paper on walls, columns on the blackboard, or A3 sheets taped to windows. Works in standard Indian classrooms if benches are shifted to create a rotation path; a school corridor or courtyard is a practical alternative where furniture is fixed.

Materials: Chart paper or A3 sheets (one per station), Sketch pens or markers — one distinct colour per group for accountability, Cello tape or Blu-tack for mounting sheets on walls or the blackboard, A whistle or bell for rotation signals audible above classroom noise

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

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.

Prepare & details

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'.

Setup: Requires 4-6 station surfaces — chart paper on walls, columns on the blackboard, or A3 sheets taped to windows. Works in standard Indian classrooms if benches are shifted to create a rotation path; a school corridor or courtyard is a practical alternative where furniture is fixed.

Materials: Chart paper or A3 sheets (one per station), Sketch pens or markers — one distinct colour per group for accountability, Cello tape or Blu-tack for mounting sheets on walls or the blackboard, A whistle or bell for rotation signals audible above classroom noise

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

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.

Prepare & details

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.

Setup: Requires 4-6 station surfaces — chart paper on walls, columns on the blackboard, or A3 sheets taped to windows. Works in standard Indian classrooms if benches are shifted to create a rotation path; a school corridor or courtyard is a practical alternative where furniture is fixed.

Materials: Chart paper or A3 sheets (one per station), Sketch pens or markers — one distinct colour per group for accountability, Cello tape or Blu-tack for mounting sheets on walls or the blackboard, A whistle or bell for rotation signals audible above classroom noise

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Assessment Ideas

Exit Ticket

After the Brainstorm Session, ask students to submit a half-page reflection answering: Which local problem did your group select and what two feasibility criteria helped you choose it? Also list one stakeholder you would interview first.

Quick Check

After Sorting Cards, display five mixed requirement statements on the board. Ask students to write on mini-slips whether each is functional or non-functional, then tally results on the board for a quick class discussion.

Peer Assessment

After Feedback Rounds, have pairs exchange their final requirement documents. Each student uses a feedback rubric to assess clarity of scope and completeness of objectives, then shares one strength and one suggestion with their partner.

Extensions & Scaffolding

• Challenge early finishers to design a one-page feasibility report for their top brainstormed problem, including data sources and estimated user load.
• Scaffolding for strugglers by providing a partially filled requirement template with missing fields they must complete after observing a sample kirana store or library.
• Deeper exploration: Ask students to compare their local kirana store problem with a similar system in another country after gathering requirements, noting cultural differences in data needs.

Key Vocabulary

Problem Identification	The process of recognizing and defining a specific issue or need that can be addressed through a technological solution, such as a software application.
Project Scope	Defines the boundaries of a project, detailing what will be included in the software solution and what will be excluded, to ensure focus and manageability.
Functional Requirements	Describe the specific actions or functions a software system must perform, such as data entry, search operations, or report generation.
Non-Functional Requirements	Specify the qualities or constraints of the system, including performance, security, usability, and reliability, rather than specific behaviors.
Stakeholder	An individual or group who has an interest in or is affected by a project, such as end-users, clients, or project managers, whose input is crucial for requirements gathering.