There are 2 tactics that I see that are common while validating Touch UI dialogues in AEM; a front-end way and a back-end way. I prefer the front-end way, as logic in the front-end will highlight the input field that is not valid, and also not allow the content authors to save the dialogue.
Out of the box, AEM Granite UI (Touch UI)Dialogues are using the jQuery Validation plugin. You can create your own jQuery Validation.
The back-end way will be you allowing the authors to save whatever value they choose, and the component in the editor mode page will display the component in RED (or some other indication) that there's a problem with the form dialogues. Sometimes you need to do this because you may want to validate the form data with your AEM backend... but you will be definitely introducing validation variables and code in your AEM component's sling model.
As you can imagine, the front-end way of using jQuery Validation gives the author a much quicker and instant feedback on what is missing In the touch UI dialogue.
You can choose based on use case. If the property is something that is must have for most pages, you can have it available during page creation (and as required probably) so that its value is set when a page is created. The authors don't need to worry about opening dialog again. The equivalent to dialog submit validation might have to be found.
If the property is an optional one, and needs to reside in a component dialog it can be chosen too, but its an add extra step for authors.