Product with multiple software packages and variants

Thursday, October 13, 2022
Avatar

I have a single product that consists of multiple pieces of software all maintained by my team.  There are also variants of this product that inherit a majority of the requirements from the base product but then might have a few additional requirements.  A particular release of the base product might contain several releases of support software.

Are components the correct this to use in this situation? i.e.

  • Base Product
    • Product Variant 1
    • Product Variant 2
    • Software Package A
    • Software Package B

We also have various optional software products that may be installed into the Base Product.  Sometimes this might require changes to the Base Product and sometimes not.  Would these be considered separate products?  Can I connect requirements between products?

3 Replies
Thursday, October 20, 2022
Avatar
re: gabe.johnson Thursday, October 13, 2022

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

Friday, October 21, 2022
Avatar
re: gabe.johnson Thursday, October 13, 2022

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.

Spira's ProjectWhat requirements means 
Product AFeatures of the Product A 
Product BFeatures of the Product B 
Customer "AA"Bundles that were or going to be delivered. Might have multiple to multiple relations to all products. 
Customer "BB"Bundles that were or going to be delivered. Might have multiple to multiple relations to all products. 
OR  
Customer supportCustomers as a level-1 requirement and bundles with their timeline under it. 
   

 

Wednesday, October 16, 2024
Avatar
re: gabe.johnson Thursday, October 13, 2022

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

 

Spira Helps You Deliver Quality Software, Faster and With Lower Risk

And if you have any questions, please email or call us at +1 (202) 558-6885

 

Statistics
  • Started: Thursday, October 13, 2022
  • Last Reply: Wednesday, October 16, 2024
  • Replies: 3
  • Views: 1784