Heading requirements and traceability

[Paul Lotz]

I have a set of requirements (in my case that I import from DOORS) such that they form a hierarchy--as pretty much all sets of requirements do.  Hence some (many) of the "requirements" are headings with no requirement text.  If I simply create a relationship matrix, for example, EA shows me all the requirements, whether they are true requirements or simply section headings, so that it makes it very difficult to determine how many of the requirements are actually covered.

Really, I want to show that we have implemented all leaf requirements, and that section headings are covered (or complete) when all their descendants are covered (as other requirements tracking tools we have do).

Has anyone devised a way to do this in EA?

Paul

[RoyC]

Hi Paul

I won't dive too deeply into this one, because (as often occurs!) I am not sure where the real problem lies. However, you can apply level numbering to your requirement hierarchies, and that numbering can be made visible in the Relationship Matrix, Element List and RTF reports.

In the soon-to-be released build 846, we have also reinstated the element hierarchy format in the Element List.

Those options would show that Requirements have a hierarchical structure, and those with no point numbers (that is, 1, 2, 3 instead of 1.1, 1.2, 1.3) are the 'section head' type.

You might then set options in the list and report facilities to display the Status value of each Requirement, and either use the 'Implemented' value or define another Status value 'Complete', to reveal which sections of the hierarchy are complete to section-head.

Is any of this on the right track?

[Paul Lotz]

Roy,

We can see the requirements hierarchy reasonably well in EA (even in build 845) in the Element List by including the section numbers.

In the Relationship Matrix I can view the heading numbers as well, so at least I can look for the requirements that have a leaf extension such as -1, for example, at the end.  (Actually, this is often clipped in the view at the moment so I have to figure out how to widen the column, if possible, but that is a detail.)  This view, however, does not give a good quick impression of what we have covered and what remains.  It would take a while looking at the matrix to figure that out.  (Also, it would be great if we could click on a requirement in the matrix and make it active without having to select "Set Context Item.")

Yes, I can select a different status for a heading requirement.  Unfortunately I have to do this manually (not bad but it would be cooler if I had a relationship EA would check so that I wouldn't make mistakes--for example if I add a leaf requirement I may have to remember to change the status of the section heading above) and this doesn't show up in any way in the same relationship matrix.  I should explore if I can make this show up meaningfully in the reports.

OK, I am working with a requirements tool that does the following.

It shows the requirements in a hierarchical view.  Actual requirements are visually distinct and therefore very easy to recognize.
It summarizes which percentage of requirements are covered.
Each level of the hierarchy has a flag if there are uncovered requirements somewhere below it.
With this kind of tool it is quite easy to see what is covered and what is not, and to navigate directly to what is not covered if any items remain.  That is kind of what I am hoping to achieve with EA, even if it is a tall order.

Maybe EA can do this and I just need to try a few more things?  Maybe I do have to make a custom report....

Paul

[Dermot]

Hello Paul,
I am not sure if this is an answer to your question, but:

1) with the Element List view and the Relationships window open (Ctrl-shift-2) - on selection of any element the relationships are imediately shown. This allows a simple iteration through to to check linkages.

2) Alternately there is a Search for "Find Orphans" - which can be set to <Current tree selection> - this will list any requirements not yet linked.

3) There is the Project | Documentation - Implementation & Dependancy - reports - try these as well.

[Graham_Moir]

I'm not sure if I've missed the point here,  but we have a hierarchy of requirements that goes from Scope (nothing more than a heading)  to High-Level (you might get a sentence or paragraph on the requirement at this level) and finally Detailed where the requirement really is defined.    We also use the numbering as previously mentioned

We organise these requirements into packages depending on their type and we then have matrix profiles which check all scope requirements are covered by high-level requirements and high-level requirements are covered by detailed requirements.  Because the matrix profile source/target paramteres require packages this allows easy checking that relationships are fully covered.  

Later we have Use Case packages that are checked for coverage using a matrix profile linking back to the detailed requirements.

