ISO 19650’DE INFORMATİON REQUİREMENTS KAVRAMSALLAŞTIRMAK

BIM teslimatlarında en büyük sürpriz, modelin “var” olmasına rağmen işe yarar bilginin “yok” olmasıdır. ISO 19650, bu boşluğu “Information Requirements” yaklaşımıyla kapatır: hangi bilginin, kim için, ne zaman, hangi formatta ve hangi doğruluk düzeyinde üretileceğini tarif ederek teslimatı ölçülebilir hâle getirir.

Bu makalede Information Requirements kavramını soyut bir liste olmaktan çıkarıp yönetişim, süreç ve veri şemasıyla birlikte ele alacağız. Amaç; OIR, AIR ve EIR katmanlarının birbirine nasıl bağlandığını, CDE üzerinde nasıl izlenebilir kılındığını ve kabul kriterleriyle nasıl doğrulandığını sistematik biçimde kavramsallaştırmaktır.

Kurumsal yazılım geliştirme ekipleri için doğru soru şudur: “BIM veri ürününü” hangi gereksinimlerle tanımlayıp hangi kalite kapılarından geçirerek canlı varlık yönetimine güvenle aktaracağız? Yanıt, gereksinimleri teknik artefaktlara dönüştürmekten ve yaşam döngüsüne yaymaktan geçer.

ISO 19650 bağlamında bilgi gereksinimlerini tanımlamak

ISO 19650 terminolojisinde “Information Requirements”, belirli bir amaç için ihtiyaç duyulan bilginin tanımıdır. Tanım; içerik (ne), bağlam (neden), zamanlama (ne zaman), sorumluluk (kim), yöntem (nasıl) ve doğrulama (hangi ölçütle) bileşenlerini birlikte içerir. Buradaki kritik nokta, gereksinimin sadece “öğe listesi” değil, aynı zamanda kabul edilebilirlik koşullarını da taşımasıdır.

Pratikte gereksinimler, teslimatın “ürün tanımı” gibi davranır. Yazılım dünyasındaki user story + acceptance criteria birleşimi gibi düşünün: “Bir varlık için bakım planı üretmek” hedefi varsa, gerekli parametreler, sınıflandırma kodları, ilişki kısıtları ve doğrulama testleri gereksinim paketinin parçası olur.

• Amaç: Karar verme, işletme, maliyet, risk veya mevzuat uyumu gibi hedefi netleştirmek
• Kapsam: Varlık türleri, disiplinler, dokümanlar ve model çıktılarıyla sınırı çizmek
• Kalite: Doğruluk, tamlık, tutarlılık, güncellik ve izlenebilirlik ölçütlerini eklemek
• Değişim: Versiyonlama ve onay akışlarıyla gereksinimi yönetilebilir kılmak

Bilgi teslimatını veri ürünü olarak konumlandırmak

Information Requirements yaklaşımını kurumsal veri ürünleriyle eşleştirmek, ekiplerin aynı dili konuşmasını sağlar. Her teslimat; şema, sözlük, doğrulama kuralları ve tüketici senaryolarıyla birlikte yönetilmelidir. Bu yaklaşım, CDE üzerinde “üretim hattı” kurarak teslimatların tekrar edilebilir ve denetlenebilir olmasını mümkün kılar.

OIR, AIR ve EIR katmanlarını ilişkilendirmek

ISO 19650’de gereksinimler katmanlıdır ve birbirini besler. OIR (Organizational Information Requirements), organizasyonun karar ihtiyacını tarif eder. AIR (Asset Information Requirements), işletmede yönetilecek varlıkların hangi bilgiyle temsil edileceğini netleştirir. EIR (Exchange Information Requirements) ise tedarik zincirinden hangi teslimatın, hangi aşamada, hangi formatta ve hangi kontrolle isteneceğini teknikleştirir.

