Skąd się wzięły przypadki użycia?
Na swoim blogu Ivar Jacobson pisze o tym skąd się wziął pomysł na zapisywanie wymagań za pomocą przypadków użycia. Jacobson pisze:
"In 1986, Use Case was the solution to the problem that traditional functional specifications were immense and not testable. To start from the users and find their different use cases made the specifications understandable, while we also at the same time found the test cases. The result was a good way to do test-driven development, now being popular in agile teams."
Polecam zresztą cały najnowszy post Jacobsona, w którym pisze o tym, że problem jest ważniejszy niż samo rozwiązanie (o czym wspominałem wcześniej tutaj).
Darmowy webinar o tworzeniu modeli przypadków użycia
Na blogu Bridging the Gap możecie się zarejestrować na darmowy webinar dotyczący tworzenia modeli przypadków użycia. Webinar jest zaplanowany na wtorek 04. maja na godzinę 18:00 EST, co oznacza 01:00 naszego czasu (będzie to już środa), (więc jeśli ktoś cierpi na bezsenność to) może warto skorzystać?
5 x „C”
Firma IAG na swoim blogu proponuje zasadę pięciu "C", która pozwala zadbać o wysoką jakość wymagań. Oto one:
- Wyrażaj się jasno (be Clear)
- prowadź dyskusje w logiczny sposób
- używaj prostych słów
- unikaj eufemizmów
- używaj stwierdzeń pozytywnych
- sprawdzaj, czy każdy punkt jest wystarczająco jasny i kompletny (w izolacji od pozostałej treści)
- Bądź spójny (be Concise)
- twórz prostą specyfikację
- korzystaj w wypunktowań
- wykorzystuj słowa, których używasz na co dzień
- używaj raczej określeń szczegółowych niż wyrażeń ogólnych
- unikaj powtarzania treści
- Bądź konkretny (be Concrete)
- wykorzystuj przykłady oraz scenariusze
- unikaj jargonu
- miej zawsze jasne przesłanki
- miej zawsze jasno określony cel
- unikaj mylących złożonych stwierdzeń
- unikaj stwierdzeń negatywnych
- Bądź kompletny (be Complete)
- używaj list kontrolnych oraz technik walidacji
- dokumentuj wszystkie możliwe wyjątki, warunki oraz odpowiedzi
- szukaj opisów operacji bez jasno i w pełni określonych wyników
- szukaj opisów operacji bez określonych dla nich zdarzeń
- specyfikuj wszystkie elementy danych
- Bądź konsekwentny (be Consistent)
- nie używaj wielu określeń dla tej samej rzeczy
- korzystaj z tych samych stylów i czcionek w całym dokumencie
5 oznak, że powinieneś zostać analitykiem biznesowym
Na blogu Bridging the Gap można znaleźć post wskazujący 5 oznak, po których możesz stwierdzić, czy zawód analityka biznesowego jest właściwy dla Ciebie. Oto one:
- Lubisz spotkania. Potrafisz rozpoznać, kiedy ludzie zamiast rozmawiać ze sobą, jedynie mówią do siebie. Dodatkowo, potrafisz w takich momentach zareagować i poprowadzić rozmowę na właściwe tory.
- Lubisz pisać, w szczególności teksty wymagające precyzji, nie przeszkadza Ci spędzanie kilkugodzinnych sesji przed komputerem.
- Odnajdujesz słabe punkty w oprogramowaniu, z którym masz do czynienia i zastanawiasz się, co mogłoby zostać zrobione, aby to oprogramowanie było lepsze?
- Potrafisz dobrze sobie radzić z napiętymi sytuacjami i nie lubisz być w konflikcie z innymi osobami. Pomagasz ludziom uporać się z problemem podejmowania decyzji poprzez dostarczanie odpowiednich informacji.
- Lubisz pisać i rysować na tablicy. Serio! jest to konieczne, aby zaangażować pozostałe osoby związane z tworzeniem oprogramowania do wspólnej, twórczej pracy.
I co? Jak się widzicie w kontekście tych 5 punktów?
Witam!
Wymagania są podstawą dla każdego systemu informatycznego - czasem są one spisane w jakimś dokumencie, czasem są jedynie w głowach twórców systemu; czasem zajmują jedną stronę, czasem można by z nich złożyć drugą Trylogię Sienkiewicza; czasem od początku do końca pozostają bez zmian, a czasem nie nadążamy z ich zmianami. Brzmi znajomo? O tym właśnie ma być ten blog. Serdecznie zapraszam do czytania i komentowania!
Ruszajmy!
