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!
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.
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.
Nie podmieniaj!
Co ze spójnością?
Co z tym zrobić?
Nie podmieniaj!
Podpowiedzi
Grając zgodnie z zasadami
"Grając zgodnie z zasadami" - tak nazywa się jeden z rozdziałów w książce Karla Wiegers "Software Requirements"
Każda organizacja działa zgodnie z pewnym zestawem ustalonym wewnętrznie lub narzuconych z zewnątrz zasad, przepisów i standardów, np. organizacje bankowe muszą działać w ramach obowiązujących przepisów prawa bankowego. Gdy tworzymy oprogramowanie dla naszego klienta, to warto zastanowić się jakimi regułami kieruje się biznes klienta, tak aby nasze oprogramowanie było z nimi zgodne.
Typy reguł biznesowych
- fakty - proste stwierdzenia, które są zawsze prawdziwe dla biznesu. Często opisują one relacje między istotnymi obiektami biznesowymi. Inne reguły mogą odwoływać się w swoich definicjach do faktów. Same fakty rzadko przekładają się bezpośrednio na wymagania funkcjonalne, są natomiast często częścią modelu danych.
Przykłady:
Każdy kontener z materiałami chemicznymi ma indywidualny identyfikator.
Każde zamówienie musi mieć określoną cenę. - ograniczenia - jak sama nazwa wskazuje ograniczają akcje , które system lub użytkownik może wykonywać.
Przykłady:
Pożyczkobiorca, który ma mniej niż 18 lat musi mieć pisemną zgodę rodzica lub opiekuna prawnego.
Stały czytelnik może mieć maksymalnie 10 książek wypożyczonych.
Użytkownik ma dostęp do dokumentów pounych jedynie jeśli uzyskał certyfikat poufności w ciągu ostatnich 12 miesięcy.
Pracownicy załóg linii lotniczych muszą mieć zagwarantowany 14-godziny odpoczynek po każdym locie. - wyzwalacze - reguły, które pod wpływem określonych zdarzeń lub w określonych warunkach wywołują specyficzne akcje.
Przykłady:
Jeśli produkt straci ważność w ciągu najbliższych 30 dni powiadom osobę przypisaną do tego produktu.
Jeśli klient zamawia książki autora, który napisał kilka książek to zaproponuj pozostałe książki tego autora przez zakończeniem składania zamówienia przez klienta. - obliczenia - określają sposób w jaki wykonywane są określone operacje matematyczne lub algorytmy.
Przykłady:
Cena produktów jest obniżana o 10% jeśli zamówienie zawiera od 6 do 10 sztuk, o 20% gdy zamówienie zawiera od 11 do 20 sztuk, o 35% dla zamówienia z ponad 20-ma sztukami.
Droga między dwoma punktami ma być wyznaczana zgodnie z algorytmem Bellmana-Forda. - wnioski - określają nową wiedzę lub zmianę stanu obiektów biznesowych ma podstawie określonych warunków.
Przykłady:
Jeśli opłata nie zostanie wniesiona w ciągu 30 dni od określonej daty zapłaty to konto klienta staje się unieważnione.
Jeśli sprzedano więcej niż sto tysięcy płyt to ma ona status platynowej.
Jak zapisywać reguły biznesowe?
5 oznak, że powinieneś zostać analitykiem biznesowym
Na blogu Bridging the Gap można znaleźć post wskazujący 5 oznak, po których możesz stwierdzić, czy zawód analityka biznesowego jest właściwy dla Ciebie. Oto one:
- Lubisz spotkania. Potrafisz rozpoznać, kiedy ludzie zamiast rozmawiać ze sobą, jedynie mówią do siebie. Dodatkowo, potrafisz w takich momentach zareagować i poprowadzić rozmowę na właściwe tory.
- Lubisz pisać, w szczególności teksty wymagające precyzji, nie przeszkadza Ci spędzanie kilkugodzinnych sesji przed komputerem.
- Odnajdujesz słabe punkty w oprogramowaniu, z którym masz do czynienia i zastanawiasz się, co mogłoby zostać zrobione, aby to oprogramowanie było lepsze?
- Potrafisz dobrze sobie radzić z napiętymi sytuacjami i nie lubisz być w konflikcie z innymi osobami. Pomagasz ludziom uporać się z problemem podejmowania decyzji poprzez dostarczanie odpowiednich informacji.
- Lubisz pisać i rysować na tablicy. Serio! jest to konieczne, aby zaangażować pozostałe osoby związane z tworzeniem oprogramowania do wspólnej, twórczej pracy.
I co? Jak się widzicie w kontekście tych 5 punktów?