Bu katmanları doğru ilişkilendirmek için “üst amaç → varlık bağlamı → değişim paketi” zincirini kurmak gerekir. Örneğin enerji verimliliği KPI’ı (OIR) hedefleniyorsa, HVAC ekipmanı için etiket, performans eğrisi, bakım periyodu gibi alanlar (AIR) tanımlanır; tedarikçiden IFC + COBie alan eşlemesi, LOD/LOI beklentisi ve doğrulama raporu (EIR) talep edilir.

OIR içinde karar senaryolarını çerçevelemek

OIR yazarken “hangi karar, hangi zaman aralığında, hangi riskle” soruları üzerinden ilerlemek işe yarar. Karar senaryoları; rapor, pano, simülasyon veya mevzuat bildirimi gibi çıktılara dönüşür. Böylece OIR soyut hedef olmaktan çıkar, veri gereksinimini tetikleyen açık bir tüketim ihtiyacına dönüşür.

AIR ile varlık sözlüğünü standardize etmek

AIR, işletme tarafının gerçek tüketim alanıdır. Varlık sınıfları, özellik setleri, birim kuralları, sınıflandırma (örn. Uniclass/OmniClass) ve benzersiz kimlik stratejisi bu katmanda netleşir. AIR’ı iyi tasarlamak, bakım yönetim sistemi (CMMS/EAM) ile BIM arasında anlam birliği kurar.

EIR ile tedarikçi teslimatlarını sözleşmeselleştirmek

EIR, ihale ve sözleşme diline çevrilen katmandır. Teslim edilecek dosya türleri, model ayrıntı seviyesi beklentileri, CDE klasör yapısı, isimlendirme, revizyon kodları ve kabul testleri EIR’da yer alır. EIR’ın gücü, “anlaşılamayan beklentileri” ölçülebilir şartlara dönüştürmesinden gelir.

CDE üzerinde gereksinim izlenebilirliği kurmak

Common Data Environment (CDE), gereksinimlerin sadece saklandığı değil, yaşam döngüsü boyunca izlenebilir kılındığı yerdir. Gereksinimlerin kim tarafından oluşturulduğu, hangi versiyonla güncellendiği, hangi teslimat paketine bağlandığı ve hangi testlerden geçtiği CDE üzerinde açık olmalıdır. Bu yaklaşım, gereksinimlerin “doküman” olmaktan çıkıp “kontrol edilebilir nesne” olmasını sağlar.

İzlenebilirlik için üç temel bağ kurmak gerekir: (1) gereksinim → teslimat öğesi (model/çizim/rapor), (2) gereksinim → doğrulama kuralı (test), (3) gereksinim → iş sonucu (KPI/karar). Böylece bir değişiklik geldiğinde etkilenen teslimatlar ve testler otomatik tespit edilebilir.

Metadata şemasıyla gereksinimleri makinece okunur kılmak

CDE’de gereksinim kayıtlarını makinece okunur hâle getirmek, otomasyonun ön koşuludur. Örneğin her gereksinime benzersiz kimlik, kapsam etiketi, disiplin, varlık sınıfı, teslimat aşaması ve doğrulama yöntemi gibi alanlar eklenebilir. Bu alanlar, arama, filtreleme ve raporlama için kritik rol oynar.

Değişiklik kontrolünü versiyon politikasıyla yönetmek

Gereksinimler yaşayan varlıklardır; proje ilerledikçe değişir. Bu değişimi yönetmek için onay kapıları, değişiklik gerekçesi, etki analizi ve geriye dönük iz kayıtları gerekir. Yazılım geliştirmedeki “change request” mantığı burada birebir çalışır: gereksinim değiştiğinde ilgili EIR maddeleri, teslimat paketleri ve doğrulama testleri güncellenir.

Bilgi doğrulama ve kabul kriterlerini tasarlamak

Information Requirements’in en önemli çıktısı, doğrulama ve kabul kriterleridir. “Modelde yangın damperi olsun” demek yetmez; damperin hangi sınıfta olacağı, hangi parametreleri taşıyacağı, hangi ilişkilere sahip olacağı ve hangi formatta raporlanacağı da yazılmalıdır. Kalite, ölçülebilir kurallara dönüştürülmediğinde teslimat tartışmaları kaçınılmaz olur.

