user defined attributes / fields

[einsweniger]

I'd like to propose yet another feature =D

I want to be able to add other attributes to the artifacts, like proposed in REQ-0-risks: you'd add likelyhood, impact and product placement to a RSK artifact.

Proposal: Allow additional attribute types to be added via settings.toml. Allow specifying constraints for the attribute. Constraints might be:

• attribute may only be used in RSK artifacts.
• attribute type (int, str, float, bool, str[] with predefined values)
• enforce attribute presence (RSK artifact MUST have "risk" attribute)

Reasons:

• art check can verify and enforce attribute existence: having an RSK without all three proposed attributes (likelyhood, impact, product-placement) will mark the artifact as incomplete/invalid.
• IEEE 29148:2011 also gives several examples of attributes (which are already mostly covered), which I'd like to have separate from the text attribute. Like difficulty, for example.
• enabling to filter on these, would IMHO add greatly to artifacts potential, since you could filter for high priority artifacts.
• the way it is now, we have to pack it all in the text field with no way to check for them.

Cons:

• probably overkill, error prone and tough to implement :D

[vitiral]

Some thoughts:

• I like the idea of extra attributes through settings.toml. I had previously thought about using an extra parameter directly on the artifact which was arbitrarily json but this is much better. I'm thinking of the format and I'm thinking something like:

  
  [attrs]
  # you must specify the type, these are optional and have no constraints (besides type)
  unchecked-int = "int"
  unchecked-str = "string"

[attrs.checked-int] type = "int" min = 0 max = 10 required = true

[attrs.optional-checked-str] type = "str" max = 10 # max refers to the length

- for querying, I think you would need to use something like [jsonpath](https://github.com/dchester/jsonpath). This would be through a flag in the cmdline and an option in the web-ui
- for web-ui probably would just display these below partof/parts. For `ls` command there would probably be an `--attrs` method where you could spell out the attributes to list.

Other reasons this would be nice:
- I would like to support plugins in the future. Some of these plugins would probably want to have custom attributes.

[rubdos]

Yet another reason this would be nice: if you ever decide that end-users can add custom top level artifacts (e.g. US for user story, which is one I'd like to have), users can fully customize them.

And an even better reason: you could now define your RSK attributes through a "default" set of attributes, instead of hard coding them. I think that would be very nice.

[vitiral]

Negative: adds complexity to the user that I think is rarely needed which might confuse people. Complexity is always something which should be avoided as much as possible.

For instance, user stories should just be part of the text in requirements. I don't see any benefit of creating a separate field for them. Actually I don't see any benefits outside of the RSK artifacts. Can anyone come up with other examples?

[einsweniger]

@vitiral Providing a way to specify attributes across all ART would make artifact way more powerful. But, as you, I fear the added complexity in code, usability and configuration will divert attention from the original goal of artifact (simple quality), which I'd rather not sacrifice.

As @rubdos, I have thought about (mis?)-using it for checking and enforcing attributes, to define structure on i.e. scenarios (or user-stories), stakeholders (needs, roles, goals, ...) and possibly other artifacts.

(kinda off-topic) My "solution" until now:

• Write a REQ that you want to document something (identify stakeholders).
• Add the SPC which defines attributes you want to capture (role, goal, needs, representative, ...).
• Document these somewhere else (we use LaTeX) and mark that as the implementation of the spec.

Downsides to this approach:

• definitions are outside artifact and must be enforced through other means (as with all implementations).
• if you derive requirements from these, they will not be traceable in artifact.

[einsweniger]

@vitiral I came up with another attribute outside of RSK: priority of a REQ to balance them against each other.

[einsweniger]

And another for requirements: type: [(non-)functional, performance, usability, constraint, ...]

[vitiral]

I've decided to go forward with this feature, soley for plugin support and ISO support. I like this because it doesn't increase the complexity of the "standard" product, but allows plugins or users to make things as complex as THEY want to.

[vitiral]

@einsweniger this would be a great issue for you to work on, if you were still interested!