A software GranuleOfRelease (or ''unit of modularity'') is a collection of software with the following attributes:

* Performs, or contributes to, a specific functionality
* All software within the GranuleOfRelease is necessary for completion of that functionality; it would be difficult to use only part of the GranuleOfRelease.  (It may be possible for specific such granules; but you shouldn't depend on that).
* May depend on other GranuleOfModularity''''''s (bad plural, I know); however ''the dependency graph among UnitsOfModularity should not contain any cycles''. Cycles among classes (etc) ''within'' a GranuleOfRelease are generally OK, though they should be short (no more than 2 or 3 participating entities); anything larger indicates that ReFactoring may be necessary.
* The GranuleOfRelease is the granule of reuse - see ReuseReleaseEquivalencePrinciple.  

Names given to granules of release in various languages and various works in TheLiterature include: class, module, package, cabinet, library, component, etc. Unfortunately, this is one area where the terminology could use some harmonization.

The phrase ''granule of release'' is chosen to avoid collisions with any of the above.

----

Many practitioners of various languages/paradigms insist that a particular language feature (such as the "class" or "module") is the proper granule of release. Languages which force the GranuleOfRelease to be a particular size usually result in maintenance/configuration headaches. That said, the UnitOfModularity generally shouldn't be smaller than a single class or stand-alone function. (Some languages require the GranuleOfRelease to be a class or first-class object; but allow other classes which do not have this functionality; that's OK. What is objected to is the notion that ''all'' classes should be releasable components).

Not to be confused with the GranuleOfDeployment. The GranuleOfRelease should be smaller than the GranuleOfDeployment.