Gereksinimden teste, iz kopmadan
Moors, MyWay’in gereksinim yönetimi panosu. Spesifikasyonu doküman gibi yazarsın, her gereksinimi onu karşılayan geliştirme işine ve doğrulayan teste bağlarsın; eksik olan, değişen ve onaylanan tek ekranda görünür. Ayrı bir araç, ayrı bir lisans, ayrı bir sunucu yok: Kanban, Scrum ve doküman alanıyla aynı kurulumda çalışır.
- Yerinde düzenlenen spesifikasyon
- Bölüm numaraları
- Pano başına seviye
- 4 izlenebilirlik bağı
- Kapsama ve matris
- Şüpheli bağ
- Taslak ve yayın sürümlü temel sürüm
- Excel, PDF, Word, Markdown çıktısı
- Formal gözden geçirme ve onay
- Kendi sunucunda
İz genelde üç araç arasında kopar
Spesifikasyon Word’de
Gereksinim dokümanı ayrı bir dosyada yaşar. Geliştirme başlayınca hangi işin hangi gereksinimi karşıladığı dosyada değil insanların aklında kalır.
İş bir araçta, test ötekinde
Görevler takip aracında, test sonuçları başka yerde. İzlenebilirlik matrisi her denetimden önce elle, tablo tablo yeniden kurulur.
Değişiklik sessizce geçer
Bir gereksinim değiştiğinde ona bağlı tasarımın ve testin yeniden bakılması gerektiğini kimse hatırlatmaz; fark, ancak test başarısız olunca anlaşılır.
Moors bu üç parçayı aynı kuruluma koyar: gereksinim, iş ve test aynı veritabanında durur, bağlar panolar arasında kurulur ve her değişiklik bağın iki ucunda görünür.
Beş adımda izlenebilir bir spesifikasyon
Ekranlardaki örnek, canlı demodaki fren kontrolcüsü kurgusunun genişletilmiş hâlidir: paydaş ihtiyaçları, sistem gereksinimleri, yazılım ve doğrulama için dört pano.
- Adım 1
Seviyeyi seç, spesifikasyonu yaz
Yeni Moors panosunu açarken seviyesini seçersin: paydaş ihtiyaçları, sistem, alt sistem, yazılım, donanım, arayüz, doğrulama / test tanımları ya da diğer. Bir pano tek bir spesifikasyondur. Dokümanı doğrudan Spesifikasyon sekmesinde yazarsın: her öğenin menüsünden üstüne, altına ya da içine Başlık, Gereksinim veya Bilgi eklenir, öğeler yukarı aşağı taşınır ve girintilenir. Başlıklar bölüm numarası alır (1, 2.1), gereksinimler başlığın ardından sıralanır (2.1-1); gereksinim eklemek alt başlıkların numarasını kaydırmaz. Numara her değişiklikte yeniden hesaplanır, her gereksinimin kalıcı kodu (REQ-12) hiç değişmez.
- Taslak, İncelemede, Onaylandı, Uygulandı, Doğrulandı ve Reddedildi statüleri hazır gelir
- Spesifikasyonda öğe ekle, taşı, girintile; gezinme bölmesinde başlık ağacı ve arama sonuçları, bölümleri daralt, eski bir temel sürümü salt okunur aç
- Onaylanan gereksinim düzenlemeye kilitlenir
- Listede Bölüm sütunu: sıralanır, "2" yazınca bölüm 2 ve altı süzülür
- Excel (.xlsx), CSV ya da Markdown (.md) dosyalarından içe aktarma; "Şablonu indir" panonun güncel alanlarıyla hazır bir Excel üretir
Yeni pano penceresi: Moors kartı ve Seviye seçimi. 
Spesifikasyonda öğe menüsü: üstüne, altına ya da içine Başlık, Gereksinim veya Bilgi ekle; taşı ve girintile. 
Liste: Bölüm sütunu en başta, başlıkların altında gereksinim ağacı. - Adım 2
Seviyeleri ve işi birbirine bağla
Sistem gereksinimi, paydaş ihtiyaçları panosundaki ihtiyaca "şundan türetilmiş" bağıyla bağlanır; geliştirme işi onu "karşılar", test görevi "doğrular". Dört izlenebilirlik bağı (türetir, karşılar, doğrular, detaylandırır) iki yönüyle seçilir ve panolar arasında kurulur. Geliştirme ve test işleri kendi Kanban ya da Scrum panolarında kalır; ekip alışkanlığını değiştirmez. Bağ haritası bir gereksinimden çıkan bütün izi tek resimde gösterir.
- Bağ eklerken pencere seçilen yönü cümleyle anlatır
- Görev oluştururken bağlantılı öğe eklenebilir
- Toplu işlem çubuğunda "Bağ ekle"
- Dashboard’da Bağ haritası ve İzlenebilirlik kapsaması widget’ları
Bağ haritası: ihtiyaçtan sistem gereksinimine, oradan yazılım işine ve teste. - Adım 3
Boşlukları gör
Kapsama, kaynağı olan, uygulanan ve doğrulanan gereksinim oranını verir ve eksik olanı tek tıkla süzer: kaynaksız, uygulanmamış, doğrulanmamış, şüpheli bağlı. Paydaş ihtiyaçları panosunda kaynak aranmaz, en üst seviye odur; doğrulama panosunda ise her test senaryosunun bir gereksinimi doğrulayıp doğrulamadığına bakılır, adımlar sayılmaz. Matris, satırda gereksinimleri, sütunda seçtiğin panonun öğelerini, hücrede bağ türünü gösterir; hiçbir gereksinime bağlı olmayan testler "Bağsız öğeler"de kalır.
- Üst çubuktaki arama ve süzgeçler Kapsama ve Matris’te de çalışır
- Kapsama sütunları sıralanır, süzülür, genişletilir
- Listede Bağlar kolonu: bağlar panoya göre gruplu, şüpheli bağ işaretli
- Başlık ve Bilgi gereksinim sayılmaz, oranı bozmaz
- Aramada bağ koşulları: hiç testi olmayan gereksinimleri kayıtlı filtre yap
Kapsama: oranlar, boşluk süzgeçleri ve şüpheli bağ sütunu. 
Matris: gereksinimler ve doğrulama panosunun testleri. - Adım 4
Değişikliği yakala
Bir gereksinimin başlığı, açıklaması ya da nitelikleri değişince ona dokunan izlenebilirlik bağları "şüpheli" işaretlenir. Bağın iki ucunda rozet çıkar, ipucu hangi alanın değiştiğini söyler. Tasarımı ya da testi yeniden gözden geçiren kişi bağı "İncelendi" ile kapatır ve bu görev geçmişine yazılır. Hangi alanların izleneceğini pano ayarı belirler.
- Şüpheli bağ Kapsama’da ayrı sütun ve süzgeç
- Başlık ve Bilgi değişikliği bağ işaretlemez
- Aramada "Şüpheli bağ" koşulu
- İnceleme kimin ne zaman yaptığıyla geçmişte
Temel sürümden sonra değişen arayüz gereksinimi: bağları şüpheli. - Adım 5
Dondur, gözden geçir, yayınla
Temel sürüm, panodaki bütün öğelerin ve bağların o anki hâlini değiştirilemez olarak saklar ve bir sürüm kodu alır. Pano 0.0 taslakla başlar; her yeni temel sürüm bir taslaktır (0.1, 0.2), Yayınla gözden geçirilen taslağı aynı içerikle ana sürüm yapar (1.0, sonra 2.0). Gözden geçirme ve onay yalnız en son taslağa açılır; taslak dokümanlardaki gibi çok turlu formal gözden geçirmeye gider, görüş bütün sürüme ya da tek bir gereksinime yazılır. Yayından önce neyin şart olduğunu ve gözden geçirme ile onayın sırasını pano ayarı belirler. Bugünkü hâlle ya da başka bir temel sürümle karşılaştırma eklenen, çıkarılan ve değişen gereksinimi alan alan gösterir.
- Yayınlanan sürüm, onun taslağı ve onaylanan ya da gözden geçirmesi olan taslak silinemez
- İçerik ve karşılaştırma Excel, CSV ya da Markdown olarak iner
- Spesifikasyon bugünkü hâliyle ya da bir temel sürümden kapak, sürüm geçmişi ve içindekilerle Excel, PDF, Word ya da Markdown olarak iner; bölüm numarası, madde türü, anahtar, bağlantı ve iki yana yaslı metin seçilir
- Kurumsal şablonda PDF ve Word çıktısı doküman sayfalarıyla aynı düzende basılır; temel sürüm doküman kodu ve gizlilik derecesi taşır
- Temel sürümler yayına göre gruplanır; yayınlanmamış taslağın adı ve açıklaması düzenlenir
- Gözden geçirmede ağırlık (Kritik, Majör, Minör, Editoryal) ve karar
- Oluşturma, yayınlama ve silme denetim kaydına düşer
Taslak 1.1 gözden geçirmede: görüşler tek tek gereksinime bağlı. 
Yayındaki 1.0 bugünkü hâlle karşılaştırılıyor: eklenen ve değişen gereksinimler.
Panoyu açınca gelenler
Adlar panoyu açanın dilinde gelir ve hepsi değiştirilebilir. Var olan Moors panoları kuruldukları tiplerle çalışmaya devam eder.
- Seviye
- Paydaş ihtiyaçları, Sistem gereksinimleri, Alt sistem gereksinimleri, Yazılım gereksinimleri, Donanım gereksinimleri, Arayüz gereksinimleri, Doğrulama / test tanımları, Diğer
- Numaralama
- Başlıklar 1, 1.2; gereksinimler başlığın ardından 1.2-1 (ayardan tek ortak seriye geçilir; temel sürüm kayıt anındaki numarayı korur)
- Tipler
- Gereksinim, Başlık, Bilgi; doğrulama panosunda Test Senaryosu, Test Adımı, Başlık, Bilgi
- Statüler
- Taslak, İncelemede, Onaylandı (düzenlemeye kilitli), Uygulandı, Doğrulandı, Reddedildi
- Nitelikler
- Kaynak, Doğrulama Yöntemi (Test, Analiz, İnceleme, Gösterim), Gerekçe, Kabul Kriteri, Gereksinim Sınıfı, Kritiklik (Yüksek, Orta, Düşük)
- Gereksinim Sınıfı
- Fonksiyonel, Performans, Arayüz, Emniyet, Siber Güvenlik, Tasarım Kısıtı, Çevresel, Kullanılabilirlik, Mevzuat
- İzlenebilirlik bağları
- Türetir, karşılar, doğrular, detaylandırır; her biri iki yönüyle
- Görünümler
- Liste, Kanban, Spesifikasyon; "Daha fazla" menüsünde Kapsama, Temel Sürüm, Matris, Sürümler
- Kapalı gelenler
- Öncelik ve Story Point (Moors’ta öncelik yerine Kritiklik); istenirse açılır
Ayrı bir araç olmamanın getirdikleri
Kendi sunucunda
Gereksinimler, testler ve onaylar kendi sunucundaki veritabanında durur. Bulut hesabı gerekmez; verinin nereye gideceğine sen karar verirsin.
Denetim kaydı
Temel sürüm oluşturma, yayınlama ve silme denetim kaydına; onay kararları ve şüpheli bağ incelemeleri kendi geçmişlerine kimin ne zaman yaptığıyla yazılır.
Pano rolleri ve yetkiler
Temel sürümü kimin alıp yayınlayacağı, kimin gözden geçirme başlatıp onay isteyeceği, kimin şüpheli bağı kapatacağı rol yetkileriyle belirlenir.
GitLab
Gereksinimi karşılayan geliştirme işinin commit’leri, dalları ve merge request’leri görev ekranında görünür; tireli kısa kodlar (SYS-REQ-12) da tanınır.
Doküman alanı
Prosedürler, planlar ve test raporları aynı kurulumdaki doküman alanında; sayfa bir gereksinime bağlanabilir.
Dashboard
İzlenebilirlik kapsaması ve Bağ haritası widget’ları, statü dağılımı ve aktiviteyle aynı panelde.
Açık konuşalım
Moors’un dili ISO/IEC/IEEE 29148 ve sistem mühendisliği pratiğinden gelir: spesifikasyon seviyeleri, gereksinim sınıfları, doğrulama yöntemleri, temel sürüm. Ama Moors süreci destekleyen bir araçtır; tek başına bir standarda uygunluk sağlamaz ve uygunluk belgesi üretmez. Uygunluk kuruluşun sürecine ve denetimine aittir. ReqIF alışverişi yoktur; gereksinimler Excel ya da CSV ile aktarılır.
Moors hakkında
Moors ayrı mı ücretlendiriliyor?
Hayır. Moors MyWay’in bir pano tipidir ve her kurulumda vardır; ayrı modül ya da ek lisans gerekmez.
Geliştirme ekibim de Moors kullanmak zorunda mı?
Hayır. Geliştirme ve test işleri kendi Kanban ya da Scrum panolarında kalır; bağ, iki pano arasında kurulur. Bağı kurmak için iki panoda da üyelik gerekir.
Var olan gereksinimlerimi nasıl getiririm?
Excel (.xlsx), CSV ya da her biri bir madde olacak Markdown (.md) dosyalarından içe aktarırsın; "Şablonu indir" panonun alanlarıyla hazır bir Excel verir; liste aynı biçimlerde, PDF ve Markdown olarak dışa aktarılır. Spesifikasyon, bugünkü hâliyle ya da seçilen bir temel sürümle Excel, PDF, Word ya da Markdown olarak iner; PDF ve Word belgesi kapak sayfasıyla (sürüm ve sürüm adı, durum, tarih), sürüm geçmişi tablosuyla ve içindekilerle açılır; neyin gireceğini dışa aktarma seçenekleri belirler. Temel sürüm içeriği ve karşılaştırması Excel, CSV ya da Markdown olarak iner. ReqIF desteklenmez.
Var olan bir panoyu Moors’a çevirebilir miyim?
Evet, Pano Ayarları > Genel’den. Gereksinim, Başlık ve Bilgi tipleri, gereksinim nitelikleri ve seviye kendiliğinden eklenir; var olan statüler ve iş akışı korunur, hazır Moors statüleri kurulmaz. Sıfırdan başlıyorsan yeni pano açmak daha temizdir.
Bir pano kaç gereksinim taşır?
Panoda bir sınır yok. Spesifikasyon görünümü ilk 5000 öğeyi gösterir, temel sürüm en çok 5000 öğeli bir panoda oluşturulabilir; liste, kapsama ve matris sayfalı çalışır.
Moors ISO/IEC/IEEE 29148 uyumlu mu?
Moors gereksinim sürecini destekler; tek başına bir standarda uygunluk sağlamaz ve uygunluk belgesi üretmez. Uygunluk kuruluşun sürecine ve denetimine aittir.
Moors’u kendi sunucunda dene
MyWay’i kur, ilk Moors panonu aç. Kılavuz her ekranı, senaryo da paydaş ihtiyacından teste kadar bütün akışı adım adım anlatır.
Canlı demoda hazır bir Moors kurgusu var
Fren kontrolcüsü örneği: paydaş ihtiyaçları, sistem gereksinimleri, yazılım ve doğrulama panoları, onaylanmış bir taslak temel sürüm, şüpheli bağlar ve bir izlenebilirlik dashboard’u. Demo içeriği İngilizcedir ve her gece sıfırlanır.
Canlı demoda gez