Temat: Wymagania funkcjonalne

Witam szanownych analityków.

Dostałem zadanie napisania specyfikacji wymagań. Mam drobny problem jak opisać wymagania niewidoczne z perspektywy użytkownika.
Mianowicie chodzi o funkcjonalności realizowane w tle. np..:
- Wywołanie pobierania danych z systemu X podczas logowania użytkownika do systemu Z. System X z kolei pobiera dane z systemu Y (system zewnętrzny innej firmy) cyklicznie ale aktualizuje bazę danych i z której korzysta przy wysyłaniu danych do systemu Z. (Logowanie jednakże nie jest nową funkcjonalnością i nie będzie zmieniana). Analogicznie wysłanie danych: System Z wysyła dane do systemu X, z kolei ten wysyła dane do systemu Y.

Istnieją również inne funkcjonalności do opisania, które działają w tle i wywołane są automatycznie.
Na Diagramie w notacji BPMN nie było problemu ich wyróżnić i krótko opisać jednak chciałbym opisać szczegółu tych funkcjonalności w sposób bardziej techniczny, wyjaśniając wymagania wstępne / końcowe, reakcje, wyjątki itp. Zastanawiam się jak zrobić to czytelnie dla użytkownika.

Czy diagram przypadków użycia i strukturyzowane formularze do tego się nadają?Ten post został edytowany przez Autora dnia 16.03.17 o godzinie 14:36

Temat: Wymagania funkcjonalne

Diagram przypadków użycia super, a z tego, co piszesz, scenariusze przypadków użycia w 100% (use case scenarios)

Temat: Wymagania funkcjonalne

Dziękuje za odpowiedź.

Średnio mi się jednak podoba całokształt jaki z tego wyjdzie tzn.

1. Pobranie danych z systemu Y przez system X..
2. Wysłanie danych do systemu Y przez system X.
3. Pobranie danych z systemu X przez system Z.
4. Wysłanie danych do systemu X przez system Z.

Gdzie X jest można powiedzieć systemem pośredniczącym.
Wyjdą trochę takie duplikaty tj. 1 i 3 oraz 2 i 4., które nieznacznie się różnią.

Myślałem, że można jakoś zrobić to prościej no ale jak mus to mus trzeba pisać :)

Pozdrawiam.Ten post został edytowany przez Autora dnia 17.03.17 o godzinie 10:50

Temat: Wymagania funkcjonalne

Podejściem „klasycznym”, powszechnie stosowanym, jest budowa modeli przypadków użycia przy udziale tzw. aktorów systemowych.
Od kilku lat popularność zdobywa notacja ArchiMate®, rozwijana przez The Open Group®, która daje nieco szersze możliwości. Po pierwsze, w ramach jednego modelu można opisywać zjawiska z kilku domen na raz, co zapewnia pełną ciągłość „narracji” – od problemu biznesowego do rozwiązania technologicznego. Po drugie, na jednym diagramie można ilustrować jednocześnie i we wzajemnych związkach aspekt strukturalny i behawioralny zjawiska, mówiąc prościej, można łatwo pokazać jak działa (zachowuje się) analizowana „struktura”. Po trzecie, bazuje na spójnym paradygmacie usługowo-procesowym: funkcjonalność modułu (elementu aktywnego) jest udostępniana poprzez usługi realizowane przez procesy wewnętrzne inicjowane zdarzeniami.
Poziom szczegółowości ArchiMate® łatwo dostosować do sytuacji i wymagań odbiorcy.
Modele mogą służyć do dokumentacji analizy problemów, specyfikacji wymagań, projektowania architektury, planowania procesu zmiany i implementacji, a nawet karmienia kota (http://www.linkedin.com/feed/update/urn:li:activity:62... ).
Nie jest to język projektowania i generacji kodu oprogramowania. Do tego lepiej nadaje się UML. Praktykuje się niekiedy łączenie notacji – ArchiMate® wtedy pełni rolę tzw. notacji „parasolowej” dla modeli UML i/lub BPMN.
Próbki użycia ArchiMate® można zobaczyć tutaj ( https://archestructure.blogspot.com/2017/02/i-wilk-syty... ) . W tym poście również poruszam problematykę wymagań. Wymaganiami funkcjonalnymi w przypadku modelowania architektury aplikacyjnej są usługi aplikacyjne realizowane przez procesy aplikacyjne (lub funkcje), które można specyfikować lub modelować szczegółowo głębiej, do ostatniego bajta, jeśli jest taka potrzeba. Można postąpić również klasycznie , zgodnie z wymaganiami inżynierii wymagań i formułować oddzielne wymagania (requirements), wskazując które wymaganie ma być zrealizowane /spełnione przez dany element architektury.
Zjawisko komunikacji międzysystemowej w ArchiMate® modeluje się dość prosto. Tu zamieszczam link do przykładowego modelu Twojego przypadku (o ile dobrze go zrozumiałem).



Pozdrawiam,
MarekTen post został edytowany przez Autora dnia 18.03.17 o godzinie 14:59