Przejdź do głównej zawartości

Inżynieria Wymagań cz. 1

Dziś kolejna recenzja (no, kolejna to może zbyt szumnie powiedziane- druga recenzja na tym blogu😉 )

Parę dni temu skończyłam czytać lekturę Pani Karoliny Zmitrowicz  „Analityk Systemów – przygotowanie do egzaminu z inżynierii wymagań” wydawnictwa PWN. We wszelkich opisach, które udało mi się przeczytać, zanim zaopatrzyłam się w książkę można było wysnuć wniosek, że książka będzie rozszerzeniem sylabusa, który znajduje się na oficjalnej stronie dotyczącej certyfikatu REQB


Autorka obiecuje, że z książki dowiemy się:
  • Czym jest inżynieria wymagań wg programu REQB i jakie czynności wchodzą w jej skład,
  • Czym są wymagania, jak można je sklasyfikować i jakimi atrybutami powinny się cechować,
  • Jakie miejsce w przedsięwzięciu informatycznym zajmuje inżynieria wymagań i jakie ma znaczenie dla sukcesu projektu,
  • Jak pozyskiwać, analizować, dokumentować wymagania oraz w jaki sposób zapewnić, że są one odpowiedniej jakości,
  • Jaki zakres wymagany jest na egzaminie certyfikowanym,
  • Jakie pytania egzaminacyjne możesz spotkać podczas egzaminu certyfikacyjnego.


Zaciekawiona i zachęcona dobrymi opiniami oraz opisem zamówiłam te pozycję i zaczęłam czytać. No i wszystko było okej, do momentu, w którym nie otworzyłam wyżej opisanego sylabusa...

Niestety Książka tylko odrobinę rozszerza to co jest opisane w tym niezbyt skomplikowanym pliku pdf. „Sylabusowe treści” są okraszone krótkimi przykładami i ładnymi dla oka diagramami, ale żeby to jakoś bardzo znacząco wpłynęło na efektywność mojej nauki? Nie wydaje mi się.

Oczywiście w podręczniku znajdziemy wszystkie zagadnienia, o które będą nas pytać w certyfikacie. Autorka przeprowadza czytelnika przez podstawy inżynierii wymagań, kontekst inżynierii wymagań, zarządzanie wymaganiami, opracowanie wymagań, modele procesów i na koniec pokazuje narzędzia, którymi możemy wykonać te wszystkie skomplikowane procesy. To co szczególnie mi się podobało to pytania egzaminacyjne, które mieściły się na końcu każdego rozdziału, może nie ma ich zbyt wiele, ale dają jakiś ogląd, czego możemy się spodziewać podchodząc do ostatecznego egzaminu.


Tylko pojawia się pytanie, czy trzeba przeczytać te książkę, żeby podejść do egzaminu certyfikującego? Wg mnie nie. Sylabus może faktycznie w sposób łopatologiczny i małociekawy przedstawia treści związane z egzaminem, ale przeglądając próbne testy wydaje mi się, że w 100% zaspokaja on potrzeby osób podchodzących do egzaminu. Niemniej jeśli łatwiej jest Ci się uczyć z tekstu, w którym zobaczysz raz na jakiś czas diagram, wykres lub jakiś rysunek i masz wolne niecałe 50 zł to może warto ją nabyć. 

 Postaram się uzupełnić ten post o różnice pomiędzy sylabusem a książką, jak już będę ostatecznie przygotować się do certyfikatu. 

Komentarze

Popularne posty z tego bloga

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym  blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego. Przejdź do pytań   Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.   Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych. No to lecimy :) pytanie na dziś to     Jak Pani przeprowadza analizę? Pierwsze co mi się nasunęło na myśl: „ To zależy ” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy. Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- J

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy! Takie podobno cieszą się największym zainteresowaniem 😊 Jakie Pani zna rodzaje diagramów UML ? No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13 😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.  Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.   Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊 Proszę napisać wymganie w formie user stories.  Proszę zapisać wymaganie w formie przypadku użycia. Czym są sytuacje wyjątkowe w opisie przypadków użycia ? No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories , a czym Use Case . User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2] User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy )[3]. Ważne jest to,