RELATÓRIO DE ESPECIFICAÇÃO DE REQUISITOS

Transcrição

1 RELATÓRIO DE ESPECIFICAÇÃO DE REQUISITOS LABORATÓRIO DE GESTÃO DE PROJECTO Carlos Frias Manuel Seixas Sérgio Junior FACULDADE DE ENGENHARIA UNIVERSIDADE DO PORTO 22 Março 2013 Filipe Mota Manuel Melo Tiago Pereira João Pereira Mariana Cardoso

2 RELATÓRIO DE ESPECIFICAÇÃO DE REQUISITOS LABORATÓRIO DE GESTÃO DE PROJECTO FACULDADE DE ENGENHARIA UNIVERSIDADE DO PORTO 22 Março 2013

3 CONTEÚDOS 1 INTRODUÇÃO 4 2 OBJETIVOS 6 3 ESPECIFICAÇÃO DE REQUISITOS Requisitos Funcionais Atores Diagramas de Casos de Uso Narrativas do Utilizador Requisitos Suplementares Requisitos Não Funcionais Breve descrição da interação da aplicação - servidor 17 4 TECNOLOGIAS UTILIZADAS 19 5 PROTÓTIPO NÃO FUNCIONAL 21 6 CONCLUSÃO 27

4 1INTRODUÇÃO

5 1INTRODUÇÃO Com este relatório o grupo visa aqui apresentar toda a informação recolhida do cliente bem como todas as especificações por este requeridas, num formato concreto e por extenso, de forma a verificar que todos os elementos aqui presentes estão completos e em conformidade com o pedido do cliente. Ao longo das seguintes páginas irão ser apresentados os objetivos do trabalho a desenvolver pela empresa nas seguintes semanas, no âmbito da disciplina de LPGR, requisitos funcionais e não funcionais extrapolados do encontro e diálogo com o cliente, uma breve descrição das tecnologias a utilizar e esboços de uma possível interface gráfica a empregar e melhorar no desenvolvimento do produto. 5 Relatório de Especificação de Requisitos

6 2OBJETIVOS

7 2OBJETIVOS Ao longo das passadas semanas, o grupo 3 da empresa Fat Tomato ficou responsável pelo desenvolvimento de uma framework e aplicação nativa de Windows8 para um dispositivo móvel que permitisse estender as funcionalidades já existentes, a nível de gestão, oferecidas pelo portal do colaborador da empresa CPC.iS. Esta framework deverá ser a base desta aplicação e de aplicações futuras e deverá assegurar serviços-base para lidar com autenticação (por exemplo, usando OAuth), comunicação com webservices de forma segura (por exemplo, usando TLS ou SSL), permitindo assim, a comunicação entre os dispositivos móveis e os servidores da empresa, possibilitando uma extensão das funcionalidades que o website disponibiliza mas, nos dispositivos móveis dos colaboradores. Esta framework deverá ainda, permitir serviços de gestão de dados locais para uso offline, que deverão ser atualizados no sistema, assim que a aplicação fique online. Esta informação local será encriptada para garantir que não é acedida indevidamente. Deverão ser usadas tecnologias que não estejam restritas a um único sistema operativo (por exemplo, HTML5 e Javascript) e uma estrutura modular de forma a facilitar a portabilidade da aplicação para outras plataformas de desenvolvimento. Por fim, o grupo irá também desenvolver um conjunto de relatórios, como este, de forma a apresentar os progressos da equipa, a arquitetura que se pretende empregar na aplicação e web services, outras informações que sejam passíveis de ser documentadas e julgadas pelo cliente e um, ou mais, protótipos que demonstrem as funcionalidades do produto. 7 Relatório de Especificação de Requisitos

8 3ESPECIFICAÇÃO DE REQUISITOS

9 Requisitos Funcionais 3ESPECIFICAÇÃO DE REQUISITOS Atores Segundo a informação recolhida, numa fase inicial o sistema terá apenas dois tipos de atores. Previamente ao login na aplicação temos o Colaborador Não Autenticado que, não tendo acesso a qualquer funcionalidade, apenas pode iniciar a sua sessão. Após o login temos o ator Colaborador que tem acesso as funcionalidades do sistema que lhe estão atribuídas. 9 Relatório de Especificação de Requisitos

