İhtiyaç belgeleri oluşturmanın doğru yolu nedir?

Şu anda süpervizörüm, bugtracking yazılımı kullanarak benim için gereksinim belgeleri / özellikleri oluşturuyor. Bu benim için korkunç bir fikir gibi görünüyor, tüm gereksinimler bu küçük biletler üzerinde ve gereksinimleri almak için bu aptal web formunu tıklamak zorundayım. Gereksinimler / yazılım özellikleri için akıllıca bir yazılım çözümü nedir?

Açıkçası, bu büyük yazılım bileşenini epeyce özelliklerle geliştiriyorum ve bu özellikler bu hata izleme yazılımında ortaya konuyor.

Şimdiye kadar hiç kimsenin izleme gereklilikleri için bir wiki kullanılmasını tavsiye etmemesine şaşırdım .

Neredeyse mükemmel bir sistem olarak buldum, çünkü:

• İnsanların gereksinimler üzerinde işbirliği yapmalarını sağlar ve bu yönü yüksek oranda görünür kılar;
• Proje ilerledikçe gereklilikleri kolayca güncel tutmanızı sağlar;
• Herhangi bir zamanda, “anlaştığımız şey bu değil” anlaşmazlığı durumunda, içeri girip geçmişi görebilirsiniz.
• Çoğu modern wiki, iyi biçimlendirme yeteneklerine sahip, bu yüzden neredeyse bir Word belgesi kadar iyi görünüyor;
• Gereksinimlerinizden doğrudan gerçek dokümantasyona köprü kurabilirsiniz;
• Farklı / eski kopyalardan çalışan insanlar hakkında asla endişelenmenize gerek yok;
• Gereksinimler, tıpkı tasarım / uygulama gibi, yinelemeli bir süreç olarak ele alınmaya başlanabilir;
• Gereksinimler gerçekten büyük / karmaşık hale gelmeye başlarsa, bunları sayfalara / konulara ayırmak kolaydır.
• Çoğu wiki HTML'yi kabul eder, bu yüzden gerçekten gelişmiş biçimlendirmeye ihtiyacınız varsa, muhtemelen Windows Live Writer gibi bir araç kullanabilirsiniz .

Seçim göz önüne alındığında, bugünlerde neredeyse her zaman wiki yöntemini seçiyorum, eski moda Word belgelerine kıyasla ya da hepsini bir hata izleyiciye sıkıştırmaya çalışmak gerçekten çok acısız.

Her zaman IEEE Std 830-1998 (IEEE Yazılım Gereksinimleri Spesifikasyonları İçin Önerilen Uygulama) 'nı SRS dokümanım için şablon olarak kullanıyorum. Http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html adresini ziyaret edin.

Nihai SRS belgesinin kendisi genellikle tek bir OpenOffice.org belgesidir, ancak elektronik tablolar ve diyagramlar dahil olmak üzere, içine giren çoğu bileşen vardır.

Bu belgelerin tümünü genellikle SVN veya CVS gibi revizyon kontrol sistemine koyduğum bir havuza koyarım. Diğer tüm iş analistleri, tasarımcıları, geliştiricileri, test uzmanları, proje yöneticileri ve müşterileri bu depoya erişebiliyor, böylece onu okuyabilir ve düzeltmeler yapabilirler.

Unutmayın, SRS yaşayan, gelişen bir belgedir. Bir süre değişmeye ve büyümeye devam edecek. Yalnızca tüm paydaşların SRS'ye erişimi olması önemli değil, aynı zamanda değişikliklerin tam bir geçmişine ve gerekirse bu değişiklikleri geri alma yeteneğine sahip olması da önemlidir. Dolayısıyla bir revizyon kontrol sistemi bu amaç için harika çalışıyor. İyi şanslar!

İhtiyaç yönetimi için hata izleyiciyi kullanmak, şirket içindeki işbirliği ve iletişim eksikliğini gizleme eğilimindedir .

Herhangi bir özel yöntem hakkında karar vermeden:

• şelale kullanacaksanız, iyi yapılandırılmış, doğru, çok sayfalı belgelere ihtiyacınız vardır (çoğu kişinin tipik olarak hata açıklaması olarak yazdığı bir paragraf değil). Bu belgelerin aynı zamanda, pazarlama / satış görevlilerinin (gereklilikleri taşıyan) mühendislik personeliyle birlikte iyi çalışmadıklarında, iyi kalitede yazmaları ve saklanması imkansızdır.
• Çevik yöntemlerden birini kullanacaksanız, bir gereksinim birimi bir hikaye kartıyla temsil edilen bir kullanıcı hikayesidir. Kartın kendisi bir gereklilik değil, yalnızca konuşmanın bir başlangıç ​​noktasıdır.

Geçmişte işverenlerimden birinin gereksinimler için bir hata izleyici kullanma konusundaki (kısa) tecrübesi, birçok insana tamamen iletişim kurmayı bırakmanın çok kolay bir yolunu vermesiydi. İnsanlar basitçe bir dilek yazar, onu böcek izleyiciye bırakır ve sonunda gerçekleşeceğini varsayarlar.

