O wymaganiach Kilka słów o wymaganiach w projektach informatycznych

23wrz/100

Czy zadałeś sobie kiedyś te pytania?

"Dlaczego?", "Jak?", "Kiedy?", "Co?", "Gdzie?". "Kto?" - te pytania powinieneś zadać sobie w kontekście każdego wymagania, aby mieć większą pewność, że w pełni rozumiesz swoje wymagania. Oto przykłady pytań:

"Dlaczego?"

  • Dlaczego potrzebujemy tego wymagania / tej funkcji?
  • Dlaczego to wymagania jest takie ważne?
  • Dlaczego została wybrana taka forma wymagania? Czy istnieje inny sposób na rozwiązanie problemu?

"Jak?"

  • Jak ta funkcja będzie używana?
  • W jaki sposób możesz zapisać dane wymaganie w krokach?
  • W jaki sposób to wymagania spełnia potrzebę biznesową Twojego klienta?
  • Jaki jest sposób, aby stwierdzić, czy to wymaganie zostało zaimplementowane?
  • W jaki inny (lepszy) sposób moglibyśmy opisać to wymaganie?

"Kiedy?"

  • Kiedy ta funkcja będzie używana?
  • Kiedy ta funkcja się nie powiedzie?

"Co?"

  • Co ja wiem o tym wymaganiu?
  • Jakie założenia przyjąłem opisując to wymaganie?
  • Co ta funkcja ma robić?
  • Jaki jest efekt wykonania tej funkcji?
  • Co musi się wydarzyć po zakończeniu wykonywania tej funkcji?
  • Co musi się wydarzyć zanim ta funkcja będzie wykonana?
  • Co powinno się wydarzyć jeśli to wymagania \ funkcja \ krok się nie powiedzie?
  • Z czym to wymaganie jest powiązane?

"Gdzie?"

  • Gdzie użytkownik będzie miał dostęp do tej funkcji?
  • Gdzie będą widoczne rezultaty?

"Kto?"

  • Kto będzie używał tej funkcji?
  • Kto będzie wprowadzał dane wejściowe dla tej funkcji?
  • Kto otrzyma rezultat wykonania tej funkcji?
  • Kogo powinienem zapytać, jeśli nie do końca rozumiem to wymaganie?

Usiądź od czasu do czasu (a w szczególności przed spotkaniem z klientem) i zadaj sobie te pytania, pozwolą Ci one lepiej przygotować się do spotkania i mieć większość pewność, że to co zrobiłeś ma jakąś wartość.

26kwi/100

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.

23mar/102

5 x “C”

Firma IAG na swoim blogu proponuje zasadę pięciu "C", która pozwala zadbać o wysoką jakość wymagań. Oto one:

  1. Wyrażaj się jasno (be Clear)
    • prowadź dyskusje w logiczny sposób
    • używaj prostych słów
    • unikaj eufemizmów
    • używaj stwierdzeń pozytywnych
    • sprawdzaj, czy każdy punkt jest wystarczająco jasny i kompletny (w izolacji od pozostałej treści)
  2. Bądź spójny (be Concise)
    • twórz prostą specyfikację
    • korzystaj w wypunktowań
    • wykorzystuj słowa, których używasz na co dzień
    • używaj raczej określeń szczegółowych niż wyrażeń ogólnych
    • unikaj powtarzania treści
  3. Bądź konkretny (be Concrete)
    • wykorzystuj przykłady oraz scenariusze
    • unikaj jargonu
    • miej zawsze jasne przesłanki
    • miej zawsze jasno określony cel
    • unikaj mylących złożonych stwierdzeń
    • unikaj stwierdzeń negatywnych
  4. Bądź kompletny (be Complete)
    • używaj list kontrolnych oraz technik walidacji
    • dokumentuj wszystkie możliwe wyjątki, warunki oraz odpowiedzi
    • szukaj opisów operacji bez jasno i w pełni określonych wyników
    • szukaj opisów operacji bez określonych dla nich zdarzeń
    • specyfikuj wszystkie elementy danych
  5. Bądź konsekwentny (be Consistent)
    • nie używaj wielu określeń dla tej samej rzeczy
    • korzystaj z tych samych stylów i czcionek w całym dokumencie
22lut/100

15 pytań

