Szablon: Specyfikacja funkcjonalna integracji lub modyfikacji (IDK-11)

Szablon IDK-11, wersja 1.0. Faza: Establish Solution.

Jak korzystać z tego szablonu

Użyj jednej specyfikacji na każdą integrację lub modyfikację w rejestrze CRIM (szablon Rejestr CRIM (IDK-10)). Konfiguracje i raporty używają zamiast tego szablonu IDK-12.
Nie zaczynaj tego dokumentu, dopóki rejestr CRIM nie pokazuje decyzji „Zatwierdzona do specyfikacji". Nie zaczynaj rozwoju, dopóki sekcje 13 i 14 nie są podpisane.
Napisz sekcje 1-4 językiem biznesowym, żeby właściciel procesu mógł je zatwierdzić. Sekcje 5-9 mogą być techniczne.
Sekcja 11 nie jest opcjonalna. Integracja lub modyfikacja bez zapisanego wpływu na aktualizacje zaskoczy kogoś przy pierwszym release update.
Utrzymuj ten dokument aktualny po starcie produkcyjnym. Wsparcie otrzymuje najnowszą wersję przy przekazaniu, razem ze scenariuszami testowymi w sekcji 10.
Zastąp każde pole [...]. Usuń wiersze oznaczone Przykład: przed zatwierdzeniem.

Metadane szablonu
Field	Value
ID szablonu	IDK-11
Faza	Establish Solution
Właściciel	Konsultant aplikacyjny, wspólnie z kierownikiem rozwiązania technicznego
Zatwierdzający	Właściciel procesu po stronie klienta i kierownik projektu po stronie klienta, zatwierdzenie komercyjne przez obu kierowników projektu, autoryzacja komitetu sterującego
Bramka kwalifikacyjna	Solution Established
Wersja	1.0

Kontrola dokumentu

Pole	Wartość
Projekt	[nazwa projektu]
ID rejestru CRIM	[ID]
Typ	[Integracja / Modyfikacja]
ID rejestru interfejsów (integracje)	[ID]
Obszar rozwiązania i proces	[obszar, proces, link do modelu procesów]
Autor	[imię i nazwisko, rola]
Projektant techniczny	[imię i nazwisko]
Status	[Szkic / W przeglądzie / Zatwierdzona / Zaktualizowana]
Lokalizacja przechowywania	[link]

Wersja	Data	Autor	Zmiana	Zatwierdził
0.1	[YYYY-MM-DD]	[imię i nazwisko]	Pierwszy szkic
[x.y]	[YYYY-MM-DD]	[imię i nazwisko]	[zmiana]	[imię i nazwisko]

1. Potrzeba biznesowa

Zapisz potrzebę, nie rozwiązanie. Podaj, kto ma tę potrzebę i co stanie się z biznesem, jeśli nie zostanie zaspokojona.

Pozycja	Opis
Potrzeba	Przykład: Kupcy muszą widzieć potwierdzenia zamówień od dostawcy w IFS Cloud bez ręcznego wprowadzania, żeby opóźnione lub zmienione daty były widoczne w dniu, w którym dostawca je zgłasza
Kto ma tę potrzebę	Przykład: Kupcy we wszystkich lokalizacjach, kierownik zakupów
Konsekwencja, jeśli nie zaspokojona	Przykład: Potwierdzone daty pozostają w e-mailu, planowanie działa na żądanych datach, opóźnione dostawy są wykrywane na doku
Odniesienie do Księgi reguł	[dokument, ID decyzji]
Korzyść oczekiwana przez sponsora	[tekst, link do pozycji business case, jeśli istnieje]

2. Kontekst procesu

Pozycja	Opis
Proces i krok, którego dotyczy	[proces, krok w modelu procesów]
Role, których dotyczy	[role biznesowe]
Lokalizacje i spółki objęte zakresem	[lista]
Zależność poprzedzająca	[co musiało się wydarzyć wcześniej]
Efekt następczy	[co korzysta z wyniku]
Powiązane inne obiekty CRIM	[ID]

3. Obecne zachowanie standardowe

Opisz, co robi dziś standardowy IFS Cloud dla tego kroku. Zweryfikuj to w środowisku projektowym przed pisaniem. Nie opisuj z pamięci ani z poprzedniej wersji.

