Gereksinim dokümantasyonu – 1

Gereksinim dokümantasyonunu iki ana doküman üzerinden yürütebilirsiniz. Bunlardan birincisi vizyon kapsam dokümanı olarak adlandırılırken, diğeri yazılım gereksinimleri belirtimi (SRS – software requirements specification) adını almaktadır. Birinci dokümana vizyon dokümanı dendiği de görülmekteyken, ikinci dokümanın benzer içerikleri "analiz dokümanı" gibi isimlerle anılabilse de, genellikle bu dokümanlar tam anlamıyla SRS faydasını göstermemektedirler. Bu yazıda öncelikle vizyon kapsam dokümanı ve içeriğinden bahsedeceğim.
 
Vizyon kapsam dokümanının kullanımını yeterince iyi açıklayabilmek için öncelikle analiz fazına bir göz atmak gerekir. Farklı metodolojiler bu fazı farklı şekillerde yapılandırsa da, esasen doğrusu bu safhayı ikiye bölerek incelemektir. RUP ve MSF gibi metodolojilerin yaptığı da budur zaten. Analiz safhasının ilk bölümünü ön analiz, ikinci bölümünü ise detaylı analiz olarak ayırmak uygun olacaktır. Ön analiz kapsam ve vizyonun belirlendiği bölüm olarak büyük önem taşımaktadır.
 
Bir projenin ön analiz safhası, projenin ne işe yarayacağı, neden yapıldığı ve ne gibi ana faydalar sağlayacağı tarzında temel sorulara cevap vermekle geçer. Bu bölümde projenin vizyonu sorgulanmalı ve kapsamı belirlenerek müşteri ile mutabakata varılmalıdır. Ayrıca ana paydaşlar ve temel riskler gibi projeyi etkileyen temel unsurlar da burada saptanır. Safhanın ana çıktısı vizyon kapsam dokümanı olarak adlandırılır. Fizibilite, risk dokümanı gibi başka çıktılar da uygulanan yaşam döngüsü modeli çerçevesinde ortaya çıkacaktır. Safhanın faaliyetlerini çıktı doküman şablonunu inceleyerek açıklamaya çalışalım.
 
Aşağıdaki doküman şablonu, geçmiş tecrübeler ve çeşitli metodolojilerin sunduğu şablonların etüd edilmesi ile oluşturulmuştur. Biz i-con’da uzunca bir süredir kullanmaktayız ve verim almaktayız.
 
Vizyon Kapsam Dokümanı şablonu:
  1. Giriş
    1. Amaç
      Dokümanın amacı ifade edilir.
    2. Kısaltmalar
      Dokümanda kullanılan kısaltmalar açıklanır.
    3. Referanslar
      Refere edilen dokümanların vb listesi verilir.
    4. Özet
      Proje hakkında bir, en fazla iki paragraflık yönetici özeti verilir.
  2. Çözüm Vizyonu
    1. Art alan
      Proje öncesi durum açıklanır.
    2. Vizyon Tanımı
      Projenin vizyonu ifade edilir.
    3. Riskler
      Sadece gerçekleşmesi durumunda projeyi başarısızlığa götürecek kadar kökten ve önemli riskler ifade edilir.
  3. Kapsam
    1. Ana özellikler
      Projenin ana özellikleri listelenir.
    2. Kapsam dışı
      Projenin kapsamı dışında kalan ana özellikler sıralanır.
    3. Diğer Gereksinimler
      Performans, güvenlik vb gibi diğer gereksinimler varsa burada listelenir.
    4. Kısıtlar, varsayımlar, bağıntılar
      Projenin uyması gereken şartlar burada belirtilir.
  4. Paydaşlar
    Proje ana paydaşları burada listelenir.
  5. İş Öncelikleri
    1. Proje başarı etkenleri
      Projenin başarı etkenleri belirtilir.
    2. Ürün başarı etkenleri
      Ürününün başarı etkenleri belirtilir.
 
Sıradan gidersek, dokümanın ilk bölümü standart doküman girişidir. Buradaki amaç projenin değil dokümanın amacıdır ve hemen hemen her projede "bu dokümanın amacı filanca projenin vizyon ve kapsamının tanımlanmadır" gibi bir ifadeden oluşmalıdır. Proje özeti gerçekten kısa olup, proje hakkında genel bir fikir oluşturmaya yetecek şekilde oluşturulmalıdır.
 
