Gereksinim analizi ve Software Discovery
Yazılım geliştirilmeden önce hedefleri, süreçleri, gereksinimleri ve riskleri netleştiriyoruz. Ortaya kapsam, mimari, efor ve uygulama için sağlam bir temel çıkar — ya da geliştirmemek yönünde gerekçeli bir öneri.
Kısaca Gereksinim analizi ve Software Discovery.
Kararınız için en önemli noktalar: ne zaman uygun olduğu, nasıl ilerlediğimiz ve nelere dikkat ettiğimiz.
- Discovery doğru seçimdir, eğer
- bir proje iş açısından henüz netleşmemişse, birden fazla birimi ilgilendiriyorsa veya mevcut sistemlere bağlanacaksa.
- Daha kısa bir netleştirme yeterlidir, eğer
- hedef, kullanıcılar ve kapsam zaten belliyse ve projenin diğer sistemlere neredeyse hiç bağımlılığı yoksa.
- Tipik çıkış noktası
- eforu güvenilir biçimde öngörülemeyen bir fikir ya da bugün tablolar, e-postalar ve tek tek kişilerin bilgisiyle yürüyen bir süreç.
- Neleri netleştiriyoruz
- Hedefler, kullanıcı rolleri, gerçek iş akışları, gereksinimler, veriler, arayüzler ve açık kararlar.
- Tipik riskler
- problemden önce çözüm, fiilen yaşanan yerine belgelenmiş süreç ve sınırı olmayan bir kapsam.
- Sonunda elinizde olan
- riskleri, kabul kriterlerini ve gerekçeli bir efor aralığını içeren, önceliklendirilmiş ve belgelenmiş bir kapsam.
- Bilinçli olarak kaçındıklarımız
- Kendi başına amaç olan atölyeler, önceliği olmayan gereksinim listeleri ve netleşmemiş bir temele dayanan taahhütler.
- Olası sonuç
- hazır yazılım, daha küçük bir kapsam ya da projeden vazgeçme yönünde bir öneri de olabilir.
Nedir — ve neleri kapsar?
Gereksinim analizi ve Software Discovery, bir yazılım projesinin — çoğunlukla bir web uygulaması, portal veya platformun — uygulamadan önce yapılandırılmış biçimde netleştirilmesidir: hangi problem, kimin için, hangi süreçlerde, hangi veri ve sistemlerle çözülecek — ve bunun içinde hangi riskler ve açık kararlar bulunuyor. Batunet bunu, kapsam, mimari, efor ve uygulama hakkında gerekçeli karar verilebilecek belgelenmiş bir temele dönüştürür.
Hizmet kapsamı
- İş hedefleri ve beklenen iş faydası
- Paydaşlar, kullanıcı rolleri ve sorumluluklar
- Mevcut süreçler ve fiilî iş akışları
- İşlevsel ve işlevsel olmayan gereksinimler
- Olmazsa olmaz / olsa iyi olur ayrımı ve ilk kapsamın belirlenmesi
- Önceliklendirme ve bağımlılıklar
- Veriler, arayüzler ve mevcut sistemler
- Teknik riskler, açık kararlar ve kabul kriterleri
- Uygulama aşamaları, efor aralığı ve dokümantasyon
Ne zaman uygun — ne zaman değil?
Projeye uyan yolu öneririz — bu hazır bir ürün olsa bile.
Uygun
- Bir proje iş açısından henüz tam tanımlanmamış, ancak bütçelendirilmesi, planlanması ve sağlam bir temelde karara bağlanması gerekiyor.
- Birden fazla departman, rol veya lokasyon aynı sistemle çalışıyor ve farklı beklentiler taşıyor.
- Yeni yazılımın mevcut sistemlere, mevcut verilere veya işleyen süreçlere uyum sağlaması gerekiyor.
- Doğru cevabın özel yazılım mı, standart bir ürün mü yoksa bir kombinasyon mu olduğu henüz belli değil.
Uygun değil
- Kullanıcıları belli ve az sayıda bağımlılığı olan küçük, net tanımlı bir proje. Burada uygulamanın başında kısa bir netleştirme yeterlidir — ayrı bir Discovery aşaması gereksiz yük olur.
- Gereksinimler, kapsam ve çerçeve koşulları zaten sağlam biçimde belgelenmiş. Bu durumda onları yeniden toplamak yerine boşluklar açısından inceleriz.
- Her siparişten önce zorunlu bir ritüel olarak Discovery. Sonunda karar çıkmayan atölyeler belge üretir, ama temel üretmez.
Kod yazılmadan önce verilen kararlar.
Teknolojinin ne yapabildiği değil, onu neden bu şekilde kullandığımız.
Çözümden önce problem
Birçok proje bir çözümle başlar. Biz önce bu çözümün hangi problemi çözmesi gerektiğini ve problemin çözüldüğünün nereden anlaşılacağını netleştiriyoruz. Çözüm ancak bundan sonra değerlendirilebilir — daha az geliştirme gerektiren alternatiflere karşı da.
Olması gereken süreç yerine gözlemlenen iş akışları
Belgelenmiş süreçler nasıl çalışılması gerektiğini anlatır. Biz gerçekte nasıl çalışıldığına bakıyoruz — istisnalarıyla, dolambaçlı yollarıyla ve sistemin yanında tutulan tablolarıyla. Sonradan en çok maliyet çıkaran gereksinimler oradadır.
Tek bir rakam yerine bir aralık
Bir projenin başında belirsizlik en yüksek düzeydedir. Bu yüzden yalnızca kesinlik iddia eden tek bir rakam yerine, dayandığı varsayımlarla birlikte gerekçeli bir efor aralığı veriyoruz. Netleşen her soru bu aralığı daraltır.
Açık sorular görünür kalır
Her şey proje başlamadan netleştirilemez. Açık kalanlar sessizce varsayılmak yerine adlandırılır, bir sorumluya atanır ve ne zamana kadar karara bağlanması gerektiği belirlenir.
Erken fark ettiğimiz riskler.
Bu tür sistemlerde tipik olarak neyin ters gittiği — ve bunu canlı ortamda görünür hâle gelmeden nasıl önlediğimiz.
Problemden önce çözüm
- Neden
- Proje, akılda hazır bir çözümle başlar — bir uygulama, bir portal, bir yapay zeka işlevi. Gereksinimler de problemi tarif etmek yerine bu çözümü doğrulayacak şekilde yazılır.
- Erken uyarı işaretleri
- Gereksinimler arayüzlerden ve araçlardan söz eder ama bir hedef belirtmez; fayda sorusuna bir işlev listesiyle cevap verilir.
- Nasıl önlüyoruz
- Hedeften ve bugünkü süreçten başlıyor, istenen çözümü ancak ardından değerlendiriyoruz — hazır yazılıma, daha küçük bir kapsama ve vazgeçme seçeneğine karşı.
- Ödünleşim
- Bedeli: İlk fikir doğrudan hayata geçirilmek yerine sınanır. Farklı durum: Çözüm zaten doğrulanmışsa kapsama ve risklere odaklanırız.
Fiilen yaşanan yerine belgelenmiş süreç
- Neden
- Süreç tanımları ve el kitapları nasıl çalışılması gerektiğini gösterir. Gerçek iş ise hiçbir yerde yazmayan istisnalar, dolambaçlı yollar ve yan listeler içerir — maliyetli gereksinimler de tam olarak orada saklıdır.
- Erken uyarı işaretleri
- Cevaplar “aslında” diye başlar; resmî olarak bir sistemin yaptığı adımları tablolar ve e-posta kutuları üstlenir; özel durumları yalnızca bir kişi bilir.
- Nasıl önlüyoruz
- İşi yapan kişilerle konuşuyor, gerçek vakaları inceliyor ve istisnaları dipnot olarak değil, gereksinim olarak kayda alıyoruz.
- Ödünleşim
- Bedeli: Uzman kullanıcıların günlük işten ayırdığı zaman. Farklı durum: Süreç yeni oluşturuluyorsa ve henüz fiilî bir uygulama yoksa.
Sınırı olmayan kapsam
- Neden
- Her gereksinim tek başına makuldür. Önceliklendirme ve sınırlama olmadan kapsam; efor, takvim ve bütçe birbirini tutmayana kadar büyür.
- Erken uyarı işaretleri
- Her şey olmazsa olmazdır; geliştirilmeyecek şeylerin bir listesi yoktur; yeni istekler eklenir ama mevcut hiçbir istek geri çekilmez.
- Nasıl önlüyoruz
- Olmazsa olmaz ile olsa iyi olur ayrılır, ilk kapsam eksiksiz bir iş akışı boyunca belirlenir ve kapsam dışında kalanlar açıkça kayda geçirilir.
- Ödünleşim
- Bedeli: İlk aşamada görünür biçimde bazı şeylerden vazgeçmek. Farklı durum: Kapsam dışarıdan kesin olarak belirlenmişse miktarı değil, sıralamayı önceliklendiririz.
Gizli bağımlılıklar
- Neden
- Proje dışındaki mevcut sistemler, veri kaynakları ve sorumluluklar çoğu zaman hızı ve uygulanabilirliği belirler. Geç fark edilirlerse mimariyi, eforu ve takvimi aynı anda kaydırırlar.
- Erken uyarı işaretleri
- Arayüzler “var” ama belgelenmemiş; verilerin kalitesi bilinmiyor; bağlanan bir sistemin sorumlusunun kim olduğunu kimse söyleyemiyor.
- Nasıl önlüyoruz
- Verileri, arayüzleri ve sorumluları erken kayda alıyor, kritik erişimleri gerçek örneklerle test ediyor ve açık kalan konuları tarihli bir risk olarak takip ediyoruz.
- Ödünleşim
- Bedeli: Uygulama kesinleşmeden önce mevcut sistemlerin sorumlularına düşen iş yükü. Farklı durum: Proje bağımsızsa ve mevcut hiçbir sisteme dokunmuyorsa.
Uygulamadan önce netleştirdiğimiz sorular.
Mimariyi araç seçiminden çok sizin yanıtlarınız şekillendirir.
Hangi problem çözülmeli — ve çözüldüğünü nereden anlayacağız?
- Neden önemli
- Doğrulanabilir bir hedef olmadan ne kapsam önceliklendirilebilir ne de sonunda projenin değip değmediği tespit edilebilir.
- Tipik sonuç
- Hedef belirsizse önce onu netleştiririz. Netse, sonraki her gereksinimin ölçüleceği ölçüt hâline gelir.
Sistemi kimler kullanacak — ve kimler kullanmadan etkilenecek?
- Neden önemli
- Kullanıcı rolleri arayüzleri ve yetkileri belirler. Muhasebe, veri koruma veya işletim gibi dolaylı etkilenenler, aksi hâlde ancak geç ortaya çıkacak gereksinimler getirir.
- Tipik sonuç
- Her iki grubu da sürece dâhil ediyor, roller, yetkiler ve işlevsel olmayan gereksinimleri buradan türetiyoruz.
Bunun gerçekten özel olarak geliştirilmesi gerekiyor mu?
- Neden önemli
- Özel yazılım; hazır yazılımın süreci karşılamadığı ya da onu uyarlamanın hedefe yönelik bir geliştirmeden daha pahalıya geldiği yerlerde kendini amorti eder.
- Tipik sonuç
- Standart bir ürün ihtiyacı karşılıyorsa onu öneriyoruz. Özel olarak geliştirilen, işletmeyi gerçekten farklı kılan kısımdır.
Hangi sistemler ve veriler işin içinde?
- Neden önemli
- Entegrasyonlar ve veri aktarımları gecikmelerin en sık nedenleri arasındadır — ve hedefli sorularla erkenden fark edilebilirler.
- Tipik sonuç
- Bir arayüz ve veri haritası çıkarıyor, herhangi bir efor tahmini vermeden önce her bağlantıyı risk açısından değerlendiriyoruz.
Gerçek fayda sağlayan en küçük kapsam nedir?
- Neden önemli
- Her şeyi içeren bir ilk kapsam geç teslim edilir ve az şey öğretir. Fazla küçük tutulan bir kapsam ise kimsenin günlük işte kullanmadığı bir sonuç üretir.
- Tipik sonuç
- İlk kapsamı eksiksiz bir iş akışı boyunca belirliyor, sonraki aşamaları buna göre sıralıyoruz.
Hangi kararlar henüz açık — ve ne zamana kadar verilmeleri gerekiyor?
- Neden önemli
- Başlangıçta açık kararların olması normaldir. Tehlikeli hâle geldikleri an, kimsenin sorumluluğunu üstlenmediği ve proje içinde sessizce verildikleri andır.
- Tipik sonuç
- Her açık karara bir sorumlu ve bir tarih atanır; efor aralığı, o zamana kadar kararın yerini tutan varsayımı açıkça belirtir.
Tasarımdan işletime.
Sistemin yalnızca çalışması yetmez, işletimde de ayakta kalması gerekir. Her önerinin bir bedeli vardır — ve farklı karar verdiğimiz durumlar da.
Hedefler ve iş faydası
Yazılımla neyin değişmesi gerektiğini kayda alıyoruz: hangi iş ortadan kalkacak, hangi hata artık yaşanmayacak, hangi karar daha hızlı verilebilecek. Mümkün olduğunca doğrulanabilir; mümkün olmadığında dürüstçe belirtilmiş.
Ödünleşim · Bedeli: Teknolojiye değil, iş birimi sorumlularına ayrılan zaman. Farklı durum: Hedef önceden belirlenmiş ve tartışmasızsa kısa bir teyit yeterlidir.
Roller ve iş akışları
Sistemle kim çalışıyor, kim etkileniyor, kim karar veriyor? Kullanıcı rollerini ve fiilî iş akışlarını tanımlıyoruz — günlük işte düzenli olarak karşılaşılan istisnalar da dâhil.
Ödünleşim · Bedeli: Birden fazla paydaşla görüşme ve gözlem. Farklı durum: Sistemi yalnızca tek bir ekip kullanıyorsa kısa bir rol özeti yeterlidir.
Gereksinimler ve sınırlama
İşlevsel gereksinimler sistemin ne yaptığını, işlevsel olmayanlar ise hangi koşullar altında yaptığını tanımlar — yük, erişilebilirlik (availability), veri koruma, izlenebilirlik. Her ikisi de önceliklendirilir ve olmazsa olmaz ile olsa iyi olur olarak ayrılır.
Ödünleşim · Bedeli: Bazı istekler görünür biçimde ertelenir. Farklı durum: Kapsam zaten bağlayıcı biçimde belirlenmişse onu boşluklar ve çelişkiler açısından inceleriz.
Veriler, arayüzler ve mevcut sistemler
Hangi veriler oluşuyor, nereden geliyor, hangi sistem esas kaynak? Hangi sistemler bağlanacak ve arayüzleri ne kadar iyi belgelenmiş? Gizli bağımlılıkların çoğu buradadır.
Ödünleşim · Bedeli: Mevcut sistemlere ve sorumlularına erken erişim. Farklı durum: Proje mevcut hiçbir veriye ve sisteme dokunmuyorsa.
Riskler ve kabul kriterleri
Teknik riskler ve açık kararlar adlandırılır ve değerlendirilir. Her önemli gereksinim için, karşılandığının nereden anlaşılacağını kayda alıyoruz — test ve kabulün temeli budur.
Ödünleşim · Bedeli: Taahhüt verilmeden önce sorulan rahatsız edici sorular. Farklı durum: Risk kanıtlanabilir biçimde düşükse değerlendirme kısa tutulur.
Aşamalar ve efor aralığı
Önceliklendirilmiş kapsam ve bağımlılıklardan kaba uygulama aşamaları ile varsayımlarıyla birlikte bir efor aralığı ortaya çıkar. Bu aralık bütçenin, mimarinin ve geliştirme yapılıp yapılmayacağı kararının temelidir.
Ödünleşim · Bedeli: Netleştirme yapılmadan bağlayıcı bir rakam verilmez. Farklı durum: Kapsam ve çerçeve, doğrudan güvenilir bir tahmin yapılabilecek kadar netse.
İlk görüşmeden çalışan sisteme.
Her proje aynı dört adımı izler. Ara sonuçları yalnızca sonda değil, süreç boyunca görür ve değerlendirirsiniz.
- 01
İhtiyacı anlamak, gereksinimleri netleştirmek
İlk görüşmeyi doğrudan yönetimle yaparsınız; projenizi, iş süreçlerinizi ve mevcut sistemlerinizi konuşuruz. Ardından hedefleri ve gereksinimleri yazılı hâle getirir, özel geliştirmenin anlamlı olup olmadığını açıkça söyleriz.
- 02
Çözümü ve mimariyi planlamak
Teknik bir çözüm önerir, kapsamı ve uygulama sırasını belirler, temel kararları gerekçeleriyle birlikte belgeleriz.
- 03
Geliştirmek ve birlikte kontrol etmek
Testler ve kod incelemeleriyle aşama aşama geliştiririz. Ara sonuçları düzenli olarak sunarız; böylece erken değerlendirip öncelikleri değiştirebilirsiniz.
- 04
Yayına almak ve desteğe devam etmek
Yayına alındıktan sonra bakım, güncelleme, izleme ve geliştirmeyi kararlaştırılan kapsamda üstleniriz. Projeye özel kaynak kod ve dokümantasyon size teslim edilir.
Proje sonunda elinizde olanlar.
Doğrulanabilir kriterlere sahip, belgelenmiş bir hedef tablosu
Olmazsa olmaz / olsa iyi olur ayrımı net, önceliklendirilmiş bir kapsam
Süreçlere, rollere ve sorumluluklara genel bir bakış
Kabul kriterleri içeren bir gereksinim kataloğu
Arayüzlere, veri kaynaklarına ve mevcut sistemlere genel bir bakış
Açık kararları içeren bir risk ve bağımlılık analizi
Özel yazılım, hazır yazılım veya vazgeçme arasındaki seçim için bir temel
Mimari ve uygulama için temel oluşturan uygulama aşamaları ve efor aralığı
Çalışma araçları ve çıktılar
Gereksinim analizi ve Software Discovery hakkında sorular
Her proje bir Discovery'ye ihtiyaç duyar mı?
Hayır. Küçük ve net tanımlı projelerde uygulamanın başında kısa bir netleştirme yeterlidir. Derinliği sabit bir format değil; belirsizlik, bağımlılıklar ve risk belirler.
Bir gereksinim analizi ne kadar sürer?
Bu, projenin büyüklüğüne ve belirsizlik derecesine bağlıdır. Kapsamı sınırlı bir projede birkaç görüşme ve kısa bir sonuç belgesi yeterlidir; birden fazla birim ve mevcut sistem işin içindeyse netleştirme de buna göre daha uzun sürer. Çerçeveyi önceden birlikte belirliyoruz.
Analizden sonra efor tahmini ne kadar güvenilirdir?
Öncesine göre daha güvenilir, ama sınırsız derecede kesin değil. Dayandığı varsayımları ve onu kaydırabilecek riskleri içeren bir efor aralığı alırsınız. Ne kadar çok şey netleşirse aralık o kadar daralır.
Ya geliştirme yapmamamız gerektiği ortaya çıkarsa?
Bu bir başarısızlık değil, bir sonuçtur. Hazır yazılım, daha küçük bir kapsam ya da vazgeçme yönünde gerekçeli bir öneri, yanlış bir temel üzerine kurulan bir projeden daha az maliyetlidir.
Hangi çalışma araçlarını kullanıyorsunuz — ve elimize ne geçiyor?
Sabit bir araç setiyle değil, netleştirmenin gerektirdikleriyle: fiilî iş akışları için süreç modelleri, önceliklendirilmiş gereksinim katalogları, önemli gereksinimler için kabul kriterleri ve verilen ve açık kalan kararlar için karar kayıtları. Analiz bu süreçte ne bir teknolojiye ne de belirli bir uygulama biçimine bağlanır.
İlgili konular.
Bu sayfayla bağlantılı rehberler, kararlar, hizmetler ve projeler.
Projenizi konuşalım.
Projenizi kısaca anlatın. İlk görüşmeyi doğrudan yönetimle yaparsınız.
