Kravdiagram
Et kravdiagram gir en visualisering av krav og deres innbyrdes koblinger, samt relasjoner til andre dokumentelementer.
Kopier
Bygg inn
requirementDiagram
requirement test_req {
id: 1
text: the test text.
risk: high
verifymethod: test
}
element test_entity {
type: simulation
}
test_entity - satisfies -> test_req
Syntaks
Et kravdiagram inneholder tre typer komponenter: krav, elementer og relasjoner.
Ord i vinkelparenteser er enumerasjonsnøkkelord, som , og alternativene deres er forklart i detalj i tabellen. user_defined... brukes der brukerinndata kreves.
Viktig merknad om brukertekst: all inndata kan omsluttes av doble anførselstegn, eller stå uten. Brukeren må imidlertid være forsiktig når inndata ikke er satt i anførselstegn. Hvis andre nøkkelord oppdages, vil editoren mislykkes i rendringen.
Krav
En kravdefinisjon inneholder kravtype, navn, ID, tekst, risiko og verifiseringsmetode. Syntaksen er som følger:
Kopier
Bygg inn
<type> user_defined_name {
id: user_defined_id
text: user_defined text
risk: <risk>
verifymethod: <method>
}
Type, risiko og metode er enumerasjoner definert i SysML.
| Nøkkelord | Alternativer |
|---|---|
| Type | Krav, funksjonelt krav, grensesnittkrav, ytelseskrav, fysisk krav, designbegrensning |
| Risiko | Lav, middels, høy |
| Verifiseringsmetode | Analyse, inspeksjon, test, demonstrasjon |
Element
En elementdefinisjon inneholder elementnavn, type og dokumentreferanse, og alle tre er brukerdefinerte. Elementfunksjonen er ment å være lettvektig, samtidig som den lar krav knyttes til deler av andre dokumenter.
Kopier
Bygg inn
element myElement {
type: string
docref: some/doc/path
}
Markdown-format
Der brukere kan tilpasse tekst (som navn, kravtekst, elementdokumentreferanse osv.), kan du:
- Omslutte teksten med doble anførselstegn
- Bruke markdown-format inne i de doble anførselstegnene
Kopier
Bygg inn
requirementDiagram
requirement "__test_req__" {
id: 1
text: "*italicized text* **bold text**"
risk: high
verifymethod: test
}
Relasjon
En relasjon består av en kildenode, en målnode og en relasjonstype.
Følg følgende definisjonsformat:
Kopier
Bygg inn
{name of source} - <type> -> {name of destination}
eller
Kopier
Bygg inn
{name of destination} <- <type> - {name of source}
"kildenode" og "målnode" skal være navnene på krav- eller elementnoder definert andre steder.
Relasjonstypen kan være én av inneholder, kopierer, utleder, oppfyller, verifiserer, foredler eller sporer.
Detaljert eksempel
Dette eksempelet bruker alle funksjonene i diagrammet.
Kopier
Bygg inn
requirementDiagram
requirement test_req {
id: 1
text: the test text.
risk: high
verifymethod: test
}
functionalRequirement test_req2 {
id: 1.1
text: the second test text.
risk: low
verifymethod: inspection
}
performanceRequirement test_req3 {
id: 1.2
text: the third test text.
risk: medium
verifymethod: demonstration
}
interfaceRequirement test_req4 {
id: 1.2.1
text: the fourth test text.
risk: medium
verifymethod: analysis
}
physicalRequirement test_req5 {
id: 1.2.2
text: the fifth test text.
risk: medium
verifymethod: analysis
}
designConstraint test_req6 {
id: 1.2.3
text: the sixth test text.
risk: medium
verifymethod: analysis
}
element test_entity {
type: simulation
}
element test_entity2 {
type: word doc
docRef: reqs/test_entity
}
element test_entity3 {
type: "test suite"
docRef: github.com/all_the_tests
}
test_entity - satisfies -> test_req2
test_req - traces -> test_req2
test_req - contains -> test_req3
test_req3 - contains -> test_req4
test_req4 - derives -> test_req5
test_req5 - refines -> test_req6
test_entity3 - verifies -> test_req5
test_req <- copies - test_entity2
Retning
Du kan bruke direction -setningen til å rendre diagrammet i ulike retninger, gyldige verdier er:
- TB - fra topp til bunn (standard)
- BT - fra bunn til topp
- LR - fra venstre til høyre
- RL - fra høyre til venstre
Kopier
Bygg inn
requirementDiagram
direction LR
requirement test_req {
id: 1
text: the test text.
risk: high
verifymethod: test
}
element test_entity {
type: simulation
}
test_entity - satisfies -> test_req
Stil
Krav og elementer kan styles ved hjelp av direkte stil eller klasser. Generelt godtar den, når en stil eller klasse brukes, en liste over krav- eller elementnavn og en liste over klassenavn, noe som gjør det mulig å tildele flere klasser samtidig. Det eneste unntaket er snarveissyntaksen ::: , der operatoren kan tildele flere klasser, men bare til ett krav eller element om gangen.
Direkte stil
Kopier
Bygg inn
requirementDiagram
requirement test_req {
id: 1
text: styling example
risk: low
verifymethod: test
}
element test_entity {
type: simulation
}
style test_req fill:#ffa,stroke:#000, color: green
style test_entity fill:pink,stroke:#333, color: blue
Klassedefinisjonen vises i følgende eksempel:
Bruk classDef til å definere gjenbrukbare stiler:
Kopier
Bygg inn
requirementDiagram
requirement test_req {
id: 1
text: "class styling example"
risk: low
verifymethod: test
}
element test_entity {
type: simulation
}
classDef important fill:#f96,stroke:#333,stroke-width:4px
classDef test fill:#ffa,stroke:#000
Standardklasse
Hvis en klasse heter default , brukes den på alle noder. Bestemte stiler og klasser bør defineres etter dette for å overstyre den anvendte standardstilen.
Kopier
Bygg inn
classDef default fill:pink,stroke:#333,stroke-width:4px;
Bruksklasse
Klasser kan brukes på to måter:
1. Bruk class -syntaksen:
Kopier
Bygg inn
class test_req,test_entity important
2. Bruk snarveissyntaksen med ::: -operatoren under eller etter definisjonen:
Kopier
Bygg inn
requirement test_req:::important {
id: 1
text: class styling example
risk: low
verifymethod: test
}
Kopier
Bygg inn
element test_elem {}
test_elem:::myClass
Kombinasjonseksempel
Kopier
Bygg inn
requirementDiagram
requirement test_req:::important {
id: 1
text: "class styling example"
risk: low
verifymethod: test
}
element test_entity {
type: simulation
}
classDef important font-weight:bold
class test_entity important
style test_entity fill:pink,stroke:#333
