Best practices for organizing requirements in large projects

[helengrace]

Hello everyone,

I would like to know how other teams organize and structure requirements in large or long-term projects inside Squash TM.
When the number of requirements grows, it sometimes becomes difficult to maintain a clear hierarchy and avoid duplicated or overlapping requirements. We are currentlySprunki Retake testing different approaches using folders, tags and links between requirements.
Do you have any recommendations or best practices for:

naming conventions,
requirement hierarchy,
traceability management,
or version handling?

I would be interested to hear how other teams manage this efficiently in real projects.

[alexiaamber]

I’m new to Squash TM, but I’ve been dealing with similar issues in larger projects. I find it helpful to keep the requirement hierarchy relatively shallow and use consistent naming conventions rather than creating too many nested folders.

For traceability, linking requirements to test cases and related items seems more maintainable than relying entirely on tags. I’d also suggest agreeing on a naming scheme early and documenting how versions or changed requirements should be handled.

I’d be interested to hear whether other teams prefer organizing primarily by project/module or by business feature when the requirement set becomes very large.