Niech się coś drukuje…
Zasłyszane w jednej z firm:
Programiści dostali specyfikację, w której jedno z wymagań było opisane szkicem ekranu z przyciskiem "Drukuj". Dociekliwy programista zaczął się zastanawiać, co ma przez to rozumieć? Drukowanie na drukarce? Drukowanie do pliku tekstowego? Może do PDF'a? Jakiś wzorzec ma być wybrany? I najważniejsze: co w zasadzie ma być wydrukowane? Na szczęście programista okazał się proaktywny, sięgnął po słuchawkę i zadzwonił do analityka odpowiedzialnego za to wymagania. Mniej więcej tak wyglądała ta rozmowa:
- Ja w sprawie wymagania ABC123.
- Słucham, w czym problem?
- Zastanawiam się, co, w jaki sposób i na czym ma być wydrukowane. Niestety z zapisanego wymagania to nie wynika.
- Hmmm...no niech się coś po prostu tam drukuje.
Czy tylko mi ręce opadają?
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ń?
Co musisz wiedzieć o planowaniu etapu zbierania wymagań?
Oto zbiór pięciu praktyk podanych przez firmę IAG, które pomogą Wam lepiej zaplanować zbieranie wymagań w Twoim kolejnym projekcie:
1. Zasoby projektu:
- Opisz wszystkich udziałowców projektu oraz uczestników procesu zbierania wymagań.
- Każdemu wymienionemu uczestnikowi przypis odpowiednią rolę oraz odpowiedzialność.
2. Strategia dla każdej czynności:
- Wskaż najlepsze podejście do każdej fazy zbierania wymagań.
- Wskaż narzędzia, z których będziesz korzystał.
- Zdefiniuj standardy oraz metryki z których będziesz korzystał.
3. Komunikacja:
- Opisz w jaki sposób będzie prowadzona komunikacja z wszystkimi uczestnikami projektu, w szczególności z klientem, architektem oraz kierownictwem projektu.
4. Plan pracy:
- Zdefiniuj szczegółowy plan pracy.
- Przygotuj się do dokumentowania czasu, jaki będzie wykorzystywany w czasie sesji zbierania wymagań (może się przydać, gdy będziesz przeprowadzał takie spotkania w kolejnych projektach).
5. Strategia podziału pracy:
- Zdefiniuj i opisz podejście do podziału pracy oraz przydziału zadań do poszczególnych osób w przypadku, gdy więcej niż jeden analityk bierze udział w projekcie.
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!
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.
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ć?
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.