Simple question, is an required field indicator (ex. *) necessary when presenting a set of a radio buttons in a form?
Caveat, one radio button will be already pre-selected.
Technically the field question is indeed required, but does the fact that one selection is always selected negate the need to visually indicate that it is required?
The problem at hand does not seem to be a question of correct asterisk marking rules, or a literal interpretation of metaphor behind the radio button control.
Rather, the conflict from your description appears to be this: While the two radio button selection instances are marked as required, the requirement is already fulfilled by pre-populated selection. However the true requirement seems to me that your user should make a meaningful choice, not just any.
So let's first ensure that that actually happens, and then think about appropriate UI presentation.
Pre-populated but required selections can be problematic because a momentarily inattentive user may consent to 'canned' choices that aren't what they would actually choose. The design problem is less a case of "You must make any old choice in order to proceed", and conformity with hard conventions for required selections, but more of "Make sure the radio button selection we pre-populated for your convenience is actually what you wish".
Yes, the asterisk to indicate required is technically redundant, as others have written. But if it is critical that your users provide accurate information on this page (and that's what required implies), present all choices in an indeterminate start state, including radio buttons. Do not pre-populate anything.
That would ensure that as your first-time user encounters the set of forms each and every one must be filled, checked, and selected ("signed, sealed, delivered...") before the calls to action 'Cancel' and 'Save' become available to them.
It is perfectly okay to my mind to present a set of radio button type controls in an initial none-selected state, even though the physical metaphor of radio button controls implies a type of 'whack-a-mole' behaviour ('one pops in, all other ones pop out' kind of thing). But remember that this is just a metaphor. If you're working within a development kit of sorts, or even a prototype application like Axure RP, UI controls like that usually come as a library 'widget' with black-box behaviour at first. That is an unfortunate constraint, but more often than not it can be overridden. If you have some progressive disclosure going on - i.e. a set of choices presented further down-page depend on an earlier radio button setting, you could even add a 'clear' function to return the radio button set to a nil state.
Looking at your UI example, it occurs to me that all forms are mandatory.
The effect of marking them as such repeatedly (*) gets washed out because the constraint seems universal to all of them - unless your actual form is longer and you're just presenting an excerpt for simplicity, or the form consists of several further pages on which compulsory selections are interspersed with optional ones.
I would therefore guard-rail the user by two things:
A collective headline sub-caption "All selections are required". If all selections are truly required, say so in no uncertain terms.
Disable 'Save', until all selections have been made, up to the very last one. Keep 'Cancel' active; this is how your user can safely exit the form.
By the above an explicit verbal instruction tells your user why the calls to action are blocked. If in addition, present all possible selections initially in an indeterminate state and thus force your user - appropriately - to provide the necessary information with intent and purpose, rather than have them inadvertently accept canned selections in auto-pilot mode.
Note I said initially. The above describes the carte-blanche state in which a first time user should find the form. If there is a function by which the user can instruct the application to remember my settings, all selections become sticky and can be edited (as needed, or simply left as they are) on subsequent visits.
I hope that helps. Best of success!
You should only mark the field as required if the user must inform something in that field. In your example, since the user is not required to change the value of the fields, you don't need to mark them.
There is a potential problem with interpreting the requirements from the user's point of view when you make a pre-selection or default choice in a mandatory field. If none of the choices are suitable to the user and the field is mandatory then you have not allowed the user to indicate that this is the case.
Normal practice would be to make mandatory only those fields that are absolutely required, and with radio buttons to ensure that all potential possibilities are covered (e.g. by using 'others') if the field is mandatory.
Pre-filling information works best when you have some information from the users to provide a strong indication of a preference, otherwise it is possible for people to skip fields that have data entered already when you actually want a confirmation from users that they have read and filled in the details.
From what I have been reading, it is easier on the user to only mark the optional fields. From what you have shown all are required, so why add the noise of the *? By switching to that model, the question becomes solved.
If you need to keep it, you might place it at the end of the label and change the color to a grey.
