Jak wdrożyć analizę wymagań?

Jak wygląda proces planowania?

Analiza wymagań jest częścią procesu planowania, który z kolei powinien wyglądać następująco:

1. A projekt wizja, która opisuje ostateczny produkt do utworzenia.
2. Ogólny plan działania lub pomysł, który określa, co należy zrobić, aby osiągnąć nasze cele.
3. Lista podstawowych zadań, które określają etapy pracy nad projektem.
4. Planowanie czasu, w którym określamy, co i kiedy powinno zostać dostarczone.
5. Szczegółowe planowanie poszczególnych zadań stworzonych podczas etapu trzeciego.

Analiza wymagań obejmuje pierwsze trzy punkty procesu planowania.

Wizja projektu

Na tym etapie powinniśmy zadać sobie kilka podstawowych pytań:

1. Co chcemy zrobić?

Na pewno w tym momencie jesteśmy już świadomi do czego dążymy, a pomysł na projekt został już dawno przedstawiony i przemyślany, ale warto zastanowić się nad nim głębiej. Być może odkryjemy nowe kwestie, które warto wyjaśnić. Pomocne mogą być tutaj następujące zagadnienia:

• Jaki problem powinien rozwiązać ten projekt?
• Kto będzie jego użytkownikiem końcowym?
• Czy tworzymy interfejs dla użytkowników? Czy jego stworzenie jest planowane w przyszłości? Czy określono typ interfejsu, który tworzymy (desktopowy lub mobilny)? Czy zależy nam na RWD?
• Czy istnieją podobne aplikacje? Jakie są ich wady i zalety?
• Czy stworzono już wstępne projekty lub makiety dotyczące projektu?
• Czy projekt będzie zależał od zewnętrznych aplikacji? Czy mają one lub znamy ich ograniczenia?
• Czy wiemy coś na temat oczekiwanej wydajności i poziomu bezpieczeństwa?

2. Jakie są wymagania?

Teraz nadszedł czas na ustalenie listy wymagań stawianych projektowi. Oprócz wymagań funkcjonalnych określamy te niezwiązane z funkcjonalnością: użyteczność, responsywność, szybkość, wydajność i bezpieczeństwo.

Niech my sprawdzić, czy każde z wymagań spełnia poniższe kryteria:

• jest kompletny - mamy jego pełny obraz,
• jest prawidłowa - zgodna z prawdą i oczekiwana,
• jest wykonalne - wykonalne i inne wymagania nie negują tego,
• jest niezbędny - jest potrzebny do działania systemu lub jest wymagany przez klienta,
• jest jednoznaczna - czytelna i niemożliwa do błędnej interpretacji,
• jest weryfikowalny - po wdrożeniu, poprzez obserwację i testowanie, możliwe jest ustalenie, czy wymóg ten został spełniony, czy nie.

3. Jaki jest ostateczny cel?

Warto w tym miejscu stworzyć prostą wizualizację działania projektu. Nic tak nie pomaga w pełni zrozumieć idei projektu, jak narysowanie podstawowego flow lub po prostu rozpisanie na tablicy w punktach tego, co ma się po kolei wydarzyć. W przypadku aplikacji z interfejsem użytkownika idealną sytuacją jest posiadanie nawet najprostszych makiet.

4. Jakie są priorytety?

Podobnie jak w przypadku budowy domu, projekty informatyczne powinny na początku zaczynać się od zera, a następnie zwracać się ku temu, co jest najbardziej potrzebne. Na początku, na podstawie listy wymagań, należy więc określić listę wszystkich możliwych funkcji, które dany projekt będzie realizował, a następnie uzgodnić, które z nich mają najwyższy priorytet i mają być zrealizowane jak najszybciej, a które są typu "nice-to-have".

Rezultatem całego etapu wizualizacji projektu powinien być ogólny obraz tego, jak projekt powinien działać, czy to poprzez makiety, czy narysowany przepływ działań. Powinniśmy również otrzymać listę wszystkich możliwych funkcji, jakie dany projekt ma spełniać, a także wiedzieć, jaki priorytet ma każda z nich.

