Już ponad 3 000 klientów ebooka. 
Ściąga z EXCELA dla każdego - SETKI przykładów funkcji otrzymasz w 3 minuty.
ZOBACZ EXCEL EBOOK >

Jak napisać specyfikację wymagań biznesowych

Wykorzystywanie dedykowanego oprogramowania może znacząco uprościć i przyspieszyć realizację wybranych procesów w firmie – np.: archiwizowania danych, raportowania, analizy, komunikacji, reklamy, itd. Jednakże zanim taka aplikacja zostanie wdrożona lub zmodyfikowana, przydatne jest spisanie wymagań biznesowych. Dokument ten może przybrać rozmaitą formę i być w różny sposób nazywany – można spotkać się z takimi określeniami jak np.: „specyfikacja biznesowa”, „analiza wymagań”, „wymagania funkcjonalne”, „potrzeby biznesowe”, itd.

Wiele osób może w tym miejscu oczywiście stwierdzić, że wdrożyło z sukcesem wiele aplikacji, a przy tym nigdy żaden dokument nie powstawał („pracują agile’owo” w końcu ;). I to jest prawda. Bez takiego opracowania da się obejść. Ale moim zdaniem jest ono bardzo przydatne i pomocne – w szczególności gdy dochodzi do sytuacji konfliktowych. Bo jak ktoś to ładnie powiedział – umowy tworzy się na czas wojny, a nie pokoju.

Cele specyfikacji biznesowej

Zanim przejdę do opisu tego, co powinna zawierać specyfikacja, zacznę od krótkiego wprowadzenia, czyli: po co się ją piszę, co się z nią dalej dzieje. Jaki jest zatem cel pisania specyfikacji wymagań?

Otóż może ona być wykorzystana na liczne sposoby. Z jednej strony może być ona podstawą pracy zespołu projektowego, który w jednym dokumencie może spisywać wszystkie potrzeby zgłoszone z różnych departamentów firmy. Plik z wymaganiami biznesowymi może krążyć wtedy po firmie, dzięki czemu można zapobiec sytuacji, w której ktoś o czymś nie wiedział.

Z drugiej strony specyfikacja wymagań jest często nieodłącznym elementem zapytania ofertowego (czasami dopiero po podpisaniu umowy o zachowaniu poufności), dzięki któremu można sprawdzić m.in.:

  • czy istnieje na rynku aplikacja, która realizuje wszystkie cele postawione przed projektowanym rozwiązaniem;
  • czy w ogóle firmę stać na wdrożenie – na podstawie opracowanej specyfikacji potencjalni dostawcy opracowują wycenę i szacują pracochłonność projektu, te dane można potem zestawić z dostępnym budżetem.

Wymagania biznesowe to pochodne celów i założeń projektu

Pierwsze wersje specyfikacji wymagań mogą przyjmować nawet bardzo roboczy charakter. I wcale nie jest wymagana od autora specjalistyczna wiedza na temat inżynierii oprogramowania. W główniej mierze chodzi o spisanie podstawowych elementów, które określą ramy projektu, jego główne cele i założenia.

Napisanie tego dokumentu przez kogoś z wewnątrz firmy, a nie zewnętrznego konsultanta, przynosi szereg korzyści – nie tylko finansowych. Chociaż wynajęcie w tym celu specjalnej firmy też ma swoje zalety.

Co się dzieję później ze specyfikacją?

Ścieżki mogą być różne. Zazwyczaj na dalszych etapach prac ten dokument trafia do Analityka Biznesowego (zatrudnionego w przedsiębiorstwie lub wynajętego przez firmę wdrożeniową), który przekłada wymagania biznesowe na język bardziej przyjazny i zrozumiały dla programistów. Powstają wtedy diagramy UML, opisywane są szczegółowo dane, moduły, obiekty, wzajemne powiązania między nimi, doprecyzowane są kwestie integracji z innymi systemami, itd.

Następnie taki dokument może trafić bezpośrednio do programisty, ewentualnie przy bardziej złożonych aplikacjach przejść jeszcze przez ręce Architekta, którego zadaniem jest zaproponowanie optymalnej architektury rozwiązania i sposobu jej wdrożenia.