Doğrulama yaklaşımı genellikle üç katmanda ele alınır: (1) sentaktik doğrulama (dosya adı, klasör, format), (2) şematik doğrulama (alanlar, tipler, zorunluluklar), (3) iş kuralı doğrulaması (tutarlılık, eşikler, ilişkiler). Bu katmanları ayrı ayrı raporlamak, tedarikçiyle iletişimi kolaylaştırır.

Ölçülebilir acceptance criteria ile kaliteyi somutlamak

Kabul kriterleri; eşik değer, zorunlu alan, format kuralı, referans kod listesi ve hata sınıflandırması içermelidir. Örneğin “%98 tamlık” hedefi koyulabilir ve eksik alanlar “kritik/önemli/düşük” olarak sınıflanabilir. Bu sayede kabul süreci pazarlık değil, veri temelli değerlendirmeye dönüşür.

{
  "requirementId": "EIR-MEP-014",
  "assetClass": "HVAC_AHU",
  "deliveryStage": "Stage_4",
  "mandatoryProperties": [
    {"name": "AssetTag", "type": "string", "rule": "nonEmpty"},
    {"name": "SerialNumber", "type": "string", "rule": "nonEmpty"},
    {"name": "Airflow_m3h", "type": "number", "rule": ">=0"},
    {"name": "MaintenanceInterval_days", "type": "integer", "rule": ">=30"}
  ],
  "classification": {"system": "Uniclass2015", "codeRule": "validCode"},
  "acceptance": {"completeness": ">=0.98", "criticalErrors": "0"}
}

Bilgi gereksinimlerini sözleşme ve süreçlere entegre etmek

Gereksinimler, sözleşme ekine yazılıp unutulursa değer üretmez. Entegrasyon; rol tanımları, teslimat takvimi, sorumluluk matrisi ve CDE iş akışlarıyla yapılır. Ekipler arası uyum için “kim üretir, kim kontrol eder, kim onaylar” zinciri açık olmalıdır. Bu noktada BEP (BIM Execution Plan) ve IDP (Information Delivery Plan) devreye girer.

BEP; yöntem, araçlar, isimlendirme, koordinasyon ve kalite yönetimi gibi “nasıl” sorusuna yanıt verir. IDP ise “ne zaman, hangi paket” sorusunu planlar. Bu iki artefakt, EIR ile birlikte işletilirse gereksinimler zaman çizelgesine ve iş yüküne bağlanır; böylece sadece doküman değil, yürütülen bir süreç olur.

IDP üzerinden teslimat paketlerini kademelendirmek

IDP oluştururken gereksinimleri aşamalara bölmek, tedarikçi tarafında uygulanabilirliği artırır. Örneğin erken aşamada kritik varlık kimlikleri ve yerleşim, orta aşamada performans parametreleri, geç aşamada bakım ve garanti bilgileri istenebilir. Böylece gereksinimler “son dakika veri toplama” krizine dönüşmeden, iteratif biçimde olgunlaştırılır.

Sorumluluk matrisiyle kontrol noktalarını netleştirmek

RACI benzeri bir sorumluluk matrisi; gereksinimin yazımı, güncellenmesi, doğrulanması ve onaylanması için rol dağıtımı sağlar. Bu matrisi CDE iş akışıyla birleştirmek, kimlerin hangi adımda işlem yapacağını otomatikleştirir ve gecikmeleri görünür kılar.

Gereksinimlerin teknik örneklerle uygulanabilir kılmak

Kurumsal ekipler için en kritik adım, gereksinimleri pratikte kullanılabilir şablonlara dönüştürmektir. Şablonlar; alan sözlüğü, kod listeleri, doğrulama kuralları ve raporlama formatlarını içerdiğinde ekipler aynı standartla çalışır. Ayrıca gereksinimler, API veya doğrulama aracıyla entegre edilerek sürekli kontrol edilebilir.

Aşağıdaki örnek, gereksinimlerin tedarikçi teslimatına bağlanması için basit bir izlenebilirlik tablosu üretme mantığını gösterir. Bu tür otomasyonlar, kalite kontrolünü proje sonuna bırakmadan erken uyarı sağlar.

