Jak zbieramy wymagania
Ostateczny dokument wymagań klienta w tworzeniu oprogramowania
Dokument Wymagań Klienta wraz z Dokumentem Wymagań Biznesowych (BRD) oraz Dokumentem Wymagań Technicznych (TRD) aka Specyfikacja Wymagań Oprogramowania (SRS)) jest jednym z głównych narzędzi w procesie wytwarzania oprogramowania. W całej społeczności kierowników projektów, analityków oprogramowania, księgowych IT, inżynierów kodujących i testujących, czyli praktycznie wszystkich, którzy zarabiają na życie będąc częścią procesu wytwarzania oprogramowania, używa się go nieustannie. Niektórzy z nas piszą go od zera, inni zmieniają i ulepszają na różnych etapach projektu, jeszcze inni używają go jako przewodnika i odniesienia dla tworzenia i testowania oprogramowania.
Rafał Kołakowski,
IT Manager and Project Manager at 3e Software House
Jako menedżer IT prowadziłem dziesiątki projektów i brałem udział w wielu innych, w różnych firmach, w tym w organizacjach produkujących złożone oprogramowanie infrastrukturalne dla jednostek rządowych. Zarówno w początkowych fazach, jak i później, w głębi tych projektów, zwykle czułem, że w moim dialogu z klientem brakuje czegoś, a mianowicie jasnej i zwięzłej struktury wraz z listą kontrolną, która zapewniłaby mnie, klienta i wszystkich interesariuszy, że nie pominęliśmy żadnych istotnych elementów projektu, które mogłyby spowodować nawet drobne zniekształcenia w produkcie końcowym lub pozwolić mu odejść na bok od tego, czego klient faktycznie potrzebował.
Tak właśnie i dlatego kilka lat temu zacząłem tworzyć szablon zwięzłego, ale wyczerpującego dokumentu, który pomógłby mi i wszystkim interesariuszom mieć większą kontrolę nad projektem, usprawnić proces rozwoju i testowania oraz zapewnić ciągłość wiedzy, tak aby uniknąć nieporozumień, ślepych zaułków i przerabiania niektórych gotowych funkcjonalności.
Szablon składa się z 6 rozdziałów, które należy wypełniać stopniowo podczas kolejnych etapów przygotowania projektu, od analizy biznesowej do początku procesu kodowania. Rozdziały są następujące:
- Wprowadzenie (cel biznesowy, opis obecnego i zmieniającego się procesu, opis techniczny itp.)
- (opcjonalnie) Opis pól formularza
- Makiety
- Historie użytkownika, kryteria akceptacji i scenariusze testowania
- Wymagania funkcjonalne
- Diagramy przypadków użycia
Wiem wystarczająco dużo i chcę szablon
Najważniejsze jest to, aby dokument był zbudowany w sposób wielofunkcyjny. Może on być (a właściwie powinien być) głównym punktem odniesienia dla programistów, testerów, grafików, właścicieli produktu i klienta. Posiadanie takiego dokumentu przynosi wiele korzyści:
- Pozwala to uniknąć chaosu. Wszystkie niezbędne informacje znajdują się w jednym dokumencie. Nie ma wątpliwości i błędnych kółek maili - gdzie umieściliśmy tę informację i która wersja jest właściwa? Czy w ogóle to zrobiliśmy?
- Wprowadzanie zmian do projektu jest dużo łatwiejsze i efektywniejsze. Ponieważ wszystkie specyfikacje, czyli user stories, kryteria akceptacji, scenariusze testowe i makiety są w tym samym miejscu, dużo mniej problematyczne jest modyfikowanie wszystkich części układanki projektowej w tym samym czasie. Gdy trzeba zmodyfikować user story lub kryteria akceptacji, można w tym samym czasie zmodyfikować odpowiednio scenariusz testowy - jest w tej samej tabeli. Makieta i specyfikacja pól formularza również nie są bardzo odległe.
- Wyżej wymieniona zaleta pociąga za sobą kolejną, bardzo ważną: znacznie mniejsze jest ryzyko niespójności pomiędzy poszczególnymi częściami analizy wymagań. Oznacza to, że dokument pomaga wszystkim zainteresowanym uniknąć niebezpiecznej sytuacji, w której np. scenariusz testowy nie odpowiada dokładnie kryteriom akceptacji, przez co na rynek trafia wadliwa aplikacja.
- Dobrze sporządzony dokument Wymagań Klienta może być wykorzystany jako specyfikacja przetargowa. Niektórzy mogą powiedzieć, że tworzenie tak szczegółowego dokumentu na stosunkowo wczesnym etapie projektu nie jest bezpieczne z biznesowego punktu widzenia. Ja widzę to inaczej. Kiedy tworzymy tak szczegółowy dokument, jest on zazwyczaj wysoko oceniany przez klientów i zwiększa ich ogólną ocenę naszej pracy. Myślę, że programiści powinni wręcz zachęcać swoich klientów do sprawdzenia cen konkurencji, korzystając z dostarczonego przez nich dokumentu wymagań klienta. W ten sposób pokazujemy naszą otwartość i zapewniamy ich, że nie muszą się martwić o ewentualne blokady ze strony dostawców.
Co ważne – dokument zdecydowanie powinien obejmować tylko jeden moduł, oznacza to budowę lub modernizację pojedynczej części aplikacji lub systemu, obejmując jedną, logiczną część procesu biznesowego – czy to zapisanie się do aplikacji, złożenie zamówienia , dokonanie płatności itp. Jeżeli zakres projektu jest ograniczony, że obejmuje tylko modyfikację pojedynczej cechy, można to opisać w jednym dokumencie wymagań. Jeśli projekt jest bardziej złożony, należy go podzielić na większą liczbę dokumentów wymagań klienta, a każdy z nich powinien zawierać informacje o tym, w jaki sposób zmiany wprowadzone w danym module wpływają na inne i jak zmiany wprowadzone w innych aplikacjach wpływają na ten projekt. konkretna część systemu. Małe aplikacje można zazwyczaj opisać w około 10 dokumentach wymagań, bardzo złożone mogą wymagać ich kilkuset. Budowanie dokumentów w ten sposób pozwala nam uniknąć zbytniego skomplikowania pojedynczego dokumentu przy jednoczesnym zapewnieniu spójności całej grupy dokumentów. Wszystkie dokumenty powinny mieć co najmniej dwuczęściową nazwę, która pozwoli wszystkim stronom łatwo zidentyfikować, do którego wniosku i do jakiej jego części odnosi się dokument.
Aby zapobiec pojawianiu się dzikich kopii dokumentu i zapewnić, że żadne zmiany w dokumencie nie pozostaną niezauważone, dokument powinien mieć tylko jedną kopię, przechowywaną w repozytorium aplikacji do zarządzania projektami, takiej jak Confluence lub Google Docs, która jest używana podczas pracy nad projekt. Wszelkie zmiany w dokumencie należy dodawać w trybie śledzenia, a następnie należy zastąpić starą kopię nową. Każdy interesariusz projektu powinien zgodzić się, że tylko raz wprowadzone zmiany w tej kopii będą obowiązywać.
Znaczenie rozdziału 1 - Wprowadzenie - jest raczej oczywiste. Skupia się on na opisie tła biznesowego i uzasadnieniu planowanej funkcjonalności. Co ważne - wszystkie punkty są istotne zarówno w nowych projektach, gdy oprogramowanie jest tworzone od podstaw, jak i w projektach zaawansowanych, gdy istotą projektu jest modyfikacja i dalszy rozwój funkcjonalności, które zostały wydane w przeszłości. W tym drugim przypadku punkt 1.2 opisuje aktualną funkcjonalność części aplikacji, która będzie modyfikowana. W pierwszym przypadku należy opisać sposób, w jaki dane czynności są obecnie wykonywane, tj. ręcznie lub za pomocą innej aplikacji, która ma zostać zastąpiona.
Jeżeli dokument jest częścią większej całości (jak wspomniano powyżej), składającej się z wielu podobnych dokumentów wymagań, powinien również zawierać przynajmniej jeden prosty diagram kontekstowy z krótkim opisem. Powinien on przedstawiać kontekst projektu wśród innych systemów i funkcjonalności, główne zależności między nimi, a przede wszystkim transfery danych. Schemat ten nie powinien być tak skomplikowany jak pełne diagramy przepływu danych. Jest to raczej widok z góry, pozwalający czytelnikowi zrozumieć rolę rozwijanej funkcjonalności wśród innych elementów systemu.
Mimo swojej oczywistości, historia rozdziału 1 (zwłaszcza punktu 1.1 - Cele biznesowe) jest skomplikowana. Przez pewien okres zdecydowałem się go wyciąć, ze względu na skargi zespołu programistów. Twierdzili oni, że nie są ani zainteresowani, ani nie mają czasu na studiowanie szczegółów biznesu klienta - potrzebują tylko historii użytkownika i kryteriów akceptacji, żeby wziąć się do pracy. Po kilku miesiącach wprowadziłem ten punkt z powrotem do dokumentu i teraz jestem już w 100% pewien, że nie pozwolę mu więcej zniknąć. Po pierwsze, z czysto ludzkiego punktu widzenia, kluczowe jest, aby cały zespół programistów rozumiał, co dana aplikacja ma robić. Jest to niezbędne, aby osiągnąć odpowiedni poziom zaangażowania i motywacji - aby wiedzieć, dokąd zmierzamy, jaka jest nasza wizja i jaki wpływ chcemy wywrzeć na rynek.
Po drugie, ta część jest bardzo ważnym punktem odniesienia w przyszłych rozmowach z klientem. Podczas długotrwałej pracy nad projektem człowiek ma tendencję do rozpraszania się i częściowego zapominania, jaki był właściwie sens całego przedsięwzięcia. Jeśli treść tego punktu ewoluuje w trakcie realizacji projektu (co w podejściu zwinnym jest jak najbardziej w porządku), podsumowanie pierwotnych celów biznesowych jest również bardzo ważnym punktem odniesienia, pozwalającym sprawdzić jak daleko jesteśmy od wstępnej wizji i jak głęboko ewoluujące potrzeby biznesowe powinny wpływać na aplikację. W tej części dokumentu powinny być wyszczególnione wszystkie ograniczenia wynikające z przepisów prawa i wewnętrznych procedur firmy. Jest to również właściwe miejsce na uwzględnienie - jeśli są istotne - zależności pomiędzy naszym projektem a innymi aplikacjami wykorzystywanymi przez organizację.
Pierwszym elementem, który dodałem do dokumentu był rozdział 4 - Historie użytkowników i scenariusze testowe. Rozdział ten zawiera najważniejsze dane, opis funkcjonalności, które powinny być rozwijane lub zmieniane w trakcie projektu. Zebrane razem powinny tworzyć czterokolumnową tabelę, podobną do tej z przykładu.
| Funkcjonalność | Tytuł | Historia użytkownika | Kryteria akceptacji |
| Dodawanie | Dodawanie przesyłki | Jako klient muszę podać swój adres i adres adresata, wydrukować etykietę do przyklejenia na paczkę i zamówić wizytę kuriera w dogodnym terminie. |
|
| Dodawanie przesyłki lokalnej | Jako klient chcę podać adres adresata w Polsce |
|
|
| Dodawanie przesyłki europejskiej | Jako klient chcę podać adres adresata znajdującego się na kontynencie europejskim, ale poza granicami Polski. |
|
|
| Dodawanie przesyłki międzynarodowej (poza Europę) | Jako klient chcę podać adres odbiorcy w kraju poza Europą |
|
W tej części należy podać co najmniej jeden typ funkcjonalności nazwany czasownikiem opisującym istotną czynność. Historie powinny być pogrupowane w taki sposób, aby każda grupa reprezentowała podobny typ operacji w zakresie ich logiki i miejsca w procesie biznesowym. Taka forma prezentacji pozwala nam na początku opisać części wspólne historie użytkownika oraz wspólne kryteria akceptacji, a następnie w każdej historii użytkownika opisać tylko te kryteria, które są specyficzne dla tej konkretnej historii.
O ile obecność historii użytkowników jest oczywista - stanowią one podstawową dokumentację każdego projektu - w tym scenariuszy testowych, to jest to coś, co wymyśliłem podczas rozmowy z developerami. Narzekali oni, że informacje zawarte w historiach użytkowników są zazwyczaj niekompletne i nieuporządkowane, przez co nie są w stanie wyprodukować funkcjonalności, które właściwie odpowiadają potrzebom klienta. Podczas spotkań demonstracyjnych klienci zazwyczaj znajdowali liczne rozbieżności pomiędzy produktem a swoją wizją. Oczywiście fakt, że wcześniej nie sprecyzowali dokładnie swojej wizji nie był dla nich żadnym wytłumaczeniem. I mieli rację. Zadaniem naszym, programistów, jest wyciśnięcie z zespołu klienta wszystkich ważnych informacji, zanim zaczniemy kodować.
Dostarczenie kompletnego zestawu historii użytkownika wraz z listą scenariuszy testowych jest bardzo skutecznym sposobem na pokonanie tego problemu. Scenariusze testowe powinny zawierać wszystkie niezbędne podróże użytkownika z odpowiednim wyjściem z aplikacji zgodnie ze specyfikacją, z tyloma wersjami tych podróży, ile jest kryteriów akceptacji - w szczególności wszystkie skrajne wartości zmiennych dostarczonych przez użytkownika.
Ktoś może zwrócić uwagę, że przygotowanie scenariuszy testowych dla wszystkich dostarczonych historii użytkownika i kryteriów akceptacji oznacza wyprodukowanie ogromnej ilości tekstu. Na przykład: Jeśli w projekcie mamy 30 historii użytkownika, każda z nich ma 5 kryteriów akceptacji i dwa typy wyjścia - pozytywne i negatywne. Oznacza to, że mamy 150 kryteriów akceptacji i nie mniej niż 300 scenariuszy testowych - czyli 100 lub więcej stron tekstu. To oczywiście za dużo, dlatego zalecamy tworzenie scenariuszy testowych w formie prostej tabeli zawierającej różne kombinacje danych wejściowych i wyjściowych, w tym komunikaty o błędach.
Przykład scenariuszy testowych
| Imię | Nazwisko | Telefon | Adres | Output | Wiadomość | ||
| John | Smith | +48503848555 | Warsaw, Al Ujazdowskie 5/6 | OK | Dziękujemy za udostępnienie danych! | ||
| John | brak | +48503848555 | Warsaw, Al Ujazdowskie 5/6 | Error | Twoje pole "nazwisko" nie może być puste. | ||
| brak | brak | +48503848555 | Warsaw, Al Ujazdowskie 5/6 | Error | Twoje pola "imię" i "nazwisko" nie mogą być puste |
itd.
Podsumowując, w ten sposób scenariusze testowe stanowią nie tylko materiał dla zespołu testerów, ale również cenną wskazówkę dla koderów. Mogą oni dowiedzieć się z nich, jak aplikacja powinna reagować na wszystkie krytyczne wartości podawane przez użytkownika. Tak napisana aplikacja powinna działać zgodnie z oczekiwaniami klienta - nie ma tu miejsca na żadne nieprzewidziane sytuacje.
Cóż... jest. Historie użytkowników plus scenariusze testowe są doskonałym punktem odniesienia do opisywania funkcji backendowych. Sprawy stają się trudniejsze, kiedy przechodzimy do projektowania frontendów i backoffice'ów. Historie użytkownika mogą opisać jak aplikacja powinna reagować, ale nie mogą opisać dokładnie jak powinna wyglądać. Kiedy pracujemy używając tylko historii użytkownika i scenariuszy testowych (nawet bardzo precyzyjnie napisanych), klienci wielokrotnie narzekają na sposób rozmieszczenia elementów na ekranie, na kolejność, wielkość poszczególnych części, na czcionki, których użyliśmy itp. Narażamy się na niekończący się potok pytań "Ale gdzie jest ....", albo "Ale dlaczego to tak wygląda?". No właśnie, dlaczego? Ponieważ tak właśnie zespół programistów wyobraził sobie aplikację na podstawie tego, co ma ona robić. Oczywiście, takie tłumaczenie nigdy nie sprawdza się w przypadku klientów i musimy przeprojektowywać interfejsy użytkownika metodą prób i błędów, prezentując klientom kolejne iteracje jedna po drugiej. Na tym etapie zrozumiałem, że aby zapewnić płynną współpracę musimy rozszerzyć dokumentację projektową o kolejny rozdział. Takim rozdziałem jest rozdział 3 - Makiety i projekty graficzne.
Praca na makietach ma wiele zalet. Po pierwsze - pozwala uniknąć sytuacji, w której programiści stworzą interfejs, który nie spodoba się klientowi. Po drugie - rysowanie ich jest doskonałą okazją dla zespołu developerskiego do przemyślenia wymagań klienta i ewentualnego znalezienia w nich niespójności. Po trzecie - równie ważne jak powyższe - makiety działają jako bardzo skuteczna pomoc wizualna, pomagając klientowi odświeżyć pamięć i zauważyć, że niektórych funkcjonalności brakuje, ponieważ zapomniał o nich wspomnieć podczas przygotowywania historii użytkownika i kryteriów akceptacji. O wiele lepiej i taniej jest usłyszeć pytanie typu "Ale gdzie jest coś?" na etapie przeglądu makiet niż na etapie przeglądu sprintu deweloperskiego. Dzięki makietom niejednokrotnie uniknęliśmy sytuacji, w której klient na etapie testów zauważył brak jakiejś istotnej funkcjonalności, zmuszając nas do przerabiania gotowych już części aplikacji. Im bardziej szczegółowe makiety - tym lepiej dla Ciebie. Powinny one pokazywać cały ekran interfejsu użytkownika, a nie tylko część, która będzie modyfikowana. Im więcej informacji, takich jak kody kolorów, dokładne wymiary, czcionki itp. - tym mniej poprawek będziesz musiał wprowadzić w przyszłości.
Rozdział 2 - Opis pól formularza nie jest moim autorskim wynalazkiem. Jest on odpowiedzią na ważną potrzebę testerów - jak sprawdzić, czy każde pole w formularzu wniosku jest przygotowane, aby dopuszczać tylko te dane, które mają odpowiedni format i rozmiar, a ich wartość mieści się w przewidywanym zakresie. Umieszczając ten punkt w dokumencie wypełniliśmy kolejną ważną lukę w procesie zbierania wymagań. Właściwe wartości każdego pola wynikają oczywiście bezpośrednio z funkcji tego pola, ale klienci powinni brać pod uwagę, że zespół programistów i testerów nie zawsze jest w pełni świadomy swoich ograniczeń biznesowych. Nie zawsze są w stanie przewidzieć, że pewne dane, które są poprawne z matematycznego lub gramatycznego punktu widzenia, mogą być niepoprawne z innych powodów. Kiedy otrzymują dokładną liczbę znaków, zakres znaków (litery lub cyfry lub oba), wzajemne zależności pomiędzy polami, lub czy treść powinna być sprawdzana słownikowo czy nie, testerzy mogą pracować znacznie efektywniej, uniknąć zadawania wielu niepotrzebnych pytań klientowi i/lub deweloperom, oraz znacznie skuteczniej wyszukiwać ewentualne błędy.
Wiele zostało już omówione, co ten dokument powinien zawierać, teraz nadszedł czas, aby powiedzieć kilka słów o informacjach, które są opcjonalne lub nie wchodzą w zakres dokumentu.
- Szczegółowa specyfikacja operacji REST lub SOAP API. Wystarczy zawrzeć bardziej ogólne informacje, jak np. jakie zapytania są potrzebne i jakie dane powinny być wymieniane. Oczywiście należy również uwzględnić to, w jakich historiach użytkowników te dane są wykorzystywane i jak powinny być reprezentowane w interfejsie użytkownika. Bez względu na to, czy stosujemy podejście contrast-first (gdzie definiujemy interfejs dokładnie przed implementacją, czy przeciwnie podejście contract-last) właściwym miejscem na szczegółową specyfikację jest dokument Swagger dla REST API lub WSDL dla SOAP.
- Wymagania niefunkcjonalne, jak np. ile jednoczesnych sesji aplikacja powinna być w stanie obsłużyć, jej czas odpowiedzi, skalowalność, wymagania bezpieczeństwa, liczne wymagania SLA, jak dostępność, średni czas naprawy, itp. Powinny być one umieszczone w osobnych dokumentach, które są wykorzystywane w procesie projektowania środowiska i platformy. Oczywiście, są one niezwykle ważne i nie powinny być pomijane.
- Wreszcie - należy pamiętać, że dokument wymagań nie jest podręcznikiem użytkownika. Podręcznik powinien być osobnym i znacznie bardziej zwięzłym dokumentem, skoncentrowanym ściśle na wyjaśnieniu znaczenia cech i przykładów ich użycia w różnych przypadkach biznesowych, z pominięciem wszystkich zbędnych szczegółów technicznych.
- Struktury danych. Opinie na temat umieszczania ich w dokumencie Wymagań Użytkownika nie są zgodne. Niektórzy twierdzą, że ta specyficzna architektura nie powinna być umieszczana w dokumencie Wymagań Klienta, gdyż zazwyczaj jest ona tworzona dynamicznie podczas fazy analizy technicznej i kodowania projektu. W praktyce, korzystne jest umieszczenie modelu danych, nawet jeśli jest to model wstępny, który będzie później modyfikowany w trakcie procesu wytwarzania. Przeglądanie oczekiwanych tabel i pól często otwiera oczy klientom i pomaga im uświadomić sobie wymagania, o których nie pomyśleli lub (niesłusznie) uznali za oczywiste. Na przykład: czy adres powinien być przechowywany w jednym ciągu tekstowym lub podzielony na osobne pola, takie jak ulica, numer domu, numer mieszkania, itp. Pierwszy sposób jest prostszy, ale drugi jest znacznie bardziej odporny na błędy i pozwala na znacznie bardziej zaawansowane operacje wyszukiwania i agregacji. Decyzje takie powinny być podejmowane na początku procesu tworzenia aplikacji, gdyż rearanżacja bazy danych, gdy aplikacja już działa, jest operacją stosunkowo skomplikowaną i kosztowną, a ponadto może generować wiele błędów. Wstępna struktura danych powinna być przygotowana przez analityka i sprawdzona przez specjalistę od baz danych lub programistę posiadającego dużą wiedzę na temat architektury baz danych, po ostatecznej akceptacji Wymagań Klienta. Podczas fazy kodowania, wszystkie niezbędne zmiany w strukturach danych (np. decyzja o podziale jednej tabeli danych na kilka mniejszych) powinny być następnie zawarte w osobnym dokumencie, który powinien być traktowany jako załącznik do Wymagań Klienta.