Vizör Çözümleri


Destek
Kaydol
Giriş Yap
Ücretsiz Deneme başlat

Yazma Gereksinimleri için Yapılması ve Yapılmaması Gerekenler

Yazma Gereksinimleri için Yapılması ve Yapılmaması Gerekenler

İçindekiler

Çoğu insan gibiyseniz, muhtemelen yazma gereksinimlerinden hoşlanmıyorsunuzdur. Bu dünyadaki en heyecan verici şey değil ama ürün geliştirmenin kritik bir parçası. Daha iyi bir gereksinimler belgesi, geliştirici ve ürün paydaşları arasındaki net iletişim sayesinde kuruluşunuza bir servet kazandırabilir. Bu da, daha fazla şeffaflık, daha az yeniden çalışma ve geliştirilmiş üretkenlik dahil olmak üzere kuruluş genelinde yansıtılır.

Her kuruluşun farklı gereksinimleri ve metodolojileri olsa da, gereksinimleri yazmanın temelleri aynı kalır. Bu yazıda, gereksinim yazma becerilerinizi geliştirmenize ve net ve net Gereksinim Belirtimleri yazmanıza yardımcı olabilecek birkaç ipucu paylaşacağız.

Gereksinim Belirtimi nedir?

Belgeleme olarak da bilinen gereksinim belirtimi, tüm sistem ve kullanıcı gereksinimlerinin bir belge biçiminde not alınması işlemidir. Bu gereksinimler açık, eksiksiz, kapsamlı ve tutarlı olmalıdır. 

Yakalama etkinliği sırasında, çeşitli kaynaklardan tüm gereksinimleri topluyoruz. Analiz ve müzakere faaliyetleri sırasında bu gereksinimleri analiz eder ve anlarız. Şimdi, bu gereksinimleri açıklayan resmi bir belge hazırlamamız gerekiyor. Gereksinim belirtimi budur. Kesin olmak gerekirse, tüm kullanıcı ve sistem ihtiyaçlarının ve kısıtlamalarının açık ve doğru bir şekilde belgelenmesi sürecidir.

Gereksinim Yönetimindeki "En İyi Uygulamalar" ne anlama geliyor?

Herkesin “en iyi uygulamalar” konusunda eğitim istemekten bahsetmesi bana çok ilginç geliyor. Bu terim genellikle aynı zamanda sağlayabileceğimiz danışmanlık türünü tanımlamak için de kullanılır. Bu gerçekten ne anlama geliyor? Hepimizin en iyi uygulamaların bireyleri eğitmek için temel olabileceği efsanesini beslediğimize inanıyorum. En iyi uygulamalar eğitilmez, deneyimlenir.

Doğaya yönelik en iyi uygulama yaklaşımını karşılaştırırsak, hayatta kalanın yalnızca en güçlü değil, aynı zamanda en üretken tür olduğunu biliyoruz. Bir kuruluştaki süreçleri değiştirmenin bu kadar zor olmasının nedenlerinden biri de budur. Bunu bir an için düşünün. En güçlü ve en üretken olan, muhtemelen kuruluşunuzdaki hemen hemen her gruptaki bireylerin çoğunluğunu tanımlar. Bunu Sistem Mühendisliği alanında defalarca gördüm. En güçlü ve en üretken mühendisler genellikle işlerini uzun yıllardır yapıyorlar ve bu işi yapmak için belirli bir yöntemleri var. Onlardan yeni teknikler ve araçlar denemelerini istemek çoğu zaman beyhudedir çünkü bunun zaten yapmakta oldukları harika işi nasıl iyileştireceğini bilmezler. Onlara en iyi uygulama yaklaşımını dayatmaya devam edersek uygulamaları hayatta kalacak.

Gereksinimleri Yazarken Karşılaşılan Zorluklar

İnsanların gereksinimleri yazarken karşılaştıkları çeşitli zorluklar vardır.

