Narzędzia służące do zarządzania wymaganiami

Zarządzanie wymaganiami oznacza proces kontroli zmian wymagań i ich konsekwencji dla systemu w ciągu całego cyklu życia systemu. Zarządzanie wymaganiami jest konieczne, gdyż w praktyce wymagania zawsze się zmieniają z powodu zmian technologicznych, organizacyjnych i czysto ludzkich. Wymagania można próbować charakteryzować pod kątem prawdopodobieństwa ich zmiany. Istotnym elementem zarządzania wymaganiami jest znalezienie ich wzajemnych powiązań co umożliwia później śledzenie koniecznych zmian w jednych wymaganiach na skutek zmian w innych.

Istotnym elementem zarządzania wymaganiami jest znalezienie wzajemnych powiązań pomiędzy:

• wymaganiami a motywacjami do ich uwzględnienia (ważne przy rozważaniu możliwych zmian wymagań)

• wymaganiami między sobą

• wymaganiami a elementami projektu i implementacji będącymi konsekwencjami tych wymagań

Dwa ostatnie typy powiązań umożliwiają późniejsze śledzenie koniecznych zmian w innych wymaganiach oraz architekturze i projekcie systemu w przypadku zmiany konkretnych wymagań. Istnieją narzędzia CASE służące specjalnie do śledzenia powyższych zależności związanych z wymaganiami.

Narzędzia CASE wspomagające proces określania wymagań związane są najczęściej z konkretną ustaloną notacją lub metodyką postępowania Istnieją narzędzia pomagające tworzyć diagramy i dokonywać transformacji pomiędzy diagramami. Typowe dla fazy określania wymagań jest tworzenie słownika – bazy danych związanych z realizowanym projektem. Baza danych o odpowiedniej strukturze pozwala na np. śledzenie konsekwencji dokonywania zmian w wymaganiach. Możliwe bywa także automatyczne tworzenie raportów na podstawie diagramów i słowników

Wymagania użytkownika często ujmowane są jako bardzo ogólne wskazania (np. „system powinien być odporny na ataki z zewnątrz” czy „sposób księgowania powinien być zgodny z obowiązującymi przepisami podatkowymi”). Przekształcenie takich ogólnych wymagań w specyfikacje dotyczące oprogramowania jest działalnością wymagającą często dużego doświadczenia, inwencji i znajomości dziedziny zastosowań oraz systemów informatycznych

Istotne jest używanie przy określaniu wymagań konkretnych, precyzyjnych, jednoznacznych i dających się następnie zweryfikować stwierdzeń. Pomocne w konkretyzacji wymagań jest stworzenie modelu systemu w ramach rozważanej dziedziny zastosowania.

Aby przekształcić zbyt ogólne wymagania niefunkcjonalne stosuje się wiele miar dla różnych kategorii wymagań, np.:

• dla szybkości działania: liczba transakcji na sekundę, czas reakcji na zdarzenie, czas odświeżenia strony

• dla łatwości użycia: czas konieczny na przeszkolenie obsługi, liczba stron (okien) pomocy

• dla niezawodności: średni czas do awarii, prawdopodobieństwo niedostępności

• dla odporności: procent zdarzeń powodujących awarię, prawdopodobieństwo zniszczenia danych w trakcie awarii

• dla przenośności: procent instrukcji zależnych od np. systemu operacyjnego lub bazy danych, liczba uwzględnionych systemów operacyjnych (baz danych)

W teorii, określanie wymagań jest fazą odrębną od projektowania systemu.
W praktyce jest prawie niemożliwe podanie pełnych wymagań systemowych bez uwzględnienia pewnych decyzji projektowych i rozwiązań architektonicznych

• specyfikacja wymagań może zawierać ustalenia co do modularnej struktury oprogramowania

• współpraca z innymi programami lub komponentami może rzutować na wymagania stawiane oprogramowaniu

• spełnienie pewnych wymagań niefunkcjonalnych może być związane z konkretnymi decyzjami implementacyjnymi

• niektóre formalne standardy zapisu wymagań posługują się informacjami z etapu projektowania

Im bardziej szczegółowa i im bardziej formalna jest specyfikacja wymagań tym więcej obejmuje szczegółów z fazy projektowania i implementacji Zapisy wymagań w postaci formularza, interfejsów lub języków formalnych w sposób oczywisty zakładają dość szczegółowy poziom wiedzy na temat projektowanego systemu oraz uprzednie podjęcie szeregu istotnych decyzji projektowych (wybór modelu oprogramowania, konkretnych funkcji lub struktur danych) Z tego powodu w iteracyjnych modelach tworzenia oprogramowania fazy określania wymagań oraz projektowania i implementacji tworzą powtarzające się cykle .

