zarządzanie wymaganiami

Informacje dotyczące zarządzania wymaganiami

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 »

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 »

Przewijanie do góry