Podstawą do opracowania dopasowanego do organizacji procesu Inżynierii Wymagań są odpowiednio dobrane dobre praktyki, metody zarządzania oraz efektywne narzędzia je wspierające. Wybór ich stanowi wyzwanie i poważny problem dla wielu organizacji. Jeżeli popatrzymy na środowiska, w których obecnie rozwijane jest oprogramowanie, to możemy stwierdzić, że zwykle zespoły analityków, programistów i testerów nie komunikują się ze sobą w sposób efektywny, co negatywnie wpływa na wydajność pracy, koszty i jakość finalnego produktu.Powszechnie używane narzędzia, jak Microsoft Word i Excel wspierające rozwój oprogramowania nie potrafią wymieniać między sobą informacji na poziomie relacji pomiędzy wymaganiami oraz ich różnymi wersjami, co prowadzi do powielania w nich funkcjonalności i konieczność żmudnego i narażonego na błędy przenoszenia między nimi danych. Wybór narzędzi dokonywany jest zwykle pod kątem zaspokojenia potrzeb każdego zespołu z osobna co z czasem całkowicie blokuje dalszy rozwój strategii departamentu odpowiedzialnego za rozwój oprogramowania. Oczywistym wnioskiem jest konieczność dążenia do konsolidacji dyscyplin inżynierii oprogramowania na poziomie integracji repozytoriów danych i ujednolicenia narzędzi, eliminując powielanie ich podstawowych funkcji.

Narzędzia w zarządzaniu wymaganiami

IBM Engineering DOORS Next

Oprogramowanie IBM Engineering DOORS Next to rozwiązanie do definiowania wymagań, które pomaga ujednolicać rozumienie potrzeb i sposobu ich zaspokojenia w zespole opracowującym produkty i usługi przy użyciu platformy współpracy (Jazz). Engineering DOORS Next jest dostosowany szczególnie do potrzeb procesów tworzenia oprogramowania czy skomplikowanych produktów.

IBM Engineering DOORS Next może pomóc zespołowi projektowemu w powiązaniu wymagań z informacjami zapisanymi w centralnym repozytorium lub w portalu zarządzania projektem. Korzystając z rozwiązania IBM, można dokumentować i kojarzyć informacje zapisane w różnych formatach i współużytkować je w grupie wielu użytkowników oraz między różnymi projektami. Oprogramowanie oferuje funkcje wyszukiwania i filtrowania, które ułatwiają poruszanie się po obszernych zasobach informacji opisujących wymagania.

Oferuje członkom zespołów możliwe do dostosowania i dobrze zabezpieczone widoki projektu, które w czasie rzeczywistym przedstawiają informacje na temat nowych artefaktów, komentarzy i wymagań, na których członkowie zespołów powinni skoncentrować swój wysiłek. Możliwość poglądowego spojrzenia na bieżący zbiór wymagań, a także wzięcia udziału w rozmowach na temat dodatkowych informacji, daje zespołom lepszy wgląd w sytuację oraz kontrolę nad nią.

Oprogramowanie IBM Engineering DOORS Next umożliwia zespołom tworzenie dokumentów tekstowych z rozbudowanym formatowaniem i diagramów procesów biznesowych, a także opracowywanie diagramów przypadków użycia, szkicowanie interfejsów użytkownika oraz rozrysowywanie i tworzenie scenariuszy. W ten sposób interesariusze mogą zrozumieć zmiany oraz ich wpływ na projekt. Użytkownicy IBM Engineering DOORS Nextmają możliwość pracowania z narzędziem z poziomu przeglądarki internetowej.

W narzędziu definiowanie wymagań opiera się o następującą strukturę artefaktów:

• Aktor
• Diagram procesu biznesowego
• Kolekcja artefaktów
• Dokument
• Słownik
• Wymaganie
• Przepływy ekranów
• Scenorys
• Przypadki użycia
• Diagramy przypadków użycia
• Szkic interfejsu użytkownika, prototypy
• Reużywalny fragment interfejsu użytkownika

