Aşama 1: Paydaş ve Sistem Gereksinimleri

15 Ağustos 2025

İllüstrasyon: üç paydaşın sesi tek bir gereksinim listesinde birleşiyor

Önce işin temeli!

Gereksinimler, iyi yönetilen her IoT projesinde en önce gelir — şematiklerden, firmware’den, ilk kod satırından önce. Ürün fikrinizin tutulmaya değer olduğuna karar verdiniz ve şimdi doğrudan inşaya atlama dürtüsü hissediyor olabilirsiniz. O dürtüye direnin. Aşama 1, gereksinimleri toplamakla ilgili; ardından gelen her şeyin temeli budur. Yeni bir devreye enerji vermek ya da kod yazmak kadar heyecanlı gelmeyebilir; ama bunu, yelken açmadan önce haritayı çizmek gibi düşünün. Haritasız seferler elbette maceralıdır — ama nadiren iyi biterler.

Aşama 1: Paydaş ve Sistem Gereksinimleri’nde tüm kilit oyunculardan girdi toplar, neyi neden geliştirdiğimizi tam olarak tanımlarız: ürünün ne yapması gerektiği, hangi koşulları karşılaması gerektiği ve hangi kısıtlara uyması gerektiği. Buraya yatırılan zaman, ileride fazlasıyla geri döner. Yolun devamındaki her tasarım kararı, her kod satırı ve her test, bu gereksinimlere kadar izlenecek — onlar projenin Kutup Yıldızı’dır. Onlar olmadan ileriye koşarsanız yanlış şeyi geliştirme ya da aylarca çalıştıktan sonra kritik bir özelliğin gözden kaçtığını, bir varsayımın yanlış olduğunu fark etme riskini alırsınız.

Bu bölümde, paydaş ve sistem gereksinimlerini yakalamanın ne anlama geldiğini açıyoruz: bu aşamanın neden önemli olduğunu, hangi gereksinim türlerini düşünmeniz gerektiğini ve bunları nasıl net biçimde belgeleyeceğinizi. Gereksinimleri erkenden sağlama almanın bir IoT projesini nasıl var edip yıkabileceğini gösteren örnekler de paylaşacağız.

Gereksinim Tam Olarak Nedir?

“Gereksinim” derken neyi kastediyoruz? Yalın ifadeyle, ü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ı — projenin kural kitabı; cihazdan beklenen her şeyi, onu daha geliştirmeden kayda geçirir. Ürününüz bir hikâye olsaydı, gereksinimler onun olay örgüsü taslağı olurdu: tüm kilit unsurların tanımlı olmasını sağlar ki hikâye sonunda bir bütün olarak ayakta dursun.

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

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.

Her kategoriyi ayrıntısıyla ele alacağız. Şimdilik şunu aklınızda tutun: iyi bir gereksinim net, spesifik ve test edilebilirdir. “Cihaz harika olmalı” mühendislik ekibinize bir şey söylemez. “Cihaz, sıcaklığı 0°C ile 50°C arasında ±0,5°C doğrulukla ölçmelidir” söyler: okuyan herkes tam olarak ne beklendiğini bilir ve ileride cihazın bunu karşılayıp karşılamadığını test edebilirsiniz. Hedeflenecek netlik seviyesi budur.

Fonksiyonel Gereksinimler