[Robert Sheridan]

I keep on finding that the structure which worked for one project does not quite do it on the next, picked up some great tips from the responses above.

Another way I have been handling requirments is to create a package hierarchy which reflects the broad functionality to be delivered (might even map to components in a sales orientated component diagram) with a dependency diagram.  I create requirements within the relevant package and turn on level numbering.

I have also been using custom stereotypes to capture additional information, e.g. business priority, which did not fit in the defaults and you could create a stereotype or tag so that you could flag a requirement as a heading or what ever and even % complete and then use the improved filtering in the reports to get it to output it as you wish - not sure if this is actually that relevant to you but may be of interest.

Robert

[Paul Lotz]

Thanks for your replies.  I finally had some time to devote to trying these with some justice.  Sorry for the delay.

I don't think I'm there yet.

Here is what I found:

I'm glad the Element list has an option to show the hierarchical structure in build 846 as Roy mentioned.  This helps a little when I also display the Status of each requirement.

I hadn't thought to show the Relationships matrix.  That is a helpful suggestion.  On the other hand, it doesn't help much if you want to see the big picture.

"Find orphans" is something of which I was also unaware.  Unfortunately applying it to the requirements tree returns no results.  It is for a different purpose.

Implementation and Dependency reports: I had previously tried these and they are helpful, but only to a point.
      a) Implementation report--This does indeed help show what is implemented.  It can also show unimplemented items, but here there is the problem that it shows me the "heading" requirements as well, which is what I was trying to avoid.  I suppose I can ignore all those elements returned that don't have a -n after them, but it would be nice if I could set the report to do that.
      b) I haven't been able to get the Dependency report to do much for me yet.  Maybe I just haven't figured it out yet....

Graham has a (custom?) solution that sounds like it works, but I'm not sure I understand it, at least in the context of the issue I am trying to solve.


Robert's comment I think is getting to the heart of the matter:
"I have also been using custom stereotypes to capture additional information, e.g. business priority, which did not fit in the defaults and you could create a stereotype or tag so that you could flag a requirement as a heading or what ever and even % complete and then use the improved filtering in the reports to get it to output it as you wish - not sure if this is actually that relevant to you but may be of interest."  I'm not sure what it would take to do the customization.

Let me rephrase the question differently.

Let's say we import a couple hundred requirements from DOORS.  Probably about 60% of those are headings, not "actual" requirements.  Let's say we've gone through and linked all but 10 of those requirements to model elements and correspondingly changed the status of those requirements to "Implemented." How would you find the 10 requirements not yet implemented (without returning any "heading" requirements)?  (Well, it's OK to show the headings to clarify the hierarchy, but it should be very clear they are headings and not one of the 10 requirements not yet covered.)

Paul

[ebeb]

Hi Paul,

I think I see the point. The problem is that you are using requirements elements for both headings and real requirements.

I'm not sure how Doors import works and if it might be customizable, but if yes, the easiest way would be to simply turn all headings to packages (as graham suggested) and keep only the real requirents as requirement elements.

May be you customize the add on or write a little Perl script to parse EA's XMI files to replace requirements by packages, if nothing helps and you still want it automatable.

Otherwise, you need to tag all heading elemtens and use some sophisticated search techniquie.

[EDIT]
Actually I'm now experiencing the same problem. I have some use cases and requirements, both hierarchically nested. When I use the relationship matrix I can see all use cases and requirements, eventhough they are just intended as "headings". I could solve this for the requirements by inititally using packages instead of requirements. But the top level use cases must remain use cases to keep the visible appearance of use cases which is importatant for generated documents.

So, it would be nice If there is an option to treat them as packages but keep ther visual appearance. So that a requirements search would not return these elements.
[/EDIT]

Regards,

Jan

[Paul Lotz]

"I think I see the point. The problem is that you are using requirements elements for both headings and real requirements.

