analiza wymagań

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 »

Zarządzanie relacjami pomiędzy wymaganiami

Zarządzanie wymaganiami to ważny element procesu wytwórczego oprogramowania. Jednym z jego elementów budowanie i zarządzanie relacjami pomiędzy wymaganiami. Najczęściej spotykanym jest podejście stosowane czy też nawet promowane przez Sparx Systems. Enterprise Architect w swojej dokumentacji proponuje, by wymagania były łączone ze sobą za pomocą agregacji lub kompozycji. To dobre, choć uproszczone podejście do tego zagadnienia,

Zarządzanie relacjami pomiędzy wymaganiami Czytaj dalej »

Zarządzanie wymaganiami – dobre praktyki

Ian Sommerville i Pete Sawyer w „Requirements Engineering: A Good Practice Guide” opisali, ponad 15 lat temu, metodę oceny i doskonalenia procesów inżynierii wymagań. Opiera się ona na wyodrębnieniu dobrych praktyk, czyli czynności będących pożądanymi elementami wzorcowego procesu inżynierii wymagań. Autorzy starali się przy tym objąć całość problematyki inżynierii wymagań. W moim mniemaniu te dobre

Zarządzanie wymaganiami – dobre praktyki Czytaj dalej »

Plan zarządzania wymaganiami

Plan zarządzania wymaganiami to dokument, który opisuje zasady postępowania z wymaganiami. W moim odczuciu to jeden z najważniejszych dokumentów, gdyż w jawny sposób opisuje szereg ważnych informacji dotyczących sposobu udokumentowania wymagań. To swoisty kontrakt pomiędzy analitykami a pozostałymi interesariuszami. Dokument w zależności od projektu może się różnić. W opisie wymagań nie zapominam o przypadkach życia, Zazwyczaj

Plan zarządzania wymaganiami Czytaj dalej »

Scroll to Top