Non-functional Requirement'lar: ISO/IEC 25010:2023 Quality Model'i, Ölçülebilir Hale Getirmek ve Nereye Yazılır?

Sürüm notu: Bu yazı kavramsaldır; quality model için ISO (Uluslararası Standardizasyon Örgütü) ve IEC'nin (Uluslararası Elektroteknik Komisyonu) Kasım 2023'te yayımlanan ortak standardı ISO/IEC 25010:2023, erişilebilirlik için W3C'nin (web standartlarını yayımlayan kuruluş) WCAG'inin (Web Content Accessibility Guidelines; web içeriğinin erişilebilirlik kuralları) 2.2 sürümü, kişisel veri için 6698 sayılı KVKK (Kişisel Verilerin Korunması Kanunu) esas alınmıştır.

Önce Tahmin Et

Example Mapping oturumlarından Selin'in defterine hiçbir karta sığmayan dört cümle kaldı. Gül: "1.000 satırlık liste yapıştırıldığında beklemeden kontrol edilsin." Hakan: "Eylülde sistem çökmesin, o iki hafta bizim yılımız." Nevin Hanım: "Bizim siparişimizi başka okul görmesin." İlçe kütüphanesinin müdürü: "Belediye, dijital hizmetlerinin ekran okuyucuyla kullanılabilmesini istiyor."

Üç soru. Bu cümlelerden hangisi tek bir story'nin acceptance criteria'sına yazılabilir? Hangisi her story için geçerli olmalı? Hangisi, yazıldığı anda ekibin bir mimari kararı yeniden düşünmesini gerektirir? Bir de dördüncü soru: "beklemeden" kaç saniye?

Non-functional Requirement Nedir?

İlk yazıdaki seviyeler tablosunda non-functional requirement'ı, davranışın hangi kalitede olacağını söyleyen requirement diye tanımlamıştık. Functional requirement sistemin ne yaptığını söyler: "Sistem, katalogda bulunamayan her ISBN'i (kitabın uluslararası standart numarası) satır numarasıyla bildirir." Non-functional requirement aynı davranışın nasıl yapılacağını söyler: ne kadar hızlı, kime açık, hangi koşulda ayakta, kimin erişebileceği biçimde.

Adı biraz yanıltıcı. "Non-functional" sanki sistemin işlevine dokunmuyormuş izlenimi verir, oysa 1.000 satırlık listeyi bir dakikada kontrol eden bir ekran, eylülde fiilen işlevsizdir. Bu yüzden literatürde "quality requirement" ya da "quality attribute requirement" adları da kullanılır. Hangi adı kullandığın, onları functional requirement'lar kadar somut yazıp yazmadığın kadar önemli değil.

Constraint'le farkını da ilk yazıda konuşmuştuk: quality requirement bir aralıkta pazarlık edilebilir, constraint ise ekibin seçmediği bir sınırdır. "Faturalar mevcut ERP (Enterprise Resource Planning; şirketin muhasebe, stok ve fatura işlerini yürüten kurumsal yazılım) sistemine aktarılır" bir constraint; "aktarım her gece 06:00'ya kadar tamamlanır" ise bir quality requirement. İkincisi için Bookstore muhasebesiyle konuşup 07:00'yi kabul ettirmek mümkün; birincisi için değil.

ISO/IEC 25010:2023: Dokuz Karakteristik

ISO/IEC 25010, yazılım ürünlerinin kalitesini karakteristiklere ve onların alt karakteristiklerine ayıran bir quality model tanımlar. Modelin amaçlarından biri tam da requirement yazmak: kalite beklentilerini adlandırmak ve hiçbirini unutmamak için ortak bir dil. 2011 baskısında sekiz karakteristik vardı; Kasım 2023'te yayımlanan revizyon bunu dokuza çıkardı. Değişikliklerin özeti şöyle: safety yeni bir karakteristik olarak eklendi; usability'nin adı interaction capability, portability'nin adı flexibility oldu. Alt karakteristiklerde de hareket var: security'ye resistance, flexibility'ye scalability eklendi; interaction capability altında eski accessibility, inclusivity ve user assistance olarak ikiye ayrıldı, self-descriptiveness eklendi; reliability'deki maturity'nin yerini faultlessness aldı.