Mówiąc prościej Analityk Biznesowej definiuje „co” ma być dokładnie zrobione, a Architekt określa „jak” ma to być wykonane. Po zakończeniu wdrożenia Analityk Biznesowy przekazuje zleceniodawcy (jeżeli przewidziane to zostało w umowie) pełną dokumentację funkcjonalną wdrożonego rozwiązania. Dokument ten jest pełnym opisem oprogramowania i stanowi przy późniejszych pracach podstawę do jego modyfikacji lub rozwoju.

Można również spotkać się z sytuacją, kiedy specyfikacja biznesowa napisana przez „zwykłego” pracownika trafia bezpośrednio do programisty, developera lub webmastera, którzy bez żadnych pośredników przekładają spisane tam wymagania na końcowe rozwiązanie. Bo w końcu wdrożenie nowego oprogramowania to nie tajemnicza alchemia tylko coś, z czym można sobie poradzić nie będąc informatykiem, o ile tylko wie się czego się chce…

Konstrukcja specyfikacji wymagań

Nie ma odgórnego, powszechnie obowiązującego, standardu tworzenia specyfikacji wymagań biznesowych – jest on uzależniony od kształtu samego systemu, dostępnego czasu, budżetu, wewnętrznych procedur, itd. Generalnie mówiąc, specyfikacja wymagań ma za zadanie zebrać w jednym dokumencie, napisanym w sposób zrozumiały i uporządkowany, wszystkie funkcjonalności, jakie ma posiadać aplikacja.

Nieodłączną cechą każdego projektowanego rozwiązania jest nieustanna zmienność wymagań. Często się zdarza, że jedno spotkanie lub rozmowa telefoniczna powodują, że należy wprowadzić istotne korekty we wcześniej przygotowanym opracowaniu. W rezultacie specyfikacja jest dokumentem dynamicznym – i na bieżąco powinny być tam rejestrowane wymagania i wszelkie zmiany wcześniejszych założeń.

Specyfikację wymagań można podzielić na dwie części:

  • wymagania funkcjonale
  • wymagania niefunkcjonalne

Na te wymagania z kolei składają się wymagania pochodzące ze strony pracowników „biznesowych” (marketing, sprzedaż, logistyka,…), którzy zazwyczaj są też końcowymi użytkownikami aplikacji, jak i reprezentantów działów IT, którzy po wdrożeniu często przejmują opiekę nad systemem. Konsultacje z tymi drugimi jest oczywiście jak najbardziej wskazana. Niejednokrotnie wymagania biznesowe i techniczne się wzajemnie przenikają, dlatego dobrze jest jak spisywane są jednocześnie i wzajemnie porównywane.

Wymagania funkcjonalne wobec aplikacji

Na wymagania funkcjonale składają się m.in. następujące elementy:

  • opisana ogólna wizja systemu, cele jakie ma spełniać oraz kontekst jego powstania (np. jakiego typy problemów zostały zdefiniowane w firmie, z jakiego typu trudnościami wiąże się brak aplikacji, itd.)
  • opis użytkowników (aktorów, grup) i ich uprawnień (ról) – innego typu uprawnienia mogą mieć Administratorzy, którzy będą opiekować się aplikacją, inne kierownicy, a inne szeregowi pracownicy;
  • opis funkcji systemu oraz sposoby korzystania z niego przez każdego z aktorów, tj. jakie procesy w nim wykonuje;
  • opis formularzy, wyświetlanych danych i operacji na nich wykonywanych;
  • zakres domyślnych raportów, które będą mogły być automatycznie generowane.

Przypadki użycia – przykład funkcjonalności

Dobrą praktyką jest spisywanie wymagań biznesowych w postaci tzw. „przypadków użycia” – ponumerowanych, pogrupowanych i jednoznacznie ponazywanych. Przypadki użycia (w skrócie UC od „use case”) koncentrują się na przedstawianiu interakcji pomiędzy użytkownikiem (aktorem), a systemem. Każdy przypadek użycia to opisana prosta sekwencja kroków – tj. zdarzeń zainicjowanych przez użytkownika i zadań wykonywanych przez system. Przykładowy przypadek użycia mógłby wyglądać następująco:

