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ń?
Ś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.
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.
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.
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ć.
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.
10 potencjalnych problemów z przypadkami użycia
Mimo iż przypadki użycia są najpopularniejszą notacją do zapisu wymagań funkcjonalnych, to nie oznacza to, że nie niosą one za sobą różnych pułapek. Pani Susan Lilly w swoim artykule "Use Case Pitfalls: Top 10 Problems from Real Projects Using Use Cases" opisuje 10 potencjalnych problemów, które mogą pojawić się, gdy korzystamy z przypadków użycia, oto one:
- Zakres systemu jest niezdefiniowany lub niespójny. Często wykorzystujemy przypadki użycia do zapisu wymagań na różnych poziomach (biznesowym, użytkownika, systemowym), pozwala to na opis z różnym poziomem szczegółowości. Problem pojawia się jednak, gdy na diagramach przypadków użycia zaczynamy mieszać ze sobą przypadki użycia z różnych poziomów - prowadzi to do niejasności i może spowodować kłopoty ze zrozumieniem wymagań przez osoby zaangażowane w projekt.
- Przypadki użycia zapisane są z punktu widzenia systemu, a nie z punktu widzenia użytkownika. Jako informatyce często zdarza nam się opisywać wymagania w kontekście tego, co system powinien robić, przypadki użycia jednak służą innym celom, ich zadaniem jest opisać intencje użytkowników. Dlatego też zawsze pisząc przypadki użycia staraj się skupić na tym, co chce osiągnąć użytkownik, a nie na tym, co system będzie robił, aby umożliwić realizację celu użytkownika.
- Nazwy aktorów są niespójne. Często wykorzystujemy różne nazwy dla aktorów pełniących te same role, lub też wykorzystujemy te same albo podobne nazwy dla opisu różnych ról. Aby unikąć tego problemu należy na samym początku prac zastanowić się jakich aktorów możemy wyróżnić w naszym systemie, nadać im unikalne identyfikatory, nazwy oraz opis.
- Zbyt dużo przypadków użycia. Duża liczba przypadków użycia może spowodować trudności w czytaniu SRSa, trudności w zrozumieniu i kłopoty w komunikacji. Staraj się zapewniać odpowiednią granularność przypadków użycia. Zastanów się, czy jakichś przypadków użycia nie możesz połączyć ze sobą? Usuń przypadki użycia, które nie wnoszą dodatkowej wartości do opisu wymagań.
- Relacje aktor-przypadek użycia przypominają pajęczą sieć. Jeśli na diagramach połączeń między aktorami i przypadkami użycia jest bardzo dużo, to powinno dać nam to do myślenia. Może aktorzy zdefiniowani są zbyt szeroko? Czy można wyodrębnić bardziej szczegółowych aktorów? A może masz zbyt wielu aktorów i wyodrębnienie nadrzędnego aktora uprościło by diagram?
- Specyfikacja jest za długa. Sprawa wygląda podobnie jak w punkcie 4-tym. Zastanów się, czy niektórych wymagań nie możesz połączyć ze sobą? Pamiętaj oczywiście, że czytelność i jednoznaczność jest naszym nadrzędnym celem, więc jeśli skrócenie specyfikacji miałoby wpłynąć na któryś z tych elementów to lepiej nie wprowadzaj takich zmian.
- Specyfikacja jest myląca i niejasna. Możliwe, że Twoim przypadkom użycia brakuje kontekstu? Zastanów się, czy określiłeś zakres wymagań i cel projektu? Może warto jest dodać sekcję wyzwalaczy i krótki opis do każdego przypadku użycia? Może Twoje przypadki użycia przypominają program komputerowy? Pamiętaj o stosowaniu dobrych praktyk, które pozwolą Ci uniknąć niektórych pułapek.
- Przypadki użycia niewłaściwie określają możliwości użytkowników. Czasem może się zdarzyć, że połączenia między aktorami a przypadkami użycia będą niepoprawnie wskazywać, jaką akcję może wykonywać poszczególny aktor. Zastanów się zawsze, czy dany aktor jest w pełni uprawniony do wykonania danego przypadku użycia? Jeśli móże wykonać go tylko w części, to może należałoby odpowiednio podzielić taki przypadek użycia na mniejsze bardziej szczegółowe części?
- Klient nie rozumie przypadków użycia. Zdarza Ci się zapomnieć, że klient może nie znać przypadków użycia? Zastanów się, co taki klient może zrozumieć ze specyfikacji, jeśli dostanie w niej zestaw przypadków użycia właśnie? Pamiętaj, aby zawsze przed rozpoczęciem pracy z klientem zapoznać go z notacją przypadków użycia, wytłumacz dlaczego przypadki użycia będą dobre dla wymagań jego systemu i w jaki sposób powinien je czytać. Może napisz razem z klientem kilka pierwszych przypadków użycia i spokojnie wytłumacz mu wszystkie niejasności?
- Przypadki użycia nie są nigdy skończone. Jeśli Twoje przypadki użycia są pisane na podstawie (lub chociaż z zamysłem) interfejsu użytkownika, to za każdym razem, gdy będziesz zmieniał interfejs prawdopodobnie będziesz też musiał zmienić przypadki użycia. Staraj się unikać szczegółów interfejsu użytkownika w swoich przypadkach użycia. Pamiętaj też o odpowiedniej analizie przypadków użycia - najpier zidentyfikuj procesy biznesowe, a później wszystkie przypadki użycia poziomu użytkownika. Zastanów się i zapisz scenariusze główne, a na końcu dodać rozszerzenia, scenariusze alternatywne i wyjątki - pozwoli Ci to lepiej zapanować nad całą specyfikacją i nie będziesz musiał tak często wprowadzać zmian.