Requirements list for scheduling solution

 User viewpoint
 1. Easy to use, intuitive
 2. Easy to administer
 3. Group scheduling
 4. Room scheduling
 5. Public and Private schedule views
 6. Public Holidays/Vacations and other absences
 7. Flexible time views (day/month/year/etc...)
 8. Sync with Palm/Handspring/Psion/Other PDAs

 9. Configurable notifications of meetings via Email, window popups, SMS,
    etc..
 10.Integration with email for notifications and also for creating meetings
 11.Integration with Outlook scheduling groupware
 12.Linux native fat client
 13.FreeBSD native fat client
 14.Solaris native fat client
 15.Support for personal to-do lists
 16.The ability to delegate and share personal calendars

 Web Client
 17.should approximate feature parity with the fat clients (binary clients)
 18.Browser agnostic (support all modern browsers)

 19.Should be able to be run on Apache or iPlanet, and therefore be able to
    support HTTPS with ease.

 20.Web interface should have a modicum of flexibility, so we can customize
    look-and-feel, etc...
 21.Solid web front-end
 22.web client should be lightweight (no Java and light on the JavaScript)

 LDAP integration
 23.User authentication against LDAP
    LDAP should be the user directory referenced for scheduling. (the list
 24.of possible attendees as shown in the client should come directly from
    LDAP, so we don't need to maintain a distinct user database)

 25.LDAP groups should be used for scheduling groups via the calendar
    server.
 26.Support for Dynamic groups from LDAP.

 27.Resources such as conference rooms should be maintained in LDAP as well
    (since we already track these in LDAP for use via phonebook)

 Administrator viewpoint
 28.Low maintenance
 29.Automation of standard maintenance tasks
 30.Backups solution that should support live backup

 31.Database synchronization across multiple calendaring nodes (Decreased
    latency for remote office usage and a possible mechanism for failover)
 32.Full support for timezone differences between nodes
 33.Server(s) run on Sparc/Solaris platform, preferably with Solaris >= 8

 34.Preferable if it used an IETF endorsed, open-standard calendaring
    protocol such as iCalendar (RFC 2445)

 35.Connection between fat client and server should be stateless or
    re-entrant (prevents clients closing down due to downed server)

 36.Calendaring policy and conflict checking should be handled by the
    server (not the client, which should be as dumb as possible)

 37.Backend database should be a well understood standard and not
    proprietary.

 38.Backend database support for oracle or Berkeley DB or similar would be
    nice
 39.An API for the calendar server should be available
 40.High availability/Redundancy
 41.Client support on solaris/windows/mac
 42.An open feel to the product (no black boxes if we can help it)
 43.Command line and GUI tools

 44.Ability to obtain text dumps of the data from the command line suitable
    for filtering through pipelines (Unix)
 45.Reasonable licensing/procing plan
 46.Reasonable upgrade cost
 47.Technical support (phone/web/etc...)
 48.Technical support cost
 49.Automated setup of accounts integrated with adduser script