Definicja wymagania, która będzie zrozumiała szczególnie dla początkujących analityków to jedno z największych wyzwań, jakie stoją przed osobami, które tworzą standardy światowe w zakresie inżynierii oprogramowania.
Dla osób z większym stażem każda z już funkcjonujących definicji jest zrozumiała, ponieważ potrafimy odróżnić potrzebę Klienta, którą słyszymy na pierwszych spotkaniach projektowych, od tego czego tak naprawdę potrzebuje Klient, aby rozwiązać swój problem.
Pytając Biznes i IT o to co rozumieją jako „definicja wymagania” usłyszymy różne stwierdzenia, co jest w pełni zrozumiałe, ponieważ każda ze stron patrzy na inne poziomy wymagań.
Biznes skupia się na potrzebie biznesowej i nie znając wszystkich możliwości systemowych opowiada swoimi słowami co chce.
Inżynier wymagań (analityk biznesowo-systemowy) pracujący po stronie IT na podstawie tego co usłyszał od Biznesu zaczyna zastanawiać się co system i w jaki sposób ma realizować, aby spełnić oczekiwania Biznesu.
Problem w tym, że wielu analityków niepoprawnie identyfikuje wymagania myląc je z regułami biznesowymi, bądź oczekiwaniami klienta, czasem pomijają wymagania pozafunkcjonalne.
A to tylko dlatego, że nie zastanawiamy się nad tym czym jest wymaganie, jaka jest hierarchia wymagań i jak prowadzić identyfikację wymagań na spotkaniu z Biznesem, aby otrzymać wszystkie informacje umożliwiające zespołowi zdefiniować zmiany w systemie, bądź systemach.
W artykule przedstawiam najczęściej spotykane definicje wymagań opatrzone moim komentarzem. Z artykułu dowiesz się czym jest hierarchia wymagań i dlaczego jest tak istotna.
1. Definicja wymagania
Poniżej zaprezentowałam najczęściej spotykane stwierdzenia określane jako definicja wymagania.
“1.Warunek lub zdolność potrzebna interesariuszowi do rozwiązania problemu lub osiągnięcia celu.
2.Warunek lub zdolność, które musi spełniać lub posiadać system lub komponent systemu, spełnienie warunków umowy, normy, specyfikacji lub innych formalnie narzuconych dokumentów.
3. Udokumentowane przedstawienie stanu lub zdolności, jak w punkcie 1 lub 2.”
Definicja ze standardu IEEE Std. 610.12-1990 (Standard ten został zastąpiony przez standard IEEE/ISO/IEC 24765-2017)
Mój komentarz: Definicja wymagania jak najbardziej pełna, ponieważ pokazuje czym jest wymaganie biznesowe (punkt 1) oraz wymaganie względem systemu (punkt 2). Nie rekomenduję tej definicji osobom początkującym, ponieważ rozpoczynając pracę z wymaganiami trudno zrozumieć czy to co mówi nam Klient na spotkaniu jest wymaganiem czy może zbiorem zasad, z którymi musimy dalej pracować, aby wyjść na wymaganie.
“Stwierdzenie, które tłumaczy lub wyraża potrzebę oraz związane z nią ograniczenia (1) i warunki (2).”
(1)Poprzez ograniczenia rozumiane są czynniki, które są nałożone na rozwiązanie, bądź projekt, które mogą go modyfikować.
(2) mierzalny atrybut jakościowy lub ilościowy, który jest określony dla wymagania.
Definicja z ISO/IEC/IEEE 29148: 2018-11 (Second edition)
Mój komentarz: Dla osób doświadczonych jest to jedna z trafniejszych definicji. Podobnie jak w przypadku definicji ze standardu IEEE 610.12-1990 nie rekomendowałabym tej definicji dla osób początkujących.
Przykłady “ograniczeń”:
Sformułowanie 1: “Rozwiązanie musi być dostarczone do [data]”,
bądź
Sformułowanie 2: “Rozwiązanie musi być gotowe na moment obowiązywania Ustawy art.XX z dnia DD.MM.RRRR”.
Takie sformułowania powodują, że w większym stopniu skupiamy się na tym, aby rozwiązanie realizowało niezbędne funkcje, które zostały zdefiniowane przez Biznes (sformułowanie 1), bądź wynikają z zapisów prawa (sformułowanie 2). Nie oznacza to, że nie zastanawiamy się nad możliwościami usprawnień rozwiązania, które projektujemy. Jednak analiza potencjalnych docelowych rozwiązań najczęściej odbywa się w II fazie projektu, czyli po oddaniu już działającego rozwiązania.
Takim charakterystycznym przypadkiem było wdrożenie JPK (Jednolity Plik Kontrolny) czy dostosowanie rozwiązań do Rozporządzenia RODO (Ochrona Danych Osobowych Osób Fizycznych), a szczególnie aspektów związanych z anonimizacją danych.
W przypadku JPK w pierwszym kroku należało przygotować rozwiązanie umożliwiające wygenerowanie pliku z danymi zgodnymi z narzuconą przez Ministerstwo Finansów strukturą. Drugorzędną kwestią (w tym przypadku) było zautomatyzowanie wysyłki wygenerowanych plików. Choć niektórym firmom udało się dostarczyć tą funkcję w pierwszym kroku.
Podobna sytuacja była z anonimizacją w RODO. W celu uniknięcia zanonimizowania danych klientów, którzy nie powinni być zanonimizowani często decydowano się na “półautomat”, czyli system generował dane zgodnie z zaimplementowanymi regułami . W drugim kroku osoba sprawdzała poprawność danych, dzięki czemu w wielu przypadkach udało się “wyłapać” wyjątki, czy nowe reguły. W ostatnim kroku projektu zautomatyzowano anonimizację danych.
Co może być jeszcze ograniczeniem? Chociażby wersja przeglądarki (w przypadku rozwiązań webowych), na którą musi być dostarczone rozwiązanie. Różnica między przeglądarkami na pierwszy rzut oka nie wydaje się duża. Zabawa zaczyna się, jeśli chcemy skonfigurować elementy rozwiązania za pomocą przeglądarki. W niektórych przeglądarkach pole tekstowe nie da się rozszerzyć, co uniemożliwia korzystanie z funkcjonalności w sposób “user friendly”.
Zwróć uwagę w definicji na punkt 2, w którym poruszana jest kwestia warunków, a dokładniej atrybutów wymagania. W najprostszym tłumaczeniu chodzi o to, że każde wysokopoziomowe wymaganie musi mieć co najmniej jeden element, na podstawie którego będzie można przetestować wymaganie. Ściślej mówiąc: każde wymaganie funkcjonalne musi mieć co najmniej jedno wymaganie pozafunkcjonalne, dzięki czemu znamy charakterystykę produktu.
“Wymagania stanowią specyfikację tego, co powinno zostać zaimplementowane. Opisują, jak powinien zachowywać się system, albo określają jego właściwości lub atrybuty. Mogą nakładać ograniczenia na proces tworzenia systemu”
I. Sommerville & P. Sawyer
Mój komentarz: Jest to moja ulubiona definicja wymagania, którą polecam szczególnie osobom początkującym. Choć głównie definicja skupia się na wymaganiach systemowych (funkcjonalnych i pozafunkcjonalnych), brakuje tu warstwy wymagań biznesowych, które dopełniłyby całości definicji.
“Definicja potrzeby lub celu klienta albo warunków bądź możliwości, którymi powinien cechować się produkt, aby zaspokoić ową potrzebę albo cel. Właściwość, jaką musi posiadać produkt, aby miał wartość dla interesariusza”
K.Wiegers, J.Beatty
Mój komentarz: Jeśli do tej definicji dodamy definicję “interesariusza” jaką zaproponował Tom Gilb:
“Każda osoba, która ma interes w projekcie IT. Interesariuszami projektu są osoby i organizacje, które są aktywnie zaangażowane w projekt, lub których interesy mogą zostać naruszone w wyniku realizacji lub ukończenia projektu.”
Definicja wymagania nabiera szerszego znaczenia i będzie oznaczała wielowymiarowość wymagań.
Dla:
Biznesu- wymaganiem będzie spełnienie potrzeby biznesowej
Programisty i Testera- wymaganiem będzie informacja co system musi umieć zrobić oraz jakie elementy ograniczające rozwiązanie muszą być uwzględnione w tym rozwiązaniu.
2. Kategoryzacja wymagań
Wiedząc jaka jest definicja wymagania musimy odpowiednio skategoryzować rodzaj informacji, jakie udało nam się zidentyfikować rozmawiając ze wszystkimi zainteresowanymi stronami (interesariuszami: Biznes, programista, tester, bądź inni członkowie zespołu produktowego).
Znając kategorie wymagań łatwiej jest nam sprawdzić czy posiadamy wszystkie informacje, aby rozpocząć dalszą pracę analityczną.
Wymagania możemy podzielić na 3 podstawowe kategorie: wymagania biznesowe, wymagania interesariuszy, wymagania rozwiązania (wymagania funkcjonalne i pozafunkcjonalne). W zależności od opracowań powyższa kategoryzacja może zostać rozszerzona o dodatkowe kategorie takie jak: wymagania przejścia czy ograniczenia (biznesowe, rozwiązania).
Certyfikacja IQBBA wyróżnia dodatkowo takie kategorie jak: założenia biznesowe czy techniczne. Osobiście uważam zaproponowane dodatkowe kategorie za nadmiarowy zabieg, ponieważ założenia biznesowe są podstawą do zdefiniowania wymagań biznesowych.
Wymaganie biznesowe – opisują korzyści biznesowe, jakie organizacja chce osiągnąć. Wymagania biznesowe skupiają się na celach biznesowych. W treści wymagania biznesowego nie powinno być elementów systemowych, lecz cel biznesowy. W celu zidentyfikowania wymagania biznesowego zastanów się wspólnie z Biznesem: “Co organizacja chce osiągnąć?”. Przykład: “Skrócenie czasu realizacji zamówienia o 10% od stanu obecnego”
Wymaganie interesariuszy – opisują cele oraz korzyści biznesowe, jakie osiągną użytkownicy systemu. Opisują co użytkownicy będą mogli robić za pomocą systemu. Często można spotkać się z określeniem: wymagania biznesowe interesariuszy. Przykład: “Otrzymanie powiadomienia o nowym zamówieniu do realizacji przez Magazyn”.
Wymaganie rozwiązania :
- wymagania funkcjonalne– opisują zachowania opisywanej funkcji rozwiązania, które realizują wymagania biznesowe. W celu łatwiejszej identyfikacji wymagania funkcjonalnego zadaj sobie pytanie: “Co funkcja musi umieć robić?”
- Pozafunkcjonalne– są dopełnieniem wymagań funkcjonalnych opisując cechy rozwiązania pod kątem jakościowym, np. wydajności czy niezawodności. Pomocnym pytaniem podczas identyfikacji tych wymagań: “Jako dobrze system ma to robić? W jaki sposób?”. W zależności od produktu, jaki tworzymy liczba wymagań pozafunkcjonalnych będzie się różnić. Zgodnie z modelem jakości zaproponowanym w standardzie ISO/IEC 25010:2011 wymagania pozafunkcjonalne to 8 grup cech jakościowych:
- Odpowiedniość funkcjonalna (kompletność, poprawność, odpowiedniość)
- Zgodność
- Użyteczność
- Niezawodność
- Bezpieczeństwo
- Łatwość utrzymania
- Przenośność
- Wsparcie
3. Od których wymagań rozpocząć analizę?
Chciałoby się klasycznie powiedzieć: “To zależy”. Ale faktycznie tak jest. Musisz znać hierarchię wymagań, czyli:
- wymaganie biznesowe
- wymaganie interesariuszy
- wymaganie funkcjonalne
- wymaganie pozafunkcjonalne.
W zależności od tego co powiedział Biznes w rozmowie z Tobą, Twoje kolejne pytanie będzie wynikało z tego gdzie zaklasyfikowałeś wypowiedź Biznesu w hierarchii wymagań (zwróć uwagę na to czy przypadkiem nie rozmawiacie o regule biznesowej a nie wymaganiu).
Jeśli Klient mówi: “System musi umożliwiać mi oznaczenie MPP (mechanizmu podzielonej płatności) na wystawianej fakturze” to wiedz, że rozmawiacie o wymaganiu funkcjonalnym.
W pierwszym kroku musisz skierować rozmowę na wymagania biznesowe, aby dowiedzieć się co chcemy osiągnąć. W tym konkretnym przypadku biznes chce osiągnąć zgodność z przepisami i to jest cel biznesowy. Aby ten cel zrealizować system musi mieć funkcje umożliwiające: ręczne oznaczenie MPP, mechanizm sprawdzający czy wystawiona kwota na FV spełnia wymogi MPP (mimo, że użytkownik ręcznie nie zaznaczył takiej opcji) itd.
W kolejnym kroku zastanawiasz się w jaki sposób użytkownik chce pracować z daną funkcjonalnością, dzięki czemu zespołowi łatwiej będzie zaprojektować usługę, na końcu zostają wymagania pozafunkcjonalne, które z uwagi na kategoryzację są łatwe do identyfikacji, ponieważ za pomocą checklisty sprawdzasz, które z cech muszą być spełnione.
Hierarchia służy nam do tego, aby zapytać o wszystkie aspekty wszystkich interesariuszy projektu. Ważna uwaga! Biznes również może a nawet często definiuje wymagania pozafunkcjonalne, które mogą wynikać z polityki bezpieczeństwa firmy czy Księgi Identyfikacji Wizualnej. Twoim zadaniem jest zebranie informacji, uporządkowanie ich i sprawdzenie czy to co powiedział Klient referuje do celu biznesowego.