Istnieje wiele programów służących do zarządzania wymaganiami. W tej prezentacji skupimy się jednak na programie Tormigo.

Tormigo jest polskim oprogramowaniem, które wspiera proces zarządzania wymaganiami oraz raportowania w Enterprise Architect.

Podstawowe cechy Tormigo to:

• wspomaganie automatycznego wersjonowania wymagań w Enterprise Architect.

• umożliwienie wczytywania wymagań do Enterprise Architect z MS Word lub OpenOffice.

• udostępnienie narzędzi do efektywniejszego mapowania wymagań na przypadki użycia.

• rozszerzenie możliwości raportowania w Enterprise Architect.

Tormigo jest konkurencją dla RaQuest w zakresie zarządzania wymaganiami. Poza tradycyjnym wpisywaniem wymagań z klawiatury Tormigo umożliwia zapisywanie danych bezpośrednio z MS Word i OpenOffice. Ponadto Tormigo działa pod Linuxem. Co więcej Tormigo umożliwia zarządzanie wymaganiami poprzez system automatycznego ich wersjonowania przy każdej zmianie. Mechanizm przyporządkowywania wymagań do przypadków użycia także poprawia komfort i skuteczność pracy analityków i projektantów.

Ponadto Tormigo oferuje szeroki wachlarz raportów. Raporty to zasadniczy moduł aplikacji Tormigo, zawiera on generator wielu typów użytecznych raportów dotyczących wymagań na oprogramowanie, szczególnie użytecznych dla analityków, managerów i inżynierów oprogramowania. Między innymi możesz przy pomocy kilku kliknięć wygenerować:

• raport zawierający listę przypadków użycia wraz ze szczegółowym opisem realizowanych (mapowanych) wymagań,

• zestawienie zawierające wymagania o określonych właściwościach,

• zestawienie dotyczące klas projektu,

• aktywności zawarte w repozytorium projektu,

• dokumentację o aktorach systemu,

• opis komponentów z projektu,

• zestawienie przypadków użycia z projektu,

• raport zawierający listę wymagań,

• specyfikacje przypadków użycia,

• listę wybranych obiektów z repozytorium projektu,

• listę obiektów powiązanych z wybranymi obiektami za pomocą wybranych relacji,

• wykaz wymagań połączonych z innym wymaganiem za pomocą agregacji pod warunkiem, że wybrane wymaganie jest startowym,

• wykaz wymagań połączonych z innym wymaganiem za pomocą agregacji pod warunkiem, że wybrane wymaganie jest startowym,

• listę obiektów połączonych z wymaganiem za pomocą relacji realizacji,

• raport dotyczący wymagań połączonych z obiektami za pomocą relacji realizacji,

• i inne.

Każdy raport można zapisać w jednym z następujących formatów: Jasper Reports, PDF, RTF, ODT, DOCX, HTML, XLS, CSV, XML. Ponadto konfiguracja aplikacji, pozwala na zdefiniowanie parametrów Tormigo specyficznych dla wybranego repozytorium projektu EA. Do parametrów personalizujących raporty należą zmienne jak: nazwa projektu, prawa autorskie, nazwę i logotyp firmy. Narzędzie pozwali Ci również zdefiniować parametry które są wspólne dla wszystkich połączeń z projektami Enterprise Architect, np. ustalić nazwę użytkownika, język interfejsu, skonfigurować współpracę z innymi aplikacjami.

Na koniec należy wspomnieć iż Tormigo ma interfejs w języku polskim i angielskim. Ponadto nie zmienia struktury bazy danych wykorzystywanej przez Enterprise Architect oraz obsługuje takie silniki baz danych jak MS SQL Server i MySQL, Oracle i pliki EAP.

Podsumowując, faza określania wymagań jest niezwykle istotnym elementem procesu tworzenia oprogramowania i żadna z metodologii rozwijania oprogramowania jej nie pomija,

Różne metodologie różnie podchodzą do określania wymagań, zwłaszcza jeśli chodzi o formalizację procesu odkrywania i specyfikacji wymagań oraz o sposób dokumentacji wymagań.

Wybór podejścia do określania wymagań powinien zależeć od charakteru projektu (czy system jest mały, średni czy duży, czy jest tworzony przez różne firmy na podstawie jednego lub wielu kontraktów, czy musi gwarantować wysoki poziom niezawodności i bezpieczeństwa, itp.).