Jaki jest właściwy sposób tworzenia dokumentów wymagań?

Obecnie mój przełożony tworzy dla mnie dokumentację wymagań / specyfikacje za pomocą oprogramowania do śledzenia błędów. Wydaje mi się to okropnym pomysłem, wszystkie wymagania dotyczą tych małych biletów i muszę kliknąć ten głupi formularz internetowy, aby uzyskać dostęp do wymagań. Co to jest rozsądne rozwiązanie dla wymagań / specyfikacji oprogramowania?

Dla jasności buduję ten duży komponent oprogramowania z kilkoma funkcjami, które są przedstawione w tym oprogramowaniu do śledzenia błędów.

Jestem raczej zaskoczony, że jak dotąd nikt nie zalecił użycia wiki do śledzenia wymagań.

Uważam, że jest to prawie idealny system, ponieważ:

• Pozwala ludziom współpracować w zakresie wymagań i sprawia, że ​​ten aspekt jest dobrze widoczny;
• Umożliwia łatwe aktualizowanie wymagań w miarę postępu projektu;
• Możesz wejść i zobaczyć historię w dowolnym momencie, w przypadku sporu dotyczącego „tego nie uzgodniliśmy”;
• Większość współczesnych stron wiki ma przyzwoite możliwości formatowania, więc wygląda prawie tak dobrze jak dokument Word;
• Możesz linkować bezpośrednio ze swoich wymagań do faktycznej dokumentacji;
• Nigdy nie musisz się martwić, że ludzie będą pracować z różnymi / przestarzałymi kopiami;
• Wymagania można zacząć traktować jako proces iteracyjny, podobnie jak projekt / wdrożenie;
• Jeśli wymagania stają się naprawdę duże / skomplikowane, łatwo jest je podzielić na strony / tematy.
• Większość wiki akceptuje HTML, więc jeśli naprawdę potrzebujesz zaawansowanego formatowania, prawdopodobnie możesz użyć narzędzia takiego jak Windows Live Writer .

Biorąc pod uwagę wybór, prawie zawsze wybieram metodę wiki, jest to naprawdę dość bezbolesne w porównaniu do staromodnych dokumentów Worda lub próby wtłoczenia tego wszystkiego w narzędzie do śledzenia błędów.

Zawsze używam IEEE Std 830-1998 (IEEE Recommended Practice for Software Requirements Specifcations) jako szablonu dla mojego dokumentu SRS. Zobacz http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

Ostateczny sam dokument SRS jest zwykle pojedynczym dokumentem OpenOffice.org, ale zwykle zawiera wiele elementów składowych, w tym arkusze kalkulacyjne i diagramy.

Zazwyczaj umieszczam wszystkie te dokumenty razem w repozytorium, które umieszczam w systemie kontroli wersji , takim jak SVN lub CVS. Wszyscy inni analitycy biznesowi, projektanci, programiści, testerzy, kierownicy projektów i klienci mają dostęp do tego repozytorium, aby mogli go czytać i wprowadzać zmiany.

Pamiętaj, że SRS to żywy, ewoluujący dokument. Przez pewien czas będzie się zmieniać i rosnąć. Dla wszystkich interesariuszy ważny jest nie tylko dostęp do SRS, ale także ważna jest pełna historia zmian, a także możliwość wycofania tych zmian, jeśli to konieczne. Dlatego system kontroli wersji działa doskonale w tym celu. Powodzenia!

Używanie narzędzia do śledzenia błędów do zarządzania wymaganiami ma tendencję do ukrywania braku współpracy i komunikacji w firmie.

Bez oceny jakiejkolwiek konkretnej metody:

• jeśli zamierzasz korzystać z wodospadu, potrzebujesz dobrze ustrukturyzowanych, dokładnych, wielostronicowych dokumentów (nie jednego akapitu, który wiele osób zwykle wpisuje jako opis błędu). Dokumenty te są również niemożliwe do napisania i utrzymania na przyzwoitym poziomie jakości, jeśli marketing / handlowcy (którzy pochodzą z wymagań) nie współpracują dobrze z personelem inżynieryjnym.
• jeśli zamierzasz zastosować jedną z metod zwinnych, wówczas jedną z jednostek wymagań jest historia użytkownika, reprezentowana przez kartę opowieści. Sama karta nie jest wymogiem, a jedynie punktem wyjścia do rozmowy.

(Krótkie) doświadczenie jednego z moich wcześniejszych pracodawców z wykorzystaniem narzędzia do śledzenia błędów w odniesieniu do wymagań polegało na tym, że dało to wielu osobom bardzo łatwy sposób całkowitego zaprzestania komunikacji. Ludzie po prostu napisaliby życzenie, wrzucili je do narzędzia do śledzenia błędów i zakładali, że w końcu się spełni.

