osobiście i bardzo subiektywnie uważam, że nawet jeśli dowolną kupę mało spójnego tekstu rozłożymy na wiersze i kolumny dowolnej ilości tabel (to się czasem nazywa czasem nadawaniem tekstowi struktury) to taki tekst nadal będzie mało spójny. Przypadki użycia jako tabelaryczna forma zapisu "user story" lub wymagań funkcjonalnych, nie uzyskają spójności poprzez sam fakt ich stabelaryzowania. Przypadki użycia zaś jako efekt analizy całości zachowań i świadomego wyboru części z nich to jest dopiero spójny i kompletny opis wymagań. Bo jak to ktoś powiedział: kompletna lista najładniejszych kobiet w danym mieście to nie lista spotkanych ładnych w ostatnim miesiącu a lista wybranych spośród wszystkich w tym mieście. Taka lista ma sens bo nie grozi nam to, ze następnego dnia w tym mieście spotkamy inna ładniejszą.
Jeżeli ktoś Ci przyniesie specyfikację przypadków użycia do systemu i nie będzie potrafił jednoznacznie odpowiedzieć na pytanie dlaczego jest ich akurat tyle a nie np. jeden mniej lub dwa więcej albo dlaczego akurat te a nie inne, to najprawdopodobniej znaczy to, że podczas wdrożenia na pewno "spotkasz kilka innych ładniejszych kobiet".
Tworzenie modelu procesów ma dwa zadania: weryfikacja spójności i kompletności opisu Zamawiającego oraz stworzenie podstawy do określenia zakresu projektu i wyspecyfikowania wymagań funkcjonalnych czyli tak zwanych przypadków użycia.
Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj "szczególnie klienta biznesowego". Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?
Tak więc, model biznesowy, udokumentowane procesy i role powinny być kluczowym wymaganiem jakie stawiać należy systemom IT. Powinny one wspierać model biznesowy i strategię firmy a nie być tylko nowym fajnym i wizerunkowym zasobem. Moim zdaniem wymagania na systemem powinny być oczekiwaniem wsparcia dla modelu biznesowego a nie tylko prostą listą kilku tysięcy funkcjonalności.
