list-needs

Added in version 5.2.0.

list-needs provides a shorthand notation to create multiple nested needs in one go.

The content of the directive should contain a standard Field Lists block, with each item in the list representing a need.

Similar to the need directive, field name should start with the need type. Proceeding options in the field name can then be specified as white-space delimited; keys with no values (key), keys with simple (non-whitespace) values (key=value), or keys with quoted values (key="value with space").

Allowed field name options are: id, title, status, tags, collapse, delete, hide, layout, style, constraints, needs_extra_options, and needs_extra_links.

Unless specified in the field name parameters, the title is taken as the first paragraph of the field content, and the content is taken as the rest of the field content.

Example 1: Simple list-needs example

.. list-needs::

    :req id=LIST-1a: Need example title

        Need example on level 1.
    :req id=LIST-1b:
        Another Need example with nested needs.

        :spec id=LIST-s2a status=open tags=list-tag1,list-tag2 author="John Doe":
            Sub-Need on level 2 with other options set
        :spec id=LIST-s2b title="Another Sub-Need on level 2.":
            With the title given in the parameters.

            :test id=LIST-s3 collapse: Sub-Need on level 3.

                Content can contain standard *syntax*.
Requirement: Need example title LIST-1a

Need example on level 1.

Requirement: Another Need example with nested needs. LIST-1b
child needs: LIST-s2a, LIST-s2b
Specification: Sub-Need on level 2 with other options set LIST-s2a
status: open
tags: list-tag1, list-tag2
author: John Doe
parent needs: LIST-1b
Specification: Another Sub-Need on level 2. LIST-s2b
parent needs: LIST-1b
child needs: LIST-s3

With the title given in the parameters.

Test Case: Sub-Need on level 3. LIST-s3
parent needs: LIST-s2b

Content can contain standard syntax.

Options

defaults

This option allows you to set default values for all needs in the list, it is parsed as a field list similar to the need directive options. Defaults will be overridden by any options set in the field name.

Example 2: defaults option

.. list-needs::
    :defaults:
        :status: open
        :tags: list-tag1,list-tag2

    :req id=LIST-d1: Need level 1

        :spec id=LIST-d2 status=closed: Sub-Need level 2
Requirement: Need level 1 LIST-d1
status: open
tags: list-tag1, list-tag2
child needs: LIST-d2
Specification: Sub-Need level 2 LIST-d2
status: closed
tags: list-tag1, list-tag2
parent needs: LIST-d1

maxdepth

The maxdepth option allows you to limit the depth of converted field lists.

Example 3: maxdepth option

.. list-needs::
    :maxdepth: 1

    :req id=LIST-m1: Need level 1

        :normal: field list
Requirement: Need level 1 LIST-m1
normal:

field list

flatten

The flatten option will flatten all nested needs into a single list.

It can be used in combination with the links-up and links-down options, to define links by structure, without the final representation being nested.

Example 5: flatten option

.. list-needs::
    :links-down: blocks, triggers
    :links-up: tests, checks
    :flatten:

    :req id=LIST-f1: Need level 1

        :spec id=LIST-f2a: Sub-Need level 2a
        :spec id=LIST-f2b: Sub-Need level 2b

            :test id=LIST-f3: Sub-Need level 3
Requirement: Need level 1 LIST-f1
is tested by: LIST-f2a, LIST-f2b
Specification: Sub-Need level 2a LIST-f2a
is blocked by: LIST-f1
tests: LIST-f1
Specification: Sub-Need level 2b LIST-f2b
is blocked by: LIST-f1
tests: LIST-f1
is checked by: LIST-f3
triggers: LIST-f3
Test Case: Sub-Need level 3 LIST-f3
checks: LIST-f2b
triggered by: LIST-f2b