1 / 18

🚀 Agile Development & Requirements Engineering

From Theory to Practice

Week 2: COIT20258 Software Engineering

Today's Journey: Discover why 95% of software companies use agile methods and how to write requirements that actually work!

🗺️ The Planning Problem

Traditional Approach: The Perfect Road Trip

Month 1-2
Plan every stop, meal, hotel reservation
Month 3-4
Research all attractions, create detailed itinerary
Month 5
Book everything, no changes allowed
Month 6
Take the trip exactly as planned

❌ What happens when you discover an amazing festival? Construction closes your route? You fall in love with a city?

Agile Approach: The Adaptive Journey

Week 1
Plan general route and first few stops
Travel
Drive, experience, learn what you enjoy
Check-in
Evaluate: What's working? What should we change?
Adapt
Plan next segment based on what you learned

✅ Discover opportunities, adapt to changes, enjoy the journey while still reaching your destination!

🤔 Think About This

Which approach would create a more memorable, valuable experience? Which would handle unexpected changes better? This same principle applies to building software in an uncertain, rapidly changing world.

🧠 The Fundamental Mindset Shift

📐 Traditional Thinking

📋➡️🏗️➡️🚀

"Plan → Build → Deploy"

Core Question:
"How can we build this system perfectly according to the original plan?"
Assumption: We can predict everything upfront and requirements won't change

🔄 Agile Thinking

📋➡️🏗️➡️📊➡️🔄

"Plan → Build → Learn → Adapt"

Core Question:
"How can we continuously deliver value while adapting to what we learn along the way?"
Assumption: We'll learn as we go and need to adapt based on feedback and changing conditions
Consider your own learning: Do you master software engineering by reading all theory perfectly first, then applying it flawlessly? Or do you learn through trying, getting feedback, and adjusting?
I master theory completely first, then apply it perfectly
I learn through cycles of trying, feedback, and adjustment
I prefer detailed planning before any action
Theory and practice are completely separate

Exactly! You naturally use agile principles in learning. You try concepts, get feedback through assignments and discussions, then adjust your understanding. This same iterative learning process works brilliantly for software development.

🎯 Why Agile Actually Works Better

The Counterintuitive Truth

This seemingly "less efficient" approach often produces better results faster

🔍 Early Problem Discovery

Find misunderstandings when they're cheap to fix, not after months of development

"Catching a requirements error in week 2 costs $100. Catching it in month 6 costs $10,000."

👥 Continuous User Learning

Discover user needs you never anticipated through regular feedback cycles

"Users often don't know what they want until they see what they don't want."

🚀 Always Have Something Working

Even if requirements change dramatically, you have valuable software to show for your efforts

"Better to have 50% of features working perfectly than 100% of features 50% complete."

📈 Adapt to Market Changes

Pivot when technology, competition, or business conditions evolve during development

"The world changes faster than we can plan for it."

💡 The Essay Writing Analogy

Traditional Approach: Create perfect outline, write entire essay start to finish without revising

Agile Approach: Write rough draft of one section, get feedback, revise, move to next section incorporating what you learned

Which produces better essays? The same principle applies to software development.

🔥 Real-World Disaster: The $440 Million Bug

Knight Capital Group - August 1, 2012

A single software deployment error caused $440 million in losses in just 45 minutes. The company went bankrupt within days.

Now that you know the full story, how could agile practices have prevented this disaster?
Better documentation of the deployment process
More thorough upfront planning and requirements gathering
Incremental deployment, automated testing, and continuous monitoring
A larger development team with more oversight

Exactly right! Agile practices like continuous integration (catching the dormant code), incremental deployment (testing on one server first), automated testing (preventing dangerous code from reaching production), and continuous monitoring (immediate alerts) would have either prevented this disaster entirely or limited the damage to minutes instead of 45 minutes.

📈 Why Did Agile Emerge?

The Traditional Problem

📋
Plan (6 months)
🔧
Build (12 months)
🚀
Deploy

Reality Check: By the time you deploy, the world has changed, customer needs have evolved, and competitors have moved ahead.

The Agile Solution

Week 1
Plan → Build → Test → Deploy
Week 2
Plan → Build → Test → Deploy
Week 3
Plan → Build → Test → Deploy

✅ Adapt to changes quickly!

📜 The Agile Manifesto (Interactive)

Click each principle to see real-world examples:

👥 People & Interactions

over processes & tools
People matter more than tools

💻 Working Software

over comprehensive documentation
Show, don't just tell

🤝 Customer Collaboration

over contract negotiation
Work WITH customers

🔄 Responding to Change

over following a plan
Embrace the unexpected

🏃‍♂️ Scrum in Action: Virtual Sprint Board

Let's simulate a 2-week sprint for a food delivery app:

📋 Product Backlog

User can create account
User can browse restaurants
User can place order
User can track delivery
User can rate experience

🎯 Sprint Backlog

User can create account
User can browse restaurants

⚡ In Progress

User can browse restaurants

✅ Done

User can create account

Sprint Goal: Enable users to create accounts and discover restaurants

