Andrey Estevão da Silva. Ferramenta de Auxílio aos Estudos: Rede Social de Estudo on-line. Bookman

Transcrição

1 2011 Ferramenta de Auxílio aos Estudos: Rede Social de Estudo on-line Bookman Andrey Estevão da Silva

2 UNIVERSIDADE ESTADUAL DE GOIÁS UNIDADE UNIVERSITÁRIA DE CIÊNCIAS EXATAS E TECNOLÓGICAS BACHARELADO EM SISTEMAS DE INFORMAÇÃO ANDREY ESTEVÃO DA SILVA Ferramenta de auxílio aos estudos: Rede Social de Estudo Online Bookman Anápolis Mês (por extenso e sem abreviação), 2011

3 UNIVERSIDADE ESTADUAL DE GOIÁS UNIDADE UNIVERSITÁRIA DE CIÊNCIAS EXATAS E TECNOLÓGICAS BACHARELADO EM SISTEMAS DE INFORMAÇÃO ANDREY ESTEVÃO DA SILVA Ferramenta de auxílio aos estudos: Rede Social de Estudo Online Bookman Trabalho de Conclusão de Curso apresentado ao Departamento de Sistemas de Informação da Unidade Universitária de Ciências Exatas e Tecnológicas da Universidade Estadual de Goiás, como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Esp. Guiliano Rangel Alves Anápolis Abril, 2011

4 PREFÁCIO O presente trabalho servirá de documentação ao sistema Bookman, tratando da parte de relacionamentos humanos (anseios do cliente) e demonstrar minuciosamente a estrutura do projeto. O projeto é uma extensão do projeto inicial, ampliando o uso do aplicativo para as redes sociais, onde usuários poderão ler textos, realizar estudos e compartilhar tanto textos como estudos pela web. A intenção é tornar o programa um aplicativo para qualquer rede social, sendo realizadas para isso melhorias de usabilidade, aprimoramento de funções já existentes no programa e o acréscimo de funções pertinente ao ramo de negócios: Ferramentas de estudo. Relacionando a estrutura deste documento, podem ser encontrados os seguintes tópicos: - Lista de elementos gráficos: Com esta, pode-se localizar mais facilmente as tabelas e figuras do projeto. - Tabela de revisões: Irá permitir mensurar e descriminar as alterações feitas no projeto em cada iteração ou correção. - Dicionário do projeto: Apresentará a definição de cada termo que se relaciona aos artefatos do software. - Gerência de Projeto: Deve mostrar como serão organizadas as atividades, o tempo previsto para conclusão de cada uma e o progresso realizado em cada semana. - Modelagem do Negócio: Deve explicitar o que foi discutido em reuniões catalogadas em atas, a descrição do negócio e a lista dos requisitos que irão compor o mesmo.

5 TABELA DE REVISÕES Esta tabela contém um histórico das revisões do documento. As entradas na tabela abaixo servem apenas de caráter ilustrativo. As demais entradas deverão ser apagadas até que a revisão a que ela se referir tenha sido criada. Versão Principais Autores Descrição da Versão Data de Término V1.0 Andrey Estevão Guiliano Rangel V1.1 Andrey Estevão Guiliano Rangel Confecção do diagrama de atividades, Processo de Desenvolvimento de Software, Atas de Reunião, Relatórios de Progresso Semanal Correção do diagrama de atividades, Processo de Desenvolvimento de Software, Atas de Reunião, Relatórios de Progresso Semanal, e elaboração da Lista de Requisitos e confecção do préprojeto para avaliação do orientador. Tabela 1 Tabela de Revisões 26/03/ /04/2011

6 SUMÁRIO 1 Lista de Elementos Gráficos Lista de Tabelas Dicionário do Projeto Gerência do Projeto Processo de Desenvolvimento de Software Cronograma de Atividades Relatório Semanal de Progresso Relatório Semanal de Progresso n.º Relatório Semanal de Progresso n.º Relatório Semanal de Progresso n.º Relatório Semanal de Progresso n.º Modelagem do Negócio Ata de Reunião Ata n.º Ata n.º Ata n.º Ata n.º Ata n.º Descrição do Negócio Lista de Requisitos Referências... 25

