Autor

Monika Perendyk

Trener, wykładowca, praktyk

Atrybuty wymagania, bo opis wymagania to za mało

8 lutego 2021 • 20 minut

Po zdefiniowaniu wymagania, bez względu na to czy jest to wymaganie biznesowe, czy wymaganie względem produktu musimy zdefiniować atrybuty takiego wymagania. Dlaczego jest to takie ważne? Bo opis wymagania to za mało, aby szybko otrzymać informację w jakiej kolejności wdrażać wymagania, czy które z wymagań zostały już zatwierdzone przez Klienta?

1. Czym jest atrybut wymagania?

Wymaganie to nie tylko tekst, ale przede wszystkim dodatkowe informacje, które pozwalają na odróżnienie danego wymagania od innych wymagań oraz umożliwiają lepsze zarządzanie zakresem projektu. Takimi dodatkowymi informacjami są atrybuty wymagania.

“ Cecha jakiejś rzeczy, osoby lub zjawiska wyróżniająca je spośród innych”

Słownik Języka Polskiego (2020)

“Atrybuty umożliwiają uporządkowanie informacji związanych z pojedynczym wymaganiem w celu ułatwienia przetwarzania, filtrowania, sortowania itp. Atrybuty mogą być wykorzystywane do wspierania wielu umiejętności związanych z inżynierią wymagań, umożliwiając sortowanie wymagań lub wybieranie ich do dalszych działań oraz umożliwiając kontrolowanie samego procesu tworzenia wymagań”

(Hull, Jackson and Dick (2011))

Bazując na powyższych definicjach brak atrybutów powoduje zwiększenie czasu, jaki zespół projektowy musi poświęcić, aby móc odpowiedzieć na podstawowe pytania:

  1. Które z listy wymagań zaimplementować jako pierwsze?
  2. Jakie są skutki braku implementacji tego wymagania, bądź grupy wymagań?
  3. Z kim z biznesu rozmawiać o tym wymaganiu?
  4. Czy wymaganie, o którym rozmawiamy jest nadal aktualne? Czy to jest jego ostateczna wersja?
  5. Które z wymagań zostały już zaimplementowane?
  6. W jaki sposób dane wymaganie wpływa na inne wymagania?
  7. Czy znamy kryteria akceptacji danego wymagania?
  8. Skąd wzięło się to wymaganie?

To tylko kilka pytań, które usłyszysz na spotkaniu projektowym, jeśli Twoje wymagania będą zawierały jedynie nagłówek z bardzo krótkim opisem wymagania.
To właśnie dzięki atrybutom wymagań, osoba zarządzająca projektem w krótkim czasie jest w stanie wygenerować raport pokazujący które z listy wszystkich wymagań o wysokim priorytecie mają status: “Zatwierdzone”, są przypisane do “Analityka 1” i będą implementowane w wersji 15.3.
Nie ma wątpliwości, że zdefiniowanie listy atrybutów, jakie chcemy utrzymywać w danym projekcie oraz ich ciągła aktualizacja jest dodatkowym czasem, jaki musi poświęcić Analityk, aby “zamknąć pracę” nad wymaganiem. Niezaprzeczalne jest również to, że jest to inwestycja w jakość, która powinna być wykonywana w każdej firmie dostarczającej wymaganie.

2. Najczęściej używane atrybuty wymagania

Nie ma jednej uniwersalnej listy atrybutów wymagań. Zgodnie z definicją atrybutu są to dodatkowe informacje ułatwiające zarządzanie projektem, zatem lista atrybutów może zmieniać się w zależności od rodzaju projektu czy nawet ze względu na rynek, na który dostarczamy oprogramowanie.

Brak uniwersalnej listy nie oznacza, że mamy ją tworzyć od nowa przed każdym uruchomieniem projektu. Istnieje lista najpopularniejszych atrybutów wymagania, od których można rozpocząć i wybrać z niej te, które dają wartość do opisywanego wymagania.