Kötü Evrak İşleri – Bazı kuruluşlarda, süreçlerin dokümantasyonu ya yoktur ya da eşit düzeyde değildir. Bu durumda, gereksinimlerin toplanması iki aşamalı bir süreç haline gelir: önce mevcut süreç üzerinde tersine mühendislik yapılması ve ardından iyileştirme ve optimizasyon gerektiren alanların belirlenmesi. Gereksinimlerin ayrıntılı ve doğru olduğunu doğrulamak için, kilit paydaşları ve konu uzmanlarını doğrudan onlarla ilişki kurarak belirlemek çok önemlidir. İş süreci haritaları çizmek ve iş akışlarını görselleştirmek, bunu yapmanın iki mükemmel yoludur. Bu, yanlış varsayımların ortadan kaldırılmasına yardımcı olurken aynı zamanda tam bir resim sağlar. Süreç haritalarının çizilmesi ve süreçlerin görüntülenmesi bu amaç için iki yararlı yaklaşımdır.

Çelişen Gereksinimler – Paydaşların iş hedefleri için farklı öncelikleri olduğunda, bu durum birbiriyle çelişen gereksinimlere yol açar. Bu gibi durumlarda, bir iş analistinin sorumluluğu, tüm gereksinimleri ayrıntılı olarak belgelemek, hangi taleplerin birbirine zıt olduğunu belirlemek ve paydaşlara neyin öncelikli olduğuna karar verme fırsatı vermektir.

Paydaşların görüşlerini dinlemeden karar veremezsiniz ve bir iş analisti olarak neye öncelik verilmesi gerektiği konusunda bazı fikirleriniz olabilir. Paydaşların bakış açısını duymak hala çok önemlidir. Bir anket oluşturmak, paydaşların çoğunluğu için neyin en önemli olduğu konusunda netlik elde etmenin yöntemlerinden biri olabilir.

Kullanıcı Girişinin Bulunamaması – Birkaç neden, son kullanıcıların bulunmamasına katkıda bulunabilir ve her biri kendi çözümünü gerektirir. Örneğin, bazen son kullanıcılar günlük işleriyle o kadar meşgul olurlar ki gereksinim toplama etkinliklerine katılmak istemezler.

Bu gibi durumlarda, bir iş analistinin yapabileceği en iyi şey, etkileşimlerin sayısını ve süresini sınırlamaktır. Toplantıdan önce mümkün olduğunca fazla araştırma yapmak tartışmayı daha organize ve bilgilendirici hale getirmeye yardımcı olacaktır. Bu neredeyse gereksinimlerin toplanmasını gereksinim doğrulama oturumlarına dönüştürmek gibidir. odak gruplarının tanımlanması ve her grup için en uygun son kullanıcıların belirlenmesi

Deneyim Yerine Arayüze Odaklanmak – Birçok paydaş ve son kullanıcı, yeni çözümün nasıl ortaya çıkması gerektiğine dair net bir vizyona sahiptir, ancak neyi başarması gerektiğini bilmiyorlar. Herhangi bir sistemin kullanıcı arayüzü çok önemlidir, ancak işlevselliği tanımlamamalı veya engellememelidir.

İş analistleri, belgelerinde tasarım ve işlevsel gereksinimleri ayrı tutmayı her zaman hatırlamalıdır. Tasarım taslakları yerine diyagramlar, kullanıcı hikayeleri veya düşük maliyetli prototipler gibi daha genel araçları kullanarak, gereksinim toplamanın işlevsel yönlerine odaklanmayı sürdürebilirler.

Paydaş Girdileri – Paydaşlar veya son kullanıcılar, tasarımcılara sistemin ne yapması gerektiği yerine sistemin nasıl çalışması gerektiğini söylemeye çalıştığında, yetersiz tasarımlara yol açabilir. Bunu engellemek için, 'neden?' diye sorarak her olası 'yanlış gereksinimi' doğrulayın. çözülmesi gereken gerçek soruna ulaşana kadar.

İletişim sorunları – Bir iş analisti ile diğer taraflar arasında yanlış iletişime yol açabilecek konular arasında dil engelleri, yanlış varsayımlar, yetersiz açıklanmış kelime dağarcığı ve teknik terimlerin aşırı kullanımı sayılabilir.

Bu sorunu önlemek için ideal yaklaşım, sık sık etkileşim kurmak ve iki yönlü konuşmalar geliştirmektir. Keşfettiğiniz ihtiyaçları belgeleyin ve çeşitli konu uzmanlarına akran değerlendirmesi ve eleştiri için gönderin, bir jargon sözlüğü oluşturun ve binaları iki kez kontrol edin.

Gereksinimleri Yazarken Yapılması ve Yapılmaması Gereken 10 Şey:

