Co To jest analiza wymagań i zbieranie w SDLC?

ten poradnik wyjaśnia, co to jest analiza wymagań, kroki analizy wymagań, przykłady i cele gromadzenia wymagań w SDLC:

Rozwój oprogramowania to ogromne zadanie, które tworzy działający produkt programowy.

oprogramowanie jest zbudowane zgodnie z wymaganiami klienta. Najczęściej ten produkt jest zgodny 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.

Co To jest analiza wymagań?

pozwól nam zrozumieć analizę wymagań za pomocą przykładu.

oczekiwania klienta/użytkownika końcowego:

klient / użytkownik końcowy otrzymuje:

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

jednak, jak widać, niezależnie od powodu niewłaściwej dostawy Produktu, głównym powodem jest wymóg. W związku z tym, gdyby dokonano prawidłowego zrozumienia wymagań, przechwytywania, wdrażania i testowania, pomogłoby to złagodzić błędną i niekompletną dostawę produktu do klienta/użytkownika końcowego.

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

etapy analizy wymagań / kroki

jak widać, Analiza wymagań jest pierwszą czynnością w SDLC, a następnie specyfikacją funkcjonalną i tak dalej. Analiza wymagań jest ważnym krokiem w SDLC, ponieważ rezonuje z testami akceptacyjnymi, które są krytyczne dla akceptacji produktu przez klientów.

w tym samouczku wyjaśnimy, w jaki sposób 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ń, które jest również nazywane elicitation.
2. następnie analizuje zebrane wymagania, aby zrozumieć poprawność i wykonalność przekształcenia tych wymagań w możliwy produkt.
3. i wreszcie dokumentowanie zebranych wymagań.

#1) gromadzenie wymagań

aby upewnić się, że wszystkie kroki wymienione powyżej są odpowiednio wykonane, należy zebrać od klienta jasne, zwięzłe i prawidłowe wymagania. Klient powinien być w stanie prawidłowo zdefiniować swoje wymagania, a analityk biznesowy powinien być w stanie zebrać go w taki sam sposób, w jaki klient zamierza przekazać.

często nie jest możliwe, aby zbieranie wymagań było wykonywane sprawnie przez analityków biznesowych od 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 dobrym pomysłem jest zaangażowanie wszystkich zainteresowanych stron, które mogą mieć wpływ na produkt końcowy.

potencjalną grupą interesariuszy mogą być inżynierowie ds. jakości oprogramowania (zarówno QC, jak i QA), każdy dostawca zewnętrzny, 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 dostarczyć moduł lub platformę programową, biblioteki oprogramowania itp. dla rozwoju produktu.

przykład: w organizacji opracowują produkt ADAS (system kamer surround dla prestiżowego producenta OEM), który potrzebuje stosu Autosar i binariów Bootloadera otrzymanych od innego dostawcy.

zaangażowanie różnych zainteresowanych stron w etap gromadzenia wymagań pomaga w zrozumieniu różnych zależności od siebie i można zapobiec ewentualnym przyszłym konfliktom.

czasami dobrym pomysłem jest stworzenie prototypowego modelu planowanego produktu i pokazanie go Klientowi. Jest to doskonały sposób, aby przekazać klientom, jakiego produktu oczekują i jak może wyglądać później. Pomaga to klientowi w wizualizacji produktu, którego oczekuje i pomaga mu wymyślić jasne wymagania.

to stworzenie prototypu zależy od dwóch rodzajów produktu:

1. podobny produkt, który zamierzali klienci, istnieje w organizacji.
2. nowy produkt do opracowania.

(i) w pierwszym przypadku łatwiej jest pokazać klientowi, jak wyglądałby produkt końcowy i jak byłby rozwijany. W Automotive ADAS możliwe jest pokazanie klientom innego produktu, który jest już na rynku i został opracowany w ramach organizacji.

na przykład system kamer surround opracowany dla OEM (GM, Volkswagen, BMW itp.) i może być zaprezentowany innemu OEM.

należy pamiętać, że nie jest rozsądne pokazywanie produktu / produktu proto klientowi, który jest w fazie rozwoju, ponieważ może to naruszać umowę o Zachowaniu Poufności podpisaną z innym klientem, dla którego produkt jest opracowywany. Może to również prowadzić do niepotrzebnych sprzeczek prawnych.

