REQ-learn
Welcome to the artifact tutorial! This file is written just like artifact markdown files are. Artifact files can be written in a range of formats, the currently supported ones being markdown, toml and yaml.
An artifact file is simply a set of artifacts, each one written like so:
# REQ-NAME
<regular markdown section here>
Artifacts can be a requirement (REQ), design-specification (SPC) or test (TST)
The artifact you are reading now is a requirement, therefore it begins with "REQ".
REQ-markdown
partof:
- REQ-learn
Artifact files like this one are written in a slightly extended markdown format. You can read more about markdown here: http://commonmark.org/help/tutorial/
The "extended" part is that artifact treats the following syntax as special:
# ART-name
<optional SPECIAL yaml section here>
###
<regular markdown section here>
Where ART
is one of REQ
, SPC
, TST
and <optional SPECIAL yaml here>
is
a few items like partof
and done
fields. We will get to those later.
SPC-learn
partof:
- REQ-markdown
Anything starting with SPC is a design specification.
Requirements (REQ) should be used for:
- Detailing what you want your application to do.
- What the architecture of your applicaiton should be.
Specifications (SPC) should be used for:
- How you intend to write your application (lower level details).
There are also tests (TST) which we will learn about later.
SPC-partof
partof:
- REQ-learn
Artifact uses the names of artifacts to automatically link them and track progress. This makes it easy for the user to intuitively link together requirements with their specification and reduces boilerplate.
For instance, [[SPC-learn]]
is automatically a "partof" REQ-learn
because
the names after the type are the same ("-learn").
You can also explicitly link artifacts like so:
# SPC-name
partof:
- SPC-other
- <additional partof>
###
<regular markdown section here>
Here is a graph of valid partof relations between artifacts:
REQ <-- SPC <-- TST
In other words:
- A REQ can be partof a REQ only
- A SPC an be partof a REQ or SPC
- A TST can be partof a REQ, SPC or TST
SPC-valid
There are only a few rules for defining artifacts:
- Case is ignored for all names.
- Names cannot overlap, even in different files.
- All names must start with either REQ, SPC or TST.
TST-definition
TST artifacts (and subartifacts) are used to document test design and are the
only way that an artifact can be considered "tested" (besides the done
field).
Artifact makes it easy to track the "progress" of your application because art ls
(and the web-ui) gives you easy to easy to read completion and tested
percentages for all your artifacts based on which ones are implemented in
source code (more on that later).
SPC-implementing
Artifacts are implemented by putting links anywhere your source code, i.e.
#SPC-name
. There are also subartifacts, i.e. #SPC-name.sub
.
Subartifacts are defined by putting [[.subart]]
anywhere in the text. These
artifacts are used to break down how to implement an artifact in pieces which
should then be linked in code.
Unit tests can be specified by using [[.tst-name]]
. These kind of subarts
contribute to an artifact's tst%
.