Co oznacza jednoznaczność specyfikacji wymagań?
Kiedyś już rozważaliśmy, co standard IEEE 830 rozumie przez dobrze napisany SRS. Przeglądaliśmy również atrybuty dobrej specyfikacji wymagań według tego samego standardu, a nawet zastanawialiśmy się, czym jest "śledzenie" wymagań. Dzisiaj chciałbym pochylić się nad kolejnym atrybutem dobrego SRSa, nad jednoznacznością.
SRS jest jednoznaczny, jeśli każde opisane wymagania ma tylko jedną interpretację.
Atrybut ten jest o tyle istotny, że niejednoznacznie zapisane wymagania będą się na nas mściły od samego początku pracy nad oprogramowaniem, aż do samego końca. Niejednoznaczne wymagania spowodują, że klient może inaczej zrozumieć zapisane wymagania, inaczej zrozumie je architekt, jeszcze inaczej zaimplementują je programiści, a testerzy będą testować jeszcze coś innego. Problem jest o tyle ciężki do rozwiązania, że często pisząc wymagania nie zdajemy sobie sprawy, że coś może mieć więcej niż jedno znaczenie, dopiero zderzenie z innym punktem widzenia pomaga nam uzmysłowić sobie, że zapisane wymaganie można zinterpretować na kilka sposobów.
Niestety, jeśli używamy języka naturalnego do opisu wymagań, to skazujemy się automatycznie na niejednoznaczność, gdyż jest ona cechą charakterystyczną właśnie takiego podejścia.
Łatwiej zadbać o jednoznaczność korzystając z notacji przeznaczonych do opisu wymagań, które często w sposób automatyczny wskażą nam potencjalne problemy wieloznaczności. Niestety podejście to ma też swoje wady - wymaga ono poświęcenia czasu oraz wysiłku do nauki sprawnego posługiwania się daną notacją. W przypadku osób "technicznych" nie powinno stanowić to problemu, jednak dla naszego klienta może okazać się to barierą nie do przeskoczenia.
Możecie podzielić się swoimi "przygodami" wynikającymi z niejednoznaczności wymagań?
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.
Ś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.
Echa konferencji Requirements Engineering 2009
W zeszłym roku miałem szansę brać udział w jednej z najbardziej prestiżowych konferencji poświęconych inżīnierii wymagań Requirements Engineering. To właśnie podczas tej konferencji zdecydowałem się założyć tego bloga, którego jednym z celów miało być omówienie najciekawszych zagadnień omawianych tamtego wydarzenia. Minęło pół roku od powstania bloga, a ja jeszcze nie napisałem ani słowa na temat konferencj - czas to zmienić.
Zacznę może od pierwszej prezentacji zaproszonej, którą poprowadził pan Dave West z Forester Research. Prezentacja dotykała problemów zwinności oraz wymagań, a pan West dzielił się wynikami różnorodnych ankiet i badań jakie prowadzone są przez Forester Research. Oto kilka fragmentów z notatek, które udało mi się zrobić:
- 1298 profesjonalistów z dziedziny IT odpowiadało na pytanie która z istniejących metodologii jest najbliższa temu, co robicie w waszej firmie? 31% podejście zwinne (zbliżone do RUP); 21# model kaskadowy; 12% podejście zwinne.
- Na pytanie, jakie są doświadczenia firm z wykorzystaniem podejść zwinnych odpowiedzi były następujące: 38% określiło, że mają wykoształcone dojrzałe podejście do zwinności; 30,8% stwierdziło, że są w połowie wdrażania podejść zwinnych; 25% dopiero zaczęło wprowadzać metodyki zwinne; a 5% dopiero zaczyna oceniać zalety takich podejść.
- Dlaczego ludzie wybierają zwinne metodyki? 63% - bo dają możliwość wprowadzenia zmian podczas tworzenia projektów; 60% - pozwalają zwiększyć jakość projektów; 60% - dają możliwość częstszych wydań; 55% - pozwalają na większość przewidywalność wydań; 45% - zwiększają motywację członków zespołów.
- Główne problemy związane z wymaganiami to: wymagania szybko stają się nieaktualne; wymagania to zwykle długie dokumenty, których nikt nie chce czytać; wymagania opisują zwykle rozwiązanie, a nie problem; zbieranie i analiza wymagań zabierają zbyt dużo czasu. Dodatkowe utrudnienia sprawiają: brak czasu po stronie klienta; wiele osób zainteresowanych tworzonym system, które często reprezentują sprzeczne interesy; słabe umiejętności komunikacyjne po stronie zespołu wytwórczego.
- Analityk powinien: mieć możliwość samodzielnego podejmowania decyzji; znać dziedzinę biznesową; dobrze współpracować z zespołem programistów.
- 81 profesjonalistów powiedziało, jakie mechanizmy z inżynierii wymagań wykorzystują najczęściej: 82% specyfikuje wymagania funkcjonalne; 62% wykorzystuje przypadki użycia; 57% tworzy prototypy; 46% specyfikuje wymagania pozafunkcjonalne; 37 % wykorzystuje warsztaty; 17% wykorzystuje wiki.
- Głównym narzędziem ankietowanych 230 analityków jest MS Office.
- Zalecenia: specyfikuj tylko to co będzie zaimplementowane; dobrze dobieraj poziom szczegółowości, staraj się estymować pracochłonność na etapie zbierania wymagań; pozwól wymaganiom ewoluować razem z powstającą implementacją; ciągle dostosowuj wykorzystywane techniki do zmieniającej się sytuacji.
- Pamiętajcie o wykorzystywaniu narzędzi i modeli graficznych.
W przygotowaniu dalsze relacje z Requirements Engineering 2009.
7 sposobów na zapewnienie porażki Twojemu projektowi
Jeśli chcesz, żeby Twój projekt zakończył się porażką zadbaj o następujące sprawy:
- Nie poświęcaj zbytniej uwagi i za dużo czasu ma wymagania
- Nie ustalaj priorytetów wymagań
- Nie słuchaj swojego klienta
- Używaj niezrozumiałych słów
- Nie używaj różnych modeli do reprezentowania wymagań
- Nie zarządzaj w żaden sposób swoimi wymaganiami
- Organizuj wiele bezproduktywnych spotkań
Znacie jeszcze jakieś inne gotowe sposoby na zapewnienie porażki projektu?
15 pytań
Na blogu firmy IAG można znaleźć ciekawy post z piętnastoma pytaniami, które warto zadań podczas sesji zbierania wymagań. Oto one:
- Czy mógłbyś podać więcej szczegółów, tak abym mógł lepiej Cię zrozumieć? Dzięki temu uzyskami więcej danych oraz lepiej zrozumiemy punkt widzenia rozmówcy.
- Czy mógłbyś podzielić się ze mną swoim rozumieniem tego, o czym przed chwilą mówiliśmy? Unikniemy dzięki temu nieporozumień wynikających z błędnego rozumienia drugiej osoby.
- Czy mógłbyś pomóc mi i zaklasyfikować te punkty? Pomoże nam to zorganizować fakty dotyczące wybranego tematu.
- Czy moglibyśmy porównać to stwierdzenie do tego, o czym mówiliśmy wcześniej? Pozwoli nam to lepiej zrozumieć rozmówcę, a także odkryć podobieństwa oraz różnice w wymaganiach.
- Czy mógłbyś zdefiniować ten termin, abym mógł go lepiej zrozumieć? Pomoże nam to utworzyć słownik pojęć i ustanowić wspólny język.
- Czy mógłbyś opisać przykładową sytuację, w której miałoby to zastosowanie? Dzięki odpowiedzi na to pytane możemy odkryć procesy, scenariusze kierujące naszym oprogramowaniem oraz warunki, jakie musi ono spełniać.
- Czy możemy porozmawiać o ograniczeniach oraz konsekwencjach tego rozwiązania? Pozwoli nam to lepiej zrozumieć omawiane wymagania.
- Możesz mi wyjaśnić, jak doszedłeś do takiego wniosku? Wyjaśnimy dzięki temu stopień wspólnego zrozumienia tematu.
- Czy możesz mi podać przykład, w jaki miałoby to działać? Dzięki przykładom lepiej zrozumiemy wymagania.
- Co jeszcze? Żeby o niczym nie zapomnieć.
- Jak rozumiesz (...)? Aby sprawdzić, czy myślimy w taki sam sposób.
- Dobra uwaga! Czy możemy ją dodać do listy spraw otwartych? Pozwoli nam to wrócić do głównego wątku rozmowy.
- Innymi słowy chodzi o to (...), tak? W taki sposób sprawdzisz, czy wszystko dobrze zrozumiałeś.
- Czy moglibyśmy przejrzeć punkty, które do tej pory przerobiliśmy? Pozwoli nam podsumować dotychczasową rozmowę.
- W jaki sposób możemy zweryfikować, czy na pewno o to chodzi? Uzyskamy dzięki temu informację, o źródle wymagania i dowiemy się, czy na pewno ma ono sens.
Spróbujcie wykorzystać te i podobne pytania podczas swoich kolejnych spotkań z klientami. Jestem ciekawe efektów, które uzyskacie.