Jedna karta wymagania łączy czynność prawną z obserwowalnym wynikiem systemu
Karta wymagania nie zastępuje analizy prawnej ani projektu technicznego. Łączy ich wyniki w formie, którą można wycenić i przetestować. Twórz osobną kartę dla każdego przypadku o innym odbiorcy, podstawie, rodzaju podpisu lub kanale. Kopiowanie jednej odpowiedzi do wszystkich dokumentów ukrywa różnice.
Pole 1. Czynność, skutek i źródło wymagania
Nazwij oświadczenie i oczekiwany skutek: zawarcie umowy, zgoda, zatwierdzenie, złożenie pisma albo wewnętrzna decyzja. Wskaż przepis, postanowienie umowy, regulamin lub instrukcję odbiorcy, z których wynika forma i kanał. Zapisz datę weryfikacji oraz właściciela interpretacji.
Nie wystarczy zdanie „wymagany podpis elektroniczny”. Karta powinna rozróżnić ogólną kategorię, podpis zaawansowany, kwalifikowany lub mechanizm krajowy, jeżeli konkretny proces go przewiduje. W przypadku formy szczególnej albo sprzecznych instrukcji zatrzymaj projekt i wyjaśnij wymaganie przed wyborem produktu.
Pole 2. Osoba, rola i reprezentacja
Wypisz podpisującego, podmiot reprezentowany i źródło umocowania. Określ, czy potrzebny jest podpis jednej osoby, reprezentacja łączna, pełnomocnictwo albo dodatkowa akceptacja. Ustal chwilę i źródło sprawdzenia, bo dane reprezentacji mogą zmieniać się niezależnie od certyfikatu.
Certyfikat może wspierać identyfikację, ale nie opisuje automatycznie wszystkich granic działania. System powinien pozwolić połączyć podpis z wynikiem kontroli roli bez wkładania zbędnych danych do dokumentu lub logu.
Pole 3. Zestaw danych przedstawiony do podpisu
Zamknij listę dokumentów i załączników. Każdy element ma identyfikator wersji, format, źródło i sposób podglądu. Karta mówi, czy podpis obejmuje jeden plik, kontener, manifest czy zestaw powiązanych podpisów. Jeżeli załącznik jest tylko wspomniany w treści, nie zakładaj, że kryptograficznie znalazł się w zakresie.
Widok i obiekt muszą pozostać zgodne
Osoba zatwierdza to, co może przeczytać, a mechanizm podpisuje dane. Test musi wykazać, że podgląd odpowiada obiektowi i że zmiana pomiędzy tymi krokami jest wykrywana. Dla dokumentów generowanych zapisuj wersję szablonu i danych, lecz nie zastępuj nimi zachowania końcowego artefaktu.
Pole 4. Format, profil i współpraca narzędzi
Wskaż dopuszczalny format podpisu, wariant osadzenia oraz wymagania odbiorcy. Podaj, czy rozwiązanie ma obsłużyć wiele podpisów, podpis odłączony, kontener, znaczniki czasu i dane do długoterminowej walidacji. Nie twórz formatu przez zmianę rozszerzenia ani przez wydruk podpisanego dokumentu do nowego PDF.
Przy integracji zewnętrznej ustal wersje interfejsu, limity, kodowanie błędów i identyfikator korelacyjny. Interoperacyjność potwierdza test artefaktu u rzeczywistego odbiorcy lub w zgodnym środowisku, nie sama deklaracja nazwy standardu.
Pole 5. Walidacja i decyzja po wyniku
Zdefiniuj moment: natychmiast po podpisie, przy odbiorze, przed wykonaniem czynności i ponownie w archiwum. Podaj źródła zaufania, politykę, raportowane składniki i słownik statusów. Dla każdego statusu zapisz następny krok: przyjęcie, odrzucenie techniczne, ponowne sprawdzenie albo ręczne wyjaśnienie.
Kwalifikowany status dokładnej usługi ocenia się z użyciem właściwej zaufanej listy i jej historii. Logo, aktywny certyfikat witryny czy ogólny wpis firmy nie zastępują tego sprawdzenia.
Pole 6. Przekazanie, dowody i przechowywanie
Określ kanał odbiorcy, format zgłoszenia, identyfikator i potwierdzenie. Osobno zapisz dowód podpisu, czasu i przekazania. Retencja powinna wynikać z celu, obowiązków i ryzyka; obejmuje również raporty, logi i kopie. Dane osobowe w artefaktach oraz telemetrii podlegają ograniczeniu dostępu i zakresu.
Plan długoterminowy opisuje ponowną walidację, zachowanie danych potrzebnych do oceny, migrację oraz ewentualną usługę konserwacji lub archiwizacji. Nie każdy dokument wymaga usługi kwalifikowanej, a zwykłe repozytorium nie staje się nią przez długi okres przechowywania.
Pole 7. Awaria, wyjście i właściciel decyzji
Zapisz zachowanie po braku usługi, przerwaniu autoryzacji, utracie odpowiedzi i niezgodności raportu. Powtórzenie nie może tworzyć dwóch niezależnych oświadczeń bez wiedzy użytkownika. Ustal również eksport, terminy dostępu po zakończeniu umowy, usunięcie danych i możliwość weryfikacji bez panelu dostawcy.
Gotowa karta ma jednoznaczne kryteria i właścicieli pól. Jeśli odpowiedź zależy od przyszłej decyzji, jest to jawna zależność z terminem, nie domyślna funkcja.