Aşama 1: Paydaş ve Sistem Gereksinimleri

15 Ağustos 2025

Önce işin temeli!

Pekâlâ, parlak IoT ürün fikrinizin tutulmaya değer olduğuna karar verdiniz. Sırada ne var? Hemen cihaz yapmaya ve firmware kodlamaya atlamak için sabırsızlanıyor olabilirsiniz, ama dizginleri çekin. Başarılı her projenin en birinci adımı gereksinimleri toplamaktır. Yeni bir devreye enerji vermek ya da şık kod yazmak kadar heyecan verici gelmeyebilir, ama bize güvenin – gereksinimler bundan sonraki her şeyin temelidir. Aşama 1’i, maceraya yelken açmadan önce hazine haritasını çizmek gibi düşünün. Bu adımı atlamak, haritasız bir sefere çıkmak gibidir – maceralı olur belki, ama sonu muhtemelen kötü biter. 😅

Aşama 1: Paydaş ve Sistem Gereksinimleri’nde tüm kilit oyunculardan girdi toplar ve neyi neden inşa ettiğimizin net bir tanımını ortaya koyarız. Ürünün tam olarak ne yapması gerektiğini, hangi koşulları karşılaması gerektiğini ve uyması gereken tüm kısıtları tanımlayacağız. Bu aşamaya zaman yatırarak kendinizi ileride sayısız baş ağrısından kurtarırsınız. Yolun devamındaki her tasarım kararı, her kod satırı ve koşacağımız her test, bu ilk gereksinimlere kadar izlenebilecek. Onlar, sonraki tüm çabalara yön veren projenizin Kutup Yıldızı’dır. Sağlam gereksinimler olmadan tasarıma dalarsanız, yanlış şeyi inşa etme ya da kritik bir şeyi kaçırma riskini alırsınız. Ve kabul edelim, kimse aylarca çalıştıktan sonra önemli bir özelliğin gözden kaçtığını ya da bir varsayımın yanlış olduğunu fark etmek istemez.

Bu bölümde, paydaş ve sistem gereksinimlerini yakalamanın ne anlama geldiğini adım adım açacağız. Bu aşamanın neden bu kadar önemli olduğunu, ne tür gereksinimleri düşünmeniz gerektiğini ve bunları nasıl net biçimde belgeleyeceğinizi anlatacağız. Gereksinimleri erkenden sağlama almanın IoT projenizi nasıl var edip yıkabileceğini gösteren bazı örnekler (ve ibret hikâyeleri) de paylaşacağız. Dalmaya hazır mısınız? Hadi gereksinimleri daha en baştan doğru yapalım!

Gereksinim Tam Olarak Nedir?

Peki “gereksinim” derken neyi kastediyoruz? En yalın haliyle gereksinimler, ürününüzün ne yapması gerektiğinin ve bunu hangi koşullar altında yapması gerektiğinin ayrıntılı bir tanımıdır. Projenizin kural kitabı ya da kontrol listesi gibidirler; IoT cihazınızdan beklenen her şeyi, siz onu daha inşa etmeden kayda geçirirler. IoT ürününüz bir hikâye olsaydı, gereksinimler onun olay örgüsü taslağı olurdu – tüm kilit unsurların tanımlı olmasını, hikâyenin sonunda anlamlı çıkmasını sağlarlar.

Gereksinimler, her biri ürününüzün farklı bir yönünü kapsayan birkaç çeşitte gelir. Ana kategoriler şunlardır:

Fonksiyonel Gereksinimler: Ürünün ne yapması gerektiği – özellikleri ve davranışları.
Fonksiyonel Olmayan Gereksinimler: Ürünün nitelikleri ve kısıtları – ne kadar iyi performans gösterdiği, ne kadar dayandığı vb.
Arayüz Gereksinimleri: Ürünün diğer sistemlerle ve dış dünyayla nasıl etkileşeceği.

