Diagram wymagań to specjalistyczny narząd wizualizacji inżynieryjnej używany przez architektów systemów, menedżerów produktów i inżynierów oprogramowania do mapowania specyfikacji technicznych, ograniczeń systemowych oraz testów weryfikacyjnych. Opierający się na standardzie SysML (Język modelowania systemów), wbudowanyrequirementDiagramsilnik pozwala Ci łączyć abstrakcyjne wymagania projektowe bezpośrednio z fizycznymi składnikami systemu i przypadkami testowymi za pomocą deklaracji opartych na tekście.
Zrozumienie elementów diagramu wymagań
Diagram wymagań składa się przede wszystkim z dwóch różnych bloków strukturalnych:Blok wymagań (które określają zasady) orazBlok elementów (które modelują kod, sprzęt lub skrypty testowe). Następnie rysuje się relacje między tymi blokami, aby stworzyć jasną macierz śledzenia.
Podstawowa struktura składni
Każdy diagram zaczyna się odrequirementDiagram nagłówka deklaracji. Następnie definiuje się bloki wymagań z zagnieżdżonymi właściwościami, bloki elementów oraz kierunkowe linie relacji.
requirementDiagram
requirement test_req {
id: 1
text: "System musi przetwarzać płatności w sposób bezpieczny."
risk: high
verifymethod: test
}
Pełna taksonomia typów wymagań
Nie wszystkie wymagania inżynieryjne są równe. Silnik oferuje sześć różnych słów kluczowych bloków do wizualnej i semantycznej kategoryzacji Twoich specyfikacji. Każdy typ zmienia etykietę nagłówka wyświetlana w ramce wyrenderowanego diagramu:
requirement: Standardowa lub ogólna specyfikacja systemu.functionalRequirement: Określa działanie lub możliwość behawioralną, którą system musi wykonać.interfaceRequirement: Definiuje punkty połączeń, wymianę danych lub protokoły komunikacji między składnikami.performanceRequirement: Ustala mierzalne metryki wykonania, takie jak prędkość, skalowalność, przepustowość lub pojemność.physicalRequirement: Określa ograniczenia materiałowe, wymiary, wagę lub ograniczenia sprzętowe.ograniczenie projektowe: Ogranicza wybory oprogramowania, stylów architektonicznych, frameworków lub standardów zgodności.
diagramWymogów
ograniczenieProjektowe starszeOgraniczenie {
id: "CON-04"
text: "Backend musi zachować zgodność wsteczną z pipeline'ami PHP 8.2."
risk: niski
verifymethod: inspekcja
}
Dokumentacja składni: Elementy wymogów i modyfikatory
Poniższa tabela rozkłada główne słowa kluczowe semantyczne, wymagane atrybuty oraz struktury klasyfikacji rozpoznawane domyślnie przez interpreter wymogów.
| Składnik składni | Typ wymogu | Opis i obsługiwane atrybuty systemu |
|---|---|---|
| Deklaracja | Identyfikator słowa kluczowego | Inicjuje płótno obszaru roboczego wymogów SysML. Należy użyć dokładniediagramWymogów nagłówek bloku. |
| Atrybut unikalnego identyfikatora | id: Ciąg znaków / Liczba całkowita |
Wymagany parametr zagnieżdżony, który zapewnia indeks śledzenia lub unikalny kod odniesienia alfanumerycznego w ramach systemu śledzenia. Dozwolone są mieszane spacje. |
| Atrybut tekstu | text: Ciąg znaków w cudzysłowach |
Wymagany opisowy ciąg znaków zawierający szczegółowy opis rzeczywistej specyfikacji lub ograniczenia zachowania elementu. Zawsze otaczaj podwójnymi cudzysłowami. |
| Atrybut ryzyka | risk:Flaga poważności |
Opcjonalny znacznik śledzący poziom poważności ryzyka architektonicznego. Akceptuje tokeny poziomu niskiego: niski, średnia, lub wysoka. |
| Atrybut weryfikacji | metoda_weryfikacji:Tag metody |
Parametr opcjonalny określający sposób dowodzenia reguły. Akceptuje standardowe wartości inżynieryjne: analiza, demonstracja, inspekcja, lub test. |
| Element systemu | element Blok |
Deklaruje składnik fizyczny, składnik oprogramowania lub skrypt testowy przy użyciu składni: element nazwa_elementu { typ: "typ_składnika" }. |
Zaawansowane relacje i linki śladu
Główna siła diagramu wymagań polega na łączeniu wymagań z rzeczywistymi systemami. Linki są rysowane za pomocą specjalistycznych, typowanych połączeń strzałkowych (np. - spełnia ->) które ustanawiają jasny cel strukturalny.
Obsługiwane operatory relacji
| Token składni relacji | Znaczenie inżynieryjne strategiczne | Zasada kierunkowego przepływu |
|---|---|---|
źródło - zawiera -> cel |
Rozdziela ogólny wymóg nadrzędny na mniejszy, zagnieżdżony wymóg podrzędny. | Wskazuje od bloku wymogu nadrzędnego w dół do bloku wymogu podrzędnego. |
element - spełnia -> wymóg |
Potwierdza, że fizyczny komponent oprogramowania lub sprzętu pomyślnie spełnia zasade. | Wskazuje od elementu bloku w kierunku docelowego wymogu bloku. |
element - weryfikuje -> wymóg |
Wskazuje, że określony skrypt testowy lub przypadek testowy sprawdza poprawność zasady. | Wskazuje od bloku testowego elementu bloku w kierunku docelowego wymogu bloku. |
źródło - kopiuje -> cel |
Wskazuje na wymóg powielony, który całkowicie odpowiada wymogowi głównemu znajdującemu się w innym miejscu. | Wskazuje od powielonej kopii w kierunku oryginalnego bloku głównego. |
źródło - śledzi -> cel |
Ustanawia szeroką zależność lub relację historyczną między dwoma oddzielnymi wymogami. | Wskazuje od wymogu zależnego w kierunku głównego bloku docelowego. |
źródło - pochodzi od -> cel |
Wskazuje, że wymóg został obliczony lub wygenerowany jako bezpośredni wynik innego wymogu. | Wskazuje od pochodnego bloku potomnego w kierunku bloku nadrzędnego źródłowego. |
źródło - dopasowuje -> cel |
Dodaje dodatkową subtelność lub jasność do bardzo złożonej, wyższej poziomu specyfikacji technicznej. | Wskazuje od dopasowanej specyfikacji w kierunku bloku docelowego bazowego. |
Elementy zdefiniowane przez użytkownika i rozszerzone atrybuty
Oprócz standardowych wymagań, element elementsłowo kluczowe pozwala na mapowanie określonych skryptów aplikacji, elementów sprzętowych lub pakietów firm trzecich na ścieżki śledzenia. Każdy blok elementu może przechowywać niestandardowe właściwości metadanych typu klucz-wartość, wykorzystując schemat typ: wewnątrz klamr klamrowych.
requirementDiagram
element payment_gateway_api {
typ: "Moduł mikroserwisu Stripe"
}
element compliance_audit_log {
typ: "Niezmienna tabela bazy danych"
}
Prawdziwy szablon: Złożona infrastruktura bezpieczeństwa e-commerce
Ten kompleksowy szablon śledzi całą ekosystemę zgodności produkcyjnej. Ilustruje dekompozycję za pomocą zawiera, mapuje ograniczenia wydajności, łączy moduły oprogramowania za pomocą spełnia, a mapuje przypadki testów integracyjnych za pomocą weryfikuje pętli.
requirementDiagram
%% Warstwa hierarchii wymagań
wymaganie security_master_req {
id: "SEC-001"
tekst: "Platforma aplikacji musi utrzymywać ściśle zgodność z normą PCI-DSS."
ryzyko: wysokie
metoda_weryfikacji: test
}
wymaganie_wydajnosci checkout_speed_req {
id: "PERF-22"
tekst: "Rozmowy uwierzytelniające kryptograficzne MFA muszą być kompilowane w czasie poniżej 200ms."
ryzyko: średnie
metoda_weryfikacji: analiza
}
wymaganie_interfejsu secure_token_req {
id: "INT-09"
tekst: "Przesyłki danych API muszą wykorzystywać zaszyfrowane tokeny JSON Web (JWT)."
ryzyko: wysokie
metoda_weryfikacji: test
}
%% Warstwa elementów systemu
element auth_service_code {
typ: "Mikroserwis backendu w Go"
}
element load_tester_script {
typ: "Skrypt wydajności K6"
}
element jwt_validator_test {
typ: "Zestaw jednostkowy integracyjny Jest"
}
%% Ścieżki relacji architektonicznych
security_master_req - zawiera -> checkout_speed_req
security_master_req - zawiera -> secure_token_req
auth_service_code - spełnia -> secure_token_req
load_tester_script - weryfikuje -> checkout_speed_req
jwt_validator_test - weryfikuje -> secure_token_req
Typowe błędy składniowe i ograniczenia systemowe
Podczas kompilowania dokładnych map inżynieryjnych pamiętaj o tych parametrach weryfikacji, aby uniknąć błędów analizy składni:
- Wymagane podwójne cudzysłowy dla ciągów: Bloki tekstu i typy (np.
tekst: "Opis",typ: "Komponent") *muszą* być otoczone podwójnymi cudzysłowami. Użycie pojedynczych cudzysłowów lub pozostawienie ciągów bez cudzysłowów spowoduje awarię kompilatora. - Ścisła składnia atrybutów: Atrybuty w nawiasach muszą używać dwukropków następujących bezpośrednio po wartościach (np.
id: 1). Pominięcie dwukropka lub zapisanie ich w tej samej linii bez odpowiedniego odstępu wcięć może spowodować błędy. - Ograniczona liczba wyborów wartości: Parametr
riskiverifymethodparametry akceptują tylko jawne tokeny systemowe (np.low,medium,highdla risk;analysis,demonstration,inspection,testdla verifymethod). Wpisanie niestandardowych wartości takich jakrisk: extremespowoduje uszkodzenie konstruktora układu. - Integralność odstępu strzałek: Linie kierunkowe muszą być wpisywane z odstępem spacją otaczającą operatory (np.
A - satisfies -> B). Skompaktowanie ciągu wA-satisfies->Busunie wyjątki przetwarzania systemu.