Zarządzanie wymaganiami - Requirements management

Zarządzanie wymaganiami to proces dokumentowania, analizowania , śledzenia , ustalania priorytetów i uzgadniania wymagań, a następnie kontrolowania zmian i komunikowania się z odpowiednimi interesariuszami. Jest to proces ciągły przez cały czas trwania projektu. Wymaganie to zdolność, z którą powinien być zgodny wynik projektu (produkt lub usługa).

Przegląd

Celem zarządzania wymaganiami jest zapewnienie, że organizacja dokumentuje, weryfikuje i spełnia potrzeby i oczekiwania swoich klientów oraz interesariuszy wewnętrznych lub zewnętrznych. Zarządzanie wymaganiami rozpoczyna się od analizy i pozyskania celów i ograniczeń organizacji. Zarządzanie wymaganiami obejmuje ponadto wspieranie planowania wymagań, integrowanie wymagań i organizacji do pracy z nimi (atrybuty wymagań), a także relacje z innymi informacjami dostarczanymi w stosunku do wymagań oraz ich zmiany.

Tak ustalona identyfikowalność jest wykorzystywana w zarządzaniu wymaganiami w celu raportowania wypełnienia interesów firmy i interesariuszy w zakresie zgodności, kompletności, zakresu i spójności. Możliwości śledzenia wspierają również zarządzanie zmianą jako część zarządzania wymaganiami w zrozumieniu wpływu zmian poprzez wymagania lub inne powiązane elementy (np. Wpływ funkcjonalny poprzez relacje z architekturą funkcjonalną) oraz ułatwiają wprowadzanie tych zmian.

Zarządzanie wymaganiami obejmuje komunikację między członkami zespołu projektowego a interesariuszami oraz dostosowywanie się do zmian wymagań w trakcie trwania projektu. Aby jedna klasa wymagań nie miała pierwszeństwa przed inną, niezbędna jest stała komunikacja między członkami zespołu programistycznego. Na przykład w tworzeniu oprogramowania dla aplikacji wewnętrznych firma ma tak duże potrzeby, że może ignorować wymagania użytkowników lub wierzyć, że podczas tworzenia przypadków użycia zadbano o wymagania użytkowników.

Identyfikowalność

Główny artykuł: Śledzenie wymagań

Śledzenie wymagań dotyczy dokumentowania okresu życia wymagania. Powinna istnieć możliwość prześledzenia pochodzenia każdego wymagania, a zatem każda zmiana wprowadzona w wymaganiu powinna być udokumentowana w celu osiągnięcia identyfikowalności. Nawet użycie wymagania po wdrożeniu i użyciu zaimplementowanych funkcji powinno być możliwe do prześledzenia.

Wymagania pochodzą z różnych źródeł, takich jak osoba zamawiająca produkt, kierownik ds. Marketingu i rzeczywisty użytkownik. Wszyscy ci ludzie mają różne wymagania dotyczące produktu. Korzystając z identyfikowalności wymagań, zaimplementowaną funkcję można prześledzić wstecz do osoby lub grupy, która tego chciała podczas pozyskiwania wymagań . Można to na przykład wykorzystać podczas procesu opracowywania, aby nadać priorytet wymaganiu, określając, jak cenne jest wymaganie dla określonego użytkownika. Może być również używany po wdrożeniu, gdy badania użytkowników pokazują, że funkcja nie jest używana, aby zobaczyć, dlaczego była wymagana w pierwszej kolejności.

Działania związane z wymaganiami

Na każdym etapie procesu rozwoju istnieją kluczowe czynności i metody zarządzania wymaganiami. Aby to zilustrować, rozważ standardowy pięciofazowy proces rozwoju z etapami badania, wykonalności, projektowania, budowy i testowania oraz wydania.

Dochodzenie

W badaniu pierwsze trzy klasy wymagań są zbierane od użytkowników, firmy i zespołu programistów. W każdym obszarze zadawane są podobne pytania; jakie są cele, jakie są ograniczenia, jakie są obecnie stosowane narzędzia lub procesy i tak dalej. Tylko wtedy, gdy wymagania te są dobrze zrozumiane, można opracować wymagania funkcjonalne .

W typowym przypadku wymagań nie można w pełni zdefiniować na początku projektu. Niektóre wymagania ulegną zmianie, albo dlatego, że po prostu nie zostały wydobyte, albo dlatego, że siły wewnętrzne lub zewnętrzne w pracy wpływają na projekt w połowie cyklu.

Produktem dostarczanym z etapu dochodzenia jest dokument wymagań, który został zatwierdzony przez wszystkich członków zespołu. Później, w trakcie opracowywania, dokument ten będzie miał kluczowe znaczenie dla zapobiegania pełzaniu zakresu lub niepotrzebnym zmianom. W miarę rozwoju systemu każda nowa funkcja otwiera świat nowych możliwości, więc specyfikacja wymagań zakotwicza zespół w pierwotnej wizji i umożliwia kontrolowaną dyskusję na temat zmiany zakresu.