UC1. Wprowadzenie danych nowego klienta:

  1. Handlowiec otwiera formularz oraz wprowadza dane nowego klienta
  2. System weryfikuje poprawności wprowadzonych danych.
  3. System sprawdza, czy nie występuje duplikacja danych.
  4. System zapisuje dane klienta w bazie danych i nadaje mu numer.

Wymagania techniczne i niefunkcjonalne

Jak już zostało wspomniane wymaganiom biznesowym mogą towarzyszyć wymagania techniczne nakładane na oprogramowanie. W wielu przypadkach okazuje się, że można je spisać podczas jednego spotkania z pracownikiem działu IT, który jest w stanie przedstawić zasady i politykę firmy wobec nowych aplikacji. Specyfikacja techniczna może zawierać przykładowo:

  • opis środowiska, w którym nowym system będzie funkcjonował, np.: systemy operacyjne stacji roboczych przyszłych użytkowników (Windows, Linux, iOS), przeglądarki internetowe (jakie?), klienci pocztowi wykorzystywani w organizacji;
  • opis systemów, z którymi będzie zintegrowany (wymagania, ograniczenia);
  • opis sposobu logowania użytkowników,
  • zasady dostępu przez VPN i urządzenia mobilne, itd.

Wymagania niefunkcjonalne to wszelkiego typu ograniczenia nakładane na budowane rozwiązanie, które nie wiążą się bezpośrednio z zadaniami, które ona wykonuje. Jednakże są one często nie mniej istotne niż wymagania funkcjonalne. Przykładowym wymaganiem tego typu są parametry jakościowe stawiane przed aplikacją, np. określenie średniego czasu, w jakim ma się otwierać wywołany przez użytkownika interfejs (może on się w końcu otwierać 1 sekundę lub 10).

Elementem, na który warto zwrócić uwagę, jest precyzyjne opisanie w specyfikacji sposobu, w jaki będzie sprawdzane, czy dane wymaganie niefunkcjonalne jest spełnione. Przykładami wymagań niefunkcjonalnych mogą być informacje o:

  • maksymalnej ilości użytkowników, którzy będą mogli w jednym czasie swobodnie korzystać z aplikacji;
  • maksymalnym czasie wdrożenia oraz deadline na uruchomienie;
  • wymaganiach wobec dokumentacji, która ma zostać opracowana przez wykonawcę (np.: projekt architektury informatycznej, projekt migracji danych, specyfikacja sprzętowa, specyfikacja funkcjonalna, harmonogram wdrożenia, instrukcje dla użytkowników itp.)
  • oczekiwaniach wobec dostawcy, co zadań przez niego wykonywanych po samym wdrożeniu (np. szkolenia dla pracowników, gwarancja, zakres wsparcia powdrożeniowego, SLA, itp.)
  • zasadach bezpieczeństwa (back-up danych, itp.);
  • sposobie obsługi niedostępności serwera;
  • kolorystyce interfejsów (lub zasadach umieszczania logo firmy).

Uzupełnieniem specyfikacji mogą być różnego rodzaju załączniki, zawierające przykładowo:

  • szkice formularzy,
  • wzorce dokumentów generowanych automatycznie (raporty, faktury,…)
  • przykładowe dokumenty, które są obecnie „w obiegu”, a które mają być zastąpione przez aplikację.
  • procedury obowiązujące w firmie (np. procedura bezpieczeństwa).

Na co warto zwrócić uwagę tworząc specyfikację biznesową?

