Be VERY careful with those functions. You are inviting truncation because your input involves fractional numbers in division without explicit typecasts. Yes, you want integers as your Y/M/D result but you might have some oddball issues crop up.
Now... here is a crazy thought for you.
Take that input integer and use it as CDate(CDbl(NO))
Then format it as a short date. It will come out as something like 01/24/00
So separate the parts between slashes to get 00 years 1 month 24 days.
For SMALL values of NO, this might be off just a bit - but for 1184 days, you will get years, months, and days on a consistent scale. The larger NO happens to be, the better this gets as it takes leap days into account.
The thing is that technically (and this is ONLY for you purists out there), Neileg is spot-on. If you don't have a start date or an end date to put that number into context, it has no "real" meaning for conversion purposes. Out of context, X number of days is just X number of days. No matter HOW big it is, it is NO years and NO months. Because (thanks to Julius Caesar and Pope Gregory) our calendar is irregular. Without that reference point, TECHNICALLY your desired answer floats a couple of days either way.
Now, if you only wanted an approximation, go for it as noted. But be aware that the answer has about a 57% chance of being at least one day off on ANY arbitrary number of days and up to 3 days off for N less than 4 years.
PARTICULARLY if this triplet of <years,months,days> will be used in ANY OTHER computation, do the computation in days. If the result is an end in itself and is only being forwarded to management because they don't understand numbers of days greater than 30, you might get away with it - as long as they don't start marking things down on calendars.