7 1 Lista de Elementos Gráficos 1.1 Lista de Tabelas Tabela 1 Tabela de Revisões... 5 Tabela 2 Processo de Desenvolvimento de Software Tabela 3 Cronograma de Atividades Tabela 4 - Relatório Semanal de Progresso n.º Tabela 5 - Relatório Semanal de Progresso n.º Tabela 6 - Relatório Semanal de Progresso n.º Tabela 7 - Relatório Semanal de Progresso n.º Tabela 8 Ata de Reunião n.º Tabela 9 Ata de Reunião n.º Tabela 10 Ata de Reunião n.º Tabela 11 Ata de Reunião n.º Tabela 12 Ata de Reunião n.º Tabela 13 Lista de Requisitos... 24

8 2 Dicionário do Projeto

9 3 Gerência do Projeto 3.1 Processo de Desenvolvimento de Software Fase Análise de Requisitos, Projeto, Protótipos de Interface, Implementação Incremental, Validação, Implantação Manutenção e Evolução Atividade Fase 1 Análise de Requisitos: Conhecimento de negócios Consiste em saber do que o cliente necessita antes da formulação de um projeto. As técnicas podem variar de uma conversa informal da equipe de projetos com o cliente a formulários elaborados em conjunto ou não com técnicas de entrevista. O ideal é que haja uma pré-entrevista para que haja o preparo necessário para próxima fase, buscando-se ter uma idéia do que o cliente necessita, para se fazer um prévio conhecimento do negócio (quando desconhecido) para-se fazer uma extração de requisitos eficaz e mensurar tecnologias de projeto que possam vir compor o futuro sistema. As reuniões devem ter curta duração e com moderadores capazes de neutralizar opiniões fora de pauta de reunião e sensíveis ao clima de reunião, podendo até requerer seu adiamento. Extração de Requisitos De posse do conhecimento do negócio em questão, a equipe de projetos procura ouvir o que seu cliente necessita. Neste ponto pode-se destinar membros da equipe que possam ser capazes de fazer pequenos protótipos de interface para serem mostrados em momentos propícios da reunião, auxiliando a comunicação e principalmente bons redatores que irão mostrar o conteúdo escrito na reunião ao cliente para que possa analisa-lo. As reuniões para compreensão dos requisitos podem variar em seu número, dependendo do tamanho do sistema em questão. Quaisquer comunicações a respeito do sistema devem ser documentadas a fim de gerar manuais explícitos de como devem ser expressos os anseios do cliente no desenvolvimento do software. Especificação de Requisitos Sabendo-se do que se trata cada requisito, os mesmos devem ser organizados em módulos ou componentes do sistema final. Isso possibilitará que a equipe de projetos possa trabalhar simultaneamente nos módulos desenvolvendo incrementos paralelos, caso haja uma equipe de tal porte e irá separar o projeto por responsabilidades. As tecnologias possíveis de serem aplicadas devem ser mostradas ao cliente, podendo-se combinar nessa fase valores de módulos e a formulação de um contrato.

10 Fase 2 Projeto Modelagem de casos de uso Mostrar as interações dos atores do sistema com o mesmo bem como a interação entre componentes do sistema, visualizando assim as relações do mesmo pela ótica de funcionalidades e quem (atores) as ativa. Modelagem das classes de negócio Aqui será descrito o cerne da aplicação, bem como as responsabilidades de cada módulo. As classes de negócio deverão ser englobadas pelo projeto arquitetural, que irá definir em qual subsistema as mesmas ficarão. Modelagem dos diagramas de atividades O diagrama de atividades auxilia na compreensão dos requisitos por meio de fluxos aos quais o sistema deverá se submeter. São os diagramas considerados como de mais simples linguagem da UML em que até mesmo o cliente que desconhece das técnicas de desenvolvimento poderá ter uma compreensão dos processos do seu sistema. Modelagem arquitetural Aqui já se consegue mensurar qual o tamanho do projeto final, abstraindo o sistema numa visão em camadas. Cada camada pode englobar pacotes como subsistemas, facilitando a compreensão dos mesmos para equipe de projetos na interpretação dos diagramas, tecnologias que deverão ser empregadas e no desenvolvimento com preceitos corretos do paradigma de orientação a objetos. Modelagem dos diagramas de sequência Tais diagramas servem para projetar a estrutura interna de desenvolvimento do software, os processos que as funções devem desparar e a interação dos atores com tais funções. Fase 3 Protótipos da interface Irão facilitar a comunicação entre cliente e equipe de projetos. O cliente consegue se expressar melhor por meio visual aquilo que ele não sabe como resolver. Nesta fase podese seguir preceitos das metodologias ágeis, em que o cliente é participante ativo do desenvolvimento do sistema, fazendo críticas aos protótipos antes que um esforço maior da equipe para implementação seja feito. Pode-se mostrar interface por interface e implementálas em seguida ou a cada interface uma iteração de implementação, orientando-se pela necessidade da implantação dos módulos. Fase 4 Implementação incremental Avalia as necessidades dos módulos do sistema para o cliente para saber se haverá uma entrega de requisito por requisito ou do sistema pronto. Caso a entrega seja incremental, cada requisito deve passar pela fase de validação e testes de aceitação. Fase 5 Validação