Innym przykładem może być system infotainment, rozwijany przez organizację i już dostępny na rynku. Analitycy biznesowi i inni interesariusze w organizacji mogą zaplanować demo warsztatowe dla klienta, wyświetlając systemy infotainment z namacalnym HMI, portami złącza urządzenia, piaskownicą itp.

pomoże to klientowi zrozumieć, jak wyglądałby 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 montaż (większość funkcji tutaj jest zakodowana na twardo w programach) lub tworząc SCHEMAT BLOKOWY lub diagram, który może przekonać klienta, jak produkt będzie wyglądał.

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

analityk biznesowy może teraz organizować formalne spotkania informacyjne, na których można zaprosić wszystkich interesariuszy, a tym samym może zanotować różne wymagania dostarczone przez Klienta (w niektórych przypadkach, jeśli interesariusze są liczniejsi, można wyznaczyć oddzielnego skrybę, aby zanotować wymagania klientów lub historie użytkowników, aby analityk biznesowy mógł skoncentrować się na moderowaniu spotkania).

zebrane wymagania mogą mieć postać user stories (w zwinnym rozwoju), przypadków użycia, dokumentów w języku naturalnym klienta, diagramów, schematów itp. Historie użytkowników stają się popularne we współczesnym cyklu życia oprogramowania. User stories są w zasadzie zbiorem danych wejściowych klientów w ich naturalnym języku.

przykład zbierania wymagań: w systemie kamer przestrzennych ADAS jedna z możliwych historii użytkownika może być: „jako użytkownik powinienem być w stanie zobaczyć, co jest w widoku z tyłu mojego samochodu”.

w każdej historii użytkownika może być wiele pytań „Dlaczego”, które pomogą klientowi w dostarczeniu bardziej szczegółowych informacji na temat wymagań.

w powyższej historii użytkownika, jeśli klient mówi” Jako użytkownik, powinienem być w stanie zobaczyć, co jest w widoku z tyłu mojego samochodu”, zadając pytanie” dlaczego „może dać”jako użytkownik, powinienem być w stanie zobaczyć, co jest w widoku z tyłu mojego samochodu, abym mógł bezpiecznie zaparkować samochód”.

pytanie „dlaczego” pomaga również w tworzeniu obiektywnych i atomowych wymagań z ogromnych wypowiedzi w języku naturalnym podanych przez Klienta. Można to łatwo zaimplementować później w kodzie.

innym sposobem zbierania wymagań jest w postaci przypadków użycia. Przypadek użycia to krok po kroku podejście do osiągnięcia określonego wyniku. To nie mówi, jak oprogramowanie będzie działać na danych wejściowych użytkownika, ale mówi, czego oczekuje się od danych wejściowych użytkownika.

przykład:

#2) analiza zebranych wymagań

po zebraniu wymagań, rozpoczyna się analiza wymagań. Na tym etapie różne zainteresowane strony siedzą i przeprowadzają burzę mózgów. Analizują zebrane wymagania i szukają możliwości ich wdrożenia. Dyskutują ze sobą i wszelkie niejasności są rozwiązywane.

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

(i) klient może podać pewne wymagania, które mogą być niemożliwe do wdrożenia z powodu różnych zależności.

przykład: klienci mogą poprosić o Widok przestrzenny systemu kamer z funkcją kamery tylnej, która pomoże w parkowaniu samochodu. Klient może również poprosić o funkcję zaczepu przyczepy, która wykorzystuje również tylną kamerę do pracy.

jeśli klient oświadczy, że kamera tylna do pomocy w parkowaniu powinna działać przez cały czas bez wyjątku, funkcja Przyczepy nigdy nie będzie działać i odwrotnie.

(ii) analityk biznesowy mógł zrozumieć wymóg klienta inaczej niż w jaki sposób programista zinterpretował.

ponieważ programiści uważają się za ekspertów technicznych, zawsze jest możliwe, że wymagania klienta są niepoprawnie przekształcane w specyfikacje funkcjonalne, które później zostaną niepoprawnie wprowadzone do architektury i dokumentów projektowych, a następnie do kodu. Wpływ jest wykładniczy i dlatego należy go sprawdzić.