Dokument w DOORS Next jest artefaktem, który możemy zaimportować ze zwykłego dokumentu MS Word lub Open Office. Przykładowo do opisanego w dokumencie procesu biznesowego możemy dołączyć stworzony w edytorze graficznym programu diagram. Aktor, przypadki użycia oraz diagramy przypadków użycia są natomiast artefaktami ściśle związanymi z językiem UML wykorzystywanym w modelowaniu systemów informatycznych Samo narzędzie posiada wbudowany mechanizm śledzenia zmian pomiędzy wymaganiami oraz innymi elementami, które mają na te wymagania wpływ.

IBM DOORS Next, obok IBM Workflow Management™ i IBM Test Management, należy do zasadniczych elementów rozwiązania IBM Engineering. Integracja między produktami do zespołowego zarządzania cyklem życia aplikacji umożliwia powiązanie wymagań ze scenariuszami testów i zadaniami programistycznymi. Takie powiązanie ułatwia uczestnikom projektu odkrywanie zmian, interpretację ich wpływu i utrzymanie poprawności oraz aktualności danych o projekcie. IBM Engineering DOORS Next jest zbudowany na platformie technicznej IBM Jazz™, której rozszerzalna architektura wspomaga sprawne zarządzanie wszystkimi etapami projekt.

IBM DOORS Next jako produkt ukierunkowany na pracę zespołową integruje zespoły i kojarzy oczekiwania biznesowe osób zainteresowanych projektem z funkcjami dokumentacyjnymi i umożliwiającymi śledzenie pochodzenia wymagań. W wielu przypadkach eliminuje konieczność wielokrotnego wykonywania tych samych prac, ponieważ sprzyja wcześniejszemu prawidłowemu sformułowaniu wymagań.

Więcej informacji: www.jazz.net

Micro Focus Dimensions

Micro Focus Dimensions RM jest kompletnym narzędziem wspierającym inżynierie wymagań, która dostarcza funkcjonalności związanych z identyfikacją wymagań, ich opracowanie, ponownym użyciem oraz śledzeniem zmian na dalszych etapach projektów. Rozwiązanie oparte o przeglądarkę www, zapewnia pełną funkcjonalność pracy z wymaganiami bez potrzeby instalowania dodatków po stronie klienta. Narzędzie posiada jeden interfejs, pozwalający na eliminacje niespójności wersji wymagań trzymanych przez użytkowników w wielu dokumentach na swoich stacjach roboczych. W aktualnej wersji interfejs pozwana na tworzenie i edycje wymagań, ich komentowanie, ankiety oraz zarządzanie zmianami. Możliwym także jest tworzenie i zarządzanie dokumentami w ramach repozytorium.

Rozwiązanie pozwala na pracę z narzędziem bez dostępu do repozytorium, dzięki integracji z Microsoft Word. Micro Focus Dimensions RM pozwala na stworzenie dokumentu na podstawie informacji z repozytorium, a po naniesieniu poprawek w dokumencie na jego ponowne zaimportowanie z naniesieniem zmian. W przypadku brak zmian, a pojawieniu się nowych elementów zostają one zapisane w postaci nowych wymagań lub odpowiadających im wpisów w repozytorium. Narzędzie podobnie jak inne profesjonalne narzędzia tego typu pozwana na wgląd w status wymagań oraz śledzenie ich relacji ze zmianami, przypadkami testowymi czy innymi zależnymi artefaktami. Micro Focus Dimensions RM jest jednym z modułów pakietu Orchestrated ALM (ang. Application Lifecycle Management), który obejmuje cały cykl życia budowy aplikacji od wymagań po zarządzanie testami. Platforma Dimensions RM umożliwia ponowne użycie zasobów oraz pomaga identyfikować elementy już reużywane w projekcie w celu zwiększenia tej utylizacji oraz informuje o zmianach mogących mieć wpływ na elementy na nich bazujących.