11 Nesta fase deverão ser realizados testes para garantir que os módulos sejam entregues ao cliente em pleno funcionamento. Dentre estes testes, podemos citar: 1. Teste de Unidade e Módulo: A realização de testes para verificar a presença de erros e comportamento adequado a nível das funções e módulos básicos do sistema. Pré-condições: Classes de teste de unidades implementadas. Pós-condições: Funcionalidades validadas. 2. Integração: A reunião dos diferentes módulos em um produto de software homogêneo, e a verificação da interação entre estes quando operando em conjunto. Pré-condições: Classes de teste de integração implementadas. Pós-condições: Funcionalidades validadas. 3. Teste Funcional: Verificar se as funcionalidades definidas em cada requisito estão sendo executadas corretamente. Pré-condições: Classes de teste funcionais implementadas. Pós-condições: Funcionalidades validadas. Fase 6 Testes de implantação Verificar o software em ambiente de execução, ou seja se não há conflitos com outros softwares do ambiente do cliente e se os requisitos de hardware especificados para implantação suportam a execução do sistema. Nesta fase podem ser combinados treinamentos com o cliente, conforme contrato especificado. Fase 7 Manutenção e Evolução Possibilitar ao cliente prestação de serviços em caso de erros não averiguados pelo cliente após os testes de execução em sua presença, abrangendo o sistema totalmente, possibilitando ao mesmo suporte técnico e implementação de requisitos posteriores. Tabela 2 Processo de Desenvolvimento de Software

12 3.2 Cronograma de Atividades Atividade Previsão Entrega Compreensão do ponto de partida para nova versão do projeto 05/03/ /03/2011 Levantamento de Requisitos do sistema 12/03/ /03/2011 Estudo dos Requisitos 19/03/ /03/2011 Elaboração do Cronograma 26/03/ /03/2011 Análise de Requisitos 26/03/ /03/2011 Definição de Requisitos 07/04/2011 Entrega do Pré-Projeto 08/04/2011 Especificação dos Requisitos 16/04/2011 Definição do Processo de Software 30/04/2011 Protótipos de Interface 15/05/2011 Desenvolvimento dos requisitos da 1 ª iteração 30/05/2011 Entrega do Pré-Projeto de TC 03/06/2011 Apresentação do Pré-Projeto 18/06/2011 Correção do Pré-Projeto 24/06/2011 Modelagem e Detalhamento dos casos de usos 02/06/2011 Modelagem Conceitual 13/08/2011 Especificação da Arquitetura 27/08/2011 Realização dos Casos de Uso 10/09/2011 Diagrama Geral de Classes 24/09/2011 Especificação de Dados 30/09/2011 Conclusão do desenvolvimento, realização de testes e conclusão do projeto 04/11/2011 Apresentação do Projeto 26/11/2011 Tabela 3 Cronograma de Atividades