Tabii ki bunu dikkate almadan yaptılar:

• kendi nitelikleri
• Projedeki payları
• diğer şartlarla çatışmalar
• Gereksinimlerdeki boşluklar
• maliyetler
• Herhangi bir teknik husus
• vb.

Aşağıdaki nedenlerden dolayı "Word" belgelerinin gereksinimler için gitmenin yanlış yolu olduğuna inanıyorum:

1. Neyin değiştiğini görmek için iki belgeyi "dağıtmak" mümkün değil.
2. Kullanıcı arayüzü, boyunca tutarlı bir stil kullanmaktan vazgeçirir. Evet, stilleri kullanmak yapılabilir, ancak zorluk yüzünden çoğu insan rahatsız olamaz.
3. Belge formatı aslında gizlidir. Tabii ki, "Word" belgelerinin olduğunu sandığım OLE dosyalarının bir özelliği var, ancak Microsoft her şeyi tonlarca aldatıcıya gömdü, bu yüzden kimse bilmiyor. Er ya da geç, sizin parlak, yeni "Word" belgenizi açmaz.
4. Diğer formatlarla iyi oynamıyor. Diğer bir deyişle, Windows ve IE kullanmıyorsanız, bir projenin belgelerini HTML dosyalarında "Word" biçimindeki dosyalara bağlar olarak düzenlediyseniz, şansınız kalmaz. Yanlış bağlantıya tıkladığınızda, düşüncenin akışını kesintiye uğratan, Word'ün uzun bir indirme ve başlatma süresi boyunca oturmanız gerekir. "Word" dokümanlarından diğerlerine köprüler işe yarayabilir ya da çalışmayabilir.
5. "Word" temel olarak kağıda görünmesi amaçlanan belgeleri yazmak içindir. Takdire şayan bir hedef, ancak çevrimiçi görüntüleme için kullanışlılıktan daha azını sağlayan hedef.

Tecrübe ettiğim alternatif bir önerim yok ama Python'un yeniden yapılandırılmış Metni veya Markdown'ı alternatif olarak düşündüm.

Genel olarak Word'ü kullanıyoruz, ancak gerçekte bunları yazılımda nasıl oluşturduğunuz, onları oluşturmak için verileri nasıl topladığınızdan daha az önemlidir ve bir bilgiyi toplayan kişinin bir gereksinimin aşırı karmaşık olduğu ve ne zaman çok daha pahalı olacağını bilecek kadar bilgili olup olmadığı daha basit bir gereksinim henüz hiç kimseye gerçek bir değer katmaz (örneğin, kimlik numaralarının atlanması gerekmeden her zaman sırayla atanmasını istedikleri zaman) veya mevcut bir gereksinimle veya planlanan başka bir özellikle çakışacağı zaman. Genellikle gerçek kullanıcılar asla konuşulmaz ve yöneticileri kesinlikle yapılması gereken bir şey bilmediklerinde ve yazılımın yeni sürümünde olmadığında birçok sürpriz vardır.

Ayrıca çeşitli pdf, Excel veya Visio dosyalarını da kullanabiliriz. Proje için tümü, SharePoint'ten toplanır ve düzenlenir, bu yüzden gerekirse daha önceki sürümleri görebiliriz.

Kullanıcı Hikayeleri içeren bir ürün birikimini (proje veya ürün başına bir tane) tutarım . Kullandıklarınız gibi böcek takip yazılımı içinde saklanabilirler. Ben kişisel olarak backlog için Excel ve sprint backlog için Trac kullanıyorum (muhtemelen bu araç gibi bir araç kullanıyorsunuz).

Yalnızca gerektiğinde , Kullanıcı Hikayesini daha fazla ayrıntıyla açıklayan ve kullanıcı hikayesine ekleyen bir Word belgesi oluşturuyorum . Ancak kullanıcı hikayesini daha küçük hikayelere bölerek bundan kaçınmaya çalışıyorum.

Küçük kullanıcı hikayelerinin yönetilmesi daha kolaydır (tahmin dahil)

Word belgesini seviyorum çünkü linkler koymama, metinleri biçimlendirmeme, masalar koymam, ekran görüntüleri ve daha pek çok şey yapmamı sağlıyor ve herkes okuyabilir.

Tabii ki, her Kullanıcı Hikayesi tahmin oturumunda ve sprint planlamasında ayrıntılı olarak açıklanmaktadır ve geliştirici üzerinde çalışmaya karar verdiğinde daha fazla soru için her zaman hazırım. Sprint incelemesi kullanarak sık sık yapılan geri bildirimler, geliştiricilerin ürün sahibi tarafından istenenden farklı bir şey yapmasını önler.

Şahsen, geçmişte Word Belgeleri kullandım, ancak gelecekte bunu benim için yönetmek için bir araç bulmaya karar verdim ... özellikle de hataları gereksinimlere göre belirleme yeteneğiyle, çünkü çoğu zaman hata Gereksinimlerde, özellikler ve uygulama arasındaki sapma değil.