Standardın tanımlarını burada aktarmıyoruz; standart ücretli ve metni telifli. Daha kullanışlı olanı, dokuz karakteristiği kendi özelliğine sorulacak sorulara çevirmek:

Son satır bir kitapçı için neredeyse boş kalıyor ve bu normal. Modeli bir form gibi her hücresi doldurulacak bir şey olarak değil, kontrol listesi olarak kullan: her karakteristiğe bak, ilgisiz olanı bilerek ve gerekçesiyle geç. "Safety bu özellik için konu dışı, çünkü sistem fiziksel bir süreci yönetmiyor" cümlesi, o satırı hiç düşünmemiş olmaktan daha değerli bir requirement kaydıdır.

"Hızlı Olsun"dan Ölçülebilir Senaryoya

Gül'ün "beklemeden" kelimesi ilk yazıdaki belirsiz kelime avının tipik avı. Onu ölçülebilir yapmanın yerleşik yolu quality attribute senaryosudur: uyarının kaynağı, uyarının kendisi, ortam, etkilenen parça, sistemin cevabı ve o cevabın ölçüsü. Altı parçanın her birini, ortalamanın neden yanılttığını ve percentile'ın neden daha iyi bir ölçü olduğunu Mimariye Giriş serisinin "Quality Attribute Senaryoları" yazısında ayrıntılı anlatmıştık. Burada aynı aracı requirement tarafından kullanıyoruz ve asıl soruya odaklanıyoruz: sayılar nereden geliyor?

Ortamı veriden kuruyoruz. 02. yazıdaki doküman analizi geçen eylül 46 kurumsal sipariş geldiğini, en büyük listenin 870 satır olduğunu gösterdi. Siparişlerin neredeyse tamamı eylülün ilk iki haftasına sıkışmış; en yoğun günde 9 sipariş. Yani sorun aynı anda binlerce kullanıcı değil, tek bir isteğin büyüklüğü. Bu bilgi, "10.000 eşzamanlı kullanıcıyı kaldırmalı" gibi başka bir projeden kopyalanmış bir cümlenin buraya ait olmadığını söylüyor.

Cevap ölçüsünü ise ölçümden kuruyoruz. Walking skeleton birinci sprint'in sonunda çalışınca Ayşe, 870 satırlık gerçek listeyi test ortamında yüz kez doğrulatıyor: p95 (isteklerin yüzde 95'inin altında kaldığı süre) 2,1 saniye. Ekip yüzde elli büyüme payı ve marj bırakarak 1.000 satır için 5 saniyeyi öneriyor; Nevin Hanım'a prototipte bu süre soruluyor ve "listeyi yapıştırıp kahvemi alırım" cevabı geliyor. Senaryo şöyle yazılıyor: "Eylülün ilk iki haftasında, aynı saat içinde on kurum sipariş verirken (ortam), bir satın alma sorumlusu (kaynak) 1.000 satırlık bir liste yapıştırıp kontrol ettiğinde (uyarı), doğrulama endpoint'i (parça) her satırın sonucunu döner (cevap); bu istek p95'te 5 saniyeyi, hiçbir koşulda 30 saniyelik timeout'u aşmaz (ölçü)."

Bu cümlenin değeri, her sayısının bir kaynağı olması. 1.000 satır doküman analizinden, 5 saniye ölçümden ve kullanıcıyla yapılan konuşmadan, on kurum geçen eylülün en yoğun gününden geliyor. Sayılardan biri değişirse, örneğin bir kütüphane zinciri 3.000 satırlık liste göndermeye başlarsa, hangisinin neden değiştiği bellidir.