13 3.3 Relatório Semanal de Progresso Relatório Semanal de Progresso n.º 01 Relatório Semanal de Progresso N.º 01 Período 24/02/2010 a 02/03/2010 Atividade Planejada Definir com o orientador quais os requisitos propostos para este ano, alé m de aprender a manipular bem o sistema a fim de sugerir novas idéias e/ou mudanças. Atividade Realizada O sistema não pode ser estudado ainda devido a dificuldade técnicas de execução, aprendizado para o mesmo. As atas foram desenvolvidas, conforme as reuniões. Estamos ainda no aguardo da disponibilização do termo de aceite no ambiente virtual, para que possa ser assinado. Próximo Período 03/03/2011 à 09/03/2011 Planejado para o próximo período Tentar adquirir conhecimento para execução do software, afim de opinar o que deve ser melhorado e como deve ser pensada a documentação e posterior desenvolvimento dos requisitos propostos na ata de reunião nº 2. Avaliação do Período de Trabalho pelo orientador Ótimo Bom Regular Ruim Tabela 4 - Relatório Semanal de Progresso n.º 01

14 3.3.2 Relatório Semanal de Progresso n.º 02 Relatório Semanal de Progresso N.º 02 Período 03/03/01 09/11/2011 Atividade Planejada Adquirir conhecimento para execução do software, para opinar o que deve ser melhorado, como deve ser pensada a documentação e posterior desenvolvimento dos requisitos da ata de reunião nº 2. Atividade Realizada O software foi executado com uma série de erros. Alguns gems que deveriam ser usados não constavam a sua versão, influindo na instalação, pois de versão para versão do Rails podem não ser executados corretamente: mudanças em suas dependências e até no próprio Ruby. O indexador de buscas não foi bem inicializado. Testes foram realizados para descobrir quais versões utilizadas. Plugins como o do banco de dados já nem são mais compatíveis com a versão do rails e ainda deveriam ser tomadas notas de instalação de alguns drivers do postgres, que poderiam ser obtidos por mecanismos de instalação automática do Linux. O leia-me foi atualizado. Ainda há erros de execução não solucionados, provavelmente ocasionados pela não atualização do projeto corretamente. Não pôde ser observada a visualização de um arquivo hierarquizado pelo software. Próximo Período 14/03/11 a 21/03/11 Planejado para o próximo período Após perfeita execução do software, propor novas soluções para os requisitos discutidos até data atual, dando inicio a documentação dos mesmos Avaliação do Período de Trabalho pelo orientador Ótimo Bom Regular Ruim Tabela 5 - Relatório Semanal de Progresso n.º 02

15 3.3.3 Relatório Semanal de Progresso n.º 03 Relatório Semanal de Progresso N.º 03 Período 14/03/11 a 21/03/11 Atividade Planejada De posse da perfeita execução do software, propor novas soluções para os requisitos discutidos até data atual, dando inicio a documentação dos mesmos. Atividade Realizada As soluções foram discutidas com o orientador e documentadas em ata. Durante a semana foi elaborado um cronograma ao qual o projeto irá se adequar, aguardando apenas o parecer do orientador para algumas observações referentes a período para execução das fases e se todo conteúdo do DMS fora abrangido. Próximo Período 27/03/2011 à 02/03/2011 Planejado para o próximo período Elaboração do processo de software e adequação do DMS para a entrega do projeto de TC do dia 08 de abril de 2011 Avaliação do Período de Trabalho pelo orientador Ótimo Bom Regular Ruim Tabela 6 - Relatório Semanal de Progresso n.º 03

16 3.3.4 Relatório Semanal de Progresso n.º 04 Relatório Semanal de Progresso N.º 04 Período 26/03/11 a 02/04/11 Atividade Planejada Corrigir todas as atas escritas até o momento, elaborar a lista de requisitos, montar o documento de pré-projeto com o conjunto de arquivos confeccionados até o momento Atividade Realizada Todas as atas foram corrigidas, foi elaborada a lista de requisitos e o documento de pré-projeto falta ser avaliado pelo orientador antes da entrega. Próximo Período 02/03/2011 à 09/03/2011 Planejado para o próximo período Correção de todas observações feitas pelo orientador e confecção do documento que estará sujeito a avaliação da banca de pré-projeto. Avaliação do Período de Trabalho pelo orientador Ótimo Bom Regular Ruim Tabela 7 - Relatório Semanal de Progresso n.º 04

