Product with multiple software packages and variants

Hi Gabe,

Normally we'd recommend creating a base Spira product that contains the core system requirements. Then you can create product variants as their own Spira products that contain the different core requirements.

Then you can share the core requirements from the base product to the variant products using the 'Product Associations' feature.

For example:

• Core features
  • Core feature 1 (project PR1)
  • Core feature 2 (project PR2)
  • Core feature 3 (project PR3)
• Product variants
  • Product A (PR4)
    • requirements from PR1
    • requirements from PR2
    • Its own requirements
  • Product B (PR5)
    • requirements from PR1
    • requirements from PR3
    • Its own requirements

Regards

David

My experience is that you should track requirements into Spira's projects that means your products.

And additionally to create Spira's projects that means your customers. Or to create one project "Customer support" where as a requirements create delivered bundles to customers. Those requirements should be associated to your prooduct's requirements via associations and by it you will have whole tracebility.

It sounds like you're dealing with a complex product ecosystem! In your case, referring to your offerings as "components" seems appropriate, especially since you have a base product, variants, and additional software packages. As for the optional software, you could categorize them as separate products or modules, depending on their independence. Connecting requirements across products is definitely feasible and can help ensure consistency and track dependencies. Retro bowl