Kurumsal Siparişin Diğer Kalite Requirement'ları

Hakan'ın "çökmesin"i reliability'ye düşüyor ve onun da bir sayıya ihtiyacı var. Bookstore'un cevabı: "1–15 Eylül arasında, iş günlerinde 08:00–20:00 arası kurumsal sipariş akışı en az yüzde 99,5 erişilebilir olur." Bu yaklaşık on bir iş gününde toplam 40 dakikalık bir kesintiye izin veriyor. Yılın geri kalanı için hedef daha gevşek; requirement'ı ortamla birlikte yazmak, ekibi bütün yıl boyunca eylül standardına zorlamaktan kurtarır. Yanına bir recoverability cümlesi ekleniyor: oturum düşerse yapıştırılan liste, taslak olarak en fazla bir dakikalık kayıpla geri gelir.

Nevin Hanım'ın cümlesi security'ye düşüyor ve iki ayrı requirement çıkarıyor. Biri confidentiality: "Bir kurumun kullanıcısı yalnızca kendi kurumunun siparişlerini görür; başka bir kurumun sipariş numarasıyla yapılan istek, siparişin varlığını da ele vermeyecek şekilde bulunamadı cevabı alır." Bu, Web Güvenliği (OWASP Top 10) serisinde OWASP'ın (web uygulaması güvenliği üzerine açık çalışmalar yürüten vakıf) A01 Broken Access Control yazısında anlattığımız IDOR (başka bir kaydın yalnız id'si değiştirilerek okunabilmesi) açığının requirement tarafındaki karşılığı. Diğeri accountability: "Bir kurumsal siparişin her durum değişikliği, değiştiren kullanıcı, zaman ve önceki ile yeni durum bilgisiyle kaydedilir; uygulama kullanıcıları bu kayıtları değiştiremez." Kaydın kaç yıl tutulacağını ekip uydurmaz; Bookstore muhasebesi ve hukuk belirler ve sayı requirement'a yazılır.

Elicitation'dan gelen bir ayrıntı burada KVKK'yı devreye sokuyor. Okulların listelerinde bazen öğretmen adları ve şube bilgileri geçiyor. Kanunun 4. maddesindeki ilkelerden biri, kişisel verinin işlendiği amaçla bağlantılı, sınırlı ve ölçülü olmasıdır; bir diğeri, amaç için gereken süreden uzun saklanmamasıdır. Sipariş için ISBN, adet ve teslimat noktası yeter. Requirement buna göre yazılıyor: "Sistem yapıştırılan listeden yalnız ISBN ve adet sütunlarını saklar; diğer sütunlar doğrulamadan sonra atılır." Satın alma sorumlusunun iletişim bilgisi ise kişisel veri ve saklama süresini yine hukuk belirler. Bunun hukuki değerlendirmesini ekip yapmaz; requirement'ı yazar ve şirketin veri koruma sorumlusuna onaylatır.

Kütüphane müdürünün cümlesi interaction capability'nin inclusivity alt karakteristiğine düşüyor. "Erişilebilir olsun" yine ölçüsüz; WCAG 2.2 ise ölçülebilir başarı kriterleri sunar. Ekip doğrulama sonuç ekranı için hedefi AA (WCAG'in üç uygunluk seviyesinin ortadakisi) seviyesi olarak koyuyor ve bu ekran için en kritik dört kriteri adıyla yazıyor: hatalı satırlar yalnızca kırmızı renkle değil metinle de işaretlenir (1.4.1 Use of Color); her hata, satır numarası ve sebebiyle metin olarak tanımlanır (3.3.1 Error Identification); bütün akış yalnız klavyeyle tamamlanabilir (2.1.1 Keyboard); "3 satırda hata var" gibi sonuç bildirimi, odak değişmeden ekran okuyucuya duyurulur (4.1.3 Status Messages). Kriterlerin ayrıntısı ve Türkiye'deki yükümlülükler Accessibility (a11y) serisinin konusu.

