Co to jest analiza i gromadzenie wymagań w SDLC?

what is requirement analysis

Ten samouczek wyjaśnia, czym jest analiza wymagań, kroki analizy wymagań, przykłady i cele gromadzenia wymagań w SDLC:

Tworzenie oprogramowania to ogromne zadanie, które tworzy działające oprogramowanie.

Oprogramowanie jest tworzone zgodnie z wymaganiami klienta. Przeważnie to oprogramowanie jest zgodne z oczekiwaniami klienta końcowego / użytkownika, podczas gdy czasami ten produkt nie jest w pełni zgodny z oczekiwaniami klienta / użytkownika końcowego.

Czego się nauczysz:

• Co to jest analiza wymagań?
  • Etapy / kroki analizy wymagań
    • 1) Zbieranie wymagań
    • # 2) Analiza zebranych wymagań
    • # 3) Dokumentowanie przeanalizowanych wymagań
  • Konwersja wymagań biznesowych na wymagania programowe
  • Zrozumienie przypadków wymagań niefunkcjonalnych
  • Różnica między wymaganiami biznesowymi a wymaganiami oprogramowania
• Wniosek
  • rekomendowane lektury

Co to jest analiza wymagań?

Zrozummy analizę wymagań na przykładzie.

Oczekiwania klienta / użytkownika końcowego:

Klient / użytkownik końcowy otrzymuje:

Jak można przeanalizować na podstawie powyższych zdjęć, produkt końcowy nie odpowiada oczekiwaniom klienta. Może to wynikać z niezliczonych powodów. nieprawidłowa realizacja wymagań klienta, wadliwy projekt, błędne zrozumienie wymagań klienta przez programistów i zespół ds. jakości itp.

Jednak, jak widać, czy jest to jakikolwiek powód niewłaściwej dostawy produktu, głównym powodem jest wymaganie. Stąd, jeśli dokonano prawidłowego zrozumienia wymagań, przechwycenia, wdrożenia i testowania, pomogłoby to złagodzić błędne i niekompletne dostarczenie produktu do klienta / użytkownika końcowego.

Dobra dostawa produktu wymaga prawidłowego zebrania wymagań, skutecznego zbadania zebranych wymagań i ostatecznie jasnej dokumentacji wymagań, jako warunku wstępnego. Cały ten proces jest również nazywany Analiza wymagań w cyklu życia oprogramowania (SDLC)

Etapy / kroki analizy wymagań

Jak widać, analiza wymagań jest pierwszą czynnością w SDLC, po której następuje specyfikacja funkcjonalna i tak dalej. Analiza wymagań jest istotnym krokiem w SDLC, ponieważ współgra z testami akceptacyjnymi, które mają krytyczne znaczenie dla akceptacji produktu przez klientów.

W tym samouczku wyjaśnimy, jak analiza wymagań jest wykonywana w SDLC. Zobaczymy również różne kroki, wyniki, wyzwania i środki naprawcze w analizie wymagań.

Analiza wymagań zaczyna się od:

1. Gromadzenie wymagań co jest również nazywane pobudzaniem.
2. To jest po analizowanie zebrane wymagania, aby zrozumieć poprawność i wykonalność przekształcenia tych wymagań w możliwy produkt.
3. I w końcu, dokumentowanie zebrane wymagania.

1) Zbieranie wymagań

Aby upewnić się, że wszystkie powyższe kroki są prawidłowo wykonane, klient musi uzyskać jasne, zwięzłe i prawidłowe wymagania. Klient powinien być w stanie właściwie zdefiniować swoje wymagania, a analityk biznesowy powinien być w stanie zebrać je w taki sam sposób, w jaki klient zamierza je przekazać.

Często nie jest możliwe, aby zbieranie wymagań było sprawnie wykonywane przez analityków biznesowych klienta. Może to wynikać z zależności od wielu osób związanych z oczekiwanym produktem końcowym, narzędziami, środowiskiem itp. Dlatego zawsze dobrze jest zaangażować wszystkich interesariuszy, którzy mogą mieć wpływ lub mogą mieć wpływ na produkt końcowy.

Ewentualną grupą interesariuszy mogą być inżynierowie ds. Jakości oprogramowania (zarówno QC, jak i QA), dowolny dostawca będący stroną trzecią, który mógłby zapewnić wsparcie w projekcie, użytkownik końcowy, dla którego produkt jest przeznaczony, programiści, inny zespół w organizacji, który może moduł lub platforma oprogramowania, biblioteki oprogramowania itp. do rozwoju produktu.

