Yazılım Mühendisliğinde Gereksinimler Neden Önemlidir?

Bu makalede, yazılım geliştirmede gereksinimlerin önemini ve bir uygulama oluştururken gereksinim aşamasını ihmal etmenin neden akıllıca bir fikir olmadığını ele alıyoruz.

" Kapsamlı belgeler üzerinde çalışan yazılım. " Bu, Çevik Manifesto'nun bir parçasıdır.

Yüzeyde, bu ifade, gereksinimlerin önemsiz olduğunu ve zamana layık olmadığını ima ediyor gibi görünebilir. Bazı geliştiriciler ve müşterileri uygun belgelerden vazgeçer. Ama bu bir hata.

Yazılım geliştirme açısından gereksinimlerin ne olduğuna dair küçük bir açıklama ile başlayalım.

Uygulama geliştirmede gereksinimler nelerdir?

Yazılım geliştirmeye uygulandığında gereksinimlerin tanımı önemli ölçüde değişmez. Gereksinimler, bir ürünün hangi özellikleri içermesi gerektiğini ve bu özelliklerin nasıl çalışması gerektiğini belirtir. Önemli olan onlara nasıl yaklaştığınızdır.

Gereksinimlerin toplanması ve analiz edilmesi, Agile ve Waterfall metodolojilerinde benzer şekilde yazılım geliştirme sürecinin ilk aşamalarından biridir. Fikir doğrulama aşamasının gereksinimler aşamasında, nihai ürünün tam olarak ne ve nasıl yapması gerektiği konusunda müşteri ve geliştirici arasında bir anlaşmaya varılmalıdır. Uygulama geliştirmedeki gereksinimler genellikle oldukça ayrıntılıdır.

Yazılım gereksinimleri nasıl tanımlanır

Yazılım geliştirmede çeşitli gereksinim türleri olabilir.

İş gereksinimleri

Müşterinin uygulamaya neden ihtiyacı var? Bir bakışta, bu bilgiler gereksiz ve hatta gereksiz görünebilir. Sonuçta, bir uygulama geliştirmeniz için size ödeme yapmak isteyen bir müşteriniz var. Neden onların nedenlerini önemsemelisiniz?

Eh, yaptığınız işle gurur duyuyorsanız ve kaliteli ürünler üretmeye çalışıyorsanız, neyin ve nasıl olduğu kadar nedenlerini de önemsemelisiniz.

İş gereksinimlerinin önemi , nihai hedef için bir vizyon sağlamalarıdır. Görünürdeki hedefle, geliştiriciler öncelikleri belirleyebilir. Bu hedeflere ulaşmak için daha iyi çözümler sunmak için uzmanlıklarını da kullanabilirler. Çoğu şirkette iş analizinin geliştirme sürecine dahil edilmesinin bir nedeni var.

Açık iş gereksinimleri olmadan, kötü kararlar alınabilir. Geliştirmeyi yavaşlatacak, son teslim tarihlerini bozacak ve ek geliştirme aşamaları ile sonuçlanacak kararlar.

Yazılım gereksinimleri

İki tür gereksinim vardır: işlevsel ve işlevsel olmayan. Basit bir ifadeyle, ayrım aşağıdaki gibidir:

İşlevsel gereksinimler hangi gereksinimlerdir - Bu sistem ne yapmak için tasarlanmıştır? Adından da anlaşılacağı gibi, yazılımın işlevselliğini tanımlarlar.

İşlevsel olmayan gereksinimler nasıl gereksinimleridir — Bu sistem yapmak için tasarlandığı şeyi nasıl yapacak? Bu gereksinimler, her özelliğin hangi koşullar altında nasıl davranması gerektiğini, hangi sınırlamaların olması gerektiğini vb. açıklar.

İkisi el ele gider. İşlevsel olmayan gereksinimler, işlevsel gereksinimleri tamamlar ve tanımlar. Örneğin, bir mesajlaşma uygulaması yaptığımızı düşünelim.

Bu durumda ana işlevsel gereksinimler şöyle olacaktır:

1. Uygulama mesaj gönderebilmelidir.
2. Uygulama, dosya ve medya aktarımını desteklemelidir.
3. Vesaire.

Bunlar oldukça basittir ve işlevsel gereksinimlerin neden önemli olduğunu anlamak kolaydır: işlevselliği ana hatlarıyla belirtirler. Bu örnekte, işlevsel olmayan gereksinimler aşağıdaki gibi olabilir :

