It is a usual situation when your cube users ask for a new attribute in a cube dimension. You will add the attribute in your project and deploy the changes which in turn get the related measure groups unprocessed. This can be a problem if your processing time is greater than the user patience…
We just had the described situation at one of our customers. The processing time for the target measure group was about 20 hours!
As a trick at the design time we can create one or two invisible "reserved" attributes in the dimension that probably undergoes an extension in the future. As they are not used they hold a single dummy member which will cost you very little processing time and storage space. When the time comes you rename the attribute, make it visible und populate with real data (ProcessUpdate). The attribute relationships for them should of course stay flexible. If you have no certain suggestion at the time of design where in the relationship tree you need them in the future – just hang them on key attribute. Also when it will be structurally wrong place later, just remember that we are talking about giving the customer a new analysis possibility and postponing the full process of the measure group. In any case you can find it better to process a big measure group one time instead of three times.
This trick can be extrapolated to the case of the new dimension which makes the whole cube unprocessed. But this poses more questions for the initial design. For example which measure groups should be connected to it? Of course the answer comes from your particular situation.