Dokumentowanie wymagań klienta

Dokumentowanie wymagań klienta
Polecane artykuły
Dokumentacja techniczna Zarządzanie zakresem wg PMBOK Plan komunikacji w projekcie Prototypowanie i modelowanie DMAIC Produkt projektu Karta projektu User stories Zmiana wg PRINCE2

Podstawą realizacji dowolnego projektu jest zaspokojenie potrzeb klienta, które pierwotnie wyrażają się w wymaganiach projektowych a następnie przekładają się na zakres projektu. Potwierdzony przez klienta zakres projektu jest podstawą do jego rozliczenia. Stanowi również punkt odniesienia w przypadku pojawiających się w trakcie realizacji pytań i wątpliwości. Zdefiniowanie wymagań jest więc jednym z pierwszych wyzwań, z jakimi musi zmierzyć się zespół projektowy. Jakość wykonanej na początku pracy rzutuje na sprawność realizacji każdego przyszłego działania projektowego.

TL;DR

Artykuł omawia znaczenie zaspokajania potrzeb klienta poprzez definiowanie zakresu projektu i dokumentowanie wymagań. Przedstawia różne metody pozyskiwania informacji od klienta, takie jak spotkania, dekompozycja wymagań i tworzenie prototypów. Omawia również różne sposoby dokumentowania wymagań, takie jak tabele, diagramy procesów biznesowych, przypadki użycia, notatki i prototypy.

Pozyskiwanie informacji od klienta

Wszystkie działania związane z definiowaniem zakresu projektu wymagają interakcji oraz współpracy klienta z menadżerem projektu, który zobowiąże się dostarczy produkt lub usługę. Współpraca może mieć charakter formalny (oficjalne spotkania, które kończą się notatką zwierającą zapis przebiegu spotkania), jak również nieformalny (luźna rozmowa w restauracji). Bez względu na formę, efektem musi być dokument udzielający odpowiedzi na pytania "Co trzeba będzie zrobić?” oraz "Skąd będzie wiadomo, że zostało to zrobione?”. Informacje te można pozyskać za pomocą narządzi, procesów i schematów, takich jak:

• Zdefiniowania warunków satysfakcji klienta
• Spotkania dotyczące zakresu projektu
• Dekompozycja wymagań klienta
• Moderowane sesje grupowe
• Diagramy procesów biznesowych
• Tworzenie prototypów
• Przypadki użycia

Sposoby dokumentowania wymagań==Istnieje wiele sposób dokumentowania wymagań klienta. Bez względu na formę, każda przekazana informacja powinna być przede wszystkim jednoznaczna. Konsekwencją pojawiania się pytań lub wątpliwości powinno być bieżące uściślanie wymagań. Metody zapisu informacji dotyczących wymagań są===Tabele=

Wymagania opisane za pomocą tabel powinny zawierać:

• numer referencyjny wymagania - za jego pomocą uproszczona zostaje komunikacja,
• dokładną i jednoznaczną treść wymagania - determinującą dalsze działania mające zaspokoić potrzebę opisaną w wymaganiu
• priorytet wymagania (MUST, SHOULD, COULD) - pozwalający ustalić, kolejność dokumentowania oraz implementowania rozwiązań,
• opis spełnienia lub odniesienie do tego opisu - służący do weryfikacji zrealizowanych produktów lub usług mających zaspokoić potrzebę.

Diagramy procesów biznesowych

Przedstawiają działania i zdarzenia występujące w procesie biznesowym. Modelowanie procesów zapisać można za pomocą kilku notacji, takich jak:

• Business Process Modeling Notation
• Event-Driven Process Chain
• Entity-relationship model
• Case Management Model and Notation
• Unified Modeling Language
• Data Flow Diagram Notation

Przedstawienie wymagań za pomocą diagramu możliwe jest poprzez wskazanie różnic pomiędzy stanem aktualnym a stanem docelowym. Wyraźnie widoczny jest wtedy obszar, który należy zmienieć. [TODO: Dodać przykładowy diagram]

Przypadki użycia

Pozwalają określić dokładne scenariusze opisujące dokładny sposób korzystania z systemów wspomagających pracę. Pełny przypadek użycia zawiera w sobie:

• identyfikator - symbol jednoznacznie identyfikujący przypadek
• nazwę - oznaczająca czynność jakiej dotyczy scenariusz,
• aktorów - osoby oraz systemy biorące udział w scenariuszu,
• warunki początkowe - opisujące wymogi dotyczące możliwości realizacji scenariusza (np. Posiadanie przez użytkownika odpowiednich uprawnień),
• warunki końcowe - opisujące efekt zrealizowanego scenariusza
• scenariusz główny - opis kroków przypadku użycia w formie dialogu operatora z systemem prowadzących do pozytywnego zakończenia,
• scenariusze alternatywne - opis scenariuszów neutralnych oraz negatywnych, nie prowadzących do osiągnięcia warunków końcowych,
• sytuacje wyjątkowe - takie jak obsługa błędów lub negatywnych odpowiedzi z systemów partnerskich.

Notatki

Notatki analityczne jest narzędziem dokumentującym wymagania nakreślane w trakcie wszystkich spotkań dotyczących potrzeb klientów. Przygotowywane są przez analityka oraz przesyłane są do wszystkich interesariuszy po spotkaniu. Po formalnym zatwierdzeniu przez uczestników notatka trafia do rejestru wymagań. Jest podstawą do stworzenia wpisu do rejestru wymagań (np. W formie tabeli), w którym wyraźnie zaznaczone jest pochodzenie wymagania.

Prototypy

Dostarczają szybkiego wizualnego modelu rozwiązania końcowego co umożliwia łatwo zidentyfikować brakujące lub błędnie wyspecyfikowane wymagania. Są użyteczne w przypadku mało i średnio skomplikowanych procesów, dla skomplikowanych procesów mogą być przerostem formy nad treścią (zbyt dużo czasu poświęci się wtedy na samo rysowanie niż przekazanie merytoryki wizualnych modeli). Przykładami prototypów mogą być:

• PoP (Proof of Principle) lub PoC (Proof of Concept) - skupia się on na projekcie systemu oraz technologii a nie na wyglądzie.
• Prototyp użyteczności - przedstawia ergonomię oraz użyteczność, testuje sposób interakcji operatora z systemem.
• Prototyp wizualny - ukazuje wizualny aspekt projektowanego rozwiązania.
• Prototyp funkcjonalny - weryfikuje funkcjonalne rozwiązania

Bibliografia

• Harold Kerzner, Harold R. Kerzner (2017). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. John Wiley & Sons, New Jersey
• Karolina Zmitrowicz (2015). Analiza biznesowa. Wymagania - pozyskiwanie, dokumentowanie, komunikowanie, weryfikacja
• Robert K. Wysocki (2013). Efektywne zarządzanie projektami. Wydanie VI, Wydawnictwo HELION, Gliwice

Autor: Joanna Szarlej