wymagania na system

Złote reguły towarzyszące przypadkom użycia

?Złote reguły? to nic innego jak wykaz punktów, które zazwyczaj kontroluję podczas tworzenia przypadków użycia. Gdy mam już narysowany przypadek użycia sprawdzam czy: przypadek użycia zapewnia wartość aktorom, krótki opis zwięźle opisuje cel przypadku użycia, przypadek użycia jest kompletny i sensowny, wydarzenie rozpoczynające przypadek użycia jest jasne, sposób i czas zakończenia przypadku użycia jest jasny, […]

Złote reguły towarzyszące przypadkom użycia Czytaj dalej »

Prototyp a przypadek użycia

Specyfikacja wymagań na system to trudny moment przede wszystkim dla osób, które muszą je wyspecyfikować. Nie zawsze wiadomo w jaki sposób narzędzia informatyki będą mogły pomóc. Często mówimy tylko o funkcjonalności i o tym w jaki sposób system ma realizować procesy biznesowe.  Powstaje pytanie jak skutecznie uzupełnić wymagania także o takie szczegóły jak rozmieszczenie przycisków,

Prototyp a przypadek użycia Czytaj dalej »

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 »

Z nowym rokiem

Z nowym rokiem uzupełniłem kilka wpisów, które były niedokończone a które miały się ukazać w grudniu. Pierwsze dwa tygodnie były dość pracowite dla mnie.  Jedno z zadań z jakiego myślę, że wywiązałem należycie się to autorskie szkolenie zakresu gromadzenia i zarządzania wymaganiami w Enterprise Architect.  Dlaczego myślę, że wywiązałem się należycie. W testach z wiedzy

Z nowym rokiem 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 »

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 »

Skuteczne i wydajne narzędzie do zarządzania wymaganiami

W zeszłym tygodniu na jednym ze spotkań dotyczącego projektu o dość sporej wartości dostałem pytanie: Dlaczego do większych projektów do zarządzania wymaganiami rekomenduję IBM Rational RequisitePro? Oponent argumentował, że to drogi produkt a wejście w niego ?spycha? w dość kosztowną platformę Rational. Pozornie miał rację. Otóż w przypadku małych firm i niewielkich projektów wystarczą narzędzia

Skuteczne i wydajne narzędzie do zarządzania wymaganiami Czytaj dalej »

Scroll to Top