Jednym z pierwszych problemów w pracy z atrybutami, jakie obserwuję wchodząc do danej firmy jako konsultant to “nadgorliwość” analityków. Patrząc na niektóre listy atrybutów widać proces tworzenia takiej listy. Ktoś usiadł i sumiennie przejrzał wszystkie dostępne listy atrybutów, wyciągnął część wspólną i zaimplementował do projektu. O ile co do pierwszych czynności nie mam zastrzeżeń, to zabrakło podstawowego kroku, czyli zastanowienia się czy lista tych atrybutów dodaje wartość do opisanego wymagania i poprawia jego czytelność.

Pamiętajmy o tym, aby zdefiniowane atrybuty wymagania aktualizować na bieżąco dla danego wymagania oraz aby przyjęta lista atrybutów była uzupełniona dla każdego wymagania. Niedopuszczalna jest sytuacja, kiedy na przykład z listy 10 atrybutów w jednym wymaganiu mamy komplet informacji, w pozostałych wymaganiach mamy wybiórcze informacje.

Pamiętaj, że lista atrybutów wymagania może się zmieniać wraz z projektem ze względu na jego specyfikę, bądź domenę. Nie wyklucza to natomiast stworzenia uniwersalnej minimalnej listy atrybutów wymagania, którą możesz rozszerzać o dodatkowe atrybuty charakterystyczne dla danego projektu.

Atrybuty możemy uporządkować ze względu na 3 grupy:
Grupa 1: Atrybuty pomagające zdefiniować wymaganie i jego cel
Grupa 2: Atrybuty wspierające zarządzanie wymaganiami
Grupa 3: Atrybuty wspierające ponowne użycie wymagania

Grupa 1: Atrybuty pomagające zdefiniować wymaganie i jego cel

Jest to grupa atrybutów, która pomaga zapewnić, że wymagają posiadają cechy dobrze sformułowanych wymagań, ale przede wszystkim pozwalają zrozumieć intencję oraz potrzeby biznesowe, jakie były źródłem dla tego wymagania.

  1. Uzasadnienie – określa dlaczego wymaganie jest potrzebne, ale również pozwala nam lepiej zrozumieć intencję wymagania oraz przyczyny jego powstania. W uzasadnieniu znajdziemy założenia czy ograniczenia, jakie są dodatkową informacją wpływającą niekiedy nawet na ustalenie priorytetu danego wymagania.
  2. Pochodzenie wymagania/źródło wymagania – każde wymaganie musi mieć wskazane swoje źródło pochodzenia. Źródłem wymagania może być potrzeba interesariuszy, dokument na podstawie którego zdefiniowano dane wymaganie, np. zgodność z konkretnym aktem prawnym, zgodność z procedurami bezpieczeństwa. Innym przykładem źródła wymagania może być również inne wymaganie, wówczas podajemy numer wymagania.

Grupa 2: Atrybuty wspierające zarządzanie wymaganiami

Atrybuty z tej grupy pomagają utrzymać aktualny stan wymagania, ale przede wszystkim podjąć działania w celu zapewnienia zarządzania zmianą, zachowania spójności, kompletności oraz pozwala na wgląd w stan realizacji wymagań przez zespół projektowy.

  1. Unikalna nazwa -tytuł, nagłówek wymagania, ważne, aby był on krótki i odzwierciedlał główną myśl, której dotyczy wymaganie
    Unikaj bardzo długich zdań, ponieważ nie są one czytelne. Skup się na intencji, jakie niesie dane wymaganie. Nie wrzucaj w nagłówek wymagania całego opisu działania, które powinno znaleźć się w treści wymagania.

Przykład:

Mamy wymaganie biznesowe użykownika, którego nagłówek będzie brzmiał:

“Umożliwienie Działowi Sprzedaży utworzenie dokumentu potwierdzającego realizację usługi”,

bądź krócej:

“ Utworzenie przez Dział Sprzedaży dokumentu potwierdzającego realizację usługi”.

Zwróć uwagę, że nagłówek wymagania musi być unikalny, zatem w słowniku pojęć, bądź modelu dziedziny ( w zależności od tego w jakim narzędziu pracujesz) umieść definicję: “usługa”, “dokument”.