Fonksiyonel gereksinimler, IoT ürününüzün belirli özelliklerini, işlevlerini ve davranışlarını tanımlar — sistemin ne yapması gerektiğini. Biri “Cihazınız ne yapıyor?” diye sorduğunda, cevap fonksiyonel gereksinimlerin bir özetidir: cihazın kullanıcıya ya da diğer sistemlere sunduğu aksiyonlar ve hizmetler.

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 takip eder)
Veri doğruluğu ve aralığı: Ölçümler ne kadar doğru ve hangi aralıkta? (ö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 — dakikada bir mi, saatte bir mi güncelliyor? Ne kadar hızlı yanıt vermeli? (örn. 10 dakikada bir ölçüm ya da 2 saniye içinde yanıt)
Veri işleme: Veriye ne oluyor — cloud’a mı gönderiliyor, hafıza kartına mı kaydediliyor, bir ekranda mı gösteriliyor?
Belirli modlar veya özellikler: Örneğin bir eşik aşıldığında devreye giren bir alarm modu, kendi kendine kalibrasyon ya da havadan (OTA) firmware güncellemeleri.

Somut bir örnek verelim. Akıllı ev kullanımı için basit bir IoT sıcaklık sensörü geliştirdiğinizi 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ımlar ve genellikle “Cihaz … -malıdır” kalıbıyla, ardından spesifik bir davranışla ifade edilir. Bu format, ileride doğrulamayı kolaylaştırır: cihaz ya belirtildiği gibi X’i yapıyordur ya da yapmıyordur.

İyi fonksiyonel gereksinimler yeteneklerin net bir resmini çizer; mühendislik ekibi tam olarak neyi gerçekleştireceğini bilir. Ancak ondan sonra donanım ve yazılım tasarımcıları buna nasıl ulaşacaklarını düşünebilir — önce ne gelir; bu gereksinimlerin şimdi tanımlanmasının nedeni de budur. Onlar olmadan, kullanıcının gerçekten ihtiyaç duyduğu şeyi ıskalayan bir ürünle kalabilirsiniz: özenle geliştirilmiş bir IoT hava istasyonu, kimse yazmadığı için nem sensörü olmadan sevk edilir. Fonksiyonel gereksinimleri baştan tanımlamak, olmazsa olmaz özellikleri bu olmadan önce yakalar.

Fonksiyonel Olmayan Gereksinimler

Fonksiyonel olmayan gereksinimler, ürünün özelliklerinden çok niteliklerini, koşullarını ve kısıtlarını belirtir: ne kadar iyi performans gösterdiği, ne kadar dayanıklı olduğu ve hangi sınırlara uyması gerektiği. Genel kalite için korkulukları koyarlar ve özelliklerin kendisi kadar kritiktirler — cihazı gerçek dünyada güvenli, güvenilir ve kullanışlı tutarlar.

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

Güç Tüketimi ve Pil Ömrü: Cihaz belirli bir güç kaynağıyla ne kadar çalışmalı? Örneğin, “Ürün, tek bir AA pille en az 1 yıl çalışmalıdır.” Bu, düşük güçlü bileşenlere ve verimli güç yönetimine odaklanmayı zorlar.
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 — “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ı etkiler.
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ün IoT ortamında güvenlik gereksinimleri, ihlalleri önlemek için zorunludur.
Çevresel ve Fiziksel Kısıtlar: Cihazın dayanması gereken koşullar, artı boyut ve ağırlık sınırları. “Cihaz -20°C ile +60°C arasında çalışmalı ve IP67 seviyesinde suya dayanıklı olmalıdır” zorlu ortamlarda hayatta kalmasını sağlar; “Cihaz 100 gramı geçmemeli ve 10cm x 5cm x 3cm’lik bir hacme sığmalıdır” onu gereken form faktöründe tutar.
Maliyet Kısıtları: Muhtemelen bir hedef maliyetiniz var — “Birim üretim maliyeti 50 doları aşmamalıdır.” Bu, ödünleşimleri yönetir: burada daha ucuz bir bileşen, orada vazgeçilen bir özellik.
Regülasyon Uyumu: Birçok IoT ürününün standartları ya da sertifikaları karşılaması gerekir — “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 belirlediği, pazarlığı olmayan gereksinimlerdir.

Uzun bir liste; ama fonksiyonel olmayan gereksinimleri ürünün taşıması gereken kalite nitelikleri olarak düşünün. Pazarlama broşürüne nadiren girerler, ama onları görmezden gelmek ürünü daha az göze çarpan biçimlerde başarısızlığa uğratır. Bir sensör veriyi kusursuz raporlayabilir (fonksiyonel!) ve yine de pili bir günde bittiği için her kullanıcıyı hüsrana uğratabilir. Bir cihaz laboratuvarda iyi çalışabilir ve güvenlik baştan içine inşa edilmediği için ilk saldırıda devrilebilir.

Bu nitelikleri baştan tanımlamak, nihai ürünün yalnızca özellik zengini değil, sağlam, kullanışlı ve yaşayabilir olmasını sağlar. Fonksiyonel olmayan gereksinimler bileşen seçimlerine, yazılım mimarisine (güvenilirlik, güvenlik), mekanik tasarıma (dayanıklılık, boyut) ve hatta nasıl test edeceğinize yön verir. Sahne arkasında çalışırlar, ama paydaş beklentilerini karşılamak ve gerçek dünya kurulumlarından sağ çıkmak için zorunludurlar.

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üzler, cihazınızla diğer her şey arasındaki temas noktalarıdır: diğer donanımlar, güç kaynakları, muhafazalar, kullanıcılar ve yazılım sistemleri. Bu kategori, cihazın hedeflenen ekosistemine oturmasını ve orada düzgün iletişim kurmasını sağlar.

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

Elektriksel Arayüzler: Her türlü elektriksel bağlantı veya sinyal. Cihaz belirli bir güç girişine mi ihtiyaç duyuyor (USB-C, pil terminalleri)? Analog bir gerilim mi çıkarıyor (0-5V sinyal), 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 cloud’la, bir akıllı telefonla ya da diğer cihazlarla nasıl konuşuyor — ağ ve protokoller. Ö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 gerekiyorsa onu da belirtin: “Cloud servisi, cihazın verisini almak için bir REST API endpoint’i sağlamalıdır.”
Mekanik Arayüzler: Fiziksel form ve oturuş. Cihaz ne kadar büyük olabilir, nasıl monte edilecek ya da muhafazalanacak? “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.” Su ve toz geçirmezlik hem çevresel bir gereksinim hem de mekanik arayüz konusudur: “Muhafaza, su ve toz direnci için IP67 sınıfında olmalıdır.” Önemli olan, cihazın gitmesi gereken yere fiziksel olarak entegre olmasıdır.
Kullanıcı Arayüzü (UI) ve Kontroller: Kullanıcının etkileşime girdiği unsurlar — butonlar, ekranlar, LED’ler. “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 göndereceğini tanımlar.

Arayüz gereksinimlerini sağlama almak, tüm parçaların birbirine nasıl takılacağını netleştirir. Endüstriyel bir makineye takılan bir sensör tasarlıyorsanız, mekanik bir arayüz gereksinimi boyutu ve vida deliği düzenini belirtir ki sensör gerçekten otursun. Cihaz pille çalışıyorsa, elektriksel bir arayüz gereksinimi standart bir konektör sağlar ki kullanıcı onu kolayca şarj edebilsin. Birini atlarsanız klasik sonuçla karşılaşırsınız: doğru portu olmadığı için kimsenin bağlanamadığı, başka her yönüyle iyi bir cihaz.

Özetle, arayüz gereksinimleri cihazınızın ortamıyla ve kullanıcılarıyla çalışmasını sağlar — o ortam ister bir akıllı ev, ister endüstriyel bir kurulum, ister elinde telefon olan biri olsun. Bunları gözden kaçırmak, çoğu zaman uyumlu ve kullanıcı dostu bir ürünle entegrasyonda baş ağrıtan bir ürün arasındaki farktır.

Paydaşları Erkenden Dahil Etmek

Peki tüm bu gereksinimler nereden geliyor? Havadan değil — onları paydaşlarınızdan topluyorsunuz: ürünün başarısında payı olan herkes. Bariz adaylar olan son kullanıcılar ve müşterilerin yanı sıra pazarlama, satış, farklı disiplinlerden mühendisler (donanım, yazılım, firmware), proje yöneticileri ve regülasyon ya da uyumluluk uzmanları da buna dahil. Her grubun kendi ihtiyaçları ve kaygıları var ve gereksinimler her kritik bakış açısını yakalamalı.

Paydaşlarınızı belirleyin ve erken dahil edin, çünkü “başarının” neye benzediğini onlar tanımlar. Pazarlama, “50 doların altında olmalı ve tek şarjla bir yıl gitmeli — müşterilerimizin beklentisi bu” diyebilir. Son kullanıcılar (ya da temsili bir persona) kurulumun basit olmasına ve bakımın asgaride kalmasına ihtiyaç duyabilir. Yazılım ekibi bir cloud platformuyla entegrasyon için sağlam bir API’ye ihtiyaç duyabilir. Güvenlik uzmanı şifreleme ve kimlik doğrulamada ısrar edecektir. Bir uyumluluk sorumlusu FCC radyo emisyon limitlerini ya da elektrik güvenliği standartlarını hatırlatacaktır. Tüm bu girdiler gereksinim olur.

Bu ihtiyaçları şimdi yüzeye çıkarmak, sonradan çıkarmaktan çok daha ucuzdur. Her paydaş grubuyla beyin fırtınası oturumları, atölyeler ya da basit görüşmeler kapsamlı bir liste oluşturur. Bunu bir fanusun içinde yapmayın: paydaş girdisi olmadan yazılan bir gereksinim hedefi ıskalayabilir. Müşteri destek ekibini atlarsanı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. Üretimi atlarsanız, seri üretimi fazla pahalı ya da zor bir tasarım tarif edebilirsiniz.

Erken katılım aynı zamanda sahiplenme yaratır. İnsanlar kaygılarının gereksinimlerde karşılandığını gördüğünde projeyi destekler ve ileride daha az sürpriz çıkar. Paydaşlar deneyim getirir — onu şimdi kullanmak, yolun devamındaki sancılı değişikliklerden kurtarır.

Bu girdiler biriktikçe, gerekli fonksiyonel, fonksiyonel olmayan ve arayüz gereksinimlerinin resmi şekillenir. Bu aşama özünde boşluğu köprülemektir: umut vadeden bir fikirle net tanımlanmış bir ürün arasında. Puslu dilekler (“Ucuz olsun! Güvenli olsun! X’i ve Y’yi yapsın!”), doğru insanlarla konuşup doğru soruları sorarak mühendislerin üzerinde çalışabileceği kesin gereksinimlere dönüşür.

Gereksinim toplama bir takım sporudur. Kilit oyuncuları — gerçek ya da mecazi anlamda — aynı odaya alın ve cihazın ne yapması gerektiğini enine boyuna tartışın. Şimdi ne kadar çok bakış açısı katarsanız, sonraki aşamalara o kadar az kör nokta taşırsınız.

Gereksinimleri Belgelemek ve Takip Etmek

Toplandıktan sonra gereksinimlerin net biçimde yazılması ve düzenlenmesi gerekir. İyi yapılandırılmış bir kayıt herkesi aynı sayfada tutar ve hiçbir şeyin kaybolmamasını sağlar. Pratikte ekipler 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 — her gereksinimin, çoğu zaman benzersiz bir tanımlayıcıyla (örn. REQ-001: Cihaz X’i yapmalıdır) listelendiği yapılandırılmış bir doküman (bazen IEEE 29148 gibi standartları izler). Resmî dokümanlar, sıkı izlenebilirlik gereken sektörlere uygundur: havacılık, otomotiv, tıbbi cihazlar.
Agile Backlog (User Story’ler): Bazı ekipler, özellikle agile olanlar, gereksinimleri user story’ler, epic’ler ya da Jira veya bir wiki gibi bir araçtaki maddeler olarak yakalar. Ö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.” Böyle bir story, mühendislik ekibi için spesifik gereksinimlere bölünür (örneğin aşırı sıcaklık uyarısı için fonksiyonel bir gereksinim). Agile formatlar daha serbesttir, ama altlarındaki gereksinimlerin yine spesifik ve test edilebilir olması gerekir.

Hangi formatı seçerseniz seçin, her gereksinimi belirsizlikten uzak ve test edilebilir tutun. “Optimal”, “kullanıcı dostu” ya da “yeterli” gibi belirsiz kelimeleri sayısallaştırmadan kullanmaktan kaçının; somut sayılar ya da net kriterler kullanın. “Pil ömrü uzun olmalı” yerine “pil ömrü, saatlik veri yüklemeleriyle tek şarjda en az 12 ay olmalıdır” yazın. Bu, tasarımcıların çalışabileceği, tahmine yer bırakmayan bir hedeftir.

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

Test: Cihazı gereksinime karşı doğrudan test edin. (Ö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ülasyonlar kullanın. (Örn. şifreleme algoritmalarını güvenlik gereksinimlerine karşı 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ğrulayın. (Örn. cihazın ölçülerini boyut gereksinimine karşı kumpasla almak ya da su geçirmezlik için PCB’de conformal kaplama uygulandığını incelemek.)
Sertifikasyon/Gösterim: Sertifikasyon ya da kanıtlanmış uyumluluk yoluyla doğrulayın. (Örn. FCC/CE regülasyon standartlarını karşıladığını belgelemek için cihazı bir laboratuvara göndermek ya da IP67 gereksinimini göstermek için su girişi testi yapmak.)

Doğrulama yöntemini baştan etiketlemek — bazı ekipler gereksinim dokümanına bir “Doğrulama Yöntemi” sütunu ekler — her gereksinimi sonradan kanıtlanabilecek biçimde ifade etmeye zorlar. Ayrıca sizi, test aşamasında birinin “Durun, bu belirsiz hedefe ulaşıp ulaşmadığımızı nasıl kontrol edeceğiz?” diye sorduğu andan kurtarır.

Son olarak, gereksinim dokümanını güncel tutun. Proje ilerledikçe gereksinimleri rafine edebilir ya da ekleyebilirsiniz (başlangıç işi titizse, ideali bunların az olmasıdır). Düzenli, sürüm kontrollü bir liste — basit bir tablo ya da yaşayan bir doküman bile — herkesi güncel, üzerinde anlaşılmış gereksinimlerde hizalar ve yeni ekip üyelerinin ürünün ne yapması gerektiğini öğrenerek hızlanmasını sağlar.

Kısacası: gereksinimleri yapışkan notlara karalayıp en iyisini ummayın. Net, yapılandırılmış bir biçimde yazın — resmî bir doküman ya da iyi bakılan bir backlog. Şimdiki netlik sonraki kafa karışıklığını önler ve doğrulamayı erken planlamak, daha pürüzsüz bir test aşamasının yolunu döşer.

Aşama 1’i Toparlarken

Devam etmeden önce bir kez daha: bir gereksinimi geç değiştirmek, ev inşa edildikten sonra fazladan bir yatak odası eklemeye karar vermek gibidir — mümkün, ama sancılı ve pahalı. IoT’de “sancılı ve pahalı”, unutulan bir sensör yüzünden komple bir PCB yeniden tasarımı ya da hesaba katılmamış bir kullanım senaryosu yüzünden büyük bir firmware revizyonu anlamına gelebilir. Gecikmeler, bütçe aşımları ya da en kötü ihtimalle kullanıcılarını ve paydaşlarını yüz üstü bırakan bir ürün anlamına gelebilir.

Net paydaş ve sistem gereksinimlerini yakalamak için şimdi emek yatırmak, projeye planını ve yol haritasını verir. Gereksinimler, işin içindeki herkes için referans noktası olur:

Donanım mühendisleri, 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 — doğrulanabilir her gereksinim, 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üş elde eder.

İleride anlaşmazlıklar ya da yeni fikirler çıktığında, gereksinim dokümanı ekibi hizada tutan Kutup Yıldızı’dır. Biri geliştirmenin ortasında kapsam şişiren bir özellik önerirse sorabilirsiniz: “Bu, üzerinde anlaştığımız gereksinimlere göre kapsamda mı? Değilse, eklemek için neyden vazgeçiyoruz?”

O yüzden Aşama 1’i doğru yapmak için zaman ayırın. Paydaşları dahil edin, işlevleri ve kısıtları enine boyuna düşünün, her şeyi net biçimde yazın ve bir bütün olarak ayakta durduğunu bir kez daha kontrol edin. Bir spesifikasyon üzerinde iterasyon yapmak, fiziksel bir cihaz ya da kod tabanı üzerinde yapmaktan çok daha ucuzdur. Bu aşamayı iyi yapın; ardından gelen her aşamayı da kurmuş olursunuz.

Elinizde sağlam bir paydaş ve sistem gereksinimleri setiyle, onları karşılayan bir şey tasarlayıp geliştirmeye geçmeye hazırsınız. Ve bunu yaparken haritayı yanınızda taşıyorsunuz — önce işin temeli, üstelik doğru yapılmış.