Na blogu firmy IAG można znaleźć ciekawy post z piętnastoma pytaniami, które warto zadań podczas sesji zbierania wymagań. Oto one:

  1. Czy mógłbyś podać więcej szczegółów, tak abym mógł lepiej Cię zrozumieć? Dzięki temu uzyskami więcej danych oraz lepiej zrozumiemy punkt widzenia rozmówcy.
  2. Czy mógłbyś podzielić się ze mną swoim rozumieniem tego, o czym przed chwilą mówiliśmy? Unikniemy dzięki temu nieporozumień wynikających z błędnego rozumienia drugiej osoby.
  3. Czy mógłbyś pomóc mi i zaklasyfikować te punkty? Pomoże nam to zorganizować fakty dotyczące wybranego tematu.
  4. Czy moglibyśmy porównać to stwierdzenie do tego, o czym mówiliśmy wcześniej? Pozwoli nam to lepiej zrozumieć rozmówcę, a także odkryć podobieństwa oraz różnice w wymaganiach.
  5. Czy mógłbyś zdefiniować ten termin, abym mógł go lepiej zrozumieć? Pomoże nam to utworzyć słownik pojęć i ustanowić wspólny język.
  6. Czy mógłbyś opisać przykładową sytuację, w której miałoby to zastosowanie? Dzięki odpowiedzi na to pytane możemy odkryć procesy, scenariusze kierujące naszym oprogramowaniem oraz warunki, jakie musi ono spełniać.
  7. Czy możemy porozmawiać o ograniczeniach oraz konsekwencjach tego rozwiązania? Pozwoli nam to lepiej zrozumieć omawiane wymagania.
  8. Możesz mi wyjaśnić, jak doszedłeś do takiego wniosku? Wyjaśnimy dzięki temu stopień wspólnego zrozumienia tematu.
  9. Czy możesz mi podać przykład, w jaki miałoby to działać? Dzięki przykładom lepiej zrozumiemy wymagania.
  10. Co jeszcze? Żeby o niczym nie zapomnieć.
  11. Jak rozumiesz (...)? Aby sprawdzić, czy myślimy w taki sam sposób.
  12. Dobra uwaga! Czy możemy ją dodać do listy spraw otwartych? Pozwoli nam to wrócić do głównego wątku rozmowy.
  13. Innymi słowy chodzi o to (...), tak? W taki sposób sprawdzisz, czy wszystko dobrze zrozumiałeś.
  14. Czy moglibyśmy przejrzeć punkty, które do tej pory przerobiliśmy? Pozwoli nam podsumować dotychczasową rozmowę.
  15. W jaki sposób możemy zweryfikować, czy na pewno o to chodzi? Uzyskamy dzięki temu informację, o źródle wymagania i dowiemy się, czy na pewno ma ono sens.

Spróbujcie wykorzystać te i podobne pytania podczas swoich kolejnych spotkań z klientami. Jestem ciekawe efektów, które uzyskacie.

8lut/100

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.

16lis/093

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 wymyślone przez Ivara Jacobsona w latach 80-tych jako opis wymagań dla systemów stosowanych w branży komunikacyjnej. W latach 90-tych, gdy powstawały elementy 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:
- id pozwalające nam 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. co jeśli nasz klient chce kupić więcej niż jedną książkę?).
Jak mógłby taki przykładowy przypadek użycia wyglądać? Na przykład tak:
<przykład>
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ę, etc.
Poniżej znajdziecie nasz wcześniejszy przykład poszerzony o elementy dodatkowe:
<przykład>
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 of effective use cases" autorstwa ??? oraz "How to write effective use cases" pana A. Cockburne'a. W kolejnym wpisie postaram się opisać kilka aspektów jakości przypadków użycia, tak abyście mniej więcej wiedzieli na co zwracać uwagę, gdy będziecie wykorzystywali przypadki użycia do zapisu swoich wymagań.

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:

Prosty przypadek użycia

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ę utworzeniadatę ostatniej zmianywersję.

Poniżej znajdziecie nasz wcześniejszy przykład poszerzony o elementy dodatkowe:

Przypadek użycia z rozszerzonymi elementami

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".

Related Posts with Thumbnails
   
Zagłosuj na ten blog w konkursie na Blog Roku 2010!
Get Adobe Flash player