RELATÓRIO DE ESPECIFICAÇÃO DE REQUISITOS

(1)

FACULDADE DE ENGENHARIA

UNIVERSIDADE DO PORTO

22 Março 2013

Filipe Mota

Manuel Melo

Tiago Pereira

RELATÓRIO DE

ESPECIFICAÇÃO

DE REQUISITOS

LABORATÓRIO DE GESTÃO

DE PROJECTO

João Pereira

Mariana Cardoso

Carlos Frias

Manuel Seixas

Sérgio Junior

(2)

FACULDADE DE ENGENHARIA

UNIVERSIDADE DO PORTO

22 Março 2013

RELATÓRIO DE ESPECIFICAÇÃO

DE REQUISITOS

LABORATÓRIO DE GESTÃO

DE PROJECTO

(3)

1 | INTRODUÇÃO 4

3.1 Requisitos Funcionais 3.1.1 Atores 9

2.2.2 Diagramas de Casos de Uso 10

2.2.3 Narrativas do Utilizador 13

3.2 Requisitos Suplementares 14

3.3 Requisitos Não Funcionais 16

3.4 Breve descrição da interação da aplicação - servidor 17

CONTEÚDOS

2 | OBJETIVOS 6

3 | ESPECIFICAÇÃO DE REQUISITOS 8

4 | TECNOLOGIAS UTILIZADAS 19

5 | PROTÓTIPO NÃO FUNCIONAL 21

(4)

INTRODUÇÃO

1

(5)

Com este relatório o grupo visa aqui apresentar toda a informação recolhi-da do cliente bem como torecolhi-das as especificações por este requerirecolhi-das, num formato concreto e por extenso, de forma a verificar que todos os elemen-tos aqui presentes estão compleelemen-tos 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.

(6)

(7)

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 funcionali-dades 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 exemp-lo, usando OAuth), comunicação com webservices de forma segura (por ex-emplo, usando TLS ou SSL), permitindo assim, a comunicação entre os dis-positivos 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á en-criptada para garantir que não é acedida indevidamente.

Deverão ser usadas tecnologias que não estejam restritas a um único siste-ma operativo (por exemplo, HTML5 e Javascript) e usiste-ma 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 se-jam passíveis de ser documentadas e julgadas pelo cliente e um, ou mais, protótipos que demonstrem as funcionalidades do produto.

(8)

3

ESPECIFICAÇÃO

DE REQUISITOS

(9)

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 funciona-lidades do sistema que lhe estão atribuídas.

Requisitos Funcionais

3 _{ESPECIFICAÇÃO DE}

(10)

10 Relatório de Especificação de Requisitos

Requisitos Funcionais

3 _{ESPECIFICAÇÃO DE}

REQUISITOS

Diagramas de Caso de Uso

(11)

Requisitos Funcionais

3 _{ESPECIFICAÇÃO DE}

REQUISITOS

Diagramas de Caso de Uso

Autenticação:

(12)

Requisitos Funcionais

3 _{ESPECIFICAÇÃO DE}

REQUISITOS

Diagramas de Caso de Uso

Justificação de falta:

(13)

A primeira coisa que faço como Colaborador não autenticado da apli-caçã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

Requisitos Funcionais

3 _{ESPECIFICAÇÃO DE}

REQUISITOS

(14)

• 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, sen-do assim consideradas pelo sistema férias não gozadas, adicionansen-do-se ao saldo de férias do colaborador o mesmo número de dias não confirma-dos.

• 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 colab-orador tiver saldo (um colabcolab-orador não pode ter saldo negativo)

Requisitos Suplementares

3 _{ESPECIFICAÇÃO DE}

(15)

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.

Requisitos Suplementares

3 _{ESPECIFICAÇÃO DE}

(16)

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 desenvolvi-mento.

Acesso à internet

A utilização completa da aplicação pressupõe uma conexão do dispositi-vo à 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.

Requisitos não Funcionais

3 _{ESPECIFICAÇÃO DE}

(17)

O colaborador efetua login na aplicação com as suas

creden-ciais. É verificado se estas existem na activity directory da

em-presa. Caso a resposta seja positiva, é de imediato enviado uma

série de informação relativa ao colaborador por parte do

servi-dor 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:

Breve descrição da interação da aplicação - servidor

3 _{ESPECIFICAÇÃO DE}

REQUISITOS

(18)

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:

Breve descrição da interação da aplicação - servidor

3 _{ESPECIFICAÇÃO DE}

REQUISITOS

(19)

(20)

4 TECNOLOGIAS

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;

(21)

PROTÓTIPO NÃO

FUNCIONAL

(22)

5 _{PROTÓTIPO NÃO}

FUNCIONAL

Ecrã de Login

(23)

5 Menu de Férias

PROTÓTIPO NÃO

FUNCIONAL

(24)

5 _{PROTÓTIPO NÃO}

FUNCIONAL

Formulário de Confirmação de Férias

(25)

5 _{PROTÓTIPO NÃO}

FUNCIONAL

(26)

5 _{PROTÓTIPO NÃO}

FUNCIONAL

Os Meus Pedidos

(27)

CONCLUSÃO

6

(28)

6

Dada por concluída esta fase, o grupo entende que foi capaz de recolher to-dos os requisitos do nosso projeto assim como os possíveis riscos no desen-volvimento deste. Tendo em conta que esta fase foi propícia ao levantamen-to de dúvidas, islevantamen-to 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.