17 4 Modelagem do Negócio 4.1 Ata de Reunião Ata n.º 01 ATA da Reunião n.º 1 Data Horário Local 12/03/2011 Das 17:00 as 17:30 Ambiente Virtual (Skype) Equipe técnica Equipe usuária Teor desta reunião Andrey Estevão e Guiliano Rangel Não se aplica A reunião serviu para levantamento dos possíveis requisitos que irão compor anova versão do BookMan para este ano, foi feita de maneira presencial. Durante a conversa foram revelados os seguintes anseios : O BookMan deverá integrar-se a redes sociais, deverá possuir indice remissivo (Exemplo semelhante à Bíblia), Conversor de medidas e melhorias de visual (Ex: ao passar o mouse por um link, renderizar uma miniatura do documento/página) Observação Importante Técnica utilizada: Entrevista Informal Requisitos Registrados - Os requisitos que foram levantados nessa reunião, caso existam. - O BookMan deverá integrar-se a redes sociais - Deverá possuir índice remissivo - Conversor de medidas - Melhorias de visual (Ex: ao passar o mouse por um link, renderizar uma miniatura do documento/página) Tabela 8 Ata de Reunião n.º 01

18 4.1.2 Ata n.º 02 ATA da Reunião n.º 2 Data Horário Local 28/08/2011 Das 16:30 as 17:00 Ambiente Virtual (Skype) Equipe técnica Equipe usuária Teor desta reunião Andrey Estevão e Guiliano Rangel Não se aplica Nesta reunião foram retiradas algumas dúvidas sobre o sistema. Dentre elas estão: A documentação do projeto deste ano deverá ser melhorada, porém seguirá com base na antiga. A IDE em que foi desenvolvido foi o Netbeans. As gems utilizadas estão no arquivo LEIA- ME do projeto, porém haverá auxílio do orientador, na manipulação das mesmas devido a problemas decorrentes da atual Versão do Rails, gerando incompatibilidade. Não era necessária uma instalação do Ubuntu para facilitar meu trabalho no PC, porém o orientando que deu início ao projeto(douglas Nículas) deu início no Ubuntu, por razões até então desconhecidas e irrelevantes. Propus que já que será apresentado em uma rede social, o cadastro de estados deveria acompanhar ou acessar uma base pronta, porém a recomendação no momento é de que fique como está. Tirei dúvidas também sobre o que era segmento onde a resposta foi a definição de um nível mais baixo do texto. Exemplo: Bíblias Versículos, Texto simples Linhas. O próximo item da reunião foram sugestões e tarefas a serem desenvolvidas até a reunião seguinte. A minha primeira ideia foi o requisito de Manter Resumos, que foi aprovada para o desenvolvimento do projeto. Foram definidas algumas datas de entrega para as tarefas da semana. Ficou a orientação de que, a medida que formos avançando com o projeto, fosse adequado o antigo conteúdo ao DMS novo. Será necessário também definir um processo de desenvolvimento de software, de data até então não marcada para entrega. Para o dia 02 de março de 2010, ficou marcado para entregar ao orientador, as duas atas feitas até agora e o termo de aceite, caso entregue no Moodle ou Grupo do Yahoo. Como requisitos, foram propostos para a versão do BookMan deste ano, os requisitos mencionados na ata nº 01 e os do tópico requisitos registrados Observação Importante Técnica utilizada: Entrevista Informal Requisitos Registrados - Requisito Manter cronograma de estudo, definido até a última versão como requisito futuro ( deve ser melhorada a sua especificação) - Requisito Manter texto em PDF - Será melhorado o requisito Manter Vínculo entre Textos - Requisito Manter Comentário - Requisito Manter dicionário - Requisito Exibir TimeLine mostrar nas redes sociais propostas os textos lidos, onde foram lidos (em que parágrafo, linha do texto o leitor está). Tabela 9 Ata de Reunião n.º 02