10 Requisitos Funcionais 3ESPECIFICAÇÃO DE REQUISITOS Diagramas de Caso de Uso Visão geral do sistema: 10 Relatório de Especificação de Requisitos

11 Requisitos Funcionais 3ESPECIFICAÇÃO DE REQUISITOS Diagramas de Caso de Uso Autenticação: Consultas: 11 Relatório de Especificação de Requisitos

12 Requisitos Funcionais Diagramas de Caso de Uso 3ESPECIFICAÇÃO DE REQUISITOS Justificação de falta: Marcação de férias: 12 Relatório de Especificação de Requisitos

13 Requisitos Funcionais Narrativas do Utilizador: 3ESPECIFICAÇÃO DE REQUISITOS A primeira coisa que faço como Colaborador não autenticado da aplicação para o Windows 8 do Portal do Colaborador da minha Empresa é o login. Para autenticar-me na aplicação insiro as credenciais da minha conta, existentes na Activity Directory da em presa. Após estar autenticado a aplicação reconhece-me como um Colaborador e eu: Marco o meu plano inicial de férias para o meu ano de trabalho; Consulto o meu calendário de férias para garantir que está tudo em ordem (este dinamicamente adapta-se as minhas modificações), podendo escolher o ano do calendário que pretendo consultar; Consulto o meu histórico de pedidos, podendo-o organizar pelas categorias: Pedido, Motivo, Início/Fim, Criação/Alteração, Estado ou Detalhe ; Consulto as notificações que recebo à medida que os meus pedidos são tratados internamente na Empresa, podendo filtrar as minhas notificações em Lida, Não lida e Sem Seleção, de forma a encontrar mais facilmente a notificação que pretendo; Confirmo os dias que efetivamente vou de férias (dos dias iniciais que marquei no meu plano de Férias); Não confirmo os dias que não vou de férias que tinha marcado no plano e ganho saldo de férias; Uso o meu saldo de férias para marcar férias numa data que não tinha planeado inicialmente; Justifico a minha ausência da Empresa onde especifico:. o período de dias da minha ausência;. o meu motivo para faltar;. e submeto um documento comprovativo da minha ausência, já preparado no dispositivo ou insiro uma foto que tirei diretamente ao documento; Satisfeito com as minhas operações, faço logout da aplicação. 13 Relatório de Especificação de Requisitos

14 Requisitos Suplementares 3ESPECIFICAÇÃO DE REQUISITOS Regras de negócio: Um colaborador deve efectuar uma marcação de férias para cada plano de férias. As férias marcadas poderão ser confirmadas, e assim passam a ser consideradas como férias efectivamente gozadas. As férias marcadas poderão também ser não confirmadas, sendo assim consideradas pelo sistema férias não gozadas, adicionando-se ao saldo de férias do colaborador o mesmo número de dias não confirmados. A marcação de férias com saldo pode ser efetuada várias vezes para o mesmo plano de férias. A marcação de férias com saldo pode ser efetuada apenas se o colaborador tiver saldo (um colaborador não pode ter saldo negativo). A marcação de férias de um ano só é permitida até Março do ano seguinte. A marcação de dias de férias só pode ser efetuada em dias úteis (não é permitida a marcação de férias a fins de semana ou feriados). Não é permitido justificar uma ausência para um dia em que já existem pedidos (confirmados ou pendentes). Não é permitida a confirmação de dias de férias de um ano se todas as férias do ano anterior ainda não foram confirmadas. A marcação de férias com saldo pode ser efetuada apenas se o colaborador tiver saldo (um colaborador não pode ter saldo negativo) 14 Relatório de Especificação de Requisitos

15 Requisitos Suplementares 3ESPECIFICAÇÃO DE REQUISITOS Desenvolvimento de Webservices: Para efeito de testes de comunicação entre a aplicação e os servidores da empresa irão ser criados webservices em.net, cujo objetivo é simularem o real funcionamento do servidor de dados da empresa. Apesar dos dados que vão fornecer serem fictícios, estes serviços terão que ser 100% funcionais dado que, mais tarde, terão de ser integrados com o sistemas da empresa e preenchidos com dados reais. Assim, permitimos uma maior flexibilidade na adaptação dos dados reais da empresa à nossa aplicação. 15 Relatório de Especificação de Requisitos