Nereye Yazılır?

Quality requirement'lar, yazıldıkları yere göre ya yaşar ya da bir wiki sayfasında unutulur. Bookstore ekibi dört yer kullanıyor ve her requirement için üç soru soruyor: yalnızca bir story'ye mi ait, her story'ye mi? Sistemin yapısını değiştiriyor mu? Otomatik olarak kontrol edilebilir mi?

İlk iki satır 05. yazıdaki ayrımın devamı: bir madde her story'de tekrar ediyorsa Definition of Done'a taşınır. Üçüncü satırda requirement artık bir seçenekler arası karşılaştırmanın girdisidir; Architecture Decision'lar serisinin "Trade-off Analizi" yazısında quality attribute senaryolarının seçenekleri tartmak için nasıl kullanıldığını, "ADR Yazmak" yazısında kararın nasıl kaydedildiğini görmüştük. Dördüncü satır, aynı serinin "ADR'dan Otomatik Kontrole" yazısındaki fikrin requirement tarafı: bir kalite beklentisi CI'da kırmızıya dönebiliyorsa, kimsenin onu hatırlamasına gerek kalmaz.

Bir requirement birden fazla yerde yaşayabilir. 5 saniye kuralı hem story'nin acceptance criteria'sında hem de bir fitness function olarak duruyor; ilki "bu story bitti mi?" sorusuna, ikincisi "altı ay sonra hâlâ doğru mu?" sorusuna cevap veriyor.

Ölçmeden Yazılan Sayı

Ölçülebilir bir requirement'ın ölçülmesi de gerekir ve bu üç ayrı anda olur. Önce yazmadan önce: bugünkü durumu, yani bir baseline'ı ölç. Ayşe'nin 2,1 saniyelik ölçümü olmasaydı, 5 saniye ya imkânsız ya da anlamsız derecede gevşek bir hedef olabilirdi. Sonra teslimden önce: aynı senaryoyu, aynı veriyle, production'a benzer bir ortamda tekrar et. Yük altında ölçmenin, workload modeling'in ve k6 ile CI'a bağlanan testlerin ayrıntısı Performance ve Load Testing serisinin konusu. En son production'da: p95'i telemetri ile izle ve eylül geldiğinde gerçek sayıya bak. Requirement'taki sayı bir tahmindi; production'daki ölçüm onun doğrulamasıdır.

Ölçemediğin bir requirement'ı da kabul etmemek gerekmez; ama onu öyle işaretle. "Yöneticiler raporu kolayca okuyabilmeli" bugün ölçülemiyorsa, yanına bir doğrulama yöntemi yaz: "iki muhasebe çalışanıyla on dakikalık kullanılabilirlik testi, yardım almadan tamamlanır". Ölçü bir sayı olmak zorunda değil; tekrarlanabilir bir kontrol olmak zorunda.

Üretimde Dikkat

Quality requirement'ı ortamıyla birlikte yaz. "Yüzde 99,5 erişilebilir" cümlesi hangi dönem, hangi saatler ve hangi akış için olduğunu söylemiyorsa, ekip ya yanlış yere yatırım yapar ya da kesintiyi tartışırken herkes başka bir şey anlar.

Her quality requirement'ın bir sahibi olsun. 5 saniyenin sahibi Product Owner, erişilebilirlik süresinin sahibi kurumsal satış, saklama süresinin sahibi hukuk. Bir sayı değişecekse kimin onayıyla değişeceği bellidir.

Sayıları zaman zaman yeniden aç. Eylülden sonra gerçek p95 1,2 saniye çıktıysa ve kimse şikâyet etmediyse, 5 saniye ekibe yanlış bir rahatlık veriyor olabilir; 30 saniyelik timeout'a takılan tek bir istek varsa, o isteğin listesi büyük ihtimalle bir sonraki yılın ortamıdır.

