Enterprise Architect w swojej dokumentacji proponuje by wymagania były łączone ze sobą za pomocą agregacji. Zastosowanie agregacji nie jest zgodne ze znanymi mi standardami. Jeśli potrzebujesz modelować wymagania zgodnie ze standardami proponuję SysML – Systems Modeling Language for Products and Systems Development. Podobne wpisy Książki o UML – UML dla Każdego Książki o UML – […]
Śledzenie zależności pomiędzy wymaganiami Czytaj dalej »
Często otrzymuję pytanie jak opisuję wymagania. Otóż wielu projektach określam statusy i wymagania w następujący sposób:Status• Proponowane – wymaganie w fazie negocjacji pomiędzy klientem a analitykami• Zatwierdzone -wymaganie zatwierdzone do realizacji.• Odrzucone – wymaganie odrzucone przez klienta lub analityków. Podobne wpisy Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET W artykule przedstawiono opis pakietu narzędziowego
Statusy i priorytety wymagań Czytaj dalej »
Otrzymałem mailem ciekawe pytanie: Czy wg Pana wiedzy istnieje w EA obiekt, który najbardziej nadawałby się do rejestracji problemów zidentyfikowanych podczas analizy (AS-IS) biznesowej lub systemowej? Mam na myśli taki obiekt, w którym rejestrowane byłby, parametry zidentyfikowanego podczas warsztatów problemu, np. nazwa, opis, powiązanie z procesem, przyczyna występowania, itp., a po zarejestrowaniu dałoby się łatwo
Rejestracja problemów zidentyfikowanych podczas analizy Czytaj dalej »
Kilka lat temu napisaliśmy z Maćkiem Kożuchem niezależnie od Sparx Systems narzędzie, które pomagało nam w pracy nad repozytoriami Enterprise Architect. Nazwaliśmy je Tormigo (natchnęła nas mrówka –> po hiszpańsku hormiga). Dziś szykujemy się do aktualizacji tego narzędzia choć minie pewnie jeszcze parę miesięcy za nim to nastąpi. O Tormigo wspominam dziś, gdyż otrzymałem maila
Tormigo za oceanem Czytaj dalej »
Nic mnie tak nie cieszy jak odkrycie, że na polskiej blogosferze pojawia się nowy blog o inżynierii oprogramowania. Tym razem takim odkryciem jest blog, który pani Ewa Wardzała. Pod dość niepozorną nazwą niezależny konsultant kryją się wpisy bazujące na doświadczeniach Pani Ewy. Mnie się na razie podoba bo jest i merytorycznie i na luzie. Sami
Niezależny konsultant–nowy blog Czytaj dalej »
Jakość opisu wymagań jest bardzo ważna i tego nie muszę nikomu tłumaczyć. Standard ANSI/IEEE 830 formułuje szereg zaleceń, jakie powinna spełniać dobrze napisana specyfikacja wymagań. Dobrze opracowaną specyfikację charakteryzują następujące cechy (na podstawie “Inżynieria oprogramowania” Krzysztof Sacha): Poprawność – specyfikacja powinna opisywać tylko te wymagania, które są potrzebne użytkownikom. Jeżeli oprogramowanie jest elementem większego systemu,
Cechy perfekcyjnych wymagań na system Czytaj dalej »
Ostatnio natknąłem się na prace Kartezjusza* “Rozprawa metodzie”. Czytając to dzieło w rozdziale w części drugiej przeczytałem opis metody, którą niemalże bez zmian stosuje się dziś w procesie analizy i projektowaniu systemów. “… Jak mnogość praw dostarcza często usprawiedliwienia występkom, tak iż w państwie o wiele większy jest ład wówczas, gdy przy niewielkiej ilości praw
Kartezjusz a projektowanie systemów Czytaj dalej »
Rzadko piszę o dyskusjach, w których uczestniczę. Tym razem pragnę zwrócić uwagę na dyskusję jaka ma miejsce na goldenline: http://www.goldenline.pl/forum/3086284/interfejs-uzytkownika-wymaganie-klienta-czy-projekt-developera/s/1#52022118 Jarek Żeliński rozpoczął ciekawą dyskusję na temat czy interfejs użytkownika jest wymaganiem czy też projektem. Na drugiej stronie wyraziłem swoją opinię: Ja już od jakiegoś czasu traktuję interfejs użytkownika, jako wymaganie klienta. Jest to chyba
Interfejs użytkownika–wymaganie czy projekt? Czytaj dalej »
Kilka dni temu w poście Inżynieria wymagań – certyfikaty pisałem o problemach w standaryzacji pracy analityka. W tamtym wpisie (być może trochę przydługim) wskazałem potrzebę potwierdzenia swoich kompetencji odpowiednim certyfikatem. Zdaję sobie sprawę, że taki certyfikat to dla wielu osób “kwiatek do kożucha”, ale myślę, że warto by się z przyjrzeć temu kwiatkowi by móc
Certyfikowany inżynier wymagań Czytaj dalej »
Jedną z bardziej żmudnych czynności realizowanych w fazie wymagań jest analiza aktów normatywnych. W mojej ocenie dużym błędem jest wskazanie w wymaganiach na system iż ma on być zgodny np. z ustawą X. Moim zdaniem, niestety trzeba rozbić każdy (mający wpływ na system) paragraf i podpunkt na oddzielne wymaganie. Poniżej krótki opis mojego “sposobu” na
Akty normatywne a wymagania Czytaj dalej »
