Wymaganie niefunkcjonalne zawsze wydają się być zbyt słabo podkreślone podczas pisania wymagań. Zazwyczaj brakuje na nie czasu i są zbyt szczegółowe by wszystkie opisać. Ponadto udziałowcy projektu w tym analitycy biznesowi mają tendencję do zaniedbywania wymagań niefunkcjonalnych gdyż pisząc wymagania skupiają się na użytkowniku i ich celach. To dziwne gdyż cele użytkownika i scenariusze przypadków […]
niedocenione wymagania niefunkcjonalne Czytaj dalej »
Chciałbym podzielić się kilkoma istotnymi zasadami, które, mam nadzieję, że pomogą ustanowić efektywne podstawy dla modelowania wymogów metodą agile (i nie tylko). 1. "Niezwykle ważny jest aktywny udział osób zainteresowanych”. Udziałowcy projektu powinni przekazywać swoje wymagania, nadawać im priorytety oraz w odpowiednim czasie podejmować decyzję. Istotnym jest, aby udziałowcy projektu zrozumieli tę koncepcję i angażowali
KILKA PORAD DLA MODELOWANIA WYMAGAŃ METODĄ AGILE Czytaj dalej »
Analizując model przypadków użycia można zidentyfikować elementy modelu statycznego (struktury). Poniżej kilka porad w tym zakresie: Szukaj rzeczowników: to zazwyczaj klasy lub atrybuty, przykładowo Centrum Odpowiedzialności. Szukaj czasowników: wskazują one często na związek. Przykładowo, użytkownik przypisuje Klienta do Centrum Odpowiedzialności. Szukaj sprawców: jeśli biznes wskazuje na ich działanie, lub są oni do czegoś potrzebni, stanowią
Identyfikacja elementów modelu statycznego na bazie modelu przypadków użycia Czytaj dalej »
Modelując procesy biznesowe czy też scenariusze działania systemów IT często dochodzi do dyskusji jak nazwać proces.Poniżej są wskazówki i lista sugerowanych nazw, które można zastosować identyfikując procesy na diagramach DFD, diagramach aktywności, czy scenariuszach opisujących dekomponujących przypadki użycia,.: Nazwa powinna składać się z wyrażenia czasownikowego poprzedzonego wyrażeniem rzeczownikowym, przykładowo ważność zakresu ubezpieczenia, Użyj wyrażenia czasownikowego
Nazywanie procesu Czytaj dalej »
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 »
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 »
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 »
