Model Updates - 2023 11 02

[invisig0th]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (97a32b1) 92.69% compared to head (27d885b) 97.30%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3407      +/-   ##
==========================================
+ Coverage   92.69%   97.30%   +4.60%     
==========================================
  Files         233      233              
  Lines       48192    48193       +1     
==========================================
+ Hits        44672    46892    +2220     
+ Misses       3520     1301    -2219     

Flag	Coverage Δ
linux	97.30% <100.00%> (+4.60%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ancailliau]

(Disclosure, spent 8 years doing a PhD about requirements engineering, focused on requirements, goal and risk modelling and analysis - if wished, we can schedule a call too)

My distinction between goals and requirements is that a requirement is a goal that is realizable by some "entity" (being voluntarily vague here) assigned to it. Goals are not realizable (i.e. too abstract) by a single entity while a requirement is.
I would generalize the :assignee property to also include software (and hardware?)

(a) It would be nice to be able to structure a bit the goals and requirements hierarchically, that is with sub-elements and alternatives. In an ideal world, being able to capture alternative set of requirements that would satisfy the parent requirements enables better evaluation of the various options. The goals and requirements should form an AND/OR-graph.
AND-refinement links relate a goal to a set of subgoals (called refinement); satisfying all subgoals in the refinement is a sufficient condition for satisfying the goal. On the other hand, OR-refinement links relate a goal to an alternative set of refinements; this means that satisfying one of the refinements is a sufficient condition for satisfying the goal.

For example, a requirement (let's not discuss the relevance of the requirement 😅): "We shall collect IP addresses of C2 used for malware family Y" could be refined in various alternatives like "We shall collect IP addresses of C2 used by family Y as published in public sources (OSINT)" or "We shall collect IP addresses of C2 used by family Y as published in private and commercial sources" or ("We shall have internal scanning capabilities with NSE scripts" and "We shall scan the IP ranges X for C2 with NSE script Z"). I would like to be able to capture the fact that I could select one or multiple options, but also that some options includes multiple requirements that must be selected together.

(b) Could you include a user-defined taxonomy for the requirements? I track hardware, software and human requirements separately in most of my use cases.

I currently tracks my requirements in a different database and would love to migrate these goals and requirements to Synapse. That would enable better tracking of the satisfaction of these requirements - including better reporting and rationale motivation for some entities modelled in Synapse.

---

Minor remark, the properties :requirements in biz:rfp and ou:contract would be incoherently named.

[invisig0th]

@ancailliau thanks so much for the input! We do occasionally encounter instances where a new model element deprecates or makes incoherent previous model elements. I'll add the ones you mentioned for potential deprecation or replacement. I completely agree on the discussion of goals vs requirements 👍

Re :assignee this is designed to be the person (or organization) who is responsible for ensuring that the requirement is met. There is not currently an abstraction that would make a union of person/organization and software ( and i would potentially argue that you still assign responsibility to an entity even if the software is what ultimately "meets" the requirement ).

We opted to defer how the requirements are composed into larger contracts/documents ( which would potentially include the need for boolean logic ) for now to get the initial ability to model individual atomic requirements. I'll add the need to include the ability to compose them ( including boolean logic ) into the discussion of the next phases of the model :)

Thanks again for your thoughts on this. It's def clear you've put a lot of thought into it 💚