Wszystkie wymienione cechy narzędzia wynikają z faktu, że bazuje ono na centralnym repozytorium, które eliminuje potrzebę kopiowania źródła wymagań czy przechowywania wymagań w wielu miejscach.

Więcej informacji : https://www.microfocus.com/en-us/products/dimensions-rm/overview

Rational DOORS (Dynamic Object Oriented Requirements System)

Narzędzie IBM Rational Doors (wcześniej Telelogic Doors) zostało zaprojektowane w celu wsparcia identyfikacji, śledzenia, analizy i zarządzania zmianami wymagań oraz zapewnienia zgodności ze standardami przemysłowymi. Doors jest kompletnym rozwiązaniem do zarządzania wymaganiami bazującym na platformie IBM Jazz. Narzędzie składa się z cześci serwerowej z dostępem przez przeglądarkę www oraz opcjonalnie z klienta działającego po stronie stacji roboczej. Oba interfejsy zapewniają pełen dostęp do funkcjonalności wspierających identyfikowanie, analizę i zarządzanie wymaganiami w projektach wytwarzania oprogramowania, produktów czy systemów przemysłowych. Na zaprezentowanym interfejsie użytkownika przedstawiono specyfikację wymagań zapisaną w postaci modułu oraz dodatkowych relacji śledzenia z innymi dokumentami wymagań czy testów.

Rozwiązanie zawiera moduł zarządzania zmianami, modułu zarządzania procesem testowania oraz raportowania ze wszystkich danych uwzględnionych w projekcie. W celu wsparcia pracy zespołów nad całym cyklem życia produktu, narzędzie dostarcza uniwersalnych interfejsów pozwalających na integracje innymi narzędziami popularnymi na rynku jak Sparx Enterprise Architect czy HP Quality Center. Narzędzie standardowo jest integrowane w ramach portfolio produktów IBM Rational i dostarczane w postaci prekonfigurowanego pakietu instalacyjnego. Rozwiązanie pozwala na definiowanie wymagań w postaci opisów, reprezentacji graficznej w postaci procesów biznesowych, przypadków użycia, interfejsów użytkownika czy scenorysów. Interfejs pozwala na tworzenie relacji wymagań z harmonogramem projektu, zadaniami, przypadkami testowymi, oraz elementami architektury systemu. Wymagania można organizować w postaci reużywalnych bloków, kolekcji lub modułów, które pozwalają zapanować nad skomplikowaniem zadaniem w postaci hierarchicznej struktury drzewiastej.

Więcej informacji: www-03.ibm.com/software/products/en/ratidoor

Blueprint Requirements Center

Blueprint jest narzędziem wspierającym definiowanie i zarządzanie wymaganiami w dużych organizacjach i skomplikowanych przedsięwzięciach. Narzędzie dostarcza pełnego wsparcia dla procesów tworzenia, walidacji, wsparcia pracy grupowej oraz zarządzania wymaganiami. Narzedzie zostało stworzone dla analityków biznesowych w obszarze wytwarzania oprogramowania, aby byli w stanie łatwo definiować wymagania, wizualizować oraz komunikować wymagania w ramach zespołu projektowego. Pozwala na zastosowanie popularnych standardów w modelowaniu oraz technik prototypowania, w celu uchwycenia kluczowych wymagań i koncepcji istotnych z perspektywy klienta. Rozwiązanie zostało zbudowane w oparciu o interfejs użytkownika znany wcześniej z produktów Microsoft Office, co sprawia, że system nawiązuje do wcześniej wypracowanych i popularnie stosowanych praktyk. Narzędzie bazuje na interfejsie dostępnym poprzez przeglądarkę, co umożliwia współbieżny dostęp do danych i ich łatwiejsze utrzymanie w przypadku pracy większych zespołów projektowych.

Mimo, że jest to narzędzie nastawione na pracę grupową, zachowuje ono możliwość przechowywania danych prywatnych oraz publikowanie ich w momencie, kiedy są one opracowane, a ich właściciel podejmie taką decyzję. Blueprint został zaprojektowany w taki sposób, aby umożliwić wsparcie dla zróżnicowanych typów wymagań, różnych form ich zapisu, czy w zależności od doświadczenia zespołów.

