diff --git a/use-case-2.md b/use-case-2.md
index 6e43cc5..0eae598 100644
--- a/use-case-2.md
+++ b/use-case-2.md
@@ -1,94 +1,63 @@
 Use Case 2: Kucharz skończył zamówienie
 =====================
 
-**Aktor podstawowy:** <!-- np. Klient -->
+**Aktor podstawowy:** Kucharz
 
 
 Główni odbiorcy i oczekiwania względem systemu:
 -----------------------------------------------
 
- - Odbiorca1: oczekiwania ...
-
- - Odbiorca2: oczekiwania ...
-
- - Odbiorca3: oczekiwania ...
+ - Kucharz: Wygodny i intuicyjny sposób zmiany stanu zamówień
 
 Warunki wstępne:
 ----------------
 
-...
+Zamówienie, które kucharz zakończył miało status "W trakcie realizacji"
 
 Warunki końcowe:
 ----------------
 
-...
+Zamówienie ma ustawiony status "Ukończone"
 
 Scenariusz główny (ścieżka podstawowa):
 ---------------------------------------
 
- 1. Krok 1 scenariusza głównego. <!-- np. 1. Klient wkłada kartę do bankomatu. -->
- 2. Krok 2 scenariusza głównego. <!-- np. 2. System prosi o podanie pinu. -->
- 3. Krok 3 scenariusza głównego. <!-- np. 3. Klient wprowadza pin.) -->
- 4. ....
+ 1. Kucharz zmienia status zamówienia, które jest w stanie "W trakcie realizacji" na status "Ukończone"
+ 2. System odpowiednio zmieni status zamówienia, z “W trakcie realizacji” na “Ukończone”
 
 Rozszerzenia (ścieżki alternatywne):
 ------------------------------------
 
- *a. nazwa rozszerzenia <!-- rozszerzenie *a może wystąpić w dowolnym kroku -->
+ *a. System ulega awari
 
-   1. krok pierwszy rozszerzenia *a
-   2. krok drugi rozszerzenia *a
+  1. Kucharz resetuje system
+  2. System ponownie wczytuje zamówienia, ich statusy i je wyświetCzla
 
- 3a. nazwa rozszerzenia <!-- np. 3a. Nieprawidłowy pin -->
+ *1a. Kucharz zmienia status nie tego zamówienia, które rzeczywiście ukończył
 
-   1. krok pierwszy rozszerzenia 3a
-   2. krok drugi rozszerzenia 3a
+  1. Kucharz zmienia status zamówienia wybranego przez pomyłkę, z powrotem na status “W trakcie realizacji” (**Czy robić osobną ścieżkę alternatywną, gdy przez przypadek zmieniono status zamówienia, które było w stanie "Do realizacji?, a może osobny Use Case na "Kucharz omyłkowo zmienił status nie tego zamowienia, które chciał"**)
+  2. System odpowiednio zmieni status wybranego zamówienia, z “Ukończone” na “W trakcie realizacji”
+  3. Kucharz wybiera zamówienie, aby status wybranego zadania zmienił się z “W trakcie realizacji” na “Ukończone”
+  4. System odpowiednio zmieni status wybranego zamówienia, z “W trakcie realizacji” na “Ukończone”
 
-     2a. nazwa scenariusza alternatywnego dla kroku 2 rozszerzenia 3a
+ *1b. Kucharz nie pamięta, który status został zmieniony przez pomyłkę
 
-       1. Krok pierwszy.
-       2. Krok drugi.
-       3. ...
+  1. Kucharz wybiera opcję “cofnij”, aby cofnąć ostatnią modyfikację statusu zamówienia
 
-     2b. nazwa scenariusza alternatywnego dla kroku 2 rozszerzenia 3a
+  2. System odpowiednio zmieni status ostatniego modyfikowanego zamówienia, na status poprzedni
 
-       1. Krok pierwszy.
-       2. ...
 
-   3. krok trzeci rozszerzenia 3a
-   4. krok czwarty rozszerzenia 3a
-
- 3b. nazwa rozszerzenia
-
-   1. krok pierwszy rozszerzenia 3b
-   2. krok drugi rozszerzenia 3b
-   3. ...
-
- 3-4a. nazwa rozszerzenia <!-- rozszerzenia 3-4a. może wystąpić w kroku 3 lub 4 -->
 
 Wymagania specjalne:
 --------------------
 
- - ... <!--np. Interfejs użytkownika musi być dostępny w języku polskim i angielskim. -->
-
- - ...
-
- - ...
+ - a* Wymagany ekran dotykowy
 
 Wymagania technologiczne oraz ograniczenia na wprowadzane dane:
 ---------------------------------------------------------------
 
- 2a. ...
-
- 2b. ...
-
- 3a. ... <!-- np. 3a. Pin składa się z 4 cyfr. -->
 
 Kwestie otwarte:
 ----------------
 
- - ... <!-- np. Czy dopuszczamy autoryzację z wykorzystaniem rozpoznawania twarzy?-->
-
- - ...
-
- - ...
+ - Przypisywanie realizowanych zamówień pod konkretnych kucharzy