W przypadku korzystania z narzędzi CASE, niektóre z nich mają wbudowany mechanizm wspierający tworzenie unikalnych nazw wymagań. Oznacza to, że nie będziemy mogli utworzyć wymagania o dokładnie takiej samej nazwie, która już została zdefiniowana w innym wymaganiu. W przypadku dużej listy wymagań jest to ułatwienie pracy, które przekłada się również na jakość wymagań.

2. Unikalny identyfikator – krótki, niepowtarzalny identyfikator dla wymagania. Może to być liczba, alias składający się z cyfr i tekstu, który referuje do grupy wymagań.

Ważne, aby identyfikator nie był ponownie użyty nawet w sytuacji, kiedy Klient zrezygnował z danego wymagania.
Często w bardzo złożonych systemach można spotkać identyfikatory, w ramach których zaszywamy dodatkowe informacje takie jak moduł, z którym związane jest dane wymaganie czy rodzaj wymagania.

Ważne jest, aby składnia identyfikatora była powszechnie dostępna i jednoznaczna dla wszystkich w Twojej organizacji a co najważniejsze, aby wszyscy ją stosowali.

Dla naszego przykładu:

Opcja A) Bardzo rozbudowany system, chcemy w szybki sposób dowiedzieć się jakiego obszaru dotyczy nasze wymaganie

W takiej sytuacji możesz spotkać się z rozbudowaną strukturą identyfikatora, np.

Identyfikator w postaci: X.YY.ZZZ, gdzie:
X oznacza unikalny identyfikator systemu/aplikacji. W naszym przypadku oznaczmy, że jest to: S, czyli System Sprzedażowy ,
YY oznacza unikalny identyfikator modułu. W naszym przypadku będzie to: RS, czyli Realizacja Szkoleń
ZZZ oznacza kolejny numer wymagania. W naszym przypadku będzie to pierwsze wymaganie, czyli: 001.

Nasz identyfikator wygląda następująco: S.RS.001.
W zależności od narzędzia, w którym tworzysz i zarządzasz wymaganiami identyfikator może być automatycznie dodatkowo dodany do nagłówka, dzięki czemu otrzymamy dla naszego przykładu następujące wymaganie:

S.RS.001 – Utworzenie przez Dział Sprzedaży dokumentu potwierdzającego realizację usługi

Opcja B) Nie potrzebujesz umieszczać informacji o systemie czy module w identyfikatorze. Zależy Ci jednak, aby w szybki sposób bez dodatkowego “klikania” dowiedzieć się o rodzaju wymagania.

W takiej sytuacji struktura identyfikatora może wyglądać następująco:
XX.YYY, gdzie:
XX– rodzaj wymagania zgodnie z przyjętą strukturą w organizacji, np. WB- wymaganie biznesowe, WF – wymaganie funkcjonalne, WNF – wymaganie niefunkcjonalne. W naszym przypadku jest to wymaganie biznesowe użytkownika, zatem oznaczmy go jako: WB
YYY– oznacza kolejny numer wymagania.W naszym przypadku będzie to pierwsze wymaganie, czyli: 001.

Dla naszego przykładu połączmy identyfikator z nagłówkiem wymagania:
WB.001 – Utworzenie przez Dział Sprzedaży dokumentu potwierdzającego realizację usługi

Bazując na powyższych przykładach możemy zauważyć, że niepozorny atrybut jakim jest identyfikator może nieść sporo informacji poza samym numerem.
Pamiętaj, że nie zawsze identyfikator musi być rozbudowany, czasem i najczęściej tak jest, na początku wystarczy jedynie kolejny numer wymagania.

Czy identyfikator zawsze powinien być w nagłówku wymagania?
Umieszczenie w nagłówku wymagania również jego identyfikatora nie jest konieczne, aczkolwiek poprawia czytelność wymagań. Brak umieszczenia identyfikatora w nagłówku nie pozbawia wymagania atrybutu, ponieważ taka informacja znajduje się na liście atrybutów wymagania, jeśli korzystamy z narzędzia CASE, np. Enterprise Architect czy Visual Paradigm. W JIRA identyfikator znajduje się w szczegółach (Details) danego wymagania.