Przykład: W organizacji opracowują produkt ADAS (system kamer dookólnych dla prestiżowego OEM), który tego potrzebuje Stos Autosar i Program rozruchowy pliki binarne otrzymane od innego dostawcy.

Zaangażowanie różnych interesariuszy na etapie zbierania wymagań pomaga w zrozumieniu różnych zależności od siebie i pozwala uniknąć ewentualnego przyszłego konfliktu.

Czasem dobrze jest stworzyć prototypowy model planowanego produktu zamierzonego i pokazać go klientowi. To doskonały sposób, aby przekazać klientom, jakiego produktu oczekują i jak może on wyglądać później. Pomaga to klientowi w wizualizacji produktu, którego oczekuje, i pomaga mu sformułować jasne wymagania.

To tworzenie prototypu zależy od dwóch typów produktu:

1. W organizacji istnieje produkt podobny do zamierzonego przez klientów.
2. Nowy produkt do opracowania.

(ja) W pierwszym przypadku łatwiej jest pokazać klientowi, jak będzie wyglądał produkt końcowy i jak zostałby opracowany. W samochodowym ADAS można pokazać klientom inny produkt, który jest już na rynku i został opracowany w ramach organizacji.

Na przykład, System kamer dookólnych opracowany dla producenta OEM (GM, Volkswagen, BMW itp.) I może być zaprezentowany innemu producentowi OEM.

Proszę zanotować , nie jest rozsądne pokazywanie klientowi produktu / prototypu, który jest w trakcie opracowywania, ponieważ może to naruszać Umowę o zachowaniu poufności podpisaną z innym klientem, dla którego ten produkt jest opracowywany. Może to również skutkować niepotrzebną szamotaniną prawną.

Inny przykład może to być system informacyjno-rozrywkowy, opracowywany przez organizację i już dostępny na rynku. Analitycy biznesowi i inni interesariusze w organizacji mogą zaplanować demonstrację warsztatową dla klienta, wyświetlając systemy informacyjno-rozrywkowe z namacalnym interfejsem HMI, portami złączy urządzeń, piaskownicą itp.

Pomoże to klientowi w zrozumieniu, jak będzie wyglądał produkt końcowy i znacznie wyraźniej przedstawi jego wymagania.

(ii) Drugi przypadek można osiągnąć, tworząc podstawowy model roboczy, wykonując proste kodowanie i składanie (głównie funkcje są tutaj zakodowane na stałe w programach) lub tworząc schemat blokowy lub diagram, który mógłby przekonać klienta, jak będzie wyglądał produkt.

W każdym razie byłoby to wytchnienie dla procesu zbierania wymagań, ponieważ klient teraz wie, czego chce.

Analityk biznesowy może teraz organizować formalne spotkania w celu zebrania wymagań, na które można zaprosić wszystkich interesariuszy, a tym samym może zanotować różne wymagania przedstawione przez klienta (w niektórych przypadkach, jeśli liczba interesariuszy jest większa, można wyznaczyć oddzielnego skrybę do notowania klienta. wymagania lub historie użytkowników, aby analityk biznesowy mógł skoncentrować się na moderowaniu spotkania).

Zebrane wymagania mogą mieć postać historie użytkownika (w programowaniu zwinnym), przypadki użycia, dokumenty klienta w języku naturalnym, diagramy, schematy blokowe itp. Historie użytkowników stają się popularne we współczesnym cyklu życia oprogramowania. Historie użytkowników to w zasadzie zestaw danych wejściowych klientów w ich języku naturalnym.

Przykład zbierania wymagań: W systemie kamer ADAS z widokiem dookólnym jedna z możliwych historii użytkownika może brzmieć: „Jako użytkownik powinienem być w stanie zobaczyć, co jest z tyłu mojego samochodu”.

Może być wielu 'dlaczego,' pytania zadawane przy każdej historyjce użytkownika, co pomoże klientowi w dostarczeniu bardziej szczegółowych informacji na temat wymagań.

Jeśli w powyższej historii użytkownika klient mówi „Jako użytkownik powinienem być w stanie zobaczyć, co jest w tylnej części mojego samochodu”, zadając pytanie 'dlaczego ”Może dać„ Jako użytkownik powinienem być w stanie zobaczyć, co jest w lusterku wstecznym mojego samochodu, aby móc bezpiecznie zaparkować samochód ”.

Zadawanie pytania 'dlaczego' pomaga również w tworzeniu obiektywnych i atomowych wymagań z ogromnych wypowiedzi w języku naturalnym podawanych przez klienta. Można to łatwo zaimplementować później w kodzie.