19 4.1.3 Ata n.º 03 ATA da Reunião n.º 3 Data Horário Local 12/03/2011 Das 17:00 as 17:30 Ambiente Virtual (Skype) Equipe técnica Equipe usuária Teor desta reunião Andrey Estevão e Guiliano Rangel Não se aplica Nesta reunião definimos novos requisitos: - Foi definida a possível criação de uma API de comunicação para projetos diversos, uma vez que ainda este ano haverá a integração do projeto para dispositivos móveis. - Para que tal fato aconteça deverá haver a criação de um plugin genérico para todas as redes sociais. - Foi passada a orientação para que a TimeLine seja definida de modo que não apenas Orkut, Facebok e twitter possam utilizar o aplicativo. - O orientador revisou a documentação do projeto feita até agora e aprovou o conteúdo escrito até o momento. - Definida também a atualização para a versão atual do Rails (Rails 3.0.5). - Sugestão de documentação com base no DMS anterior e criação de arquivos PDF facilitando a portabilidade. - Me propus a criar um SVN para compartilhamento dos arquivos do projeto. Observação Importante Técnica utilizada: Entrevista Informal Atualização do ambiente de desenvolvimento Requisitos Registrados - Fornecer API - Comunicação entre sistemas - Exibir TimeLine Tabela 10 Ata de Reunião n.º 03

20 4.1.4 Ata n.º 04 ATA da Reunião n.º 4 Data Horário Local 16/03/2011 Das 20:00 as 20:30 Universidade Estadual de Goiás Equipe técnica Equipe usuária Teor desta reunião Andrey Estevão, Vinícius e Guiliano Rangel Não se aplica Foram estipuladas algumas atividades para cada projeto. Tornou-se oficial o fato de que o Bookman teria sua versão Mobile, feita no Android, porém implementada em um outro projeto, o que nos fez cogitar a criação de webservices. A compreensão dos requisitos referentes à rede social tornou-se mais clara: É quem será a reponsavel por fornecer a API descrita nas atas anteriores, sendo capaz de comunicar-se com as redes sociais e fornecer subsídios para plataforma móvel, ofertando condições para que outros sistemas possam vir a implementar a ferramenta. Destrinchou-se também a função da Timeline, equiparando-a com a função Atualizações do Orkut, que permitirá o usuário mostrar nas redes sociais os textos lidos, bem como o detalhamento de trechos. Foi anotado um requisito futuro: Ler texto em PDF. Ficou registrado outro requisito, o de disponibilizar textos carregados para outros usuários, ou seja, tornar textos públicos ou privados. Foi esclarecida ainda a relação de usuários na qual o sistema irá operar, em que Usuários participam de grupos e podem ser especializados em usuários comuns ou moderadores. Observação Importante Técnica utilizada: Entrevista Informal Os usuários cadastrados deverão ser do tipo moderador ou usuário comum. Requisitos Registrados - Comunicação via webservices - Ler texto em PDF - Manter Grupos de Usuários - Disponibilizar Textos/ Base de dados de Texto Tabela 11 Ata de Reunião n.º 04

21 4.1.5 Ata n.º 05 ATA da Reunião n.º 5 Data Horário Local 26/03/2011 Das 20:00 as 21:00 Ambiente Virtual (Skype) Equipe técnica Equipe usuária Teor desta reunião Andrey Estevão, Vinícius e Guiliano Rangel Não se aplica Foram revisadas todas as atas e todos os relatórios semanais de progresso. Sobre a arquitetura, devem ser feitos mais enfoques na rede social e procurar detalhar melhor a arquitetura com relação a rede sociais. No cronograma foi mencionado o termo Projeto de TC, porém o termo correto é Pré-Projeto. Foi explicado que a especificação de requisitos não entra no pré-projeto, somente a definição. As iterações serão Uma por VA, ou seja, uma carga de tarefas será combinada e esta deve ser entregue no prazo estipulado. Ao revisar o cronograma, vimos que um mês e meio de implementação seria pouco, devido à exigência de tempo dos requisitos e para aproveitar melhor o poder da linguagem. Para especificação de requisitos faremos uma reunião presencial.sobre o requisito Manter PDF, faremos pesquisas para saber se há alguma maneira de manipular as linhas do arquivo (fazer anotações, marcações, etc), pois até onde conhecemos só seria possível fazer isso página por página. Sobre as atas referentes à Timeline, foi orientado ter cuidado com os conceitos: Ela será responsabilidade da aplicação e não das redes sociais, se comportando como uma rede social própria. Os integrantes da rede social serão chamados de parceiros de estudo.sobre a pagina inicial, definimos que o fluxo inicial não seria partir da tela de cadastro e sim de uma página onde já fosse exibida a Timeline, pois assim a apresentação do software ficaria mais rica, mostrando os parceiros de estudo relacionados ao estudo e o que estavam lendo, ex: últimos 3 textos lidos.a ata 3 está com o local errado e limita o projeto apenas a PDA s, porém o escopo, envolve todos dispositivos móveis. Na ata 4, foi solicitado falar como foram divididas as atividades do projeto web e mobile, não apenas citá-las. Sobre onde se fala de fornecer a base de dados, melhorar o texto, pois não ficou claro. Novos requisitos também foram identificados e serão expostos no tópico Requisitos Registrados. Observação Importante Técnica utilizada: Entrevista Informal Requisitos Registrados - Requisito Realizar Carga do Texto Download de XML original do texto. - Requisito Exportar estudo. - Importar componentes de estudo (vínculos, anotações, dicionário, plano de leitura/estudo) - Tela inicial (Melhorias detalhadas no tópico teor da reunião) Tabela 12 Ata de Reunião n.º 05