def trace_requirements(requirements, delivered_items):
    """
    requirements: list of dicts {id, assetClass, mandatoryProperties[]}
    delivered_items: list of dicts {assetClass, properties{}}
    returns: list of dicts {requirementId, status, missing[]}
    """
    results = []
    by_class = {}
    for item in delivered_items:
        by_class.setdefault(item["assetClass"], []).append(item)

    for req in requirements:
        candidates = by_class.get(req["assetClass"], [])
        missing_props = []
        for mp in req["mandatoryProperties"]:
            key = mp["name"]
            if not any(key in c.get("properties", {}) and str(c["properties"].get(key)).strip() != "" for c in candidates):
                missing_props.append(key)

        status = "PASS" if len(missing_props) == 0 else "FAIL"
        results.append({"requirementId": req["id"], "status": status, "missing": missing_props})

    return results

Sınıflandırma ve kod listeleriyle semantiği tutarlı kılmak

Sınıflandırma, farklı disiplinlerin aynı varlığı aynı anlamla etiketlemesini sağlar. Kod listeleri; varlık türü, sistem, bölge, işlev gibi alanlarda kontrollü değer seti sunar. Böylece raporlama, analiz ve varlık yönetimi entegrasyonu sırasında anlamsal sürtünme azalır.

LOD ile LOI ayrımını gereksinimlerde açıkça belirtmek

Gereksinimleri yazarken LOD (geometrik ayrıntı) ile LOI (bilgi ayrıntısı) karıştığında yanlış beklentiler oluşur. ISO 19650 pratiklerinde, geometri ve bilgi olgunluğunu ayrı ayrı tarif etmek ve aşamaya göre artırmak daha sağlıklıdır. Böylece model “ağırlaşmadan” bilgi “zenginleşebilir”.

Yaygın hataları ve olgunluk adımlarını planlamak

Information Requirements dönüşümünde en sık görülen hata, gereksinimleri tek seferde ve aşırı ayrıntıyla yazmaktır. Bu yaklaşım hem maliyeti artırır hem de tedarikçi tarafında uygulanabilirliği düşürür. Olgunluk, iterasyonla gelir: önce kritik varlıklar ve zorunlu alanlar, sonra kalite eşikleri ve otomasyon, en son ölçütlerin kurumsal KPI’lara bağlanması.

İkinci yaygın hata, gereksinimleri CDE iş akışından kopuk tutmaktır. Gereksinimler CDE’de versiyonlanmıyor, teslimat paketine bağlanmıyor ve doğrulama raporu üretmiyorsa, ekipler yine e-posta ve toplantı döngüsüne geri döner. Bu nedenle süreç tasarımı, içerik kadar önemlidir.

Minimum uygulanabilir gereksinim setiyle başlamak

Başlangıç için “minimum uygulanabilir gereksinim seti” yaklaşımı işe yarar: kritik varlık sınıfları, benzersiz kimlik, temel sınıflandırma ve az sayıda zorunlu alan. İlk döngüde hedef, sürdürülebilir bir kontrol mekanizması kurmaktır; kapsam büyütme daha sonra gelir.

Kalite metriklerini raporla ve sürekli iyileştirerek yönetmek

Her teslimatta hata türleri, tamlık oranları, gecikmeler ve tekrar eden sorunlar raporlanmalıdır. Bu raporlar tedarikçi performansını ve iç süreç darboğazlarını görünür kılar. Süreç olgunlaştıkça doğrulama kuralları genişletilir, kabul eşikleri iyileştirilir ve otomasyon kapsamı büyütülür.

Bu yaklaşımı bir eğitim yol haritasına bağlamak isterseniz, kurum içi süreçlerinize uygun şablon ve örneklerle ilerlemek için ISO 19650 BIM eğitimi içeriğine göz atabilirsiniz. Doğru kurgu; gereksinimleri katmanlandırmak, CDE’de izlenebilir kılmak ve kabul kriterleriyle doğrulamaktır.