Computer Science · Grade 12 · Software Engineering Principles · Term 4

Requirements Engineering

Understanding how to gather, analyze, and document user and system requirements for a software project.

• Ontario Curriculum Expectations
• CS.SE.5
• CS.PM.2

About This Topic

Requirements engineering is the foundational process of defining, documenting, and maintaining requirements for a software system. This involves understanding what the software needs to do (functional requirements) and the qualities it must possess, such as performance, security, and usability (non-functional requirements). Effective requirements gathering ensures that the final product aligns with user needs and project goals, preventing costly rework and scope creep later in development.

Students explore various techniques for eliciting requirements, including interviews, surveys, and use case analysis. They learn to distinguish between user needs and system specifications, and the critical importance of clear, unambiguous, and testable requirements. Understanding the impact of poorly defined requirements, such as project delays, budget overruns, and user dissatisfaction, highlights the value of this discipline within software engineering.

This topic benefits greatly from active learning because students can directly practice elicitation and documentation. Engaging in mock client meetings or analyzing case studies of software failures due to poor requirements allows for immediate application of concepts and development of critical thinking skills.

Key Questions

1. Explain the difference between functional and non-functional requirements.
2. How do ambiguous requirements impact the success of a software project?
3. Design a set of clear and testable requirements for a simple application.

Watch Out for These Misconceptions

Common Misconception

Requirements are just a wish list from the client.

What to Teach Instead

Requirements are detailed specifications that define what the software must do and how well it must perform. Active learning through role-playing client interviews helps students see the structured process of translating needs into actionable requirements.

Common Misconception

All requirements are the same; they just need to be written down.

What to Teach Instead

There's a crucial difference between functional (what it does) and non-functional (how it does it) requirements. Analyzing case studies where ambiguity in either type led to failure, or creating use cases, helps students appreciate the distinct nature and importance of each.

Active Learning Ideas

Role Play: Client Interview Simulation

Students pair up, with one acting as a client and the other as a business analyst. The analyst interviews the client to gather requirements for a hypothetical application, documenting functional and non-functional needs. Roles can be switched for broader practice.

45 min·Pairs

Use Case Diagram Creation

Given a scenario for a simple application (e.g., a library book checkout system), students individually or in small groups create a use case diagram. They identify actors, use cases, and relationships, then write brief descriptions for each use case.

40 min·Small Groups

Requirements Analysis: Case Study

Present students with a case study detailing a software project that failed due to poor requirements. In small groups, they analyze the case to identify specific requirement issues and propose how better requirements engineering could have prevented the failure.

35 min·Small Groups

Frequently Asked Questions

What is the difference between functional and non-functional requirements?

Functional requirements describe the specific behaviors or functions a system must perform, essentially what the software does. Non-functional requirements, on the other hand, define the qualities or constraints of the system, such as performance, security, reliability, and usability.

How do ambiguous requirements impact software projects?

Ambiguous requirements lead to misunderstandings between developers and stakeholders, resulting in features that don't meet expectations. This can cause significant delays, budget overruns, rework, and ultimately, user dissatisfaction with the final product.

How can students practice designing clear and testable requirements?

Students can design requirements for a simple application by first simulating client interviews to gather raw needs. They then practice transforming these needs into specific, measurable, achievable, relevant, and time-bound (SMART) functional and non-functional requirements, which are inherently testable.

Why is active learning beneficial for learning requirements engineering?

Active learning, through simulations like client interviews or analyzing real-world case studies of requirement failures, allows students to directly apply theoretical concepts. This hands-on experience helps them grasp the nuances of elicitation, documentation, and the critical impact of clear, well-defined requirements on project success.