Kompleksowy i solidny proces specyfikacji wymagań
Kompleksowy i solidny proces specyfikacji wymagań (CRRSP) lub CRRSP (czyt. ostry ) to metodologia gromadzenia, definiowania i sprawdzania poprawności wymagań dotyczących oprogramowania . CRRSP nie jest restrykcyjnym procesem krok po kroku, ale adaptowalną ramą, zamierzoną do dostosowania przez zespoły analizy biznesowej, które wybierają elementy procesu odpowiednie dla ich potrzeb.
Historia
CRSP został opracowany w 2008 roku przez starszego analityka biznesowego, Barbarę Davis, po latach badań i udoskonalania dzięki praktycznym doświadczeniom jako starszy analityk biznesowy i dyrektor centrum doskonałości analityków biznesowych w organizacjach takich jak UST Global i Safeway .
Związek z innymi metodologiami
Podejście CRRSP do wymagań oprogramowania pozwala na aplikacje z większością typów metodologii projektowych oraz elastycznym i elastycznym punktem wyjścia, w którym można zastosować metodologię. CRRSP różni się od innych metodologii, takich jak Waterfall , RAD , Agile i RUP , ponieważ jest to konkretnie metodologia definiowania i walidacji wymagań w kontekście większego cyklu życia projektu, podczas gdy inne to metodologie projektowe, które definiują sam ogólny cykl życia projektu .
Jednym z głównych czynników w CRRSP jest to, że ewoluuje wymagania poprzez wymagania wysokiego, średniego i niskiego poziomu poprzez coraz głębsze nurkowanie w zabezpieczeniach wymagań.
Gradacja
Kluczowymi etapami metodologii wymagań CRRSP są badania i pozyskiwanie, analiza, opracowanie i specyfikacja oraz walidacja. Charakteryzuje się szczegółowymi etapami walidacji, narzędziami i technikami, a także unikalnymi wynikami analiz i produktami identyfikowalności.
Badania i pozyskiwania
Celem etapu badań i pozyskiwania jest zrozumienie i zbadanie czynników biznesowych, celów i celów, artefaktów projektu utworzonych do tej pory oraz stworzenie przepływu pracy, który pomoże zilustrować obecny stan i pożądany stan przyszły. Ostatecznie określa wymagania średniego poziomu projektu.
Analiza
Analizując wymagania średniego poziomu, analityk wykorzystuje ocenę luk, bardziej szczegółową formę analizy luk oraz tabele przyczynowo-skutkowe lub decyzyjne, aby nakreślić scenariusze, dalej przekształcając wymagania wysokiego poziomu w wymagania średniego poziomu.
Opracowanie i specyfikacja
Opracowanie i specyfikacja to etap spójnego dokumentowania i tworzenia dokumentu wymagań w formacie, który ostatecznie zostanie przekazany zespołom projektowym, programistycznym i testowym w celu wykorzystania ich do tworzenia ich produktów i rezultatów. Generuje dopracowane reguły biznesowe, dopracowane schematy przepływu pracy i wymagania niskiego poziomu.
Konwencja nazewnictwa i numeracji
Metodologia CRRSP narzuca ścisłą konwencję nazewnictwa i numeracji wymagań w ramach projektu i ogólnie produktów. Wynika to z podobnego uzasadnienia i logiki stojącej za nazywaniem huraganów i tornad, ponieważ wymaganiu przypisuje się wyłączny numer, który pozostaje jego własnym, nawet jeśli artykuł zostanie złomowany. Zapewnia to dokładną identyfikowalność w wielu wersjach dokumentacji i zmianach zakresu.
Numery są przypisywane do ostatecznej wersji roboczej przed udostępnieniem zespołom projektowym, programistycznym i testowym w procesie przeglądu niejednoznaczności. Gwarantuje to, że nie będzie zamieszania wśród zespołu BA podczas dokumentowania wymagań. Numery są przypisane tylko do wymagań wysokiego poziomu; podnumery są przypisane do wymagań średniego i niskiego poziomu, ponieważ są one rozszerzeniem wymagań wysokiego poziomu.
Na przykład, jeśli wymagania dotyczące internetowego koszyka na zakupy określają, że aplikacja musi być w stanie obliczyć podatek dla określonego stanu i/lub prowincji klienta internetowego, wymaganie byłoby zapisane w następujący sposób:
1.1 Klienci muszą mieć możliwość wyboru stanu ORAZ/LUB prowincji za pomocą selektora.
Jednak wymaganie zostanie później zmienione, aby stwierdzić, że aplikacja musi być w stanie obliczyć podatek dla określonego stanu i/lub prowincji klienta online, wówczas wymaganie zostanie przepisane jako:
1.1 Wymóg usunięty. 1.2 Stan lub prowincja z profilu klienta zostaną użyte do obliczenia podatków od zakupu.
Walidacja
Walidacja wykorzystuje kombinację technik niejednoznaczności pochodzących z testów opartych na wymaganiach i modelowania logicznego. Techniki te obejmują dziennik niejednoznaczności, przegląd niejednoznaczności i wskazówki dotyczące niejednoznaczności z udziałem zespołów projektowych, deweloperskich i testujących w celu ustalenia jasności i kompletności wymagań. Recenzje i przewodniki wykorzystują jasny zestaw kryteriów dla recenzentów, aby upewnić się, że informacje są kompletne, spójne, dokładne i napisane językiem, który jasno określa i definiuje zamierzone funkcjonowanie nowego oprogramowania.
Analiza porównawcza
Zwolennicy tej metodologii są w stanie zastosować specjalistyczną formułę do określenia efektywności działań związanych z wymaganiami poprzez benchmarking i pomiar względem ustalonego benchmarku. Poprzez analizę porównawczą działań związanych z wymaganiami w całym projekcie, zespół BA jest w stanie lepiej zrozumieć, gdzie spędzany jest czas, jak go udoskonalić oraz być w stanie zwiększyć wydajność i skuteczność zadań jako sposób na ulepszenie projektu. Okazało się, że jest to najskuteczniejsza technika szybkiego dostosowania słabnącego projektu ze względu na wgląd, jaki zapewnia zespołowi podczas procesu.
Analizując ogólnie działania związane z wymaganiami w wielu projektach, organizacje są w stanie uzyskać bardziej szczegółowy obraz działań związanych z wymaganiami i określić, gdzie można je ulepszyć. Może to wskazywać na możliwości szkolenia wśród zespołu analizy biznesowej, zapotrzebowanie na więcej zasobów lub większe wsparcie kierownictwa, ale może również wskazywać, czy problem dotyczy zespołów programistycznych czy testujących. Może również dostarczyć wystarczających dowodów na poparcie zmiany ogólnych procesów cyklu życia.
Zasady biznesowe
Reguły biznesowe są zwykle podzielone na osobny dokument z odniesieniami zawartymi w samych wymaganiach. Konwencje nazewnictwa i numeracji są takie same jak w przypadku wymagań, ale są oznaczone jako zasady z literą „B” poprzedzającą numer.
Na przykład, jeśli reguła biznesowa B36 dla tego samego koszyka na zakupy stanowi, że podatki są naliczane od całkowitej kwoty zakupu zgodnie z 12% stawką podatkową dla Kolumbii Brytyjskiej, wówczas reguła biznesowa będzie zapisana jako:
B36.1 Stawka podatkowa dla Kolumbii Brytyjskiej 12%
Jeśli wymaganie 1.1 odwołuje się do tej reguły biznesowej, byłoby zapisane jako:
1.1 Klient musi mieć możliwość wyboru swojego stanu ORAZ/LUB prowincji z selektora. Obowiązujące reguły biznesowe: B36
Przypadków użycia
Przypadki użycia można rozpocząć w dowolnym momencie procesu wymagań i udoskonalić po spełnieniu wymagań. Ich wartość polega na dodaniu warstwy walidacji wymagań w celu wsparcia przeglądu pod kątem kompletności. Mogą one zostać przedstawione użytkownikom w przewodniku, aby pomóc zweryfikować krok po kroku proces, przez który użytkownik i system przejdą podczas wykonywania określonych transakcji. Zarówno przypadki użycia literackie (opisowe), jak i diagramowe (takie jak UML , Activity lub Swim Lane ) są odpowiednie do tego ze względu na wartość, jaką każdy z nich może zapewnić użytkownikom końcowym.
Linki zewnętrzne
- [4] Dostęp do oficjalnych informacji CRRSP (w tym certyfikacji i plików do pobrania) na stronie Requirements Networking Group
- [5] Witryna Bender RBT