jak otwierać pliki bin na Androidzie

Innym sposobem zbierania wymagań jest format przypadków użycia . Przypadek użycia to podejście krok po kroku do osiągnięcia określonego rezultatu. Nie mówi to, jak oprogramowanie będzie działać na dane wejściowe użytkownika, a raczej mówi, czego oczekuje się od danych wejściowych użytkownika.

Przykład:

# 2) Analiza zebranych wymagań

Zbieranie zapotrzebowań, rozpoczyna się analiza wymagań. Na tym etapie różni interesariusze odbywają sesję burzy mózgów. Analizują zebrane wymagania i szukają możliwości ich wdrożenia. Dyskutują ze sobą, a wszelkie niejasności są wyjaśniane.

Ten krok jest ważny w procesie analizy wymagań z następujących głównych powodów:

(ja) Klient może podać pewne wymagania, których implementacja może być niemożliwa ze względu na różne zależności.

Przykład: Kliencimoże poprosić o obejrzenie systemu kamer z funkcją kamery cofania, która pomoże parking samochód. Klient może również poprosić o Zwiastun filmu funkcja zaczepu, która również wykorzystuje do pracy tylną kamerę.

Jeśli klient stwierdzi, że jest wymagana kamera cofania parking pomoc powinna działać przez cały czas bez wyjątku, wtedy Zwiastun filmu funkcja nigdy nie zadziała i na odwrót.

(ii) Analityk biznesowy mógł zrozumieć wymaganie z klient inaczej niż jak programista zinterpretowałbym.

Ponieważ programiści myślą jak eksperci techniczni, zawsze istnieje możliwość, że wymagania klienta zostaną nieprawidłowo przekonwertowane na specyfikacje funkcjonalne, które później zostaną niepoprawnie wprowadzone do dokumentacji architektonicznej i projektowej, a następnie do kodu. Wpływ jest wykładniczy, dlatego należy go sprawdzić.

Możliwym środkiem zaradczym może być zastosowanie zwinnej metody tworzenia oprogramowania, śledzenie przypadków użycia dostarczonych przez klienta itp.

# 3) Dokumentowanie przeanalizowanych wymagań

Po zakończeniu analizy wymagań rozpoczyna się dokumentacja wymagań. Analiza wymagań wynika z różnego rodzaju wymagań.

Oto niektóre z nich:

(ja) Specyfikacja wymagań klienta.

(ii) Wymaganie dotyczące architektury oprogramowania.

Przykład:

(iii) Wymagania dotyczące projektowania oprogramowania.

Przykład:

zrobić kopię tablicy java

(iv) Specyfikacja wymagań funkcjonalnych (bezpośrednio wyprowadzona ze specyfikacji klienta).

Przykład: „Gdy użytkownik naciśnie ikonę Bluetooth w Infotainment HMI, powinien zostać wyświetlony ekran Bluetooth”

(v) Niefunkcjonalna specyfikacja wymagań (mianowicie wydajność, obciążenie, obciążenie itp.).

Przykład: „Powinno być możliwe sparowanie 15 urządzeń Bluetooth z systemem informacyjno-rozrywkowym bez pogorszenia wydajności systemu”.

(my) Wymagania dotyczące interfejsu użytkownika.

Przykład: „Na ekranie Tuner FM powinien znajdować się przycisk do wybierania różnych stacji”

Powyższe wymagania są rejestrowane i dokumentowane w narzędziach do zarządzania wymaganiami, takich jak IBM DOORS, HP QC. Czasami organizacje mają własne narzędzia do zarządzania wymaganiami, które pozwalają obniżyć koszty.

Przyjrzyjmy się teraz procesowi konwersji Wymagania biznesowe do Wymagania Systemowe (funkcjonalne i niefunkcjonalne).

Konwersja wymagań biznesowych na wymagania programowe

Wymagania biznesowe, jak omówiono powyżej, to wymagania wysokiego poziomu, które mówią o tym, czego użytkownik końcowy oczekuje od określonego działania w systemie oprogramowania. Opracowanie całego systemu oprogramowania w oparciu o te wymagania nie jest możliwe, ponieważ nie wspomniano o szczegółowym opisie sposobu wdrożenia systemu lub komponentu oprogramowania.

Dlatego wymagania biznesowe muszą zostać podzielone na bardziej szczegółowe wymagania dotyczące oprogramowania, które będą dalej uszczegóławiane na wymagania funkcjonalne i niefunkcjonalne.

Aby to zrobić, można wykonać następujące kroki:

1. Podziel wysokie wymagania biznesowe na szczegółowe historie użytkowników.
2. Tworzenie schematu blokowego w celu zdefiniowania przepływu działań.
3. Zapewnienie warunku uzasadniającego pochodne historyjki użytkownika.
4. Diagramy szkieletowe wyjaśniające przepływ pracy obiektów.
5. Definiowanie niefunkcjonalnych wymagań z wymagań biznesowych.

Zacznijmy od przykładu Automotive Infotainment.

Wymóg biznesowy mówi: „Użytkownik końcowy powinien mieć dostęp do pola widżetu nawigacji z poziomu interfejsu HMI systemu Infotainment i powinien mieć możliwość ustawienia adresu docelowego”.

Tak więc powyższe kroki można zaimplementować jako:

# 1) Podziel wysokie wymagania biznesowe na szczegółowe historie użytkowników.

Przekształćmy to wymaganie biznesowe w historię użytkownika na wysokim poziomie, „ Jako użytkownik powinienem mieć dostęp do pola widżetu Nawigacja, aby móc wprowadzić adres docelowy ”. Ta historia użytkownika mówi, czego potrzebuje użytkownik końcowy. Postaramy się zdefiniować, jak zrealizować ten wymóg.

Zacznijmy od zadania możliwych pytań dotyczących tego historyjki użytkownika.

1. Kim są użytkownicy?
2. Jak mogę uzyskać dostęp do nawigacji, wbudowanej (z karty SD) lub ze smartfona?
3. Jaki rodzaj miejsc docelowych mogę wprowadzić?
4. Czy powinienem mieć prawo wjazdu do celu, nawet gdy samochód jest na parkingu?

Są to bardziej szczegółowe historie użytkowników pochodzące z historii użytkowników wysokiego poziomu i pomogłyby nam uzyskać lepszy wgląd w nasze wymagania biznesowe.

W tym momencie możemy zająć się jedną z pod-historii użytkownika i zacząć zadawać pytania. Weźmy (nr 3):

1. Czy mogę wprowadzić miejsca docelowe, takie jak współrzędne geograficzne, adres pocztowy, za pomocą funkcji rozpoznawania mowy itp.?
2. Czy potrzebuję GPS do wprowadzania współrzędnych geograficznych?
3. Czy mogę wprowadzić aktualny adres docelowy, wyszukując w historii adresów?

# 2) Stworzenie schematu blokowego w celu zdefiniowania przepływu działań.

Teraz widzimy, że wymaganie biznesowe jest podzielone na bardzo szczegółowe przypadki użycia, które można zaznaczyć na schemacie blokowym, jak poniżej:

# 3) Zapewnienie warunków uzasadniających pochodne historyjki użytkownika.

Widzimy, że bardziej szczegółowe informacje pojawiają się w wyniku dekompozycji wymagań biznesowych wysokiego poziomu na szczegółowe historie użytkowników niskiego poziomu i na schemat blokowy. Z tego schematu możemy uzyskać szczegóły techniczne potrzebne do wdrożenia, a mianowicie.

• Czas wczytywania ekranu do wyświetlenia miejsca docelowego powinien wynosić 1 sekundę.
• Klawiatura do wprowadzania miejsca docelowego powinna zawierać znaki alfanumeryczne i symbole specjalne.
• Przycisk włączania / wyłączania GPS powinien być obecny na ekranie wprowadzania celu nawigacji.

Powyższe informacje spełniają historyjki użytkownika i umożliwiają dyskretne i mierzalne testowanie wymagania, co pozwala uniknąć nieporozumień z wymaganiem podczas implementacji jako funkcji.

# 4) Diagramy szkieletowe wyjaśniające przepływ pracy obiektów.

Z powyższego przypadku użycia wyprowadzimy diagram szkieletowy, który sprawi, że interfejs użytkownika będzie bardziej przejrzysty.

# 5) Definiowanie niefunkcjonalnych wymagań z wymagań biznesowych.

Konieczne jest, aby szczegółowe wymagania dotyczące oprogramowania wywodziły się z wymagań biznesowych wysokiego poziomu, ale często identyfikowane są tylko wymagania funkcjonalne, które określają, jak system będzie się zachowywał przy danych wejściowych / czynnościach użytkownika.

Jednak wymagania funkcjonalne nie wyjaśniają wydajności systemu ani innych parametrów jakościowych, takich jak dostępność, niezawodność itp.

Przykłady:

a) Weźmy na przykład powyższy samochodowy system informacyjno-rozrywkowy.

