Gereksinim - Requirement

Gelen ürün geliştirme ve proses optimizasyonu , bir gereklilik belirli bir tasarım, ürün veya süreç amaçları karşılamak için gelen tek bir belgelenmiş fiziksel veya fonksiyonel ihtiyaçtır. Örneğin sistem mühendisliği , yazılım mühendisliği veya işletme mühendisliği dahil olmak üzere mühendislik tasarımında biçimsel anlamda yaygın olarak kullanılır . Bir müşteriye, organizasyona, dahili kullanıcıya veya diğer paydaşlara değer ve fayda sağlamak için bir sistemin gerekli (veya bazen istenen) işlevine, niteliğine, kabiliyetine, karakteristiğine veya kalitesine hitap edebilecek geniş bir kavramdır. Gereksinimler, farklı özgüllük düzeyleriyle gelebilir; örneğin, bir gereksinim spesifikasyonu veya gereksinim "spesifikasyonu" (genellikle kesin olarak "spesifikasyon / spesifikasyonlar olarak anılır, ancak aslında farklı spesifikasyon türleri vardır) açık, oldukça objektif / net (ve genellikle nicel) bir gereklilik (veya bazen, bir malzeme, tasarım, ürün veya hizmet tarafından karşılanması gereken bir dizi gereksinim.

Ürün geliştirmenin tasarım aşamalarında girdi olarak bir dizi gereksinim kullanılır . Gereksinimler ayrıca doğrulama sürecine önemli bir girdidir, çünkü testler belirli gereksinimlere kadar uzanmalıdır. Gereksinimler, belirli bir proje için hangi öğelerin ve işlevlerin gerekli olduğunu gösterir. Ne zaman yazılım geliştirme yinelemeli yöntemler veya çevik yöntemlerin kullanıldığı, sistem gereksinimleri aşamalı tasarımı ve uygulaması ile paralel olarak geliştirilmektedir. İle şelale modeli gereksinimleri tasarımı ve uygulaması öncesinde geliştirilmektedir.

Terimin kökenleri

Gereksinim terimi , yazılım mühendisliği topluluğunda en azından 1960'lardan beri kullanılmaktadır.

IIBA'dan ( BABOK ) Business Analysis Body of Knowledge® sürüm 2 Rehberi'ne göre , bir gereklilik şu şekildedir :

1. Paydaşın bir sorunu çözmek veya bir hedefe ulaşmak için ihtiyaç duyduğu bir koşul veya yetenek.
2. Bir sözleşmeyi, standardı, şartnameyi veya diğer resmi olarak dayatılmış belgeleri yerine getirmek için bir çözüm veya çözüm bileşeni tarafından karşılanması veya sahip olunması gereken bir koşul veya yetenek.
3. Bir koşulun veya yeteneğin (1) veya (2) 'de olduğu gibi belgelenmiş bir temsili.

Bu tanım, IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology'ye dayanmaktadır.

Ürün ve süreç gereksinimleri

Gereksinimlerin iki alanla ilgili olduğu söylenebilir:

• Ürün gereksinimleri , bir sistemin veya ürünün özelliklerini belirler.
• Süreç gereksinimleri , gelişmekte olan kuruluş tarafından gerçekleştirilecek etkinlikleri belirler. Örneğin, süreç gereksinimleri, takip edilmesi gereken metodolojileri ve kuruluşun uyması gereken kısıtlamaları belirtebilir.

Ürün ve süreç gereksinimleri yakından bağlantılıdır; bir ürün gereksiniminin bir süreç gereksinimini desteklemek için gereken otomasyonu belirlediği söylenebilirken, bir süreç gerekliliğinin bir ürün gereksinimini desteklemek için gereken etkinlikleri belirlediği söylenebilir. Örneğin, maksimum bir satış fiyatı gereksinimini (bir ürün gereksinimi) elde etmeye yardımcı olmak için bir maksimum geliştirme maliyeti gereksinimi (bir süreç gereksinimi) empoze edilebilir; Ürünün bakımının yapılabilmesine yönelik bir gereklilik (bir ürün gereksinimi), genellikle belirli geliştirme stillerini (örneğin, nesneye yönelik programlama ), stil kılavuzlarını veya bir gözden geçirme / inceleme sürecini (süreç gereksinimleri) izlemek için gereksinimler empoze ederek ele alınır .

Gereksinim türleri

Gereksinimler tipik olarak, bir geliştirme ilerlemesinde farklı aşamalarda üretilen türlere göre sınıflandırılır ve taksonomi, kullanılan genel modele bağlıdır. Örneğin, aşağıdaki şema ile icat edildi İş Analizi Uluslararası Enstitüsü onların içinde Bilginin İş Analizi Gövde (ayrıca bkz FURPS ve gereksinimleri Türleri ).

Mimari gereksinimler

Mimari gereksinimler, sistem yapısı ve sistem davranışının , yani bir sistemin sistem mimarisinin gerekli entegrasyonunu tanımlayarak ne yapılması gerektiğini açıklar .

Gelen yazılım mühendisliği , bunlar denir mimari açıdan önemli gereksinimleri bir yazılım sisteminin üzerinde ölçülebilir bir etkiye sahip olan gereksinimleri olarak tanımlanır, mimarlık .

İş gereksinimleri

Bir kuruluşun amaçlarının, hedeflerinin veya ihtiyaçlarının üst düzey beyanları. Genellikle bir kuruluşun gerçekleştirmek istediği fırsatları veya çözmek istedikleri sorunları tanımlarlar. Genellikle bir iş vakasında belirtilir .

Kullanıcı (paydaş) gereksinimleri

Belirli bir paydaşın veya bir grup paydaşın ihtiyaçlarının orta düzey beyanları. Genellikle birisinin amaçlanan çözümle nasıl etkileşim kurmak istediğini açıklarlar. Genellikle üst düzey iş gereksinimleri ile daha ayrıntılı çözüm gereksinimleri arasında bir orta nokta görevi görür.

İşlevsel (çözüm) gereksinimler

Genellikle çözümün ihtiyaç duyacağı yeteneklerin, davranışların ve bilgilerin ayrıntılı ifadeleri. Örnekler arasında metin biçimlendirme, bir sayının hesaplanması, bir sinyalin modüle edilmesi yer alır. Bazen yetenekler olarak da bilinirler .

Hizmet kalitesi (işlevsel olmayan) gereksinimleri

Çözümün etkili kalması gereken koşulların, çözümün sahip olması gereken niteliklerin veya içinde işlemesi gereken kısıtlamaların genellikle ayrıntılı ifadeleri. Örnekler şunları içerir: güvenilirlik, test edilebilirlik, sürdürülebilirlik, kullanılabilirlik. Bunlar aynı zamanda özellikler , kısıtlamalar veya hastalıklar olarak da bilinir .

Uygulama (geçiş) gereksinimleri

Genellikle, yalnızca işletmenin mevcut durumundan istenen gelecek durumuna geçişi sağlamak için gereken ayrıntılı yetenek veya davranış beyanları gerekir, ancak bundan sonra artık gerekli olmayacaktır. Örnekler arasında işe alım, rol değişiklikleri, eğitim, verilerin bir sistemden diğerine taşınması yer alır.

Düzenleme gereksinimleri

Yasalar (Federal, Eyalet, Belediye veya Bölgesel), sözleşmeler (şartlar ve koşullar) veya politikalar (şirket, departman veya proje düzeyi) tarafından tanımlanan gereksinimler .

İyi gereksinimlerin özellikleri

İyi gereksinimlerin özellikleri, farklı yazarlar tarafından çeşitli şekillerde ifade edilir; her yazar genellikle genel tartışmalarına veya ele alınan özel teknoloji alanına en uygun özellikleri vurgular. Bununla birlikte, aşağıdaki özellikler genel olarak kabul edilmektedir.

Gereksinimlerin kalitesine katkıda bulunan dikkate alınması gereken daha birçok özellik vardır. Gereksinimler veri bütünlüğü kurallarına tabi ise (örneğin), doğruluk / doğruluk ve geçerlilik / yetkilendirme de değerli özelliklerdir. İzlenebilirlik , gereksinim setinin ihtiyacı karşıladığını doğrular (daha fazla ve gerekenden az olamaz).

Yukarıdakilere bazıları Harici Olarak Gözlemlenebilir'i ekler, yani gereksinim, ürünün harici olarak gözlemlenebilen veya kullanıcı tarafından deneyimlenen bir özelliğini belirtir. Bu tür savunucular, iç mimari, tasarım, uygulama veya test kararlarını belirleyen gereksinimlerin muhtemelen kısıtlamalar olduğunu ve Gereksinimler belgesinin Kısıtlamalar bölümünde açıkça ifade edilmesi gerektiğini savunurlar. Karşıt görüş, bu perspektifin iki noktada başarısız olduğudur. Birincisi, bakış açısı, kullanıcı deneyiminin kullanıcı tarafından algılanamayan gereksinimler tarafından desteklenebileceğini kabul etmemektedir. Örneğin , kullanıcıya coğrafi kodlu bilgi sunma gereksinimi, harici bir üçüncü taraf iş ortağıyla bir arayüz gereksinimi ile desteklenebilir. Arayüz kullanıcı tarafından algılanamaz, ancak arayüz aracılığıyla elde edilen bilgilerin sunumu kesinlikle olmaz. İkincisi, bir kısıt tasarım alternatiflerini sınırlarken, bir gereksinim tasarım özelliklerini belirtir. Örneğe devam etmek için, bir web hizmeti arabirimi seçme gereksinimi, kısıtlayıcı tasarım alternatiflerinden Tek Oturum Açma mimarisiyle uyumlu yöntemlere göre farklıdır.

Doğrulama

Tüm gereksinimler doğrulanabilir olmalıdır. En yaygın yöntem testtir. Durum böyle değilse, bunun yerine başka bir doğrulama yöntemi kullanılmalıdır (örneğin analiz, gösteri, inceleme veya tasarımın gözden geçirilmesi).

Yapıları gereği belirli gereksinimler doğrulanabilir değildir. Bunlar, sistemin hiçbir zaman veya her zaman belirli bir özelliği sergilememesi gerektiğini söyleyen gereksinimleri içerir . Bu gereksinimlerin uygun şekilde test edilmesi, sonsuz bir test döngüsü gerektirecektir. Doğrulanabilmesi için bu tür gereksinimlerin yeniden yazılması gerekir. Yukarıda belirtildiği gibi, tüm gereksinimler doğrulanabilir olmalıdır.

Yazılım düzeyinde doğrulanamayan işlevsel olmayan gereksinimler, yine de müşteri niyetinin bir belgesi olarak saklanmalıdır. Ancak, bunları karşılamanın pratik bir yolu olduğu belirlenen süreç gereksinimlerine kadar izlenebilirler. Örneğin, arka kapılardan bağımsız olmak için işlevsel olmayan bir gereksinim, çift ​​programlamayı kullanmak için bir işlem gereksinimi ile değiştirilerek karşılanabilir . İşlevsel olmayan diğer gereksinimler, diğer sistem bileşenlerine kadar izlenecek ve bu düzeyde doğrulanacaktır. Örneğin, sistem güvenilirliği genellikle sistem düzeyinde analizle doğrulanır. Aviyonik yazılımı , karmaşık güvenlik gereksinimleri ile DO-178B geliştirme sürecini takip etmelidir .

Sistem veya yazılım gereksinimlerinin türetilmesine yol açan faaliyetler. Gereksinim mühendisliği, bir fizibilite çalışması veya projenin kavramsal bir analiz aşamasını ve gereksinimlerin ortaya çıkarılmasını ( paydaşların ihtiyaçlarını toplama, anlama, gözden geçirme ve ifade etme ) ve gereksinim analizi , analiz (tutarlılık ve eksiksizliğin kontrol edilmesi), şartname (dokümantasyon) içerebilir . gereksinimleri) ve doğrulama (belirtilen gereksinimlerin doğru olduğundan emin olunması).

