SOFTWARE REQUIREMENTS

AND ANALYSIS

W1/D1
INTRODUCTION
Volkan ABUR, PhD, PMP
 Computer Engineer
 Lecturer
 Founder of Nexmind3
 Entrenepreneur
 Volunteer

[Link]/in/
volkan-abur
Software Requirements and
Analysis
is focusing the phases to:
 ROLE AND
IMPORTANCE

“In the software life cycle, Requirements Engineering and Analysis form the foundation of everything that
follows. This is the stage where we translate human needs into precise technical understanding — defining
not just what to build, but why it matters. Clear, well-analyzed requirements prevent costly
misunderstandings later in development and ensure that the final product truly meets user expectations.
In short, this phase is where customer satisfaction begins, because a system built on the right
requirements is one that actually solves the right problem.”
 ROLE AND
IMPORTANCE
(empahised words)

“In the software life cycle, Requirements Engineering and Analysis form the foundation of everything that
follows. This is the stage where we translate human needs into precise technical understanding — defining
not just what to build, but why it matters. Clear, well-analyzed requirements prevent costly
misunderstandings later in development and ensure that the final product truly meets user expectations.
In short, this phase is where customer satisfaction begins, because a system built on the right
requirements is one that actually solves the right problem.”
 ROLE AND
IMPORTANCE
(mottos)

 Where Software Success First Begins

 From Vision to Value: The Lifecycle Connection
 Building It Right
 The Foundation of Software Quality

? It’s your turn. Come up with 3 slogans about Software Deployment and
Maintenance
OUTLINE

Course To provide students with the ability to identify, analyze, document, and validate software
Objective: requirements. To develop the competence to transform user needs into technical specifications
within real project scenarios.

Learning 1. Explain the phases of the requirements engineering process.

Outcome: 2. Distinguish between user and system requirements.
3. Apply various requirements elicitation techniques.
4. Use modeling tools such as use case diagrams, user stories, activity and data flow
diagrams.
5. Prioritize requirements and manage traceability and verification processes.
6. Prepare a complete Software Requirements Specification (SRS) for a given project. |
OUTLINE
Week
Course
Schedule:
OUTLINE
Week
Course
Schedule:
OUTLINE
Week This 16-week course provides a comprehensive understanding of how to
identify, analyze, document, and validate software requirements
Course throughout the early stages of the software life cycle. Students begin by
Schedule exploring the fundamentals of requirements engineering, including types
Summary: of requirements and elicitation techniques, and then progress to
advanced modeling practices such as use cases, user stories, data flow
diagrams, and behavioral models. The course also emphasizes validation,
prioritization, and traceability processes, as well as change management
and agile requirement practices. Through case studies and a capstone
project involving a complete Software Requirements Specification (SRS),
students learn to transform user needs into precise, actionable system
1 quiz
requirements that ensure project success and customer satisfaction.
Assessment 1 Practical
and Participatio Homework 1 Final
n Exam
Teaching
Methods: 1 Midterm
Kahoot and
Mentimeter
Sessions
“If you don’t get the
requirements right,
everything else is
wrong.” – Ian
Sommerville
 Why do software projects fail?
Tree Metaphor

How the How the

consultant project
described it documented

What How tje How tha How the

Customer Project analyst programmer
Explained it Leader designed it wrote it
understood it

What How the How it was What the

operations customer supported customer
installed to was billed really needed
test
Why do software projects fail?
Keywords of
Communication
Importance of
Requirements

“Requirements errors are expensive and visible.”

Fixing a defect in design costs 10x more than in requirements;

fixing it after release costs 100x more.”
 What is Requirements
Engineering?
Definition: “Definition: “A systematic process of discovering,
documenting, and maintaining a set of requirements.”
Origin: From Latin requīrere = “to seek”
In software: Describes what the system should
do, not how it should do it

Example: “The system shall…” statements

