Scope
This set of requirements is for defining a plug-in system for CERT, to enable the easy adding and removal of different types of detectors at runtime.

1.	Allow the user to add one or more plugins.
a.	When adding a plugin offer to move it to one of the standard application support folders if it isn’t already in one.
2.	Allow the user to remove one or more plugins.
a.	Offer to move the plugin to either the trash or a ‘disabled plugins’ folder.
3.	Allow the user to toggle processing of each plugin at runtime.
4.	Allow the user to include or not include the results of each plugin when collecting results.
5.	The display of each AU should automatically appear if it’s turned on and disappear if it’s turned off.
6.	The application will need to adjust it’s UI at runtime (as opposed to compile time) based on which plugins are available and activated, creating views for each one and arranging them.
7.	Each plugin should offer one or more services.
8.	Each plugin may require zero or more services.
9.	At runtime, active plugins would be run in an order based on which services they need/offer.
10.	There needs to be a standardized way of transferring data from one step to the next.
11.	A simpler approach than the previous two requirements would be to pre-define several steps in the process and have each plugin decide in which step it should run.
a.	One step is just after finding a set of faces.
b.	Another would be during the kernel process, just after the SVMWeight multiplication.
12.	Steps that don’t have direct dependencies on each other should run in parallel.
13.	Each AU (or emotion) detector should be separately loadable and runnable.
14.	Each AU (or emotion) detector should have a unique label which should be defined as part of the plugin or data file(s).
15.	Performance should be as close to that of the current version as possible.
16.	Implementation language should be C++, but Objective-C has much better plugin support.