Oczywiście zrobili to bez względu na:

• własne kwalifikacje
• ich udział w projekcie
• koliduje z innymi wymogami
• luki w wymaganiach
• koszty
• wszelkie względy techniczne
• itp.

Uważam, że dokumenty „Word” są niewłaściwą drogą do spełnienia wymagań z następujących powodów:

1. Nie ma możliwości „różnicowania” dwóch dokumentów, aby zobaczyć, co się zmieniło.
2. Interfejs użytkownika odradza stosowanie spójnego stylu w całym tekście. Tak, można używać stylów, ale większości ludzi nie przeszkadza to z powodu trudności.
3. Format dokumentu jest zasadniczo ukryty. Jasne, istnieje specyfikacja dla plików OLE, które, jak sądzę, są w dokumentach „Word”, ale Microsoft zakopał wszystko przydatne pod tonami blather, więc nikt tak naprawdę nie wie. Wcześniej czy później twoje błyszczące, nowe „Słowo” nie otworzy dokumentu.
4. Nie działa dobrze z innymi formatami. Oznacza to, że jeśli nie korzystasz z systemu Windows i IE, nie masz szczęścia, jeśli ktoś zorganizuje dokumenty projektu w plikach HTML z linkami do plików w formacie „Word”. Kliknij niewłaściwy link i musisz usiąść przez długi okres pobierania i rozpoczynania programu Word, przerywając przepływ myśli. Hiperłącza z dokumentów „Word” do innych mogą, ale nie muszą działać.
5. „Słowo” jest zasadniczo przeznaczone do pisania dokumentów, które mają pojawić się na papierze. Godny podziwu cel, ale taki, który czyni go mniej niż przydatnym do oglądania w Internecie.

Nie mam alternatywnej sugestii, z którą mam doświadczenie, ale pomyślałem o restrukturyzowanym tekście Pythona lub Markdown jako alternatywach.

Zasadniczo używamy programu Word, ale w rzeczywistości sposób ich tworzenia w oprogramowaniu jest mniej ważny niż sposób gromadzenia danych w celu ich utworzenia i to, czy osoba gromadząca informacje wie wystarczająco dużo, aby wiedzieć, kiedy wymaganie jest zbyt skomplikowane i będzie znacznie droższe niż prostsze wymaganie nie dodaje jednak żadnej wartości rzeczywistej (na przykład gdy chce, aby numery identyfikacyjne były zawsze przypisywane w celu, aby żaden z nich nigdy nie był pomijany) lub gdy będzie to kolidować z istniejącym wymaganiem lub inną zaplanowaną funkcją. Często z rzeczywistymi użytkownikami nigdy nie rozmawia się i jest wiele niespodzianek, gdy ich menedżerowie nie wiedzą czegoś, co absolutnie musiało zostać zrobione i nie jest to nowa wersja oprogramowania.

Możemy również korzystać z różnych plików pdf, Excel lub Visio. Wszystkie z nich są gromadzone i edytowane poza SharePoint, więc w razie potrzeby możemy zobaczyć wcześniejsze wersje.

Prowadzę rejestr produktu (jeden na projekt lub produkt), który zawiera Historie użytkowników . Mogą być przechowywane w oprogramowaniu do śledzenia błędów, takim jak to, którego używasz. Osobiście używam Excela do rejestrowania zaległości i Traca do rejestrowania zaległości sprintu (prawdopodobnie używasz takiego narzędzia).

Gdy tylko jest to wymagane, tworzę dokument programu Word opisujący historię użytkownika z dodatkowymi szczegółami i dołączam ją do historii użytkownika. Ale staram się tego uniknąć, dzieląc historię użytkownika na mniejsze.

Małe historie użytkowników są łatwiejsze do zarządzania (w tym oszacowania)

Podoba mi się dokument Word, ponieważ pozwala mi umieszczać linki, formatować teksty, umieszczać tabele, zrzuty ekranu i więcej, i każdy może je czytać.

Oczywiście, każda historia użytkownika jest szczegółowo wyjaśniona w sesji szacunkowej i planowaniu sprintu, i zawsze jestem dostępny na więcej pytań, gdy programista zdecyduje się nad nim popracować. Częste informacje zwrotne przy użyciu przeglądu sprintu uniemożliwiają programistom robienie czegoś innego niż wymaga tego właściciel produktu.

Osobiście w przeszłości korzystałem z Dokumentów Word, ale postanowiłem w przyszłości znaleźć narzędzie do zarządzania tym ... zwłaszcza z możliwością ustawiania błędów zgodnie z wymaganiami, ponieważ często błąd jest w wymaganiach, a nie odchylenie między specyfikacjami a implementacją.