Kiedy warto umieścić identyfikator w nagłówku wymagania?
Jeśli nie korzystasz z narzędzia CASE, a do dyspozycji masz Word-a to warto umieścić identyfikator w nagłówku wymagania, bowiem na spisie treści będziesz widział od razu numery wymagań, a i czytanie czasem obszernie opisanego dokumentu staje się łatwiejsze.

3. Typ wymagania/kategoria wymagania – określa typ wymagania: wymaganie biznesowe, wymaganie funkcjonalne, wymaganie pozafunkcjonalne.

Lista typów wymagań zależy od tego, jaki schemat podziału wymagań został przyjęty w danej organizacji.
Możesz spotkać się z bardziej rozbudowanymi listami, np. zamiast: “wymaganie pozafunkcjonalne” będą wymienione rodzaje wymagań pozafunkcjonalnych (np. bezpieczeństwo).

Czy muszę uzupełniać atrybut: typ wymagania, nawet jeśli wcześniej został już wpisany jako część składowa identyfikatora?
Odpowiedź jest jedna: Tak i to bezwzględnie, choć z jednym wyjątkiem. Pamiętaj, że dodanie informacji o rodzaju/typie wymagania w nagłówku jest jedynie dodatkową informacją, która ma pomóc czytelnikowi od razu zobaczyć z jakim rodzajem wymagania ma do czynienia.


Jeśli korzystasz np. z Enterprise Architecta i dodajesz wymagania z sekcji: “Extended Requirements” (na rysunku poniżej oznaczono cyfrą: 1), obiekt zostaje dodany (rys. ozn. numerem 2) i automatycznie nadawany jest typ wymagania (rys. ozn. numerem 3 ) zgodnie z wybranym typem wymagania.

(w celu powiększenia rysunku kliknij w niego)

widok atrybutów w EA
Widok atrybutów w Enterprise Architect

Podobnie jest w przypadku Visual Paradigm, gdzie po wcześniejszej konfiguracji typów wymagań system automatycznie ustawia wybrany typ w utworzonym obiekcie.

widok wymagania z oznaczonym atrybutem: rodzaj wymagania w VP
Widok wymagania oraz oznaczenia rodzaju wymagania w Visual Paradigm

Wyjątkiem, kiedy nie musimy, ale nadal możemy duplikować informację o typie wymagania, jest przechowywanie wymagań w Word.

Organizacje różnie sobie z tym radzą, jedne bezpośrednio pod nagłówkiem stosują tabelę, w której przechowują wszystkie atrybuty wymagania- w takiej sytuacji informacja o typie wymagania powinna również znaleźć się w tabeli. Inne organizacje pod nagłówkiem wymagania wprowadzają treść tego wymagania.