Wizualizacja projektu jest kluczowym momentem podczas analizy wymagań. Pomaga ona w dogłębnym zrozumieniu istoty problemu, a im lepsze materiały ilustrujące problem, tym sprawniejsze kolejne etapy planowania.

Plan działania

Na tym etapie określamy już, jak wyobrażamy sobie działanie projektu jako całości. Dobrze jest mieć kilka pomysłów na realizację, przemyśleć i przedyskutować każdy z nich, wskazać ich słabe i mocne strony. Warto też w tym miejscu szczegółowo rozrysować wybrany pomysł, jeśli nie wszystkie.

Ten etap to także czas na rozważenie kwestii czysto technologicznych, nie tylko w jakim języku czy frameworku zostanie napisany projekt, ale także jakich dodatkowych narzędzi będziemy potrzebować, np. czy zdecydujemy się na wykorzystanie AWS stack, a może coś innego. Jeśli wahamy się między jakimiś technologiami lub nie mamy pomysłu, z czego skorzystać, to warto taką decyzję przesunąć w czasie i oddelegować do zadania badawczego. Oczywiście możemy to zrobić tylko wtedy, gdy dalsze planowanie nie jest blokowane przez takie badania. W przeciwnym razie możemy śmiało podpiąć je pod zadania w planie. sprint.

Główne zadania

Po ustaleniu planu projektu przystępujemy do zdefiniowania głównych zadań, które następnie zostaną szczegółowo omówione i podzielone na mniejsze zadania przez zespół programistów podczas planowania nowego sprintu. Ważne jest, aby opisać każde zadanie tak dokładnie, jak to możliwe.

Podsumowanie

Jak wspomniano wcześniej, proces analizy wymagań będzie się różnił w zależności od złożoności projektu. Są problemy łatwiejsze i trudniejsze, są też takie, które zostały już przez kogoś rozwiązane i zupełnie nowe, nad którymi trzeba się dłużej zatrzymać. Niezależnie od tego, istnieje kilka ważnych wskazówek, o których należy pamiętać:

• Komunikacja. Jest to najważniejszy element każdego cyklu życia projektu; wszystko powinno być jasno zdefiniowane i wyjaśnione.
• Szybkie zrozumienie problemu. Świetnie jest mieć napisaną dokumentację projektu, ale pamiętajmy, by była ona jak najbardziej zwięzła i nie zajmowała tysiąca stron. Każdy członek zespołu zespół powinni mieć do niego dostęp i być w stanie szybko zrozumieć wizję projektu.
• Prostota przede wszystkim. Starajmy się, by to co planujemy było jak najprostsze, wybierajmy prostsze rozwiązania, które można łatwo rozwinąć w przyszłości, lub zrezygnujmy z nich, gdy zajdzie taka potrzeba.
• Nie będzie to potrzebne. Biorąc pod uwagę, że w programowaniu kierujemy się zasadą YAGNI, tutaj mamy to z tyłu głowy i nie przyspieszamy za bardzo.
• Zmiany. Nie bójmy się ich, każdy projekt prędzej czy później ich potrzebuje. Ponadto nie łudźmy się, że to, co zaplanujemy dziś, będzie działać wiecznie. Jednocześnie nie traktujmy zmian jako czegoś złego i niepożądanego. Zmiany powinny być synonimem poprawy, a o to nam przecież chodzi: by projekt był jak najlepszy.
• Czas. Nie pozwólmy, by planowanie trwało zbyt długo i przeciągało się w nieskończoność. Jeśli mamy problem, który nas blokuje, to szukajmy rozwiązań na zewnątrz lub wybierajmy najłatwiejszą opcję.

O powyższych aspektach warto zawsze pamiętać podczas analizy wymagań, a wtedy przebiegnie ona sprawnie i będzie podstawą dobrze zaplanowanego projektu.

Czytaj więcej:

• Jakie jest najlepsze podejście do zarządzania projektami związanymi z tworzeniem oprogramowania?
• Dobre praktyki Codest dotyczące tworzenia oprogramowania. Nasze podejście do customer journey
• Krótki przewodnik po budowaniu i rozwijaniu własnego rynku. Co warto wiedzieć?