<\/p>\n
W jednym ze wcze\u015bniejszych wpis\u00f3w<\/a> 1<\/a><\/sup>, przedstawi\u0142em moje uwagi dt. przypadk\u00f3w u\u017cycia. Na ko\u0144cu obieca\u0142em, \u017ce dodam jeszcze troch\u0119 praktycznych przyk\u0142ad\u00f3w. I w\u0142a\u015bnie tym chcia\u0142bym si\u0119 dzi\u015b zaj\u0105\u0107. Chcia\u0142em, aby przedstawione przyk\u0142ady by\u0142y „wzi\u0119te z \u017cycia”, dlatego s\u0105 oparte na pewnym projekcie, kt\u00f3ry realizowa\u0142em. Przedstawi\u0119 w skr\u00f3cie problem, tak aby mo\u017cna by\u0142o uchwyci\u0107 o co w nim chodzi, a jednocze\u015bnie opis nie by\u0142 zbyt anga\u017cuj\u0105cy. W oparciu o te informacje, przeprowadz\u0119 skr\u00f3con\u0105 wersj\u0119 analizy wymaga\u0144, efektem kt\u00f3rej b\u0119dzie przypadek u\u017cycia, zapisany w formie szkicu2<\/a><\/sup><\/p>\n Analiza b\u0119dzie opiera\u0107 si\u0119 na przyk\u0142adzie projektu budowy systemu sprzeda\u017cy B2B. Kr\u00f3tki opis zagadnienia:<\/p>\n Pewna sp\u00f3\u0142ka planuje prowadzenie sprzeda\u017cy B2B online w bran\u017cy, w kt\u00f3rej do tej pory nie istnia\u0142 podobny system. Klientami s\u0105 przedsi\u0119biorstwa produkcyjne, g\u0142\u00f3wnym przedmiotem sprzeda\u017cy jest rodzaj materia\u0142\u00f3w wykorzystywanych w cyklu produkcyjnym. Materia\u0142y maj\u0105 r\u00f3\u017cn\u0105 charakterystyk\u0119 (w\u0142a\u015bciwo\u015bci) istotne przy wyborze konkretnego produktu, mo\u017cna okre\u015bli\u0107 tak\u017ce powi\u0105zanie produkt\u00f3w w grupy pod wzgl\u0119dem rodzaju, a tak\u017ce pod wzgl\u0119dem w\u0142a\u015bciwo\u015bci wzajemnie uzupe\u0142niaj\u0105cych si\u0119 produkt\u00f3w. Zam\u00f3wienia dostarczane s\u0105 do odbiorc\u00f3w za po\u015brednictwem zewn\u0119trznych firm logistycznych, ich gabaryty (waga, obj\u0119to\u015b\u0107, rodzaj opakowania) jest bardzo r\u00f3\u017cna. Materia\u0142y wytwarzane s\u0105 przez 2 g\u0142\u00f3wnych producent\u00f3w w Polsce, a tak\u017ce mog\u0105 pochodzi\u0107 od dostawc\u00f3w zagranicznych. Producent mo\u017ce (ale nie musi) by\u0107 istotny dla zamawiaj\u0105cego. Zapotrzebowanie na produkty mo\u017ce mie\u0107 charakter zmienny, sezonowy, jednak jest to w du\u017cym stopniu uzale\u017cnione od rodzaju produktu i du\u017cej liczby czynnik\u00f3w zewn\u0119trznych. Zmienno\u015b\u0107 ma wp\u0142yw zar\u00f3wno na producent\u00f3w jak i odbiorc\u00f3w, co mo\u017ce odbija\u0107 si\u0119 na zmianach cen, okresowej niedost\u0119pno\u015bci cz\u0119\u015bci materia\u0142\u00f3w lub op\u00f3\u017anieniach w dostawie. Ze wzgl\u0119du na wielko\u015b\u0107 pojedynczego zam\u00f3wienia i jego koszt, sprzedawca umo\u017cliwia op\u00f3\u017anione p\u0142atno\u015bci, zam\u00f3wienia roz\u0142o\u017cone na wiele dostaw. Zale\u017cy mu na zachowaniu du\u017cej p\u0142ynno\u015bci finansowej, nie kredytowaniu odbiorc\u00f3w z w\u0142asnych \u015brodk\u00f3w, gwarancji p\u0142atno\u015bci, jednocze\u015bnie na utrzymaniu sta\u0142o\u015bci zam\u00f3wie\u0144 od klient\u00f3w, swoistej monopolizacji (najlepiej jakby odbiorca zamawia\u0142 wszystkie p\u00f3\u0142produkty tylko u tego sprzedawcy) i wiedzy na temat przysz\u0142ego zapotrzebowania. Sprzedawca nie prowadzi w\u0142asnego magazynu.<\/p><\/blockquote>\n Zarz\u0105d sp\u00f3\u0142ki chcia\u0142by wdro\u017cy\u0107 system informatyczny, kt\u00f3ry wspomo\u017ce jej dzia\u0142ania biznesowe, czyli dostarczy funkcjonalno\u015bci pozwalaj\u0105cej obs\u0142ugiwa\u0107 cykl zam\u00f3wie\u0144 i dostaw, wspieraj\u0105cej komunikacj\u0119 z producentami, klientami i podwykonawcami.<\/p>\n Poniewa\u017c omawiam tutaj tylko przyk\u0142ad odkrywania przypadk\u00f3w u\u017cycia, wi\u0119c skupiam si\u0119 wy\u0142\u0105cznie na analizie przypadk\u00f3w u\u017cycia i pomijam lub ograniczam pozosta\u0142e cz\u0119\u015bci analizy wymaga\u0144. Nie pojawi si\u0119 wi\u0119c ani model domeny, ani opis proces\u00f3w biznesowych, ani inne obszary analizy jak integracja, interfejs u\u017cytkownika, algorytmy, regu\u0142y. Bez tych obszar\u00f3w, trudno w mojej opinii zrobi\u0107 dobr\u0105 analiz\u0119 wymaga\u0144, dlatego podkre\u015blam, \u017ce przedstawione tu przyk\u0142ady s\u0105 tylko fragmentem wi\u0119kszej ca\u0142o\u015bci. Oczywi\u015bcie nikt nie zabroni zacz\u0105\u0107 od przypadk\u00f3w u\u017cycia i na tym pozosta\u0107. Jednak w efekcie powstanie, delikatnie m\u00f3wi\u0105c, kaleki opis wymaga\u0144. W rzeczywisto\u015bci analiza przypadk\u00f3w u\u017cycia powinna powsta\u0107 na jednym z dalszych etap\u00f3w prac i opiera\u0107 si\u0119 na du\u017co wi\u0119kszym zasobie informacji, ni\u017c przedstawiony powy\u017cej opis problemu. Wi\u0119c nie r\u00f3bcie tego w pracy, to tylko przyk\u0142ad.<\/p>\n Na podstawie wcze\u015bniej wykonanych krok\u00f3w analizy, powinni\u015bmy by\u0107 wstanie wskaza\u0107 aktor\u00f3w (odpowiadaj\u0105cych np. poszczeg\u00f3lnym uczestnikom proces\u00f3w biznesowych) oraz wykorzystywane przez nich przypadki u\u017cycia. Poniewa\u017c, jak zaznaczy\u0142em wcze\u015bniej, pomijamy t\u0105 cz\u0119\u015b\u0107 analizy, wi\u0119c po prostu spr\u00f3bujemy wskaza\u0107 tutaj jeden z przypadk\u00f3w u\u017cycia i przeprowadzi\u0107 jego analiz\u0119.<\/p>\n Jako nasz testowy okaz wybierzemy use case odpowiadaj\u0105cy za funkcjonalno\u015b\u0107 z\u0142o\u017cenia nowego zam\u00f3wienia.<\/p>\n Identyfikator<\/strong>: B2B-UC-001<\/p>\n Nazwa<\/strong>: Zarejestruj nowe zam\u00f3wienie<\/p>\n Aktor<\/strong>: Klient<\/p>\n Opis<\/strong>: dostarcza Klientowi funkcjonalno\u015b\u0107 zg\u0142oszenia nowego zam\u00f3wienia. System musi zapewni\u0107 zarejestrowanemu Klientowi mo\u017cliwo\u015b\u0107 okre\u015blenia szczeg\u00f3\u0142\u00f3w zam\u00f3wienia: okre\u015blenia rodzaj\u00f3w produkt\u00f3w, parametr\u00f3w produkt\u00f3w, miejsca i terminu realizacji zam\u00f3wienia (dostawy). W trakcie sk\u0142adania zam\u00f3wienia system powinien tak\u017ce umo\u017cliwi\u0107 zarejestrowanie Klienta i\/lub zalogowanie si\u0119 Klienta. System weryfikuje poprawno\u015b\u0107 i kompletno\u015b\u0107 wprowadzonego zam\u00f3wienia \u2013 dost\u0119pno\u015b\u0107 towar\u00f3w, mo\u017cliwo\u015bci transportowe, poprawno\u015b\u0107 ilo\u015bci towar\u00f3w, brak blokad na koncie klienta, rejestruje je i uruchamia jego procesowanie.<\/p><\/blockquote>\n Mamy wi\u0119c podstaw\u0105 wersj\u0119 przypadku u\u017cycia, a raczej jego zarys. Sk\u0142ada si\u0119 z:<\/p>\n Podsumowuj\u0105c – mamy zarys tematu, wiemy czego dotyczy opisywana funkcjonalno\u015b\u0107 i z jakich czynno\u015bci powinna si\u0119 sk\u0142ada\u0107. Jednak nadal czego\u015b brakuje. Przejd\u017amy wi\u0119c do nast\u0119pnego etapu.<\/p>\n Dla lepszego zdefiniowania warunk\u00f3w, ogranicze\u0144 i potrzeb aktor\u00f3w wskazane jest okre\u015blenie granic, czyli opisania z jednej strony kiedy UC mo\u017ce i powinien zosta\u0107 uruchomiony a z drugiej – kiedy i w jaki spos\u00f3b UC ko\u0144czy si\u0119. Do opisu przypadku u\u017cycia dodajemy wi\u0119c pola:<\/p>\n Wyzwalacz (trigger<\/em>)<\/strong>: przypadek u\u017cycia jest uruchamiany na \u017c\u0105danie u\u017cytkownika Dodali\u015bmy informacje, kt\u00f3re pozwol\u0105 okre\u015bli\u0107 jaki kontekst musi by\u0107 zapewniony aby UC m\u00f3g\u0142 by\u0107 uruchomiony (warunki pocz\u0105tkowe). Co wi\u0119cej oznacza to tak\u017ce, \u017ce je\u017celi te warunki nie s\u0105 zapewnione to UC nie mo\u017ce by\u0107 uruchomiony. Dodali\u015bmy te\u017c informacj\u0119 jakie zdarzenie uruchamia przypadek u\u017cycia (wyzwalacz). Akurat w tym wypadku jest to do\u015b\u0107 banalne zdarzenie, jednak warto zaznaczy\u0107, \u017ce jest to do\u015b\u0107 istotny element opisu przypadku u\u017cycia. W szczeg\u00f3lno\u015bci dla przypadk\u00f3w, kt\u00f3re opisuj\u0105 automatyczne czynno\u015bci systemu oraz takich kt\u00f3re wywo\u0142ywane s\u0105 z innych przypadk\u00f3w u\u017cycia. Przyk\u0142adowo, po zako\u0144czeniu UC kt\u00f3rym si\u0119 tu zajmujemy powinien zosta\u0107 uruchomiony inny UC – Zweryfikuj zam\u00f3wienie. Wyzwalaczem dla tego przypadku u\u017cycia b\u0119dzie zdarzenie Zarejestrowano zam\u00f3wienie w statusie nowe.<\/p>\n Przejd\u017amy teraz na drugi koniec czyli punkty opisu pod tytu\u0142em \u201ewarunki ko\u0144cowe\u201d. Te dwa punkty pozwalaj\u0105 nam okre\u015bli\u0107 jaka sytuacja musi zosta\u0107 zapewniona po zako\u0144czeniu przypadku u\u017cycia gdy przypadek zako\u0144czy si\u0119 sukcesem (warunek ko\u0144cowy) lub pora\u017ck\u0105 (minimalny warunek ko\u0144cowy. Pierwszy jest w miar\u0119 oczywisty \u2013 okre\u015bla stan, kt\u00f3ry spodziewamy si\u0119 osi\u0105gn\u0105\u0107 po zako\u0144czeniu wykonywania przypadk\u00f3w u\u017cycia. Ale po co ten drugi? Wbrew pozorom, mo\u017ce to by\u0107 nawet istotniejsza informacja. Pozwoli nam unikn\u0105\u0107 sytuacji, gdy co\u015b p\u00f3jdzie nie tak i zostawimy system w stanie nieustalonym. W szczeg\u00f3lno\u015bci jest to istotne, gdy zaczynamy m\u00f3wi\u0107 o bardziej technicznych UC na przyk\u0142ad integracyjnych.<\/p>\n Dodatkowo, warto tu rozr\u00f3\u017cni\u0107 dwa rodzaje sukcesu – sukces przypadku u\u017cycia i sukces testu sprawdzaj\u0105cego przypadek u\u017cycia. Pierwszy oznacza, \u017ce przypadek si\u0119 powi\u00f3d\u0142 i zosta\u0142 osi\u0105gni\u0119ty warunek ko\u0144cowy, drugi zale\u017cny jest od rodzaju testu i oznacza \u017ce test przebieg\u0142 poprawnie (nie stwierdzono odst\u0119pstw od scenariusza test\u00f3w), czyli mo\u017ce to tak\u017ce oznacza\u0107 osi\u0105gni\u0119cie minimalnego warunku ko\u0144cowego je\u017celi test sprawdza\u0142 w\u0142a\u015bnie taki przebieg.<\/p>\n Mamy wi\u0119c przypadek kt\u00f3ry ma ju\u017c dobrze zdefiniowane ramy, oczekiwania i warunki. Brakuje jeszcze okre\u015blenia przebiegu. Co prawda mamy ju\u017c zarysowany g\u0142\u00f3wny scenariusz, kt\u00f3ry okre\u015bla co si\u0119 dzieje w trakcie wykonywania takiego przypadku u\u017cycia, jednak \u2013 po pierwsze jest jeszcze do\u015b\u0107 og\u00f3lny a po drugie \u2013 to nie jest jedyny scenariusz. Scenariusze powinny wskazywa\u0107 czynno\u015bci, nazywa\u0107 dzia\u0142ania i ich rezultaty podejmowane przez obie strony (system i aktora) d\u0105\u017c\u0105cych do osi\u0105gni\u0119cia celu. G\u0142\u00f3wny scenariusz jest po prostu rozwini\u0119ciem opisu, powinien doda\u0107 szczeg\u00f3\u0142y, ale nadal opisywa\u0107 najcz\u0119\u015bciej spotykany, najbardziej popularny spos\u00f3b post\u0119powania.<\/p>\n G\u0142\u00f3wny scenariusz<\/strong>: Zarejestrowany u\u017cytkownik przegl\u0105da list\u0119 oferowanych produkt\u00f3w. Po wybraniu jednego z produkt\u00f3w klient dodaje go zam\u00f3wienia. System prosi klienta o okre\u015blenie ilo\u015bci produkt\u00f3w (uwaga: zale\u017cne od rodzaju produktu). Klient mo\u017ce wykona\u0107 ten krok dowoln\u0105 liczb\u0119 razy, kolejno\u015b\u0107 dodawania produkt\u00f3w nie jest istotna. Klient podejmuje decyzj\u0119 o z\u0142o\u017ceniu zam\u00f3wienia. System potwierdza \u017ce konto klienta jest aktywne i zatwierdzone. System potwierdza poprawno\u015b\u0107 zam\u00f3wienia: dost\u0119pno\u015b\u0107 towar\u00f3w, prawid\u0142ow\u0105 ilo\u015b\u0107. System sprawdza rodzaj rozlicze\u0144 klienta \u2013 dost\u0119pne formy p\u0142atno\u015bci i potwierdza, \u017ce klient nie ma zablokowanych p\u0142atno\u015bci. System sprawdza mo\u017cliwo\u015bci transportowe \u2013 okre\u015bla wymagany rodzaj transportu i jego dost\u0119pno\u015b\u0107. System prezentuje konfiguracj\u0119 klientowi. Klient okre\u015bla dat\u0119 dostawy, adres dostawy. Klient zatwierdza zam\u00f3wienie. System rejestruje zam\u00f3wienie i przekazuje je do zatwierdzenia.<\/p><\/blockquote>\n Okre\u015blili\u015bmy g\u0142\u00f3wny scenariusz powodzenia, jednak nadal czego\u015b brakuje. Przyst\u0119pujemy wi\u0119c do wymy\u015blania wszelkich innych mo\u017cliwych sytuacji \u201eco by by\u0142o gdyby\u201d. Przyk\u0142adowo: scenariusz g\u0142\u00f3wny nie uwzgl\u0119dnia sytuacji gdy: u\u017cytkownik zalogowa\u0142 si\u0119 ale jego konto nie jest aktywne i zatwierdzone (w omawianym przypadku rejestracja konta musia\u0142a by\u0107 potwierdzana przez pracownik\u00f3w) lub konto posiada blokady sprzeda\u017cy (kolejny pomys\u0142 zamawiaj\u0105cego omawiany system \u2013 konto mog\u0142o by\u0107 zablokowane za nieterminow\u0105 p\u0142atno\u015b\u0107) lub te\u017c zam\u00f3wienie nie mo\u017ce by\u0107 zrealizowane z powodu braku towar\u00f3w lub innych ogranicze\u0144. Dla wszystkich wymy\u015blonych alternatyw musimy teraz opisa\u0107 scenariusze, przyk\u0142adowo:<\/p>\n Scenariusz alternatywny \u2013 zablokowane konto<\/strong>: W trakcje weryfikacji konta klienta, system stwierdza \u017ce konto klienta nie jest aktywne (nie zosta\u0142o zatwierdzone) lub posiada inn\u0105 blokad\u0119. System prezentuje u\u017cytkownikowi informacj\u0119 o tym fakcie, umo\u017cliwia przes\u0142anie wiadomo\u015bci do administracji dt. konta. System rejestruje tak\u017ce informacj\u0119 o sk\u0142adanym zam\u00f3wieniu oraz przypisuje do konta klienta konfiguracj\u0119 zam\u00f3wienia w stanie oczekuj\u0105ce.<\/p><\/blockquote>\n I tak dalej \u2013 ka\u017cdy istotny scenariusz alternatywny powinien zosta\u0107 opisany.<\/p>\n Histori\u0119 z przypadkiem u\u017cycia mo\u017cna ci\u0105gn\u0105\u0107 dalej i dalej. Mo\u017cna przede wszystkim rozbudowa\u0107 scenariusze, zapisuj\u0105c je w mniej lub bardziej formalnej strukturze (poczynaj\u0105c od wypunktowania krok\u00f3w, ko\u0144cz\u0105c na modelu UMLowym scenariuszy w postaci diagram\u00f3w aktywno\u015bci). Mo\u017cna rozbudowywa\u0107 opisane ju\u017c wy\u017cej warunki, mo\u017cna \u015bci\u015blej powi\u0105za\u0107 UC z pozosta\u0142ymi obszarami analizy. Mo\u017cna jeszcze wiele zdzia\u0142a\u0107. Wszystko jednak zale\u017cy od jednego kluczowego ustalenia \u2013 Definicji: Sko\u0144czone. W ka\u017cdym projekcie, czy nawet na ka\u017cdym jego etapie powinni\u015bmy mie\u0107 ustalone gdzie ko\u0144czymy, co jest wystarczaj\u0105cym, zadowalaj\u0105cym zestawem informacji.<\/p>\n Powy\u017cszy artyku\u0142 nie obejmuje tak\u017ce informacji o relacjach mi\u0119dzy przypadkami u\u017cycia. Chwila zastanowienia si\u0119 nad scenariuszami (zw\u0142aszcza g\u0142\u00f3wnym) wystarczy, aby stwierdzi\u0107 \u017ce co\u015b tam jest nie tak. Kroki s\u0105 za \u201egrube\u201d, s\u0105 na tyle og\u00f3lne, \u017ce za du\u017co pozostaje jeszcze do wyja\u015bnienia. I w tym momencie wchodz\u0105 powi\u0105zane przypadki u\u017cycia. Wr\u00f3c\u0119 do tego tematu jeszcze. Moje do\u015bwiadczenie wskazuje, \u017ce w pe\u0142ni sformalizowane przypadki u\u017cycia przewa\u017cnie nie s\u0105 najw\u0142a\u015bciwszym rozwi\u0105zaniem. Kiedy\u015b stara\u0142em si\u0119 ka\u017cdy przypadek opisa\u0107 jak najdok\u0142adniej, rozpisuj\u0105c scenariusze do najdrobniejszych krok\u00f3w, z kt\u00f3rych ka\u017cdy mia\u0142 nawet w\u0142asny identyfikator. Jednak, zderzaj\u0105c si\u0119 wielokrotnie ze zmienno\u015bci\u0105 wymaga\u0144, nie\u015bcis\u0142o\u015bci\u0105 \u017c\u0105da\u0144 klient\u00f3w, doszed\u0142em do wniosku, \u017ce w taki spos\u00f3b zbyt du\u017co wysi\u0142ku idzie na marne. Obecnie, w wi\u0119kszo\u015bci sytuacji, mo\u017ce poza najbardziej technicznymi i kluczowymi obszarami jak integracja czy przetwarzanie danych, przyjmuj\u0119 bardziej elastyczne, \u201ezwinne\u201d podej\u015bcie. Przypadek musi by\u0107 na tyle szczeg\u00f3\u0142owo opisany, aby nie budzi\u0142 pyta\u0144 interpretacyjnych (\u201eco autor mia\u0142 na my\u015bli\u201d), by\u0142 zrozumia\u0142y i czytelny oraz by\u0142 \u0142atwo testowalny. Nie musi by\u0107 rozpisany ze szczeg\u00f3\u0142ami do najdrobniejszego kroku.. Ale o zwinnych analizach mo\u017ce nast\u0119pnym razem.<\/p>\n W jednym ze wcze\u015bniejszych wpis\u00f3w 1, przedstawi\u0142em moje uwagi dt. przypadk\u00f3w u\u017cycia. Na ko\u0144cu obieca\u0142em, \u017ce dodam jeszcze troch\u0119 praktycznych przyk\u0142ad\u00f3w. I w\u0142a\u015bnie tym chcia\u0142bym si\u0119 dzi\u015b zaj\u0105\u0107. Chcia\u0142em, aby przedstawione przyk\u0142ady by\u0142y „wzi\u0119te z \u017cycia”, dlatego s\u0105 oparte na pewnym projekcie, kt\u00f3ry realizowa\u0142em. Przedstawi\u0119 w skr\u00f3cie problem, tak aby mo\u017cna by\u0142o uchwyci\u0107 o … Czytaj dalej Przypadki u\u017cycia – przyk\u0142ad<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,6],"tags":[21,8,17,16],"class_list":["post-189","post","type-post","status-publish","format-standard","hentry","category-analiza","category-uml","tag-analiza-biznesowa","tag-przypadki-uzycia","tag-uc","tag-use-case"],"_links":{"self":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/189","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/comments?post=189"}],"version-history":[{"count":19,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/189\/revisions"}],"predecessor-version":[{"id":459,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/189\/revisions\/459"}],"wp:attachment":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/media?parent=189"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/categories?post=189"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/tags?post=189"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Temat<\/em><\/strong><\/h2>\n
Dodatkowe za\u0142o\u017cenia<\/strong><\/h2>\n
Przypadki u\u017cycia<\/strong><\/h2>\n
Etap pierwszy – szkic przypadku u\u017cycia<\/strong><\/h2>\n
\n
Etap drugi – granice i oczekiwania<\/h2>\n
\nWarunki pocz\u0105tkowe<\/strong>: u\u017cytkownik musi by\u0107 zalogowany
\nWarunek ko\u0144cowy<\/strong>: zam\u00f3wienie w statusie nowe jest zarejestrowane, powi\u0105zane z kontem klienta; zam\u00f3wienie spe\u0142nia wszystkie regu\u0142y zam\u00f3wienia w statusie nowe (patrz model dziedziny\/regu\u0142y biznesowe)
\nMinimalny warunek ko\u0144cowy<\/strong>: z kontem klienta jest powi\u0105zana informacja o uruchomieniu sk\u0142adania zam\u00f3wienia, w logach systemowych zarejestrowana jest informacja o przebiegu sk\u0142adania zam\u00f3wienia i przyczynach zako\u0144czenia<\/p><\/blockquote>\nEtap trzeci \u2013 scenariusze i alternatywy<\/h2>\n
Co dalej<\/h2>\n
\n