możliwym środkiem zaradczym może być stosowanie zwinnej metody tworzenia oprogramowania, śledzenie przypadków użycia, które zapewnia klient itp.

#3) dokumentowanie analizowanych wymagań

po zakończeniu analizy wymagań rozpoczyna się dokumentacja wymagań. Z analizy wymagań wychodzą różne rodzaje wymagań.

niektóre z nich to:

(i) specyfikacja wymagań klienta.

(ii) wymagania dotyczące architektury oprogramowania.

przykład:

(iii) wymagania dotyczące projektowania oprogramowania.

przykład:

(iv) Specyfikacja wymagań funkcjonalnych (bezpośrednio pochodząca ze specyfikacji klienta.)

przykład: „gdy użytkownik dotknie ikony Bluetooth na HMI Infotainment, ekran Bluetooth powinien być wyświetlony”

(v) specyfikacja wymagań niefunkcjonalnych (tj. wydajność, stres, obciążenie itp.).

przykład: „powinno być możliwe sparowanie 15 urządzeń Bluetooth z systemem infotainment bez pogorszenia wydajności systemu”.

(vi) wymagania dotyczące interfejsu użytkownika.

przykład: „Na ekranie tunera FM powinien być umieszczony przycisk do wyboru 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ą niestandardowe narzędzia do zarządzania wymaganiami, aby obniżyć koszty.

przyjrzyjmy się teraz procesowi przekształcania wymagań biznesowych w Wymagania programowe (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 chce od określonej akcji w systemie oprogramowania. Opracowanie całego systemu oprogramowania w oparciu o te wymagania nie jest możliwe, ponieważ nie podano szczegółowego opisu sposobu implementacji systemu lub komponentu oprogramowania.

tak więc wymagania biznesowe muszą być podzielone na bardziej szczegółowe wymagania dotyczące oprogramowania, które będą bardziej szczegółowe do wymagań funkcjonalnych i niefunkcjonalnych.

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

1. podziel wysokie wymagania biznesowe na szczegółowe historie użytkowników.
2. Wyprowadzanie schematu blokowego w celu zdefiniowania przepływu działań.
3. podanie warunku uzasadniającego pochodne historie użytkowników.
4. Schematy szkieletowe wyjaśniające przepływ pracy obiektów.
5. Definiowanie wymagań niefunkcjonalnych poza wymaganiami biznesowymi.

zacznijmy od przykładowego Automotive Infotainment system.

wymóg biznesowy mówi:”użytkownik końcowy powinien mieć dostęp do widżetu nawigacyjnego z systemu Infotainment HMI i powinien być w stanie ustawić adres docelowy”.

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

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

przekonwertujmy ten wymóg biznesowy na historię użytkownika wysokiego poziomu: „jako użytkownik powinienem mieć dostęp do okna widżetu nawigacji, aby móc wprowadzić adres docelowy”. Ta historia użytkownika opowiada, co jest potrzebne użytkownikowi końcowemu. Postaramy się określić, jak wdrożyć ten wymóg.

zacznijmy od zadawania ewentualnych pytań temu użytkownikowi.

1. kim są użytkownicy?
2. jak Mogę uzyskać dostęp do nawigacji na pokładzie (z karty SD) lub ze smartfona?
3. jakie miejsca docelowe mogę wpisać?
4. Czy powinienem mieć możliwość wjazdu do miejsca docelowego, nawet gdy samochód jest na parkingu?

są to bardziej szczegółowe historie użytkowników na poziomie wywodzące się z historii użytkowników na wysokim poziomie i pomogłyby nam uzyskać lepszy wgląd w nasze wymagania biznesowe.

w tym momencie możemy wziąć jedną z podpowiedzi użytkownika i zacząć przesłuchiwać. Weźmy (nie. 3):

1. Czy mogę wprowadzić wpisy docelowe, takie jak współrzędne geograficzne, adres pocztowy, Rozpoznawanie mowy itp.?
2. Czy potrzebuję GPS do wprowadzania współrzędnych geograficznych?
3. Czy mogę wprowadzić bieżący adres docelowy, wyszukując w historii adresów?

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

teraz widzimy, że wymóg biznesowy jest podzielony na bardzo szczegółowe przypadki użycia, które można oznaczyć na schemacie blokowym, jak poniżej:

#3) zapewnienie warunków uzasadniających pochodne historie użytkowników.

widzimy, że bardziej szczegółowe informacje pojawiają się z powodu rozkładu wymagań biznesowych wysokiego poziomu na szczegółowe historie użytkowników niskiego poziomu i na SCHEMAT BLOKOWY. Na podstawie tego schematu możemy uzyskać szczegóły techniczne potrzebne do wdrożenia, tj.

• czas ładowania ekranu do wyświetlenia wpisu docelowego powinien wynosić 1 sek.
• klawiatura wpisu docelowego powinna mieć znaki alfanumeryczne i symbole specjalne.
• Włącz/Wyłącz GPS przycisk przełączania powinien być obecny na ekranie wprowadzania celu nawigacji.

powyższe informacje spełniają historie użytkowników i umożliwiają dyskretne i wymierne testowanie wymogu, unikając pomylenia z wymogiem podczas wdrażania jako funkcje.

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

na podstawie powyższego przypadku użycia uzyskamy schemat szkieletu, który sprawi, że interfejs użytkownika będzie jaśniejszy.

#5) Definiowanie wymagań niefunkcjonalnych poza wymaganiami biznesowymi.

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 mówią, jak system zachowa się do określonego wejścia/działania użytkownika.

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

przykłady:

a) weźmiemy przykład powyższego automotive infotainment system.

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