Bu kategorilerin her birine birazdan ayrıntısıyla gireceğiz. Şimdilik şunu aklınızda tutun: iyi bir gereksinim net, spesifik ve test edilebilirdir. “Cihaz müthiş olmalı” demek yetmez – bu, mühendislik ekibinize hiçbir şey kazandırmaz. Bunun yerine “Cihaz, sıcaklığı 0°C ile 50°C arasında ±0,5°C doğrulukla ölçmelidir” gibi somut ifadeler gerekir. Ne kadar spesifik olduğuna dikkat ettiniz mi? Okuyan herkes tam olarak ne beklendiğini bilir ve ileride cihazın bu kriteri karşılayıp karşılamadığını gerçekten test edebilirsiniz. Gereksinim yazarken hedeflediğimiz netlik seviyesi işte bu.

Fonksiyonel Gereksinimler

Fonksiyonel gereksinimler, IoT ürününüzün belirli özelliklerini, işlevlerini ve davranışlarını tanımlar. Başka bir deyişle sistemin ne yapması gerektiğini açıkça yazarlar. Biri “Cihazınız ne yapıyor?” diye sorduğunda, cevap fonksiyonel gereksinimlerin bir özeti olacaktır. Bu gereksinimler tamamen cihazınızın kullanıcıya ya da diğer sistemlere sunduğu aksiyonlar ve hizmetlerle ilgilidir.

Bir IoT cihazı için fonksiyonel gereksinimler genellikle şunları içerir:

Veri algılama veya aksiyonlar: Cihaz hangi veriyi ölçüyor ya da hangi aksiyonları gerçekleştiriyor? (örn. sıcaklık ölçer, vana açar, konum takibi yapar)
Veri doğruluğu ve aralığı: Bu ölçümler ne kadar doğru? Hangi değer aralığını kaldırabiliyor? (örn. sıcaklığı 0°C ile 50°C arasında ±0,5°C doğrulukla ölçer)
Sıklık veya zamanlama: İşlevini ne sıklıkla yerine getiriyor? Güncellemeleri dakikada bir mi, saatte bir mi gönderiyor? Ne kadar hızlı yanıt vermeli? (örn. 10 dakikada bir ölçüm alır ya da bir komuta 2 saniye içinde yanıt verir)
Veri işleme: Veriyle ne yapıyor? Cloud’a mı gönderiyor, hafıza kartına mı kaydediyor, yoksa bir ekranda mı gösteriyor?
Belirli modlar veya özellikler: Örneğin, bir eşik aşıldığında devreye giren bir alarm modu var mı? Kendini kalibre edebiliyor mu? Havadan (OTA) firmware güncellemelerini destekliyor mu?

Bunu bir örnekle canlandıralım. Akıllı ev kullanımı için basit bir IoT sıcaklık sensörü yaptığınızı varsayalım. Bazı fonksiyonel gereksinimler şöyle olabilir:

Cihaz, ortam sıcaklığını 0°C ile 50°C arasında ±0,5°C doğrulukla ölçmelidir.
Cihaz, en az 10 dakikada bir sensör ölçümü almalıdır (güncelleme hızı).
Cihaz, her ölçümden sonra sensör verisini 30 saniye içinde bir cloud sunucusuna iletmelidir (veri gecikmesi).
Cihaz, sıcaklık kullanıcı tanımlı bir eşiği aştığında bir LED yakıp söndürmeli ve uyarı göndermelidir.

Bunların her biri, sistemin yaptığı bir şeyi tanımlayan birer fonksiyonel gereksinim. İfade biçimlerine dikkat edin: genellikle “Cihaz … -malıdır” kalıbıyla başlayıp spesifik bir aksiyon ya da davranışla devam ederler. Bu format, ileride “Evet, cihaz gerçekten de belirtildiği gibi X’i yapıyor” doğrulamasını kolaylaştırır.

