"Sistem Kullanıcı Dostu Olacaktır" Bir Gereksinim Değildir

Bir projenin başarısız olma sebebini geriye doğru takip ettiğinizde, izin çoğu zaman kodda ya da tasarımda bitmediğini görürsünüz. Şartnamede biter.

Ve şartnamedeki cümle genellikle şu türdendir:

"Sistem kullanıcı dostu olacaktır." "Yazılım yüksek performanslı çalışacaktır." "Ürün zorlu çevre koşullarına dayanıklı olacaktır."

Bu cümleler kötü yazılmış gereksinimler değil. Gereksinim değiller. Çünkü hiçbirinin doğrulanma yolu yok ve doğrulanamayan bir ifade, bir temenni.

Doğrulanabilir gereksinimin dört şartı

Uluslararası sistem mühendisliği pratiğinde (INCOSE rehberleri ve türevleri) bir gereksinimin taşıması gereken nitelikler uzun bir listedir. Sahada işe yarayan çekirdek dört tanesi:

1. Tekil. Bir gereksinim bir şey söyler. İçinde "ve" varsa muhtemelen iki gereksinimdir ve biri geçip diğeri kalabilir. Bu durumda o maddeye "geçti" mi dersiniz, "kaldı" mı?

2. Belirsizliksiz. Tek bir okuma biçimi olmalı. Tedarikçinin okuduğu ile müşterinin okuduğu aynı cümle olmalı; bu, sözleşmeli işlerde teorik bir kaygı değildir.

3. Doğrulanabilir. Nasıl kanıtlanacağı belli olmalı: muayene, analiz, gösterim veya test. Bunu yazarken sorulacak soru şudur: "Bu maddenin sağlandığını hangi kanıtla iddia edeceğim?" Cevap yoksa gereksinim de yoktur.

4. Çözümden bağımsız. Gereksinim ne istendiğini söyler, nasıl yapılacağını değil. "Sistemde X marka sensör kullanılacaktır" bir gereksinim değil, bir tasarım kararıdır. Ve şartnameye yazıldığı anda tasarımcının elini bağlar, üstelik sorumluluğu da müşteriye geçirir.

En sık yapılan sekiz hata

Ölçüsüz sıfat. "Hızlı", "güvenilir", "kolay", "yeterli", "uygun", "makul", "optimum". Hepsi ölçüsüz. Sayı yoksa gereksinim yok.

"Gerektiğinde" / "mümkün olduğunca". Bu ifadeler doğrulama sorumluluğunu belirsizleştirir. Kim gerektiğine karar veriyor?

Pasif cümle. "Veriler kaydedilecektir." Kim kaydedecek? Sistem mi, operatör mü, yer istasyonu mu? Fail belirsizse sorumluluk da belirsizdir.

Gereksinim içinde tasarım. "Sistem, PID kontrolcü kullanarak konumunu koruyacaktır." Kontrolcü tipini müşteri neden belirlesin? Doğrusu: "Sistem, 5 m/s rüzgâr altında konumunu ±1 m içinde koruyacaktır."

İki gereksinimin birleşmesi. "Sistem verileri kaydedecek ve yer istasyonuna aktaracaktır." Kayıt çalışıyor, aktarım çalışmıyorsa madde geçti mi?

Doğrulama yöntemi yazılmamış. Her gereksinimin yanında nasıl doğrulanacağı durmalı. Bunu sonradan eklemek, gereksinimlerin bir kısmının hiç doğrulanamayacağını geç fark etmek demektir.

Koşul belirtilmemiş. "Menzil 10 km olacaktır." Hangi irtifada? Hangi anten konfigürasyonunda? Hangi rüzgârda? Koşulsuz sayı, tartışma çıkaran sayıdır.

Tolerans yok. "Ağırlık 2 kg olacaktır." Tam olarak mı? 2,05 kg kabul mü? Toleransı yazmayan şartname, kabul aşamasında pazarlığa dönüşür.

İşe yarayan yazım kalıbı

Basit ve savunması kolay bir kalıp:

[Koşul altında], [özne] [ne yapacak/hangi özelliği sağlayacak], [ölçülebilir kriter ve tolerans ile].