16 Requisitos não Funcionais 3ESPECIFICAÇÃO DE REQUISITOS Segurança O sistema deve proteger a informação de acessos não autorizados através da utilização de um sistema de autenticação e verificação de privilégios (protocolo OAuth). Usabilidade O sistema deve ser simples e fácil de usar. Escalabilidade O sistema deve estar preparado para crescer com o crescimento do número de utilizadores e das correspondentes operações Disponibilidade, Fiabilidade e Robustez Dado o intuito da aplicação ser primeiramente os dispositivos móveis, a aplicação deverá estar disponível a qualquer altura, em qualquer lugar, sendo para isso necessário um sistema fiável e robusto. Flexibilidade e portabilidade A aplicação deverá ser desenvolvida de forma flexível e modular de forma a facilitar a portabilidade e aplicação a outras plataformas de desenvolvimento. Acesso à internet A utilização completa da aplicação pressupõe uma conexão do dispositivo à Internet (Wi-Fi, GPRS, outros). Manutenção offline de informação A aplicação em modo offline permite somente a consulta de notificações, pedidos e calendário de férias se estes estiverem disponiveis em cache (o colaborador eventualmente poderá restringir que informação será guardada na aplicação). Design standard de Windows 8 O design da aplicação deverá seguir os princípios e guidelines do design UX (ou Metro) e deverá cumprir as normas necessárias para ser aceite na Store do Windows8. 16 Relatório de Especificação de Requisitos

17 3ESPECIFICAÇÃO DE REQUISITOS Breve descrição da interação da aplicação - servidor 1º Exemplo: O colaborador efetua login na aplicação com as suas credenciais. É verificado se estas existem na activity directory da empresa. Caso a resposta seja positiva, é de imediato enviado uma série de informação relativa ao colaborador por parte do servidor da empresa, desde o plano de férias, lista de pedidos a lista de notificações recebidas. O seguinte diagrama de sequência esboça este processo: 17 Relatório de Especificação de Requisitos

18 3ESPECIFICAÇÃO DE REQUISITOS Breve descrição da interação da aplicação - servidor 2º Exemplo: Caso o utilizador deseje fazer alguma alteração, por exemplo: confirmar o aproveitamento de um dia de férias, é enviado um pedido de alteração do dia de férias aos servidores da empresa. O seguinte diagrama de sequência esboça este processo: 18 Relatório de Especificação de Requisitos

19 4TECNOLOGIAS UTILIZADAS

20 4TECNOLOGIAS UTILIZADAS Plataforma de desenvolvimento: Windows 8; Linguagens a utilizar (Front-end): HTML5; CSS3; Javascript; Design UX (Metro); Linguagens a utilizar (Back-end): C#; Protocolo de autenticação: Oauth; Cifra de encriptação: Oauth; Software IDE: Visual Studio 2012; 20 Relatório de Especificação de Requisitos

21 PROTÓTIPO NÃO 5FUNCIONAL

22 5PROTÓTIPO NÃO FUNCIONAL Ecrã de Login Menu principal (Home) 22 Relatório de Especificação de Requisitos

23 5 PROTÓTIPO NÃO FUNCIONAL Menu de Férias Formulário de Marcação do Plano de Férias 23 Relatório de Especificação de Requisitos

24 5PROTÓTIPO NÃO FUNCIONAL Formulário de Confirmação de Férias Formulário de Marcação de Férias com Saldo 24 Relatório de Especificação de Requisitos

25 5PROTÓTIPO NÃO FUNCIONAL Consulta do Plano de Férias Formulário de Justificação de Ausência 25 Relatório de Especificação de Requisitos

26 5PROTÓTIPO NÃO FUNCIONAL Os Meus Pedidos Listagem de Notificações 26 Relatório de Especificação de Requisitos

27 6CONCLUSÃO

28 6 Dada CONCLUSÃO por concluída esta fase, o grupo entende que foi capaz de recolher todos os requisitos do nosso projeto assim como os possíveis riscos no desenvolvimento deste. Tendo em conta que esta fase foi propícia ao levantamento de dúvidas, isto fez com que a comunicação entre membros da equipa e sobretudo entre equipa-cliente fosse melhorada. Após leitura e aprovação do relatório por parte do cliente, o grupo parte então para próxima fase, elaborar a arquitetura da framework, webservices e aplicação. 28 Relatório de Especificação de Requisitos