From Requirements to System Design

Real Industry Practice

Gavin Moh · Prismatic Technologies Sdn Bhd
15 May 2026

🎯 INTERACTION 1 — Perfect spec challenge:
"Who thinks in a real job, someone hands you a complete, polished requirements document before you write any code?" (show of hands)
"Hold that thought — ask me again at the end of this session."

🎯 INTERACTION 2 — Work-is-done follow-up:
"Alright, let's say you somehow got that perfect spec, you delivered exactly what it says. Who thinks your work is done at that point?" (show of hands)

🎯 INTERACTION 3 — Group project reality check:
"Now think about your own group projects — did requirements ever actually change halfway through?" (show of hands — then bridge:)
"So: we just said we expect a perfect spec and that delivering it means we're done. But every one of us has already experienced the opposite. Today I'll show you that industry works the same way — and how we deal with it."

🎯 INTERACTION 4 — AI preamble:
"Before we go further — let's talk about AI. Everyone is talking about it. Silicon Valley keeps saying software engineering is done, that AI will replace developers. I want to address this from the perspective of someone actually working in the industry."

🎯 INTERACTION 5 — AI tools:
"How many of you use AI tools — ChatGPT, Copilot, Claude — for coursework?" (show of hands)
"Now keep your hand up if you've ever used AI to help figure out WHAT to build, not just how to code it."
"That gap — between generating code and understanding what actually needs to be built — is what today is about."

🎯 INTERACTION 6 — AI & jobs:
"Who here is worried AI is going to take your job before you graduate?" (show of hands)
"I want to hear from you — what specifically worries you about AI in this field?" (open floor)

About Me

Gavin Moh

Senior Software Developer & DevOps
at Prismatic Technologies.

Talking points (~2 min):

Why I'm here: I'm not an academic. I'm not going to teach you UML notation. I'm here to show you what actually happens between "we should build this" and "it's in production" — the messy middle that textbooks skip.

My path: I've been in software engineering for 8 years. My focus is backend and DevOps. I've worked across software agencies, tech startups, and now an IoT company — so I've seen how different teams operate.

Industries I've touched: Property platforms, interior design ERPs, architecture publishing, ecommerce, HR systems, foreign worker management, cryptocurrency, even multi-level marketing systems. Sounds random — but the pattern is the same: every business has processes they need digitised. The tech changes, the thinking doesn't.

Backend — simple version: When you use an app, the part you see is the frontend. Everything behind that — storing your data, processing requests, running business logic, talking to other services — that's backend. I write code that runs on servers and deals with databases. If the frontend is the restaurant menu, backend is the kitchen.