Sprint Duration: 2 weeks | Team Velocity: 2 story points

⚡ Extreme Programming (XP) Practices

👫 Pair Programming

Two developers, one keyboard

Think of it like: Having a coding buddy who catches your mistakes in real-time

🧪 Test-First Development

Write tests before writing code

Think of it like: Planning your route before you start driving

🔄 Continuous Integration

Merge code changes frequently

Think of it like: Updating a shared Google Doc in real-time

🛠️ Refactoring

Constantly improve code quality

Think of it like: Editing a draft essay to make it clearer

Try This: Use pair programming for your next coding assignment - one person types, the other reviews and suggests improvements!

📋 What Are Requirements?

Simple Definition

Requirements are:

  • WHAT the software needs to do (functional)
  • HOW WELL it needs to do it (non-functional)

Real Example: Coffee Ordering App

Functional: User can select coffee size and type
Non-Functional: Order must be processed within 3 seconds
Functional: User can pay with credit card
Non-Functional: App must work on 99.9% of smartphones

👤 User vs System Requirements

🎯 User Requirement Example:

"As a student, I want to check my grades online so I can track my academic progress."

👥 User Requirements (WHAT)

Written for customers in plain language

"I want to see my grades"
"I want to compare my performance"
"I want to download transcripts"

⚙️ System Requirements (HOW)

Detailed technical specifications

"System shall display grades within 2 seconds"
"System shall require login authentication"
"System shall generate PDF transcripts"

🎯 FURPS+ Model for Non-Functional Requirements

📱 Usability

How easy is it to use?

"App must be usable by people with disabilities"

🔒 Reliability

Does it work consistently?

"System must be available 99.9% of the time"

⚡ Performance

How fast/efficient is it?

"Pages must load in under 3 seconds"

🛡️ Security

How well is data protected?

"All data must be encrypted in transit"

🚨 Connecting to Your DRS Project

Agile Approach for DRS

Sprint 1: Basic disaster reporting
Sprint 2: Assessment & prioritization
Sprint 3: Coordination features
Sprint 4: External integrations

DRS Requirements Examples

Functional: Users can report disasters with location and type
Performance: System responds to reports within 30 seconds
Functional: System assigns response teams automatically
Reliability: Available 99.99% of the time during emergencies

🎮 Interactive Activity: Classify Requirements

Classify this requirement: "The system shall respond to disaster reports within 30 seconds"
Functional Requirement
Non-Functional Requirement (Performance)
User Requirement
Business Requirement

Correct! This is a non-functional requirement specifically addressing performance - it defines HOW WELL the system should perform, not WHAT it should do.

Quick Tip: If it answers "HOW WELL" or "HOW FAST" or "HOW SECURE" - it's non-functional!

⚠️ When NOT to Use Agile

🚀 Spacecraft Software

Lives depend on it - need exhaustive testing and documentation

🏥 Medical Devices

Regulatory approval requires detailed specifications

🏛️ Government Contracts

Legal requirements for fixed scope and price

🏭 Legacy System Integration

Complex dependencies require careful planning

Key Insight: Choose your approach based on risk, regulation, and team size. Most projects benefit from a hybrid approach!

🏢 How Top Companies Use These Concepts

🎵 Spotify

Squad Model: Small autonomous teams (8-12 people) that act like mini-startups

Each squad has a product owner, developers, and full autonomy to decide how to work

📺 Netflix

DevOps Culture: Deploy code 1000+ times per day with automated testing

If something breaks, they fix it in minutes, not months

📦 Amazon

Two-Pizza Teams: If you need more than 2 pizzas to feed the team, it's too big

Small teams move faster and communicate better

🚗 Tesla

Continuous Deployment: Over-the-air updates deliver new features monthly

Your car gets better while you sleep!

🛠️ Apply This to Your Other Subjects

📚 Group Assignments

  • Set 1-week sprints
  • Daily check-ins via WhatsApp
  • Review progress weekly
  • Adapt based on feedback

🎯 Personal Projects

  • Break large tasks into small chunks
  • Set clear, measurable goals
  • Get feedback early and often
  • Iterate and improve

💼 Future Career

  • 95% of companies use agile
  • These skills make you valuable
  • Apply beyond software development
  • Leadership and project management

📝 Assignment Tips

  • Use FURPS+ for complete requirements
  • Write user stories clearly
  • Focus on working software
  • Document decisions, not just code

🎯 Key Takeaways

Today You Learned:

  • Why Agile Emerged: Traditional methods too slow for changing world
  • Agile Manifesto: People, software, collaboration, change
  • Scrum & XP: Practical frameworks for agile development
  • Requirements Engineering: Functional vs non-functional, user vs system
  • FURPS+ Model: Complete framework for non-functional requirements

🚀 Your Next Actions:

1. Apply Scrum principles to your Assignment 1

2. Practice writing clear requirements for your DRS project

3. Join an online agile community (Reddit r/agile)

4. Use these concepts in your other group work!

🌟 Remember: Agile isn't just about software - it's a mindset for solving complex problems!