Örnekler:

Kötü: "Sistem uzun süre çalışacaktır." İyi: "Sistem, 25 °C ortam sıcaklığında ve nominal görev profilinde, tam şarjlı bataryayla en az 35 dakika kesintisiz çalışacaktır. Doğrulama: test."

Kötü: "Arayüz kullanıcı dostu olacaktır." İyi: "Eğitim almış bir operatör, sistemi açtıktan sonra en fazla 90 saniye içinde görev başlatabilecektir. Doğrulama: gösterim, en az 5 farklı operatörle."

İkinci örnek önemli: "kullanıcı dostu" gibi doğası gereği öznel görünen bir istek bile, gözlemlenebilir bir davranışa çevrildiğinde doğrulanabilir hale gelir. Genellikle çevrilemeyen gereksinim değil, çevirmeye üşenilen gereksinim vardır.

Ar-Ge projelerinin özel sorunu

Burada dürüst olmak gerekir: bir Ar-Ge projesinde bütün gereksinimleri başta net yazamazsınız. Yazabiliyorsanız yaptığınız şey zaten Ar-Ge değildir.

Bu gerçek bir gerilim ve çözümü "o zaman gereksinim yazmayalım" değil. İşe yarayan yaklaşım:

Gereksinimi olgunluk seviyesiyle işaretleyin. Her maddenin yanında bir durum bulunsun: kesin / hedef / araştırılıyor. Böylece hangi maddenin üzerine tasarım kurulabileceği, hangisinin henüz kurulamayacağı görünür olur.

"Araştırılıyor" maddelerine karar tarihi koyun. Bir gereksinimin belirsiz kalması sorun değil; ne zaman netleşeceğinin belirsiz kalması sorundur. Karar tarihi olmayan açık madde, projenin sonunda patlar.

Eşik ve hedef değer kullanın. Savunma programlarında yaygın ve çok işe yarayan bir pratik: her performans gereksinimi için kabul edilebilir asgari (eşik) ve arzu edilen (hedef) değer tanımlanır. Böylece ekip neyi feda edebileceğini bilir. Tek değer yazılan şartnamede her madde eşit derecede kutsaldır (ki bu, hiçbirinin kutsal olmaması demektir).

İzlenebilirlik: gereksinimin unutulan yarısı

Gereksinim yazmak işin yarısı. Diğer yarısı, her gereksinimin nereye bağlandığını bilmek.

Sağlıklı bir izlenebilirlik zincirinde her gereksinim yukarı (hangi üst seviye ihtiyaçtan türedi) ve aşağı (hangi tasarım öğesi karşılıyor, hangi test doğruluyor) bağlanır.

Bunun pratik faydası şu: bir gereksinim değiştiğinde neyin etkileneceğini dakikalar içinde görürsünüz. İzlenebilirliği olmayan projede aynı soru bir haftalık toplantı turu gerektirir ve cevabı yine de eksik kalır.

Ayrıca yukarı bağlanamayan gereksinimler ortaya çıkar, yani kimsenin istemediği ama şartnamede duran maddeler. Bunlar her projede vardır ve maliyetleri gerçektir.

Program yöneticisi için pratik sonuç

Gereksinim dokümanı, teknik ekibin işi gibi görünür ama sonuçları tamamen yönetseldir:

• Kabul kriteri gereksinimden türer. Gereksinim belirsizse projenin ne zaman biteceği de belirsizdir. Bitmeyen projelerin çoğu, bitmediği için değil, bittiğini kanıtlayamadığı için bitmez.
• Kapsam kayması gereksinimden sızar. "Bu zaten kullanıcı dostu olmanın parçası" cümlesiyle eklenen her iş, ölçüsüz bir maddenin açtığı kapıdan girer.
• Gereksinim gözden geçirmesi, projenin en ucuz kalite faaliyetidir. Bir günlük ortak okuma toplantısında bulunan belirsizlik, altı ay sonra bir tasarım turuna mal olur.

Bir cümlelik özet:

Doğrulama yöntemini yazamıyorsanız, o bir gereksinim değildir.

---

Bu yazıdaki görüşler şahsıma aittir, çalıştığım kurumları bağlamaz.