Öğrenme yolu 04Ders 2 / 10

Yazılım değişirken gereksinimleri izlenebilir tutun

Kullanıcı sonucunu kararlara, kabul ölçütlerine, uygulamaya ve kanıta bağlayın. Varsayımlar değiştiğinde bağlantıları güncelleyin.

Uygulayıcı10 minİncelendi

Yayımlayan Nasıl yazıyoruz?

Neler öğreneceksiniz?

  • Sınırları açık, gözlenebilir bir gereksinim yazın.
  • Bir gereksinimi değişiklik ve kontrolleri boyunca izleyin.
  • Değişen bir varsayımdan etkilenen sonraki belgeleri belirleyin.

Birinin doğrulayabileceği davranışı tanımlayın

“Modern bir müşteri dışa aktarma özelliği oluşturun” ifadesi önemli kararları açık bırakır. Kullanıcıları, kayıtları, alanları veya hata davranışını tanımlamaz. Ajan ya sormak ya da varsayım yapmak zorunda kalır. Kaydedilmeyen varsayımları sonradan incelemek zordur.

Sınırı açık bir kurgusal gereksinim kullanın: kimliği doğrulanmış bir yönetici, kendi kuruluşundaki etkin müşterileri dışa aktarabilir. Dışa aktarılan veriler müşteri kimliğini ve görünen adını içerir. İletişim bilgilerini ve arşivlenmiş kayıtları içermez. Yönetici rolü olmayan kullanıcıya dışa aktarma sonucu verilmez.

Biçim, hacim, yanıt süresi ve hata işleme hakkında hâlâ kararlar gerekir. Bilinmeyenleri açıkça işaretleyin. Yararlı bir gereksinim tanımı, belirsizliği kendinden emin ifadelerle gizlemek yerine görünür kılar.

Gereksinimleri uygulama tercihlerinden ayırın

Kullanıcının, izin verilen bir kayıt kümesini kullanılabilir bir biçimde alması gerekir. Veri tabanı sorgusu, kütüphane ve endpoint yapısı uygulama tercihleridir. Her mevcut tercihi kalıcı bir iş ihtiyacı saymadan, bunları gereksinime bağlayın.

Önemli sonuçları olan bir kararı bağlamı, alternatifleri ve gerekçesiyle kaydedin. Örneğin, eşzamanlı dışa aktarma küçük hacimler için uygun olabilir. Daha büyük hacim, arka plan işi ve ayrı bir indirme yetkilendirme kontrolü gerektirebilir.

Değişen kararı sürümlerken gereksinimi mümkün olduğunca sabit tutun. Böylece inceleyiciler farklı bir uygulama yöntemini, kullanıcılara verilen farklı bir sözden ayırt edebilir.

Kısa bir kanıt zinciri oluşturun

İncelemelerde anlaşılır kalan tanımlayıcılar kullanın. Bu örnekte EXPORT-01, kuruluş sınırını tanımlayabilir. Bu ad örnek amaçlıdır; zorunlu bir numaralandırma sistemi değildir.

BağlantıÖrnek
GereksinimEXPORT-01: yalnızca yöneticinin kuruluşundaki kayıtlar
Tasarım kararıÜyelik kontrolünü tarayıcıda değil, sunucuda uygulayın
UygulamaPR, sorguyu ve yetkilendirme yolunu değiştirir
DoğrulamaBaşka bir kuruluşun kayıtlarına yönelik istek reddedilir
Yayın kanıtıKontrol sonucu kabul edilen commit’i ve artefaktı tanımlar

Zincir gerçek kanıta işaret etmelidir. Test adının gereksinim kimliğini içermesi, doğrulama ifadesinin o gereksinimi kontrol ettiğini kanıtlamaz. Testi ve çalıştırdığı üretim yolunu inceleyin.

NIST SSDF, güvenli geliştirme içindeki gereksinimler ve doğrulama için bağlam sağlar. Sırf belge üretmek yerine, bu faaliyetleri incelenebilir kılmak için izlenebilirliği kullanın. Çerçeveyi okuyun.

Değişen bir varsayımın etkisini inceleyin

İş biriminin artık arşivlenmiş müşterilere ihtiyaç duyduğunu varsayın. Bu değişiklik, sorgudaki bir bayraktan fazlasını etkiler. Saklama kurallarını, yetkilendirmeyi, beklenen hacmi, kullanıcı açıklamalarını ve mevcut raporların anlamını kontrol edin.

Etkilenen belgeleri ve kontrolleri inceleme için işaretleyin. İşletim sorumlusunun eski bir yayını açıklayabilmesi için önceki kararı koruyun. Son tasarımı kaçınılmaz göstermek için geçmişi sessizce yeniden yazmayın.

Ajan, referansları bulmaya ve güncellemeler önermeye yardımcı olabilir. Sorumlular, çelişen gereksinimleri çözmeli ve değişen davranışı kabul etmelidir. Eşleşen dosyaların listesi bir başlangıç noktasıdır; eksiksiz bir etki değerlendirmesi değildir.

Kaydı kullanılabilecek kadar küçük tutun

Uygulamayı, doğrulamayı ve işletimi etkileyen kararları kaydedin. Aynı gereksinimi birbiriyle bağlantısız birçok belgede tekrarlamayın. Bakımı yapılan tek bir kaynağa bağlantı vermeyi tercih edin.

Bir değişikliği kabul etmeden önce, inceleyicinin değişikliğin amacından gerçek kanıta kadar ilerleyip ilerleyemediğini sorun. İşletime geçmeden önce, hizmet sorumlusunun ilgili sınırı ve kurtarma kararını bulup bulamadığını sorun. Bunlar yararlı izlenebilirliğin pratik testleridir.

Alıştırmayı yapın

Bir yöneticinin etkin müşterileri dışa aktarması için gereksinim yazın. İzin verilen kullanıcıları, kuruluş sınırını, alanları, hata davranışını ve ölçülebilir tamamlanma koşulunu ekleyin. Bunu kurgusal bir teste ve yayına bağlayın. Ardından gereksinime arşivlenmiş müşterileri ekleyin ve etkilenen kararları listeleyin.

Çalışma sayfasını indir (Markdown)

Anladığınızı kontrol edin

Mimari ve testler hazırlandıktan sonra gereksinim tanımı değişiyor. Ne yapılmalıdır?

Kaynaklar ve ek okumalar

Taiga'dan ilgili okumalar