Jak wiele narzędzi działających w obszarze zarządzania wymaganiami, Blueprint pozwala na wbudowane przeglądy wymagań oraz dyskusje, co w ocenie producentów ma za zadanie podniesienie jakości wymagań oraz ich precyzyjności.

Dzięki partnerstwie firmy Blueprint z Hewlett-Packard, narzędzie pozwala na integrację z HP Quality Center na poziomie tworzenia dwustronnych powiązań pomiędzy wymaganiami czy przypadkami testowymi. Połączenie danych z obu rozwiązań, pozwala przekazywanie atrybutów wymagań, ich opisu, a także automatyczne generowanie przypadków testowych, czy raportowanie. Zbudowanie z obu narzędzi jednej platformy pozwala na zastosowanie koncepcji RBT (ang. Requirements Based-Testing) oraz zgodną z metodyką T-Map.Next RDT (ang. Result-Driven Testing), a przy tym ugruntowanie i sformalizowanie procesów zapewnienia jakości, czy istotne z perspektywy osób zarządzających skrócenie czasów testów.

Więcej informacji: https://www.blueprintsys.com/solution/requirements-management

Open Source Requirements Management Tool / aNimble Platform

Open Source Requirements Management Tool (OSRMT) jest jednym z najbardziej popularnych narzędzi do zarządzania wymaganiami, rozwijanym od roku 2006 w ramach SourceForge i licencji GPL. Produkt przeznaczony jest głównie do Inżynierii Wymagań, ale wspiera także takie obszary, jak zarządzanie zmiana. Dzięki pokryciu całego cyklu życia aplikacji pozwala na pełne śledzenie relacji pomiędzy artefaktami jak, wymagania, projekt, implementacja, testy. OSRMT wspiera pozyskiwanie wymagań, kontrole wersji, autorskie atrybuty dla wymagań, uzasadnianie, różne źródła wymagań, wymagany wysiłek, priorytety klienta oraz zespołu.

Rozwiązanie było dostępne przy użyciu dwóch interfejsów, jak aplikacja napisana w Javie (Swing) oraz przy użyciu przeglądarki.

Dynamiczny rozwój projektu przez ostatnie lata doprowadził do przeszło 70 tysięcy pobrań i wdrożeń liczonych w setkach stacji roboczych. Niestety nie uchroniło to projektu przed brakiem aktywności zespołu, który rozwijał narzędzie i w rezultacie zawiesił projekt. Wyzwaniem biznesowym dużej liczby użytkowników stało się przeniesienie danych, raportów, procesów z tego już niewspieranego i nierozwijanego narzędzia.

Kontynuacją projektu OSRMT jest platforma aNimble, która w domyśle ma być rozwinięciem OSRMT w wersji 1.5. Platforma posiada przeprojektowaną architekturę bazującą na innych technologiach, a dostęp do wszelkich zasobów odbywa się tylko przez przeglądarkę www. Projekt stanowi koło ratunkowe dla wcześniejszych użytkowników OSRMT, pozwalając na migrację z już nierozwijanego rozwiązania do rokującej platformy.

Więcej informacji: http://sourceforge.net/projects/nimble/

Inne narzędzia warte uwagi:

• Modern Requirements
• Jama Software
• Visure Requirements
• Orcanos
• Accompa
• Pearls
• Perforce Helix RM

Cechy dobrego narzędzia do zarządzania wymaganiami

Bazując na wyzwaniach związanych z doborem narzędzi wspierających procesy Inżynierii Wymagań oraz dobrych praktykach wypisano listę kluczowych funkcjonalności, istotnych przy wyborze technologii. Na liście znalazły się jedynie funkcjonalności najbardziej kluczowe z perspektywy popularnych procesów analitycznych . Lista może więc nie uwzględniać pewnych aspektów istotnych dla niektórych gałęzi przemysłu.