🎯 INTERACTION 1 — DevOps check: "DevOps — hands up if you could explain what it means to the person next to you."
(Only a few hands go up — that's normal.)
"Alright, I've got the rest of you. Quick version:"
• Traditionally: devs write code, throw it over the wall to ops to deploy. Two separate teams, two separate priorities.
• DevOps breaks that wall: you build it, you run it.
• Developers own deployment, monitoring, infrastructure — the whole lifecycle.

Transition: "Let me introduce you to where I work — because the case study we're going to walk through comes straight from this company."

My Company

Prismatic Technologies

We bridge the physical and digital worlds — IoT sensors, real-time data, and cloud insights for a greener, smarter future.

Flood Monitoring & Prediction

Early warning systems using real-time data to mitigate flood risks.

Continuous EIA on Construction

Monitor noise level and vibration on construction sites.

Earth Slope Monitoring

Detect ground movement via inclination and soil moisture sensors.

Assets Tracking

Monitor high-value assets across any environment with GPS and BLE tracking.

Today's Case Study

Sustainable Building Integrated

Real-time monitoring of energy, water and air quality.

Talking points (~90 sec):

This is where I work now. Before Prismatic I was working at software agencies — we build what the clients ask for. Here it's different: we're building our own products, which means we have to figure out what to build. That's relevant for today.

Our solutions — quick tour:
• Flood Monitoring & Prediction — early warning systems using real-time data to mitigate flood risks.
• Continuous EIA on Construction — monitor noise level and vibration on construction sites.
• Earth Slope Monitoring — detect ground movement via inclination and soil moisture sensors.
• Assets Tracking — monitor high-value assets across any environment with hybrid GPS and BLE tracking.
• Sustainable Building Integrated — real-time monitoring of energy, water and air quality.

I saved this one for last for a reason. Today we're going deep on Sustainable Building Integrated — our case study.

Why this one? It started as a vague internal goal — "we should monitor buildings for ESG compliance." That's it. No spec, no wireframes, no user stories. Everything you're about to see — the architecture, the design decisions, the tech stack — came from us working backwards from that one sentence. That's system analysis and design in the real world.

SDLC models

Same phases, different rhythm

The models are maps, not the territory. They describe the shape of the work — but real projects don't follow straight lines.

Foundation

SDLC

Every project still moves through these concerns, even when the order is messy.

Plan Analyze Design Implement Maintain

Waterfall

One-way handoff

Best when uncertainty is low and each phase can be signed off before the next starts.

1Plan

2Analyze

3Design

4Implement

5Maintain

Agile

Fast learning loop

Best when requirements are still emerging and feedback is more valuable than certainty.

Plan

Build

Test

Learn

Ground this in what they already know. These models are in their syllabus — but I want them to see models as thinking tools, not memorisation material.

SDLC first: planning, analysis, design, implementation, maintenance. Every real project touches all five. The big difference from the textbook is overlap — in industry you'll be clarifying requirements while implementation is already running.

Waterfall: not inherently bad. It works when requirements are truly known and sign-off matters. The risk is using it when nobody actually knows what they want yet.

Agile: a shorter learning loop — plan, build, test, learn, adjust. Useful when requirements are still taking shape and you need user feedback to steer.

Optional question: "If a client says they know exactly what they want, what could go wrong if you believe them too early?" Let students answer, then connect back to uncertainty.

Close: the model is less important than why you chose it. Low uncertainty = longer planning. High uncertainty = shorten the loop. That sets up the next slide — in practice, it's always a hybrid.

Case Study

Sustainable Building Integrated

The market reality that started it all.

📋 What Bursa Demands

Energy: MWh by renewable vs non-renewable, intensity ratio
Water: ML by source, water-stress areas, intensity
GHG: Scope 1, 2 & 3 in tCO₂e
3 years of auditable comparative data

😰 What Companies Have

Track bills and meter readings
manually in spreadsheets
Can't split energy by renewable
vs non-renewable source
Emissions estimated from bills
— if tracked at all
Data scattered across years of files.
No baseline. No audit trail.

🎯 Look at the two columns. Do you see the gap?

Regulators demand granular, auditable data.
Companies can't produce it. Not in any reliable way.

🤔 But wait — is that really true?
Can companies truly not produce this data at all?

Of course they can.
They track bills. They log meter readings in spreadsheets.
They send someone to check the meters every month.
It's just slow. Inaccurate. Unauditable.

Regulators noticed this gap. They're pushing companies toward "reasonable assurance" — verified, real-time, auditable data. Not spreadsheets.

🎯 OPENING: "Alright — let's walk through a real case study. This is a product my company built called Sustainable Building Integrated."

Walk the left column — what Bursa demands:
- Energy: companies must report total MWh, split by renewable vs non-renewable, with intensity ratios (MWh per RM revenue). Most can't even split their electricity bill by source.
- Water: total megalitres withdrawn, broken down by source (municipal, groundwater, surface). Companies in water-stress areas face extra scrutiny.
- GHG: Scope 1 = what you burn directly (company vehicles, generators). Scope 2 = the electricity you buy (TNB's emissions on your behalf). Scope 3 = everything else — suppliers, employee commuting, business travel. Scope 3 is usually 70-90% of total emissions and the hardest to measure.
- 3 years of comparative data: you need to show trends, not just this year's number.

Walk the right column — what companies have:
- Most companies just have their utility bills. They can't break down energy by renewable vs non-renewable.
- Someone walks around reading meters, types numbers into Excel. It's entirely manual.
- Emissions tracking? Most haven't even started.
- 3-year data? They don't have last quarter's.

🎯 INTERACTION 1: Advance to amber prompt. "Do you see the gap?" Wait for students to respond. If they don't, advance to reveal: "Regulators demand granular data. Companies can't produce it."

🎯 INTERACTION 2 — the twist: Advance again. "But wait — is that really true? Can companies not produce this data at all?" Let them think. Then advance: "Of course they can. They track bills. They log readings. They send someone to check the meters. It's just slow, inaccurate, and unauditable."

🎯 CLOSE: Advance to final green callout. "Regulators noticed this. They're pushing toward 'reasonable assurance' — verified, real-time, auditable data. That's the market gap. That's why this product exists."

Transition: "So we saw this gap — regulators demanding reasonable assurance, companies stuck with spreadsheets — and decided to build a platform. Here's what we started with."

The Brief

So We Decided to Build Something

"Build an ESG monitoring platform."

That's it. That was the entire brief.

No RFP. No client interviews. No spec. No user stories. No wireframes.
Just an internal product vision.

This is normal in product companies — you have a direction, not a spec.

🎯 Put yourself in our shoes: Someone hands you this one sentence. What's YOUR first question?

What does "ESG monitoring" actually mean?
What data? Which metrics? How often?
→ Requirements elicitation

Who's going to use this?
Sustainability officers? Facility managers? Regulators?
→ Stakeholder analysis

Where does the data come from?
Existing meters? New sensors? Manual entry?
→ System boundaries & data sources

What are they reporting for?
Bursa compliance? Internal KPIs? Both?
→ Business objectives

🎯 SETUP: "You just saw the regulatory reality — Scope 1, 2, 3 emissions, energy intensity ratios, water stress areas, 3 years of comparative data. Now here's what we actually started with: one sentence."

🎯 INTERACTION: Read the prompt aloud. Let students call out their first question. Validate their answers — they're thinking like an analyst. Then reveal the four questions we asked.

- The gap between what Bursa requires and what we knew is massive. That's the point.
- In a product company, the "client" is the market. Nobody writes the spec for you.
- These four questions became our discovery roadmap.

Transition: "So we had questions. Next step: go find answers. Here's what we did."

Case Study · Discovery

First, We Had to Learn the Domain

📚 Step 1 — Understand ESG. We learned the GHG Protocol: Scope 1 (what you burn directly), Scope 2 (the electricity you buy), Scope 3 (everything else — suppliers, travel, waste). For most buildings, Scope 2 is the largest chunk. Every kilowatt-hour maps to a carbon equivalent. You can't report what you don't measure.

🎯 Step 2 — Decide where to start. We knew how to build IoT. We just learned the ESG landscape. Where would you begin?

⚡ Step 3 — Energy monitoring first.

Largest slice of Scope 2. Every building already has electricity meters.
It's the foundation — once energy data is flowing, water and carbon calculations layer on top.

We built a working prototype. We called it the MVP.

🎯 OPENING: "We're an IoT company — building devices, connecting sensors, beaming data to dashboards. That's our comfort zone. But ESG? That was new territory."

Fragment 1 — Learn the domain:
- We had to understand the GHG Protocol. Scope 1 = what you burn (company vehicles, on-site generators). Scope 2 = the electricity you purchase (TNB). Scope 3 = your entire value chain (suppliers, employee commuting, business travel, waste disposal).
- For most commercial buildings, Scope 2 is by far the largest contributor. Every kWh from TNB has a carbon emission factor — a specific tCO₂e value.
- Core insight: you cannot report emissions you haven't measured. The data has to exist first.

🎯 INTERACTION (fragment 2): "You know what we're good at — IoT, sensors, data pipelines. You just learned the ESG landscape — Scope 1/2/3, energy as the big one. If you were us, where would you start building?" Let students answer. Guide toward energy.

Fragment 3 — Energy first:
- Energy monitoring is the natural entry point. Every building already has electricity meters. It's the biggest contributor to Scope 2. It's the foundation the rest of the platform builds on.
- We built a working prototype — real devices on real meters, data flowing to a dashboard. Was it complete? No. Did it handle water, carbon calculations, Bursa reports? Not yet. But it was real, it was running, and it proved the concept.
- MVP: minimum viable product. Just enough to learn what we didn't know.

Transition: "So we had an MVP. Sensors reading energy meters, data on a dashboard. But energy was never the whole picture — here's what else was on our roadmap."

Case Study

Energy Was Just the Start

The energy MVP proved the concept. Over time, we added more sensors — one by one.

💧

Water

Consumption, flow rate, leak detection. Every litre has a carbon cost.

🌡️

Air Quality

Temperature, humidity, CO₂. Comfort index for occupants.

⚡

Automation

CO₂ too high? Trigger ventilation. No human needed to respond.

🎯 Each sensor type was developed and integrated one at a time. Energy first, then water, then air quality, then automation. Every addition taught us something new about the architecture.

🎯 OPENING: "The energy MVP was running. But that was just the first sensor type. Here's what we added over time — one by one, each in its own iteration."

Water: Consumption tracking, flow rates, leak detection. Water treatment and distribution generate carbon, so every litre has an emissions footprint. Different meter type, different protocol — had to integrate it into the existing pipeline.

Air quality: Temperature, humidity, CO₂. This is about occupant comfort and health. CO₂ buildup in meeting rooms affects cognitive performance. Yet another sensor type with its own data format.

Automation: If CO₂ hits a threshold, trigger ventilation. This was a step change — the system now needs to send commands, not just collect data. It needs to act. Different requirement, different architecture challenge.

Closing callout: "Notice the pattern. We didn't design for all of these upfront. We added them one at a time — energy, water, air quality, automation. Each addition was its own mini-sprint. Each one tested whether our architecture could actually grow without breaking."

Transition: "So with the energy MVP running and more sensors on the way, we took the system into a real building. Here's what happened."

Case Study · Deployment

Time to Put the MVP in a Real Building

Our first design was straightforward — and probably familiar:

📡 WiFi
Sensors

→

☁️ Cloud
Server

→

📊 Dashboard

WiFi sensors → internet → cloud → dashboard. Clean and simple — on paper.

🎯 Looks familiar, right? But a commercial building is not your living room.

⚠️ Dead zones everywhere
Mechanical rooms. Basements. Rooftops. No WiFi reaches where the meters actually live.

🚫 "You're not putting devices on our network."
Building owners have security policies. IT teams don't want unknown IoT devices on their WiFi.

🌐 Internet goes down → system is dead
At home, no big deal. In a commercial building with compliance obligations? A single outage means missing data.

Home ≠ commercial.
Residential = single phase. Commercial = 3-phase + digital power meters. Different hardware, different stakes.

🎯 OPENING: "We had a working MVP. Energy meters, data flowing, dashboard live. Time to deploy in a real building."

Fragment 1 — the design: Walk the diagram. "WiFi sensors → cloud → dashboard. If this looks familiar, it should — it's exactly how consumer IoT works. Your Tuya smart plug, your Smart Life temperature sensor, your WiFi camera. This architecture is everywhere."

🎯 INTERACTION (fragment 2): "Show of hands — who here has IoT devices at home? Tuya? Smart Life? Xiaomi? WiFi plugs, sensors?" (Most hands should go up.) "Yeah, me too. This is the exact same architecture. But a commercial building is nothing like your living room."

Fragments 3-4 — reveal problems:
- Dead zones: at home, your WiFi router is in the middle of a small apartment. In a commercial building, meters live in mechanical rooms, basements, electrical risers — the worst possible places for WiFi. Concrete walls, steel structures.
- Network access: at home, it's YOUR WiFi. In a building, the owner's IT team has security policies. They are not handing over credentials so you can stream sensor data.
- Internet reliability: at home, if WiFi drops for an hour, your smart plug just waits. In a commercial ESG system, missing data means a failed compliance audit. Different stakes entirely.
- The red card: "Residential is single phase. Commercial is 3-phase with digital power meters. The hardware is completely different — and so are the stakes. A failed compliance audit because of missing data is not the same as a smart plug that won't turn on."

Transition: "So WiFi was out. We needed a way to get data out of mechanical rooms, basements, and rooftops — without touching the building's network. That's when we discovered LoRaWAN."

Case Study · Recap

Let's Look at What Just Happened

①

Learned ESG. Scope 1, 2, 3. Energy is the largest chunk.

②

Narrowed to energy monitoring. Built a working prototype. MVP.

③

Deployed in a real building. WiFi sensors → cloud → dashboard.

④

WiFi dead zones. No network access. Pure cloud unreliable.

Plan

Build

Test

Learn

🎯 This is Agile. One sprint done. Now we apply what we learned and go again.

🎯 OPENING: "Let's pause and look at what we just went through. Four steps. Each one built on the last."

Fragments 1-4 — walk each card:
- ① We learned the ESG domain. Scope 1/2/3. Energy is the big one.
- ② We narrowed to energy monitoring. Built a working prototype in the lab. MVP.
- ③ We deployed in a real building. WiFi sensors → cloud → dashboard.
- ④ (red card) We discovered WiFi dead zones, no network access, pure cloud is fragile.

Fragment 5 — the labels: "Now let me put names on these. ① = Plan. ② = Build. ③ = Test. ④ = Learn. This is the Agile cycle — Plan what to build, Build the smallest thing, Test it in the real world, Learn what's broken."

Fragment 6 — Agile: "This is Agile. Not a buzzword — just a pattern. We started with a rough idea, built the smallest thing that works, tested it, and discovered what we didn't know. One sprint, complete. Now we take those lessons and start the next one."

Reality check (say this, not on slide): "Now, before you think this was a neat two-week sprint — it wasn't. This took months. Nobody at the time was saying 'let's do a sprint.' We were just figuring things out. I'm retrofitting the labels so you can see the pattern, but the pattern is real."

Transition: "We learned three things: WiFi doesn't work everywhere, building networks are off-limits, and pure cloud is fragile. Next: apply those lessons. Here's what we built instead."

Case Study

WiFi Failed. What Replaces It?

📶 Cellular ✗

1 SIM card per device. Who manages 100 SIMs across a building? Who pays the data plan? At building scale — far too expensive.

🔵 Bluetooth ✗

Range is actually shorter than 2.4GHz WiFi. You'd need a gateway in every single room — same dead zone problem, just more hardware.

🔶 Zigbee ✗

Mesh network — nodes relay through each other. Still needs a coordinator per floor. Adds networking complexity we didn't want at scale.

📡 LoRaWAN ✅

Ultra-long range — one gateway covers an entire building. Low power — batteries last years. Own frequency — no dependency on building IT. Already proven in our other projects.

⚠ Trade-offs: Low data rate — we send only the most important readings. Limited 2-way communication — we designed simple relays for automation.

🎯 We didn't pick the "best" technology. We picked the one that fit our constraints — range, cost, power, and what we already knew.

🎯 OPENING: "WiFi failed. So we went looking for alternatives. Here's what we considered — and how we made the choice."

Fragment 1 — Cellular: "There are 4G/5G modules for IoT. But one SIM per sensor — at 50 sensors per building, who's managing 50 phone numbers? Who's paying RM30/month per SIM? Who handles telco contracts for every deployment? At commercial building scale, it's a logistics nightmare."

Fragment 2 — Bluetooth: "BLE range is about 10 metres in ideal conditions. Through concrete walls? Maybe 3 metres. You'd need a Bluetooth gateway in every room. That's the same dead zone problem — you're just installing more hardware to work around it."

Fragment 3 — Zigbee: "Zigbee uses a mesh — nodes relay messages through each other. Sounds clever, and it works great in smart homes. But at building scale, you still need a coordinator on every floor. Mesh routing adds latency, complexity, and failure modes we'd rather not debug at 2am."

Fragment 4 — LoRaWAN: "LoRaWAN's range is measured in kilometres. One gateway covers the entire building — basement to rooftop, through concrete and steel. Sensors run on batteries for 5+ years. It operates on its own frequency band — no touching the building's network at all. Trade-offs: you're sending small binary packets, not streaming data. We pick the most important readings. Two-way communication is limited — for automation, we designed simple relays that accept basic on/off commands. We'd already used LoRaWAN for outdoor asset tracking — it was familiar territory. We knew the quirks."

Fragment 5 — closing: "In industry, you rarely pick the 'best' technology. You pick the one that fits your constraints. Range. Cost. Power. Existing expertise. LoRaWAN checked our boxes — not all boxes, but the ones that mattered."

Transition: "So now we had a way to get data out of any corner of the building. But we still had one problem left — what happens when the internet goes down?"

Case Study

LoRaWAN Fixed Connectivity. What's Still Wrong?

📡 LoRa
Sensors

→

📶 Gateway

→

☁️ Cloud

→

📊 Dashboard

🎯 Building loses internet. What happens to your system?

📡 LoRa
Sensors

→

🧠 Edge
Gateway

→

☁️ Cloud

→

📊 Dashboard

⚡ Edge computing. Make the gateway smart. Automation runs locally — no cloud round-trip. Internet down? Gateway buffers readings, syncs when back online.

🎯 OPENING: "LoRaWAN solved connectivity. No more dead zones. No more begging building IT for network access. But look at the gateway — right now it's just a dumb relay forwarding everything to the cloud. We fixed one problem and exposed another."

🎯 INTERACTION (fragment 2): "The building loses internet. Construction crew cut a cable. ISP outage. What happens to your ESG system right now?" Let students answer. Guide them: data stops flowing, dashboard goes blank, automation is dead.

Fragment 3 — Edge computing: "What if the gateway wasn't dumb? What if it could process data, make decisions, buffer readings — all locally? That's edge computing. Automation triggers instantly on the gateway — no waiting for a cloud round-trip. Internet drops? The gateway keeps collecting and buffering. Reconnects? Syncs everything. The building doesn't even notice the outage. And remember those CO₂ sensors from earlier? With edge, the gateway triggers ventilation directly — no internet needed."

Fragment 4 — updated diagram: "Gateway → Edge Gateway. Same hardware, much smarter. Local processing for automation. Offline buffer for resilience. Cloud handles long-term storage, analytics, ESG reporting. The cloud is no longer a single point of failure."

Transition: "So now we had the architecture: LoRaWAN for connectivity, Edge for reliability, Cloud for analytics. Here's how it all came together."

Case Study

The Dashboard Had Its Own Journey

While we solved connectivity and reliability on the hardware side, the software was evolving through its own discovery — one requirement at a time.

📊 First: just show everything

Power, voltage, ampere, temperature, humidity, CO₂, water flow. Display every reading we're collecting. Raw. Honest. Exhausting.

🔐 Then: protect it

Added login. Not everyone should see every building's data. Different users, different access.

📱 Then: stop expecting users to watch

People don't stare at dashboards all day. Added Telegram alerts — push notifications when something actually matters.

🎯 OPENING: "All that hardware talk — LoRaWAN, edge gateways, dead zones. But what about the software? What did the users actually see? That had its own discovery journey."

Fragment 1 — raw readings: "We built exactly what you'd expect: a dashboard showing every reading. Power. Voltage. Ampere. Temperature. Humidity. CO₂. Water flow. Every sensor, every data point. We were proud of it."

Fragment 2 — login: "Then we realized: different people need different views. A facility manager shouldn't see another building's data. A sustainability officer shouldn't be able to change settings. Basic access control."

Fragment 3 — alerts: "Bigger realization: nobody sits watching a dashboard. You can't hire someone to stare at CO₂ readings hoping to catch a spike. We added Telegram notifications — thresholds trigger alerts. Don't watch the dashboard. The dashboard tells you when to look."

Transition: "So now we had a dashboard with login and alerts. Multiple clients started asking to use it. That's when we hit the next problem."

Case Study

The Dashboard Journey (Continued)

🏢 Multiple clients = copied code

Started deploying to more clients. Realized we were duplicating the entire codebase every time. Made it one multi-tenant platform — one codebase, many tenants.

👻 Then: nobody was looking

Users stare at the dashboard for two weeks. Then stop. Nobody cares about raw ampere readings. The dashboard that took months to build? Ghost town.

🌳 So: translate the numbers

Users don't feel kilowatt-hours. They feel trees saved. Cars off the road. Energy saved vs baseline after turning off the aircond at night. Help them tell their ESG story.

🎯 Then two more requirements hit us — both from outside, neither we planned for.

🎯 OPENING: "Dashboard was live. Login. Alerts. Multiple clients started asking to use it. Great problem to have, right?"

Fragment 1 — multi-tenant: "Every new client meant copying the entire codebase. Separate server, separate database, separate deployment. Maintaining ten copies of the same code is a nightmare. We consolidated into one multi-tenant platform — one codebase, one deployment, data separated by tenant. Huge architectural change driven by a scaling problem."

Fragment 2 — nobody looks: "We built this beautiful dashboard. Users opened it every day... for about two weeks. Then the novelty wore off. Nobody stares at ampere readings. Nobody cares about voltage fluctuations. The dashboard became a ghost town. Hard truth: we built something users didn't actually want to use."

Fragment 3 — storytelling: "So we asked: what DO they care about? They care about their environmental impact. But not in kilowatt-hours — in something they can feel. How many trees did we save this month? How many cars is that equivalent to? How much energy did we save compared to last year, after we fixed that aircond leakage? We stopped showing raw data and started helping clients tell their ESG story."

Fragment 4 — teaser: "And then, from completely outside our planning, two more requirements landed."

Transition: "These didn't come from us. They came from regulators and the utility company."

Case Study

Requirements You Don't Plan For

These came from the outside. Clients brought them to us.

🏗️ Building Energy Intensity (BEI)

Clients pursuing Green Building Index certification asked: "Can your platform track BEI — kWh per square metre per year?" We hadn't heard of it. We added it.

⚡ TNB maximum demand

Exceed your maximum demand during TNB's peak hours? Heavy penalty. Clients wanted monitoring and alerts before they hit the threshold. We added peak-hour tracking.

🎯 Every feature on these slides was discovered AFTER we started building. None of it was in the original brief. Requirements don't wait for a "phase" to end.

🎯 OPENING: "Two requirements we never planned for. Both came from clients asking 'can your platform do this?'"

Fragment 1 — BEI / GBI: "The Green Building Index is Malaysia's green building rating system. It scores buildings across six categories — energy efficiency, indoor environment, water, materials, site planning, and innovation. Buildings earn Certified, Silver, Gold, or Platinum based on their score. While GBI is NOT required for a standard operating license (that's an administrative process with SSM documents, tenancy agreements, signboard approvals from DBP), many developers and building owners pursue GBI because Penang councils offer incentives — cash rebates on development charges for Gold/Platinum, density bonuses for certified buildings. Plus, new commercial buildings in Penang must install solar on 75% of roof area. Our clients pursuing GBI asked: 'Can your platform track Building Energy Intensity — kWh per square metre per year — as part of Energy Efficiency scoring?' We'd never dealt with BEI before. We built it into the platform."

Fragment 2 — TNB maximum demand: "TNB charges commercial and industrial customers based on their Maximum Demand — the single highest power draw in any 30-minute window during peak hours (8am-10pm). Even if your factory is quiet 99% of the month, one spike — like turning on all your chillers at once — locks in your MD charge for the entire billing cycle. This is a 'capacity readiness' fee. TNB has to build infrastructure to handle your worst-case load, and they charge you for it whether you use it or not. At up to RM97 per kW, this can be a huge chunk of the bill. Clients were getting surprise penalties and asked us: 'Can you monitor usage against TNB peak hours and alert us BEFORE we exceed?' We added real-time tracking against peak-hour thresholds."

Fragment 3 — closing: "Look at everything on these three slides. Raw readings. Login. Telegram alerts. Multi-tenant. Storytelling. BEI. TNB peak demand. Not one of these was in the original brief — 'Build an ESG monitoring platform.' Every single feature was discovered along the way. Requirements don't arrive neatly at the start of a project. They show up while you're building. That's the reality."

Transition to next slide: "And that brings us back to the big picture — what really happens in industry versus what the textbook tells you."

Reflection

Where Do Requirements Actually Come From?

🧠 Product vision
"Build an ESG monitoring platform" — one sentence. No spec.

📚 Domain research
Learning GHG Protocol, Scope 1/2/3, what Bursa actually requires.

⚠️ Technical failure
WiFi dead zones forced us to find LoRaWAN.

🔬 Technology research
Evaluating cellular, Bluetooth, Zigbee before choosing.

🙋 Client requests
"Can you track BEI? Can you monitor TNB peak demand?"

🔌 Regulatory discovery
Bursa ESG mandates. GBI scoring criteria. New rules, new features.

📊 Usage data
Nobody looked at the dashboard. Forced us to rethink storytelling.

None of these were JAD sessions or formal interviews.
But every one required communication — with a client, a domain expert, a regulator, a teammate.

🎯 Requirements gathering isn't a phase. It's a continuous conversation that happens through every channel, all the time.

🎯 OPENING: "Let's zoom out. We just walked through an entire product journey. Look at where every single requirement actually came from."

Walk each card (fragments 1-7):
- Product vision: internal direction, no client. "Build an ESG platform."
- Domain research: we didn't know ESG. We had to learn it. Every lesson became a requirement.
- Technical failure: WiFi didn't work. The building forced a new requirement on us.
- Technology research: we didn't just pick LoRaWAN. We evaluated and eliminated alternatives.
- Client requests: BEI and TNB MD came from clients knocking on our door with problems we hadn't anticipated.
- Regulatory discovery: Bursa mandates, GBI scoring — the rules changed, and our product had to follow.
- Usage data: the dashboard was a ghost town. The data told us we built the wrong thing.

Fragment 8 — the punchline: "Your textbook teaches JAD sessions, structured interviews, questionnaires. Those are tools — they have their place. But look at this list. Not one of these came through a formal elicitation process. Requirements arrived through product vision, technical failure, client panic, regulatory change, and usage analytics."

Fragment 9 — closing: "Requirements gathering isn't a phase you complete. It's a continuous conversation — with clients, domain experts, regulators, and your own data. The person who can listen across all these channels, and translate between them? That's the analyst. That could be you."

Transition: "And that brings us back to the big picture — what really happens in industry versus what the textbook tells you."

Case Study

How We Actually Built and Shipped

🔄 You build it, you run it

No separate ops team. Developer writes, reviews, deploys, and owns it in production. Build → Review → Deploy. Ship fast, continuously.

🔌 Real hardware testing

You can't fully simulate IoT. Test environment with actual sensors and gateways. Without physical devices, you're shipping blind.

🛠️ Maintenance never ends

Firmware updates for devices. Security patches for gateways. Monitor production to catch issues before the client calls. System is never "finished."

🎯 The system is never "finished." New sensor type, new report format, new integration — there's always something next.

🎯 OPENING: "We've talked about discovery, design, connectivity, edge, dashboards. But how did we actually build and ship all of this?"

Fragment 1 — Build → Review → Deploy: "Every change goes through peer review before it reaches production. No automated tests — just another developer checking your work. That means every commit has to be clean, readable, and obviously correct. The safety net isn't automation — it's another pair of eyes."

Fragment 2 — hardware testing: "You can mock sensor data for API tests, and we do. But when a physical energy meter sends readings in a weird format at 3am, no unit test catches that. You need real hardware. We kept a test environment with actual sensors, gateways, and meters running. Every release hit physical hardware before going to clients."

Fragment 3 — maintenance: "The SDLC textbook puts maintenance as the last phase. In reality, it starts the day you deploy. Devices need firmware OTA updates. Gateways need security patches. You need monitoring that catches issues before the building operator calls you. Maintenance isn't a phase — it's continuous."

Fragment 4 — closing: "The system is never finished. There's always a new sensor type to integrate, a new report format to support, a new client with a new requirement. That's not a failure — that's the nature of software."
Transition: "So what does all of this mean for how we think about system analysis and design?"

What Really Happens in Industry

Pure Waterfall is rare No client knows every requirement upfront.

Agile is usually hybrid Teams borrow the parts that help them move.

Small changes, often Ship continuously. Tiny increments reviewed and deployed fast beat big-bang releases.

Requirements keep arriving They do not politely wait for a "phase" to end.

The SDLC is not wrong Reality is more overlapping than the diagrams suggest.

Your job is adaptation Keep the system stable while the product learns.

Change is the constant If you cannot accept that things will change, this industry will feel painful.

Speed beats completeness Ship the MVP first, add features later. Users reveal what actually matters.

- The textbook models give you a vocabulary. Reality uses pieces of all of them.
- Pure Waterfall is almost unheard of in industry today because no client can give you complete requirements upfront. Software is too complex for that.
- CI/CD is common in tech companies and startups, but many smaller or traditional companies are still catching up. What matters more than automation is the habit: ship small changes often, review each other's work, don't let code pile up.
- Pause after the closing lines. Every student who raised their hand earlier about "work is done after delivery" should feel this.
- Speed beats completeness: this directly contradicts what they're taught in uni — submit polished assignments. In industry, you ship rough and iterate.

Theory concepts: SDLC models, iterative vs sequential development, CI/CD.

What This Case Study Taught Me

Requirements are discovered, not collected.
One sentence → LoRaWAN, edge, multi-tenant, BEI, TNB MD. None of it was in the original brief.
Failure is a better teacher than planning.
WiFi dead zones taught us connectivity. The ghost town dashboard taught us what users actually want.
Constraints make better decisions than preferences.
We didn't pick LoRaWAN because it's "better." Cellular was too expensive, BLE too short-range, Zigbee too complex. Constraints forced the right choice.
You don't need to know everything upfront. Just start.
Energy first. One sensor. One building. Learn. Then water. Then air quality. Then automation. Just start.

🎯 CLOSING: "Four things this case study taught me — and I hope it teaches you too."

Point 1: Look at everything we built. LoRaWAN, edge gateways, multi-tenant platform, BEI tracking, TNB peak demand monitoring. Not one of those was in the original brief. Requirements aren't collected in week one — they're discovered over months.

Point 2: The WiFi failure taught us more about building connectivity than any white paper. The empty dashboard taught us more about user needs than any interview. Failure is data. Listen to it.

Point 3: We evaluated four technologies and eliminated three. The choice wasn't made by preference — it was forced by constraints. Range. Cost. Power. Existing expertise. Good architecture comes from understanding what you CAN'T do.

Point 4: We didn't build the whole platform at once. Energy monitoring first. One sensor type. One building. Then we learned. Then we added water. Then air quality. Then automation. You don't need the full picture to start. You just need to start.

Transition: "Everything I just showed you — the architecture, the tech choices, the dashboard features — came from discovering requirements as we went. Not from a document we wrote at the start. That's the real job of system analysis and design. Now — what questions do you have?"

Questions?

From Requirements to System Design · Gavin Moh · Prismatic Technologies Sdn Bhd