İyi fonksiyonel gereksinimler, yetenekler konusunda net bir resim çizer. Mühendislik ekibinin tam olarak hangi özellikleri gerçekleştireceğini bilmesini sağlarlar. Bunları sağlama aldıysanız, donanım ve yazılım tasarımcılarınız bunlara nasıl ulaşacaklarını düşünmeye başlayabilir (ama önce ne yapılacağı gelir; bu gereksinimleri şimdi tanımlamamızın sebebi de bu). Net fonksiyonel gereksinimler olmadan, kullanıcının gerçekten ihtiyaç duyduğu şeyi yapmayan bir ürünle kalabilirsiniz. Örneğin, gösterişli bir IoT hava istasyonu yaptığınızı ve kimse açıkça gereksinim olarak yazmadığı için nem sensörü koymadığınızı sonradan fark ettiğinizi hayal edin – tüh! Fonksiyonel gereksinimleri baştan tanımlamak, olmazsa olmaz tüm özellikleri en başından yakalayarak bu “tüh” anlarının önüne geçer.

Fonksiyonel Olmayan Gereksinimler

Fonksiyonel olmayan gereksinimler, IoT ürününüzün belirli özelliklerinden ziyade niteliklerini, koşullarını ve kısıtlarını belirtir. Ürünün ne kadar iyi performans gösterdiğini, ne kadar dayanıklı olduğunu ve uyması gereken sınırlamaları tanımlarlar. Başka bir deyişle, bir özellik tarif etmeseler bile ürünün genel performansı ve kalitesi için korkulukları ve çıtaları koyarlar. Fonksiyonel olmayan gereksinimler, göz alıcı özellikler kadar kritiktir – cihazınızın gerçek dünyada güvenli, güvenilir ve kullanışlı olmasını sağlarlar.

Bir IoT cihazı için yaygın fonksiyonel olmayan başlıklar şunlardır:

Güç Tüketimi ve Pil Ömrü: Cihaz belirli bir güç kaynağıyla ne kadar süre çalışmalı? Örneğin, “Ürün, tek bir AA pille en az 1 yıl çalışmalıdır.” Bu, tasarımınızın düşük güçlü bileşenlere ve verimli güç yönetimine odaklanmasını sağlar.
Güvenilirlik ve Uzun Ömür: Cihaz zaman içinde ne kadar dayanıklı olmalı? Genellikle Mean Time Between Failures (MTBF) ya da benzeri bir metrikle ifade edilir. Örneğin, “Cihaz, kritik bir arıza yaşamadan en az 5 yıl kesintisiz çalışmalıdır.” Bu, bileşen seçimini ve tasarım paylarını etkileyebilir.
Güvenlik ve Gizlilik: Verileri ve kullanıcı gizliliğini nasıl koruyacaksınız? Örn. “Tüm veri iletimleri AES-256 ile şifrelenmelidir” ya da “Kullanıcı kimlik bilgileri güvenli biçimde saklanmalı ve asla düz metin olarak iletilmemelidir.” Günümüz IoT dünyasında güvenlik gereksinimleri, saldırıların ve veri sızıntılarının önüne geçmek için hayati önemdedir.
Çevresel ve Fiziksel Kısıtlar: Cihazın dayanması gereken koşullar ve karşı karşıya olduğu boyut/ağırlık sınırlamaları. Örneğin, “Cihaz -20°C ile +60°C arasında çalışmalı ve IP67 seviyesinde suya dayanıklı olmalıdır” zorlu ortamlarda hayatta kalmasını güvence altına alırken, “Cihaz 100 gramı geçmemeli ve 10cm x 5cm x 3cm’lik bir hacme sığmalıdır” onu istenen form faktöründe tutar.
Maliyet Kısıtları: Muhtemelen bir hedef maliyetiniz ya da bütçeniz var. Örn. “Birim üretim maliyeti 50 doları aşmamalıdır.” Bu gereksinim tasarımda ödünleşimleri zorlar; buna uymak için daha ucuz bir bileşen seçebilir ya da pahalı bir özellikten vazgeçebilirsiniz.
Regülasyon Uyumu: Birçok IoT ürününün belirli standartları ya da sertifikaları karşılaması gerekir. Örneğin, “Cihaz, kablosuz iletişim için CE ve FCC regülasyonlarına uymalıdır” ya da bir makine sisteminin parçasıysa “ISO 13849 güvenlik standardına uyulmalıdır.” Bunlar, sektör ve güvenlik standartlarının dayattığı, pazarlığı olmayan gereksinimlerdir.