Do kluczowych cech z perspektywy nowoczesnego narzędzia do pracy z wymaganiami możemy zaliczyć:

• Zapewnienie przechowywania wymagań w jednym miejscu - o łatwym dostępie dla wszystkich interesariuszy
• Wsparcie dla zarządzania zmianami i wersjonowania wymagań
• Prototypowanie interfejsów
• Import i eksportowanie wymagań z/do plików CSV
• Wbudowane wsparcie dla standardu ReqIF
• Możliwość importowania wymagań z dokumentów tekstowych
• Definiowanie wymagań przy użyciu rozbudowanego formatowania (ang. rich-text editing)
• Modelowanie procesów biznesowych
• Definiowanie własnych atrybutów dla wymagań
• Tworzenie własnych typów wymagań
• Modelowanie przypadków użycia
• Możliwość definiowania wymagań i celów biznesowych w projekcie
• Wbudowana obsługa słowników
• Przeglądy wymagań
• Tworzenie grup wymagań
• Wsparcie dla planowania w projekcie
• Integracja wymagań z przypadkami testowymi i innymi artefaktami cyklu życia
• Wsparcie dla estymacji i ustalania priorytetów dla wymagań
• Oznaczenie wymagań (ang. tagging)
• Wsparcie dla dyskusji i komentarzy
• Zarządzanie zamianami wymagań
• Analiza wpływu z odkrywaniem podejrzanych wymagań (ang. suspect link changes)
• Kontrola historii zmian
• Możliwość przeszukiwania repozytorium
• Tworzenie wersji bazowych i możliwość pracy z nimi
• Generowanie raportów
• Tworzenie szablonów dokumentów
• Zarządzanie rolami oraz uprawnieniami

Wdrożenie narzędzia do zarządzania wymaganiami

Wdrożenie narzędzi, które mają docelowo wspierać i usprawniać procesy wytwarzania oprogramowania są zawsze wyzwaniem konsumującym dużo czasu i środków finansowych. Aby rozwiązanie były w pełni stosowane w organizacji, należy pamiętać że podstawą jest zawsze wypracowany proces inżynierii wymagąń, który jest zaakceptowany i uzgodniony wewnątrz organizacji. W innym wypadku wdrożenie narzędzii miają się z celem, gdyż będzie ono bez użyteczne. Wysokiej klasy rozwiązania dedykowane przychodzą od dostawców już w pewnej konfiguracji, którą zawsze można stosować do swoich potrzeb. Wymaga to jednak od organizacji wysokiego poziomu dorzałości wewnętrznej w obszarze IT oraz świadomości rynku. Jest to jednak sytuacja w procesach nastawionych na niski koszt produkcji bardzo rzadko spotykana, bo firmy nie chcą inwestować w ich zdaniem zbędne narzędzi czy procesy, a skupić się na produkcie. Zorientowanie na korzyści z perspektywy celów krótkoterminowych może oczywiście przynieść wartość na dynamicznym rynku szybko zmieniających się potrzeb. Brak planowania długoterminowego rozwoju produktów i procesów ich produkcji mści się zawsze. Liczne firmy doradcze pomagają wdrażać zarówno procesy inżynierii wymagań, a także narzedzia je wspierające, nie są to projekty łatwe i wymagają od zespołu realizacji doświadczenia zarówno pod optymalizacji procesów i znajomości narzędzi, które będą wdrażane. Aby oddać poziom skomplikowania i długość takiego projektu poniżej przedstawiono etapy wdrożenia.

Krok 1 – Zebranie informacji o aktualnym procesie i wymaganiach klienta