İkinci bölüm çözümü ifade eder. Analistin temel işinin çözüm tanımlamak olduğunu hatırlarsak, bu kısım ilgili çözümü ifade eden önemli bir bölümdür. Art alan "background" kelimesinin türkçesi olup, proje öncesi mevcut durumu ifade eder. Eğer proje başka bir ürünün yerini almayı hedefliyorsa, yahut henüz bu konuda hiçbir çalışma yapılmamışsa, belki de ilgili süreç elle (manuel) takip ediliyorsa, bunlardan söz edilmelidir. Bu kısmı okuyan proje takımı müşterinin mevcut durumu hakkında bilgi sahibi olacaktır. Vizyon tanımı projenin neden yapıldığını ifade eder. Proje takımına ortak bir hedef vermeli ve onları motive etmelidir. Vizyon hem basit hem karmaşık, bazen de anlamsını kaybetme riski taşıyan bir konu olarak bu yazının sınırlarını aşmaktadır. Şimdilik bu kadarını söylerek bu konuyu başka bir yazıda değinmek üzere kenara ayıracağız.
 
Üçüncü bölüm projenin kapsamını belirler ve birçok projede bence en önemli bölümdür. Ana özellikler 3.1 başlığı altında sıralanır. Burada analistin dikkat etmesi gereken, detayları doğru başlıklar altında toplamak ve tekrardan kaçınmaktır. Örneğin sipariş verme diye bir ana özelliğimiz varsa, bu siparişin muhtemelen bir iş akışı da olacaktır. Bu durumda ilgili sipariş akışını ifade etmek için iş akışı başlığında bir ana özellik daha koymak tekrar yol açar. Ana özellikler 1-2 paragrafla açıklanmalıdır ancak daha fazla detaya gerek yoktur. Detaylar sonraki fazda ortaya çıkacak ve SRS içinde yer alacaktır.
 
Bu dokümanda yadırganan başlıklardan biri de kapsam dışıdır. Beraber çalıştığımız birçok uzman, ana özelliklerde ifade edilmeyen herşeyin kendiliğinden kapsam dışı olduğunu düşünmektedir. Ancak tecrübe bunun böyle olmadığını göstermiştir. Haliyle kapsam dışında kalan herşeyi listelemek de imkansızdır, bu durumda bu başlığa ne yazılmalıdır? Kapsam dışını basitçe ismi geçmiş ama yapılmamasına karar verilmiş ana özellikler gibi düşünebilirsiniz. Bu müşteri tarafından ifade edilip vazgeçilmiş veya analist tarafından önerilip kabul edilmeyen özellikler olabilir. Bu madde daha önceki yazılarımızda yer alan kapsamın korunmasında önemli bir önlemdir.
 
Paydaşlarla ilgili de söylenecek oldukça fazla şey var. Bu yüzden basitçe paydaşları dahili ve harici olarak ikiye ayırıp, diğer detayları sonraki bir yazıya bırakmak en iyisi olacak. Dahili paydaşlar proje takımı, harici paydaşlarsa projenin çıktısından doğrudan ya da dolaylı etkilenecek ve/veya faydalanacak tüm kesimleri belirler. Önemli harici paydaşlar, yani kullanımı ya da kabulü olmazsa projenin başarılı tamamlanamayacağı tüm paydaşlar bu başlık altında listelenmelidir. Ayrıca ön analiz sırasında bilinen diğer paydaşlar da burada tanımlanır.
 
Önceliklerin proje ve ürün olarak ikiye ayrılmasının temel sebebi bunların bazen farklı olabilmesidir. Örneğin teslim tarihi proje ile ilgili bir kıstasken, kalite ürünü bağlamaktadır.
 
Dokümanın genel özellikleri bunlardır. Vizyon ve paydaşlar hakkında ayrıca belirtilmesi gereken noktalar olmakla beraber dokümanın yapısını değiştirecek bir durum söz konusu değildir. Bu dokümanı ön analizin sonunda yayınlamanızı ve müşteriye onaylatmanızı öneririm. Sonraki faaliyetler yaşam döngüsü modeline göre değişiklik gösterebilmektedir. Şablonu olduğu gibi ya da değiştirerek kullanabilirsiniz.
Bu yazı Yazılım mühendisliği içinde yayınlandı. Kalıcı bağlantıyı yer imlerinize ekleyin.

1 Response to Gereksinim dokümantasyonu – 1

  1. Taner dedi ki:

    Yeni projelere başlarken gereksinim dokümantasyonu şarttır bu dokümanın içeriğini gayet net anlatmışsınız. Önceden gereksinim dokümanı oluşmamış var olan bir projeye ek modüller yazarken mevcut proje için gereksinim dokümanı hazırlamak oldukça maliyetli oluyor. Bu durumda analiz dokümanı oluşturmak için izlenecek yol ne olmalıdır.

Taner için bir cevap yazın Cevabı iptal et

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s