Esta seção é responsável por apresentar o levantamento de requisitos a serem atendidos para a concepção da infra-estrutura CollaboraTVware. Vale lembrar que esta infra-estrutura visa auxiliar na solução do problema da sobrecarga de conteúdo presente na TV Digital Interativa através de um serviço de classificação, capaz de extrair padrões a partir de um conjunto de participações colaborativas obtidas de diversos usuários, e um serviço de predição, responsável por auxiliar, de posse dos padrões obtidos pelo serviço de classificação, na escolha de programas e serviços por um determinado usuário conforme o seu perfil e contexto.
No escopo deste trabalho, a participação colaborativa corresponde à
avaliação atribuída pelos usuários no sentido de expressar a sua opinião sobre o
programa ou serviço interativo consumido conforme índices pré-definidos. Esta opinião pode ser uma avaliação tradicional como por exemplo: “ruim”, “regular”, “bom”, “ótimo”, “excelente”; pode também representar o grau de satisfação no uso
de um determinado serviço interativo: “muito insatisfeito”, “insatisfeito”, “pouco satisfeito”, “satisfeito” ou “muito satisfeito”; ou até mesmo expressar uma opinião que tenha uma relação direta com natureza do conteúdo em questão, como é o caso de um programa educativo com as seguintes avaliações a serem escolhidas pelos usuários: “básico”, “intermediário”, “avançado”, “pouco didático”, “didático”, dentre outras. Ou então, no caso de um programa jornalístico: “pouco informativo”, “informações formativas”, “interessante”, “informações como diversão”, “notícias que distraem”, “sensacionalista” e “entretenimento”. Como pôde ser visto, a avaliação pode variar conforme o estudo de caso a ser aplicado.
Um outro termo também empregado no trabalho é modelo de
conhecimento. Um modelo de conhecimento, conforme visto na seção 6.2 e
exemplificado na seção 6.2.1, pode ser traduzido como o resultado obtido do aprendizado supervisionado de uma função em uma tarefa de classificação. Neste trabalho referem-se aos padrões extraídos pelo serviço de classificação e utilizados pelo serviço de predição. Tais serviços e modelo de conhecimento serão discutidos em detalhes mais adiante na arquitetura proposta (seção 8.7).
Antes de serem apresentados os requisitos propriamente dito é importante mencionar também que a infra-estrutura CollaboraTVware é composta por dois subsistemas: dispositivo do usuário e provedor de serviços.
A seguir são enumerados os requisitos funcionais e requisitos não funcionais identificados.
8.3.1 Requisitos Funcionais
Os requisitos funcionais (RFs) descritos abaixo foram classificados em dois tipos: RF-DU quando se referir a um requisito funcional do dispositivo do usuário; e RF-PS no caso de ser um requisito funcional do provedor de serviços.
• RF-DU.1 – Monitorar a interação do usuário com a programação disponível;
• RF-DU.2 – Registrar informações monitoradas na forma de histórico e agregá- las para serem enviadas ao provedor de serviços;
• RF-DU.3 – Atualizar o modelo do usuário de acordo com as informações obtidas diretamente do usuário;
• RF-DU.4 – Atualizar o modelo do usuário de acordo com as informações obtidas pela monitoração da interação;
• RF-DU.5 – Possibilitar o registro da avaliação atribuída pelo usuário a um determinado programa;
• RF-DU.6 – Prover um serviço de predição responsável por, de posse de modelos de conhecimento obtidos, predizer a avaliação dos programas aos usuários conforme o seu perfil e contexto corrente;
• RF-PS.1 – Prover um serviço responsável por obter informações agregadas dos dispositivos dos usuários e persisti-las;
• RF-PS.2 – Prover um serviço de classificação capaz de criar modelos de conhecimento segundo a avaliação de programas realizada por diversos usuários;
• RF-PS.3 – Prover formas de verificar o desempenho dos modelos de conhecimento gerados;
• RF-PS.4 – Prover um serviço de difusão de modelos de conhecimento a vários usuários simultaneamente;
8.3.2 Requisitos Não Funcionais
A seguinte relação de requisitos não funcionais (RNF) deve estar presente na solução:
• RNF.1 – Por questões de interoperabilidade, a infra-estrutura proposta deve ser alinhada com padrões de metadados voltados para TV Interativa (MPEG- 7, MPEG-21 e TV-Anytime), mesmo que seja necessário estendê-los;
• RNF.2 – Identificar e modelar as informações contextuais utilizadas pela infra- estrutura no dispositivo do usuário;
• RNF.3 – A infra-estrutura deve disponibilizar uma API (Application
Programming Interface) no dispositivo do usuário para que as aplicações
tenham acesso às suas funcionalidades;
• RNF.4 – Em termos de cenário, deve fundamentar-se no modelo funcional de referência do TV-Anytime para sistemas de TV Interativa (TV-ANYTIME, 2007a) como arquitetura de referência, bem como explorar o modelo de canal de retorno intermitente também proposto pelo TV-Anytime (TV-ANYTIME, 2000) devido à necessidade de comunicação no sentido dispositivo do usuário – provedor de serviços;
• RNF.5 – Solução independente de middleware embarcado, porém necessita da presença de máquina virtual Java (presente nos middlewares existentes, vide seção 2.1.2.1) e canal de retorno disponível (uso da pilha de protocolos TCP/IP);
• RNF.6 – Escalabilidade: é importante que a solução tenha escalabilidade de modo que parte do processamento deva ser distribuído, ou seja, realizado no dispositivo do usuário;
• RNF.7 – Privacidade: filtragem daquilo que deve e o que não deve ser compartilhado com os provedores, ou seja, definir o que é de caráter confidencial. A identificação do usuário (ID) e o seu nome, por exemplo, são informações confidenciais e o seu uso na infra-estrutura deve ser dispensado.