[HOME_NETWORK_TF] Priorities for requirements

Hi Giuseppe, here is my perspective on the relative priorities of  
requirements.

Some stand out as a common requirement that underpin everything else.  
These would seem obvious candidates to be high priority. Specifically:

... Security considerations (for applications, users and content):

     1.7.5.1 Application trust level
     1.7.5.2 Access to home network services
     1.7.5.3 Prevent leaking of information
     1.7.3.8 Content Protection

... And the basics of discovery of services and content:

     1.7.2.1 Service Discovery
     1.7.2.2 Content Discovery
     1.7.2.3 Content Players Discovery
     1.7.2.6 Media Identification

I believe Media Identification should be considered a higher priority. It  
is a prerequisite for applications to be able to properly relate items of  
media content to a wider web of data/content. This was at the core of most  
of the BBC's second screen scenarios and demos described in Berlin.

These alone are insufficient to fulfill most of the use cases and user  
scenarios identified. The use cases that seem most straightforward to  
address next and which also show the most immediate utility are those that  
support the ability to control and query media playback:

     1.7.1.1 Compatibility with widely deployed standards
     1.7.3.1 Control of content players
     1.7.3.2 Playback of content
     1.7.3.3 Playback of live content
     1.7.3.4 3 Box model
     1.7.3.5 Time-synchronization

The requirements listed above focus on enabling applications to utilise  
existing home network services.  The remaining requirements all enable use  
cases and scenarios that are of great interest, but could be considered a  
"next step" of making it possible for applications to advertise and/or  
offer services. I therefore would consider these to be of lower priority.

     1.7.2.5 Services Advertisement
     1.7.2.4 Content Advertisement
     1.7.3.7 Application communication
     1.7.4.1 Push migration
     1.7.4.2 Pull migration

Going for high accuracy time synchronisation enables a smaller set of  
scenarios than achieving some less precise degree of time synchronisation.  
It is also probably harder to do well. I'd also class this as lower  
priority.

    1.7.3.6 Accurate time-synchronization

regards


Matt
-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/

Received on Monday, 22 August 2011 08:07:00 UTC