SE311 · Chapter 1 · Annotated SlidesSoftware Requirements Engineering Fundamentals
Original
Overview

Software Requirements Engineering Fundamentals

What a requirement is, the levels and types of requirements (business, user, functional, non-functional, domain), why requirements engineering matters (Mars Climate Orbiter), the RE activities and process, requirements development vs. management, and RE challenges.

How to read this page

Every original slide is shown unchanged. Yellow marks on a slide point to a numbered note: hover or tap a mark to jump to its note, and hover a note to see its marks. Questions tagged Past exam appeared on a real paper; Prediction questions are likely angles, not confirmed. Pick an answer to each question: a wrong pick tells you why it is wrong, so you can try again.

All 33 slides
  1. 1 Slide 1
  2. 2 Slide 2
  3. 3 Introduction
  4. 4 Requirements Engineering (RE) Process
  5. 5 Given that
  6. 6 Course Objectives
  7. 7 Class Project
  8. 8 Class Project
  9. 9 Slide 9
  10. 10 Software Requirements Knowledge Area
  11. 11 What is a software requirement ?
  12. 12 What are software requirements ?
  13. 13 Slide 13
  14. 14 Software Requirements
  15. 15 Non-functional Requirements
  16. 16 Expression of Non-functional Requirements
  17. 17 Slide 17
  18. 18 • Product properties • Product features • How should the system do? • What should the system do? • Helps verify performance. • Helps verify functionality. • More difficult to capture. • Easier to capture.
  19. 19 Slide 19
  20. 20 Slide 20
  21. 21 Domain Requirements
  22. 22 Slide 22
  23. 23 Mars Climate Orbiter
  24. 24 Integrated Resource Management Project (GIRES)
  25. 25 Why Focus on RE?
  26. 26 RE Activities
  27. 27 RE Activity
  28. 28 Requirements Engineering (RE) Process
  29. 29 RE Process
  30. 30 Requirements Development Process
  31. 31 Boundary Between RD and RM
  32. 32 RE Challenges
  33. 33 Slide 33
Slide 1 / 33

Slide 1

Slide 1: Slide 1
Slide 2 / 33

Slide 2

Slide 2: Slide 2
Slide 3 / 33

Introduction

Slide 3: Introduction
Slide 4 / 33

Requirements Engineering (RE) Process

Slide 4: Requirements Engineering (RE) Process

Notes

  1. Requirements errors account for 40–50% of all defects, and they are the most expensive to fix late.

Exam angle

PredictionQ1

Errors introduced during requirements activities account for 40 to 50 percent of all defects found in software.

Slide 5 / 33

Given that

Slide 5: Given that
Slide 6 / 33

Course Objectives

Slide 6: Course Objectives
Slide 7 / 33

Class Project

Slide 7: Class Project
Slide 8 / 33

Class Project

Slide 8: Class Project
Slide 9 / 33

Slide 9

Slide 9: Slide 9
Slide 10 / 33

Software Requirements Knowledge Area

Slide 10: Software Requirements Knowledge Area
Slide 11 / 33

What is a software requirement ?

Slide 11: What is a software requirement ?

Notes

  1. A requirement: a statement of a capability or condition the system must have to satisfy a stakeholder need.

Slide 12 / 33

What are software requirements ?

Slide 12: What are software requirements ?
Slide 13 / 33

Slide 13

Slide 13: Slide 13

Notes

  1. Three levels: BUSINESS requirements (why: objectives) → USER requirements (what users must be able to do) → FUNCTIONAL requirements (what the system must do), plus non-functional requirements and constraints.

  2. Tip Three levels: BUSINESS requirements (why: objectives) → USER requirements (what users must be able to do) → FUNCTIONAL requirements (what the system must do), plus non-functional requirements and constraints.

Exam angle

PredictionQ1

List and briefly explain THREE types of requirements, with an example for each.

Compare with the model answer

Business requirement: why the organization builds the system (e.g. "reduce order processing time by 30%"). User requirement: a task users must be able to do (e.g. "a clerk can register a new customer"). Functional requirement: a behaviour the system must perform (e.g. "the system shall email a receipt after payment"). Non-functional: a quality or constraint (e.g. "pages load within 2 seconds").

Slide 14 / 33

Software Requirements

Slide 14: Software Requirements

Exam angle

PredictionQ1

Which is a functional requirement?

Slide 15 / 33

Non-functional Requirements

Slide 15: Non-functional Requirements

Notes

  1. Non-functional: quality attributes (performance, security, usability, availability), external interfaces, constraints. Harder to capture than functional requirements.

Exam angle

PredictionQ1

Functional requirements are more difficult to capture than non-functional requirements.

Slide 16 / 33

Expression of Non-functional Requirements

Slide 16: Expression of Non-functional Requirements
Slide 17 / 33

Slide 17

Slide 17: Slide 17
Slide 18 / 33

• Product properties • Product features • How should the system do? • What should the system do? • Helps verify performance. • Helps verify functionality. • More difficult to capture. • Easier to capture.

Slide 18: • Product properties • Product features • How should the system do? • What should the system do? • Helps verify performance. • Helps verify functionality. • More difficult to capture. • Easier to capture.
Slide 19 / 33

Slide 19

Slide 19: Slide 19
Slide 20 / 33

Slide 20

Slide 20: Slide 20
Slide 21 / 33

Domain Requirements

Slide 21: Domain Requirements

Notes

  1. Domain requirements: come from the application domain (laws, regulations, domain rules).

Exam angle

PredictionQ1

Which is a domain requirement?

Slide 22 / 33

Slide 22

Slide 22: Slide 22
Slide 23 / 33

Mars Climate Orbiter

Slide 23: Mars Climate Orbiter

Notes

  1. Mars Climate Orbiter (1999) was lost because one team used imperial units and another metric: a requirements/interface failure.

Slide 24 / 33

Integrated Resource Management Project (GIRES)

Slide 24: Integrated Resource Management Project (GIRES)
Slide 25 / 33

Why Focus on RE?

Slide 25: Why Focus on RE?
Slide 26 / 33

RE Activities

Slide 26: RE Activities
Slide 27 / 33

RE Activity

Slide 27: RE Activity
Slide 28 / 33

Requirements Engineering (RE) Process

Slide 28: Requirements Engineering (RE) Process
Slide 29 / 33

RE Process

Slide 29: RE Process

Notes

  1. RE is iterative, not a one-time phase.

Exam angle

PredictionQ1

Requirements engineering is not an iterative process.

Slide 30 / 33

Requirements Development Process

Slide 30: Requirements Development Process
Slide 31 / 33

Boundary Between RD and RM

Slide 31: Boundary Between RD and RM

Notes

  1. Requirements development produces the baseline; requirements management controls changes to it (traceability, versions, status).

Slide 32 / 33

RE Challenges

Slide 32: RE Challenges

Notes

  1. Challenges: unclear scope, changing requirements, stakeholders who disagree or are unavailable, ambiguity, gold-plating.

Slide 33 / 33

Slide 33

Slide 33: Slide 33