Gereksinimler belirsizlik, eksiklik ve tutarsızlık konularına eğilimlidir. Titiz inceleme gibi tekniklerin bu sorunların üstesinden gelmeye yardımcı olduğu gösterilmiştir. Gereksinimler aşamasında çözülebilen belirsizlikler, eksiklikler ve tutarsızlıklar tipik olarak, aynı sorunların ürün geliştirmenin sonraki aşamalarında bulunduğunda olduğundan daha az düzeltilmesi gereken siparişlerin maliyetini düşürür. Gereksinim analizi, bu sorunları ele almaya çalışır.

Çok belirsiz olan gereksinimler ile çok ayrıntılı olan gereksinimler arasında dikkate alınması gereken bir mühendislik değiş tokuşu vardır.

1. üretmek uzun zaman alır - bazen tamamlandıktan sonra modası geçmiş olma noktasına gelir
2. mevcut uygulama seçeneklerini sınırlandırın
3. üretmek pahalı

Çevik yaklaşımlar , gereksinimleri yüksek düzeyde temel alarak ve ayrıntıları tam zamanında veya son sorumlu an temelinde detaylandırarak bu sorunların üstesinden gelmenin bir yolu olarak gelişti .

Belgeleme gereksinimleri

Gereksinimler genellikle farklı paydaşlar arasında bir iletişim aracı olarak yazılır. Bu, gereksinimlerin hem normal kullanıcılar hem de geliştiriciler için anlaşılmasının kolay olması gerektiği anlamına gelir. Bir gereksinimi belgelemenin yaygın bir yolu, sistemin ne yapması gerektiğini belirlemektir. Örnek: 'Yüklenici ürünü en geç xyz tarihinden önce teslim etmelidir.' Diğer yöntemler, kullanım durumlarını ve kullanıcı hikayelerini içerir .

