When to nest requirements vs when to aggregate

[mark1406]

Are there rules/guidelines on when to nest requirements (creating an owned by relationship) versus when to create an aggregation relationship?

[Paolo F Cantoni]

Are there rules/guidelines on when to nest requirements (creating an owned by relationship) versus when to create an aggregation relationship?

Do you mean when should you use composite versus shared aggregation for Requirements?

If so, then you are asking about the various forms of meronymy for Requirement.  My view is that if when the holonym (parent requirement) is removed, the meronymy (children) also have no meaning, then you have a composition, otherwise you have shared aggregation.

NOTE: any specific requirement may have both composite and shared nestlings!  As I argue above, we are really discussing the relationship between one specific requirement and another.  In addition to the aggregation relationships, one may have simple association between any two requirements.

Hope that helps,
Paolo

[mark1406]

Thanks Paolo, you've confirmed my suspicion that this isn't black and white and your approach seems logical. In practice, is there any risk to mandating aggregation only?

[Paolo F Cantoni]

Thanks Paolo, you've confirmed my suspicion that this isn't black and white and your approach seems logical. In practice, is there any risk to mandating aggregation only?

I wouldn't think so Mark; although there's the continuing debate about whether there is such a thing as Requirements Decomposition...

The consensus view here (at Proteus) is that if you discover a "composite" requirement you should attempt to decompose it into its constituent meronyms.  This is to ensure that you attempt to trace at the appropriate level of granularity!  Typically you'll be hard pressed to adequately trace at the composite level - and, in fact, the composite requirement may not pass the "Duck Test" for a valid Requirement.

Having said that, and having found all the appropriate "leaf" requirements - you might chose to aggregate (shared) them for convenience by various categorizations etc...  In all likelihood, the aggregates thus synthesized may bear only casual relationship to the original composites!

Does that help or confuse?
Paolo

[mark1406]

Thanks for the feedback. Specifically I am trying to determine the best way to document business requirements such as "minimise the time to identify errors in historical FooBaa data" along with the implied technical requirements for the system that will realise the requirement and the user interactions with the system.

My current thinking is that...

The aggregated technical requirements for the above include a wizard that reviews the imported data and employs a heuristic learning algorithm. So the technical requirements specify the capabilities of the system.

The use cases then define how the user interacts with the wizard and algorithm. So they specify the requirements fo the interfaces and state machine.

Does that seem correct from a UML documentation perspective?

[fwoolz]

One possibly related point:

Requirements may be literally nested in the Project Browser simply by dragging and dropping such that a requirement becomes a child of another. If level numbering is turned on, this gives a nicely hierarchical outline view of requirements in the Project Browser. An additional plus is that the level number can be included in RTF reports. However, while the parent-child relationship is created in the EA database, no corresponding nesting relationship connector is created.

I have always found this to be a bit inconsistent, but it does at least give the user the option of specifying the type of relationship between requirements. Perhaps Sparx could add a project option like "Nesting in Project Browser automatically creates a (fill in the blank) link"?

Cheers,
Fred Woolsey

[mark1406]

I agree Fred. This does seem inconsistent and the ability to specify a default relationship / pick at relationship creation would seem to be useful.

[«Midnight»]

I suppose the connector should be consistent with what the hierarchy view shows. And of course the hierarchy should in turn be consistent with the Project Browser tree. Withing those limits Sparx could go about this however they wanted.

Of course this would be best if it were consistent across all of EA, but that's part of a larger (and much more important) discussion.