Too much requirements for my project

[araggones]

Hi everyone,

I have a project with +7k requirements but most of them follow a pattern. I would like to group them into different requirement groups. Doing this I hope to be able to link one requirement group with the elements related in Enterprise Architect. Somebody know how should I do this?

Thank you,
Araggones

[qwerty]

By creating packages or any kind of structure.

q.

[Dermot]

If you are importing these from a spreadsheet and wanting group them by packages - see the CSV import example in the whitepaper:
http://www.sparxsystems.com/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf
Alternatetively try the MS Office interface Excel importer:
http://www.sparxsystems.com/products/mdg/int/office/office-integration.html

[Josef Stadelmann]

What is a requirement?
Are your requirements expressed as a Use Cases?
If YES: How do you structure a Use Case?
Maybe if you catch AND structure your Use Cases properly, your  requirement count will go down to about 15%.
I have seen abstract requirements in excess of that and the first thing we had to do was to become concrete and
transform this abstract requirement list into real meaningful Use Cases.

The structure of a Use Case can be like that (I like to receive more ideas)
1. Use Case has a main flow
2. Use Cases for a start have a pre- and a post conditions, and they must all fulfill a purpose (post-condition).
3. Use Cases have invariants during the execution of the Use Case
4. Use Cases may well have side flows
5. Use Cases side flows have discriminants & discriminators to leave the main flow and enter the side flow
6. Use Cases may well run into exceptions
7. Use Cases in exception state needs to handle the exception
8. Use Cases structured that way have a lot more information for following models, be it analysis or design or what ever UML can provide.
9. Use Cases structured that way are what you need to develop the final system- and acceptance test. Because a Use Case defined must be shown by the final running system.

If all this shown here ends up in different even abstract requirements then rethink about what is said above and rewrite it as Use Cases as concrete as possible.

To group think about to which business domains your Use Case belongs to.
Business Domains may become your groups/packages/components/(sub-)systems. Grouping that way, may be a first step toward an well defined architecture.
 
Josef

[araggones]

Hello,

First of all thank you for your responses, I really appreciate it. Second, the requirements that I have are in DOORS. The objective that I have is to link them to my diagrams, doing this I will have the correct traceability between requirements and analysis.

Araggones

[qwerty]

So what is the question?

q.

[araggones]

Hi Qwerty,

I have been able to solve it, so everything ok now. Thank you and sorry for not be enough clear in my last response.

Araggones