Uzun bir liste, ama fonksiyonel olmayan gereksinimleri ürününüzün taşıması gereken kalite nitelikleri olarak düşünün. Pazarlama broşüründe ilk gösterdiğiniz şey olmayabilirler, ama onları görmezden gelirseniz ürününüz daha az göze çarpan biçimlerde başarısız olabilir. Veriyi kusursuz raporlayan (fonksiyonel!) harika bir sensör hayal edin, ama pili bir günde bitiyor – kullanıcılar hüsrana uğrar. Belki cihazınız laboratuvarda harika çalışıyor, ama güvenlik baştan içine inşa edilmediği için ilk hacker’da devre dışı kalıyor. Bu örnekler, eksik fonksiyonel olmayan gereksinimlerin projenizi nasıl baltalayabileceğini gösteriyor.

Bu nitelikleri baştan tanımlayarak, nihai ürünün yalnızca özellik zengini değil, aynı zamanda sağlam, kullanıcı dostu ve yaşayabilir olmasını güvence altına alırsınız. Fonksiyonel olmayan gereksinimler birçok tasarım kararına yön verir: bileşen seçimlerini, (güvenilirlik ve güvenlik için) yazılım mimarisini, (dayanıklılık ve boyut için) mekanik tasarımı, hatta ürünü nasıl test edeceğinizi bile etkilerler. “Sahne arkasında” kalıyor olabilirler, ama paydaş beklentilerini karşılamak ve gerçek dünya kurulumlarında başarılı olmak için kesinlikle vazgeçilmezdirler.

Arayüz Gereksinimleri

Arayüz gereksinimleri, ürününüzün dış dünyayla — hem fiziksel hem mantıksal olarak — nasıl bağlanıp etkileşeceğini tanımlar. Arayüzleri, cihazınızla diğer her şey arasındaki temas noktaları olarak düşünün: diğer donanımlar, güç kaynakları, muhafazalar, kullanıcılar ve yazılım sistemleri. Bu kategori, IoT cihazınızın hedeflendiği ekosisteme uyum sağlamasını ve orada düzgün iletişim kurmasını güvence altına alır.

Arayüz gereksinimlerinin kapsadığı bazı başlıklar şunlar:

Elektriksel Arayüzler: Her türlü elektriksel bağlantı veya sinyali kapsar. Örneğin, cihazınız belirli bir güç girişine mi ihtiyaç duyuyor (USB-C, pil terminalleri)? Analog bir gerilim mi çıkarıyor (0-5V sinyal gibi), yoksa diğer donanımlara dijital bir arayüz mü (I²C, SPI, UART) sunuyor? Bir gereksinim şöyle olabilir: “Cihaz, güç ve veri bağlantısı için bir USB-C portuna sahip olmalıdır” ya da “Sensör ölçümüyle orantılı 0-5V analog çıkış sağlamalıdır.”
Haberleşme Arayüzleri: Cihazınız cloud’la, bir akıllı telefonla ya da diğer cihazlarla nasıl konuşacak? Bu, ağı ve protokolleri kapsar. Örneğin, “Cihaz, cloud’a Wi-Fi üzerinden bağlanmalı ve sensör verisini yayınlamak için MQTT protokolünü kullanmalıdır” ya da “Bir akıllı telefon uygulamasıyla haberleşmek için Bluetooth Low Energy (BLE) desteklemelidir.” Bir API ihtiyacı varsa onu da belirtirsiniz (örn. “Cloud servisi, cihazın verisini çekmek için bir REST API endpoint’i sağlamalıdır”).
Mekanik Arayüzler: Cihazın fiziksel formu ve oturuşu. Ne kadar büyük olabilir? Nasıl monte edilecek ya da muhafazalanacak? Örneğin, “Cihazın PCB’si, standart bir muhafazaya sığmak için 5cm x 5cm olmalıdır” ya da “GoPro tarzı bir montaj aparatıyla uyumlu montaj deliklerine sahip olmalıdır.” Suya ya da toza dayanıklı olması gerekiyorsa, bu hem çevresel bir gereksinim hem de mekanik arayüz konusudur (örn. “Muhafaza, su ve toz direnci için IP67 sınıfında olmalıdır”). Özünde bu, cihazın gitmesi gereken yere fiziksel olarak entegre olmasını garanti eder.
Kullanıcı Arayüzü (UI) ve Kontroller: IoT ürününüzde kullanıcıların etkileşime girdiği unsurlar (butonlar, ekranlar, LED’ler vb.) varsa, bunlar da arayüz gereksinimi olarak yakalanabilir. Örneğin, “Cihaz, kullanıcının erişebileceği fiziksel bir reset butonu içermelidir” ya da “Veri iletimi sırasında yanıp sönen bir LED göstergesi olmalıdır.” Bunlar, kullanıcıların cihazdan nasıl bilgi alacağını ya da ona nasıl komut gireceğini tanımlar.

