Analiza biznesowa - krótki przewodnik
Co to jest analiza biznesowa?
Analiza biznesowa to zestaw zadań, wiedzy i technik wymaganych do zidentyfikowania potrzeb biznesowych i określenia rozwiązań problemów biznesowych przedsiębiorstwa. Chociaż ogólna definicja jest podobna, praktyki i procedury mogą się różnić w różnych branżach.
W branży technologii informatycznych rozwiązania często zawierają komponent służący do tworzenia systemów, ale mogą również obejmować ulepszenie procesów lub zmianę organizacyjną.
Analiza biznesowa może również służyć zrozumieniu aktualnego stanu organizacji lub służyć jako podstawa do identyfikacji potrzeb biznesowych. Jednak w większości przypadków analiza biznesowa jest wykonywana w celu zdefiniowania i zweryfikowania rozwiązań, które spełniają potrzeby biznesowe, cele lub zadania.
Kim jest analityk biznesowy?
Analityk biznesowy to osoba, która analizuje organizację lub domenę biznesową (rzeczywistą lub hipotetyczną) i dokumentuje jej biznes, procesy lub systemy, oceniając model biznesowy lub jego integrację z technologią. Jednak tytuły organizacyjne są różne, np. Analityk, analityk biznesowy, analityk systemów biznesowych lub może analityk systemów.
Dlaczego analityk biznesowy?
Organizacje stosują analizę biznesową z następujących powodów -
Zrozumienie struktury i dynamiki organizacji, w której system ma zostać wdrożony.
Zrozumienie bieżących problemów w docelowej organizacji i zidentyfikowanie możliwości poprawy.
Aby upewnić się, że klient, użytkownik końcowy i programiści mają wspólne zrozumienie organizacji docelowej.
W początkowej fazie projektu, kiedy wymagania są interpretowane przez zespół rozwiązań i projektantów, rolą analityka biznesowego jest przegląd dokumentów rozwiązań, ścisła współpraca z projektantami rozwiązań (zespołem IT) i kierownikami projektów w celu zapewnienia, że wymagania są jasne.
W typowej dużej organizacji IT, zwłaszcza w środowisku programistycznym, można spotkać zespoły dostawcze na miejscu i za granicą pełniące wyżej wymienione role. Możesz znaleźć „analityka biznesowego”, który pełni rolę kluczowej osoby, która musi łączyć oba zespoły.
Czasami wchodził w interakcje z użytkownikami biznesowymi, a czasami z użytkownikami technicznymi, a na końcu ze wszystkimi interesariuszami projektów, aby uzyskać zgodę i ostateczne skinienie głową przed przystąpieniem do dokumentacji.
Dlatego rola licencjata jest bardzo istotna w skutecznym i udanym starcie dla każdego projektu.
Rola analityka biznesowego IT
Rola analityka biznesowego zaczyna się od zdefiniowania i określenia zakresu obszarów biznesowych organizacji, następnie wyodrębnienia wymagań, przeanalizowania i udokumentowania wymagań, zakomunikowania tych wymagań odpowiednim interesariuszom, zidentyfikowania właściwego rozwiązania, a następnie zweryfikowania rozwiązania w celu ustalenia, czy wymagania spełniają oczekiwane standardy.
Czym różni się od innych zawodów?
Analiza biznesowa różni się od analizy finansowej, zarządzania projektami, zapewniania jakości, rozwoju organizacyjnego, testowania, szkoleń i opracowywania dokumentacji. Jednak w zależności od organizacji analityk biznesowy może wykonywać niektóre lub wszystkie te powiązane funkcje.
Analitycy biznesowi, którzy pracują wyłącznie nad tworzeniem systemów oprogramowania, mogą być nazywani analitykami biznesowymi IT, technicznymi analitykami biznesowymi, analitykami biznesowymi online, analitykami systemów biznesowych lub analitykami systemów.
Analiza biznesowa obejmuje również współpracę między interesariuszami, zespołami programistycznymi, zespołami testującymi itp
Cykl życia rozwoju oprogramowania
Cykl życia oprogramowania (SDLC) to proces realizowany w projekcie oprogramowania w organizacji oprogramowania. Składa się ze szczegółowego planu opisującego, jak rozwijać, utrzymywać, zastępować, zmieniać lub ulepszać określone oprogramowanie. Definiuje metodologię poprawy jakości oprogramowania i całego procesu rozwoju.
SDLC to proces używany przez analityków IT w celu opracowania lub przeprojektowania wysokiej jakości systemu oprogramowania, spełniającego zarówno wymagania klienta, jak i rzeczywiste wymagania.
Uwzględnia wszystkie powiązane aspekty testowania oprogramowania, analizy i konserwacji poprocesowej.
Na poniższej ilustracji przedstawiono ważne fazy SDLC -
Etap planowania
Każda czynność musi zaczynać się od planu. Brak planu oznacza niepowodzenie. Stopień planowania różni się w zależności od modelu, ale bardzo ważne jest, aby dokładnie zrozumieć, co zamierzamy zbudować, tworząc specyfikacje systemu.
Definiowanie etapu
Na tym etapie analizujemy i definiujemy strukturę systemu. Definiujemy architekturę, komponenty i sposób, w jaki te komponenty pasują do siebie, aby stworzyć działający system.
Projektowanie etapu
W projekcie systemu szczegółowo opisano funkcje i operacje projektowe, w tym układy ekranu, reguły biznesowe, diagramy procesów i inną dokumentację. Dane wyjściowe tego etapu opisują nowy system jako zbiór modułów lub podsystemów.
Etap budowy
To jest faza rozwoju. Rozpoczynamy generowanie kodu w oparciu o projekt systemu przy użyciu kompilatorów, interpreterów, debuggerów, aby ożywić system.
Realizacja
Wdrożenie jest częścią Etapu Budowy. W tej fazie rozpoczynamy generowanie kodu w oparciu o projekt systemu przy użyciu kompilatorów, interpreterów, debuggerów, aby ożywić system.
Etap testowania
Ponieważ różne części systemu są ukończone; przechodzą serię testów. jest testowany pod kątem wymagań, aby upewnić się, że produkt faktycznie spełnia potrzeby określone w fazie wymagań.
Plany testów i przypadki testowe służą do identyfikacji błędów i upewnienia się, że system działa zgodnie ze specyfikacjami.
W tej fazie wykonywane są różne rodzaje testów, takie jak testy jednostkowe, testy ręczne, testy akceptacyjne i testy systemowe.
Śledzenie defektów w testowaniu
Raporty z testów oprogramowania służą do przekazywania wyników wykonanych planów testów. W takim przypadku raport powinien zawierać wszystkie informacje testowe, które odnoszą się do aktualnie testowanego systemu. Kompletność raportów będzie weryfikowana podczas sesji instruktażowych.
Testowanie projektu ma na celu osiągnięcie dwóch głównych celów -
Wykrywaj awarie i usterki w systemie.
Wykryj niespójność między wymaganiami a implementacją.
Poniższy schemat blokowy przedstawia Defect Tracking Process -
Aby osiągnąć główne cele, strategia testowania proponowanego systemu będzie zwykle składać się z czterech poziomów testowania.
Są to testy jednostkowe, testy integracyjne, testy akceptacyjne i testy regresyjne. W poniższych podrozdziałach opisano te poziomy testowania, które role zespołu programistów są odpowiedzialne za ich opracowanie i wykonanie oraz kryteria określania ich kompletności.
Rozlokowanie
Po zakończeniu fazy testowej system zostaje zwolniony i trafia do środowiska produkcyjnego. Gdy produkt jest przetestowany i gotowy do wdrożenia, zostaje oficjalnie wypuszczony na odpowiedni rynek. Czasami wdrażanie produktu odbywa się etapami, zgodnie ze strategią biznesową organizacji.
Produkt może najpierw zostać wydany w ograniczonym segmencie i przetestowany w rzeczywistym środowisku biznesowym (UAT - testy akceptacyjne użytkowników). Następnie, na podstawie opinii, produkt może zostać wydany w takim stanie, w jakim jest lub z sugerowanymi ulepszeniami w docelowym segmencie rynku.
Proces post SDLC
Po wprowadzeniu produktu na rynek, jego utrzymanie jest wykonywane dla istniejącej bazy klientów.
W środowisku produkcyjnym system zostanie poddany modyfikacjom z powodu niewykrytych błędów lub innych nieoczekiwanych zdarzeń. System jest oceniany, a cykl jest powtarzany w celu konserwacji systemu.
Rola analityka biznesowego w procesie SDLC
Jak widać na poniższym diagramie, BA jest zaangażowane w tworzenie wymagań biznesowych i przekształcanie ich w wymagania rozwiązania.
Zajmuje się przekładaniem cech rozwiązania na wymagania programowe. Następnie kieruje fazą analizy i projektowania, dyktuje tworzenie kodu, a następnie śledzi fazę testowania podczas naprawiania błędów jako agent zmian w zespole projektowym i ostatecznie spełnia wymagania klienta.
Analiza biznesowa - role
Rola analityka biznesowego w projekcie IT może być wielostronna. Członkowie zespołu projektowego mogą pełnić wiele ról i obowiązków. W niektórych projektach BA może pełnić rolę analityka Business Intelligence, projektanta baz danych, specjalisty ds. Zapewnienia jakości oprogramowania, testera i / lub trenera, gdy dostępne są ograniczone zasoby.
Możliwe jest również przejęcie roli analityka biznesowego w określonych projektach przez koordynatora projektu, kierownika ds. Rozwoju aplikacji lub dewelopera.
Analiza biznesowa w dużym stopniu nakłada się na analizę wymagań firmy, aby funkcjonować jak zwykle i optymalizować sposób ich funkcjonowania. Niektóre przykłady analizy biznesowej to:
- Tworzenie architektury biznesowej
- Przygotowanie uzasadnienia biznesowego
- Przeprowadzanie oceny ryzyka
- Pozyskiwanie wymagań
- Analiza procesów biznesowych
- Dokumentacja wymagań
Główne role licencjata
Kluczową rolą większości analityków biznesowych jest współpraca między biznesem a programistami technicznymi. Analitycy biznesowi współpracują z klientami biznesowymi w celu zebrania / zdefiniowania wymagań systemu lub procesu w celu poprawy produktywności, jednocześnie współpracując z zespołami technicznymi w celu zaprojektowania i wdrożenia systemu / procesu.
Jako współtwórca
Głównym obowiązkiem licencjata jest przyczynianie się do rozwoju użytkownika biznesowego / kluczowych użytkowników w identyfikowaniu problemów biznesowych, potrzeb i funkcji, rozumienie obaw i wymagań interesariuszy w celu określenia możliwości ulepszeń oraz wnoszenie wkładu biznesowego w opracowanie uzasadnienia biznesowego dla IT projekt rozwoju systemu.
Jako moderator
Analityk biznesowy ma również ułatwiać / koordynować pozyskiwanie i analizę wymagań, współpracę i komunikację z interesariuszami oraz zarządzać ich oczekiwaniami i potrzebami, a także zapewniać, że wymagania są kompletne, jednoznaczne i mapować je do potrzeb biznesowych w czasie rzeczywistym organizacji.
Jako analityk
Inną ważną rolą byłaby ocena proponowanego systemu i gotowości organizacyjnej do wdrożenia systemu oraz zapewnienie wsparcia użytkownikom i koordynacja z personelem IT.
Pomoc w przeglądzie i dostarczaniu danych wejściowych do projektu proponowanego systemu informatycznego z perspektywy biznesowej, rozwiązywanie problemów / konfliktów między interesariuszami, pomoc w organizowaniu kompleksowej i wysokiej jakości UAT poprzez pomoc użytkownikom w opracowywaniu przypadków testowych oraz pomoc w organizowaniu szkoleń w celu zapewnienia wdrożony system informatyczny, który jest w stanie sprostać potrzebom i wymaganiom biznesowym oraz zrealizować spodziewane korzyści.
Planowanie i monitorowanie działań analizy biznesowej pod kątem rozwoju zakresu, harmonogramu i podejścia do wykonywania czynności związanych z analizą biznesową dla projektu rozwoju systemu informatycznego, monitorowanie postępów, koordynacja z Kierownikiem Projektu Wewnętrznego oraz raportowanie przychodów, rentowności, ryzyk i problemów wszędzie tam, gdzie właściwy.
Kluczowe obowiązki analityka biznesowego
Odpowiedzialność analityka biznesowego wymagałaby od niego wykonywania różnych obowiązków na różnych etapach projektu, które zostały wyjaśnione poniżej -
Faza inicjacji
Ta faza oznaczać będzie początek nowego projektu, a analityk biznesowy rozróżni następujące obowiązki -
- Pomoc w przeprowadzeniu analizy kosztów i korzyści projektu.
- Zrozum uzasadnienie biznesowe.
- Sprawdź wykonalność rozwiązania / projektu / produktu.
- Pomoc w tworzeniu karty projektu.
- Zidentyfikuj interesariuszy w projekcie.
Faza planowania
Ta faza będzie obejmować zebranie wymagań i planowanie, jak projekt będzie realizowany i zarządzany. Jego obowiązki będą obejmowały następujące funkcje -
- Pozyskiwanie wymagań
- Analizuj, organizuj i dokumentuj wymagania.
- Zarządzaj wymaganiami, tworząc przypadki użycia, RTM, BRD, SRS itp.
- Oceń proponowane rozwiązania.
- Współpracuj i usprawniaj komunikację z interesariuszami.
- Pomoc w formułowaniu planów zarządzania projektami.
- Pomoc w znalezieniu zakresu projektu, ograniczeń, założeń i ryzyk.
- Pomoc w projektowaniu doświadczenia użytkownika rozwiązania.
Faza wykonywania
Faza ta oznacza opracowanie rozwiązania zgodnie z zebranymi wymaganiami. Obowiązki obejmują -
Wyjaśnij wymagania zespołowi IT / programistycznemu.
Wyjaśnij wątpliwości, obawy dotyczące proponowanego rozwiązania do opracowania.
Omów i ustal priorytety zmian zakresu projektu i uzyskaj zgodę.
Utwórz skrypty testów beta do wstępnych testów.
Dzielenie się rozwijanymi modułami z interesariuszami i proszenie o ich opinie.
Przestrzeganie terminów i zarządzanie oczekiwaniami interesariuszy.
Rozwiązywanie konfliktów i zarządzanie komunikacją z zespołem projektowym.
Faza monitorowania i kontroli
Na tym etapie projekt jest mierzony i kontrolowany pod kątem wszelkich odchyleń od pierwotnych planów. Ta faza przebiega jednocześnie z fazą wykonania.
Tworzenie skryptów testowych oraz przeprowadzanie kompleksowych testów modułowych i integracyjnych.
Przeprowadzanie UAT (wykorzystanie testów akceptacyjnych) i tworzenie raportów z testów.
Uzyskaj akceptację / akceptację produktów od klienta.
Wyjaśnij prośby o zmianę zespołowi programistycznemu.
Monitoruj rozwój wniosków o zmianę i weryfikuj ich realizację zgodnie z celem projektu.
Faza zamknięcia
Ta faza oznacza zamknięcie projektu. Obowiązki są -
Przedstawienie gotowego projektu klientowi i uzyskanie jego akceptacji.
Twórz podręczniki szkoleniowe dla użytkowników, wszelkie materiały funkcjonalne i inne przewodniki instruktażowe.
Przeprowadź rozbudowane testy integracyjne w środowisku produkcyjnym.
Twórz końcową dokumentację produktu, dokumentuj wyciągnięte wnioski z projektu.
Co BA ma dostarczyć?
Analityk biznesowy służy jako pomost między użytkownikami biznesowymi a specjalistami IT. Ich obecność znacząco przyczyni się do sukcesu projektów informatycznych. Posiadanie dedykowanego analityka biznesowego ma wiele zalet. Dedykowany analityk biznesowy może -
Zapewnia jasny zakres projektu z biznesowego punktu widzenia.
Opracuj solidne uzasadnienia biznesowe i bardziej realistyczne oszacowanie zasobów i korzyści biznesowych.
Przygotowuje lepsze raporty dotyczące zakresu projektów, planowania i zarządzania pod względem kosztów i harmonogramu, szczególnie w przypadku dużych projektów informatycznych.
Tworzy jasne i zwięzłe wymagania, co z kolei pomaga zapewnić jaśniejsze i dokładniejsze wymagania, jeśli projekt IT jest zlecany na zewnątrz.
Wyraź rzeczywiste potrzeby biznesowe użytkowników i efektywnie zarządzaj ich oczekiwaniami.
Poprawia jakość projektowania proponowanego systemu informatycznego tak, aby spełniał wymagania użytkownika.
Zapewnia jakość opracowanego systemu przed przekazaniem go użytkownikom końcowym do przeglądu i akceptacji.
Organizuje kompleksowe testy jakości dostarczonych systemów i przekazuje informacje zwrotne personelowi technicznemu IT.
Analiza biznesowa - narzędzia i techniki
Analityk biznesowy powinien być zaznajomiony z różnymi narzędziami analitycznymi i powiązanymi technologiami, gdy nosisz kapelusz BA. To znaczy, jeśli trzymasz tę pozycję.
Jak już się dowiedzieliśmy wcześniej, analiza biznesowa to proces, w którym próbujesz zrozumieć przedsiębiorstwo biznesowe i identyfikujesz możliwości, obszary problemowe, problemy i spotykasz szerokie grono osób pełniących różnorodne role i obowiązki, takie jak CEO, VP, Director i zrozumienie ich wymagań biznesowych.
Zasadniczo istnieją 3 rodzaje analizy biznesowej, które możemy podzielić na -
Strategic Analysis- Strategiczna analiza biznesowa dotyczy prac przedprojektowych. Jest to metoda lub proces identyfikacji problemów biznesowych, opracowywania strategii biznesowych, celów i zadań wspomagających najwyższe kierownictwo. Zapewnia raportowanie informacji zarządczych w celu efektywnego podejmowania decyzji.
Tactical Analysis - Obejmuje znajomość konkretnych technik analizy biznesowej, które można zastosować we właściwym czasie w odpowiednim projekcie.
Operational Analysis- W tego typu analizie biznesowej koncentrujemy się na aspekcie biznesowym poprzez wykorzystanie technologii informacyjnej. To także proces badania systemów operacyjnych w celu identyfikacji możliwości usprawnienia biznesu.
Dla każdego rodzaju analizy istnieje zestaw narzędzi, które są dostępne na rynku i które są dostosowane do potrzeb i wymagań organizacyjnych.
Jednak, aby zmaterializować wymagania biznesowe w zrozumiałe informacje, dobry licencjat będzie wykorzystywał techniki znajdowania faktów, wywiady, przeglądu dokumentacji, kwestionariuszy, pobierania próbek i badań w swoich codziennych działaniach.
Wymagania funkcjonalne i niefunkcjonalne
Możemy podzielić wymaganie na dwa główne typy, takie jak wymagania funkcjonalne i niefunkcjonalne.
W przypadku wszystkich projektów technologicznych wymagania funkcjonalne i niefunkcjonalne muszą być rozdzielone i oddzielnie przeanalizowane.
Zdefiniowanie odpowiedniego narzędzia i odpowiedniej techniki może być trudnym wyzwaniem. Niezależnie od tego, czy tworzysz zupełnie nową aplikację, czy wprowadzasz zmiany w istniejącej aplikacji. Rozważanie właściwej techniki procesu funkcjonalnego jest sztuką samą w sobie.
Przegląd szeroko stosowanych technik analizy biznesowej, które są obecnie dostępne na rynku -
Procesy | Techniki | Dostarczane elementy procesu (wyniki) |
---|---|---|
Aby określić wymagania funkcjonalne i niefunkcjonalne |
|
Business Requirements Documents -
Common Template -
|
Możliwość zastosowania narzędzi i procesu
Chociaż istnieje wiele narzędzi i procedur dostępnych dla analityków biznesowych, wszystko zależy od aktualnych praktyk organizacji i tego, jak chcieliby z nich korzystać.
Na przykład, root-cause analysis jest używany, gdy istnieje potrzeba, aby zagłębić się w pewien ważny obszar lub funkcję.
Jednak dokument wymagań biznesowych jest najbardziej popularnym i akceptowanym sposobem umieszczania wymagań w formacie dokumentacji.
W kolejnych rozdziałach omówimy szczegółowo niektóre z powyższych technik.
Analiza biznesowa - sesja JAD
Joint Application Development (JAD) to proces służący do zbierania wymagań biznesowych podczas opracowywania nowych systemów informatycznych dla firmy. Proces JAD może również obejmować podejścia mające na celu zwiększenie udziału użytkowników, przyspieszenie rozwoju i poprawę jakości specyfikacji. Celem sesji JAD jest zebranie merytorycznych ekspertów / analityków biznesowych lub informatyków w celu wypracowania rozwiązań.
Analityk biznesowy to ten, który wchodzi w interakcję z całą grupą i zbiera informacje, analizuje je i wydaje dokument. Odgrywa bardzo ważną rolę w sesji JAD.
Korzystanie z sesji JAD
Sesje JAD to wysoce ustrukturyzowane, ułatwione warsztaty, które gromadzą decydentów klientów i personel IT w celu uzyskania wysokiej jakości wyników w krótkim czasie.
Innymi słowy, sesja JAD umożliwia klientom i programistom szybkie osiągnięcie porozumienia co do podstawowego zakresu, celów i specyfikacji projektu lub w przypadku braku porozumienia, co oznacza, że projekt wymaga ponownej oceny.
Mówiąc najprościej, sesje JAD mogą
Simplify - Łączy miesiące spotkań i rozmów telefonicznych w zorganizowany warsztat.
Identify - Zagadnienia i uczestnicy
Quantify - Potrzeby w zakresie informacji i przetwarzania
Clarify - Krystalizacja i wyjaśnienie wszystkich wymagań uzgodnionych podczas sesji.
Unify - Dane wyjściowe z jednej fazy rozwoju są wkładem do następnej.
Satisfy- Klienci definiują system; dlatego jest to ich system. Wspólne uczestnictwo ma wpływ na wynik; angażują się w sukces systemów.
Uczestnicy sesji JAD
Uczestnicy biorący udział w sesji JAD to:
Sponsor wykonawczy
Sponsor wykonawczy to osoba kierująca projektem - właściciel systemu. Zwykle są na wyższych stanowiskach i są w stanie podejmować decyzje oraz zapewniać niezbędną strategię, planowanie i kierunek.
Ekspert merytoryczny
Są to użytkownicy biznesowi i zewnętrzni eksperci, którzy są niezbędni do udanego warsztatu. Eksperci merytoryczni są kręgosłupem sesji JAD. Będą napędzać zmiany.
Facylitator
On przewodniczy spotkaniu; identyfikuje problemy, które można rozwiązać w ramach spotkania. Facylitator nie przekazuje informacji na spotkanie.
Kluczowi użytkownicy
Kluczowi użytkownicy lub nazywani również superużytkownikami w niektórych przypadkach byli używani zamiennie i nadal różnią się w zależności od firmy. Kluczowi użytkownicy to na ogół użytkownicy biznesowi, którzy są ściślej dostosowani do projektu IT i są odpowiedzialni za konfigurację profili członków swojego zespołu podczas projektów.
Na przykład: załóżmy, że John jest kluczowym użytkownikiem, a Nancy, Evan są użytkownikami systemu SAP. W tym przypadku Nancy i Evan nie mają dostępu do zmiany funkcjonalności i profilu, podczas gdy Jan jako użytkownik klucza ma dostęp do edycji profilu z większą liczbą uprawnień.
Uważa się, że podejście JAD, w porównaniu z bardziej tradycyjną praktyką, prowadzi do szybszego rozwoju i większej satysfakcji klienta, ponieważ klient jest zaangażowany w cały proces rozwoju. Dla porównania, w tradycyjnym podejściu do tworzenia systemów, deweloper bada wymagania systemowe i opracowuje aplikację, przy czym klient składa serię wywiadów.
Techniki gromadzenia wymagań
Techniki opisują sposób wykonywania zadań w określonych okolicznościach. Zadanie może nie mieć żadnej lub jednej lub więcej powiązanych technik. Technika powinna dotyczyć przynajmniej jednego zadania.
Poniżej przedstawiono niektóre z dobrze znanych technik gromadzenia wymagań -
Burza mózgów
Burza mózgów jest używana podczas gromadzenia wymagań, aby uzyskać jak najwięcej pomysłów od grupy ludzi. Zwykle używany do identyfikowania możliwych rozwiązań problemów i wyjaśniania szczegółów możliwości.
Analiza dokumentów
Przegląd dokumentacji istniejącego systemu może pomóc podczas tworzenia dokumentu procesu AS – IS, a także prowadzić analizę luk w celu określenia zakresu projektów migracyjnych. W idealnym świecie dokonalibyśmy nawet przeglądu wymagań, które napędzały tworzenie istniejącego systemu - punkt wyjścia do dokumentowania bieżących wymagań. Fragmenty informacji są często zakopane w istniejących dokumentach, które pomagają nam zadawać pytania w ramach weryfikacji kompletności wymagań.
Grupa fokusowa
Grupa fokusowa to zbiór osób reprezentujących użytkowników lub klientów produktu w celu uzyskania opinii. Informacje zwrotne można zebrać na temat potrzeb / możliwości / problemów w celu zidentyfikowania wymagań lub można je zebrać w celu walidacji i udoskonalenia już uzyskanych wymagań. Ta forma badania rynku różni się od burzy mózgów tym, że jest procesem zarządzanym z określonymi uczestnikami.
Analiza interfejsu
Interfejsami oprogramowania mogą być ludzie lub maszyny. Integracja z zewnętrznymi systemami i urządzeniami to tylko kolejny interfejs. Podejścia projektowe zorientowane na użytkownika są bardzo skuteczne w upewnianiu się, że tworzymy użyteczne oprogramowanie. Analiza interfejsu - przeglądanie punktów styku z innymi systemami zewnętrznymi jest ważne, aby nie przeoczyć wymagań, które nie są od razu widoczne dla użytkowników.
Wywiad
Wywiady z interesariuszami i użytkownikami mają kluczowe znaczenie dla tworzenia doskonałego oprogramowania. Bez zrozumienia celów i oczekiwań użytkowników i interesariuszy jest mało prawdopodobne, abyśmy ich spełnili. Musimy również rozpoznać perspektywę każdego rozmówcy, abyśmy mogli odpowiednio zważyć i odnieść się do jego wkładu. Słuchanie to umiejętność, która pomaga świetnemu analitykowi uzyskać większą wartość z wywiadu niż przeciętnemu analitykowi.
Obserwacja
Obserwując użytkowników, analityk może zidentyfikować przebieg procesu, kroki, problemy i możliwości poprawy. Obserwacje mogą być bierne lub aktywne (zadawanie pytań podczas obserwacji). Obserwacja pasywna jest lepsza do uzyskania informacji zwrotnej na temat prototypu (w celu udoskonalenia wymagań), gdzie aktywna obserwacja jest bardziej skuteczna w zrozumieniu istniejącego procesu biznesowego. Można zastosować dowolne podejście.
Prototypowanie
Prototypowanie to stosunkowo nowoczesna technika zbierania wymagań. W tym podejściu zbierasz wstępne wymagania, które wykorzystasz do zbudowania wstępnej wersji rozwiązania - prototypu. Pokazujesz to klientowi, który następnie podaje dodatkowe wymagania. Zmieniasz aplikację i ponownie przełączasz się z klientem. Ten powtarzalny proces trwa, dopóki produkt nie osiągnie masy krytycznej potrzeb biznesowych lub dla uzgodnionej liczby iteracji.
Warsztaty wymagań
Warsztaty mogą być bardzo skuteczne w zbieraniu wymagań. Bardziej zorganizowane niż sesja burzy mózgów, zaangażowane strony współpracują w celu udokumentowania wymagań. Jednym ze sposobów uchwycenia współpracy jest utworzenie artefaktów modelu domeny (takich jak diagramy statyczne, diagramy aktywności). Warsztaty będą skuteczniejsze z dwoma analitykami niż z jednym.
Inżynieria odwrotna
Gdy projekt migracji nie ma dostępu do wystarczającej dokumentacji istniejącego systemu, inżynieria odwrotna zidentyfikuje, co robi system. Nie określi, co system powinien zrobić, i nie zidentyfikuje, kiedy system zrobi źle.
Ankieta / kwestionariusz
Podczas zbierania informacji od wielu osób - zbyt wielu, by przeprowadzić wywiad z ograniczeniami budżetowymi i czasowymi - można skorzystać z ankiety lub kwestionariusza. Ankieta może zmusić użytkowników do dokonania wyboru, oceny czegoś („Zdecydowanie zgadzam się, zgadzam się…”) lub zadawania pytań otwartych, umożliwiających swobodne udzielanie odpowiedzi. Projekt ankiety jest trudny - pytania mogą zniechęcać respondentów.
Dokument wymagań funkcjonalnych
Dokument wymagań funkcjonalnych (FRD) to formalne zestawienie wymagań funkcjonalnych aplikacji. Służy temu samemu celowi co umowa. Tutaj programiści zgadzają się zapewnić określone możliwości. Klient zgadza się uznać produkt za zadowalający, jeśli zapewnia możliwości określone w FRD.
Wymagania funkcjonalne odzwierciedlają zamierzone zachowanie systemu. Takie zachowanie może być wyrażone jako usługi, zadania lub funkcje, które system musi wykonywać. Dokument powinien być dostosowany do potrzeb konkretnego projektu. Definiują takie rzeczy, jak obliczenia systemowe, manipulowanie i przetwarzanie danych, interfejs użytkownika i interakcja z aplikacją.
Dokument wymagań funkcjonalnych (FRD) ma następujące cechy -
Pokazuje, że aplikacja zapewnia wartość pod względem celów biznesowych i procesów biznesowych w ciągu najbliższych kilku lat.
Zawiera pełen zestaw wymagań dla aplikacji. Nie pozostawia nikomu miejsca na przyjęcie czegokolwiek, co nie zostało określone w FRD.
Jest niezależny od rozwiązania. ERD jest oświadczeniem o tym, co ma zrobić aplikacja, a nie jak to działa. FRD nie zobowiązuje programistów do projektowania. Z tego powodu jakiekolwiek odniesienie do użycia określonej technologii jest całkowicie nieodpowiednie w FRD.
Wymóg funkcjonalny powinien obejmować:
Opisy data do wprowadzenia do systemu
Opisy operations wykonywane na każdym ekranie
Opisy work-flows wykonywane przez system
Opisy system reports lub inne wyjścia
Kto może wejść do data do systemu?
Sposób, w jaki system spełnia, ma zastosowanie regulatory requirements?
Specyfikacja funkcjonalna jest przeznaczona do czytania przez wszystkich odbiorców. Czytelnicy powinni rozumieć system, ale do zrozumienia tego dokumentu nie jest wymagana wiedza techniczna.
Elementy dostarczane w zakresie wymagań funkcjonalnych
Dokument wymagań biznesowych (BRD) składa się z -
Functional Requirements- Dokument zawierający szczegółowe wymagania dotyczące opracowywanego systemu. Wymagania te definiują cechy funkcjonalne i możliwości, które musi posiadać system. Upewnij się, że wszelkie założenia i ograniczenia zidentyfikowane podczas uzasadnienia biznesowego są nadal dokładne i aktualne.
Business Process Model - Model aktualnego stanu procesu (model „jak jest”) lub koncepcja tego, czym proces powinien się stać (model „być”)
System Context Diagram - Diagram kontekstowy przedstawia granice systemu, elementy zewnętrzne i wewnętrzne, które oddziałują z systemem, oraz odpowiednie przepływy danych między tymi podmiotami zewnętrznymi i wewnętrznymi.
Flow Diagrams (as-is or to-be)- Diagramy graficznie przedstawiają sekwencję operacji lub przepływ danych dla procesu biznesowego. W zależności od złożoności modelu dołączony jest jeden lub więcej diagramów przepływu.
Business Rules and Data Requirements - Reguły biznesowe definiują lub ograniczają niektóre aspekty działalności i służą do definiowania ograniczeń danych, wartości domyślnych, zakresów wartości, liczności, typów danych, obliczeń, wyjątków, wymaganych elementów oraz integralności relacyjnej danych.
Data Models - Diagramy powiązań encji, opisy encji, diagramy klas
Conceptual Model - Przedstawianie na wysokim poziomie różnych podmiotów dla funkcji biznesowej i ich wzajemnych relacji.
Logical Model - Ilustruje konkretne jednostki, atrybuty i relacje związane z funkcją biznesową i przedstawia wszystkie definicje, cechy i relacje danych w środowisku biznesowym, technicznym lub koncepcyjnym.
Data Dictionary and Glossary - Zbiór szczegółowych informacji o elementach danych, polach, tabelach i innych jednostkach, które składają się na model danych stanowiący podstawę bazy danych lub podobnego systemu zarządzania danymi.
Stakeholder Map- Identyfikuje wszystkich interesariuszy, na których ma wpływ proponowana zmiana, oraz ich wpływ / uprawnienia w zakresie wymagań. Dokument ten został opracowany w początkowej fazie Metodologii Zarządzania Projektem (PMM) i jest własnością Kierownika Projektu, ale zespół projektowy musi go zaktualizować, ponieważ w trakcie procesu identyfikowani są nowi / zmienieni interesariusze.
Requirements Traceability Matrix - Tabela ilustrująca logiczne powiązania między indywidualnymi wymaganiami funkcjonalnymi i innymi typami artefaktów systemowych, w tym inne wymagania funkcjonalne, przypadki użycia / historie użytkowników, elementy architektury i projektu, moduły kodu, przypadki testowe i reguły biznesowe.
specyfikacje dotyczące wymagań oprogramowania
Specyfikacja wymagań oprogramowania (SRS) to dokument, który jest używany jako środek komunikacji między klientami. Specyfikacja wymagań oprogramowania w swojej najbardziej podstawowej formie jest formalnym dokumentem używanym do komunikowania wymagań oprogramowania między klientem a deweloperem.
Dokument SRS koncentruje się na WHAT należy zrobić i ostrożnie unika rozwiązania (how to do). Służy jako umowa między zespołem programistycznym a klientem. Wymagania na tym etapie są napisane przy użyciu terminologii użytkownika końcowego. W razie potrzeby później zostanie z niego opracowana formalna specyfikacja wymagań.
SRS to pełny opis zachowania systemu, który ma zostać opracowany, i może obejmować zestaw przypadków użycia opisujących interakcje użytkowników z oprogramowaniem.
Cel SRS
SRS to narzędzie do komunikacji między klientem / klientem, analitykiem biznesowym, programistami systemów, zespołami utrzymania ruchu. Może to być również umowa pomiędzy kupującym a dostawcą.
- To da solidne podstawy dla fazy projektowania
- Wspiera zarządzanie i kontrolę projektów
- Pomaga w kontrolowaniu i ewolucji systemu
Specyfikacja wymagań oprogramowania powinna być kompletna, spójna, identyfikowalna, jednoznaczna i weryfikowalna.
W specyfikacji systemu należy uwzględnić następujące kwestie -
- Zdefiniuj funkcje systemów
- Zdefiniuj partycjonowanie funkcjonalne sprzętu / oprogramowania
- Zdefiniuj specyfikację wydajności
- Zdefiniuj partycjonowanie wydajności sprzętu / oprogramowania
- Zdefiniuj wymagania bezpieczeństwa
- Zdefiniuj interfejs użytkownika (podręcznik użytkownika)
- Zapewnij rysunki / instrukcje instalacji
- Szablon specyfikacji wymagań oprogramowania
Historia zmian
Data | Opis | Autor | Komentarze |
---|---|---|---|
<data> | <Wersja 1> | <Twoje imię> | <Pierwsza wersja> |
Zatwierdzenie dokumentu
Następująca specyfikacja wymagań oprogramowania została zaakceptowana i zatwierdzona przez:
Podpis | Wydrukowana nazwa | Tytuł | Data |
---|---|---|---|
<Twoje imię> | Lead Software Eng. | ||
David | Instruktor | ||
Analiza biznesowa - przypadki użycia
Jednym z dziewięciu diagramów UML jest diagram przypadków użycia. Są to nie tylko ważne, ale niezbędne wymagania dotyczące projektów oprogramowania. Zasadniczo jest używany w cyklach życia oprogramowania. Jak wiemy, istnieją różne fazy w cyklu rozwoju, a najczęściej używaną fazą dla przypadków użycia byłaby faza zbierania wymagań.
Co to jest przypadek użycia?
Przypadek użycia opisuje sekwencję działań wykonywanych przez system, który zapewnia wartość aktorowi. Przypadek użycia opisuje zachowanie systemu w różnych warunkach, gdy odpowiada on na żądanie jednego z interesariuszy, zwanegoprimary actor.
Aktor jest tym, który systemu, innymi słowy, jest użytkownikiem końcowym.
W inżynierii oprogramowania i systemów przypadek użycia to lista kroków, zazwyczaj definiujących interakcje między rolą (znaną w UML jako „aktor”) a systemem, prowadzących do osiągnięcia celu. Aktor może być człowiekiem lub systemem zewnętrznym.
Przypadek użycia określa przepływ zdarzeń w systemie. Bardziej dotyczy tego, co jest wykonywane przez system w celu wykonania sekwencji działań.
Korzyści z przypadku użycia
Przypadek użycia zapewnia następujące korzyści -
Jest to łatwy sposób na uchwycenie wymagań funkcjonalnych z naciskiem na wartość dodaną dla użytkownika.
Przypadki użycia są stosunkowo łatwe do napisania i odczytania w porównaniu z tradycyjnymi metodami wymagań.
Przypadki użycia zmuszają programistów do myślenia z perspektywy użytkownika końcowego.
Przypadek użycia angażuje użytkownika w proces wymagań.
Anatomia przypadku użycia
Nazwa : nazwa opisowa, która ilustruje cel przypadku użycia.
Opis : opisuje, co robi przypadek użycia w kilku zdaniach.
Aktor : Wymień wszystkich aktorów, którzy uczestniczą w przypadku użycia.
Warunek wstępny : warunki, które należy spełnić przed rozpoczęciem przypadku użycia.
Przebieg wydarzeń : opis interakcji między systemem a aktorem.
Stan postu : Opisz stan systemu po wykonaniu przypadku użycia.
Wytyczne dotyczące szablonu przypadku użycia
Udokumentuj każdy przypadek użycia, używając szablonu podanego na końcu tego rozdziału. Ta sekcja zawiera opis każdej sekcji w szablonie przypadków użycia.
Identyfikacja przypadków użycia
Use-Case ID- Nadaj każdemu przypadkowi użycia unikalny identyfikator liczbowy w formie hierarchicznej: XY Powiązane przypadki użycia można pogrupować w hierarchii. Wymagania funkcjonalne można prześledzić wstecz do oznaczonego przypadku użycia.
Use-Case Name- Podaj zwięzłą, zorientowaną na wyniki nazwę przypadku użycia. Odzwierciedlają one zadania, które użytkownik musi wykonać przy użyciu systemu. Uwzględnij czasownik oznaczający działanie i rzeczownik. Kilka przykładów -
Wyświetl informacje o numerze części.
Ręcznie zaznacz źródło hipertekstu i utwórz łącze do celu.
Złóż zamówienie na płytę CD ze zaktualizowaną wersją oprogramowania.
Historia przypadków użycia
Tutaj wspominamy o nazwiskach osób, które są interesariuszami dokumentu Usecase.
Created By - Podaj imię i nazwisko osoby, która początkowo udokumentowała ten przypadek użycia.
Date Created - Wprowadź datę, w której przypadek użycia został pierwotnie udokumentowany.
Last Updated By - Podaj imię i nazwisko osoby, która wykonała ostatnią aktualizację opisu przypadku użycia.
Date Last Updated - Wprowadź datę ostatniej aktualizacji przypadku użycia.
Definicja przypadku użycia
Poniżej znajdują się definicje kluczowych koncepcji przypadku użycia -
Aktor
Aktor to osoba lub inny podmiot zewnętrzny w stosunku do określonego systemu oprogramowania, który współdziała z systemem i wykonuje przypadki użycia w celu wykonania zadań. Różni aktorzy często odpowiadają różnym klasom użytkowników lub rolom określonym w społeczności klientów, która będzie używać produktu. Podaj nazwę aktora (ów), który będzie wykonywał ten przypadek.
Opis
Podaj krótki opis przyczyny i wyniku tego przypadku użycia lub ogólny opis sekwencji działań i wyniku wykonania przypadku użycia.
Warunki wstępne
Wymień wszelkie działania, które muszą mieć miejsce, lub wszelkie warunki, które muszą być spełnione, zanim przypadek użycia będzie można rozpocząć. Ponumeruj każdy warunek wstępny.
Examples
- Tożsamość użytkownika została uwierzytelniona.
- Komputer użytkownika ma wystarczającą ilość wolnej pamięci do uruchomienia zadania.
Warunki wysyłania
Opisz stan systemu na zakończenie wykonania przypadku użycia. Ponumeruj każdy warunek postu.
Examples
- Dokument zawiera tylko prawidłowe tagi SGML.
- Cena towaru w bazie danych została zaktualizowana o nową wartość.
Priorytet
Wskaż względny priorytet implementacji funkcjonalności wymaganej do wykonania tego przypadku. Zastosowany schemat priorytetów musi być taki sam, jak zastosowany w specyfikacji wymagań oprogramowania.
Częstotliwość użycia
Oszacuj, ile razy ten przypadek użycia zostanie wykonany przez aktorów w odpowiedniej jednostce czasu.
Normalny przebieg wydarzeń
Podaj szczegółowy opis działań użytkownika i odpowiedzi systemu, które będą miały miejsce podczas wykonywania przypadku użycia w normalnych, spodziewanych warunkach. Ta sekwencja dialogowa ostatecznie doprowadzi do osiągnięcia celu określonego w nazwie i opisie przypadku użycia. Opis ten można zapisać jako odpowiedź na hipotetyczne pytanie: „Jak mogę <wykonać zadanie określone w nazwie przypadku użycia>?” Najlepiej zrobić to jako ponumerowaną listę czynności wykonywanych przez aktora na przemian z odpowiedziami dostarczanymi przez system.
Kursy alternatywne
Dokumentuj inne, legalne scenariusze użycia, które mogą mieć miejsce w tym przypadku użycia oddzielnie w tej sekcji. Podaj alternatywny kurs i opisz wszelkie różnice w kolejności wykonywanych czynności. Ponumeruj każdy kurs alternatywny, używając ID przypadku użycia jako przedrostka, a następnie „AC”, aby wskazać „Kurs alternatywny”. Przykład: XYAC.1.
Wyjątki
Opisz wszelkie przewidywane błędy, które mogą wystąpić podczas wykonywania przypadku użycia, i zdefiniuj, jak system ma reagować na te warunki. Opisz także, jak system ma zareagować, jeśli wykonanie przypadku użycia nie powiedzie się z nieoczekiwanego powodu. Ponumeruj każdy wyjątek, używając identyfikatora przypadku użycia jako przedrostka, a następnie „EX”, aby wskazać „Wyjątek”. Przykład: XYEX.1.
Zawiera
Wymień wszystkie inne przypadki użycia, które są uwzględnione („nazywane”) przez ten przypadek użycia. Wspólne funkcje, które pojawiają się w wielu przypadkach użycia, można podzielić na osobne przypadki użycia, które są zawarte w tych, które wymagają tej wspólnej funkcjonalności.
Specjalne wymagania
Zidentyfikuj wszelkie dodatkowe wymagania, takie jak wymagania niefunkcjonalne, dla danego przypadku, które mogą wymagać uwzględnienia podczas projektowania lub wdrażania. Mogą to być wymagania dotyczące wydajności lub inne cechy jakościowe.
Założenia
Wymień wszelkie założenia przyjęte w analizie, które doprowadziły do zaakceptowania tego przypadku użycia w opisie produktu i napisania opisu przypadku użycia.
Uwagi i problemy
Wymień wszelkie dodatkowe komentarze dotyczące tego przypadku użycia lub wszelkich pozostałych nierozwiązanych problemów lub TBD (do ustalenia), które należy rozwiązać. Określ, kto rozwiąże każdy problem, termin i ostateczne rozwiązanie.
Zarządzanie zmianami i kontrola wersji
Kontrola wersji to zarządzanie zmianami w dokumentach, dużych witrynach internetowych i innych zbiorach informacji. Zmiany są zwykle identyfikowane za pomocą kodu liczbowego lub literowego, określanego jako numer wersji lub poziom zmiany. Każda wersja jest powiązana z sygnaturą czasową i osobą dokonującą zmiany.
Diagramy przypadków użycia
Ważną częścią Unified Modeling Language (UML) są narzędzia do rysowania diagramów przypadków użycia. Przypadki użycia są wykorzystywane na etapie analizy projektu w celu określenia i podziału funkcjonalności systemu. Dzielą system na aktorów i przypadki użycia. Aktorzy reprezentują role, które mogą odgrywać użytkownicy systemu.
Tymi użytkownikami mogą być ludzie, inne komputery, elementy sprzętu, a nawet inne systemy oprogramowania. Jedynym kryterium jest to, że muszą one być zewnętrzne w stosunku do części systemu, która jest podzielona na przypadki użycia. Muszą dostarczać bodźców do tej części systemu i muszą otrzymywać z niej wyniki.
Przypadki użycia reprezentują czynności, które aktorzy wykonują z pomocą twojego systemu w dążeniu do celu. Musimy zdefiniować, czego ci użytkownicy (aktorzy) potrzebują od systemu. Przypadki użycia powinny odzwierciedlać potrzeby i cele użytkownika i powinny być inicjowane przez aktora. Biznes, aktorzy, Klienci uczestniczący w biznesowym przypadku użycia powinni być połączeni z przypadkiem użycia przez skojarzenie.
Rysowanie diagramów przypadków użycia
Poniższy rysunek pokazuje, jak przypadek użycia może wyglądać jak schemat UML. Sama walizka wygląda jak owal. Aktorzy są rysowani jako małe postacie z patyków. Aktorzy są połączeni z przypadkiem użycia liniami.
Use-case 1 - Sprzedawca sprawdza przedmiot
- Klient kładzie przedmiot na ladzie.
- «Używa» Swipe UPC Reader.
- System wyszukuje kod UPC w bazie danych, określając opis pozycji i cenę
- System emituje słyszalny sygnał dźwiękowy.
- System ogłasza opis pozycji i cenę za pośrednictwem komunikatów głosowych.
- System dodaje cenę i rodzaj towaru do aktualnej faktury.
- System dodaje cenę do poprawnej sumy częściowej podatku
Zatem relacja „używa” jest bardzo podobna do wywołania funkcji lub procedury.
Przypadek użycia używany w ten sposób nazywany jest abstrakcyjnym przypadkiem użycia, ponieważ nie może istnieć samodzielnie, ale musi być używany w innych przypadkach użycia.
Przykład ─ Przypadek użycia wycofania
Celem klienta w stosunku do naszego automatu do sprzedaży pieniędzy (bankomatu) jest wypłacenie pieniędzy. Więc dodajemyWithdrawalprzypadek użycia. Wypłata pieniędzy z automatu może wiązać się z koniecznością przeprowadzenia transakcji przez bank. Więc dodajemy też innego aktora -Bank. Obaj aktorzy uczestniczący w przypadku użycia powinni być połączeni z przypadkiem użycia przez skojarzenie.
Automat z pieniędzmi zapewnia przypadki użycia wypłaty dla klienta i aktorów banku.
Relacje między aktorami a przypadkami użycia
Przypadki użycia można uporządkować za pomocą następujących relacji -
- Generalization
- Association
- Extend
- Include
Uogólnienie między przypadkami użycia
Mogą wystąpić sytuacje, w których aktorzy są powiązani z podobnymi przypadkami użycia. W takim przypadku przypadek użycia dziecka dziedziczy właściwości i zachowanie zastosowania nadrzędnego. Stąd musimy uogólnić aktora, aby pokazać dziedziczenie funkcji. Są reprezentowane przez ciągłą linię z dużym pustym trójkątnym grotem.
Związek między przypadkami użycia
Skojarzenia między aktorami i przypadkami użycia są zaznaczone na diagramach przypadków użycia liniami ciągłymi. Skojarzenie istnieje zawsze, gdy aktor jest zaangażowany w interakcję opisaną przez przypadek użycia.
Poszerzać
Istnieje kilka funkcji, które są uruchamiane opcjonalnie. W takich przypadkach używana jest relacja rozszerzenia i dołączana jest do niej reguła rozszerzenia. Należy pamiętać, że podstawowy przypadek użycia powinien być w stanie samodzielnie wykonać funkcję, nawet jeśli rozszerzający przypadek użycia nie jest wywoływany.
Relacja wydłużania jest pokazana jako przerywana linia z otwartym grotem strzałki skierowanym z rozszerzającego się przypadku użycia do rozszerzonego (podstawowego) przypadku użycia. Strzałka jest oznaczona słowem kluczowym „rozszerz”.
Zawierać
Służy do wyodrębniania fragmentów przypadków użycia, które są powielane w wielu przypadkach użycia. Służy również do uproszczenia dużego przypadku użycia poprzez podzielenie go na kilka przypadków użycia i wyodrębnienie wspólnych części zachowań dwóch lub więcej przypadków użycia.
Uwzględnij relację między przypadkami użycia, która jest pokazana za pomocą przerywanej strzałki z otwartym grotem od podstawowego przypadku użycia do dołączonego przypadku użycia. Strzałka jest oznaczona słowem kluczowym „dołącz”.
Przypadki użycia dotyczą tylko wymagań funkcjonalnych systemu. Inne wymagania, takie jak reguły biznesowe, wymagania dotyczące jakości usług i ograniczenia implementacyjne, należy przedstawić oddzielnie.
Poniższy diagram jest przykładem prostego diagramu przypadków użycia z zaznaczonymi wszystkimi elementami.
Podstawowe zasady udanego zastosowania przypadków użycia
- Uprość, opowiadając historie
- Pracuj bez perfekcji
- Zrozum szerszy obraz
- Zidentyfikuj możliwość ponownego wykorzystania przypadków użycia
- Skoncentruj się na wartości
- Zbuduj system w plasterkach
- Dostarczaj system stopniowo
- Dostosuj się do potrzeb zespołu
Szablon przypadku użycia
Tutaj pokazaliśmy przykładowy szablon przypadku użycia, który analityk biznesowy może wypełnić, aby informacje były przydatne dla zespołu technicznego w celu ustalenia informacji o projekcie.
Identyfikator przypadku użycia: | |||
Nazwa przypadku użycia: | |||
Stworzone przez: | Ostatnia aktualizacja przez | ||
Data utworzenia: | Data ostatniej aktualizacji | ||
Aktor: | |||
Opis: | |||
Warunki wstępne: | |||
Warunki publikacji: | |||
Priorytet: | |||
Częstotliwość użycia: | |||
Normalny przebieg wydarzeń: | |||
Kursy alternatywne: | |||
Wyjątki: | |||
Obejmuje: | |||
Specjalne wymagania: | |||
Założenia: | |||
Uwagi i problemy: |
Analiza biznesowa - wymagania Mngmt
Gromadzenie wymagań dotyczących oprogramowania jest podstawą całego projektu tworzenia oprogramowania. Pozyskiwanie i zbieranie wymagań biznesowych to krytyczny pierwszy krok dla każdego projektu. Aby wypełnić lukę między wymaganiami biznesowymi i technicznymi, analitycy biznesowi muszą w pełni zrozumieć potrzeby biznesowe w danym kontekście, dostosować je do celów biznesowych i odpowiednio komunikować te potrzeby zarówno interesariuszom, jak i zespołowi programistycznemu.
The key stakeholders wish that someone could explain customer / client requirements in plain English. Will this benefit them from understanding the value at a high-level? This will be the main-focus area, as they will try to map the documentation with the requirements and how BA could communicate in the best possible way.
Why Projects Fail
There are many reasons why projects fail but some of the common areas include the below −
- Market and Strategy Failure
- Organizational and Planning Failures
- Quality Failures
- Leadership and Governance failures
- Skills, Knowledge and competency failures
- Engagement, team work and communication failures
At the core of the issue is that projects are increasingly complex, changes occur and communication is challenging.
Why Successful Teams do Requirements Management
Requirements management is about keeping your team in-sync and providing visibility to what is going on within a project.
It is critical to the success of your projects for your whole team to understand what you are building and why – that’s how we define requirements management. The “why” is important because it provides context to the goals, feedback and decisions being made about the requirements.
This increases predictability of future success and potential problems, allowing your team to quickly course correct any issues and successfully complete your project on time and within budget. As a starting point, it’s valuable for everyone involved to have a basic understanding of what requirements are, and how to manage them.
Let’s Start with the Basics
A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system. Component to satisfy a contract, standard, specification, or other formally imposed documents.
A requirement can be expressed with text, sketches, detailed mockups or models, whatever information best communicates to an engineer what to build, and to a QA manager what to test. Depending on your development process, you might use different terminology to capture requirements.
High-level requirements are sometimes referred to simply as needs or goals. Within software development practices, requirements might be referred to as “use-cases”, “features” or “functional requirements”. Even more specifically within agile development methodologies, requirements are often captured as epics and stories.
Regardless of what your team calls them or what process you use; requirements are essential to the development of all products. Without clearly defining requirements you could produce an incomplete or defective product. Throughout the process there can be many people involved in defining requirements.
A stakeholder might request a feature that describes how the product will provide value in solving a problem. A designer might define a requirement based on how the final product should look or perform from a usability or user interface standpoint.
A business analyst might create a system requirement that adheres to specific technical or organizational constraints. For today’s sophisticated products and software applications being built, it often takes hundreds or thousands of requirements to sufficiently define the scope of a project or a release. Thus, it’s imperative that the team be able to access, collaborate, update, and test each requirement through to completion, as requirements naturally change and evolve over time during the development process.
Now that we’ve defined the value of requirements management at a high-level, let’s go deeper into the four fundamentals that every team member and stakeholder can benefit from understanding −
- Planning good requirements: “What the heck are we building?”
- Collaboration and buy-in: “Just approve the spec, already!”
- Traceability & change management: “Wait, do the developers know that changed?”
- Quality assurance: “Hello, did anyone test this thing?”
Does everyone know what we’re building and why? That’s the value of requirements management.
Collaboration and Buy- In from Stakeholders
Is everyone in the loop? Do we have approval on the requirements to move forward? These questions come up during development cycles. It would be great if everyone could agree on requirements, but for large projects with many stakeholders, this does not usually happen. Trying to get everyone in agreement can cause decisions to be delayed, or worse, not made at all. Gaining consensus on every decision is not always easy.
In practice, you don’t necessarily want “consensus,” you want “buy-in” from the group and approval from those in control so you can move the project forward. With consensus, you are trying to get everyone to compromise and agree on the decision. With buy-in, you are trying to get people to back the best solution, make a smart decision and do what is necessary to move forward.
You don’t need everyone to agree that the decision is the best. You need everyone to support the decision. Team collaboration can help in receiving support on decisions and in planning good requirements.
Collaborative teams work hard to make sure everyone has a stake in projects and provides feedback. Collaborative teams continuously share ideas, typically have better communication and tend to support decisions made because there is a shared sense of commitment and understanding of the goals of the project.
It’s when developers, testers, or other stakeholders feel “out of the loop” that communication issues arise, people get frustrated and projects get delayed. Once everyone has bought-in to the scope of work, it is imperative for requirements to be clear and well documented. Keeping track of all the requirements is where things get tricky.
Imagine having a to-do list a mile long that involves collaborating with multiple people to complete. How would you keep all those items straight? How would you track how one change to an item would affect the rest of the project? This is where traceability and change management add value.
Planning Good Requirements
So, what makes a good requirement? A good requirement should be valuable and actionable; it should define a need as well as provide a pathway to a solution. Everyone on the team should understand what it means. Requirements vary in complexity.
A good Requirements Document can be part of a group with high-level requirements broken down into subrequirements.
They may also include very detailed specifications that include a set of functional requirements describing the behavior or components of the endproduct.
Good requirements need to be concise and specific, and should answer the question, “what do we need?” Rather than, “how do we fulfil a need?”
Good requirements ensure that all stakeholders understand their part of the plan; if parts are unclear or misinterpreted the final product could be defective or fail.
Preventing failure or misinterpretation of requirements can be aided by receiving feedback from the team continuously throughout the process as requirements evolve. Continuous collaboration and buy-in with everyone is a key to success.
Requirement Gathering and Analysis
A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an organizational objective; a condition or capability that must be met or possessed by a system.
Requirement analysis in software engineering covers those tasks that go into determining the needs or conditions to meet for a new or altered product taking account of the possible conflicting requirements of various stakeholders, analyzing, documenting, validating and managing software or system requirements.
The requirements should be −
- Documented
- Actionable
- Measurable
- Testable
- Traceable
Requirements should be related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
A Business analyst gathers information through observing the existing systems, studying the existing procedures, discussions with the customers and the end users. The analyst should also have imaginative and creative skills in absence of a working System. Analyzing the gathered requirement to find the missing links is requirement analysis.
Eliciting Approach
To elicit the objectives, ask the business expert, the development manager, and the project sponsor the following questions −
What business objectives of the company will this project help achieve?
Why are we doing this project now?
What will happen if we do it later?
What if we do not do it at all?
Who will benefit from this project?
Do the people who will benefit from it consider it the most important improvement that can possibly be made at this time?
Should we be doing a different project instead?
Possible objectives might be reducing costs, improving the customer service, simplifying the work flow, replacing obsolete technology, piloting a new technology, and many others. Also, make sure you understand exactly how the proposed project will help accomplish the stated objective.
Different Types of Requirements
The most common types of requirement which a Business analyst is interested would be the following −
Business Requirements
Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objectives while remaining solution independent. A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations.
User Requirements
User requirements should specify the specific requirements which the user expects/wants from software to be constructed from the software project. A user requirement should be Verifiable, Clear and concise, Complete, Consistent, Traceable, Viable.
The user requirements document (URD) or user requirements specification is a document usually used in software engineering that specifies what the user expects the software to be able to do.
System Requirements
System requirements deal with defining software resources requirements and prerequisites that needs to be installed on a computer to provide optimal functioning of an application.
Functional Requirements
Functional requirements capture and specify specific intended behavior of the system being developed. They define things such as system calculations, data manipulation and processing, user interface and interaction with the application, and other specific functionality that show how user requirements are satisfied. Assign a unique ID number to each requirement.
Non-Functional Requirements
Non-functional requirement is the one which specifies criteria that can be used to judge the operation of a system rather than specific behaviors. System architecture speaks on the plan for implementing non-functional requirements.
Non-functional requirements speak on how the system should look like or it can be mentioned like “system shall be”. Non-functional requirements are called as qualities of the system.
Transition Requirements
Transition Requirements describe capabilities that the solution must fulfill in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete.
They are differentiated from other requirements types, because they are always temporary in nature and because they cannot be developed until both an existing and new solution is defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation.
Traceability and Change Management
Requirements traceability is a way to organize, document and keep track of all your requirements from initial idea generation through to the testing phase.
The requirements trace ability matrix (RTM) provides a method for tracking the functional requirements and their implementation through the development process. Each requirement is included in the matrix along with its associated section number.
As the project progresses, the RIM is updated to reflect each requirement’s status. When the product is ready for system testing, the matrix lists each requirement, what product component addresses it, and what test verifies that it is correctly implemented
Include columns for each of the following in the RTM −
- Requirement description
- Requirement reference in FRD
- Verification Method
- Requirement reference in Test Plan
Example − Connecting the dots to identify the relationships between items within your project. It is a connector of common downstream flow.
Idea Requirements Design Test Business Objectives
You should be able to trace each of your requirements back to its original business objective.
By tracing requirements, you are able to identify the ripple effect changes have, see if a requirement has been completed and whether it’s being tested properly. Traceability and change management provides managers peace of mind and the visibility needed to anticipate issues and ensure continuous quality.
Quality Assurance
Getting requirements delivered right the first time can mean better quality, faster development cycles and higher customer satisfaction with the product. Requirements management not only helps you get it right, but also helps your team save money and many headaches throughout the development process.
Concise, specific requirements can help you detect and fix problems early, rather than later when it is much more expensive to fix. In addition, it can cost up to 100 times more to correct a defect later in the development process after it’s been coded, than it is to correct early on while a requirement.
By integrating requirements management into your quality assurance process, you can help your team increase efficiency and eliminate rework. Moreover, rework is where most of the cost issues occur.
In other words, development teams are wasting majority of their budgets on efforts that are not performed correctly the first time. For example, a developer codes a feature based on an old specification document, only to learn later, that the requirements for that feature changed. These types of issues can be avoided with effective requirements management best practices.
In summary, requirements management can sound like a complex discipline, but when you boil it down to a simple concept – it’s about helping teams answer the question, “Does everyone understand what we’re building and why?” From the business analysts, product managers and project leaders to the developers, QA managers and testers, along with the stakeholders and customers involved – so often the root cause of project failure is a misunderstanding of the scope of the project.
When everyone is collaborating, and has full context and visibility to the discussions, decisions and changes involved with the requirements throughout the lifecycle of the project, that is when success happens consistently and you maintain continuous quality. In addition, the process is smoother with less friction and frustration along the way for everyone involved.
Note − Research has shown that project teams can eliminate 50-80% of project defects by effectively managing requirements. According to the Carnegie Mellon software engineering institute, “60-80 percent of the cost of software development is in rework.”
Obtaining Requirements Signoff
Requirements signoff formalizes agreement by project stakeholders that the content and presentation of the requirements, as documented, are accurate and complete. Formal agreement reduces the risk that, during or subsequent to implementation, a stakeholder will introduce a new (previously unencountered) requirement.
Obtaining requirements signoff typically involves a face-to-face final review of requirements, as documented, with each project stakeholder. At the end each review, the stakeholder is asked to formally approve the reviewed requirements document. This approval may be recorded either physically or electronically.
Obtaining requirements signoff is typically the final task within Requirements Communication. The Business Analyst will require the output from the Formal Requirements Review(s), including accommodation of any comments or objections which were raised during the review process.
Business Analysis - Modelling
A Business Model can be defined as a representation of a business or solution that often include a graphic component along with supporting text and relationships to other components. For example, if we have to understand a company’s business model, then we would like to study the following areas like −
- Core values of the company
- What it serves?
- What is sets apart?
- Its key resources
- Major relationships
- Its delivery channels
With the help of modelling techniques, we can create a complete description of existing and proposed organizational structures, processes, and information used by the enterprise.
Business Model is a structured model, just like a blueprint for the final product to be developed. It gives structure and dynamics for planning. It also provides the foundation for the final product.
Purpose of Business Modelling
Business modelling is used to design current and future state of an enterprise. This model is used by the Business Analyst and the stakeholders to ensure that they have an accurate understanding of the current “As-Is” model of the enterprise.
It is used to verify if, stakeholders have a shared understanding of the proposed “To-be of the solution.
Analyzing requirements is a part of business modelling process and it forms the core focus area. Functional Requirements are gathered during the “Current state”. These requirements are provided by the stakeholders regarding the business processes, data, and business rules that describe the desired functionality which will be designed in the Future State.
Performing GAP Analysis
After defining the business needs, the current state (e.g. current business processes, business functions, features of a current system and services/products offered and events that the system must respond to) must be identified to understand how people, processes and technology, structure and architecture are supporting the business by seeking input from IT staff and other related stakeholders including business owners.
A gap analysis is then performed to assess, if there is any gap that prevents from achieving business needs by comparing the identified current state with the desired outcomes.
If there is no gap (i.e. the current state is adequate to meet the business needs and desired outcomes), it will probably not be necessary to launch the IT project. Otherwise, the problems/issues required to be addressed in order to bridge the gap should be identified.
Techniques such as SWOT (Strengths, Weaknesses, Opportunities and Threats) Analysis and document analysis can be used.
To Assess Proposed System
BA should assist the IT project team in assessing the proposed IT system to ensure that it meets the business needs and maximizes the values delivered to stakeholders. BA should also review the organization readiness for supporting the transition to the proposed IT system to ensure a smooth System Implementation.
BA should help the IT project team to determine whether the proposed system option and the high-level system design could meet the business needs and deliver enough business value to justify the investment. If there are more than one system options, BA should work with the IT staff to help to identify the pros and cons of each option and select the option that delivers the greatest business value.
Guiding Principles for Business Modelling
The primary role of business modelling is mostly during inception stage and elaboration stages of project and it fades during the construction and transitioning stage. It is mostly to do with analytical aspects of business combined with technical mapping of the application or software solution.
Domain and User variation − Developing a business model will frequently reveal areas of disagreement or confusion between stakeholders. The Business Analyst will need to document the following variations in the as-is model.
Multiple work units perform the same function − Document the variances in the AS-IS model. This may be different divisions or geographies.
Multiples users perform the same work − Different stakeholders may do similar work differently. The variation may be the result of different skill sets and approaches of different business units or the result of differing needs of external stakeholders serviced by the enterprise. Document the variances in the AS-IS model.
Resolution Mechanism − The Business Analyst should document whether the ToBe solution will accommodate the inconsistencies in the current business model or whether the solution will require standardization. Stakeholders need to determine which approach to follow. The To-Be model will reflect their decision.
Example of BA role in Modelling ERP Systems
A Business analyst is supposed to define a standard business process and set up into an ERP system which is of key importance for efficient implementation. It is also the duty of a BA to define the language of the developers in understandable language before the implementation and then, utilize best practices and map them based on the system capabilities.
A requirement to the system is the GAAP fit analysis, which has to balance between −
The need for the technical changes, which are the enhancements in order to achieve identity with the existing practice.
Effective changes, which are related to re-engineering of existing business processes to allow for implementation of the standard functionality and application of process models.
Functional Business Analyst
Domain expertise is generally acquired over a period by being in the “business” of doing things. For example,
A banking associate gains knowledge of various types of accounts that a customer (individual and business) can operate along with detailed business process flow.
An insurance sales representative can understand the various stages involved in procuring of an Insurance policy.
A marketing analyst has more chances of understanding the key stakeholders and business processes involved in a Customer Relationship Management system.
A Business Analyst involved in capital markets project is supposed to have subject matter expertise and strong knowledge of Equities, Fixed Income and Derivatives. Also, he is expected to have handled back office, front office, practical exposure in applying risk management models.
A Healthcare Business Analyst is required to have basic understanding of US Healthcare Financial and Utilization metrics, Technical experience and understanding of EDI 837/835/834, HIPAA guidelines, ICD codification – 9/10 and CPT codes, LOINC, SNOMED knowledge.
Some business analysts acquire domain knowledge by testing business applications and working with the business users. They create a conducive learning environment though their interpersonal and analytical skills. In some cases, they supplement their domain knowledge with a few domain certifications offered by AICPCU/IIA and LOMA in the field of Insurance and financial services. There are other institutes that offer certification in other domains.
Other Major Activities
Following a thorough examination of current business processes, you can offer highly professional assistance in identifying the optimal approach of modelling the system.
Organizing the preparation of a formalized and uniform description of business processes in a manner ensuring efficient automation in the system.
Assistance to your teams in filling out standard questionnaires for the relevant system as may be furnished by the developers.
Participation in working meetings requirements towards the developers are defined.
Check and control as to whether the requirements set by you have been properly “reproduced” and recorded in the documents describing the future model in the system (Blueprints).
Preparation of data and assisting for prototyping the system.
Assistance in preparation of data for migration of lists and balances in the format required by the system.
Review of the set-up prototype for compliance with the requirements defined by the business process owners.
Acting as a support resource to your IT teams in preparing data and actual performance of functional and integration tests in the system.
In the next section, we will discuss briefly about some of the popular Business Modelling Tools used by large organizations in IT environments.
Tool 1: Microsoft Visio
MS-Visio is a drawing and diagramming software that helps transform concepts into a visual representation. Visio provides you with pre-defined shapes, symbols, backgrounds, and borders. Just drag and drop elements into your diagram to create a professional communication tool.
Step 1 − To open a new Visio drawing, go to the Start Menu and select Programs → Visio.
Step 2 − Move your cursor over “Business Process” and select “Basic Flowchart”.
The following screenshot shows the major sections of MS-Visio application.
Let us now discuss the basic utility of each component −
A − the toolbars across the top of the screen are like other Microsoft programs such as Word and PowerPoint. If you have used these programs before, you may notice a few different functionalities, which we will explore later.
Selecting Help Diagram Gallery is a good way to become familiar with the types of drawings and diagrams that can be created in Visio.
B − The left side of the screen shows the menus specific to the type of diagram you are creating. In this case, we see −
- Arrow Shapes
- Backgrounds
- Basic Flowchart Shapes
- Borders and Titles
C − The center of the screen shows the diagram workspace, which includes the actual diagram page as well as some blank space adjacent to the page.
D − The right side of the screen shows some help functions. Some people may choose to close this window to increase the area for diagram workspace, and re-open the help functions when necessary.
Tool 2: Enterprise Architect
Enterprise architect is a visual modeling and design tool based on UML. The platform supports the design and construction of software systems, modeling business processes and modeling industry based domains. It is used by business and organizations to not only model the architecture of their systems. But to process the implementation of these models across the full application development life cycle.
The intent of Enterprise architect is to determine how an organization can most effectively achieve its current and future objectives.
Enterprise architect has four points of view which are as follows −
Business perspective − The Business perspective defines the processes and standards by which the business operates on day to day basis.
Application Perspective − The application perspective defines the interactions among the processes and standards used by the organization.
Information Perspective − This defines and classifies the raw data like document files, databases, images, presentations and spreadsheets that organization requires in order to efficiency operate.
Technology Prospective − This defines the hardware, operating systems, programming and networking solutions used by organization.
Tool 3: Rational Requisite Pro
The process of eliciting, documenting organizing tracking and changing Requirements and communicating this information across the project teams to ensure that iterative and unanticipated changes are maintained throughout the project life cycle.
Monitoring status and controlling changes to the requirement baseline. The Primary elements are Change control and Traceability.
Requisite Pro is used for the above activities and project administration purposes, the tool is used for querying and searching, Viewing the discussion that were part of the requirement.
In Requisite Pro, the user can work on the requirement document. The document is a MS-Word file created in Reqpro application and integrated with the project database. Requirements created outside Requisite pro can be imported or copied into the document.
In Requisite Pro, we can also work with traceability, here it is a dependency relationship between two requirements. Traceability is a methodical approach to managing change by linking requirements that are related to each other.
Requisite Pro makes it easy to track changes to a requirement throughout the development cycle, so it is not necessary to review all your documents individually to determine which elements need updating. You can view and manage suspect relationships using a Traceability Matrix or a Traceability Tree view.
Requisite Pro projects enable us to create a project framework in which the project artifacts are organized and managed. In each project the following are included.
- General project information
- Packages
- General document information
- Document types
- Requirement types
- Requirement attributes
- Attribute values
- Cross-project traceability
Requisite Pro allows multiple user to access the same project documents and database simultaneously hence the project security aspect is to very crucial. Security prevents the system use, potential harm, or data loss from unauthorized user access to a project document.
It is recommended that the security is enabled for all RequisitePro projects. Doing so ensures that all changes to the project are associated with the proper username of the Individual who made the change, thereby ensuring that you have a complete audit trail for all changes.