Re: ISSUE-7: Gathering requirements [Calendar API]

On Sep 16, 2009, at 18:32 , <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com 
 > wrote:
> Key Functionality:
>
> * Create a new calendar event
> * Update an existing calendar event
> * Remove an existing calendar event
> * Find existing calendar events

This does not include support for multiple calendars, is that  
intentional?

> Notes:
> * An iCalendar [1] format MUST be used to represent an 'event' object
> throughout the Calendar API.

This bit is not clear: iCalendar is a format, whereas we'd have to  
deal with an API. Are you saying that the data model behind the format  
(which is quite extensive) should be supported by objects  
encapsulating events? Because that brings in a fair amount of  
information — not that I disagree with mapping to iCalendar, but we  
should discuss how extensive we are. At the very least summarising  
what iCalendar offers (e.g. repeats, all-day events, etc.) would be  
helpful.

One further thing that isn't included here is the ability to export to  
an iCalendar file. If the model is iCalendar anyway it should be  
simple, but as a requirement it's rather useful because it can then be  
attached to an email.

> Does anyone expect any more than this in the first instance of API
> requirements? Does anyone see the need to break down the key
> functionality to medium and low level requirements at the beginning or
> during the API creation phase?

No, but detailing this a little bit when referencing an external  
source is helpful.

> Perhaps others have different views on the best process to use. For
> example, an alternative proposal could be to begin with use cases and
> work out the required functionality from there or to look at existing
> implementations and identify the shared core functionality as the  
> basis
> for any given API (FYI, the Calendar API requirements included above  
> are
> a loose paraphrasing of BONDI Calendar API requirements).

Right. As discussed before we'll only go to the more complex, heavy  
requirements process if the lightweight one doesn't work.

--
Robin Berjon
   robineko — setting new standards
   http://robineko.com/

Received on Wednesday, 23 September 2009 11:38:21 UTC