Arayüz gereksinimlerini sağlama alarak, projenizin tüm parçalarının birbirine nasıl geçeceğini netleştirirsiniz. Endüstriyel bir makineye takılması gereken bir sensör tasarladığınızı düşünün – mekanik bir arayüz gereksinimi, boyutu ve vida deliği düzenini belirterek sensörün o makineye gerçekten oturmasını sağlar. Ya da diyelim cihazınız pille çalışıyor – elektriksel bir arayüz gereksinimi, kullanıcının onu kolayca şarj edebilmesi için standart bir konektör koymanızı güvence altına alabilir. Bir arayüz gereksinimini atlamak, ileride tuhaf durumlara yol açabilir. (Doğru portu ya da adaptörü olmadığı için kimsenin bağlanamadığı gayet iyi bir cihaz gördünüz mü hiç? Sizin ürününüz o olmasın!)

Özetle, arayüz gereksinimleri IoT cihazınızın ortamıyla ve kullanıcılarıyla iyi geçinmesini sağlar. Cihazınızı daha büyük sisteme bağlarlar – o sistem ister bir akıllı ev, ister endüstriyel bir kurulum, ister sadece elinde telefon olan bir kullanıcı olsun. Bunları gözden kaçırmak, uyumlu ve kullanıcı dostu bir ürünle entegrasyon sırasında baş ağrıtan bir ürün arasındaki fark olabilir.

Paydaşları Erkenden Dahil Etmek

Peki tüm bu gereksinimler aslında nereden geliyor? Havadan düşmüyorlar – onları paydaşlarınızdan topluyorsunuz. Paydaşlar, ürünün başarısında payı olan tüm kişi ya da gruplardır. Son kullanıcılar ya da müşteriler gibi bariz olanların yanı sıra şirketinizin pazarlama ekibi, satış ekibi, farklı disiplinlerden mühendisler (donanım, yazılım, firmware), proje yöneticileri, hatta regülasyon ya da uyumluluk uzmanları da buna dahildir. Bu insanların her birinin kendi ihtiyaçları ve kaygıları vardır ve gereksinimler tüm bu kritik bakış açılarını yakalamalıdır.

Paydaşlarınızı belirleyin ve bu erken aşamada onları aktif biçimde işe dahil edin. Nedeni şu: paydaşlar, ürün için “başarının” neye benzediğini çözmenize yardım eder. Pazarlama ekibi, “50 doların altında olmalı ve tek şarjla bir yıl gitmeli, çünkü müşterilerimizin beklentisi bu” diyebilir. Son kullanıcılar (ya da temsili bir kullanıcı personası) cihazın kurulumunun süper kolay olmasına ve asgari bakım gerektirmesine ihtiyaç duyabilir. Yazılım ekibi, cihazı bir cloud platformuyla entegre etmeyi planladıkları için sağlam bir API ihtiyacının altını çizebilir. Güvenlik uzmanı, şifreleme ve kimlik doğrulama gereksinimlerinde ısrar edecektir. Bir uyumluluk sorumlusu, FCC radyo emisyon standartlarını ya da elektrik güvenliği standartlarını karşılamanız gerektiğini hatırlatabilir. Tüm bu girdiler gereksinimlere dönüşür.

