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.
Gereksinim analizi ve Software Discovery: kısa bir özet.
Karar vericiler için kısa özet: Bu hizmet hangi durumlarda uygundur, nasıl çalışırız ve nelere odaklanırız?
- 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
- Karar üretmeyen çalıştaylar, önceliklendirilmemiş gereksinim listeleri ve belirsiz varsayımlara 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.
Erken fark ettiğimiz riskler.
Bu tür sistemlerde sık karşılaşılan riskleri, erken uyarı işaretlerini ve aldığımız önlemleri açıklıyoruz.
- 01
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şı.
- Avantajlar ve sınırlamalar
- 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.
- 02
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.
- Avantajlar ve sınırlamalar
- 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.
- 03
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.
- Avantajlar ve sınırlamalar
- 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.
- 04
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.
- Avantajlar ve sınırlamalar
- 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.
Koddan önce sorduğumuz sorular.
Mimariyi belirlemek için önce ihtiyaçlarınızı ve kısıtlarınızı netleştiriyoruz. Aşağıdaki sorular teknik kararlarımızın temelini oluşturur.
- 01
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.
- 02
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.
- 03
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.
- 04
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.
- 05
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.
- 06
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.
Bu hizmet nedir, 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
Kod yazılmadan önce verilen kararlar.
Teknoloji seçimlerimizin ve uygulama yaklaşımımızın gerekçeleri.
- 01
Çö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.
- 02
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.
- 03
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.
- 04
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.
Geliştirme yaklaşımımız: Batunet Engineering Method.
İhtiyaçların netleştirilmesinden uzun vadeli bakım ve işletime uzanan yedi aşamalı çalışma yaklaşımımız.
- 01
FrameProblemi netleştirme
Herhangi bir çözüm düşünülmeden önce asıl problem, sınırları ve ölçülebilir bir başarı tanımı belirlenir.
- 02
ModelModelleme
İş alanını (domain) ortak ve açık bir dille modelliyor, farklı sorumlulukları ayrı bağlamlarda tanımlıyoruz.
- 03
DecideKarar
Temel mimari kararları, değişiklik maliyeti henüz düşükken değerlendirir ve gerekçeleriyle birlikte belgeleriz.
- 04
ProveKanıtlama
Kapsamı genişletmeden önce çalışan bir temel kurar, mimariyi en riskli iş akışı üzerinde doğrularız.
- 05
BuildGeliştirme
Doğrulanmış temel üzerinde küçük, test edilebilir ve geri alınabilir adımlarla geliştiririz. İlerleme her hafta görünür olur.
- 06
HardenSağlamlaştırma
Hata senaryolarını, yükü ve güvenliği test ediyoruz. Sistemin normal koşulların yanı sıra sorun anlarında da nasıl davrandığını doğruluyoruz.
- 07
Operateİşletim
Sistemi işletir, izler ve geliştirmeye devam ederiz — ve onu anlaşılır ve değiştirilebilir tutarız.
Tasarımdan canlı kullanıma.
Sistemin çalışmasının yanı sıra canlı ortamda izlenebilir ve yönetilebilir olması gerekir. Her önerinin avantajlarını, maliyetlerini ve farklı bir seçimin uygun olacağı koşulları değerlendiriyoruz.
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ş.
Avantajlar ve sınırlamalar · 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.
Avantajlar ve sınırlamalar · 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.
Avantajlar ve sınırlamalar · 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.
Avantajlar ve sınırlamalar · 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.
Avantajlar ve sınırlamalar · 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.
Avantajlar ve sınırlamalar · 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.
Projenize sağladığımız katkılar.
- 01
Doğrulanabilir kriterlere sahip, belgelenmiş bir hedef tablosu
- 02
Olmazsa olmaz / olsa iyi olur ayrımı net, önceliklendirilmiş bir kapsam
- 03
Süreçlere, rollere ve sorumluluklara genel bir bakış
- 04
Kabul kriterleri içeren bir gereksinim kataloğu
- 05
Arayüzlere, veri kaynaklarına ve mevcut sistemlere genel bir bakış
- 06
Açık kararları içeren bir risk ve bağımlılık analizi
- 07
Özel yazılım, hazır yazılım veya vazgeçme arasındaki seçim için bir temel
- 08
Mimari ve uygulama için temel oluşturan uygulama aşamaları ve efor aralığı
Ne zaman uygun — ne zaman değil?
Dürüst yanıt, danışmanlığın bir parçasıdır. Soruna uyan yolu öneririz.
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.
Ç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 teknik içerikleri inceleyin.
Konuyu derinleştiren kavramları, mimari kararları, uygulama kılavuzlarını ve değerlendirmeleri birlikte inceleyin.