Wdrożenie narzędzia do zarządzania wymaganiami nie jest procesem prostym ani szybkim, jednak może być projektem, który doprowadzi do sporych oszczędności w organizacji. Pierwszym krokiem wdrażania zarówno procesów Inżynierii Wymagań, jak i narzędzi, jest zebranie wymagań i oczekiwań klienta co do samego procesu lub jego usprawnień. Pierwszym pytaniem zadanym przez firmę wdrażającą rozwiązanie będzie sytuacja obecna i stosowane w organizacji metodyki oraz standardy, które muszą być spełniane np. z powodu uwarunkowań prawnych lub domeny biznesowej, w której porusza się organizacja. Jako że definicja zarządzania wymaganiami jest często rozmyta, należy na wczesnym etapie uzgodnić z klientem jego oczekiwania i ograniczenia związane z realizacją projektu. Informacje najczęściej są zbierane w formie warsztatu, w którym uczestniczą reprezentanci grup dotkniętych przez proces Inżynierii Wymagań oraz przedstawiciele biznesu. Efektem prac jest dokument „Plan Zarządzania Wymaganiami”, który opisuje formalną komunikacje w obszarze wymagań, w zespole oraz zasady współpracy z dostawcami zewnętrznymi. Dokument specyfikuje, w jaki sposób opisujemy, przetrzymujemy, zmieniamy wymagania oraz jakie dokumenty na ich podstawie opracowujemy. Plan powinien opisywać proces pracy z wymaganiami w całym cyklu życia i rozwoju aplikacji lub systemu. W przypadku powoływania się w planie na metodyki, należy zapewnić, że ich praktyki są faktycznie stosowane w organizacji w sposób poprawny i zalecany.

Krok 2 – Wybór narzędzia automatyzującego proces

Po stworzeniu procesu odpowiednio skrojonego na potrzeby organizacji i uwzględniającego wszystkie jej potrzeby i realia dziedziny, w której się porusza, następuje proces doboru odpowiedniego narzędzia. Wybór powinien zostać wcześniej poprzedzony odpowiednią analizą rynku w celu znalezienia rozwiązania najlepiej pasującego do opisanego wcześniej procesu Inżynierii Wymagań, ale także uwzględniającego jego przyszłe zmiany. Podczas analizy musimy uwzględnić wszystkie czynniki mające wpływ na wdrożenie i używanie narzędzia jak: szkolenia, koszt licencji, koszt wdrożenia, integracja rozwiązania z obecnym portfolio narzędzi w organizacji (wszystkie czynniki zostały omówione w dalszej części książki). Zły wybór generuje wysoki koszty na etapie wdrożenia, utrzymania i nie prowadzi do oczekiwanych efektów w postaci oszczędności.

Krok 3 – Implementacja rozwiązania

Każde narzędzie dostarczane jest przez producenta w pewnej domyślnej konfiguracji, którą otrzymujemy zaraz po instalacji samego produktu. Rolą firmy realizującej projekt wdrożeniowy jest dostosowanie wdrażanego produktu do realnych potrzeb organizacji i wcześniej zdefiniowanego planu zarządzania wymaganiami, tak aby narzędzie wspierało wypracowane rozwiązanie najlepiej, jak tylko pozwala na to jego funkcjonalność. Konfiguracja narzędzia powinna obejmować dostosowanie typów wymagań, atrybutów, używanych szablonów dokumentów, miar oraz metryk oraz ról i uprawnień dla samych użytkowników. W ramach procesu wdrożeniowego powinny zostać wypracowane oraz zaimplementowane w organizacji procedury użycia narzędzia przez klienta a osoby w niech uczestniczące odpowiednie przeszkolone. Proces edukacji powinien być dostosowany do wypracowanego procesu, a nie powinien się tylko skupiać na funkcjonalnościach narzędzia, które nie muszą być wszystkie istotne z perspektywy klienta końcowego.

Krok 4 – Projekt pilotażowy