1. Hizmet, tüm büyük tarayıcılarda tam işlevsellik sunmalıdır: Microsoft Edge, Google Chrome (en son iki sürüm), Mozilla Firefox (son iki sürüm), Opera, Safari (en son sürüm).
2. Mobil düzenler desteklenmelidir.
3. Vesaire.

Gördüğün gibi, işlevsel gereksinimler, temelde sisteme dahil edilmesi gereken bir işlevsellik listesidir. . Öte yandan, işlevsel olmayan gereksinimler özeldir. Geliştirme ve test koşullarını tanımlamak için gereklidirler.

Yinelemeli Çevik sürecin , geliştirmenin herhangi bir aşamasında değişiklik yapma olasılığını gerektirdiği doğrudur, ancak bu, yukarıda belirtilen gereksinimlerin tümü anlamına gelmez. Sadece onları esnek hale getirmeniz gerekiyor.

Kesin parametreler belirtilmeden, bir özelliğin tam olarak olması gerektiği gibi tasarlanıp tasarlanmadığını anlamak imkansızdır.

Gereksinimler kapsamlı bir şekilde analiz edilmeli ve belgelenmelidir. Niye ya? Çünkü aksi takdirde pek çok şey ters gidebilir.

Demokles'in belgelenmemiş gereksinimlerin kılıcı

Yazılım gereksinimlerinin önemi en iyi kalite güvence uzmanları tarafından anlaşılır. Proje gereksinimleri doğru bir şekilde belirlenmediğinde en büyük darbeyi QA'lar alır. Ne yapması ve nasıl yapması gerektiğine dair net yönergeler olmadan yazılımın doğru şekilde uygulanıp uygulanmadığını belirlemeye çalıştığınızı hayal edin. Bu tam bir delilik.

Ancak bu sorun yalnızca test kullanıcılarını etkilemez. Resmi bir spesifikasyonun olmaması şu anlama gelir:

• Bitmiş bir ürünü veya hatta özelliği neyin oluşturduğuna dair net bir anlayış yoktur.
• Müşteri, geliştirmenin sonunda ne bekleyeceğini ve ne için ödeme yaptığını bilmiyor.
• Geliştiriciler, söylenenlere ve kendilerinin bunu nasıl anladıklarına bağlı olarak özelliklerin özelliklerini bulmak zorunda kalıyor.
• Böcekler. Her yerdeler.

Belgelenmemiş gereksinimler, her tarafta yanlış iletişime yol açar. Bir müşterinin ve bir geliştiricinin aynı terimleri farklı şekilde anlaması hiç de nadir değildir. Özellikle, müşterinin işiyle yakından tanışmayan bir dış kaynak geliştirme şirketinden bahsediyorsak.

İletişimsizlik, sırayla, sürekli yeniden çalışma, değişiklikler ve hata düzeltmeleri için düz bir yol açar. Belgelenmiş gereksinimler olmadan her şeyin planlandığı gibi gitme olasılığı var, ancak zayıf. Genellikle bu zincir, kesintiye uğramış teslim tarihleri ​​ve çatıdan geçen maliyetlerle sona erer.

Sorunsuz proje geliştirmeyi sağlamak için, ürünün tüm bölümleri ve geliştirme süreci, her ekip üyesi tarafından aynı şekilde anlaşılmalıdır. Geliştiricilerin ürünün her özelliğini tam olarak müşterinin gördüğü gibi görmelerini sağlamak için bir yazılım gereksinimleri belirtimi (SRS) yapılır.

Şeytan ayrıntılarda gizlidir: İyi bir yazılım gereksinimleri belirtimi yapan nedir?

Şimdi, gerçek yazılım gereksinimleri spesifikasyonları son derece ayrıntılı olabilir veya sadece özelliklerin bir taslağı olabilir. Ayrıntı düzeyi bir dizi faktöre bağlıdır.

Yüksek kalite gereksinimleri , projeye dahil olan herkes tarafından kolayca anlaşılır. Bu, teknik konularda bilgili olan veya olmayan müşteriyi içerir. Bazı şirketler son derece teknik ve ayrıntılı bir gereksinim listesi talep ederken, diğerleri sıradan olmayan terimlerle gereksinimleri tercih ediyor.

