Introduction to Sphinx-Needs
Define a Need
Documentation: How-to work with Sphinx-Needs Need [1].
Example 1: How-to create a Need.
.. req:: Example Requirement
:id: R_EXAMPLE_REQUIREMENT
:status: new
This is our example requirement.
.. spec:: Example Specification
:id: S_EXAMPLE_SPECIFICATION
:status: new
:links: R_EXAMPLE_REQUIREMENT
This is our example Specification.
This is our example requirement. |
This is our example Specification. |
Minimum need
With needs_title_optional it is even possible to skip the title.
So the bare minimum need only has a :id:.
Rendering of a fully defined need
Example 3: Fully defined need Need.
.. need:: The title of the need gives some basic context
:id: N_FULLY_NEED
:status: draft
:tags: my_tags
Here we can write our content.
It is possible to use multiple blocks of text, seperated by empty new lines.
| We can even detail
| where we have textual line breaks within the block.
We can add pictures:
.. figure:: pictures/avatar.png
:scale: 100 %
:alt: My avatar
First line is the caption of the figure (a simple paragraph).
A legend consists of all elements after the caption.
And tables:
.. table:: Truth table for "not"
:widths: auto
:align: center
===== =====
A not A
===== =====
False True
True False
===== =====
And many more. See the following examples.
Here we can write our content. It is possible to use multiple blocks of text, seperated by empty new lines. We can even detail
where we have textual line breaks within the block.
We can add pictures: Fig. 20 First line is the caption of the figure (a simple paragraph). A legend consists of all elements after the caption. And tables:
And many more. See the following examples. |
Types
Documentation: How-to configure Sphinx-Needs Types [2].
Options
Documentation: How-to configure Sphinx-Needs Options [3].
The special option :id:, has to be unique within the current project.
It is often useful, you write self speaking id’s which even can be easily reviewed.
Additionally you can use auto generated ids via IDE extension or scripting see https://github.com/useblocks/sphinx-needs/issues/728.
A discussion how ID’s could be generated across organisations is currently ongoing in https://github.com/useblocks/sphinx-needs/discussions/1088#discussioncomment-8131189.
Links
Documentation: How-to configure Sphinx-Needs Links [4].
Reference to Needs
Documentation: How-to use Sphinx-Needs Reference to Needs [5].
Example 4: Reference to Needs
:need:`R_EXAMPLE_REQUIREMENT` is here like a customer requirement,
where the :need:`[[title]] in [[status]] ([[id]]) <S_EXAMPLE_SPECIFICATION>` is our derived specification.
Example Requirement (R_EXAMPLE_REQUIREMENT) is here like a customer requirement, where the Example Specification in new (S_EXAMPLE_SPECIFICATION) is our derived specification.
Embedded a Need in a Need
Example 5: Embedded a Need in a Need
.. need:: Parent
:id: N_PARENT
Here is some text before the embedded need. You could even write any other rst text.
.. need:: Child
:id: N_CHILD
Here is some text inside of the embedded need. You could even write any other rst text.
Here is some text after the embedded need. You could even write any other rst text.
NeedPart
Example 6: Need with needpart, linking to parts and filter
.. need:: Test need with need parts
:id: N_NEED_WITH_PARTS
:tags: needpart_example
:np:`(precondition)` of the need.
:np:`(2) Part 2 of need`.
Part :np:`(3)`: Here is your thired part of need.
.. need:: Need links to part 1
:id: N_LINK_TO_PART1
:tags: needpart_example
:links: N_NEED_WITH_PARTS.precondition
.. need:: Need links to part 2 and 3
:id: N_LINK_TO_PART2
:tags: needpart_example
:links: N_NEED_WITH_PARTS.2, N_NEED_WITH_PARTS.3
We link to :need:`N_NEED_WITH_PARTS.2` and :need:`N_NEED_WITH_PARTS.3`.
.. needtable::
:tags: needpart_example
:filter: is_need
:show_parts:
:columns: id;title;outgoing;incoming
:style: table
precondition of the need. Part 2 of need 2. Part 3: Here is your thired part of need. |
We link to Part 2 of need (N_NEED_WITH_PARTS.2) and (N_NEED_WITH_PARTS.3). |
ID |
Title |
Outgoing |
Incoming |
|---|---|---|---|
Need links to part 1 |
|||
Need links to part 2 and 3 |
|||
Test need with need parts |
|||
→ |
|||
→ Part 2 of need |
|||
→ |
External Projects
To reuse needs from another project, you can use the following possibilities:
needs_external_needs
With needs_external_needs you can import the needs.json from another project. The needs are available in the memory of the current Sphinx-Needs build, but all links jump to another web-project / web-server.
We have add an external project already referenced within this documentation:
408needs_external_needs = [
409 {
410 'base_url': 'https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io',
411 'json_url': 'https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/needs.json',
412 'css_class': 'external_link',
413 },
414]
Needs are read from the other project, marked as external, and can be used as they would be created within this project. You can find filters, which use the imported needs in all following reports.
needimport
You can even import the needs with needimport from another project,
but the needs are rendered within your project.
Documentation: How-to import needs with needimport.
Example 7: How-to import a Need.
.. needimport:: example_needs.json
:id_prefix: imp_
:tags: imported
:template: extend_template
Keep my test text. Reject Reason added during needimport: Reject Reason copied with dynamic function: | Here I add a multi line reject reason. | First line | Second line |
We do use here a template, to make the reject_reason available to the content of the need.
The reject_reason is been set in the needextend in the next chapter.
In the template extend_template we access to the reject reason:
1{# Place the original content here #}
2{{content}}
3
4
5**Reject Reason added during needimport:**
6{{reject_reason}}
7
8**Reject Reason copied with dynamic function:**
9:ndf:`copy('reject_reason', '{{id}}')`
You can find the documentation of the option template for needimport in
needimport customization.
You can find the documentation of the option template for need in need template.
You can find the documentation of dynamic functions and the copy function especially in dynamic functions.
How-to change a need with needextend
Documentation: How-to extend needs with needextend.
Here we extend the imported needs from previous chapter with additional information.
Example 8: How-to extend a Need.
.. needextend:: imp_test_item
:status: implemented
:reject_reason:
| Here I add a multi line reject reason.
| First line
| Second line
Challenges
The issue with needextend is, how to ensure the final output is correct. Here it is often necessary to protect attributes for changes with needextend via needs_warnings. See Monitoring modifications.
Filter
Documentation: How-to use Sphinx-Needs Filters [6].
We use these filters in different examples within this document in the following reports.
NeedPie
Documentation: How-to use Sphinx-Needs NeedPie [7].
Example 9: How-to use a NeedPie.
.. needpie:: Ratio of requirement types
:labels: Stakeholder Requirement, Software Requirement, Evaluation
type == 'stake_req' and is_external == True
type == 'sw_req' and is_external == True
type == 'evaluation' and is_external == True
NeedBar
Documentation: How-to use Sphinx-Needs NeedBar [8].
Example 10: How-to use a NeedBar.
.. needbar:: Requirements & Status Overview
:legend:
:colors: black, yellow, orange, green
:xlabels: FROM_DATA
:ylabels: FROM_DATA
, Stakeholder Requirement , Software Requirement
empty, type=='stake_req' and status=='' , type=='sw_req' and status==''
accepted, type=='stake_req' and status=='accepted' , type=='sw_req' and status=='accepted'
implemented, type=='stake_req' and status=='implemented', type=='sw_req' and status=='implemented'
verified, type=='stake_req' and status=='verified' , type=='sw_req' and status=='verified'
NeedTable
Documentation: How-to use Sphinx-Needs NeedTable [9].
Example 11: How-to use a NeedTable.
.. needtable:: List of software requirements
:types: sw_req
:style: table
:columns: id; title; status
ID |
Title |
Status |
|---|---|---|
Allow double definitions of same Key / Value |
verified |
|
Detect merge conflicts |
verified |
|
Definition: list of dictionaries |
verified |
|
Merge python dictionaries |
verified |
|
Name of the tool: merge_dicts |
verified |
|
Output in merge conflict case |
verified |
Example 12: How-to use a NeedTable II.
.. needtable:: List of stakeholder requirements
:types: stake_req
:style: datatables
:columns: id; title; status; is_external as "External"
ID |
Title |
Status |
External |
|---|---|---|---|
Configuration item |
new |
False |
|
Software item |
new |
False |
|
Integrated software |
new |
False |
|
Application parameter |
new |
False |
|
Contract |
new |
False |
|
Contract |
new |
False |
|
Commitment/agreement |
new |
False |
|
Commitment / agreement |
new |
False |
|
Interface agreement |
new |
False |
|
Data |
new |
False |
|
Benchmarking data |
new |
False |
|
Customer satisfaction data |
new |
False |
|
Process performance data |
new |
False |
|
Design |
new |
False |
|
Domain architecture |
new |
False |
|
Domain model |
new |
False |
|
Software architectural design |
new |
False |
|
Software architectural design |
new |
False |
|
Software detailed design |
new |
False |
|
Software detailed design |
new |
False |
|
System architectural design |
new |
False |
|
System architectural design |
new |
False |
|
Goals |
new |
False |
|
User documentation |
new |
False |
|
Customer manual |
new |
False |
|
Handling and storage guide |
new |
False |
|
Training material |
new |
False |
|
Measure |
new |
False |
|
Customer satisfaction survey |
new |
False |
|
Field measure |
new |
False |
|
Personnel performance measure |
new |
False |
|
Process measure |
new |
False |
|
Project measure |
new |
False |
|
Quality measure |
new |
False |
|
Risk measure |
new |
False |
|
Risk measure |
new |
False |
|
Service level measure |
new |
False |
|
Plan |
new |
False |
|
Configuration management plan |
new |
False |
|
Project plan |
new |
False |
|
Quality plan |
new |
False |
|
Recovery plan |
new |
False |
|
Recovery plan |
new |
False |
|
Release plan |
new |
False |
|
Reuse plan |
new |
False |
|
Review plan |
new |
False |
|
Risk management plan |
new |
False |
|
Risk management plan |
new |
False |
|
Risk mitigation plan |
new |
False |
|
Risk mitigation plan |
new |
False |
|
Documentation plan |
new |
False |
|
Problem management plan |
new |
False |
|
Change management plan |
new |
False |
|
Improvement plan |
new |
False |
|
Test specification |
new |
False |
|
Test specification |
new |
False |
|
Technology monitoring plan |
new |
False |
|
Test plan |
new |
False |
|
Test plan |
new |
False |
|
Policy |
new |
False |
|
Reuse policy |
new |
False |
|
Process description |
new |
False |
|
Product |
new |
False |
|
Product release information |
new |
False |
|
Product release package |
new |
False |
|
Software unit |
new |
False |
|
Software unit |
new |
False |
|
System |
new |
False |
|
Temporary solution |
new |
False |
|
Proposal |
new |
False |
|
Request for quotation |
new |
False |
|
Request for proposal |
new |
False |
|
Reuse proposal |
new |
False |
|
Supplier proposal response |
new |
False |
|
Record |
new |
False |
|
Acceptance record |
new |
False |
|
Acceptance record |
new |
False |
|
Communication record |
new |
False |
|
Communication record |
new |
False |
|
Contract review record |
new |
False |
|
Delivery record |
new |
False |
|
Problem record |
new |
False |
|
Baseline |
new |
False |
|
Meeting support record |
new |
False |
|
Configuration management record |
new |
False |
|
Product release approval record |
new |
False |
|
Progress status record |
new |
False |
|
Progress status record |
new |
False |
|
Proposal review record |
new |
False |
|
Change request |
new |
False |
|
Change request |
new |
False |
|
Customer request |
new |
False |
|
Quality record |
new |
False |
|
Review record |
new |
False |
|
Review record |
new |
False |
|
Risk action request |
new |
False |
|
Risk action request |
new |
False |
|
Change control record |
new |
False |
|
Traceability record |
new |
False |
|
Traceability record |
new |
False |
|
Validation results |
new |
False |
|
Validation results |
new |
False |
|
Verification results |
new |
False |
|
Verification results |
new |
False |
|
Test results |
new |
False |
|
Test results |
new |
False |
|
Register |
new |
False |
|
Change history |
new |
False |
|
Corrective action register |
new |
False |
|
Corrective action register |
new |
False |
|
Preferred suppliers register |
new |
False |
|
Preferred suppliers register |
new |
False |
|
Schedule |
new |
False |
|
Tracking system |
new |
False |
|
Tracking system |
new |
False |
|
Work breakdown structure |
new |
False |
|
Work product list |
new |
False |
|
Stakeholder groups list |
new |
False |
|
Cybersecurity scenario register |
new |
False |
|
Asset library |
new |
False |
|
Report |
new |
False |
|
Analysis report |
new |
False |
|
Analysis report |
new |
False |
|
Configuration status report |
new |
False |
|
Evaluation report |
new |
False |
|
Project status report |
new |
False |
|
Reuse evaluation report |
new |
False |
|
Risk analysis report |
new |
False |
|
Risk analysis report |
new |
False |
|
Risk status report |
new |
False |
|
Risk status report |
new |
False |
|
Problem status report |
new |
False |
|
Assessment/audit report |
new |
False |
|
Improvement opportunity |
new |
False |
|
Process performance report |
new |
False |
|
Supplier evaluation report |
new |
False |
|
Supplier evaluation report |
new |
False |
|
Vulnerability analysis report |
new |
False |
|
Repository |
new |
False |
|
Configuration management system |
new |
False |
|
Process repository |
new |
False |
|
Requirement specification |
new |
False |
|
Build list |
new |
False |
|
Stakeholder requirements |
new |
False |
|
Documentation requirements |
new |
False |
|
Interface requirements specification |
new |
False |
|
Software requirements specification |
new |
False |
|
Software requirements specification |
new |
False |
|
System requirements specification |
new |
False |
|
System requirements specification |
new |
False |
|
Verification criteria |
new |
False |
|
Cybersecurity goals |
new |
False |
|
Cybersecurity controls |
new |
False |
|
Standard |
new |
False |
|
Acceptance criteria |
new |
False |
|
Product release criteria |
new |
False |
|
Quality criteria |
new |
False |
|
Supplier evaluation criteria |
new |
False |
|
Supplier qualification criteria |
new |
False |
|
Strategy |
new |
False |
|
Reuse strategy |
new |
False |
|
Verification strategy |
new |
False |
|
Verification strategy |
new |
False |
|
Validation strategy |
new |
False |
|
Validation strategy |
new |
False |
|
Template |
new |
False |
|
Work product |
new |
False |
|
Technical Requirements |
new |
False |
|
ACQ.11.BP1: Elicit needs. |
new |
False |
|
ACQ.11.BP10: Ensure compliance of stated requirements. |
new |
False |
|
ACQ.11.BP2: Define technical requirements. |
new |
False |
|
ACQ.11.BP3: Identify acquisition needs. |
new |
False |
|
ACQ.11.BP4: Ensure consistency. |
new |
False |
|
ACQ.11.BP5: Identify affected groups. |
new |
False |
|
ACQ.11.BP6: Communicate to affected groups. |
new |
False |
|
ACQ.11.BP7: Establish a change mechanism. |
new |
False |
|
ACQ.11.BP8: Track impact of changing technology. |
new |
False |
|
ACQ.11.BP9: Identify constraints and standards. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Legal and Administrative Requirements |
new |
False |
|
ACQ.12.BP1: Identify relevant regulations. |
new |
False |
|
ACQ.12.BP10: Establish criteria for liability issues. |
new |
False |
|
ACQ.12.BP2: Consider relevant regulations. |
new |
False |
|
ACQ.12.BP3: Agree on (contractual) terms and conditions. |
new |
False |
|
ACQ.12.BP4: Ensure usage of agreed terms and conditions. |
new |
False |
|
ACQ.12.BP5: Establish acceptance criteria. |
new |
False |
|
ACQ.12.BP6: Establish escalation mechanisms. |
new |
False |
|
ACQ.12.BP7: Establish management of intellectual property rights. |
new |
False |
|
ACQ.12.BP8: Provide for warranties and service level agreements. |
new |
False |
|
ACQ.12.BP9: Define provision for the suppliers. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
Project Requirements |
new |
False |
|
ACQ.13.BP1: Identify relevant groups. |
new |
False |
|
ACQ.13.BP10: Establish payment requirements. |
new |
False |
|
ACQ.13.BP11: Identify risks. |
new |
False |
|
ACQ.13.BP12: Communicate risks. |
new |
False |
|
ACQ.13.BP13: Define ownership of relationships. |
new |
False |
|
ACQ.13.BP14: Define rights for use and distribution. |
new |
False |
|
ACQ.13.BP15: Establish support and maintenance requirements. |
new |
False |
|
ACQ.13.BP2: Communicate with relevant groups. |
new |
False |
|
ACQ.13.BP3: Define organizational requirements. |
new |
False |
|
ACQ.13.BP4: Define management requirements. |
new |
False |
|
ACQ.13.BP5: Identify required competency. |
new |
False |
|
ACQ.13.BP6: Define responsibilities and goals. |
new |
False |
|
ACQ.13.BP7: Identify information needs. |
new |
False |
|
ACQ.13.BP8: Define exchange of information. |
new |
False |
|
ACQ.13.BP9: Establish criteria for interim work products. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
9 |
new |
False |
|
Request for Proposals |
new |
False |
|
ACQ.14.BP1: Define rules for CFP / ITT. |
new |
False |
|
ACQ.14.BP2: Assemble requirements. |
new |
False |
|
ACQ.14.BP3: Establish terms and conditions for CFP / ITT. |
new |
False |
|
ACQ.14.BP4: Define financial terms. |
new |
False |
|
ACQ.14.BP5: Define project terms. |
new |
False |
|
ACQ.14.BP6: Define technical terms. |
new |
False |
|
ACQ.14.BP7: Identify relevant regulations. |
new |
False |
|
ACQ.14.BP8: Prepare and issue a CFP / ITT. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
Supplier Qualification |
new |
False |
|
ACQ.15.BP1: Establish qualification criteria. |
new |
False |
|
ACQ.15.BP2: Evaluate supplier. |
new |
False |
|
ACQ.15.BP3: Short-list suppliers with required qualification. |
new |
False |
|
ACQ.15.BP4: Evaluate any shortfalls. |
new |
False |
|
ACQ.15.BP5: Perform corrective actions. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
Supplier request and selection |
new |
False |
|
ACQ.2.BP1: Establish supplier evaluation criteria. |
new |
False |
|
ACQ.2.BP2: Evaluate potential suppliers. |
new |
False |
|
ACQ.2.BP3: Prepare and execute request for quotation |
new |
False |
|
ACQ.2.BP4: Negotiate and award the contract/agreement. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
Contract Agreement |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
Supplier Monitoring |
new |
False |
|
ACQ.4.BP1: Agree on and maintain jointprocesses, |
new |
False |
|
ACQ.4.BP2: Exchange all agreed information. |
new |
False |
|
ACQ.4.BP3: Review technical development with the supplier. |
new |
False |
|
ACQ.4.BP4: Review progress of the supplier. |
new |
False |
|
ACQ.4.BP5: Act to correct deviations. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
ACQ.3.BP1: Negotiate the contract/agreement. |
new |
False |
|
ACQ.3.BP2: Specify rights and duties. |
new |
False |
|
ACQ.3.BP3: Review contract/agreement for supplier \ capability monitoring. |
new |
False |
|
ACQ.3.BP4: Review contract/agreement for risk mitigation \ actions. |
new |
False |
|
ACQ.3.BP5: Approve contract/agreement. |
new |
False |
|
ACQ.3.BP6: Award contract/agreement. |
new |
False |
|
ACQ.3.BP7: Communicate result to tenderers. |
new |
False |
|
Detect merge conflicts |
accepted |
True |
|
Merge python dictionaries |
accepted |
True |
|
Test Item |
implemented |
False |
|
Project Management |
new |
False |
|
MAN.3.BP1: Define the scope of work. |
new |
False |
|
MAN.3.BP10: Review and report progress of the project. |
new |
False |
|
MAN.3.BP2: Define project life cycle. |
new |
False |
|
MAN.3.BP3: Evaluate feasibility of the project. |
new |
False |
|
MAN.3.BP4: Define, monitor and adjust project activities. |
new |
False |
|
MAN.3.BP5: Define, monitor and adjust project estimates and resources. |
new |
False |
|
MAN.3.BP6: Ensure required skills, knowledge, and experience. |
new |
False |
|
MAN.3.BP7: Identify, monitor and adjust project interfaces and agreed commitments. |
new |
False |
|
MAN.3.BP8: Define, monitor and adjust project schedule. |
new |
False |
|
MAN.3.BP9: Ensure consistency. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
Risk Management |
new |
False |
|
MAN.5.BP1: Establish risk management scope. |
new |
False |
|
MAN.5.BP2: Define risk management strategies. |
new |
False |
|
MAN.5.BP3: Identify risks. |
new |
False |
|
MAN.5.BP4: Analyze risks. |
new |
False |
|
MAN.5.BP5: Define risk treatment actions. |
new |
False |
|
MAN.5.BP6: Monitor risks. |
new |
False |
|
MAN.5.BP7: Take corrective action. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Measurement |
new |
False |
|
MAN.6.BP1: Establish organizational commitment for measurement. |
new |
False |
|
MAN.6.BP10: Evaluate information products and measurement activities. |
new |
False |
|
MAN.6.BP11: Communicate potential improvements. |
new |
False |
|
MAN.6.BP2: Develop measurement strategy. |
new |
False |
|
MAN.6.BP3: Identify measurement information needs. |
new |
False |
|
MAN.6.BP4: Specify measures. |
new |
False |
|
MAN.6.BP5: Perform measurement activities. |
new |
False |
|
MAN.6.BP6: Retrieve measurement data. |
new |
False |
|
MAN.6.BP7: Analyze measures. |
new |
False |
|
MAN.6.BP8: Use measurement information for decision-making. |
new |
False |
|
MAN.6.BP9: Communicate measures. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
Cybersecurity Risk Management |
new |
False |
|
MAN.7.BP1: Determine cybersecurity risk management scope. |
new |
False |
|
MAN.7.BP2: Define cybersecurity risk management practices. |
new |
False |
|
MAN.7.BP3: Identify potential risks. |
new |
False |
|
MAN.7.BP4: Prioritize potential risks initially for damage. |
new |
False |
|
MAN.7.BP5: Analyze potential risks and evaluate risks. |
new |
False |
|
MAN.7.BP6: Define risk treatment option. |
new |
False |
|
MAN.7.BP7: Monitor risks. |
new |
False |
|
MAN.7.BP8: Take corrective action. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
Process Improvement |
new |
False |
|
PIM.3.BP1: Establish commitment. |
new |
False |
|
PIM.3.BP2: Identify issues. |
new |
False |
|
PIM.3.BP3: Establish process improvement goals. |
new |
False |
|
PIM.3.BP4: Prioritize improvements. |
new |
False |
|
PIM.3.BP5: Plan process changes. |
new |
False |
|
PIM.3.BP6: Implement process changes. |
new |
False |
|
PIM.3.BP7: Confirm process improvement. |
new |
False |
|
PIM.3.BP8: Communicate results of improvement. |
new |
False |
|
PIM.3.BP9: Evaluate the results of the improvement project. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
Reuse Program Management |
new |
False |
|
REU.2.BP1: Define organizational reuse strategy. |
new |
False |
|
REU.2.BP3: Assess domains for potential reuse. |
new |
False |
|
REU.2.BP4: Assess reuse maturity. |
new |
False |
|
REU.2.BP5: Evaluate reuse proposals. |
new |
False |
|
REU.2.BP6: Implement the reuse program. |
new |
False |
|
REU.2.BP7: Get feedback from reuse. |
new |
False |
|
REU.2.BP8: Monitor reuse. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
Cybersecurity Requirements Elicitation |
new |
False |
|
SEC.1.BP1: Derive cybersecurity goals and cybersecurity requirements. |
new |
False |
|
SEC.1.BP2: Establish bidirectional traceability. |
new |
False |
|
SEC.1.BP3: Ensure consistency. |
new |
False |
|
SEC.1.BP4: Communicate agreed cybersecurity requirements. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
Cybersecurity Implementation |
new |
False |
|
SEC.2.BP1: Refine the details of the architectural design. |
new |
False |
|
SEC.2.BP10: Communicate agreed results of cybersecurity implementation. |
new |
False |
|
SEC.2.BP2: Allocate cybersecurity requirements. |
new |
False |
|
SEC.2.BP3: Select cybersecurity controls. |
new |
False |
|
SEC.2.BP4: Refine interfaces. |
new |
False |
|
SEC.2.BP5: Analyze architectural design. |
new |
False |
|
SEC.2.BP6: Refine the details of the detailed design. |
new |
False |
|
SEC.2.BP7: Develop software units. |
new |
False |
|
SEC.2.BP8: Establish bidirectional traceability. |
new |
False |
|
SEC.2.BP9: Ensure consistency. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
Risk Treatment Verification |
new |
False |
|
SEC.3.BP1: Develop a risk treatment verification and integration strategy. |
new |
False |
|
SEC.3.BP2: Develop specification for risk treatment verification. |
new |
False |
|
SEC.3.BP3: Perform verification activities. |
new |
False |
|
SEC.3.BP4: Establish bidirectional traceability. |
new |
False |
|
SEC.3.BP5: Ensure consistency. |
new |
False |
|
SEC.3.BP6: Summarize and communicate results. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Risk Treatment Validation |
new |
False |
|
SEC.4.BP1: Develop a risk treatment validation strategy. |
new |
False |
|
SEC.4.BP2: Develop specification for risk treatment validation. |
new |
False |
|
SEC.4.BP3: Perform and document risk treatment validation activities. |
new |
False |
|
SEC.4.BP4: Establish bidirectional traceability. |
new |
False |
|
SEC.4.BP5: Ensure consistency. |
new |
False |
|
SEC.4.BP6 Summarize and communicate results. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Supplier Tendering |
new |
False |
|
SPL.1.BP1: Establish communication interface. |
new |
False |
|
SPL.1.BP2: Perform customer inquiry screening. |
new |
False |
|
SPL.1.BP3: Establish customer proposal evaluation criteria. |
new |
False |
|
SPL.1.BP4: Evaluate customer request for proposal. |
new |
False |
|
SPL.1.BP5: Determine need for preliminary pre-studies. |
new |
False |
|
SPL.1.BP6: Identify and nominate staff. |
new |
False |
|
SPL.1.BP7: Prepare supplier proposal response. |
new |
False |
|
SPL.1.BP8: Establish confirmation of agreement. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Product Release |
new |
False |
|
SPL.2.BP1: Define the functional content of releases. |
new |
False |
|
SPL.2.BP10: Ensure product release approval before delivery. |
new |
False |
|
SPL.2.BP11: Ensure consistency. |
new |
False |
|
SPL.2.BP12: Provide a release note. |
new |
False |
|
SPL.2.BP13: Deliver the release to the intended customer. |
new |
False |
|
SPL.2.BP2: Define release products. |
new |
False |
|
SPL.2.BP3: Establish a product release classification and numbering scheme. |
new |
False |
|
SPL.2.BP4: Define the build activities and build environment. |
new |
False |
|
SPL.2.BP5: Build the release from configured items. |
new |
False |
|
SPL2.BP6: Communicate the type, service level and duration of support \ for a release. |
new |
False |
|
SPL.2.BP7: Determine the delivery media type for the release. |
new |
False |
|
SPL.2.BP8: Identify the packaging for the release media. |
new |
False |
|
SPL.2.BP9: Define and produce the product release \ documentation/release notes. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
Quality Assurance |
new |
False |
|
Change Request Management |
new |
False |
|
SUP.10.BP1: Develop a change request management strategy. |
new |
False |
|
SUP.10.BP2: Identify and record the change requests. |
new |
False |
|
SUP.10.BP3: Record the status of change requests. |
new |
False |
|
SUP.10.BP4: Analyze and assess change requests. |
new |
False |
|
SUP.10.BP5: Approve change requests before implementation. |
new |
False |
|
SUP.10.BP6: Review the implementation of change requests. |
new |
False |
|
SUP.10.BP7: Track change requests to closure. |
new |
False |
|
SUP.10.BP8: Establish bidirectional traceability. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
9 |
new |
False |
|
SUP.1.BP1: Develop a project quality assurance strategy. |
new |
False |
|
SUP.1.BP2: Assure quality of work products. |
new |
False |
|
SUP.1.BP3: Assure quality of process activities. |
new |
False |
|
SUP.1.BP4: Summarize and communicate quality assurance activities and results. |
new |
False |
|
SUP.1.BP5: Ensure resolution of non-conformances. |
new |
False |
|
SUP.1.BP6: Implement an escalation mechanism. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Verification |
new |
False |
|
SUP.2.BP1: Develop a verification strategy. |
new |
False |
|
SUP.2.BP2: Develop criteria for verification. |
new |
False |
|
SUP.2.BP3: Conduct verification. |
new |
False |
|
SUP.2.BP4: Determine and track actions for verification results. |
new |
False |
|
SUP.2.BP5: Report verification results. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
Joint Review |
new |
False |
|
SUP.4.BP1: Define review elements. |
new |
False |
|
SUP.4.BP2: Establish a mechanism to handle review outcomes. |
new |
False |
|
SUP.4.BP3: Prepare joint review. |
new |
False |
|
SUP.4.BP4: Conduct joint reviews. |
new |
False |
|
SUP.4.BP5: Distribute the results. |
new |
False |
|
SUP.4.BP6: Determine actions for review results. |
new |
False |
|
SUP.4.BP7: Track actions for review results. |
new |
False |
|
SUP.4.BP8: Identify and record problems. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
Documentation |
new |
False |
|
SUP.7.BP1: Develop a documentation management strategy. |
new |
False |
|
SUP.7.BP2: Establish standards for documentation. |
new |
False |
|
SUP.7.BP3: Specify documentation requirements. |
new |
False |
|
SUP.7.BP4: Identify the relevant documentation to be produced |
new |
False |
|
SUP.7.BP5: Develop documentation. |
new |
False |
|
SUP.7.BP6: Check documentation. |
new |
False |
|
SUP.7.BP7: Distribute documentation. |
new |
False |
|
SUP.7.BP8: Maintain documentation. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Configuration Management |
new |
False |
|
SUP.8.BP1: Develop a configuration management strategy. |
new |
False |
|
SUP.8.BP2: Identify configuration items. |
new |
False |
|
SUP.8.BP3: Establish a configuration management system. |
new |
False |
|
SUP.8.BP4: Establish branch management. |
new |
False |
|
SUP.8.BP5: Control modifications and releases. |
new |
False |
|
SUP.8.BP6: Establish baselines. |
new |
False |
|
SUP.8.BP7: Report configuration status. |
new |
False |
|
SUP.8.BP8: Verify the information about configured items. |
new |
False |
|
SUP.8.BP9: Manage the storage of configuration items and baselines. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
Problem Resolution Management |
new |
False |
|
SUP.9.BP1: Develop a problem resolution management strategy. |
new |
False |
|
SUP.9.BP2: Identify and record the problem. |
new |
False |
|
SUP.9.BP3: Record the status of problems. |
new |
False |
|
SUP.9.BP4: Diagnose the cause and determine the impact of the problem. |
new |
False |
|
SUP.9.BP5: Authorize urgent resolution action. |
new |
False |
|
SUP.9.BP6: Raise alert notifications. |
new |
False |
|
SUP.9.BP7: Initiate problem resolution. |
new |
False |
|
SUP.9.BP8: Track problems to closure. |
new |
False |
|
SUP.9.BP9: Analyze problem trends. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Software Requirements Analysis |
new |
False |
|
SWE.1.BP1: Specify software requirements. |
new |
False |
|
SWE.1.BP2: Structure software requirements. |
new |
False |
|
SWE.1.BP3: Analyze software requirements. |
new |
False |
|
SWE.1.BP4: Analyze the impact on the operating environment. |
new |
False |
|
SWE.1.BP5: Develop verification criteria. |
new |
False |
|
SWE.1.BP6: Establish bidirectional traceability. |
new |
False |
|
SWE.1.BP7: Ensure consistency. |
new |
False |
|
SWE.1.BP8: Communicate agreed software requirements. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
Software Architectural Design |
new |
False |
|
SWE.2.BP1: Develop software architectural design. |
new |
False |
|
SWE.2.BP2: Allocate software requirements. |
new |
False |
|
SWE.2.BP3: Define interfaces of software elements. |
new |
False |
|
SWE.2.BP4: Describe dynamic behavior. |
new |
False |
|
SWE.2.BP5: Define resource consumption objectives. |
new |
False |
|
SWE.2.BP6: Evaluate alternative software architectures. |
new |
False |
|
SWE.2.BP7: Establish bidirectional traceability. |
new |
False |
|
SWE.2.BP8: Ensure consistency. |
new |
False |
|
SWE.2.BP9: Communicate agreed software architectural design. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Software Detailed Design and Unit Construction |
new |
False |
|
SWE.3.BP1: Develop software detailed design. |
new |
False |
|
SWE.3.BP2: Define interfaces of software units. |
new |
False |
|
SWE.3.BP3: Describe dynamic behavior. |
new |
False |
|
SWE.3.BP4: Evaluate software detailed design. |
new |
False |
|
SWE.3.BP5: Establish bidirectional traceability. |
new |
False |
|
SWE.3.BP6: Ensure consistency. |
new |
False |
|
SWE.3.BP7: Communicate agreed software detailed design. |
new |
False |
|
SWE.3.BP8: Develop software units. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Software Unit Verification |
new |
False |
|
SWE.4.BP1: Develop software unit verification strategy including regression strategy. |
new |
False |
|
SWE.4.BP2: Develop criteria for unit verification. |
new |
False |
|
SWE.4.BP3: Perform static verification of software units. |
new |
False |
|
SWE.4.BP4: Test software units. |
new |
False |
|
SWE.4.BP5: Establish bidirectional traceability. |
new |
False |
|
SWE.4.BP6: Ensure consistency. |
new |
False |
|
SWE.4.BP7: Summarize and communicate results. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
Software Integration and Integration Test |
new |
False |
|
SWE.5.BP1: Develop software integration strategy. |
new |
False |
|
SWE.5.BP2: Develop software integration test strategy including regression test strategy. |
new |
False |
|
SWE.5.BP3: Develop specification for software integration test. |
new |
False |
|
SWE.5.BP4: Integrate software units and software items. |
new |
False |
|
SWE.5.BP5: Select test cases. |
new |
False |
|
SWE.5.BP6: Perform software integration test. |
new |
False |
|
SWE.5.BP7: Establish bidirectional traceability. |
new |
False |
|
SWE.5.BP8: Ensure consistency. |
new |
False |
|
SWE.5.BP9: Summarize and communicate results. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
Software Qualification Test |
new |
False |
|
SWE.6.BP1: Develop software qualification test strategy including regression test strategy. |
new |
False |
|
SWE.6.BP2: Develop specification for software qualification test. |
new |
False |
|
SWE.6.BP3: Select test cases. |
new |
False |
|
SWE.6.BP4: Test integrated software. |
new |
False |
|
SWE.6.BP5: Establish bidirectional traceability. |
new |
False |
|
SWE.6.BP6: Ensure consistency. |
new |
False |
|
SWE.6.BP7: Summarize and communicate results. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
Requirements Elicitation |
new |
False |
|
SYS.1.BP1: Obtain stakeholder requirements and requests. |
new |
False |
|
SYS.1.BP2: Understand stakeholder expectations. |
new |
False |
|
SYS.1.BP3: Agree on requirements. |
new |
False |
|
SYS.1.BP4: Establish stakeholder requirements baseline. |
new |
False |
|
SYS.1.BP5: Manage stakeholder requirements changes. |
new |
False |
|
SYS.1.BP6: Establish customer-supplier query communication mechanism. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
System Requirements Analysis |
new |
False |
|
SYS.2.BP1: Specify system requirements. |
new |
False |
|
SYS.2.BP2: Structure system requirements. |
new |
False |
|
SYS.2.BP3: Analyze system requirements. |
new |
False |
|
SYS.2.BP4: Analyze the impact on the operating environment. |
new |
False |
|
SYS.2.BP5: Develop verification criteria. |
new |
False |
|
SYS.2.BP6: Establish bidirectional traceability. |
new |
False |
|
SYS.2.BP7: Ensure consistency |
new |
False |
|
SYS.2.BP8: Communicate agreed system requirements. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
System Architectural Design |
new |
False |
|
SYS.3.BP1: Develop system architectural design. |
new |
False |
|
SYS.3.BP2: Allocate system requirements. |
new |
False |
|
SYS.3.BP3: Define interfaces of system elements. |
new |
False |
|
SYS.3.BP4: Describe dynamic behavior. |
new |
False |
|
SYS.3.BP5: Evaluate alternative system architectures. |
new |
False |
|
SYS.3.BP6: Establish bidirectional traceability. |
new |
False |
|
SYS.3.BP7: Ensure consistency. |
new |
False |
|
SYS.3.BP8: Communicate agreed system architectural design. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
System Integration and Integration Test |
new |
False |
|
SYS.4.BP1: Develop system integration strategy. |
new |
False |
|
SYS.4.BP2: Develop system integration test strategy including \ regression test strategy. |
new |
False |
|
SYS.4.BP3: Develop specification for system integration test. |
new |
False |
|
SYS.4.BP4: Integrate system items. |
new |
False |
|
SYS.4.BP5: Select test cases. |
new |
False |
|
SYS.4.BP6: Perform system integration test. |
new |
False |
|
SYS.4.BP7: Establish bidirectional traceability. |
new |
False |
|
SYS.4.BP8: Ensure consistency. |
new |
False |
|
SYS.4.BP9: Summarize and communicate results. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
|
7 |
new |
False |
|
8 |
new |
False |
|
System Qualification Test |
new |
False |
|
SYS.5.BP1: Develop system qualification test strategy including \ regression test strategy. |
new |
False |
|
SYS.5.BP2: Develop specification for system qualification test. |
new |
False |
|
SYS.5.BP3: Select test cases. |
new |
False |
|
SYS.5.BP4: Test integrated system. |
new |
False |
|
SYS.5.BP5: Establish bidirectional traceability. |
new |
False |
|
SYS.5.BP6: Ensure consistency. |
new |
False |
|
SYS.5.BP7: Summarize and communicate results. |
new |
False |
|
1 |
new |
False |
|
2 |
new |
False |
|
3 |
new |
False |
|
4 |
new |
False |
|
5 |
new |
False |
|
6 |
new |
False |
NeedFlow
Documentation: How-to use Sphinx-Needs NeedFlow [10]. The code been expected and generated is for plantuml [15]. You can configure the visual representation of needs elements in needflow with needs-types. NeedFlow expects to get plantuml deployment-diagram [13] elements as representation.
Example 13: How-to use a NeedFlow.
.. needflow:: Requirement Linkage
:filter: is_external == True and (type=='stake_req' or type=='sw_req')
:show_link_names:
:debug:
:scale: 30
@startuml
' Nodes definition
artifact "<size:12>Stakeholder Requirement</size>\n**Detect merge**\n**conflicts**\n<size:10>CSTRQ_DETECT_MERGE_CONFLICTS</size>" as CSTRQ_DETECT_MERGE_CONFLICTS [[https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/requirements/stakeholder_specification.html#CSTRQ_DETECT_MERGE_CONFLICTS]] #abcdef
artifact "<size:12>Stakeholder Requirement</size>\n**Merge python**\n**dictionaries**\n<size:10>CSTRQ_MERGE_DICTS</size>" as CSTRQ_MERGE_DICTS [[https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/requirements/stakeholder_specification.html#CSTRQ_MERGE_DICTS]] #abcdef
artifact "<size:12>Software Requirement</size>\n**Allow double**\n**definitions of**\n**same Key /**\n**Value**\n<size:10>SWRQ_ALLOW_DOUBLE_DEFINITION</size>" as SWRQ_ALLOW_DOUBLE_DEFINITION [[https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/requirements/software_specification.html#SWRQ_ALLOW_DOUBLE_DEFINITION]] #abcdef{
'child needs:
}
artifact "<size:12>Software Requirement</size>\n**Detect merge**\n**conflicts**\n<size:10>SWRQ_DETECT_MERGE_CONFLICTS</size>" as SWRQ_DETECT_MERGE_CONFLICTS [[https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/requirements/software_specification.html#SWRQ_DETECT_MERGE_CONFLICTS]] #abcdef{
'child needs:
}
artifact "<size:12>Software Requirement</size>\n**Definition:**\n**list of**\n**dictionaries**\n<size:10>SWRQ_LIST_OF_DICTS</size>" as SWRQ_LIST_OF_DICTS [[https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/requirements/software_specification.html#SWRQ_LIST_OF_DICTS]] #abcdef{
'child needs:
}
artifact "<size:12>Software Requirement</size>\n**Merge python**\n**dictionaries**\n<size:10>SWRQ_MERGE_DICTS</size>" as SWRQ_MERGE_DICTS [[https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/requirements/software_specification.html#SWRQ_MERGE_DICTS]] #abcdef
artifact "<size:12>Software Requirement</size>\n**Name of the**\n**tool:**\n**merge_dicts**\n<size:10>SWRQ_TOOL_merge_dicts</size>" as SWRQ_TOOL_merge_dicts [[https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/requirements/software_specification.html#SWRQ_TOOL_merge_dicts]] #abcdef
artifact "<size:12>Software Requirement</size>\n**Output in merge**\n**conflict case**\n<size:10>SWRQ_USE_FIRST_VALUE_FOR_KEY</size>" as SWRQ_USE_FIRST_VALUE_FOR_KEY [[https://reconf2023-product-as-code-philippartsch-a4d4571b1b7e4136d3bdb6.gitlab.io/requirements/software_specification.html#SWRQ_USE_FIRST_VALUE_FOR_KEY]] #abcdef{
'child needs:
}
' Connection definition
SWRQ_ALLOW_DOUBLE_DEFINITION -up-> CSTRQ_DETECT_MERGE_CONFLICTS: satisfies\n
SWRQ_DETECT_MERGE_CONFLICTS -up-> CSTRQ_DETECT_MERGE_CONFLICTS: satisfies\n
SWRQ_LIST_OF_DICTS -up-> CSTRQ_MERGE_DICTS: satisfies\n
SWRQ_MERGE_DICTS -up-> CSTRQ_MERGE_DICTS: satisfies\n
SWRQ_USE_FIRST_VALUE_FOR_KEY -up-> CSTRQ_DETECT_MERGE_CONFLICTS: satisfies\n
@endumlStructured Sphinx-Needs reports in tables
Often you have the use case to structure reports of Sphinx-Needs in table view. You can do this with e.g. a list-table to structure the visual representation.
Example 14: Reports structured with tables
.. list-table:: Reports
:header-rows: 1
* - Report
- Representation
* - NeedPie
- .. needpie:: Ratio of requirement types
:labels: Stakeholder Requirement, Software Requirement, Evaluation
type == 'stake_req' and is_external == True
type == 'sw_req' and is_external == True
type == 'evaluation' and is_external == True
* - NeedBar
- .. needbar:: Requirements & Status Overview
:legend:
:colors: black, yellow, orange, green
:xlabels: FROM_DATA
:ylabels: FROM_DATA
, Stakeholder Requirement , Software Requirement
empty, type=='stake_req' and status=='' , type=='sw_req' and status==''
accepted, type=='stake_req' and status=='accepted' , type=='sw_req' and status=='accepted'
implemented, type=='stake_req' and status=='implemented', type=='sw_req' and status=='implemented'
verified, type=='stake_req' and status=='verified' , type=='sw_req' and status=='verified'
* - NeedTable
- .. needtable:: List of software requirements
:types: sw_req
:style: table
:columns: id; title; status
* - NeedFlow
- .. needflow:: Requirement Linkage
:filter: is_external == True and (type=='stake_req' or type=='sw_req')
:show_link_names:
:show_filters:
:scale: 30
Report |
Representation |
|||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
NeedPie |
||||||||||||||||||||||
NeedBar |
||||||||||||||||||||||
NeedTable |
|
|||||||||||||||||||||
NeedFlow |
Used filter: |
NeedUml
Documentation: How-to use Sphinx-Needs NeedUml [12].
The debug option is often useful here, see Sphinx-Needs NeedUml & NeedArch debug option [14].
The code been expected and generated is for plantuml [15].
You can use needs-render-context to extend the data available in needarch and needuml.
Example 15: How-to use a NeedUml.
.. needuml::
{{uml("M_MERGE_DICTS", "class")}}
note right of [M_MERGE_DICTS]
We use M_MERGE_DICTS to merge python dictionaries.
end note
NeedArch
NeedArch is extending the functionality of NeedUml, to access local data of a Need.
Documentation: How-to use Sphinx-Needs NeedArch [11].
The code been expected and generated is for plantuml [15] and
you can use jinja [16] to template your plantuml code.
You can find detailed description in Architecture Expert Guide.
Example 16: How-to use a NeedArch`
.. arch_module:: Our own script
:id: M_OWN_SCRIPT
.. needarch::
'example how to use information from the current need
{{flow(need().id)}}
'add diagram information from another source
{{uml("M_MERGE_DICTS", "class")}}
'link elements
{{need().id}} -> {{needs["M_MERGE_DICTS"].implements[0]}}
|
Templating
With templates you can template the content for needs. It is even possible to add text before and after a need. The documentation is part of needs doc under How-to use Sphinx-Needs Templates [17].
We use it here finally in conf.py:
363needs_global_options = {
364 'test_status': {'predicates': [('type=="sw_req"', '[[check_verified()]]')]},
The templates are defined available in /needs_templates e.g. arch_template.need used in docname == “architecture-examples”:
1{# Place the original content here #}
2{{content}}
3
4**Following needarch is been added with needs template**
5
6:np:`(Deployment)` Diagram
7
8{% raw %}
9.. needarch::
10 :key: Deployment
11
12 {{flow(need().id)}} {
13 {% for e in need().parent_needs_back %}
14 {% if needs[e].parent_need == need().id and (needs[e].type == "outport" or needs[e].type == "inport") %}{{uml(e)}}{% endif %}
15 {% endfor %}
16 {% if 'Deployment' in need().parts %}card "Deployment Diagram" as {{need().id + '.Deployment'}} {{ref(need().id + '.Deployment')}}{% endif %}
17 {% if 'Sequence' in need().parts %}card "Sequence Diagram" as {{need().id + '.Sequence'}} {{ref(need().id + '.Sequence')}}{% endif %}
18 }
19{% endraw %}
An example need which uses such template is Component with Diagrams (C_DIAGRAMS).
Dynamic functions
Documentation: How-to use Sphinx-Needs Dynamic functions [18].
You can even define your own dynamic functions in conf.py and use them in your needs. See Sphinx-Needs develop-own-functions.
Example 17: How-to use dynamic functions.
.. need:: Test Dynamic Functions 0
:id: N_DF_0
:status: open
:links: [[links_from_content()]]
Uses dynamic function ``links_from_content()`` to fetch all links mentioned in the content.
e.g. :need:`N_DF_1` and :need:`N_DF_3` are now part of the linked elements.
.. need:: Test Dynamic Functions 1
:id: N_DF_1
:status: open
This need has id :ndf:`copy("id")` and status :ndf:`copy("status")`.
.. need:: Test Dynamic Functions 2
:id: N_DF_2
:status: [[copy("status", "N_DF_1")]]
:links: N_DF_1
Copies status of :need:`N_DF_1` to own status.
.. need:: Test Dynamic Functions 3
:id: N_DF_3
:links: N_DF_2, [[copy('links', 'N_DF_2')]]
Set own link to :need:`N_DF_1` and also copies all links from it.
Uses dynamic function |
This need has id N_DF_1 and status open. |
Copies status of Test Dynamic Functions 1 (N_DF_1) to own status. |
Set own link to Test Dynamic Functions 1 (N_DF_1) and also copies all links from it. |
Layouts
Documentation: with an dedicated chapter under How-to use Sphinx-Needs Layouts & Styles [19].
You can define your own layouts finally in conf.py with needs_layouts and use them for your needs:
257needs_layouts = {
258 "clean_with_edit_link": {
259 "grid": "simple",
260 "layout": {
261 "head": [
262 '<<meta("type_name")>>: **<<meta("title")>>** <<meta_id()>> <<collapse_button("meta", '
263 'collapsed="icon:arrow-down-circle", visible="icon:arrow-right-circle", initial=False)>> '
264 '<<link(url="github_edit_url", image_url="icon:edit", image_height="17", image_width="17", is_dynamic=True)>>'
265 ],
266 "meta": [
267 '<<meta_all(no_links=True, exclude=["layout", "post_template", "style", "delete", "jinja_content", "github_edit_url"])>>',
268 '<<meta_links_all()>>'
269 ],
270 },
It is been used here, to get the edit button on all needs.
You can set the default layout like we do in conf.py
258needs_default_layout = 'clean_with_edit_link'
You could set the layout even via needs_global_options.
Variant Management
You can find detailed description in How-To use variant management.
Schema Validation
With Sphinx-Needs 6.0.0 it is possible to define a data schema of all needs.
It enables strong type definition.
The schema follows the json schema definition, but extends it to support even modelling of relations.
See more details in the Documentation.
It is now possible to define for needs_extra_options a strong type definition which is the basis
for further ontology information, see needs_extra_options in the
Documentation.
Schema Validation is for bigger setups and should be agreed from experts in ontology management.
Extensions for Visual Studio Code
ubCode
ubCode
provides support for Sphinx-Needs and rst via a toml configuration file and a implements
rst / Sphinx-Needs parser in Rust.
It offers gui tools in the IDE like preview of complete rst files, link preview,
used / defined linkage of needs elements, and more.
Important are the rst and Sphinx-Needs linter and beautifier.
See more details in the Documentation.