Celem dodania atrybutu jakim jest typ wymagania jest umożliwienie szybkiego wylistowania wymagań o określonym typie, co jest trudno osiągalne, jeśli korzystamy z Word. Jeśli przechowujemy wymagania w postaci tekstu w Confluence istnieje możliwość wygenerowania raportu zestawiającego typy wymagań. Nadal należy jednak pamiętać, że Word i Confluence nie są narzędziami dedykowanymi do zarządzania wymaganiami.
Wylistowanie informacji o typie wymagań wraz z dodatkowymi atrybutami w EA czy VP jest jedną z podstawowych funkcji tych narzędzi.

  1. Autor wymagania – oznaczenie osoby, która wprowadziła wymaganie. W przypadku użycia narzędzi CASE bardzo często system automatycznie przypisuje osobę zalogowaną, która dodała wymaganie do repozytorium. Pamiętaj, aby nie mylić z autora wymagania z innym atrybutem wymagania- właściciel wymagania.
  2. Data utworzenia wymagania – data wprowadzenia wymagania do katalogu wymagań. W przypadku użycia narzędzi CASE data tworzona jest automatycznie. Pamiętaj, że nie wszystkie wymagania tworzone są w momencie uruchomienia projektu. Niektóre z nich są tworzone w trakcie spotkań z Klientem. Informacja o dacie utworzenia wymagania pozwala Ci nie tylko zarządzać wymaganiem, ale przede wszystkim prześledzić, w którym momencie projektu powstało wymaganie. Dzięki tej informacji łatwiej jest zarządzać zmianą w projekcie, ale również priorytetami wymagań.
  3. Właściciel wymagania – osoba odpowiedzialna za zatwierdzanie zmian w wymaganiu. Najczęściej jest to jeden z interesariuszy. Możesz spotkać się z określeniem: “Właściciel biznesowy”. Takie stwierdzenie ułatwia odróżnienie autora wymagania od jego właściciela. Określenie “właściciel wymagania” jest bardziej uniwersalne, ponieważ “właściciela biznesowego” mamy w wymaganiach biznesowych, natomiast właścicielem wymagań pozafunkcjonalnych czy funkcjonalnych może być np. członek zespołu.
  4. Interesariusze– informacja, jakich grup interesariuszy dotyczy wymaganie. Dzięki tej informacji wiemy, które grupy interesariuszy mają wpływ na ostateczny kształt wymagania oraz będą uczestniczyć w zatwierdzaniu wymagań
  5. Status – listę statusów wymagań warto zdefiniować na początku projektu, aby śledzić, którymi wymaganiami powinniśmy zająć się na danym etapie projektu. Dzięki ustawieniu statusu wymagania wiemy, które wymagania są w trakcie implementacji, a które są np. odrzucone przez Klienta.
  6. Numer wersji wymagania – informacja o aktualnej wersji wymagania, dzięki czemu widzimy jak w czasie zmieniało się wymaganie. Wymaganie, które ma wiele zmian zwiększa ryzyko w projekcie, ale również widać w którym obszarze mamy największą niewiadomą.
  7. Data zatwierdzenia wymagania – data zatwierdzenia aktualnej wersji wymagania.
  8. Data ostatniej zmiany wymagania – data ostatniej zmiany wymagania. Możesz spotkać się z sytuacją, kiedy data zatwierdzenia wymagania jest wcześniejsza niż data ostatniej zmiany wymagania, co ma również odzwierciedlenie w statusie: “Niezatwierdzone”. Patrząc jedynie na te 3 atrybuty (data zatwierdzenia wymagania, data ostatniej zmiany wymagania i status wymagania) widzimy, że wymaganie zostało zatwierdzone przez Klienta, a następnie uległo zmianie.
  9. Stabilność wymagania – informacja o “podatności” wymagania na zmiany. Wymagania oznaczone jako niestabilne, czyli takie, które są zmieniane przez Klienta nie powinny trafić do produkcji, ponieważ nawet po zaimplementowaniu wymagania ulegnie ono zmianie. Często atrybut jest powiązany z numerem wersji wymagania. Uproszczając można przyjąć, że im wyższa wersja wymagania tym bardziej niestabilne mamy wymaganie. Patrząc na wcześniej opisywany przypadek ze zmianą wymagania, automatycznie powinniśmy ustawić takie wymaganie jako: “niestabilne”. Tym samym widzimy ścisłą korelację pomiędzy poszczególnymi atrybutami.
  10. Priorytet – informacja o kolejności implementacji. Nie mylić z ważnością danego wymagania, bowiem każde wymaganie może być ważne z punktu widzenia prowadzenia biznesu, lecz w którymś momencie stanie się pilne, czyli będzie wymagało szybkiego wdrożenia a co za tym idzie jego priorytet zmieni się na najwyższy.
  11. Krytyczność wymagania – informacja o wpływie danego wymagania na działanie rozwiązania. Krytyczne wymagania to takie, które muszą być zaimplementowane, aby system w ogóle mógł działać. Informacja ta wpływa również na nadawanie priorytetów danym wymaganiom. Określenie krytyczności wymagania może być listą: 1,2,3, gdzie 1 oznacza wymaganie najbardziej krytyczne. Można skorzystać też z innej listy, np.: “Krytyczny, wysoki, średni, niski”. Często w narzędziach CASE krytyczność wymagania oznaczona jest jako: “ważność” wymagania.
  12. Ryzyko wymagania – informacja, która pozwala nam odpowiedzieć na pytanie jakie ryzyko musimy uwzględnić, jeśli dane wymaganie nie zostałoby zaimplementowane. Ten atrybut podobnie jak atrybuty: stabilność, krytyczność są informacjami, po analizie których określamy priorytet. Często narzędzie CASE wspiera wyliczenie takiego priorytetu na podstawie tych informacji.