Najczęstsze błędy popełniane przy tworzeniu specyfikacji wymagań biznesowych to:

  • brak jasno sprecyzowanych priorytetów stawianych przed aplikacją. Powinno być jasno opisane, które elementy mają kluczowe znaczenie, a które drugorzędne.
  • nadmierność wymagań – w trakcie konsultacji wewnątrz firmy i spotkań z różnymi pracownikami można bardzo łatwo natrafić na prawdziwy koncert życzeń i prześciganie się w coraz to bardziej oryginalnych pomysłach na to, jakie zadania i funkcje ma aplikacja realizować. Cele powinny być jasno zdefiniowane – a jeżeli jakieś wymaganie nie jest odpowiedzią na żaden z celów to powinno być usunięte z listy. Bardzo łatwo stworzyć skomplikowaną aplikację – ale o wiele trudniej jest przekonać innych pracowników do jej użytkowania.
  • brak umiejętności przełożenia „myśli na papier” – pisanie w sposób ogólnikowy, skrótowy. Zdarza się, że autor specyfikacji wychodzi z założenia, że wszyscy się domyślą o co mu chodzi – a jeśli nie to się zapyta. Tylko, że potem nie ma już czasu na pytania i doprecyzowanie. Brak jednoznaczności wymagań prowadzi często do licznych nieporozumień i nerwów. W sytuacjach spornych z dostawcą, w pierwszej kolejności odwołuje się do specyfikacji, jeżeli coś zostanie tam niedokładnie opisane to istnieją duże szanse na to, że zostanie także niedokładnie odwzorowane w aplikacji;
  • brak dokładnej analizy problemu, który aplikacja ma rozwiązać. Bywa tak, że aplikacja wcale nie jest rozwiązaniem, gdyż problem leży gdzie indziej;
  • niekonsultowanie dokumentu z innymi działami firmy. W pierwszej kolejności należy zdefiniować wszystkich interesariuszy, których będzie dotyczyć budowane rozwiązanie. Każdy z nich powinien się wypowiedzieć, a następnie zatwierdzić zakres wymagań;
  • pomijanie wymagań niefunkcjonalnych;
  • skoncentrowanie się na wymaganiach technicznych, a nie na ludziach i ich potrzebach. Konsekwencją tego błędu jest sytuacja, kiedy zbudowana aplikacja jest poprawna technicznie, ale nie spełnia oczekiwań w niej pokładanych (mówiąc krócej – jest bezużyteczna);
  • powtórzenia, sprzeczności, brak uporządkowanej struktury dokumentu (np. pomieszczane wymagania z różnych obszarów). Dokument specyfikacji powinien mieć swoją logikę, jasny podział na rozdziały – np. wg. poszczególnych modułów aplikacji;
  • używanie niezrozumiałej terminologii i brak objaśnień/ słownika na końcu dokumentu;
  • niekompletność, wychodzenie z założenia, że wszystkie wymagania spisze się dopiero na etapie projektu, ewentualnie nie będzie problemu z dodaniem kolejnych funkcjonalności (problemu zwykle nie ma tylko, że po tym jak zostanie zatwierdzony zakres i budżet projektu, każda dodatkowe wymaganie to dodatkowe koszty, na które niekoniecznie będzie zgoda);
  • brak zebranych potwierdzeń („okejek’) ze strony managmentu dla końcowej wersji specyfikacji. Praktyka pokazuje, że wiele osób ma zaskakującą skłonność do częstego zmieniania zdania – i nie ma co z nimi bazować na ustnych ustaleniach. Szczególnie, gdy w grę wchodzą duże pieniądze.

Pytanie...
Korzystasz z EXCEL lub PowerPoint?
Poznaj setki praktycznych przykładów!
500 funkcji Excel + 500 slajdów PowerPoint

Zobacz podręcznik =>

4 komentarze do “Jak napisać specyfikację wymagań biznesowych”

    • myślałem nad opracowaniem takowego, ale zauważyłem, że w internecie jest sporo już ciekawych przykładów. Najlepiej w google’a wpisać anglojęzyczne terminy, a wyskoczy sporo gotowych wzorców. Przykładowe terminy to: „business specification template”, „business requirements”. Do podanych fraz można także dodać pdf/ excel/ doc – a wyskoczą już konkretne pliki.

      Odpowiedz
  1. Wspaniały dokument. Unikalne podzielenie się wiedzą w pigułce. Lista błędów to prawdziwy coaching. Dziękuję w imieniu wszechświata i jasnej strony mocy )

    Odpowiedz

Dodaj komentarz

X