Belgeleriniz ne kadar teknolojiyle dolu olursa olsun, yazılım gereksinimlerini yönetmek için genel kurallar vardır. Hatta resmi bir standart bile var: IEEE Std 830-1998, "Yazılım Gereksinimleri Spesifikasyonları için Önerilen Uygulama." Standarda göre iyi bir SRS'nin olması gerekenler:

• doğru . Bu kolay. SRS'nin doğruluğu, müşteri ve geliştirici tarafından sahip oldukları anlaşmaya göre onaylanır. SRS, teknik şartnamelere ve diğer tüm geçerli proje belgelerine uygun olmalıdır.

• açık . Bir SRS'nin ana amaçlarından biri, yanlış iletişimi ortadan kaldırmaktır. Bu nedenle, her gereksinim belirtimi, yalnızca bir olası yoruma sahip olacak şekilde yazılmalıdır. Bir SRS'nin sözlük içermesi alışılmadık bir durum değildir.

• Tamamlayın . Uygulama ne kadar karmaşıksa, SRS'nin o kadar ayrıntılı olması gerekir. Eksiksiz bir SRS, performans gereksinimlerinden işlevselliğe kadar her tarafı kapsar. Ayrıca tasarıma belirli sınırlar koyar. Ancak hiçbir zaman kesin bir tasarım belirtmez. Yalnızca parametreler sunar.

• tutarlı . İç tutarlılık, bir SRS'deki hiçbir ifadenin aynı SRS'deki diğer ifadelerle çelişmediği anlamına gelir. Bu, bir sözlük eklemek için başka bir nedendir - böylece belgedeki herhangi bir nesne, süreç ve belirtim kesin bir terimle belirtilir.

• Önem ve/veya istikrar açısından derecelendirilmiştir . Çoğu durumda, sahip olunması gereken gereksinimler ve olması gereken gereksinimler vardır. Yazılım gereksinimleri spesifikasyonlarının her iki türü de açıkça etiketlemesi önemlidir. Bu, proje için adım adım bir plan oluştururken geliştiricilere ve proje yöneticilerine yardımcı olacaktır.

• Doğrulanabilir . SRS'ye dahil ettiğiniz her gereksinimi test etmenin bir yolu olmalıdır. Doğrulanabilir olarak kabul edilmek için gereksinimlerin ölçülebilir ve somut kavramlar içermesi gerekir.

• değiştirilebilir . Bu, SRS yapısını ifade eder. Değişiklikleri uygulamanız gerektiğinde proje iş akışını kesintiye uğratmamak için SRS'nin açık ve kolay değiştirilebilir olması ve gereksinimlerin tekrarlanmaması gerekir.

• izlenebilir . SRS'de belirtilen her gereksinimin kaynağını belirlemek kolay olmalıdır.

Bunlar tavsiyelerdir . Gerçekte şirketler projeye, müşteriye ve ekibe bağlı olarak bu noktalardan bazılarından vazgeçebilir. Ama biraz yol göstermek her zaman iyidir.

Gereksinimler, iOS ve Android uygulama geliştirme veya web geliştirme konusunda uzman olsanız da kullanışlıdır. Genel amaçlı belgelerdir. Ve nasıl göründükleri genellikle geliştiricilere ve müşterilerine bağlıdır.

Bir SRS'nin ilgili tüm taraflar için anlaşılması kolay olması gerektiğinden, bunları tasarlamanın en iyi yolu da tartışmalıdır. Bazıları tabloları, bazıları listeleri tercih eder. Spesifikasyonlarını görsel olarak veri akış diyagramları ve çizelgeleri olarak tercih eden geliştiriciler var. Bir gereksinim belirtimi belgesi oluşturmanın tek bir doğru yolu yoktur.

Çözüm

Yazılım gereksinimleri işe yaradığında en yaygın noktalar şunlardır:

• Hedefi anlamak
• Geliştirme maliyetlerini tahmin etme
• Kapsamlı bir program oluşturma
• Öncelikleri belirlemek

Gereksinimlerin belgelenip belgelenmeyeceği, her geliştiricinin kendisi için karar verdiği bir şeydir. Ve gereksinimlerin değeri projenin ölçeğine göre değişir. Mind Studios'ta her şeyin düzenli olmasını tercih ediyoruz, bu nedenle tüm gereksinimleri belgeliyoruz. Bunu nasıl yaptığımızla ilgileniyorsanız veya genel olarak gereksinimlerin değeri hakkında sorularınız varsa, iletişim formumuz aracılığıyla bize ulaşın .