Grupa 3: Atrybuty wspierające ponowne użycie wymagania

Atrybuty z tej grupy mogą być stosowane przez organizację, która wytwarza podobne produkty ze względu na linię tworzonych produktów, region czy kraj.

  1. Wydanie – numer wydania, w ramach którego ma być zaimplementowane wymaganie
  2. Region – informacja o regionie, dla którego jest dedykowane dane wymaganie. Dotyczy to sytuacji, kiedy rozwiązanie jest dedykowane na różne rynki. Dzięki informacji o regionie łatwiej nam jest później rozwijać funkcjonalności w sytuacji, kiedy chcemy dostosować oprogramowanie do danego regionu.
  3. Kraj – podobnie jak w przypadku regionu otrzymujemy informację o kraju, którego dotyczą dane wymagania, być może charakterystyczne tylko dla tego kraju, np. sposób naliczania odsetek, czy sposób księgowania, bądź rodzaje dokumentów jakie są tworzone po wykonaniu danego kroku biznesowego.
  4. Segment rynku – informacja o segmencie rynku, dla którego wdrażamy dane wymagania.
  5. Produkt/Obszar – informacja o tym, jakiego obszaru biznesowego, bądź produktu, czy linii produktowej dotyczy dane wymaganie.

Od czego zacząć pracę z atrybutami wymagania?

  1. Wypisz wszystkie atrybuty wymagania, które według Ciebie są wartościowe z punktu widzenia prowadzenia projektów w firmie, w której pracujesz.
    W tym celu możesz skorzystać z zaproponowanych najpopularniejszych atrybutów wymagań. Możesz również przejrzeć projekty, w których brałeś udział, szczególnie takich, które zakończyły się opóźnieniem w realizacji wymagań, prace były źle oszacowane, czy zmienność wymagań po stronie klienta była duża.
    Zastanów się jakich informacji w wymaganiach zabrakło, aby uniknąć takiej sytuacji, bądź zminimalizować wystąpienie takich sytuacji w projekcie.
  2. Przedyskutuj z zespołem przygotowaną przez Ciebie listę, zastanówcie się, czy lista jest kompletna, a jeśli brakuje jakiejś informacji dopisz ją do listy.
  3. Przetestuj przygotowaną listę z zespołem podczas projektu
  4. Podczas retrospekcji po zakończonym projekcie porozmawiajcie o zastosowanej w projekcie liście atrybutów wymagań, aby dowiedzieć się:
    A) Czy zaprojektowana przez Was lista spełniła Wasze oczekiwania?
    B) Które z atrybutów wymagań okazały się przydatne, a które zbędne, bądź nie wnoszące żadnej wartości?
    C) Czy w trakcie projektu pojawiły się nowe informacje, które powinniśmy dodać do listy naszych atrybutów wymagań?

Moja rada: Zacznij od minimalnej listy atrybutów, którą będziesz stosował do każdego wymagania.

Subiektywna lista podstawowych atrybutów, od której warto rozpocząć pracę:

  1. Unikalny identyfikator
  2. Unikalna nazwa wymagania
  3. Uzasadnienie wymagania /opis
  4. Typ wymagania
  5. Data utworzenia wymagania
  6. Data ostatniej zmiany wymagania
  7. Autor wymagania
  8. Źródło
  9. Priorytet
  10. Status
  11. Numer wersji wymagania

W dalszej kolejności możemy rozszerzyć tą listę o następujące elementy takie jak:

  1. Krytyczność
  2. Ryzyko
  3. Wydanie
Udostępnij




Aby pogłębić wiedzę po artykule zalecam szkolenie:

Dobre praktyki analizy w projektach IT

Zobacz