Skąd się wzięły przypadki użycia?
Na swoim blogu Ivar Jacobson pisze o tym skąd się wziął pomysł na zapisywanie wymagań za pomocą przypadków użycia. Jacobson pisze:
"In 1986, Use Case was the solution to the problem that traditional functional specifications were immense and not testable. To start from the users and find their different use cases made the specifications understandable, while we also at the same time found the test cases. The result was a good way to do test-driven development, now being popular in agile teams."
Polecam zresztą cały najnowszy post Jacobsona, w którym pisze o tym, że problem jest ważniejszy niż samo rozwiązanie (o czym wspominałem wcześniej tutaj).
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.
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.
Benchmark dla przypadków użycia
Które przypadki użycia wybrać do badań?
W naszym zespole zajmującym się Inżynierią Oprogramowania na Politechnice Poznańskiej skupiamy naszą uwagę w dużej mierze na analizie przypadków użycia. W ramach naszych prac tworzymy metody oraz narzędzia pozwalające analizować wymagania z różnych punktów widzenia. W pewnym momencie pojawił się problem: na jakich danych powinniśmy testować nasze metody i narzędzia? Wiadomo, że jeśli będziemy testować na danych spreparowanych przez nas to wyniki będą niemiarodajne. Moglibyśmy wziąć też pod uwagę specyfikacje stworzone w rzeczywistych projektach.Powstaje wówczas jednak pytanie: które specyfikacje powinniśmy wybrać? Doszliśmy więc do wniosku, dlaczego by nie przeanalizować dostępnych nam przypadków użycia i nie stworzyć pewnego rodzaju specyfikacji referencyjnej, która jak najwierniej odzwierciedlałaby rzeczywisty świat wymagań zapisanych w postaci przypadków użycia?
Benchmark 1.0
Aby stworzyć taki swoisty benchmark dla narzędzi badających przypadki użycia przeanalizowaliśmy 432 przypadki użycia z 11 dostępnych nam specyfikacji wymagań. Cześć naszej analizy możecie znaleźć tutaj (resztą wyników mogę udostępnić zainteresowanym osobom, w takiej sytuacji proszę o kontakt). Samą specyfikację, która powstała w wyniku tych prac znajdziecie tutaj. Jak powstał nasz benchmark? Każdy z przypadków użycia był przez nas badany m.in. pod kątem liczby kroków, liczby warunków początkowych, liczby kroków wykonywanych przez budowany system, itp. Następnie po takiej analizie zebraliśmy wyniki ze wszystkich projektów, co pozwoliło nam stworzyć obraz "przeciętnej" specyfikacji wymagań. Na tej podstawie stworzyliśmy przykładową specyfikację zachowującą właściwości specyfikacji "przeciętnej".
Benchmark 2.0
Po kilku miesiącach postanowiliśmy rozszerzyć naszą analizę o 5 kolejnych projektów (524 przypadki użycia łącznie), dodaliśmy również drugi wymiar do naszych badań. Za pierwszym razem wzięliśmy pod uwagę jedynie charakterstki ilościowe (liczba kroków, liczba rozszerzeń, etc.), tym razem dodatkowo analizowaliśmy różnież charakterystyki jakościowe (czy w każdym kroku jest wskazany aktor? czy używana jest czynna forma czasownika? etc.) i w ten sposób powstały dwie wersje referencyjnej specyfikacji: jedna zawierająca wyłącznie wyniki analizy ilościowej oraz druga zawierająca zarówno wyniki analizy ilościowej jak i jakościowej. Częściowe wyniki analiz możecie znaleźć tutaj, po resztę trzeba niestety poczekać dopóki nasz artykuł nie zostanie opublikowany. Benchmark w wersji ilościowej znajdziecie tutaj, a ten z dodatkową analizą jakościową tutaj.
Chcesz nam pomóc?
A może miałbyś ochotę podzielić się z nami swoimi przypadkami użycia? Jakość naszej pracy badawczej w dużej mierze zależy od tego na jakich danych operujemy. Czym więcej mamy danych rzeczywistych tym bardziej dopasowane metody i narzędzia możemy tworzyć. Zatem jeśli masz możliwość podzielenia się z nami wymaganiami ze swoich projektów to śmiało napisz do mnie maila! Oczywiście gwarantujemy pełną poufność danych, a jeśli trzeba to możemy również podpisać odpowiednie umowy.
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.
Które elementy dokumentu wymagań mają największy wpływ na projekt?
Z perspektywy analityka wydaje się oczywistością, że wymagania odgrywają ważną (jeśli nie najważniejszą!) rolę podczas wytwarzania oprogramowania. Niestety pozostałe osoby zaangażowane w proces tworzenia produktów informatycznych mają takie samo podejście i często hołdują zasadzie "nie uwierzę dopóki nie zobaczę".
Opis badania
Twójka naukowców japońskich Mayumi Itakura Kamata oraz Tetsuo Tamai postanowiło przebadać 32 projekty realizowane w ciągu 3 lat (2003 - 2005) w jednym z japońskich oddziałów pewnej międzynarodowej firmy (nazwa firmy nie pada, ale jako iż Mayumi Itakura Kamata pracuje dla IBM'a, to można się domyśleć, że to właśnie o tę firmę chodzi). W każdym z badanych projektów niezależny i doświadczony zespół zapewnienia jakości oceniał projekt (wraz ze wszystkimi powstałymi artefaktami, wliczając w to wymagania), a w zasadzie jego 100 aspektów w skali od 0 do 5. Każdy projektów został również oceniony pod względem zmieszczenia się w przeznaczonym czasie oraz budżecie. O projektach wiemy również, że wszystkie były tworzone na potrzeby zewnętrznych klientów, były to projekty średniej i dużej wielkości. Powyższe dane stanowiły podstawę do analizy tego, które czynniki jakości wymagań wpływają najbardziej na problemy w projektach.
Wnioski
Jakie wnioski wyniesiono z przeprowadzonej analizy? Otóż:
- Istnieje związek między jakością dokumentu wymagań (SRS - Software Requirements Specification), a końcowym sukcesem projektu, jednak nie wszystkie elementy SRS'a są tak samo ważne.
- Gdy wszystkie elementy SRSa są opisane na podobnym poziomie szczegółowości, to projekt ma duże szanse na sukces końcowy.
- Ogólny opis wizji systemu oraz jego celu ma znaczny wpływ na produkt końcowy, w szczególności projekty z dobrym opisem misji projektu zwykle kończą się na czas.
- Projekty ze słabym opisem celu projektu, a z obszernym opisem samej funkcjonalności potrafią często kończyć się przekroczeniem budżetu.
- Wyznaczenie wymagań, które mogą się zmienić w późniejszym czasie jest dobrą praktyką uniknięcia dodatkowych kosztów.
Jak widać, powyższe wnioski dość jasno określają, że wymagania, a w szczególności jasne określenie wizji i celu projektu może znacznie wpłynąć na końcowy sukces naszych prac. Pamiętajmy o tym tworząc naszą najbliższą specyfikację wymagań. Może niech to będzie nasze postanowienia na rok 2010?
Artykuł, na którym bazowałem to"How Does Requirements Quality Relate to Project Success or Failure? " autorstwa Mayumi Itakura Kamata oraz Tetsuo Tamai i był on prezentowany na konferencji Requirements Engineering w 2007 roku.
Przypadki użycia
Historia powstania przypadków użycia
Ostatnio zastanawialiśmy się, w jaki sposób można zapisać wymagania. Jednym z nieformalnych sposobów są przypadki użycia. Zostały one zaproponowane przez Ivara Jacobsona w latach 80-tych jako opis wymagań dla systemów stosowanych w branży telekomunikacyjnej. W latach 90-tych, gdy powstawały fundamenty notacji UML postanowiono włączyć pana Jacobsona do grona twórców UMLa i w ten sposób przypadki użycia znalazły swoje miejsce jako element tej właśnie notacji. Z jednej strony pozwoliło to przypadkom użycia zyskać na popularności i stać się jednym z popularniejszych sposobów zapisu wymagań (badania pokazują, że przypadki użycia i zapis scenariuszy jest wykorzystywany w ponad 50% projektów). Z drugiej strony jednak UML spowodował, że przypadki użycia zaczęły być kojarzone wyłącznie z diagramami, na których specyfikuje się aktorów oraz funkcje do jakich mają oni dostęp. Oczywiście diagramy są ważne, pozwalają one ogarnąć ogólną wizję funkcjonalności oraz zależności między przypadkami użycia. Przypadki użycia to jednak dużo więcej niż same diagramy - ich istotą są scenariusze interakcji między aktorami systemu.
Podstawowe elementy przypadków użycia
Tak jak wspomniałem powyżej głównym elementem przypadków użycia są scenariusze interakcji (zwane równieżscenariuszami głównymi), gdyż to one niosą za sobą największą wartość jeśli chodzi o wymagania. Co jeszcze w takim razie składa się na przypadek użycia? W podstawowej wersji poza scenariuszem podajemy:
- identyfikator pozwalający w jednoznaczny sposób odwoływać się do przypadku użycia,
- nazwę określającą czego dotyczy dany przypadek użycia,
- aktorów biorących udział w interakcji
- opis wyjątków oraz rozszerzeń dla scenariusza interakcji.
Z czego wynika ten ostatni element? Otóż w głównym scenariuszy podajemy pozytywny przebieg interakcji, czyli np. jeśli opisujemy zakup książki w sklepie internetowym to scenariusz główny kończy się zakupem książki (jest to tzw. "happy day scenario"). Co z przypadkami, gdy np. książki nie ma w naszym sklepie? Właśnie do takich sytuacji wykorzystywana jest sekcje wyjątków i rozszerzeń, w których możemy opisać sytuacje wyjątkowe (np. błędnie podane hasło przez użytkownika, błąd przy nawiązaniu połączenia zdalnego, itp.) oraz rozszerzenia naszego scenariusza głównego (np. gdy książki akurat nie ma w naszym sklepie, lub gdy nasz klient chce kupić więcej niż jedną książkę?).
Poniżej znajdziecie przykład przypadku użycia z wymienionymi wcześniej elementami:
Rozszerzony przypadek użycia
Poza podstawowymi elementami w przypadku użycia można zawszeń:
- wyzwalacze (ang. trigger) opisujące jakie zdarzenie może wywołać dany przypadek użycia
- warunki początkowe (ang. preconditions) określające jakie warunki muszą być spełnione, aby przypadek użycia mógł zostać wykonany
- warunki końcowe (ang. postconditions) mówiące o tym jakie warunki muszą być spełnione na końcu poprawnego wykonania przypadku użycia
- opis prezentujący skróconą wersję przypadku użycia
- wymagania dodatkowe określające wymagania, które nie zostały zawarte w scenariuszach, a są w jakiś sposób powiązane z przypadkiem użycia
- szkice ekranów prezentujące przykładowy wygląd systemu w danym kroku
- poza tym nazwisko autora przypadku użycia, datę utworzenia, datę ostatniej zmiany, wersję.
Poniżej znajdziecie nasz wcześniejszy przykład poszerzony o elementy dodatkowe:
Dlaczego przypadki użycia są fajne?
Jak widzimy przypadki użycia pisane są w języku naturalnym, co powoduje, że czytelnik nie potrzebuje specjalistycznej wiedzy, aby taki przypadek użycia zrozumieć. Dodatkowo z góry określona struktura ułatwia czytanie, gdyż każde wymagania zapisane jest w taki sam sposób. Pisanie takich przypadków również jest proste - każdy element wymagania ma swoje określone miejsce, więc dość prosto jest skupić się na każdym elemencie i opisać go osobno.
Czy to naprawdę jest takie proste?
Patrząc na powyższe przykłady może się wydawać, że w pisaniu przypadków użycia nie ma nic trudnego, gdyż korzystamy tutaj z języka naturalnego, który z łatwością pozwala nam wyrażań nasze myśli. Okazuje się, że z przypadkami użycia związana są pewne pułapki, o których należy pamiętać zapisując wymagania właśnie w taki sposób. Różne "zasadzki" oraz dobre praktyki opisane są m.in. w książkach pt. "Patterns for effective use cases" oraz "Writing effective use cases".
Jak zapisywać wymagania?
Skoro badania (np te lub te) pokazują, że wymagania sprawiają kłopoty, to powstaje naturalne pytanie w jaki sposób zapisywać wymagania tak aby miały one jak największą wartość? Pierwszym pytaniem jakie powinniśmy sobie zadań przy wyborze sposobu zapisu wymagań jest "kim jest nasz klient?". Dlaczego takie pytanie? To klient właśnie będzie specyfikował wymagania i to on musi je zatwierdzić. Innym klientem będzie kierownik apteki z wykształcenia farmaceuta, dla którego będziemy pisali stosunkowo prosty system do zarządzania zamówieniami leków, a innym inżynier lotów kosmicznych w NASA, dla którego będziemy pisali system kontroli dla najnowszego wahadłowca. Jakie różnice między tymi klientami są dla nas najważniejsze? Po pierwsze każdy z nich ma inny poziom wiedzy technicznej - aptekarz jest w stanie zrozumień język naturalny i zapewne po krótkim wprowadzeniu również podstawowe diagramy, natomiast notacje formalne (często matematyczne) mogą być dla niego zbyt trudne; inżynier z NASA natomiast bez trudu powinien poradzić sobie z notacjami formalnymi, jest to zapewne dla niego "chleb powszedni". Po drugie każdy z tych klientów ma inny poziom oczekiwań co do budowanego systemu - inżynier NASA oczekuje systemu o najwyższym stopniu precyzji, dokładności oraz niezawodności, dlatego trzeba się zastanowić nad sposobem zapisu wymagań, który pozwoli nam to zapewnić; aptekarz z kolei może nam pozwolić na większy margines dokładności. Musimy zatem zawsze zastanowić się dla kogo będziemy pisali oprogramowanie oraz jak krytyczny nasz system będzie. W przypadku mniej technicznych klientów i niekrytycznych systemów możemy pozwolić sobie na notację opartą na języku naturalnym, natomiast gdy mamy do stworzenia system o krytycznym znaczeniu wówczas warto zastanowić się nad notacją formalnych lub semi-formalnych, gdyż notacje te pozwalają nam na matematyczną weryfikację kompletności oraz poprawności wymagań.