analizawymagan

Raporty w analizie IT

Posted by admin

Wstęp

Raporty, raportowanie… Cały czas się przewija to jak trzeba i jak będzie raportowana praca danej osoby w systemie. W moim skromnym jeszcze doświadczeniu raportowanie odmieniłem już chyba przez wszystkie przypadki i na wszystkie sposoby. Dlatego postaram się opisać o czym trzeba pamiętać przygotowując i zbierając wymagania dotyczące raportu.

  1. Czy raport jest raportem?

Po pierwsze to musimy się dowiedzieć czy raport nie ma jakichkolwiek potencjalnych opcji edycji danych. Raport jest od wyświetlania danych. Potem z czasem wychodzą różne dziwne twory w serwisach raportowych powiązane z javascriptem które pozwalają na edycję danych.

Wszystko fajnie tylko w 95% przypadków taki „raport” napisał kolega który już nie pracuje od 3 lat każdy się boi cokolwiek w tym tworze zmienić i utrzymanie tego kosztuje wiele czasu i pieniędzy.

Jeśli raport ma biznesowe inklinacje do tego że dane wygenerowane z raportu mają być edytowane. To taki raport już nie jest raportem.

2. Cel biznesowy

Rzeczy która się przewija zawsze. Po co chcemy robić ten raport? Czy taki raport już nie istnieje?

3. Interaktywność raportu

Czy ma być filtrowanie? Czy raport ma być klikalny(jak kliknę w słupek wykresu to on ma zniknąć)? Czy kliknięcie w wykres ma nawigować do danych szczegółowych? Czy mam być przeniesiony z raportu w kontekst klienta?

Czy mam mieć możliwość natychmiastowego poinformowania o wyniku osoby trzecie? Itd. itd. Od stopnia interaktywności często dochodzimy do oceny czy chcemy raport czy może jednak funkcjonalność do oprogramowania w ramach jakiejś aplikacji biznesowej.

Kluczowa kwestia do poruszenia to fakt żeby nie pchać się na siłe w wykresy. Często jest tak że wystarcza jedna liczba, jeden dobrze wyliczony współczynnik. Zaawansowane wykresy nie są potrzebne i nie musimy na siłę pokazywać ze umiemy je wykonać.

4. Informacje do pokazania.

Lista danych, ich typ i ich przetwarzanie. Chcemy wykresy? Chcemy surową tabelę? Skąd pochodzą dane do raportu? Są aktualne? Mamy tam dostęp? Jak często dane się aktualizują w źródle?

Najlepszym sposobem jaki udało mi się wypracować na przestrzeni czasu to dotarcie do tego jakie decyzje chcemy podjąć na podstawie tego raportu i które dane są potrzebne do podjęcia decyzji. Wtedy nie pomijamy żadnych szczegółów oraz nie pakujemy danych nadmiarowych.

5. Liczba osób oglądających raport? Dla kogo ma być raport?

Kto go może zobaczyć? Kto nie może go zobaczyć? Jak wygląda sprawa bezpieczeństwa? Raport tylko w sieci czy online na zewnątrz?

Kto mógłby być zainteresowany odbiorem raportu? Raport zamawia jednostka X firmy a zainteresowani mogą być też z jednostek Y, Z, E, D, A i ludzie z jednostki X nawet mogą nie wiedzieć że podobne zapotrzebowanie jest w innych jednostkach.

6. Jak często raport powinien być odświeżany?

Raz dziennie? Raz na miesiąc? Online? Raport powinien być na żądanie użytkownika? Raport powinien być tworzony automatycznie i wysyłany do interesariuszy?

7. Wynik raportu powinien być możliwy do wyeksportowania do PDF, Excel, word?

8. Co jest tańsze do wykonania?

Raport czy wyświetlanie danych w aplikacji operacyjnej w odpowiedni sposób?

9. Historyzacja

Czy potrzebujemy danych historycznych? Jeśli tak to jak długo? Wystarczy bieżący rok czy musimy trzymać dane w archiwum o wiele dłużej. Kiedy dane powinny być przestać aktualizowane? „Mrozimy” bazę na koniec okresu czy dane powinny żyć swoim życiem przez dłuższy czas?

10. Paginacja

Jeśli mamy tabelę. To ile max wierszy na stronę? Ile kolumn? Kolumny można ukrywać/pokazywać? Jak mamy wykresy to które wykresy najpierw? Czy wykresy też poddajemy paginacji?

11. Layout raportu

Mamy standard layoutu w firmie? Raport powinien spełniać wymogi wyglądu?

Tesotwanie raportu

Pisząc przypadki testowe musimy założyć wszystkie warunki na które może natrafić raport:

  • Użytkownik i jego dostęp do raportu(kierownik widzi co innego niż dyrektor czy pracownik niższego szczebla)
  • Dostęp do raportu poza siecią
  • Performance raportu w zależności od obciążenia serwera
  • Zachowanie raportu w różnych okresach czasu(jak zamykamy miesiąc, jak mamy sezon urlopowy)
  • Testy poprawności danych
  • No i najważniejsze czy raport spełnia cel biznesowy(czy nie jest trudny w użytkowaniu? Czy nie zniechęca ilością klikania?) Trzeba spojrzeć na raport od punktu widzenia użytkownika. Czy raport dobrze wpasowuje się w dzień pracy użytkownika i wspomaga go w bieżącej pracy?

Podsumowanie

Trochę tego jest 😉 Polecam osobiście stosować do tego specjalnie przygotowaną chcecklistę aby nie pomijać jakiś czynników. Dzięki za przeczytanie i do zobaczenia w kolejnych postach. Napisz proszę w komentarzu czy nie pominąłem jakiegoś czynnika. Chętnie zaktualizuje wpis 🙂

Chcesz zostać Analitykiem IT? Kliknij w baner poniżej

DARMOWA checklista jakości wymagań!

Zapisz się na listę mailową a dam Ci za darmo checklistę jakości wymagań biznesowych.

Uzupełnienie powyższego pola stanowi zgodę na otrzymywanie od analizowac.pl newslettera zawierającego treści marketingowe. Zgodę można wycofać w każdym czasie. Wycofanie zgody nie ma wpływu na zgodność z prawem przetwarzania dokonanego przed jej wycofaniem.