Hata izleme aracı kullanmak benim başıma gelmedi, ama tamamen mantıklı geliyor.

Meraktan, hoşlanmadığın şey ne?

EDIT: bir uyarı; yöneticinize hata izleme yazılımını yeniden markalaştırmasını söyleyin. Aksi halde, içindeki her şeyin bir hata olduğu varsayılır. Son müşterimde bu politik sorunu yaşadım, böylelikle görevleri böcek takipçisine koydum. İyi değil.

Bunu halletmek için 6 ya da 7 yıl önce bir gereksinim veritabanı yazdım. Her gereksinim kaydında kısa bir açıklama, "tanım" notu ve "notlar" notu (her ikisi de zengin metin, ekran görüntülerini gömme yeteneği vb.) Vardır. Proje için teslim edilebilecek, sıra numarası (mantıksal olarak sıralanabilir), kullanım için durum / özellik, zaman tahmini ile ilgilenen, birileri uygulama için seçtiyse, ilgilenen kişi için bir alan da var. vb.

Ayrıca özellikleri tasarlarken “Durum” - “Girildi”; Bir grup gereksinim gözden geçirilip uygulamaya hazır olduğu tespit edildikten sonra "onaylandı"; Programcı tarafından gereksinimin yapıldığını düşündüklerinde bir kez ayarlanan “Uygulandı” ve KG teknolojisi bir kez daha programlayıcı ile aynı fikirde olduklarında “Doğrulandı”. (QA teknolojisi kabul etmezse, programcının geri alabilmesi için "Onaylandı" ya geri koyabilir.) Gereksinimler aynı zamanda "Ertelenmiş", "Reddedildi" veya "Sorgulandı" olabilir (Değişim Kontrol Panosunun buna bakması gerekir) .)

Bunu iyi yapmanın püf noktası makul bir ayrıntıdır. Bazen bir cümle gereksinimine sahip olmak mantıklı gelebilir (örneğin, "12345 sayılı sorunda açıklanan sorun giderildi"), ancak genel olarak gereksinimler, tüm bir özelliğin (veya bir tanesinin büyük bir bölümünün) tüm önemli yönlerini tanımlamalıdır. Örneğin, tipik bir "yeni rapor" özelliği, bir rapor formatı (çıktının nasıl göründüğü) ve seçenekler iletişim kutusu için bir gereksinim (alanları, doğrulama, vb. Açıklar) gerekebilir. Sadece kolay bir sorgudan başka bir şey yerine verileri parçalayan karmaşık bir jeneratör var. Ek olarak, ilgili yardım konusu için bir "Yardım" gereksinimi de oluşturacağız.

Bu şeyleri büyük bir belge yerine veritabanı kayıtlarında tutmanın büyük avantajları vardır. Birden fazla programcı aynı anda gereksinimler üzerinde çalışabilir. Bireysel kayıtlar kilitlenir, böylece bir seferde yalnızca bir kişi düzenleyebilir, ancak başka biri düzenlerken açılabilir ve okunabilir. Yine de en büyük avantaj, gerekliliklerin ne olduğu ile ilgili dokümantasyonu aramayı kolaylaştırması ve nasıl uygulandığına dair notlar almasıdır. Şu anda burada 25.000'den fazla gereksinimimiz var ve tüm gereklilikleri tüm alanlarda, tanımlarda, notlarda ya da her neyse, belirli kelimelerle 10 saniyenin altında kolayca bulabiliriz. (Bunu 6+ yıl boyunca Word belgelerini kullanarak deneyin.)

İnsanların neden bir "hata izleyicide" gereksinim duymanın kötü bir fikir olduğunu söyleyebildiklerini anlayabiliyorum, ancak tahminime göre, araçlar aranabilir bir veritabanında gereksinimleri tutmak kötü bir fikir olduğu için değil.

Bir keresinde http://www.pivotaltracker.com/ adresini kullandım ancak şu anki şirketimde çekirdek özellik kaynağı olarak .doc ve birleşik özellikler istek listesi ve sorun takibi olarak Lighthouse kullanıyoruz. Benim için takımdaki diğer insanların, Word'e çok alışkın olduklarında diğer araçları kullanmaya başlamalarını sağlamak zor.

Çevik metodolojiyi izleyebiliyorsanız, aşağıdaki bağlantılar iyi bir Çevik Proje Yönetimi aracı seçmenizde size yol gösterebilir:

• Çevik Proje Yönetim Araçları
• Farklı Çevik Proje Yönetim Araçlarının Karşılaştırılması

Ve cidden, Agile metodolojisini deneyin - ne yaparsanız yapın basit, şık, saçma sapan, jazzy olmayan, ortak bir duyusal yaklaşım sergiler, böylece her ekip üyesi diğer üyelerin rolünü ve çabasını anlar ve takdir eder.

İyi şanslar!