Association type between requirements?

[ea0804]

Which association should be between a requirement and an other requirement which is included in the first?

Example:
Requirement 1: create statistic
Requirement 2: create orderer statistic
Requirement 3: create customer statistic

create statistic
+- create orderer statistic
+- create customer statistic

My sugestion would be Aggregation or Nesting...
Which would you choose?

[thomaskilian]

I would use aggregation - or removal of the included requirement respectively placing it somewhere aside. Most times it does not make much sense to have a requirement stated twice.

[sargasso]

I've got to slightly disagree here Thomas.

It is very common in my experience for a generic requirement - expressed early in the RD phase - to give rise to further specialised variants as analysis proceeds and other stakeholder views are presented.

Previously I have tried the "split and specialise" approach with the following poor outcome.  The viewpoint of the original requirement specifier is lost.  The framework of their world experience that gives rise to the generic version is valid and immutable, they a) dont care about the specialisation and b) become confused about why their view is no longer presented in the model.

What I tend to do these days is to retain the generic and tag it as "unimplementable" (or whatever value is politically correct in the environment).  Then, as you say, use aggregation associations to link the specialisations to the generic.  This, in my experience, has been acceptable to the original specifier - they can see that the import of their requirement has not been lost and appreciate that someone is actually furthering it in the analysis.  

Furthermore, (for the UML high-churchers) the use of Composite vs Shared aggregation can add value during the phasing design.  In that, composite requirement structures can easily be idenitified as being for delayed implementation if the generic is delayed, whereas shared structures need more careful analysis - even though the generic may be delayed one or more of the specialisations may need to be implemented earlier.

Looking at sobedi's example, at face value, it seems that the structure is indeed composite and the second level requirements are indeed specialisations.  Just pretending...

Code: [Select]


create statistic <<mandatory>>
 <>   <*>
 |     |
 |     |_create orderer statistic <<mandatory>>
 |
 |____ create customer statistic <<desired>>

...gives me a clear visual on what to consider for inclusion in Rel1.

bruce

[thomaskilian]

Hi Bruce,
of course it depends on the viewpoint and yours is absolutely correct However the requirement "create statistics" is nice but rather meaningless. I would have grouped the finer grained ones in a common package. Actually that's the way I do it, not by connecting them via aggregation. The use of packages also has the advantage that *related* requirements are placed nearby. I also have a separate diagramm to show these. Traceability might be of interest though. In that case I would not delete the included requirements but I would put them somewhere aside. In that way I still have the information about creation time and the related stakeholder. However it shows that requirements have to be reengineered from time to time in order to find duplicates or similar ones that need to be united.

I think it mainly depends on the type of project which way you go.

[ea0804]

Hi Thomas, hi Bruce,

thanks for your opinions!!!

i agree with both of you,
i personally like to structure specializations in a common node. This gives quite a good structure in the project view and a clean tree.

On the other side the structured information in the project view is not available in the model, because no links are automatically created between the common requirement and the specialized requirements... For my project (reverse engineering documentation for a "in production" software tool) it means, that i have no gain from the structured requirements aside from a good looking project view.

so i will implement thomas solution and package the requirements and build my structure with packages.

[Paolo F Cantoni]

Hi All,

I've gone the nesting route...  For a number of reasons.

Since you can decompose requirements (and most requirements
tracking tools require/allow you to do it), I looked at
composite aggregation versus containment (nesting).

In many other UML 2 tools (but not yet EA), joining two elements
with a nesting connector will automatically rearrange the
containment hierarchy in the browser.  Similarly, rearranging the
browser automatically adjusts the nesting/containment
relationships between the elements involved. In EA, I can
manually adjust the browser when I add the nesting relationship
(somewhat burdensome but...).  So, I end up with a tree view in
the browser and a diagrammatic tree on the diagram.

The UML 2 Superstructure Specification tells us that there
are two (actually three) forms of representations for the
membership relationship.  (see Figure 61 in ptc-04-10-02).
It seems to me that all these related forms represent
requirement decomposition.

You can, more correctly, use other relationships (such as
dependency) to model those type of relationships between
requirements, once you have the decomposition handled by
nesting.

Now if only EA would do the automagic for me...

Paolo