SysAssist Kosterski Engineering
ENUmów rozmowę

Automotive SPICE · SYS.1 · SYS.2 · SYS.3 · szkice testów

Mniej przepisywania wymagań. Więcej inżynierii systemowej.

SysAssist działa wprost w Twoim ALM, według SYS.1, SYS.2 i SYS.3 Automotive SPICE: rozpisuje wymagania interesariuszy na wymagania systemowe, sprawdza te, które już masz, i przygotowuje szkice przypadków testowych z tego, co zatwierdzisz. Każda sugestia czeka na Twoją decyzję — a każda decyzja zostaje zapisana przy samym elemencie.

Umów rozmowę o pilotażu Prześledź jedno wymaganie

Działa w Codebeamer, DOORS / DOORS Next, Polarion i Windchill RV&S

Przykład: wymaganie w Twoim ALM przeanalizowane przez SysAssist — trzy ustalenia czekają na Twoją decyzję.
SYS-REQ-0442 · rew. 3 3 ustalenia

„System powinien1 szybko2 reagować na sygnał z czujnika parkowania3.”

  1. 1

    „Powinien” nie jest wiążące — wymagania formułujemy słowem „musi”.

    sformułowanie · ISO/IEC/IEEE 29148 · pewność: wysoka

  2. 2

    „Szybko” nie da się zweryfikować. Propozycja: „w ciągu ⟨t⟩ ms” — wartość wpisujesz Ty.

    SYS.2.BP3 · weryfikowalność · pewność: wysoka

  3. 3

    Który czujnik, jaki sygnał? Brak odwołania do definicji interfejsu.

    SYS.3 · interfejsy · pewność: średnia

Twoja decyzja zapisze się jako komentarz przy SYS-REQ-0442.

Twój wtorek — przed i po

Nie cała praca — ta powtarzalna część, która zjada najwięcej godzin.

Dzisiejszy wtorek

  1. Trzy godziny na czytanie 80 wymagań z nowego modułu
  2. Ręczne zaznaczanie niejasnych sformułowań w Excelu
  3. Odtwarzanie trasowalności, bo link się zgubił
  4. Zaczynasz rozpisywać nową specyfikację klienta na wymagania systemowe — od zera
  5. Pytania do klienta piszesz wieczorem, bo wcześniej nie było czasu

Wtorek z SysAssist

  1. Przeglądasz niejednoznaczności, które są już oznaczone
  2. Zatwierdzasz przygotowaną dekompozycję nowej specyfikacji klienta na wymagania systemowe
  3. Pytania do klienta gotowe do wysłania przed obiadem
  4. Zatwierdzasz proponowane linki — trasowalność jest aktualna
  5. Reszta dnia: architektura, nie przepisywanie

Zostaje przy Tobie

  • Zatwierdzanie każdej zmiany, zanim trafi do ALM
  • Decyzje architektoniczne — dostajesz warianty, wybierasz Ty
  • Kontakt z klientem — pytania najpierw trafiają do Ciebie
  • Zamknięcie wymagania jako zweryfikowanego

Gdzie działa w modelu V

Po lewej stronie przygotowuje i sprawdza — od wymagań klienta aż po architekturę. Po prawej przygotowuje szkice przypadków testowych z tego, co zatwierdzisz.

SYS.1 Pozyskiwanie wymagań SYS.2 Wymagania systemowe SYS.3 Architektura systemu dekompozycja alokacja SYS.5 Weryfikacja systemu SYS.4 Weryfikacja integracji SWE · HWE poza zakresem szkice testów Ty zatwierdzasz szkice testów Ty zatwierdzasz tu działa SysAssist każdy szkic czeka na Twoje zatwierdzenie
Po lewej stronie modelu V SysAssist rozpisuje i sprawdza wymagania (SYS.1, SYS.2, SYS.3), po prawej przygotowuje szkice przypadków testowych (SYS.4, SYS.5). Każdy szkic czeka na Twoje zatwierdzenie.
SYS.1

Pozyskiwanie wymagań

Konsoliduje wymagania interesariuszy rozproszone po dokumentach i formułuje pytania doprecyzowujące tam, gdzie intencja jest niejasna.

SYS.2

Wymagania systemowe