Gereksinimlerdeki değişiklikler

Gereksinimler genellikle zamanla değişir. Tanımlandıktan ve onaylandıktan sonra, gereksinimler değişiklik kontrolü altına alınmalıdır . Birçok proje için gereksinimler, sistem tamamlanmadan önce değiştirilir. Bu kısmen bilgisayar yazılımının karmaşıklığından ve kullanıcıların ne istediklerini görmeden önce bilmemelerinden kaynaklanmaktadır. Gereksinimlerin bu özelliği, gereksinim yönetimi çalışmalarına ve uygulamalarına yol açmıştır .

Sorunlar

Rekabetçi standartlar

Gereksinimlerin ne olduğu ve bunların nasıl yönetilip kullanılması gerektiğine dair birbiriyle yarışan birkaç görüş vardır. Sektördeki önde gelen iki kuruluş IEEE ve IIBA'dır. Bu grupların her ikisi de bir gereksinimin ne olduğuna dair farklı ama benzer tanımlara sahiptir.

Yazılım gereksinimlerinin gerekliliği ve etkilerine ilişkin anlaşmazlıklar

Pek çok proje, gereksinimler konusunda çok az anlaşma ile veya hiç anlaşma olmadan başarılı olmuştur. Ayrıca bazı kanıtlar, gereksinimlerin belirlenmesinin yaratıcılığı ve tasarım performansını azaltabileceğini gösterir. Gereksinimler yaratıcılığı ve tasarımı engeller çünkü tasarımcılar sağlanan bilgilerle aşırı derecede meşgul olurlar. Daha genel olarak, bazı araştırmalar, yazılım gereksinimlerinin, gerçek gereksinimlerin bulunmadığı durumlarda tasarım kararlarının gereksinim olarak yanlış sunulmasının yarattığı bir yanılsama olduğunu ileri sürmektedir .

