zarządzanie wymaganiami

Informacje dotyczące zarządzania wymaganiami

o wymaganiach

W sieci pojawił się nowy blog o wymaganiach (http://owymaganiach.pl/). Cieszy mnie ta inicjatywa, Pana Jakuba Jurkiewicza – doktoranta na Politechnice Poznańskiej, gdyż w sieci jest mało zasobów na temat inżynierii oprogramowania a te zapowiadają się sensownie.    Z pierwszych wpisów polecam teksty o przypadkach użycia. Powodzenia 🙂 Technorati Tagi: przypadki użycia,zarządzanie wymaganiami Podobne wpisy Zintegrowane środowisko […]

o wymaganiach Czytaj dalej »

Alternatywna prezentacja wymagań

W Enterprise Architect jest dedykowany do gromadzenia wymagań element zwany ?Requirement? Jest to bardzo komfortowa sytuacja, ale co zrobić gdy nie ma takiego elementu w danym narzędziu CASE? Podobne wpisy UML – zastosowanie w biznesie Po raz kolejny Centrum Promocji Informatyki zorganizowało seminarium związane z wykorzystaniem języka UML w biznesie. W tym przedsięwzięciu miałem swój

Alternatywna prezentacja wymagań Czytaj dalej »

Przypadki użycia i aktorzy– kilka rad

Kilka porad odnośnie przypadków użycia i aktorów. Przypadek użycia nie dostarcza funkcjonalności aktorowi Problem: Często oznacza to, że każdy przypadek użycia sam w sobie nie dostarcza wartości aktorowi. Rada: Proszę połączyć fragmentaryczne przypadki użycia w kompletną sekwencję takich fragmentów, które łącznie zapewnią wartość aktorom. Stanowiska pracy jako aktorzy Problem: Powszechnym błędem jest tworzenie aktorów, którzy

Przypadki użycia i aktorzy– kilka rad Czytaj dalej »

Wspólne słownictwo

W trakcie szkicowania procesów biznesowych należy zdefiniować wspólne słownictwo, przy użyciu najpopularniejszych terminów i wyrażeń w zakresie problemu. Następnie należy konsekwentnie wykorzystywać wspólne słownictwo we wszystkich tekstowych opisach biznesu. W ten sposób, utrzymują Państwo spójne opisy tekstowe i unika się nieporozumień wśród członków projektu dot. stosowania i znaczenia terminów. Słownictwo powinno mieć formę słownika. Aby

Wspólne słownictwo Czytaj dalej »

Trzy korzyści z przypadków użycia

Każdemu zalecam stosowanie przypadków użycia ? także a może przede wszystkim w projektach Agile. Poniżej zamieszczam trzy podstawowe zalety, które myślę, że przekonają do używania przypadków użycia w projektach Agile 1. Dzięki przypadkom użycia zyskuje się kontekst Nawet w projektach Agile przypadki użycia są mechanizmem umożliwiającym firmom osiąganie celów. Podejście, które wykorzystuje ustrukturyzowane wymagania dostarcza

Trzy korzyści z przypadków użycia Czytaj dalej »

Historyjki użytkownika a przypadki użycia

Obecnie znajdujemy się w dziwnej sytuacji ? są user stores (zwane w języku polskim historyjkami użytkownika) i scenariusze przypadków użycia z czego te ostatnie można podzielić na przypadki użycia formalne i nieformalne a także streszczenia przypadków użycia. Czym one się różnią, a w czym są takie same? Przypadki użycia, scenariusze przypadków użycia i user stories

Historyjki użytkownika a przypadki użycia Czytaj dalej »

Dobre praktyki inżynierii wymagań

Jakiś czas temu na stronie Pana Kowalczykiewicza był ciekawy tekst na temat dobrych praktyk w inżynierii wymagań. Obecnie ta strona jest wyłączona. Z tego też powodu pozwalam sobie na publikację tego tekstu, który (co mnie zadziwia) miałem w swoim archiwum. Tekst ten został odrobinę przeformatowany. Ian Sommerville i Pete Sawyer zaproponowali ciekawą metodę oceny i

Dobre praktyki inżynierii wymagań Czytaj dalej »

Słownik w Enterprise Architect

Każdy inżynier oprogramowania dobrze wie jak ważnym dokumentem jest Słownik w trakcie procesu wytwórczego oprogramowania a szczególnie w jego pierwszych fazach. Bez zrozumienia pojęć czy skrótów, którymi posługuje się klient z na pewno nie rozwiążemy jego problemu. Enterprise Architect (EA) udostępnia nam funkcjonalność związaną z budową Słownika (menu Project > Documentation > Glossary?). W okienku

Słownik w Enterprise Architect Czytaj dalej »

Zarządzanie wymaganiami w Enterprise Architect – mapowanie wymagań na przypadki użycia

Enterprise Architect, moim zdaniem, nie jest najszczęśliwszym narzędziem do zarządzania wymaganiami. Nie jest też beznadziejny. W projektach dla mnie ważne jest to jak wymagania są mapowane na konkretne przypadki użycia (PU). Pozwala to stwierdzić, które PU są bardziej złożone, wymagają większej uwagi i są ważniejsze dla klienta. Aby to stwierdzić trzeba zmapować PU z konkretnymi

Zarządzanie wymaganiami w Enterprise Architect – mapowanie wymagań na przypadki użycia Czytaj dalej »

Specyfikacja systemu a przypadki użycia

Na jednym ze spotkań z klientem otrzymałem pytanie: Czy przypadki użycia są jedyną formą specyfikacji systemu? Moja odpowiedź była jasna: NIE. Przypadki użycia są niewątpliwie pożyteczne dla specyfikowania systemów, ale nie pozwalają w pełni opisać wymagań. Przypadki użycia stanowią swoiste agregaty dla wymagań, pozwalają dokonać pewnej dekompozycji wymagań na poszczególne funkcje systemu. Niestety ich rola

Specyfikacja systemu a przypadki użycia Czytaj dalej »

Scroll to Top