«The system shall…» Statements
does) (1)
Functional Requirements (What the system
The system shall allow users to log in using their email and password.
The system shall validate user credentials against the database.
The system shall send an email confirmation after successful registration.
The system shall allow administrators to add, update, and delete user accounts.
The system shall display real-time stock prices updated every 10 seconds.
The system shall record each transaction in the audit log.
The system shall generate a monthly performance report for each department.
The system shall prevent duplicate entries in the product catalog.
The system shall automatically back up data every 24 hours.
1. «The system shall…» Statements
The system shall process each user request within 2 seconds.

2:
(2)
The system shall support at least 1,000 concurrent users.
2 🔒 Security
The system shall encrypt all user passwords using SHA-256. 1 🕒 Performance
The system shall require two-factor authentication for admin users.
3: 6 🌍 Portability
The system shall maintain 99.5% uptime monthly. 4 🧩 Usability
The system shall recover automatically from network interruptions within 30 seconds.
4: 5 🔄 Maintainability
The system shall provide feedback to the user within 1 second after each action. 3 ⚡ Reliability &
The system shall be accessible to visually impaired users according to WCAG 2.1 standards.
Availability
5:
The system shall allow new modules to be added without modifying the core architecture.
The system shall include configuration files that can be updated without recompiling code.
6:
The system shall operate on Windows, macOS, and Linux environments. Non-Functional
The system shall adapt its UI layout automatically for mobile and desktop devices. Requirements
(How. The system
behaves)
«The system shall…» Statements
(3)
Business & Compliance Requirements
The system shall comply with GDPR data privacy regulations.
The system shall generate reports in XBRL format for regulatory submission.
The system shall store financial transactions for a minimum of 7 years.
«The system shall…» Statements
✅ Well-written “The system shall…” statements:

 Express only one requirement (no “and/or” chaining)

 Are measurable and testable
 Avoid unnecessary technical details — describe what the
system must do, not how it will be done

Example:

“The system must be fast” → bad-written statement

rewrite as :

“The system shall process requests within 2 seconds.” → well-written

statement
Requirements Elicitation
Requirements elicitation is the process of
discovering and understanding what users,
customers, and other stakeholders really
need from a software system. It goes beyond
simply collecting requests — it involves
active communication, observation, and
interpretation to uncover both expressed
and hidden needs. Common elicitation
techniques include interviews,
questionnaires, workshops, brainstorming
sessions, document analysis, and
prototyping. The goal is to build a shared
understanding between stakeholders and
developers so that requirements are
accurate, complete, and aligned with
business objectives. Effective elicitation lays
the foundation for every successful software
project.
Requirements Diagrams
 Requirements Diagrams
In requirements engineering, diagrams are used to visualize complex information, clarify
relationships, and bridge communication gaps between technical and non-technical
stakeholders. They help transform abstract requirements into clear, structured
representations that everyone can understand. By using models such as use case
diagrams, data flow diagrams, activity diagrams, or entity-relationship diagrams,
analysts can illustrate system behavior, data movement, and interactions among
components. This visual approach reduces ambiguity, supports validation, and ensures that
both developers and users share the same understanding of what the system must achieve.
The Output of Requirements
Phase
 Requirements Topics
 Types of Requirements: Functional vs Non-functional

 Levels of Requirements: Business → User → System → Design → Implementation

 Dimensions of Software Quality: Performance, security,

Sustainability, clean code

 Common Problems: Ambiguity, volatility, lack of traceability, poor prioritization

 Tools: Jira, Trello, Miro, Visual Paradigm, Lucidchart

 Agile and Traditional Approaches: evolving requirements, user stories,

continuous validation, fixed requirements, formal approval

 Traceability and Change Control: Requirements Traceability Matrix

 Requirements Validation Techniques: Review, walkthrough, prototype, user

acceptance
Two Scenarios (1)
Case 1 – NASA’s Mars Climate Orbiter (1999)
It was supposed to be a proud moment for NASA — a $327 million
spacecraft designed to study Mars’ atmosphere and send back
valuable data. Everything looked perfect on launch day. But as the
orbiter approached Mars, it suddenly vanished. Later
investigations revealed the unthinkable: one engineering team had
used imperial units, while another had used metric. The tiny
mismatch went unnoticed in the requirements documentation. As
a result, the spacecraft entered Mars’ atmosphere too low and
burned up completely. The tragedy wasn’t caused by bad code or
hardware — it was caused by unclear requirements and a missing
standard. A small detail lost in communication destroyed an entire
mission.
 Two Scenarios (1)
Unit mismatch: One team used imperial units (pound-seconds),
another used metric (newton-seconds); this was never reconciled
in requirements documents.
Lack of standardization: No unified data standard or requirement
rule was enforced across engineering teams. NASA Mars Climate
Poor communication: The software and navigation teams worked Orbiter – Key Problems
in silos without validating assumptions.
Missing verification step: There was no independent validation to
ensure all requirements matched across subsystems.
Weak documentation traceability: The conversion requirement
wasn’t traced through design, test, and validation phases.
Overconfidence in automation: The teams assumed “it will work”
without system-level simulation or requirements review.
 Two Scenarios (2)
Case 2 – Denver International Airport Baggage System (1995)

When Denver decided to build one of the world’s most advanced

airports, they dreamed of a fully automated baggage system that
could sort, route, and load luggage faster than any human could.
But the vision was never turned into clear, realistic requirements.
Airlines, engineers, and contractors each had their own
assumptions — and no one aligned them properly. When the
system finally went live, chaos erupted: bags were shredded,
delayed, and sent to wrong gates; thousands piled up in the
terminal. After 16 months of delays and millions of dollars lost, the
city abandoned the automation and returned to manual handling.
The lesson was painful but powerful: great technology without
well-defined requirements leads not to innovation, but to disaster.
 Two Scenarios (2)
Unclear and evolving requirements: System goals changed during
design, but documentation was never updated.
No stakeholder alignment: Airlines, city officials, and contractors
Denver had conflicting expectations.
International Unrealistic scope: The requirement set was too ambitious for the
Airport Baggage given time and technology.
System – Key Insufficient analysis and modeling: Critical timing and mechanical
Problems constraints were never analyzed in detail.
Poor change management: Requirement changes were made
informally, causing inconsistencies.
Inadequate testing environment: The system was never tested
under realistic airport conditions before deployment.
Communication breakdown: No single authority coordinated
requirements between multiple vendors and subsystems.
TEŞEKKÜRLER

+90 533 748 57 70 / @volkanabur