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).
A najczęściej używana notacja to…
Patrząc przez ramię
Ile razy zastanawialiście się, w jaki sposób modelować Wasze wymagania? Która notacja będzie najlepsza? Który sposób modelowania powinienem\am wybrać? Ile razy zaglądaliście przez ramię koleżanki lub kolegi, żeby zobaczyć jak oni to robią? Czy nie fajnie by było spojrzeć przez ramię prawie 200 innych analityków i zobaczyć, z czego oni korzystają w swojej pracy z wymaganiami?
Ale jak to zrobić?
Na szczęście panowie Colin J. Neill oraz Phillip A. Laplante z Penn State University postanowili dowiedzieć się czegoś więcej na temat najczęściej stosowanych praktyk inżynierii wymagań. Stworzyli internetową ankietę, która składała się z 22 pytań i zaprosili do jej wypełnienia prawie 2000 osób (głównie absolwentów PennState University). Odpowiedzi udzieliły 194 osoby (m.in. z takich firm jak SAP, Boeing, Dupont, Simens Medical Systems) i odpowiedzi te były podstawą artykułu "Requirements Engineering: The State of the Practice", który ukazał się w 2003 roku.
A zwycięzcą jest...
Jako, że cały dokument jest dostępny tutaj, to nie będę rozwodził się nad poszczególnymi wnioskami, tylko przedstawię najciekawsze (moim zdaniem) wyniki, i tak:
- 60% osób biorących udział w ankiecie stosowało w jakimś stopniu prototypowanie.
- 35% respondentów powiedziało, że wykorzystują podejście kaskadowe.
- W projektach, które trwały dłużej niż dwa lata najpopularniejsze było podejście iteracyjne.
- 33% osób stwierdziło, że nie korzystają z żadnej metodologii
- 51% respondentów powiedziało, że stosują nieformalne sposoby zapisu wymagań, 27% sposoby półformalne, a 7% stosują notacje formalne.
- W 59% przypadków stosuje się inspekcje, jako sposób na podniesienie jakości wymagań.
- 52% osób stwierdziło, że w ich firmach za mało uwagi poświęca się na inżynierię wymagań.
- Ponad 50% osób wykorzystuje przypadki użycia i/lub scenariusze do zapisu wymagań.
Tak wyglądają wyniki badań po drugiej stronie oceanu, ciekaw jestem jak to wyglądałoby u nas? Bylibyście zainteresowani wzięciem udziału w takim badaniu? Dajcie znać w komentarzach lub mailowo.
Webinar Ellen Gottesdiener – „Success with Requirements…”
Pani Ellen Gottesdiener zaprasza na darmowy webinar pod tytułem "Success with Requirements - The Art and Science of Requirements Elicitation" na jutro na godzinę 18:00 naszego czasu. Tak dla przypomnienia Ellen Gottesdiener to ta pani, która napisała książkę "Requirements by Collaboration: Workshops for Defining Needs", o której trochę już wcześniej pisałem. Myślę, że jest to świetna szansa na spotkanie z panią Gottesdiener, na zdobycie nowej wiedzy i nowych doświadczeń. Żeby wziąć udział w spotkaniu trzeba się zarejestrować tutaj.
Śledzenie wymagań
We wpisie Jaki powinien być Twój SRS? napisałem, że jedną z cech poprawnego dokumentu wymagań jest "łatwość śledzenia (ang. traceability)". Nie dla wszystkich z Was może być jasne, o co w tym wyrażeniu chodzi, więc spieszę z wyjaśnieniem.
SRS jest łatwy do śledzenia jeśli pochodzenie każdego wymagania jest jasne i oraz jeśli dokument ułatwia odwoływanie się do poszczególnych wymagań podczas jego edycji. Trzeba pamiętać, o tym, że mamy:
- łatwość śledzenia wstecz - jasne wskazanie na źródło wymagania;
- łatwość śledzenia wprzód - każde wymaganie powinno mieć unikalną nazwę oraz identyfikator, aby łatwo można się było do niego odwołać.
W kontekście tego, dobrze jest przypomnieć sobie wpis nie podmieniaj!
Jaki powinien być Twój SRS?
Twój SRS powinien być (*):
- Poprawny
- Jednoznaczny
- Kompletny
- Spójny
- Uporządkowany według ważności i/lub stabilności wymagań
- Weryfikowalny
- Modyfikowalny
- Łatwy do śledzenia (ang. traceable) [zna ktoś może lepsze tłumaczenie?]
Czy możesz szczerze powiedzieć, że Twój ostatni SRS miał wszystkie powyższe cechy?
(*) Na podstawie standardu IEEE 830-1998.
Walidacja czy weryfikacja?
W kontekście sprawdzania jakości wymagań często mówi się o weryfikacji oraz o walidacji. Co oznaczają te dwa pojęcia? Znaczą one to samo, czy może coś innego?
Walidacja pozwala nam sprawdzić, czy oprogramowania jest zgodne z tym czego oczekuje klient; pozwala nam odpowiedzieć na pytanie "czy budujemy dobre oprogramowanie?".
Weryfikacja pozwala nam stwierdzić, czy budowane oprogramowanie zgodne jest z zebranymi przez nad wymaganiami; pozwala nam odpowiedzieć na pytanie "czy dobrze budujemy oprogramowanie?".
Jako przykład możemy wziąć sobie proste okienko logowania. W takim wypadku możemy wykorzystać weryfikację, aby sprawdzić, czy okienko przyjmuje dobre dane i czy wyświetla odpowiedni komunikat o błędzie. Walidacja natomiast każe nam się zastanowić, czy to okno logowania jest nam w ogóle potrzebne? czy spełnia ono jakiś konkretny cel klienta?
Jak pisać specyfikacje wymagań według IEEE?
W instrukcji tworzenia specyfikacji wymagań, o której pisałem kilka tygodni temu postanowiliśmy oprzeć strukturę specyfikacji na standardzie IEEE 830-1998. Standard ten opisuje dobre praktyki oraz sugeruje podejścia do specyfikowania wymagań oprogramowania, które mają pomóc zapisać wymagania w sposób kompletny oraz jednoznaczny. Standard za swój cel wyznacza sobie pomoc przy:
- Dokładnym opisie wymagań przez klientów.
- Pełnym zrozumieniu wymagań klientów przez dostawców oprogramowania.
- Definiowaniu standardowego formatu oraz zawartości dokumentu specyfikacji wymagań (SRS) w organizacji.
Według IEEE 830-1998 dobry SRS powinien:
- być podstawą umowy między klientem, a dostawcą oprogramowania na temat tego co tworzony system powinien robić;
- pomóc zredukować wysiłek wkładany w wytworzenie systemu;
- być podstawą dla estymacji kosztów oraz harmonogramu;
- dostarczać fundamenty dla walidacji oraz weryfikacji wymagań;
- ułatwiać transfer oprogramowania do nowych użytkowników;
- służyć jako podstawa dla dalszych rozszerzeń oprogramowania.
W kolejnych wpisach postaram się przybliżyć Wam dalsze wskazówki jakie można znaleźć w standardzie IEEE 830-1998. Jeśli jednak nie możecie się doczekać, żeby o nich przeczytać to zapraszam do lektury naszej instrukcji oraz przykładowej specyfikacji.
Requirements Interchange Format (RIF)
Podczas konferencji "Requirements Engineering 2009", o której pisałem w zeszłym tygodniu miałem okazję wysłuchać prezentacji na temat ciekawego formatu wymiany/przenoszenia wymagań. Format ten nazywany jest RIF (Requirements Interchange Format), powstał 2004 i od tamtego czasu jest aktywnie rozwijany i wykorzystywany, szczególnie przez firmy motoryzacyjne oraz medyczne. Skąd wzięła się potrzeba stworzenia takiego formatu? Okazuje się, że często firmy mają sporą liczbę podwykonawców, z których każdy dysponuje innymi narzędziami do zarządzania wymaganiami. Problemem jest tworzenie, przesyłanie oraz modyfikacja wymagań w takim środowisku. Stąd też pomysł na format, który bazowałby na XML'u i który pozwalałby w łatwy sposób przenosić wymagania między różnymi narzędziami, co pozwoliłoby zmniejszyć nakłady czasowego oraz finansowe na zarządzanie wymaganiami. Co ważne RIF'em zainteresowała się OMG, więc jest szansa, że wkrótce format ten stanie się standardem firmowanym właśnie przez OMG.
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ć?