Podczas gdy wiele organizacji nadal używa tylko dokumentów do zarządzania wymaganiami, inne zarządzają podstawami wymagań za pomocą narzędzi programowych. Narzędzia te umożliwiają zarządzanie wymaganiami w bazie danych i zwykle mają funkcje automatyzacji śledzenia (np. Poprzez umożliwienie tworzenia łączy elektronicznych między wymaganiami nadrzędnymi i podrzędnymi lub między przypadkami testowymi a wymaganiami), elektroniczne tworzenie linii bazowych, kontrolę wersji oraz Zarządzanie zmianami. Zwykle takie narzędzia zawierają funkcję eksportu, która umożliwia utworzenie dokumentu specyfikacji poprzez wyeksportowanie danych wymagań do standardowej aplikacji dokumentu.

Wykonalność

Na etapie wykonalności określane są koszty wymagań. W przypadku wymagań użytkowników bieżący koszt pracy porównuje się z przyszłymi przewidywanymi kosztami po wdrożeniu nowego systemu. Zadawane są takie pytania: „Ile kosztują nas błędy przy wprowadzaniu danych?” Lub „Jaki jest koszt złomu spowodowanego błędem operatora w obecnym interfejsie?” W rzeczywistości potrzeba nowego narzędzia jest często dostrzegana, gdy na te pytania zwracają się osoby zajmujące się finansami w organizacji.

Koszty biznesowe obejmowałyby: „Jaki dział ma na to budżet?” „Jaka jest oczekiwana stopa zwrotu z nowego produktu na rynku?” „Jaka jest wewnętrzna stopa zwrotu z obniżenia kosztów szkolenia i wsparcia, jeśli stworzymy nowy, łatwiejszy w użyciu system?”

Koszty techniczne są związane z kosztami rozwoju oprogramowania i sprzętu. „Czy mamy odpowiednich ludzi do stworzenia narzędzia?” „Czy potrzebujemy nowego sprzętu do obsługi rozszerzonych ról oprogramowania?” To ostatnie pytanie jest bardzo ważne. Zespół musi zbadać, czy najnowsze zautomatyzowane narzędzia dodadzą wystarczającą moc obliczeniową, aby przenieść część obciążenia z użytkownika na system w celu zaoszczędzenia czasu ludzi.

Pytanie wskazuje również na fundamentalną kwestię dotyczącą zarządzania wymaganiami. Człowiek i narzędzie tworzą system, a ta realizacja jest szczególnie ważna, jeśli narzędziem jest komputer lub nowa aplikacja na komputerze. Umysł ludzki przoduje w równoległym przetwarzaniu i interpretacji trendów przy niewystarczających danych. Procesor wyróżnia się przetwarzaniem szeregowym i dokładnymi obliczeniami matematycznymi. Nadrzędnym celem wysiłków związanych z zarządzaniem wymaganiami w projekcie oprogramowania byłoby zatem zapewnienie, że zautomatyzowana praca zostanie przypisana do odpowiedniego procesora. Na przykład: „Nie każ człowiekowi pamiętać, gdzie jest w interfejsie. Interfejs powinien przez cały czas informować o lokalizacji człowieka w systemie ”. Lub „Nie zmuszaj człowieka do wprowadzania tych samych danych na dwóch ekranach. Spraw, aby system przechował dane i w razie potrzeby wypełnij drugi ekran ”.

Produktem dostarczanym na etapie wykonalności jest budżet i harmonogram projektu.

Projekt

Zakładając, że koszty są precyzyjnie określone, a korzyści do uzyskania są dostatecznie duże, projekt może przejść do etapu Projektowania. W projektowaniu głównym działaniem związanym z zarządzaniem wymaganiami jest porównywanie wyników projektu z dokumentem wymagań, aby upewnić się, że praca pozostaje w zakresie.

Ponownie, elastyczność jest najważniejsza dla sukcesu. Oto klasyczna historia zmiany zakresu w trakcie transmisji, która faktycznie działała dobrze. Projektanci samochodów Forda na początku lat 80. oczekiwali, że do końca dekady ceny benzyny osiągną 3,18 dolara za galon. W połowie okresu projektowania Forda Taurus ceny osiągnęły około 1,50 dolara za galon. Zespół projektowy zdecydował, że może zbudować większy, wygodniejszy i mocniejszy samochód, jeśli ceny benzyny pozostaną niskie, więc przeprojektowali samochód. Premiera Taurusa ustanowiła rekordy sprzedaży w całym kraju, gdy pojawił się nowy samochód, przede wszystkim dlatego, że był tak pojemny i wygodny w prowadzeniu.