Bu arada, çevik yazılım geliştirme metodolojilerinin çoğu , hareketli bir hedef olarak gördükleri yazılım gereksinimlerini önceden titizlikle tanımlama ihtiyacını sorguluyor. Bunun yerine, aşırı programlama , örneğin, kullanıcı hikayelerini (sistemin ne yapması gerektiğinin bir yönünü açıklayan bir dizin kartına uyan kısa özetler) kullanarak gereksinimleri gayri resmi olarak tanımlar ve geliştiricinin doğrudan müşteriden açıklama isteme görevi olduğunu düşünür. Çevik metodolojiler, bir dizi otomatik kabul testinde gereksinimleri yakalamaya çalışır .

Gereksinimler sürünme

Kapsam kayması , zaman içinde değişen gereksinimlerden kaynaklanabilir. Gelen Gereksinimler yönetim gereksinimleri değişiklik izin verilir, ancak yeterince izlenen veya ek gözetimi daraltma veya maliyet ve potansiyel programı başarısızlığı olarak işlenmez adımlar (daha sonra kullanıcı gereksinimleri iş hedeflerine) önceki değilse, o zaman şartlar değişiklikler yaşanma olasılığı kolay ve vardır. Gereksinim değişikliklerinin, geliştiricilerin iş üretebildiğinden daha hızlı gerçekleşmesi ve sonuç olarak geriye gitme çabası kolaydır .

Birden çok gereksinim sınıflandırması

