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.
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.
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.
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.
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?
Kompletny SRS na wyciągnięcie ręki…i to za darmo!
W zeszłym roku zostaliśmy zaproszeni (jako zespół Inżynierii Oprogramowania na Politechnice Poznańskiej) do współpracy przez Wydział Informatyki Urzędu Miasta Poznania nad dokumentem zawierającym wskazówki dotyczące zbierania wymagań dla projektów informatycznych. Jednostki samorządowe objęte są przepisami dotyczącymi zamówień publicznych, dlatego też najczęściej muszą one same muszą zadbać o zebranie wymagań dla systemów informatycznych, wymagania te później są podstawą ogłoszonego przetargu na realizację systemu.
Efektem naszej współpracy są 3 dokumenty:
- wskazówki dotyczące dokumentowania wymagań dla systemów informatycznych
- przykładowa pełna specyfikacja wymagań dla systemu archiwizacji elektronicznej
- wzorzec dla dokumentu specyfikacji wymagań (na bazie standardu IEEE 830:1998)
Dzięki uprzejmości Wydziału Informatyki Urzędu Miasta Poznania wszystkie 3 dokumenty są publicznie dostępne. Zapraszam tutaj (znajdziecie tam archiwum zip ze wspomnianymi wcześniej dokumentami oraz dodatkowy dokument zawierający szczegóły dotyczące zasad rozpowszechniania naszego opracowania).
Mam nadzieję, że zarówno zebrane przez nas wskazówki jak i przykład pozwolą Wam jeszcze efektywniej zbierać wymagania w Waszych projektach. Jeśli będziecie korzystali z tych dokumentów to dajcie znać co o nich sądzicie i czy się Wam przydały. Jesteśmy bardzo ciekawi Waszych opinii!
Oczywiście jeśli jesteście zainteresowani współpracą nad podobnym projektem, lub macie jakikolwiek problem z wymaganiami w Waszych projektach to również dajcie koniecznie znać.
Trzeci rozdział „Requirements by Collaboration”
Trzeci rozdział książki "Requirements by Collaboration: Workshops for Defining Needs", którą obecnie czytam przynosi nam zbiór składników, które powinny być częścią każdego dobrego warsztatu wymagań. Oto one:
- Wspólny cel. Zadbaj, aby każdy z uczestników rozumiał cel każdego ze spotkań warsztatowych. Zawsze zaczynaj mając na względzie końcowy efekt, jaki chcesz osiągnąć poprzez spotkanie.
- Odpowiedni ludzie. Pamiętaj, aby w każdym spotkaniu brali udział przedstawiciele klienta, użytkowników końcowych oraz dostawcy oprogramowania. Każda z tych grup ma inną wiedzę, inne doświadczenia oraz inne cele. Jeśli uda Ci się zebrać ich razem i umożliwisz im efektywną współpracę, to każde spotkanie przyniesie wymierną wartość.
- Współdzielona przestrzeń. Zadbaj o to, żeby wszyscy uczestnicy warsztatów byli zebrani w tym samym pomieszczeniu podczas spotkań. Coraz więcej mówi się o zaletach rozproszonych zespołów, ale jeśli chcesz osiągnąć sukces podczas swoich spotkań, to fizyczna obecność wszystkich osób w jednym pokoju może zdecydowanie pomóc.
- Mądre grupy. Pamiętaj, że jako grupa jesteście w stanie wymyślić więcej niż każdy z was z osobna.
- Praca wstępna. Staraj się, żeby każdy z uczestników spotkania miał do zrobienia pewną pracę wstępną, którą będzie się mógł podzielić podczas spotkania. Dzięki temu przyspieszy to spotkanie i wymusi na każdym uczestniku odpowiednie przygotowanie się oraz przemyślenie celu spotkania.
- Dobre pytania. Odpowiednie pytania są kluczem do dobrej komunikacji podczas warsztatów. Pamiętaj o tym!
- "Poważna" gra. Jeśli jest to możliwe, to pozwól uczestnikom na "zabawę" podczas spotkań. Niech puszczą wodze wyobraźni, niech mimo powagi spotkania poczują się swobodnie.
- Zaufanie. Zaufanie jakim darzą się uczestnicy spotkania pozwala oszczędzić czas, zwiększa jakość oraz efektywność spotkań, a także pozwala szybciej podnieść się po ewentualnych porażkach lub chwilowych problemach.
- Zróżnicowanie procesów. Podczas spotkań staraj się korzystać z różnych technik aby podtrzymać innowacyjność oraz motywację grupy. Niech czasem pracują indywidualnie, czasem w parach, a czasem w małych grupach. Czasami ty zadawaj pytania, a czasem niech oni zastanowią się nad dobrymi pytaniami. Czasem niech coś tworzą, a czasem niech sprawdzają prace innych.
- Testowanie efektów końcowych. Zawsze musisz wiedzieć, kiedy osiągnąłeś zadowalające Cię efekty. Jeśli chcesz na przykład, żeby efektem były diagramy przypadków użycia, to musisz wiedzieć wcześniej jaki poziom szczegółowości Cię zadowoli i do takiego poziomu będziesz dążył podczas spotkania.
- Wspólne decyzje. Staraj się tak prowadzić spotkanie, aby decyzje podejmowała cała grupa, a nie jedynie osoby ze szczebla kierowniczego.
- Elastyczna struktura. Każde spotkanie powinno być odpowiednio przemyślane i zaplanowane, ale nigdy nie wiadomo co wydarzy się podczas warsztatu, więc musisz zawsze być przygotowany na ewentualne zmiany, które będzie trzeba wprowadzić.
- Korzystanie z obu półkul mózgowych. Jeśli uda Ci się pobudzić obie półkule mózgowe uczestników zespołu, to z pewnością takie spotkanie przyniesie lepsze efekty a także będzie bardziej satysfakcjonujące dla całej grupy.
- Częste omówienia. Staraj się w miarę często podsumowywać pracę. Niech uczestnicy sprawdzają siebie nawzajem, pozwól również na wzajemną konstruktywną krytykę.
Lista spraw otwartych
Często podczas pracy, a w szczególności podczas rozmów i spotkań z innymi osobami związanymi z projektem zdarza się, że jakiś pomysł wpada nam do głowy, albo też pojawia się pytanie lub wątpliwość, na wyjaśnienie których nie ma w danej chwili czasu. Co wówczas robimy? Najczęściej mówimy sobie "muszę później do tego wrócić", "później to przedyskutujemy". I co się dzieje? Najczęściej zupełnie o tym zapominamy! Aby uniknąć takich sytuacji, które mogą później przyprawić nas o niejeden ból głowy, warto jest dla każdego projektu prowadzić tzw. "listę spraw otwartych" (ang. issue list), w której będziemy na bieżąco zapisywać nasze pomysły, pytania i wątpliwości. Taką listę możemy umieścić na końcu naszego dokumentu specyfikacji wymagań, dzięki temu będzie ona dostępna dla potencjalnych czytelników. Bardzo ważne jest aby taką listę regularnie przeglądać! Na przykład raz w tygodniu, przed każdym spotkaniem z klientem, etc., pozwoli nam to znaleźć czas, żeby zająć się sprawami z listy.