Standard File and Directory Set
All files have a JSON Schema: https://github.com/Luftfartsverket/reqstool-client/tree/main/src/reqstool/resources/schemas/v1
For examples see:
reqstool_config.yml
Contains file and directory configuration used by Reqstool
.
The layout of files and directories for a project can change using any of the following types:
-
java-maven: dynamic files are relative "../target" to the static files
-
java-maven-docs: dynamic files are relative "../../target" to the static files
-
custom: custom path to dynamic files can be set relative to the static files
If no reqstool_config.yml file is present in the folder that contains the static files, Reqstool will expect all files and folders, even the dynamic ones, to reside in the path provided to the -p argument when Reqstool is run. This works well with a Maven zip file directory structure.
If you are using a regular Maven project, It is recommended to let all the static files be placed in a folder in the root of the project called 'requirements'. Your reqstool_config.yml file should also be placed in this folder, and would then only need to include the following:
# yaml-language-server: $schema=https://raw.githubusercontent.com/Luftfartsverket/reqstool-client/main/src/reqstool/resources/schemas/v1/reqstool_config.schema.json
type: java-maven
Below is an example on how to change the default paths to the required *.yml files and folders that are generated when the artifact is produced by Maven. The path specified for should be relative to the -p argument that you provide when Reqstool is run.
# yaml-language-server: $schema=https://raw.githubusercontent.com/Luftfartsverket/reqstool-client/main/src/reqstool/resources/schemas/v1/reqstool_config.schema.json
type: custom
locations:
test_results_dirs:
- ../target/some_folder/failsafe
- ../target/my_folder/surefire
annotations:
implementations: ../target/hello/requirements_annotations_impls.yml
tests: ../target/demo/requirements_annotations_tests.yml
requirements.yml
Contains all the requirements.
Below is an example of a requirement.yml file:
metadata:
urn: ms-101
variant: microservice
title: Some Microservice Requirement Title
url: https://url.example.com
requirements:
- id: REQ_101
title: Title REQ_101
significance: may
description: Requirement with automated test and should have no implementation
rationale: Rationale REQ_001
categories: ["maintainability", "functional-suitability"]
implementation: N/A
lifecycle:
state: obsolete
reason: Superseded by REQ_102
revision: 0.0.1
The metadata
of the requirements.yml is required to describe the application.
in the requirements
section, an array of requirements can be specified. Some of the fields are required
Required fields
-
id: Must be unique within the project.
-
title: A title of the requirement.
-
significance: Could be
shall, should`
ormay
. -
description: Short text to describe the requirement.
-
categories: Which categories the requirement relates to.
-
revision: In which version of Reqstool client the requirement was introduced.
Optional fields
-
rationale: Why this requirement is important.
-
implementation: If this requirement requires a source code implementation or not. Currently, there are two acceptable values: in-code or N/A. This defaults to
in-code
if omitted. -
lifecycle: Provides four options: "draft", "effective", "obsolete", "deprecated". Effective is the default if lifecycle is omitted. If set to obsolete or deprecated, reqstool will throw a waring during parsing when a requirement or svc is referenced in code or by other requirements, SVCs, or MVRs.
software_verification_cases.yml
Contains information about how specific requirements should be verified.
One of the fields to be set on a software verification case is the verification type which can be selected from five different pre-defined values (automated-test, manual-test, review, platform, other).
All but the automated-test value expects at least one manual verification entry of that particular software verification case. The automated test value expects at least one automated test should exist and preferably pass.
requirement_annotations.yml
Typically generated by an annotations parser and lists all requirement annotations
JSON Schema |