I'm not sure how Doors import works and if it might be customizable, but if yes, the easiest way would be to simply turn all headings to packages (as graham suggested) and keep only the real requirents as requirement elements."

Yes, that is exactly the problem.  I understand the goal of turning all headings into packages but this will not work with the DOORS import tool (and converting heading requirements to packages in EA will cause us to lose synchronization with DOORS).

Paul

[Graham_Moir]

Just a couple of extra comments

1) The relationship matrix requires packages for source and target which seems to me to be an argument for structuring the elements into packages.
2)  As stereotype is not an attribute for requirements, as well as organisation in packages we also use "Requirement Type"  (Settings/General Types/Requirement tab  - this is just called "Type" in the requirements properties dialogue) as a method of distinguishing between different types of requirement.
3) There is also the "hierarchy" window which is useful for showing relationships and for me more intuitive than the relationships window
4) When I use "Find Orphans" it finds requirement elements that have no relationships - not sure why it doesn't work for you.

[Paul Lotz]

Graham,

I totally agree with at least your first two points.  These don't address the issue at hand, however, at least as far as working with requirements imported from DOORS.

Paul

[Paul Lotz]

OK, what I think is this:
A "heading requirement" is a different type of animal from a "regular requirement."  These are two fundamentally different things and have different "needs" when it comes to traceability relationships and so on.  (I want to trace a "regular requirement" to another [nonrequirement] model element or a method in code.  I never want to do this for a "heading requirement." On the flip side, I want to establish a hierarchical relationship between a "heading requirement" and all the requirements below it (which I never want to do with a "regular requirement.")  Furthermore, I want the reporting capabilities to reflect the requirements coverage in a manner consistent with these two types of relationships, such that I can see the coverage comprehensively in a single report or view.  (Ultimately I want to see which requirements we have covered [and where] and which remain to be covered without a lot of extraneous information [in other words, I don't want EA to tell me "heading requirements" don't have realization links to [nonrequirement] model elements or code since these shouldn't anyway.)  Additionally, I want EA to point out where in the hierarchy uncovered requirements remain, which means EA must understand the requirements hierarchy (which it already kind of does).

Why would anybody not want this?

Paul

[Paul Lotz]

I looked more into "Find Orphans."

The EA help describes this as:
"Find Orphans - Searches for orphaned elements throughout the model, with the ability to filter on common element fields using a search term. An 'orphaned' element is an element that does not appear on any diagram in the model."

EA correctly returns no results when I run it on my requirements hierarchy, since all requirements appear on requirements diagrams.  (Further, all requirements have links, if only to other requirements in the hierarchy.  Further, I can and do use the drag and drop method to establish realization links between requirements and [nonrequirement] model elements [indepependent of any diagram], so that checking for which requirements don't appear on any diagram is not a good test of the relationships I am seeking in this case.)

Paul

[Graham_Moir]

Paul - thanks for the clarification on "Find Orphans"which is useful.

Also with regard to "Heading Requirements" which we would call "Scope Requirements" we actually use an aggregation relationship rather than realization as the heading/scope statement element is essentially a container for the real requirements.   Similarly our high-level requirements are aggregations of the detailed requirements, it's only when we get to Use Cases do we start to use the realize relationship.   The Hierarchy window uses terms like "Composed of" and "Realized by" to reflect this which is more intuitive for us.

[Paul Lotz]

Graham,

You wrote:

Also with regard to "Heading Requirements" which we would call "Scope Requirements" we actually use an aggregation relationship rather than realization as the heading/scope statement element is essentially a container for the real requirements.

Exactly!  Our requirements diagrams have aggregation relationships to show the hierarchical relationships.  (If we were using SysML we would use the namespace containment relationship.)

So, yes, we see "composed of," "part of," and "realized by" in the Hierarchy window.  We should also distinguish between aggregation/containment relationships and realization relationships in the various views and reports.

(Note that in our case we are using realization relationships between individual "real" requirements and the [nonrequirement] model element or code file that realizes that requirement.)