Jeśli kierowca (użytkownik końcowy) samochodu odtwarza muzykę z USB, a nawigacja jest w toku, odbiera również połączenie przychodzące przez Bluetooth w trybie głośnomówiącym, wtedy obciążenie procesora i pamięci RAM wzrasta do maksymalnego poziomu, ponieważ wiele procesów jest działa w tle.

W tym momencie, jeśli kierowca dotknie interfejsu ekranu dotykowego systemu Infotainment, aby odrzucić połączenie przychodzące za pomocą automatycznej odpowiedzi SMS (tak samo jak w naszych telefonach komórkowych), system powinien być w stanie wykonać to zadanie i nie powinien się zawieszać ani zawieszać. To jest wydajność systemu, gdy obciążenie jest duże i testujemy dostępność i niezawodność.

b) Innym przypadkiem jest scenariusz stresu.

Weźmy na przykład system informacyjno-rozrywkowy, który odbiera wiadomości SMS (może 20 w ciągu 10 sekund) za pośrednictwem podłączonego telefonu Bluetooth. System Infotainment powinien być w stanie obsłużyć wszystkie przychodzące SMS-y i w żadnym momencie nie powinien przegapić żadnego przychodzącego powiadomienia SMS na Infotainment HMI.

Powyższe przykłady to przypadki wymagań niefunkcjonalnych, których nie można przetestować za pomocą samych wymagań funkcjonalnych. Chociaż czasami klienci nie spełniają tych niefunkcjonalnych wymagań. Organizacja jest odpowiedzialna za dostarczenie im tych informacji, gdy produkt jest dostarczany do klienta.

Zrozumienie przypadków wymagań niefunkcjonalnych

Poniższa tabela wyjaśnia wymagania niefunkcjonalne:

Wymagania niefunkcjonalne, w przeciwieństwie do wymagań funkcjonalnych, wymagają pełnego cyklu życia projektu, aby zostać wdrożone, ponieważ są wdrażane stopniowo w odpowiednich Sprintach Agile lub w różnych iteracjach.

Tak więc w ten sposób wyprowadzamy wymagania programowe z wymagań biznesowych.

Różnica między wymaganiami biznesowymi a wymaganiami oprogramowania

Widzieliśmy powyżej, jak wyprowadzić wymagania dotyczące oprogramowania z wymagań biznesowych wysokiego poziomu. Wymagania programowe umożliwiają programiście i inżynierom testów opracowanie systemu i sprawne przetestowanie go. Tak więc teraz wiemy, że wymagania biznesowe są wysokopoziomowymi wymaganiami klienta w języku naturalnym, podczas gdy wymagania dotyczące oprogramowania to szczegółowe wymagania niskiego poziomu, które pomagają we wdrożeniu systemu oprogramowania.

Przyjrzyjmy się szczegółowej różnicy między tymi dwoma typami wymagań.

Wniosek

Analiza wymagań jest podstawą każdego modelu SDLC.

Problem pominięty podczas analizy wymagań i złapany podczas testów jednostkowych może kosztować organizację dziesiątki tysięcy dolarów, a ten koszt może doprowadzić do milionów dolarów, jeśli pochodzi z rynku jako wezwanie zwrotne (w 2017 r. Producent ładowanych poduszek powietrznych w USA, Takata a grzywna w wysokości 1 miliarda dolarów z powodu wybuchu poduszek powietrznych).

Organizacja wykonywałaby zadania związane z kontrolą szkód, takie jak analiza przyczyn źródłowych, przygotowanie 5 dokumentów dlaczego, analiza drzewa błędów, dokument 8D itp. Zamiast koncentrować się na rozwoju oprogramowania i jakości.

W najgorszych przypadkach organizacja zostałaby wciągnięta w pozwy sądowe wniesione przez klienta, jeśli dana funkcja jest związana z bezpieczeństwem, takim jak dostęp do ochrony, poduszka powietrzna, ABS (układ przeciwblokujący) itp.

rekomendowane lektury

• Fazy, metodologie, proces i modele SDLC (cyklu życia oprogramowania)
• Cechy wymagań funkcjonalnych i wymagań niefunkcjonalnych
• Jak przetestować specyfikację wymagań oprogramowania (SRS)?
• 5 śmiertelnych błędów w zarządzaniu wymaganiami i jak je przezwyciężyć
• Jak przetestować aplikację bez wymagań?
• Środki dotyczące SSDLC (bezpieczny cykl życia oprogramowania)
• Model spiralny - Co to jest model spiralny SDLC?
• Co to jest model wodospadu SDLC?