1 numarayı yap Teker Teker – Her gereksinim ayrı bir test durumu olarak ele alınmalıdır. ve, or, vb. gibi bağlaçlar, gereksinimlerin kaybolmasına neden olabileceğinden kullanılmamalıdır. Bu, özellikle önemlidir, çünkü bunun gibi terimler, yazılım geliştiricilerin ve testçilerin gereksinimleri gözden kaçırmasına neden olabilir. Karmaşık ihtiyaçları, her biri ayrı ayrı test edilebilene kadar daha küçük parçalara bölmek, bunun olmasını önlemenin bir yoludur.

# 1 yapma. “Nasıl” Değil “Ne” Konuşun – Sistemin nasıl yaptığına değil, ne yapacağına odaklanılmalıdır. Ek olarak, alan adları, programlama dili nesneleri ve yazılım nesneleri gibi tasarım konularına çok fazla dalmaktan kaçının. Kendinizi Gereksinim Belirtim Belgesinde bu konuları tartışırken bulursanız, bir adım geri atın - bu muhtemelen fazla spesifikleştiğiniz anlamına gelir.

2 numarayı yap İzlenebilirlik – Proje yönetiminde izlenebilirlik, gereksinimlerin projedeki diğer bileşenlerle bağlantılı olmasını sağlamak anlamına gelir. Bu, proje yöneticilerinin, geliştiricilerin ve paydaşların, bir gereksinimin tüm yaşam döngüsünü baştan sona tüm yönlerde ve ayrıca sistemin diğer bölümleriyle birlikte takip etmelerini sağlar. İzlenebilirliği düzgün bir şekilde yönetirseniz, herhangi bir gereksinime karşılık gelmeyen kodlardan ('kaçak' kod) kaçınabilir ve her test senaryosunun en az bir gereksinimi kapsadığından emin olabilirsiniz. Gereksinimleri benzersiz bir tanımlayıcıyla etiketleyerek ve kaynakları hakkında tüm ekip üyelerinin erişebileceği merkezi bir havuzda bilgi sağlayarak izlenebilir hale getirebilirsiniz.

# 2 yapma. İstisna yok – Bir gereksinimin bir kaçış maddesi olmamalıdır. Örneğin, “Sistem, kullanıcının açıkça yanlış bir kullanıcı adı girdiği durumlar dışında, oturum açma denemelerinin sayısını belirleyecektir”.

3 numarayı yap Mümkün – Mevcut kaynaklarla birlikte proje bütçesi ve zaman çizelgesinin uygulanabilir olduğundan emin olun. Bu koşul gereksinimi destekleyebilirse, planla ilerlemek mümkündür.

# 3 yapma. “Bırakma” Maddelerine Hayır Deyin – Ama, hariç ve sadece gerekliyse gibi dışa vurma ifadelerinden uzak durmaya çalışın.

4 numarayı yap Tutarlılık – Tutarlı bir ayrıntı düzeyini koruyun. Örneğin, kullanıcı gereksinimleri için her cümlenin öznesi bir son kullanıcı olmalıdır. Benzer şekilde, sistem gereksinimleri için bir sistem her cümlenin konusu olmalıdır.

# 4 yapma. Kısaltma Yok – Her gereksinim, herhangi bir kısaltma veya jargon olmadan tam bir cümle olmalıdır.

5 numarayı yap Aktif ses – Daima aktif bir sesle yazın, oyunculardan birinin her cümlenin öznesi olduğundan emin olun.

# 5 yapma. Belirsiz Olma – gibi Belirsiz terimler kullanmayın. yaklaşık vb.ve gereksinimler belgesinde bunun gibi daha fazla terim. Gereksinimleri, dahil olan herkesin doğru anlayacağı şekilde açıkladığınızdan emin olun. Belirsiz ifadeler yanlış yorumlara yol açabilir ve çeşitli paydaşlar arasında çatışmalara neden olabilir.

6 numarayı yap Konu ve Yüklem – Her gereksinim için bir özne (kullanıcı/sistem) ve bir yüklem (amaçlanan sonuç, eylem veya koşul) olmalıdır.

# 6 yapma. Spekülasyonlar Zarar Verebilir – Tahmin etmeyin; söz konusu olmayan özelliklerin listesini yapmayın. Bir sistemin tüm beklenmedik başarısızlıkları ele almasını istediğinizi söylemek tamamen hayaldir çünkü hiçbir sistem asla istediğiniz gibi yüzde yüz olmayacaktır. Yinelemelerden ve çelişkili ifadelerden kaçının.