Rozpisuje wymagania interesariuszy na szkice wymagań systemowych z linkami trasowalności i sprawdza istniejące pod kątem kompletności, jednoznaczności i weryfikowalności.

SYS.3

Architektura systemu

Proponuje alokację wymagań systemowych do elementów architektury i flaguje interfejsy, które nie zostały jeszcze zdefiniowane.

SYS.4 · SYS.5

Szkice przypadków testowych

Przygotowuje przypadki testowe z zatwierdzonych wymagań i interfejsów — warunki wstępne, kroki, oczekiwane wyniki — każdy z linkiem do źródła.

Od wymagania klienta do wymagań systemowych

SysAssist nie tylko sprawdza to, co już jest. Rozpisuje wymaganie interesariusza na szkice wymagań systemowych — a wartości, które znasz tylko Ty, zostawia Tobie do uzupełnienia.

STK-REQ-017 · specyfikacja klientaSYS.1

„Kierowca musi być ostrzegany o przeszkodach podczas parkowania z małą prędkością.”

Szkice wymagań systemowychSYS.2
  • SYS-REQ-0450System musi aktywować wykrywanie przeszkód po włączeniu biegu wstecznego lub przy prędkości poniżej ⟨v⟩ km/h.Szkic
  • SYS-REQ-0451System musi wykrywać przeszkody w odległości od ⟨min⟩ do ⟨max⟩ cm od tylnego zderzaka.Szkic
  • SYS-REQ-0452System musi generować ostrzeżenie dźwiękowe i wizualne po wykryciu przeszkody.Szkic
  • PytanieDo klienta: jaka prędkość to „mała prędkość”?Czeka na Ciebie

Każdy szkic ma link do STK-REQ-017. Wartości w ⟨ ⟩ wpisujesz Ty; pytanie trafi do klienta dopiero po Twoim zatwierdzeniu.

Jedno wymaganie — od ustalenia do przypadku testowego

Wymaganie z góry tej strony, prześledzone do końca.

  1. Krok 1 z 3

    Ty decydujesz

    Akceptujesz, edytujesz albo odrzucasz każde ustalenie. Dodajesz to, czego model nie może wiedzieć — tutaj czas reakcji uzgodniony z klientem.

    Przegląd · SYS-REQ-04423 z 3 rozstrzygnięte
    • 1„powinien” → „musi”Zaakceptowane
    • 2„szybko” → „w ciągu 200 ms”„Uzgodnione z klientem w protokole z kick-offu.”Zaakceptowane · edytowane
    • 3Sygnał z czujnika — bez zmian„Interfejs opisany w SYS-ARC-0027, link już istnieje.”Odrzucone

    Rew. 4„System musi reagować na sygnał z czujnika parkowania w ciągu 200 ms.”

  2. Krok 2 z 3

    Decyzja zapisuje się przy elemencie

    Zmiany trafiają do ALM dopiero po Twoim zatwierdzeniu. Ustalenie, Twoja decyzja i uzasadnienie zapisują się jako komentarze przy samym wymaganiu — czysta trasowalność decyzji na przeglądy i assessmenty, bez osobnego logu do prowadzenia.

    Komentarze · SYS-REQ-04423
    • SysAssist09:14

      3 ustalenia: sformułowanie (ISO/IEC/IEEE 29148), weryfikowalność (SYS.2.BP3), interfejs (SYS.3).

    • Ty09:41

      Akceptuję 1 i 2, t = 200 ms wg protokołu z kick-offu. Odrzucam 3: interfejs opisany w SYS-ARC-0027.

    • SysAssist09:41

      Zmiana wprowadzona po zatwierdzeniu: rew. 3 → rew. 4.

  3. Krok 3 z 3

    Powstają szkice testów

    Z zatwierdzonego wymagania SysAssist przygotowuje szkice przypadków testowych do weryfikacji systemu, każdy z linkiem do źródła. Przeglądasz je i zatwierdzasz jak wszystko inne.

    Szkice testów · SYS-REQ-0442 rew. 4SYS.5
    • TC-0442-01Sygnał z czujnika → reakcja w ciągu 200 msSzkic
    • TC-0442-02To samo przy maksymalnym obciążeniu magistrali → reakcja w ciągu 200 msSzkic
    • TC-0442-03Brak sygnału z czujnika → brak reakcji (przypadek negatywny)Szkic

    Każdy szkic ma link do SYS-REQ-0442 i trafia do Twojego systemu testów dopiero po zatwierdzeniu.

