Chair: Ian

• Requirement Organization - discuss straw man proposal - RmRequirementsOrganizationScenarios

Minutes

Attendees: IanGreen, DominicTulley, SimonWills, AndyBerner, IanGiblett? , JimConallen, DaveJohnson

Minutes:

SW: Two (AB said "more") related things: (i) Understanding - single requirement in isolation does not have context so it can't be understood. To understand several requirements they need to be logically structured. Unordered bag is not useful. This is practical, and perhaps soft.

(ii) Parent/child in the hierarchy has meaning but might not be best represented as structure - we'd be better with tracelinks.

AB: A headng serves a grouping role to aid understanding. Parent/child relationships where the parent is really a requirement.

IG: are the realtionships orthogonal.

AB: What is the notion of hierarchy? Eg one example: folder structure. "macro scale". another is "micro scale" - headings and sections.

SW: how would you start from a requirement and discover its parent resource?

Eg See the other requirements that are tested by the same test case; or the other performance related requirements?

DJ: Agree that there are multiple hierachies that need to be expressed.

AB: how can we focus on a folder hierarchy, for example?

What's special about folders?

SW: We could use the straw man, or we could use an explicit link. Concern over expense of link resources.

We would need to decide on the behaviour in the following terms - multiplicity, lifetime, ownership, reuse etc.

IG: What are the traits of a collection? SW: Could there be a query that returned some non-canonical heirarchy structure?

AB: What might we learn from SCM/AM/AssetMgmt

AB: Suggested that folder hierarchies have a "standard" set of traits and are fairly standard meaning. There is little semantic "leakage" from one resource in a folder to a sibling.