Bu ihtiyaçları şimdi yüzeye çıkarmak, sonradan çıkarmaktan çok daha iyidir. Her paydaş grubuyla beyin fırtınası oturumları, atölyeler ya da basitçe görüşmeler yaparak ürünün ne yapması ve hangi koşulları karşılaması gerektiğinin kapsamlı bir listesini oluşturabilirsiniz. Bunu bir fanusun içinde yapmayın – paydaş girdisi olmadan yazılmış bir gereksinim hedefi ıskalayabilir. Örneğin, müşteri destek ekibine danışmayı unutursanız, “Cihaz, fabrika ayarlarına dönmek için bir reset mekanizması sağlamalıdır” gibi (sorun giderme için önemli) bir gereksinimi gözden kaçırabilirsiniz. Ya da üretim ekibini yok sayarsanız, seri üretimi fazla pahalı ya da zor bir tasarım tarif edebilirsiniz.

Paydaşları erken dahil etmek aynı zamanda sahiplenme yaratır. Herkes kendi kaygılarının gereksinimlerde karşılandığını gördüğünde projeyi destekleme olasılığı artar ve ileride daha az tatsız sürpriz çıkar. Üstelik paydaşların deneyimlerinden gelen içgörüleri vardır – bundan şimdi yararlanmak, sizi yolun devamındaki sancılı değişikliklerden kurtarabilir.

Tüm bu girdileri topladıkça, az önce konuştuğumuz fonksiyonel, fonksiyonel olmayan ve arayüz gereksinimlerinin resmi şekillenmeye başlayacak. Bu aşama özünde havalı bir fikirle net tanımlanmış bir ürün arasındaki köprüyü kurmaktır. Puslu dilekleri (“Ucuz olsun! Güvenli olsun! X’i ve Y’yi yapsın!”) alır, mühendislerin üzerinde çalışabileceği kesin gereksinimlere dönüştürürsünüz. Bunu da doğru insanlarla konuşarak ve doğru soruları sorarak yaparsınız.

Unutmayın, gereksinim toplama bir takım sporudur. Tüm kilit oyuncuları (kelimenin gerçek ya da mecazi anlamıyla) aynı odaya toplayın ve bu cihazın herkesi mutlu etmek için ne yapması gerektiğini enine boyuna tartışın. Şimdi ne kadar çok bakış açısı katarsanız, sonra o kadar az kör noktanız olur.

Gereksinimleri Belgelemek ve Takip Etmek

Tüm bu gereksinimleri paydaşlarınızdan topladıktan sonra, sıradaki adım onları net biçimde yazıya dökmek ve düzenlemektir. Gereksinimleri iyi yapılandırılmış bir formda yakalamak kritiktir, çünkü herkesin aynı sayfada olmasını ve hiçbir şeyin kaybolmamasını sağlar. Pratikte ekipler gereksinimleri belgelemek için farklı yöntemler kullanır:

Resmî Gereksinim Dokümanı: Birçok proje bir System Requirements Specification (SRS) ya da Product Requirements Document (PRD) oluşturur. Bu, her gereksinimin genellikle benzersiz bir tanımlayıcıyla (örn. REQ-001: Cihaz X’i yapmalıdır) listelendiği, yapılandırılmış bir doküman olabilir (bazen gereksinim mühendisliği için IEEE 29148 gibi standartları izler). Resmî dokümanlar titizlik açısından harikadır ve sıkı izlenebilirlik gereken sektörlerde yaygındır (havacılık, otomotiv, tıbbi cihazlar gibi).
Agile Backlog (User Story’ler): Bazı ekipler, özellikle agile ortamlarda, gereksinimleri bir dizi user story, epic ya da Jira veya bir wiki gibi araçlardaki maddeler olarak yakalayabilir. Örneğin: “Bir ev sahibi olarak, evimin sıcaklığı 30°C’nin üzerine çıktığında sensörün beni uyarmasını istiyorum ki klimayı açabileyim.” Bu user story, mühendislik ekibi için spesifik gereksinimlere (aşırı sıcaklık uyarısı için fonksiyonel bir gereksinim gibi) bölünebilir. Agile formatlar daha serbesttir, ama o story’lerin içindeki temel gereksinimleri yine spesifik ve test edilebilir tutmak önemlidir.

