analiza wymagań

Funkcje aplikacji: alternatywa dla przypadków użycia

Sytuację zna każdy analityk pracujący z istniejącymi systemami: zespół otrzymuje zgłoszenie zmiany lub rozwoju funkcjonalności. Gdzie precyzyjnie przypisać nowe wymagania, skoro nie tworzymy już szczegółowych przypadków użycia od zera? Klasyczne podejście dokumentacyjne sprawdza się przy projektowaniu nowych systemów, ale w codziennej praktyce zarządzania zmianą potrzebujemy czegoś bardziej pragmatycznego. Odpowiedzią na ten problem może być koncepcja […]

Funkcje aplikacji: alternatywa dla przypadków użycia Czytaj dalej »

Podstawowe zasady zarządzania wymaganiami

W dynamicznym świecie rozwoju oprogramowania, gdzie technologia zmienia się w zawrotnym tempie, a projekty stają się coraz bardziej złożone, skuteczne zarządzanie wymaganiami jest ważniejsze niż kiedykolwiek wcześniej. Ponad 15 lat temu Ian Sommerville i Pete Sawyer położyli podwaliny pod tę dziedzinę (pisałem o tym w tekście Zarządzanie wymaganiami – dobre praktyki), ale dzisiejsze wyzwania wymagają

Podstawowe zasady zarządzania wymaganiami Czytaj dalej »

Wymagania a architektura systemów

Sporo się mówi o współpracy między analitykami a architektami. Wymagania oraz ograniczenia techniczne i biznesowe to wspaniała platforma do interakcji między analitykami i architektami. Celem niniejszego artykułu jest analiza i przedstawienie zależności między wymaganiami a architekturą systemów informatycznych. Postaram się przedstawić jak różne rodzaje wymagań – funkcjonalne, niefunkcjonalne, techniczne i biznesowe – wpływają na kształtowanie

Wymagania a architektura systemów Czytaj dalej »

BPMN i UML w praktyce cz.2 – zmiana

Kilka tygodni temu napisałem tekst w którym zaprezentowałem praktyczne podejście do notacji UML i BPMN (https://wolski.pro/2024/01/bpmn-i-uml-w-praktyce/). Przygotowanych zostało kilka diagramów opisujących  wymagania biznesowe, procesy biznesowe, przypadki użycia, diagramy aktywności i komponentów. Zaprezentowane wówczas podejście wydaje się, że jest przydatne, gdy nie mamy modeli a z uwagi na stopień skomplikowania wytwarzanego oprogramowania, posiadanie modeli może być

BPMN i UML w praktyce cz.2 – zmiana Czytaj dalej »

BPMN i UML w praktyce

Łączne użycie UML i BPMN w projekcie informatycznym zapewnia komplementarne podejście do modelowania zarówno aspektów technicznych, jak i biznesowych systemu. UML skupia się na strukturze i działaniu systemu informatycznego, podczas gdy BPMN koncentruje się na procesach biznesowych i ich przepływie. Dzięki temu, możliwe jest kompleksowe ujęcie przedsięwzięcia, uwzględniając zarówno wymagania biznesowe, jak i techniczne. Wykorzystanie

BPMN i UML w praktyce Czytaj dalej »

10 wskazówek poprawiających analizę wymagań

Podczas mojej pracy zauważyłem, że spory problem stanowią wymagania i w sumie to cała analiza. Trudnością nie jest ich spisanie. Trudnością jest ich wyartykułowanie, przeanalizowanie i potwierdzenie. Pomijam turbulencje związane z celem zamiany czy też budowy systemu. Nie zawsze trzeba wiedzieć, po co się zmienia system. Żartowałem :-). Wiedzieć trzeba. W tym wpisie podzielić się kilkoma

10 wskazówek poprawiających analizę wymagań Czytaj dalej »

Gherkin a przypadki użycia

Wielokrotnie już pisałem o metodach zwinnych oraz bardziej klasycznych. W tym tekście także wejdę w ten temat, a mianowicie postaram się porównać podejście analityczne oparte o przypadki użycia i Gherkin wywodzące się z nurtu Behavior-Driven Development. Czym jest Gherkin a czym przypadek użycia? Przypadek użycia Zacznę od przypadku użycia. Przypadek użycia (ang. use case) to

Gherkin a przypadki użycia Czytaj dalej »

Subiektywne porównanie narzędzi do modelowania procesów biznesowych

W wielu firmach, z którymi mam przyjemność współpracować jest stosowana nierozłączna para: JIRA i Confluence.  JIRA odpowiada za zarządzania zadaniami a Confluence jest swoistym repozytorium treści. Narzędzia te zostały niejako wtłoczone w proces wytwarzania oprogramowania. Korzystają z niego programiści, testerzy, a także analitycy i architekci. W wielu firmach pojawia się też i narzędzie do modelowania.

Subiektywne porównanie narzędzi do modelowania procesów biznesowych Czytaj dalej »

Zasada TAO w procesie wytwórczym oprogramowania

W co większych firmach lub przy okazji dużych przedsięwzięć zwanych projektami, analitycy to nie jedna lub dwie osoby a grupa ludzi, która opracowuje wymagania, procesy biznesowe, specyfikuje wymagania. Ta grupa ludzi współpracuje z projektantami, programistami oraz ogólnie rozumianym biznesem. W takich organizacjach obserwuję dwa różne sposoby działania. Jeden, w którym nie ma opracowanych zasad modelowania

Zasada TAO w procesie wytwórczym oprogramowania Czytaj dalej »

Wymagania biznesowe a wymagania systemowe

Wiele się mówi o potrzebie identyfikacji celów projektowych, celów organizacji a także o potrzebie identyfikacji wymagań biznesowych oraz systemowych. Wszystko po to by lepiej zrozumieć oczekiwania biznesu (interesariuszy) w kontekście tego co ma być zrobione, na czym ma polegać zmiana, co ma być wynikiem realizacji projektu.  Wymienione powyżej elementy mają finalnie być uszczegółowione wymaganiami na system.

Wymagania biznesowe a wymagania systemowe Czytaj dalej »

Przewijanie do góry