7 numarayı yap Doğrulanabilir – Gereksinimleri düzenlerken akılda tutulması gereken bir başka şey de, her zaman test edilebilir olmaları gerektiğidir. Bu, sistemin söz konusu gereksinimi karşıladığını doğrulamanın mümkün olması gerektiği anlamına gelir. Bu aynı zamanda bir sonraki noktamız olan izlenebilirlikle de bağlantılıdır. Bir gereksinim belirsiz terimlerle doluysa, sistemin Performans açısından bu standartları gerçekten karşılayıp karşılamadığını analiz etmek ve doğrulamak zorlaşır. Bu nedenle, Gereksinim toplamanın belirsiz bir süreç olmaması için mümkün olduğunca dilinizde netlik ve kesinlik hedefleyin.

# 7 yapma. Seçeneklerden Kaçının – Fikir veya seçenek sunmayın. Bunları, olabilir, olabilir, olabilir veya gerekli ifadelerini içeren herhangi bir ifadede görebilirsiniz.

8 numarayı yap Doğru – Her cümlenin uygun bir özne, fiil ve yüklem ile tam ve dilbilgisi açısından doğru olduğundan emin olun.

# 8 yapma. Gelecek Zamanda Konuşma – Henüz tanımlanmamış bir gereksinime atıfta bulunmayın. Amacınız, belgeyi mümkün olduğunca okunması keyifli hale getirmektir.

9 numarayı yap odak – Saçma sapan, çok uzun cümleleri ve güncelliğini yitirmiş makalelere yapılan atıfları ortadan kaldırarak odak oluşturun.

# 9 yapma. Nerelerde ve Nerelerde Kullanılmalı? – Gereksinimlerin belirtildiği yerde “Yapılacak”, gerçekleri ifade etmek için “İrade” kullanılmalıdır; & Ulaşılacak bir hedefi temsil etmek için “Gerekir”.

10 numarayı yap Organize Evrak İşleri Harikalar Yaratır – Belgenizin okunabilirliğini iyileştirmek ve birden çok kaynağa çapraz referans vererek zaman kaybetmekten kaçınmak için gereksinimleri tek bir yerde organize edin.

# 10 yapma. Bilinmeyen Terimler Kullanmayın – Test senaryolarını tanımlamaya çalışırken zorluk yaratabileceğinden, "kullanıcı dostu, çok yönlü ve sağlam" gibi bilinmeyen terimler kullanmayın. Bu kelimeler genellikle farklı insanlar için farklı anlamlar taşır.

Görüş Gereksinimleri ALM Platformu

Visure, dünya çapında her büyüklükteki kuruluş için gereksinim yönetiminde uzmanlaşan en güvenilir uygulama yaşam döngüsü yönetim platformlarından biridir. Visure'ın ana ortakları, iş açısından kritik ve güvenlik açısından kritik şirketlerdir. Şirket, risk yönetimi, sorun ve kusur takibi, izlenebilirlik yönetimi, değişiklik yönetimi ve kalite analizi, gereksinim sürümleri oluşturma ve güçlü raporlama gibi çeşitli diğer alanlar dahil olmak üzere tüm Uygulama Yaşam Döngüsü Yönetimi süreçleriyle entegre olur.  

Hem işlevsel hem de işlevsel olmayan gereksinimlerde size yardımcı olacak bir gereksinim yönetimi aracı arıyorsanız, Visure Requirements'a göz atın. Bu platform ile projenizin tüm gereksinimlerini tek bir yerden kolayca oluşturabilir, yönetebilir ve takip edebilirsiniz.

Sonuç

Gereksinim belirleme, yazılım geliştirmede kritik bir süreçtir, ancak iyi gereksinimleri yazmak zor olabilir. Sağladığımız 20 ipucu, daha iyi gereksinimler yazmanıza yardımcı olacak ve süreci dahil olan herkes için daha sorunsuz hale getirecektir. Gereksinimlerinizi bir sonraki seviyeye yazmak istiyorsanız, Visure Requirements ALM Platformu gibi bir araç kullanmayı düşünün. talep et Ücretsiz 30 günlük deneme bugün platformumuzun ihtiyaç toplama ve yönetim süreçlerinizi kolaylaştırmanıza nasıl yardımcı olabileceğini görün.

Bu gönderiyi paylaşmayı unutmayın!

Iyi