Pozycja	Opis
Zweryfikowana funkcjonalność standardowa	Przykład: Ręczne wprowadzanie potwierdzonej daty i ilości na pozycji zamówienia zakupu. Standardowa obsługa komunikatów przychodzących dla potwierdzeń zamówień przez IFS Connect.
Środowisko i wersja, w której zweryfikowano	[nazwa środowiska, release i poziom service update]
Pokazano	[nazwiska, data]
Dlaczego standard nie wystarcza	Przykład: Portal dostawcy nie potrafi wygenerować standardowego formatu komunikatu, a ręczne wprowadzanie nie skaluje się do liczby pozycji
Odrzucone alternatywy standardowe, z powodem	[alternatywa, powód]

4. Wymagane zachowanie

Ponumeruj każde wymaganie. Każde musi być testowalne i musi mapować się na co najmniej jeden scenariusz w sekcji 10.

ID wym.	Wymaganie	Priorytet	Źródło
Przykład: R1	Gdy portal dostawcy zgłasza potwierdzenie, odpowiadająca pozycja zamówienia zakupu pokazuje potwierdzoną datę i ilość dostawy	Konieczne	Księga reguł PUR-D07
Przykład: R2	Potwierdzenie, które nie pasuje do żadnej otwartej pozycji, nie jest stosowane. Jest wymienione dla kupca wraz z powodem.	Konieczne	Warsztat [YYYY-MM-DD]
[ID]	[wymaganie]	[Konieczne / Pożądane / Możliwe]	[źródło]

Poza zakresem tej specyfikacji: [lista jawna].

5. Projekt funkcjonalny

5.1 Przegląd

[Krótki opis narracyjny rozwiązania, z diagramem przepływu lub linkiem. Wskaż, gdzie działa każda część: wewnątrz IFS Cloud, w middleware, w drugim systemie.]

5.2 Kroki projektu

Krok	Aktor lub komponent	Działanie	Wynik
Przykład: 1	Portal dostawcy	Publikuje potwierdzenie z numerem zamówienia, pozycją, uwolnieniem, datą i ilością	Komunikat dostępny dla warstwy integracyjnej
Przykład: 2	Warstwa integracyjna	Wyszukuje pozycję zamówienia zakupu przez projekcję, sprawdza status i otwartą ilość	Pozycja znaleziona albo błąd wg sekcji 8
Przykład: 3	Warstwa integracyjna	Wywołuje standardową akcję potwierdzającą pozycję	Standardowa logika biznesowa waliduje i aktualizuje pozycję
[n]	[aktor]	[działanie]	[wynik]

5.3 Zmiany widoczne dla użytkownika