w tym momencie, jeśli kierowca dotknie ekranu dotykowego systemu infotainment, aby odrzucić połączenie przychodzące za pomocą wiadomości SMS z automatyczną odpowiedzią (tak samo jak w naszych telefonach komórkowych), system powinien być w stanie wykonać to zadanie i nie powinien zawieszać się ani ulegać awarii. Jest to wydajność systemu, gdy obciążenie jest wysokie i testujemy dostępność i niezawodność.

B) innym przypadkiem jest scenariusz stresu.

Weźmy na przykład, system infotainment odbiera z powrotem SMSs (może 20 SMS w ciągu 10 sekund) za pośrednictwem podłączonego telefonu Bluetooth. System Infotainment powinien obsługiwać wszystkie przychodzące wiadomości SMS 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 było przetestować za pomocą samych wymagań funkcjonalnych. Chociaż czasami klienci tęsknią za dostarczeniem tych niefunkcjonalnych wymagań. Obowiązkiem organizacji jest dostarczenie im tych informacji, gdy produkt jest dostarczany do klienta.

zrozumienie wymagań niefunkcjonalnych przypadków

poniższa tabela wyjaśnia wymagania niefunkcjonalne:

wymagania niefunkcjonalne, w przeciwieństwie do wymagań funkcjonalnych, weź pełny cykl życia projektu, aby go wdrożyć, ponieważ są one wdrażane stopniowo w odpowiednich sprintach zwinnych lub w różnych iteracjach.

w ten sposób wyprowadzamy wymagania dotyczące oprogramowania z wymagań biznesowych.

różnica między wymaganiami biznesowymi a wymaganiami dotyczącymi oprogramowania

widzieliśmy powyżej, jak czerpać wymagania dotyczące oprogramowania z wymagań biznesowych wysokiego poziomu. Wymagania programowe umożliwiają programiście i inżynierowi testowemu opracowanie systemu i sprawne przetestowanie go. Tak więc, teraz wiemy, że wymagania biznesowe są wysokie wymagania klientów języka naturalnego, podczas gdy wymagania dotyczące oprogramowania są szczegółowe wymagania niskiego poziomu, które pomagają we wdrażaniu 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 koszt ten może prowadzić do milionów dolarów, jeśli pochodzi z rynku jako oddzwanianie (w 2017 r.USA obciążyło producenta poduszek powietrznych, Takatę grzywną w wysokości 1 mld USD z powodu eksplodujących poduszek powietrznych).

organizacja skończyłaby na wykonywaniu zadań związanych z kontrolą uszkodzeń, takich jak analiza przyczyn źródłowych, przygotowanie dokumentów 5 why, 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 złożone przez Klienta, jeśli dana funkcja jest związana z bezpieczeństwem/bezpieczeństwem, takie jak dostęp do zabezpieczeń, poduszka powietrzna, ABS (układ przeciwblokujący) itp.