When services start sequentially, dependencies are implicit in the order of startup. Parallelism benefits from explicit dependencies.
serel allows dependencies to be expressed as:
xml - serialisation of the W3C's Resource Description Format [wc00]
special comments inside boot scripts, as per the Linux Standard Base Specification [lsb]
synchronisation primitives usable from within boot scripts
Examples are shown in Appendix A.
These options offer comparable expressive power to each of the actors with an interest in dependencies: system administrators, OS vendors, and service developers.
Integrity of the dependencies is critical to a healthy boot. serel aggregates dependencies into graphs, which may correspond to a runlevel, a switch between runlevels, or other granularities such as "network" or "windows". Graphs are tested for integrity prior to committing to parallel boot.  
It is not assumed that dependencies for all services are known at boot time. Best-effort handling of "unknown" services involves starting such services after all parallel services have finished and retaining the order of startup from the non-serel boot. Other approaches are possible.
Early releases of serel distributed default dependencies by inserting special comments within boot scripts. This approach carries a number of undesirable properties, including the burden of maintaining dependencies scattered across dozens of files. serel now distributes default dependencies in a single xml configuration file.
Apple's OS/X 10 starts it's services in parallel [sv00]. Dependencies are expressed via xml configuration files, one per service.