Hangi çerçeve altında çalıştığına bağlı olarak gereksinimler için birden fazla sınıflandırma vardır. (Örneğin, IEEE, IIBA veya US DoD yaklaşımlarının belirtilen standartları). Farklı mekanlarda farklı dil ve süreçler veya gündelik konuşma, kafa karışıklığına ve istenen süreçten sapmaya neden olabilir.

Süreç yolsuzlukları

İnsanlar tarafından yürütülen bir süreç, yönetimde insan kusurlarına tabidir; burada kolaylık veya arzu veya siyaset, sürecin tam anlamıyla yıkılmasına veya sürecin ilerlemesi beklenen yoldan sapmalara yol açabilir. Örnekler şunları içerir:

• Hiçbir titizliğin olmadığı süreç dikkate alınmaz - İşleten kuruluşun çok az bağımsızlığına veya gücüne sahip olması veya kayıtlarda güvenilir ve şeffaf olmaması gibi istisnalar veya değişiklikler yaygındır, bu genel sürecin göz ardı edilmesine yol açabilir.
• Yeniden yapmak isteyen yeni oyuncular - örneğin, yeni insanların güçlerini veya değer iddialarını göstermek için seleflerinin çalışmalarını değiştirmek istemeye yönelik doğal eğilimleri, örneğin iş hedefleri de dahil olmak üzere önceki CEO'nun planlamasını değiştirmek isteyen yeni bir CEO gibi. halihazırda geliştirilmekte olan bir şey (bir yazılım çözümü gibi) veya yeni oluşturulmuş bir ofis, bir projenin mevcut gelişimi için nesnelerdir çünkü bunlar, kullanıcı gereksinimleri oluşturulduğunda mevcut değildir, bu nedenle projeyi geri izlemek ve yeniden temel almak için bir çabaya başlarlar.
• Çizgilerin dışına renklendirme - örneğin, daha fazla kontrol isteyen kullanıcılar, yalnızca "kullanıcı gereksinimi" veya öncelik düzeyinin gereksinim yönetimi tanımını karşılayan şeyleri girmekle kalmaz, aynı zamanda kullanıcı gereksinimleri olarak tasarım ayrıntılarını veya tercih edilen satıcı özelliklerini veya ofislerinin söylediği her şeyi en yüksek olarak ekler. olası öncelik.
• Geç ortaya çıkmak - örneğin, geliştirmeden önce gereksinimleri ortaya çıkarmak için çok az çaba sarf etmek veya hiç çaba göstermemek. Bunun nedeni, bireysel katılımdan bağımsız olarak aynı faydayı elde edeceklerini veya sadece test aşamasında ve bir sonraki dönüşte talep ekleyebilmelerinin bir anlamı olmadığı veya iş sonrası bekleyerek her zaman doğru olma tercihlerinden kaynaklanıyor olabilir. eleştiri.

ABD Savunma Bakanlığı sürecinde, gereksinim konularının bazı tarihsel örnekleri şunlardır:

• Pentagon Savaşları'nda tasvir edilen gündelik gereksinimler hareketinin M-2 Bradley sorunları ;
• Fighter mafyasının hafif avcı konseptinden F-16 büyümesi, rekabeti sabote etmeye çalışan F-15 programına veya hafif ve düşük maliyetli olma konseptini aşındıran yerel arzuları yerine getiren bireysel ofislere atfedildi.
• coşku ca. 1998 'Net-Ready', Net-Ready ofisinden Anahtar Performans Parametresi olarak görevini yerine getirdi, ofis dışında gereksinimleri belirleme süreci ve bu ofisin önceden tanımlanmış süreci, KPP'nin ne olduğuna dair tanımları veya bazı çabalarla tutarlı değil. uygun olmayabilir veya "Net-Ready" yi neyin oluşturduğunu tanımlayamayabilir.

Ayrıca bakınız

• İş gereksinimleri
• Yazılım gereksinimleri
• Gereksinim mühendisliği
• Gereksinimlerin analizi
• Gereksinimlerin ortaya çıkarılması
• İhtiyaç Yönetimi
• Gereksinim önceliklendirme
• Gereksinimler izlenebilirliği
• Şartname (teknik standart)
• Shall and will - ifade etme
• MoSCoW Yöntemi - önceliklendirme tekniği
• Kullanıcı hikayesi
• Kullanım Örneği

Referanslar

Dış bağlantılar

• Sistem Gereksinimlerini Keşfetme