Sparx Systems Forum

Enterprise Architect => General Board => Topic started by: JonTP on May 31, 2014, 12:30:23 am

Title: Requirement Hierarchy
Post by: JonTP on May 31, 2014, 12:30:23 am

When I generate a document from my requirements, any hierarchy is not preserved when the .docx document is produced.

• is this expected behaviour?
• can I preserve the hierarchy?

Thanks in advance.

Title: Re: Requirement Hierarchy
Post by: Helmut Ortmann on May 31, 2014, 12:57:00 am

Hi,

you have to model the hierachy.

The easiest thing is to use nested packages. But there are a lot of possibilities to control hierachy, derived from and more.


Helmut

Title: Re: Requirement Hierarchy
Post by: JonTP on May 31, 2014, 01:16:31 am

Thanks Helmut

I thought I had modelled the hierarchy. The hierarchy in the Project Browser (PB) mirrors what is on the diagram. That is to say, when a requirement is nested on the diagram it is one level down on the PB. In other cases the requirement is a derived requirement.

Maybe I'm missing something.

Title: Re: Requirement Hierarchy
Post by: Helmut Ortmann on May 31, 2014, 02:54:40 am

Hi,

you can model on a diagram
- nested relationship
- dependency with stereotype <<derive>>
  Have a lock in SysML: They have some stereotyped dependencies for requirements
- Simply put a requirement inside a requirement (also nested)
- There are also other ways

A good way is to use packages for the main organisation of requirements like:
- Customer requirements
- Software requirements
- Functional Requirements
- Non Functional Requirements
- etc.

Without knowing your specific domain and your requirements to organize requirements it's only possible to give general advice.

Personaly I think you could manage requirments with an UML tool like EA up to 1000 requirements. If you have more or sophistocated requirements to manage requirements consider using a specialized Addin or a special requirement tool.

Helmut

Title: Re: Requirement Hierarchy
Post by: JonTP on May 31, 2014, 03:10:35 am

Thanks Helmut.

Good advice. Thought I'd done all of this. One thing I did was drag from my requirements in PB onto the diagram and then create a nesting (or <<derive>>) connection between blocks. This is reflected on the diagram but does give the behaviour I have mentioned. I have used packages and sub-packages as well but this doesn't give me a full hierarchy.

You mention putting a requirement inside a requirement and I am assuming this is a drag and drop operation. I'll need to test whether that gives me what I am after.

Up to about 700 reqts at the moment and the experience leads me to concur with you top limit of 1000. Worth knowing that.

Thanks for taking an interest.

Title: Re: Requirement Hierarchy
Post by: Helmut Ortmann on May 31, 2014, 04:33:33 am

Hi,

consider:
- using http://www.raquest.com/ or other tools
- defining your requirement process
   (your requirements to your requirement process)

Usually management of requirements is an essential process. It's not simply visualizing requirements. It's working, management with them over a long period. They have different states and you may want to see what you will have to tackle after changing one of them, and...

So be careful to make quick decisions. 700 requirements are a lot. Don't take my 1000 requirements for granted. It's a ballpark figure not a fix number.

There are reasons why there are full equipped requirement tools.


Helmut

  

Title: Re: Requirement Hierarchy
Post by: JonTP on May 31, 2014, 10:21:52 pm

Food for thought. Thanks Helmut

JP

Title: Re: Requirement Hierarchy
Post by: Stefan Bolleininger on May 31, 2014, 11:37:37 pm

Hi,

working in requirements management without having another tool than Enterprise Architect, I currently consult projects bigger than 5000 req's within on Requirements specification. It is not about the number, it is about the structure and the usage. (I think they are competetive with other requirement management tools in efficiency and effectivity, however enterprise architect supports the project with complete modelling processes ;))

"Depending on your project teams' workflow and processes, the choice of the tool is a rational of their working processes and desired outcomes"

Regards

Stefan

Title: Re: Requirement Hierarchy
Post by: Helmut Ortmann on June 01, 2014, 04:14:40 am

Hi,

I support Stefans statements. It's a complex decision.

Helmut

Title: Re: Requirement Hierarchy
Post by: Robert Sheridan on June 05, 2014, 03:36:09 am

Have you tried using level numbering? You can turn it on for the packages and then include it in your report layouts.

Title: Re: Requirement Hierarchy
Post by: Nizam Mohamed on June 11, 2014, 01:56:04 pm

Jon
There are some very good suggestions here, adding to 'em, have you considered these...

• Template Fragments gives us a greater control to group nested requirements as separate sections in document (e.g. Tables )
• Also nesting in the documentation is directly related to how it is in the PB, and has very little to do with diagrams, so it might be worth to see if the nesting is reflected in the PB.

Title: Re: Requirement Hierarchy
Post by: JonTP on June 13, 2014, 06:03:10 pm

Thanks everyone. Ended up exporting to .docx and then re-creating my PB hierarchy using indents in the Word doc.

Did think about level numbering but the levels get so long 2.1.3.2.1.1 etc that they become difficult and confusing.

Did separate sections into packages so that I could apply Word numbering on headings which helped with readability.

Delivery deadline for the docs now passed so have moved on to something else.

Thanks for all the suggestions everyone.

JP