Po poprawnej implementacji narzędzia następuje etap uzyskania odpowiedzi na pytanie, czy wypracowane rozwiązanie procesowe wraz z narzędziami faktycznie rozwiązuje obecne wyzwania i czy jesteśmy jest w stanie w pełni wdrożyć je w organizacji. Weryfikacja powinna się odbyć w ramach projektu pilotażowego, który powinien być rzeczywistym projektem, aby odpowiednio zmotywować jego uczestników do pracy i nadać przedsięwzięciu odpowiedni bieg. Brak odpowiedniej motywacji osób może doprowadzić do potraktowania zadania jako drugoplanowego, co jednocześnie doprowadzi do braku realnej oceny rozwiązania i jego ewentualnych wad wymagających poprawienia. Projekt powinien także być krótkim o niskim priorytecie, aby szybko zweryfikować wypracowane rozwiązanie i aby jego ewentualne negatywne skutki nie miały wpływu na operacyjne działanie organizacji. Jeżeli projekt będzie się przeciągał w czasie, to możemy długo czekać na podsumowanie projektu i oceny wprowadzonych usprawnień. Przeprowadzony projekt powinien zostać poddany dogłębnej analizę pod kątem wartości i wyzwań, które wniósł do organizacji. Osoby odpowiedzialne za realizację tego przedsięwzięcia powinny w dalszej części projektu pełnić rolę ekspertów dziedzinowych i propagować wiedzę oraz świadomość w temacie danej dziedziny w organizacji. Pełnią oni rolę tzw. ekspertów dziedzinowych (ang. Subject-Matter Expert) oraz mentorów w kolejnych projektach dla innych członków organizacji w celu szerzenia wiedzy i odpowiedniego stosowania wypracowanych praktyk.

Krok 5 – Propagacja rozwiązania na inne projekty

Po zakończeniu wcześniejszych etapów, kolejnym krokiem w procesie wdrożenia narzędzia jest propagacja rozwiązania na inne projekty w organizacji. Wcześniej wypracowane i zweryfikowane elementy procesowe są wdrażane w rzeczywistym ekosystemie projektowym. Na tym etapie powinniśmy zaplanować wsparcie projektu wdrożeniowego przez osoby realizujące wdrażanie narzędzi i pełniące rolę mentorów dziedzinowych z zakresu wypracowanego procesu. Częstą praktyką jest szkolenie docelowych uczestników procesu i użytkowników narzędzia w temacie wypracowanego procesu i jego wsparcia przez wybrane narzędzie do zarządzania wymaganiami. Popularne są w tym obszarze szkolenia ukierunkowane typowo na narzędzia lub na określone techniki specyfikowania wymagań jak np. pisanie przypadków użycia.

Czynniki mające znaczenie przy doborze odpowiednich narzędzi

Przy wyborze dowolnych narzędzi dla wsparcia procesów wytwarzania oprogramowania, należy wykonać dokładną analizę poprzedzającą wdrożenie. Dotyczy to zarówno narzędzi komercyjnych, jak i darmowych, gdzie koszt licencji jest możliwy do pominięcia, jedak wdrożenie i utrzymanie może być bardzo kosztowne. Proces wyboru odpowiedniego narzędzia powinien być osobnym projektem w organizacji, a nie jak zazwyczaj fragmentem już realizowanych projektów. Pozwoli to skuteczenie dobrać narzędzie dla całej organizacji, a nie w pośpiechu tylko i wyłączeni do potrzeb aktualnie realizowanego projektu. Ma to szczególne znaczenie przy narzędziach komercyjnych, których koszt skutecznie przekracza budżet większości z projektów.Wybór narzędzia zawsze jest zdeterminowany przez cene, rodzaj dostępu do danych, wspierane metodyki, sposób przechowywania wymagań oraz wsparcie dla potrzeb organizacji. Aby analiza była zrealizowana w sposób pełny należy odpowiedzieć sobie na pytania, które mogą mieć znaczący wpływ na ewentualne wdrożenie utrzymanie narzędzia.

Do najbardziej kluczowych czynników, które powinny być brane pod uwagę przy wyborze narzędzi można zaliczyć:

Proces wdrożony w organizacji – narzędzie powinno być w stanie wspierać proces istniejący w organizacji. Większość narzędzi komercyjnych dostarcza szablonów metodyk lub pozwala na dostosowanie struktury procesów do potrzeb organizacji, która będzie je wdrażać. Brak wsparcia dla procesów uniemożliwi wykorzystanie w pełni możliwości narzedzia, a wręcz może uniemożliwiać jego użycie.

Zmiany w procesie w przymości – jeżeli proces będzie zmieniany w przyszłości, należy upewnić się, że wybrane narzędzie będzie w stanie nadal go wspierać.

Koszt oprogramowania – jest to jeden z najbardziej kluczowych czynników brany pod uwagę z perspektywy inwestycji w narzędzia. Przy wyborze oprogramowania koszt licencji stanowi zazwyczaj połowę całej inwestycji, należy ponadto pamietać o uwzględnieniu elementów, takich jak usługi wdrożeniowe czy szkoleniowe. Kalkulując całkowitą wartość projektu należy uwzględnić:

• Koszty licencji
• Koszty wdrożenia oprogramowania
• Koszty szkoleń (lokalne lub zagranicą)
• Koszty utrzymania oprogramowania (odnowienia licencji)

Skala użycia narzędzia – czyli kwestia tego, czy narzędzie będzie używane w jednym projekcie, czy też w całej organizacji. Większa utylizacja oprogramowania wpływa na optymalizację zwrotu z inwestycji w skali całej organizacji. W przypadku komercyjnych rozwiązań użycie ich w jednym projekcie może być niemożliwe ze względu na koszt zakupu licencji, usług wdrożenia i szkoleń.

Zagadnienia związane z integracją narzędzia z innymi obszarami (zarządzanie projektem, procesem testowym, zmianami) – przy różnorodności dostawców narzedzi, kwestia integracji staje się skomplikowana, w rezultacie czego można utracić możliwość integracji danych z całego procesu, w tym możliwość śledzenia. Aby sprostać temu wyzwaniu, zalecane jest wybieranie narzędzi integrujących się z aktualnie posiadanymi rozwiazaniami lub ukierunkowanie strategii organizacji na jednego dostawcę całej platformy narzędzi do zarządzania procesem tworzenia oprogramowania.

Możliwości wdrożenia i wsparcia – istnieje wielu dostawców narzędzi wspierających procesy Inżynierii Wymagań, jednak nie wszystkie działają na polskim rynku. Przy wyborze technologii istotne jest, aby wybrane narzędzia miały lokalne wsparcie techniczne w obszarze wdrażania oraz merytoryczne w zakresie prowadzenia szkoleń. W przeciwnym wypadku może to generować wysokie koszty usług związanych z wsparciem oprogramowania.

Przyszłościowe plany rozwoju produktu (ang. roadmap) – przy zakupie narzędzi należy pamiętać o sprawdzeniu dalszych planów jego rozwoju z perspektywy minimum 3 lat. W przeciwnym wypadku może nas spotkać niemiła niespodzianka w postaci zaprzestania wsparcia narzędzia przez jego dostawcę, co w połączeniu braku ścieżki migracji do innego rozwiązania, może okazać się znacznym problemem w utrzymaniu spójności i efektywności procesu Inżynierii Wymagań. Kwestia rozwoju narzędzi w mniejszym stopniu dotyczy rozwiązań Open Source, gdyż w tym przypadku w założeniu użytkownik może je w dowolnym momencie rozbudować ingerując w kod.

Zakres użycia narzędzia - w przypadku wielu przedsięwzieć, wybrane narzędzia mogą być stosowane zarówno przez klienta, jak i dostawcę rozwiązania. Użycie tych samych narzędzi przez obie strony najczęściej ma na celu usprawnienie komunikacji i współpracy. Przed dokonaniem zakupu należy sprawdzić, czy licencja producenta pozwala na taką formę jej współdzielenia. Część dostawców w takim modelu współpracy wymaga, by klient i dostawca posiadali własne licencje. W optymalnej sytuacji dostawca lub klient może używać licencji w posiadaniu drugiej strony na czas realizacji projektu.