Nigdy nawet nie przyszło mi do głowy, aby użyć narzędzia do śledzenia błędów, ale ma to sens.

Z ciekawości, czego w tym nie lubisz?

EDYCJA: jedno zastrzeżenie; poproś swojego kierownika o zmianę marki oprogramowania do śledzenia błędów. W przeciwnym razie zakłada się, że wszystko w nim jest błędem. Miałem ten problem polityczny u mojego ostatniego klienta, gdzie umieszczałem zadania w narzędziu do śledzenia błędów. Niedobrze.

Napisałem bazę wymagań 6 lub 7 lat temu, aby sobie z tym poradzić. Każdy rekord wymagań ma krótki opis, notatkę „definicji” i notatkę „notatki” (zarówno tekst sformatowany, z możliwością osadzania zrzutów ekranu itp.). Istnieją również inne pola, dotyczące projektu, dostawy, numeru sekwencji (aby można je było logicznie zamówić), przypadku użycia / funkcji, z którą jest związany, szacunkowego czasu, pola dla osoby obsługującej go, jeśli ktoś wybrał go do realizacji, itp.

Istnieje również „Status” - „Wprowadzono”, ponieważ podczas projektowania funkcji; „Zatwierdzony”, ustalany po przejrzeniu grupy wymagań i ustaleniu, że jest gotowy do wdrożenia; „Wdrożony”, ustawiony przez programistę, gdy uznają, że wymaganie jest spełnione, i „Zatwierdzony”, gdy technologia kontroli jakości zgodzi się z programistą. (Jeśli technik kontroli jakości się nie zgadza, może ustawić go z powrotem na „Zatwierdzony”, aby programista go odzyskał.) Wymagania mogą być również „Odroczone”, „Odrzucone” lub „Przesłuchane” (co oznacza, że ​​Rada Kontroli Zmian musi to sprawdzić. .)

Sztuką robienia tego dobrze jest rozsądna szczegółowość. Czasami sensowne może być posiadanie wymagań jednego zdania (np. „Problem opisany w numerze 12345 jest naprawiony”), ale ogólnie wymagania powinny opisywać wszystkie ważne aspekty całej funkcji (lub dużej części jednego). Na przykład typowa funkcja „nowego raportu” będzie wymagała formatu raportu (jak wygląda dane wyjściowe), a także okna dialogowego opcji (wyjaśniającego pola, sprawdzanie poprawności itp.). Może być nawet trzeci, jeśli jest złożony generator generujący trzaski danych, a nie tylko proste zapytanie czy coś w tym rodzaju. Ponadto utworzymy wymaganie „Pomoc” dla odpowiedniego tematu pomocy.

Ogromne zalety trzymania tych rzeczy w rekordach bazy danych zamiast dużego dokumentu. Wielu programistów może jednocześnie pracować nad wymaganiami. Poszczególne rekordy są zablokowane, więc tylko jedna osoba może edytować na raz, ale można je otwierać i czytać, gdy ktoś inny edytuje. Największą zaletą jest to, że zapewnia łatwą do przeszukiwania dokumentację zarówno tych wymagań, jak i notatek dotyczących ich wdrożenia. Mamy tam obecnie ponad 25 000 wymagań i możemy łatwo znaleźć wszystkie wymagania z określonymi słowami we wszystkich polach lub w definicji, notatkach lub cokolwiek innego, w mniej niż 10 sekund. (Spróbuj tego z dokumentami Word o wartości ponad 6 lat).

Rozumiem, dlaczego ludzie mogą twierdzić, że złym pomysłem jest robienie wymagań w „narzędziu do śledzenia błędów”, ale domyślam się, że to dlatego, że narzędzia są do bani, a nie dlatego, że utrzymywanie wymagań w bazie danych z możliwością przeszukiwania jest złym pomysłem.

Kiedyś użyłem http://www.pivotaltracker.com/, ale w mojej obecnej firmie używamy .doc jako źródła specyfikacji podstawowej i Lighthouse jako połączonej listy życzeń i śledzenia problemów. Dla mnie trudno jest sprawić, aby inni ludzie w zespole zaczęli używać innych narzędzi, gdy są tak przyzwyczajeni do programu Word.

Jeśli postępujesz zgodnie z metodologią Agile, poniższe linki poprowadzą Cię przez proces wyboru odpowiedniego narzędzia Agile Project Management:

• Zwinne narzędzia do zarządzania projektami
• Porównanie różnych narzędzi do zwinnego zarządzania projektami

A tak na poważnie, wypróbuj metodologię Agile - głosi ona proste, eleganckie, bezsensowne, nie jazzujące, wspólne zmysłowe podejście we wszystkim, co robisz, tak aby każdy członek zespołu rozumiał i doceniał rolę i wysiłek każdego innego członka.

Powodzenia!