Strona lub lobby	Zmiana	Role, które ją widzą
[strona]	[zmiana lub „brak"]	[role]

5.4 Zastosowane zasady projektowe

Aktualizacje przechodzą przez standardowe projekcje i ich logikę biznesową. Żadnych bezpośrednich zapisów do bazy danych.
Preferuj konfigurację i opublikowane interfejsy zamiast zmienionego kodu aplikacji. Podaj poziom dostosowania z rejestru CRIM: [Rozszerzenie interfejsowe / Modyfikacja].
[zasada specyficzna dla projektu]

6. Wykorzystane dane i projekcje

Potwierdź nazwy projekcji, entity set i akcji w API Explorer środowiska projektowego. Nazwy poniżej są zastępcze, dopóki nie zostaną zweryfikowane.

Projekcja	Entity set lub akcja	Operacja	Odczytywane lub zapisywane pola	Zweryfikowano w środowisku, data
Przykład: [projekcja obsługi zamówień zakupu]	[entity set pozycji zamówienia zakupu]	Odczyt	Numer zamówienia, pozycja, uwolnienie, status, żądana data, otwarta ilość	[środowisko], [YYYY-MM-DD]
Przykład: [projekcja obsługi zamówień zakupu]	[akcja potwierdzenia pozycji]	Zapis	Potwierdzona data, potwierdzona ilość	[środowisko], [YYYY-MM-DD]
[projekcja]	[entity set / akcja]	[Odczyt / Zapis]	[pola]	[zweryfikowano]

Mapowanie pól:

Pole źródłowe	Pole docelowe	Transformacja lub reguła	Obowiązkowe
[pole]	[pole]	[reguła]	[Tak / Nie]

Pola niestandardowe, encje niestandardowe lub konfiguracja potrzebne dla tego projektu: [lista z ID CRIM albo „brak"].

7. Bezpieczeństwo

Pozycja	Opis
Konto integracyjne	[nazwa konta. Jedno konto na integrację, nigdy konto nazwanej osoby.]
Metoda uwierzytelniania	[np. OAuth client credentials przez dostawcę tożsamości IFS]
Permission set	[nazwa. Przyznaje wyłącznie projekcje i akcje z sekcji 6.]
Tylko odczyt czy zapis	[Tylko odczyt / Zapis. Dostęp do zapisu wymaga autoryzacji komitetu sterującego zapisanej w sekcji 13.]
Opiekun poświadczeń	[rola, która przechowuje i rotuje sekret]
Rotacja i odwołanie	[jak sekret jest rotowany, jak dostęp jest usuwany przy wycofaniu]
Przenoszone dane osobowe lub wrażliwe	[brak / opis, z odniesieniem do zatwierdzenia właściciela prywatności]
Ścieżka sieciowa	[źródło, cel, porty, szyfrowanie w tranzycie]
Logowanie	[co jest logowane, gdzie, retencja, potwierdzenie, że logi zawierają wyłącznie klucze, a nie treść biznesową, jeśli wymagane]

8. Obsługa błędów

ID błędu	Sytuacja	Wykrycie	Reakcja systemu	Kto jest powiadamiany i jak	Odzyskanie
Przykład: E1	Pozycja zamówienia nie znaleziona lub już zamknięta	Wyszukanie nie zwraca otwartej pozycji	Komunikat zaparkowany z powodem, nic nie zaktualizowane	Kupiec, przez [element lobby / zdarzenie e-mail]	Kupiec poprawia odniesienie w portalu, komunikat jest przetwarzany ponownie
Przykład: E2	IFS Cloud niedostępny	Wywołanie zawodzi lub przekracza limit czasu	Ponowienie `[ustalić w projekcie]` razy, następnie zaparkowanie	Właściciel integracji, przez alert monitoringu	Automatyczne ponowne przetworzenie po powrocie połączenia
[ID]	[sytuacja]	[wykrycie]	[reakcja]	[powiadomienie]	[odzyskanie]

Zasady: żaden komunikat nie ginie po cichu, żaden komunikat nie jest stosowany dwukrotnie, a każdy zaparkowany komunikat ma właściciela.

9. Wolumeny i wydajność

Uzupełnij liczbami od biznesu. Nie szacuj ich w zespole projektowym.

Miara	Wartość	Źródło liczby
Transakcje dziennie, normalnie	`[ustalić w projekcie]`	[imię i nazwisko, rola]
Transakcje dziennie, w szczycie	`[ustalić w projekcie]`	[imię i nazwisko, rola]
Największy pojedynczy komunikat lub plik	`[ustalić w projekcie]`	[imię i nazwisko, rola]
Wymagany czas przetwarzania	`[ustalić w projekcie]`	[imię i nazwisko, rola]
Okno operacyjne	`[ustalić w projekcie]`	[imię i nazwisko, rola]
Oczekiwany wzrost	`[ustalić w projekcie]`	[imię i nazwisko, rola]

Test wolumenowy wymagany przed SAT: [Tak / Nie, odniesienie do planu testów].

10. Scenariusze testowe

Pokryj najpierw przepływ typowy, potem wyjątki normalne, potem wyjątki specyficzne. Te scenariusze stają się specyfikacją testową przekazywaną do wsparcia.

ID testu	Pokrywa	Klasa	Warunki wstępne i dane	Kroki	Oczekiwany wynik	Wynik, tester, data
Przykład: T1	R1	Typowy	Zwolnione zamówienie zakupu z jedną otwartą pozycją	Opublikowanie potwierdzenia dla pełnej ilości z datą późniejszą niż żądana	Pozycja pokazuje potwierdzoną datę i ilość. Historia zamówienia pokazuje zmianę. Brak zaparkowanego błędu.	[Zaliczony / Niezaliczony], [imię i nazwisko], [YYYY-MM-DD]
Przykład: T2	R2, E1	Wyjątek normalny	Pozycja zamówienia zakupu już zamknięta	Opublikowanie potwierdzenia dla tej pozycji	Nic nie zaktualizowane. Komunikat zaparkowany z powodem. Kupiec widzi go w [miejscu].
[ID]	[ID wym.]	[Typowy / Wyjątek normalny / Wyjątek specyficzny]	[dane]	[kroki]	[oczekiwane]

Środowiska testowe: test jednostkowy w [środowisko], test integracyjny w [środowisko], uwzględniony w skrypcie SAT [ID]. Testy wykonywane na rzeczywistym koncie integracyjnym i permission secie, nie na koncie administratora.

11. Wpływ na aktualizacje

Pozycja	Opis
Poziom dostosowania	[Rozszerzenie interfejsowe / Modyfikacja, z rejestru CRIM]
Dotknięte obiekty dostarczone	[projekcje, encje, strony, moduły kodu]
Co musi być ponownie zweryfikowane przy każdym release update	Przykład: Nazwy i sygnatury entity set i akcji z sekcji 6, zachowanie akcji potwierdzającej, uprawnienia permission setu, scenariusze T1 i T2
Co musi być sprawdzone przy każdym service update	[zazwyczaj smoke test scenariusza T1, podaj to]
Przebudowa lub uplift potrzebne przy release update	[Nie dla Rozszerzenia interfejsowego / Tak dla Modyfikacji, z szacowanym nakładem `[ustalić w projekcie]`]
Właściciel ponownej weryfikacji	[rola po stronie klienta po starcie produkcyjnym]
Warunek wycofania	[w jakich okolicznościach ten obiekt może zostać wycofany, np. gdy standard pokryje potrzebę]

12. Wdrożenie i przekazanie

Pozycja	Opis
Trasa dostawy	[Build Place do środowisk Use Place dla kodu, pakiety konfiguracji dla konfiguracji, wdrożenie komponentów zewnętrznych]
Potrzebne kroki cutover	[pozycje do dodania do planu cutover]
Monitoring po starcie produkcyjnym	[co jest monitorowane, przez kogo]
Właściciel wsparcia	[rola]
Zawartość przekazania	Ta specyfikacja, scenariusze testowe z sekcji 10, wiersz rejestru interfejsów, dane opiekuna poświadczeń

13. Wycena i zatwierdzenie komercyjne

Rozwój nie zaczyna się przed ukończeniem tej sekcji.

Pozycja	Wartość
Wycena specyfikacji, budowy, testów, dokumentacji	`[ustalić w projekcie]`
Wycena cyklicznego nakładu na aktualizacje	`[ustalić w projekcie]`
Założenia i wyłączenia	[tekst]
Odniesienie do wniosku o zmianę	[ID]
Autoryzacja komitetu sterującego	[data spotkania, odniesienie do protokołu]

Rola	Imię i nazwisko	Decyzja	Data
Kierownik projektu po stronie dostawcy	[imię i nazwisko]	[Zatwierdzono / Odrzucono]	[YYYY-MM-DD]
Kierownik projektu po stronie klienta	[imię i nazwisko]
Sponsor po stronie klienta (jeśli wymagane umową)	[imię i nazwisko]

14. Zatwierdzenie

Zatwierdzając, klient potwierdza, że sekcje 1-4 poprawnie opisują potrzebę i wymagane zachowanie, że scenariusze testowe w sekcji 10 są podstawą odbioru, oraz że wpływ na aktualizacje w sekcji 11 jest zrozumiały.

Rola	Imię i nazwisko	Decyzja	Data
Właściciel procesu po stronie klienta	[imię i nazwisko]	[Zatwierdzono / Zatwierdzono z uwagami / Odrzucono]	[YYYY-MM-DD]
Kierownik projektu po stronie klienta	[imię i nazwisko]
Kierownik rozwiązania technicznego (przegląd projektu technicznego)	[imię i nazwisko]
Architekt rozwiązania (przegląd spójności)	[imię i nazwisko]

Uwagi i warunki: [tekst]

Niezależny szablon zgodny z metodyką wdrożeniową IFS. Nie jest oficjalnym dokumentem IFS. IFS jest zastrzeżonym znakiem towarowym IFS AB.

Marketplace