Dla managera: czas i zasoby

Skąd wracają godziny — i jak pilotaż udowodni to na Waszych własnych wymaganiach.

cel pilotażu

−50%

czasu przeglądu dokumentacji wymagań

cel pilotażu

+50%

niespójności wykrytych przed formalnym przeglądem

  • Pierwsza analiza, zanim zacznie się przegląd

    Każde wymaganie jest przeczytane, sprawdzone i opisane, zanim inżynier otworzy dokument. Przegląd zaczyna się od listy ustaleń, a nie od surowego tekstu.

  • Mniej późnych defektów

    Niejednoznaczności i brakujące interfejsy wychodzą w SYS.2 i SYS.3 — a nie w testach integracyjnych, gdzie poprawki kosztują najwięcej.

  • Czas seniorów na pracę seniorów

    Szkice dekompozycji, linki trasowalności i szkice testów przychodzą gotowe do zatwierdzenia. Najbardziej doświadczeni inżynierowie zajmują się decyzjami architektonicznymi.

  • Szybsze przygotowanie do assessmentu

    Historia decyzji jest już przy każdym elemencie, więc mniej czasu idzie na zbieranie dowodów przed assessmentem ASPICE.

  • Bez nowych etatów i bez nowego narzędzia

    Działa w Waszym istniejącym ALM — bez migracji i bez nowego systemu do utrzymania.

Jak to mierzymy. Przed pilotażem zapisujemy Wasz punkt odniesienia — godziny przeglądów, ustalenia na etap, poprawki po przeglądzie. Po pilotażu porównujemy na tym samym rodzaju pracy. Liczby powyżej to cele pilotażu, nie wyniki.

Pierwszy tydzień

Najpierw tylko odczyt. Twój proces się nie zmienia, dopóki sam nie zdecydujesz.

  1. Dzień 1

    Podłączenie do Twojego ALM w trybie tylko do odczytu. Nic się jeszcze nie zmienia w Twojej codziennej pracy.

  2. Dzień 2–3

    Pierwsze ustalenia trafiają do kolejki przeglądu — oceniasz je we własnym tempie, obok normalnej pracy.

  3. Koniec tygodnia

    Wspólnie ustalamy, które zadania warto przekazać, a które zostają w pełni ręczne.

Pytania techniczne

Czy SysAssist zastąpi inżyniera systemowego?

Nie. SysAssist przygotowuje, Ty decydujesz. Każda sugestia czeka w kolejce przeglądu — nic nie zapisuje się w Twoim ALM bez zatwierdzenia inżyniera.

Czy tylko sprawdza, czy też pisze wymagania?

Jedno i drugie. Rozpisuje wymagania interesariuszy na szkice wymagań systemowych (SYS.1 → SYS.2), proponuje ich alokację do elementów architektury (SYS.2 → SYS.3), sprawdza istniejące wymagania i przygotowuje szkice testów. Wszystko, co przygotuje, czeka na Twoje zatwierdzenie.

Co jeśli model się myli?

Odrzucasz ustalenie jednym kliknięciem i krótkim uzasadnieniem. Każde ustalenie pokazuje regułę i dowód, na którym się opiera, więc łatwo je ocenić — a odrzucenie zapisuje się jak każda inna decyzja.

Gdzie jest przechowywana historia decyzji?

Przy samym elemencie, jako komentarze w Twoim ALM: ustalenie, decyzja i uzasadnienie. Nie ma osobnego logu do prowadzenia — a podczas assessmentu „dlaczego” jest tuż obok wymagania.

Czy sam tworzy przypadki testowe?

Przygotowuje szkice na podstawie zatwierdzonych wymagań. Szkic pozostaje szkicem, dopóki go nie przejrzysz i nie zatwierdzisz — nic nie powstaje w Twoim systemie testów bez Ciebie.

Gdzie fizycznie są nasze dane?

Zależnie od ustaleń — integracja z silnikiem AI już obecnym w Twojej organizacji (np. Copilot) lub wdrożenie w pełni on-premise.

Jak wygląda pierwszy krok?

Krótki, płatny pilotaż na wąskim, uzgodnionym zadaniu — z jasnymi kryteriami sukcesu ustalonymi przed startem.