22 4.2 Descrição do Negócio O sistema Bookman é uma ferramenta de estudos on-line, cujo princípio se baseia na carga de textos para a aplicação, onde o usuário tem condições de estruturá-lo para seu estudo. Dentre as funções que o sistema apresenta até o momento estão: - Manter estado: O usuário é capaz de manipular as informações referentes ao estado onde reside. - Manter usuário: Função que permite ao moderador administrar os usuários da rede ou que um usuário possa manipular suas próprias informações. - Manter configuração do layout de estudo: Permite o usuário definir como será o layout de estudo utilizado, ou seja cores que o sistema deverá apresentar em cada ação do usuário, estilos de fonte, etc. - Manter anotações: Permite o utilizador realizar anotações sobre os trechos lidos, bem como gerenciá-las. - Manter marcações e tags: Permite o usuário gerenciar as marcações feitas sobre trechos estudados. - Navegar: Requisito que permite o usuário percorrer trechos relacionados. - Manter cronograma de estudo: Permite o usuário se organizar utilizando o software para gerenciar seu plano de estudos. - Manter histórico Permite o usuário verificar os textos que já leu. - Manter texto: Permite o usuário a realizar a gerência dos textos em que realizou carga. - Manter vínculo entre trechos permite que o usuário consiga realizar relações entre trechos lidos, ou de uma palavra com uma anotação. Tais requisitos compuseram a primeira versão do sistema. Para a versão a que este projeto se destina, tem-se a pretensão de implementar as funcionalidades de integração com redes sociais (e ser uma rede social), o que sugere que deve haver controles não apenas de usuários, mas de grupos de usuários, fornecer uma solução genérica para que qualquer rede social possa

23 vir a exibir o aplicativo, possibilitar o comentário de fatos ocorridos, mostrando as ações decorrentes de leituras e estudos feitos, publicar arquivos e anotações referentes a eles, ou seja, funções comuns de qualquer aplicativo de redes sociais. Ainda, para que outras aplicações possam desfrutar do aplicativo, deve haver um caminho ou manual para que se possa acessá-la, o que será providenciado por uma interface de programação (API). Há também a intenção de desenvolver algumas características que possam de certa forma enriquecer a estrutura de um texto simples, provendo e contextualizando informações, como por exemplo, gerar índices remissivos, converter medidas e criar dicionários. Outro requisito que irá compor o projeto deste ano é a melhoria visual e apresentação mais explícita das funcionalidades, características que tornam uma aplicação mais agradável e mais fácil de ser utilizada, facilitando assim a sua propagação pela web.

24 4.3 Lista de Requisitos Identificação R15 R16 R17 R18 R19 R20 R21 R22 R23 R24 R25 R26 R27 R28 R29 R30 Requisito Integração com redes sociais Gerar Índice remissivo Conversor de Medidas Amigabilidade Visual Manter Cronograma de Estudo Manter Texto PDF Gerenciar Comentários Manter Dicionário Exibir TimeLine Fornecer API Comunicar via webservices Manter Grupo de Usuários Realizar Carga(Download) de Texto XML Exportar Estudo Importar componentes de estudo Melhorar Tela Inicial Tabela 13 Lista de Requisitos

25 5 Referências SOBRENOME, Nome do autor. Ferramenta de Auxílio aos estudos: Rede Social de estudo online Bookman.