Jednak w większości przypadków odejście od pierwotnych wymagań w takim stopniu nie działa. Dokument wymagań staje się więc kluczowym narzędziem, które pomaga zespołowi w podejmowaniu decyzji dotyczących zmian projektowych.

Budowa i test

Na etapie budowy i testowania głównym działaniem zarządzania wymaganiami jest upewnienie się, że praca i koszty mieszczą się w harmonogramie i budżecie, a powstające narzędzie faktycznie spełnia wymagania. Głównym narzędziem wykorzystywanym na tym etapie jest budowa prototypu i testowanie iteracyjne. W przypadku aplikacji interfejs użytkownika można utworzyć na papierze i przetestować z potencjalnymi użytkownikami podczas tworzenia struktury oprogramowania. Wyniki tych testów są zapisywane w przewodniku projektowania interfejsu użytkownika i przekazywane zespołowi projektowemu, gdy są gotowi do opracowania interfejsu. Oszczędza to ich czas i znacznie ułatwia pracę.

Weryfikacja: ten wysiłek weryfikuje, czy wymaganie zostało poprawnie wdrożone. Istnieją 4 metody weryfikacji: analiza, inspekcja, testowanie i demonstracja. Na przykład numeryczne wyniki wykonania oprogramowania lub test sieciowy dostarczają analitycznego dowodu, że wymóg został spełniony. Weryfikacja dokumentacji dostawcy lub arkuszy specyfikacji również weryfikuje wymagania. Faktyczne testowanie lub demonstracja oprogramowania w środowisku laboratoryjnym również weryfikuje wymagania: rodzaj weryfikacji testowej ma miejsce, gdy używany jest sprzęt testowy, który zwykle nie jest częścią laboratorium (lub testowanego systemu). Kompleksowe procedury testowe, które przedstawiają kroki i ich oczekiwane wyniki, jasno określają, co należy postrzegać jako wynik wykonania kroku. Po zakończeniu kroku lub zestawu kroków oczekiwany wynik ostatniego kroku będzie zawierał informacje o tym, co zostało zaobserwowane, a następnie zidentyfikuje, które wymaganie lub wymagania zostały zweryfikowane (oznaczone numerem). Numer wymagania, tytuł i słownictwo są powiązane razem w innym miejscu w dokumencie testowym.

Zarządzanie zmianą wymagań

Prawie żaden projekt rozwoju oprogramowania nie zostałby ukończony bez wprowadzenia pewnych zmian w projekcie. Zmiany mogą wynikać ze zmian w środowisku, w którym ma być używany gotowy produkt, zmian biznesowych, zmian w przepisach, błędów w pierwotnej definicji wymagań, ograniczeń technologicznych, zmian w środowisku bezpieczeństwa i tak dalej. Działania związane z zarządzaniem zmianą wymagań obejmują przyjmowanie żądań zmiany od interesariuszy, rejestrowanie otrzymanych żądań zmiany, analizowanie i określanie celowości i procesu wdrażania, wdrażanie żądania zmiany, zapewnienie jakości wdrożenia i zamykanie żądania zmiany. Następnie dane dotyczące żądań zmian są kompilowane, analizowane, a odpowiednie metryki są wyprowadzane i łączone z organizacyjnym repozytorium wiedzy.

Wydanie

Zarządzanie wymaganiami nie kończy się wraz z wydaniem produktu. Od tego momentu napływające dane dotyczące akceptacji aplikacji są gromadzone i wprowadzane do fazy badania następnej generacji lub wydania. W ten sposób proces zaczyna się od nowa.

Obróbka

Pozyskanie narzędzia wspierającego zarządzanie wymaganiami nie jest sprawą trywialną i należy je podjąć w ramach szerszej inicjatywy doskonalenia procesów. Od dawna panuje przekonanie, że narzędzie, raz nabyte i zainstalowane w projekcie, może zaspokoić wszystkie jego potrzeby związane z zarządzaniem wymaganiami. Jednak zakup lub opracowanie narzędzia wspierającego zarządzanie wymaganiami może być decyzją kosztowną. Organizacje mogą zostać obciążone drogimi umowami wsparcia, nieproporcjonalny wysiłek może zostać skierowany na naukę korzystania z narzędzia i skonfigurowanie go pod kątem określonych potrzeb, a także niewłaściwe użycie, które może prowadzić do błędnych decyzji. Organizacje powinny postępować zgodnie z procesem przyrostowym, aby podejmować decyzje dotyczące narzędzi wspierających ich szczególne potrzeby z szerszego kontekstu ich procesu rozwoju i oprzyrządowania. Narzędzia są przedstawione w Identyfikowalności wymagań .

Zobacz też

Bibliografia

Dalsza lektura

Zewnętrzne linki