Yasal requirement'ları ekip içinde yorumlama. KVKK, erişilebilirlik mevzuatı ya da muhasebe kayıtlarının saklama süresi gibi konularda requirement'ı ekip yazar ama içeriğini hukuk ya da uyum sorumlusu onaylar; onay, requirement'ın yanına tarihiyle not edilir.

Sık Düşülen Tuzaklar

İlk tuzak quality requirement'ları projenin sonuna bırakmak. Erişilebilirlik ve kurum izolasyonu, ekranlar ve endpoint'ler bittikten sonra eklenmeye çalışıldığında her ekran ve her endpoint yeniden açılır. Walking skeleton'ın ilk sürümünde bile bir kurum izolasyonu testi ve bir klavye kontrolü olmalı.

İkinci tuzak ölçüsüz maddeler: "Sistem güvenli olmalı", "sistem ölçeklenebilir olmalı". Bu cümleler bir backlog'da yıllarca durur, hiçbir zaman bitmez ve hiçbir kararı etkilemez. Her birini en az bir senaryoya ya da kontrol edilebilir bir cümleye çevir; çeviremiyorsan henüz bir requirement yok, bir endişe var.

Üçüncüsü başka bir projeden sayı kopyalamak. "Yüzde 99,99 erişilebilirlik" ya da "200 ms yanıt süresi" bir e-ticaret vitrininde anlamlı olabilir; yılda 46 sipariş alan bir kurumsal akış için bu sayılar ekibin aylarını yanlış probleme harcatır.

Dördüncüsü quality requirement'ı "As a system" diye başlayan bir story'ye çevirmek. 03. yazıdaki "As a developer" tuzağının ikizi: "Sistem olarak hızlı olmak istiyorum" kimseye değer vermez ve hiçbir zaman bitmez. Requirement ait olduğu story'nin acceptance criteria'sına, Definition of Done'a ya da bir fitness function'a gider.

Beşincisi ISO/IEC 25010'u doldurulacak bir form gibi kullanmak. Dokuz karakteristiğin altındaki bütün alt karakteristiklere birer cümle yazan bir doküman, kimsenin okumadığı kırk satır üretir. Model bir kontrol listesidir; asıl iş, önemli olan üç dört karakteristik için iyi senaryolar yazmaktır.

Küçük Bir Deneme

★☆☆ Ekibinin backlog'unda ya da wiki'sinde "hızlı", "güvenli", "ölçeklenebilir", "kullanıcı dostu" kelimelerini ara. Bulduğun her cümleyi ISO/IEC 25010:2023'ün dokuz karakteristiğinden birine etiketle ve hangilerinin hiç temsil edilmediğine bak.

★★☆ Üzerinde çalıştığın bir özellik için bir quality attribute senaryosu yaz. Her sayının yanına kaynağını not et: ölçüm, doküman analizi, kullanıcıyla konuşma ya da tahmin. Kaynağı "tahmin" olan sayıları ölçmek için bir plan çıkar.

★★★ Mevcut bir quality requirement'ı bu yazıdaki tablodaki dört yerden en uygun olanına taşı. Fitness function'a uygunsa CI'da çalışan küçük bir kontrol yaz; Definition of Done'a uygunsa ekiple konuşup ekle; ADR gerektiriyorsa kararın seçeneklerini listele.

Elimizde artık kurallarıyla, örnekleriyle ve kalite beklentileriyle bir spesifikasyon var. Ama hepsi hâlâ insan dilinde, kartlarda ve story açıklamalarında duruyor; kod değiştiğinde kimse onları kendiliğinden kontrol etmiyor. Bir sonraki yazıda Example Mapping'in çıktısını Gherkin'e çeviriyoruz: Given-When-Then, Rule, Scenario Outline ile hem stakeholder'ın okuyabileceği hem de bilgisayarın çalıştırabileceği, executable bir spesifikasyon yazacağız.