Hangi formatı seçerseniz seçin, her gereksinimin belirsizlikten uzak ve test edilebilir olduğundan emin olun. İyi bir pratik, “optimal”, “kullanıcı dostu” ya da “yeterli” gibi belirsiz kelimeleri sayısallaştırmadan kullanmaktan kaçınmaktır. Bunun yerine somut sayılar ya da net kriterler kullanın. Örneğin “pil ömrü uzun olmalı” demek yerine “pil ömrü, saatlik veri yüklemeleriyle tek şarjda en az 12 ay olmalıdır” deyin. Bu, tasarımcılara net bir hedef verir ve tahmin yürütmeye yer bırakmaz.

Bir diğer faydalı alışkanlık: her gereksinimi, ileride onu nasıl doğrulayacağınızla etiketleyin. Bu, ürünün o gereksinimi karşıladığını nasıl kanıtlayacağınızı baştan düşünmek demektir. Yaygın doğrulama yöntemleri şunlardır:

Test: Gereksinimi karşılayıp karşılamadığını görmek için cihazı doğrudan test edersiniz. (Örn. 12 aylık pil ömrünü doğrulamak için cihazın bir pille ne kadar çalıştığını ölçmek.)
Analiz: Hesaplamalar ya da simülasyonlarla doğrularsınız. (Örn. güvenlik gereksinimlerini karşıladıklarından emin olmak için şifreleme algoritmalarını analiz etmek ya da pil ömrünü kestirmek için güç tüketimini hesaplamak.)
Muayene: Bitmiş ürünü gözlemleyerek ya da ölçerek doğrularsınız. (Örn. boyut gereksinimine uyduğundan emin olmak için cihazın ölçülerini kumpasla almak ya da su geçirmezlik için conformal kaplamanın uygulandığını görmek üzere PCB’yi incelemek.)
Sertifikasyon/Gösterim: Bazı gereksinimler sertifika alarak ya da uyumluluğu göstererek doğrulanır. (Örn. FCC/CE regülasyon standartlarını karşıladığını belgelemek için cihazı bir laboratuvara göndermek ya da IP67 su geçirmezlik gereksinimini göstermek için su girişi testi yapmak.)

Doğrulama yöntemini baştan etiketleyerek (bazı ekipler gereksinim dokümanına “Doğrulama Yöntemi” diye bir sütun bile ekler), her gereksinimin sonradan kanıtlanabilecek biçimde ifade edilmesini güvence altına alırsınız. Bu sizi, test aşamasında birinin “Durun, bu belirsiz hedefe ulaştığımızı nasıl kontrol edeceğiz?” diye sorduğu o korkunç senaryodan da kurtarır.

Son olarak, gereksinim dokümanınızı ya da listenizi güncel tutmayı unutmayın. Proje ilerledikçe bazı gereksinimleri rafine edebilir ya da yenilerini ekleyebilirsiniz (gerçi baştan titiz bir iş çıkardıysanız umarız çok fazla değişiklik olmaz!). Düzenli ve sürüm kontrollü bir liste tutmak (basit bir tablo ya da yaşayan bir doküman bile olur), herkesin üzerinde anlaşılmış güncel gereksinimlerin ne olduğunu izlemesine yardımcı olur. Ayrıca yeni ekip üyelerinin, ürünün ne yapması gerektiğini anlamak için gereksinimleri okuyarak hızla adapte olmasını sağlar.

