Dołączanie grafiki do wymagań

Naturą wymagań jest ich forma tekstowa. Każde wymaganie jest formułowane w języku naturalnym. Składa się co najmniej z jednego zdania oznajmującego.

Dobrze, żeby wymaganie miało:

• swój unikalny identyfikator, do którego można referować w innych artefaktach analitycznych, 
• nazwę - która w skrótowej formie prezentuje jego charakter,
• treść - jedno lub kilka zdań; może się składać również z listy numerowanych lub wypunktowań.

A co, jeśli wymaganie dotyczy na przykład ekranu użytkownika lub kształtu raportu? 

Czy należy wówczas w formie tekstowej opisywać położenie przycisku na ekranie? 

Doświadczony analityk wie, że znacznie skuteczniej jest w wymaganiu umieścić prototyp ekranu pokazujący miejsce, gdzie taki przycisk zostanie umieszczony przez programistę.

Połączenie dwóch diagramów przez dwuklik

Niedawno otrzymałem od jednego z czytelników takie zapytanie:

Przeglądałem Pana stronę internetową na temat obsługi Enterprise Architecta, jednak nie znalazłem tam informacji na temat problemu, który próbuje rozwiązać od jakiegoś czasu, a mianowicie: czy istnieje możliwość połączenia dwóch diagramów, np. czynności poprzez dwuklik na jednym z elementów jednego, który kończąc jeden proces jest jednocześnie początkiem drugiego procesu. Byłbym bardzo wdzięczny za odpowiedz czy coś takiego jest możliwe a zarazem podpowiedz jak to zrobić.

Postanowiłem przygotować odpowiedź w postaci wpisu na blogu, gdyż może to być przydatna informacja również dla innych czytelników.

Jak uruchomić dwie wersje Enterprise Architect?

Jeśli instalujemy nowszą wersję programu Sparx Enterprise Architect jesteśmy informowani uprzejmie, że musimy odinstalować poprzednią wersję programu. Jeśli się zgodzimy, wówczas instalator wykona za nas automatycznie tę operację.

Jeśli jednak chcielibyśmy z jakichś powodów skorzystać z poprzedniej wersji programu, czy musimy każdorazowo odinstalowywać i instalować ponownie program?

Okazuje się, że na jednym komputerze mogą współistnieć dwie lub więcej wersji EA.

Mapowanie przypadku użycia

Opracowanie modelu użycia ma na celu udokumentowanie w fazie analizy szczegółowych wymagań dotyczących funkcjonalności budowanego rozwiązania. W tym celu definiowani są aktorzy, którzy wchodzą w interakcję z systemem oraz przypadki użycia, które opisują wykorzystywaną przez nich funkcjonalność.

Jednakże analiza systemów informatycznych oprócz modelu funkcjonalnego obejmuje również inne obszary, takie jak:

• zarządzanie wymaganiami,
• modelowanie procesów biznesowych,
• modelowanie danych (logiczny model danych / model domeny),
• modelowanie interfejsu użytkownika. 

Ponadto analiza nie może istnieć w oderwaniu od innych zadań projektowych, takich jak:

• zarządzanie zakresem projektu,
• zarządzanie ryzykiem,
• zarządzanie problemami,
• zarządzanie zmianą,
• projektowanie,
• implementacja,
• testy.

Częstą praktyką jest chociażby opracowywanie scenariuszy i przypadków testowych przez analityków, które są wykorzystywane przez testerów. Dzieje się tak, gdyż przypadki testowe bazują w głównej mierze na przypadkach użycia, a analityk zna je najlepiej.

Zatem, wskazane jest stworzenie i utrzymywanie określonych powiązań elementów modelu użycia z elementami innych obszarów.

Jak przenieść scenariusz do innego przypadku użycia?

W trakcie pracy nad modelem użycia często dochodzi do sytuacji, w której analityk dochodzi do wniosku, że określony scenariusz należy przenieść z jednego przypadku użycia do innego. Może tak się zdarzyć, gdy okazuje się, że scenariusz alternatywny powinien rozwidlać się jeszcze bardziej, czyli mieć jeszcze dodatkowe alternatywy.
Czasem istnieje również potrzeba stworzenia nowego przypadku użycia podobnego do już istniejącego, na przykład, gdy tworzymy kolejną specjalizację przypadku generalizującego.
Gdyby scenariusze pisane były w zwykłym dokumencie MS Word, wówczas przeniesienie czy skopiowanie kroków scenariusza byłoby banalne. Jednak jeśli zdecydowaliśmy się na zastosowanie ustrukturalizowanych scenariuszy (Structured scenario), wówczas staje się to problematyczne.
Na szczęście istnieje rozwiązanie...

Raport dla przypadków użycia

Z modelem przypadków użycia tworzonym przez analityków w programie Enterprise Architect powinno się zapoznać wielu interesariuszy projektu. Spośród nich można wymienić projektantów, programistów, ale przede wszystkim przedstawicieli klienta, takich jak kluczowi użytkownicy, eksperci dziedzinowi i inni. W związku z tym, jeśli decydujemy się na opisywanie scenariuszy przypadków użycia w formie Structured Scenario w EA - powinniśmy również zadbać o ich stronę dokumentacyjną.
Profesjonalnie przygotowany raport poprawia czytelność i odbiór wyników pracy fazy analizy.

Scenariusze przypadków użycia w EA

W Sparx Enterprise Architect od wersji 8.0 wprowadzono możliwość opisywania scenariuszy przypadków użycia w formie ustrukturalizowanej (Structured Scenario). Wcześniej scenariusz można było tworzyć tylko w postaci sformatowanego tekstu zawierającego ewentualnie listy numerowane. Od dawna możliwe było również opracowanie scenariusza w formie Linked Document dołączonego do elementu typu Use Case.
W tym artykule chciałbym przybliżyć możliwości wykorzystania mechanizmu Structured Scenario. Ten sposób posiada wiele zalet i warto się z nimi zapoznać.