The generally most important requirement is of course the possibility of an unattended installation. SCCM is in theory designed to allow user interaction but it's basically counteractive to the idea of mass deployment and I don't think it is used anywhere in practice.
I would say as minimum allow a completely silent installation (equivalent of /qn msi parameter) but if possible also a passive one (equivalent to /qb-! meaning progress bar but no option to cancel no dialogs to accept).
If there are options in your setup allow for parameters or a response file. If possible present those options when -? is specified and also in documentation.
In general SCCM will just run a given commandline but the main difference from running it yourself is that it will use the builtin system account.
Normally there should not be any differences to a normal admin user with uac but I have seen several setups fail only in that case, so you should always test with that user. You can use psexec or paexec to run a commandline as system account. Because of this default (or at least a commandline option) should be to install for all users. If per user files or reg_keys have to be set those should be done on first program start not via setup. If it absolutely has to be done before first program start SCCM allows for executing with user rights once per user but you need a seperate setup (or commandline) and it is a dangerous practice (assume updates are running when user first starts the program - user setup would be queued)
Reboots should be avoided at all costs. They are not feasible for mass deployment of software imo. If they absolutely have to be note that SCCM does in the package/program deplyoment model not support "conditional" reboots, so if there is a possibility for a reboot it always has to happen. In the application deployment model it is possible to use the default return codes 3010 = Soft Reboot and 1641 = Hard Reboot to allow application controlled reboots. I would however avoid to force the SCCM admin to use a specific deployment method.
Feedback to the user is generally only possible via logs and return codes. Any form of blocking popup will not work well with sccm. Even if you argue that the popup would only be present in case of an error you have to consider that sccm deplyoment is usually used to run a software on hundreds if not thousands of computer and the user in front of those computers has absolutely no use for an error message. Even worse if your software blocks and there is other software queued it will have to wait until your software returns.
If you think there is a high probability that a installation is not successful I would recommend good logging (maybe allow for a special log besides default msi logging which can be hard to read) and even more good documentation. It is in general a nice thing to have a special documentation for unattended deployment that explains all the properties. If you have many cases that might lead to deployment failure explain them there as well. The admin deploying your software has to know those beforehand he will never be able to test well enough and if he finds out about them afterwards it might be too late.
With those caveats mentioned it is also important to say that there is one method of setup that is vastly preferred by Microsoft themselves and that is silent msi installation with product code (might be default fo all msis) In their application deployment model they allow the admin to create the whole application directly from the file. The product code will be used for detecting successful installation and uninstall is also directly possible if wanted. Of couse other forms of setups are supported as well (just less easy). In the older package/program model there is no difference between msi or anything else.