Özetle, gereksinimleri yapışkan notlara karalayıp hayırlısını beklemeyin. Onları net, yapılandırılmış bir biçimde yazıya dökün – ister resmî bir doküman olsun, ister iyi bakılan bir backlog. Şimdiki netlik, sonraki kafa karışıklığını önler. Ve her gereksinimi nasıl doğrulayacağınızı planlayarak, yolun devamındaki test ve validasyon aşamasının daha pürüzsüz geçmesinin zeminini döşersiniz.

Aşama 1’i Toparlarken

Geliştirmenin bir sonraki aşamasına yelken açmadan önce, bu gereksinim aşamasının neden bu kadar kritik olduğunu bir kez daha vurgulayalım. Bir gereksinim hakkında sonradan fikir değiştirmek, ev inşa edildikten sonra fazladan bir yatak odası eklemeye karar vermek gibidir – mümkündür, ama sancılı ve pahalı olacaktır. IoT ürünleri dünyasında “sancılı ve pahalı”, bir sensörü unuttuğunuz için devre kartının komple yeniden tasarlanması ya da belirli bir kullanım senaryosunu baştan hesaba katmadığınız için büyük bir firmware revizyonu anlamına gelebilir. Proje gecikmeleri, bütçe aşımları ya da en kötü ihtimalle kullanıcılarını ve paydaşlarını tatmin edemeyen bir ürün demek olabilir.

Net paydaş ve sistem gereksinimlerini yakalamak için şimdi emek yatırarak, özünde projeniz için bir plan ve yol haritası inşa ediyorsunuz. Bu gereksinimler, işin içindeki herkes için referans noktası haline gelir:

Donanım mühendisleri, bu spesifikasyonları karşılayan bileşenleri seçmek ve devreleri tasarlamak için onları kullanır.
Yazılım ve firmware geliştiricileri, belirtilen işlevleri ve performansı gerçekleştirmek için kod yazar.
Test uzmanları, test planlarını doğrudan gereksinimlerden oluşturur (her gereksinim doğrulanabilir olması gerektiğinden, doğal olarak bir ya da daha fazla test senaryosuna dönüşür).
Proje yöneticileri, karşılanan gereksinimleri işaretleyerek ilerlemeyi takip eder ve kritik hiçbir şeyin düşmediğinden emin olur.
Paydaşlar, ürünün ne yapacağına (ve ne yapmayacağına) dair şeffaf bir görüşe sahip olur; belirsizlik azalır.

İleride anlaşmazlıklar ya da yeni fikirler ortaya çıktığında, gereksinim dokümanı ekibi hizada tutan Kutup Yıldızınızdır. Biri geliştirmenin ortasında kapsamı şişirecek bir özellik önerdiğinde, dönüp şunu sorabilirsiniz: “Bu, üzerinde anlaştığımız gereksinimlere göre kapsamda mı? Değilse, eklemek için neyden vazgeçiyoruz?” Bu, kapsamı ve beklentileri yönetmeye yardımcı olur.

O yüzden Aşama 1’i doğru yapmak için zaman ayırın. Paydaşları dahil edin, tüm işlevleri ve kısıtları enine boyuna düşünün, her şeyi net biçimde yazıya dökün ve hepsinin mantıklı olduğunu bir kez daha kontrol edin. Bir konsept ya da spesifikasyon üzerinde iterasyon yapmak, fiziksel bir cihaz ya da kod tabanı üzerinde yapmaktan çok daha ucuz ve kolaydır. Bu aşamayı iyi yaparsanız, sonraki tüm aşamalarda başarı için zemini hazırlamış olursunuz.

Elinizde sağlam bir paydaş ve sistem gereksinimleri setiyle ilerlemeye hazırsınız. Önünüzde işin eğlenceli kısmı var – tüm o iyi tanımlanmış gereksinimleri karşılayan bir şeyi tasarlayıp inşa etmek! Ama bunu yaparken bu hazine haritasını (gereksinimlerinizi) yanınızda taşıyacak, her zaman rotada kaldığınızdan emin olacaksınız. Önce işin temeli – ve artık onu doğru yaptınız.