Vous êtes sur la page 1sur 38
UNIOESTE – Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado

UNIOESTE – Universidade Estadual do Oeste do Paraná

CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática

Curso de Bacharelado em Informática

Sistema Gerenciador de Hotel

Adriano Douglas Girardello Ana Paula Fredrich Tiago Alexandre Schulz Sippert

CASCAVEL

2009

ADRIANO DOUGLAS GIRARDELLO ANA PAULA FREDRICH TIAGO ALEXANDRE SCHULZ SIPPERT

SISTEMA GERENCIADOR DE HOTEL

Processo de Engenharia de Requisitos, Empresa: Hotel Real, Curso: Processo de Engenharia de Software II (PES II), Série: 4º ano.

Professor : Victor Francisco Araya Santander.

CASCAVEL

2009

Sumário

Capítulo 1 – Introdução

Capítulo 2 – Metodologia de desenvolvimento

Capítulo 3 – Cronograma de atividades

Capítulo 4 – Modelagem organizacional e Modelagem de requisitos não-funcionais

4.1 – Modelo de dependências estratégicas (SD)

4.2 – Modelo de razões estratégicas (SR)

4.3 – NFR Framework

Capítulo 5 – Requisitos do Sistema

5.1 – Requisitos funcionais

5.2 – Requisitos não-funcionais

Capítulo 6 – Caso de uso do sistema

6.1 – Descrições textuais dos casos de uso do sistema

Capítulo 7 – Diagrama de Classe do Sistema

7.1 – Descrições textuais das classes do sistema

Capítulo 8 – Conclusão

Apêndice A – Sobre o Hotel Real

Apêndice B – Entrevista

Apêndice C – Deficiências dos livros de registros

Apêndice D – Glossário

Capítulo 1 Introdução

A empresa escolhida para desenvolver o projeto de engenharia de software foi o Hotel

Real. O hotel está localizado na Avenida Brasil número 4506, centro, CEP 85.812-000, na cidade de Cascavel-PR. Atua com a razão social “Girardello Vacari & Cia Ltda.”. O Apêndice A traz uma descrição mais detalhada sobre o Hotel Real, assim como, discute com mais detalhes o dia-a-dia do mesmo.

O Hotel Real trabalha na área de hotelaria à mais de 30 anos. A empresa não possui

nenhum sistema automatizado de informação implantado, todas as atividades de operação como cadastros de hóspedes e empresas, controle de diárias, entre outras, são realizadas manualmente com o auxilio de livros de registros, como está detalhado no Apêndice C. Sendo assim, propõe-se a implantação de um sistema gerenciador hoteleiro que aperfeiçoe todas as operações que envolvam informações/dados do hotel. O sistema proposto será implementado na plataforma Windows com as seguintes características: os usuários farão uso de um computador localizado na recepção para cadastros de hóspedes e empresas, verificação de disponibilidade de quartos, gerenciamento de diárias

entre outras ações. O sistema será utilizado por diferentes funcionários, desde recepcionistas até a gerência, mas com níveis de privilégios diferenciados através de login e senha. Neste documento será apresentado um estudo detalhado dos Requisitos Funcionais, Não-Funcionais e modelagem organizacional (i* e NFR) do Sistema Gerenciador Hoteleiro, além dos diagramas de Casos de Uso e de Classe usando o padrão UML, que facilitam a visualização no processo de Engenharia de Requisitos.

O processo de elicitação de requisitos sobre a empresa, em forma de entrevista, está

detalhado no Apêndice B.

Capítulo 2 Metodologia de Desenvolvimento

No processo de desenvolvimento de software é extremamente importante e necessário que se faça uso de uma metodologia, tanto para a organização da produção quanto para a melhora em produtividade e qualidade. Dentre as principais metodologias e processos estão os modelos: Cascata, Iterativo e Incremental, Espiral, RAD, RUP, XP e Scrum. A metodologia escolhida para o projeto foi o Modelo em Espiral, pois é a que mais se aproxima das características do projeto a ser desenvolvido. Dentre elas, a possibilidade de que em cada iteração sejam obtidas versões do sistema cada vez mais complexas, podendo assim serem modificados alguns requisitos se o protótipo não estiver de acordo com o que o cliente deseja. Além disso, a eliminação de erros e alternativas inadequadas, através da análise de riscos e da revisão das atividades em cada ciclo, torna-se possível com essa metodologia. Outros modelos de desenvolvimento tem suas desvantagens, que foram consideradas como critérios de eliminação na escolha do modelo em espiral. Algumas destas desvantagens são:

O modelo em cascata não permite que se volte atrás em uma etapa. Em nosso caso os requisitos do usuário podem mudar, fazendo-se assim necessário que parte de uma etapa anterior possa ser reavaliada; Métodos Ágeis necessitam da presença constante do cliente para validação do desenvolvimento. Em nosso caso o cliente, ou seja, o gerente do hotel, não tem tempo suficiente para que possa estar envolvido com o processo de desenvolvimento. Métodos Formais implicam em muita documentação e muito tempo aplicado a fase de requisitos e projeto, sendo melhor aplicados em sistemas críticos. O projeto em questão é relativamente simples e não é um sistema crítico, sendo que não há necessidade de uso de métodos formais. O Modelo em Espiral consiste de basicamente quatro fases: Análise, Projeto, Implementação e Testes, que são repetidas até que se chegue a uma fase na qual o protótipo desenvolvido está suficientemente satisfatório do ponto de vista do cliente, para que seja considerado como sistema final.

Capítulo 3 Cronograma de Atividades

Para uma melhor organização e controle das atividades foi criado um cronograma especificando as atividades e o tempo que cada uma precisará para ser executada. O projeto tem como recursos humanos os integrantes do grupo deste trabalho e como recursos físicos as máquinas e laboratórios da Universidade em que o mesmo está sendo desenvolvido. A seguir são descritas as atividades a serem realizadas, sendo sua duração conforme a Figura (3.1).

[AT-01] Contato inicial da equipe de desenvolvimento com o cliente. Elicitação dos requisitos para o desenvolvimento de software através de entrevistas com o cliente.

[AT-02] Debate para escolha de uma metodologia de desenvolvimento. Elaboração dos diagramas de modelagem organizacional i*, NFR Framework, Casos de Uso e de classes.

[AT-03] Elaboração do documento de Especificação de Requisitos e Análise

[AT-04] Escolha de uma linguagem de programação baseada nos requisitos elicitados. Análise de tecnologias e processos para utilização no projeto.

[AT-05] Estudo e capacitação da equipe na linguagem de programação e tecnologias escolhidas para o desenvolvimento do sistema, incluindo banco de dados.

[AT-06] Implementação de um protótipo da interface do programa.

[AT-07] Visita, validação e entrega do protótipo ao cliente.

[AT-08] Implementação das classes que identificam os objetos principais do sistema, incluindo gerenciamento dos mesmos (Hóspede, Quarto, Empresa, Recepcionista, Gerente, Administrador, Usuário).

[AT-09] Implementação das classes de gerenciamento do sistema (Reserva, Diária).

[AT-10] Implementação das funcionalidades de Relatórios e Login no sistema.

[AT-11] Testes das implementações.

[AT-12] Implementação das modificações geradas pelas visitas ao cliente.

[AT-13] Elaboração da documentação do sistema e trabalho final.

[AT-14] Entrega e implantação do sistema final

Figura 3.1: Cronograma das Atividades.

Figura 3.1: Cronograma das Atividades.

Capítulo 4

Modelagem Organizacional e Modelagem de Requisitos Não Funcionais

Apresentaremos neste capítulo uma modelagem organizacional do hotel Real a partir da técnica i*, utilizando os modelos: SD (Modelo de Dependências Estratégicas) e SR (Modelo de Razões Estratégicas). E também demonstraremos a modelagem dos requisitos não-funcionais usando o NFR Framework.

4.1 Modelo de Dependências Estratégicas (SD)

A partir da Figura (4.1) podemos ter uma visão do modelo SD e assim conseguimos

observar que ele é composto por cinco atores, sendo que os atores que interagem realmente com o sistema são o gerente, o recepcionista e o administrador.

O ator cliente interage com o recepcionista, desejando do mesmo receber um bom

atendimento, podendo realizar reservas, fazer check-in e check-out, disponibilizando sempre que necessário os dados para o recepcionista.

O ator recepcionista interage com o sistema, sendo necessário que primeiramente ele

faça o login no sistema para ter acesso as seguintes operações disponíveis à ele:

gerenciamento de empresas, hóspedes, reservas e diárias. É necessário que as operações sejam

feitas de maneira transparente e fácil, pois o recepcionista requer usabilidade para com o sistema.

O gerente é um ator que tem a possibilidade de fazer todas as operações que um

recepcionista, por meio de um login e senha diferenciada. Ainda pode fazer o gerenciamento dos quartos e ter acesso aos relatórios gerados. Como o gerente está apto a fazer operações

especiais, ele espera do sistema que ele seja confiável e seguro.

O administrador é um ator especial no sistema, sendo necessário que ele possua um

login e senha para fazer sua autenticação no sistema. Sua única tarefa é fazer o gerenciamento de usuários, de tal forma que os usuários possam ser criados, alterados ou removidos, conforme a necessidade da organização do hotel. Na criação de um usuário o administrador sempre especifica o nível de privilégios que cada usuário terá.

Figura 4.1: Modelo de Dependências Estratégicas.

Figura 4.1: Modelo de Dependências Estratégicas.

4.2 Modelo de Razões Estratégicas (SR)

O modelo SR Figura (4.2) é um complemento do modelo SD, já que ele demonstra de forma mais detalhada as atividades que devem ser realizadas para que um objetivo seja alcançado.

Com a expansão do ator Sistema de Gerenciamento de Hotéis, podemos observar que os gerenciamentos, tanto de quarto, usuários, empresas e hóspedes possuem subdivisões em comum, como: incluir, desde que os dados sejam válidos; alterar, desde que os dados sejam válidos e a entidade esteja cadastrada; consultar os dados desde que a entidade esteja cadastrada e haja um identificador da entidade; remover, desde que uma entidade esteja cadastrada.

Da mesma forma que os outros gerenciamentos anteriormente explicados, as operações de gerenciamento de diárias e reservas também possuem subdivisões em comum, como: consultar os dados desde que a entidade esteja cadastrada e haja um identificador da entidade; incluir, desde que haja um quarto disponível e o hóspede esteja devidamente cadastrado no sistema; cancelar e alterar, desde que a entidade esteja cadastrada. O gerenciamento de diária ainda tem uma subdivisão finalizar, que requer que uma diária esteja ativa e ocorre com o pagamento da mesma.

Além disso, podemos observar que para ocorrer o login no sistema, são necessários dois recursos: o usuário e a senha do mesmo.

Figura 4.2: Modelo de Razões Estratégicas

Figura 4.2: Modelo de Razões Estratégicas

4.3 NFR Framework

O diagrama NFR Framework representado na Figura (4.3) nos permite ter uma visão melhor dos requisitos não funcionais e suas decomposições, operacionalizações (detalhadas na seção 5.2) e interdependências. Além disso, nos mostrar como as operacionalizações interferem uma nas outras, tanto positivamente como negativamente.

interferem uma nas outras, tanto positivamente como negativamente. Figura 4.3: Diagrama NFR Framework

Figura 4.3: Diagrama NFR Framework

Capítulo 5 Requisitos do Sistema

Para a classificação dos requisitos funcionais e não-funcionais quanto à sua prioridade, foi feita a divisão em três categorias: essenciais, importantes e desejáveis. Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente. Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim. Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.

5.1 Requisitos Funcionais

Os requisitos funcionais de um sistema são as capacidades que ele irá fornecer aos usuários. A seguir são apresentados os requisitos funcionais do sistema, assim como uma breve descrição dos mesmos. [RF-01] Incluir Hóspede. Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir incluir um novo hóspede, a partir dos seguintes dados: nome, nacionalidade, CPF, estado civil, sexo, profissão, data de nascimento, data do cadastro, procedência, destino, número do RG, telefone, placa do carro e observações. [RF-02] Alterar Hóspede Prioridade: Importante Solicitante: Recepcionista Descrição: O sistema deve permitir alterar os dados cadastrais de um hóspede, através de uma consulta por nome ou CPF. [RF-03] Consultar Hóspede Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir fazer a consulta de um hóspede através do nome ou CPF do mesmo. Sendo que o resultado da consulta será exibido em tela. [RF-04] Excluir Hóspede Prioridade: Importante

Solicitante: Recepcionista Descrição: O sistema deve permitir excluir um hóspede a partir de uma consulta por nome ou CPF. [RF-05] Incluir Empresa Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir incluir uma nova empresa, a partir dos seguintes dados: nome/razão social, endereço, CNPJ, telefones, falar com (responsável), o cargo do mesmo (responsável), inscrição estadual, e-mail, site, e observações. [RF-06] Alterar Empresa Prioridade: Importante Solicitante: Recepcionista Descrição: O sistema deve permitir alterar os dados cadastrais de uma empresa, através de uma consulta por nome ou CNPJ. [RF-07] Consultar Empresa Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir fazer consulta de uma empresa através de nome ou CNPJ. Sendo que o resultado da consulta será exibido em tela. [RF-08] Excluir Empresa Prioridade: Importante Solicitante: Recepcionista Descrição: O sistema deve permitir excluir uma empresa a partir de uma consulta por nome ou CNPJ. [RF-09] Incluir Quarto Prioridade: Essencial Solicitante: Gerente Descrição: O sistema deve permitir incluir um novo quarto, a partir dos seguintes dados: número/identificador, tipo do quarto, número de camas e observações. [RF-10] Alterar Quarto Prioridade: Importante Solicitante: Gerente Descrição: O sistema deve permitir alterar os dados cadastrais de um quarto, através de uma consulta por número/identificador. [RF-11] Consultar Quarto Prioridade: Essencial Solicitante: Gerente Descrição: O sistema deve permitir fazer consulta de um quarto através do numero/identificador. Sendo que o resultado da consulta será exibido em tela. [RF-12] Excluir Quarto Prioridade: Importante Solicitante: Gerente Descrição: O sistema deve permitir excluir um quarto a partir de uma consulta por número/identificador. [RF-13] Incluir Reserva Prioridade: Desejável Solicitante: Recepcionista

Descrição: O sistema deve permitir incluir uma nova reserva, a partir dos seguintes dados: nome, empresa, data prevista para chegada, telefone, hora prevista para chegada, número de pessoas e observações. [RF-14] Alterar Reserva Prioridade: Desejável Solicitante: Recepcionista Descrição: O sistema deve permitir alterar os dados de uma reserva, através de uma consulta por nome ou data prevista para chegada. [RF-15] Consultar Reserva Prioridade: Desejável Solicitante: Recepcionista Descrição: O sistema deve permitir fazer consulta de uma reserva através do nome ou data prevista para chegada. Sendo que o resultado da consulta será exibido em tela. [RF-16] Cancelar Reserva Prioridade: Desejável Solicitante: Recepcionista Descrição: O sistema deve permitir cancelar uma reserva a partir de uma consulta por nome ou data prevista para chegada. [RF-17] Incluir Diária Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir incluir uma nova diária a partir dos seguintes dados: identificador de uma pessoa já cadastrada, data de entrada, data prevista de saída, valor da diária e observações. [RF-18] Alterar Diária Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir alterar os dados de uma diária. [RF-19] Consultar Diária Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir fazer consulta de uma diária através da data da mesma. Sendo que o resultado da consulta será exibido em tela. [RF-20] Cancelar Diária Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir cancelar uma diária. [RF-21] Finalizar Diária Prioridade: Essencial Solicitante: Recepcionista Descrição: O sistema deve permitir a finalização de uma diária, sendo esta, total dos gastos do hóspede, tanto a soma dos valores das diárias em que ele permaneceu no hotel, como os gastos extras na lanchonete. [RF-22] Incluir Usuário Prioridade: Essencial Solicitante: Administrador Descrição: O sistema deve permitir incluir um novo usuário, a partir dos seguintes dados: nome, login/nome, senha e a prioridade.

[RF-23] Alterar Usuário Prioridade: Importante Solicitante: Administrador Descrição: O sistema deve permitir alterar os dados cadastrais de um usuário, através de uma consulta por nome. [RF-24] Consultar Usuário Prioridade: Importante Solicitante: Administrador Descrição: O sistema deve permitir fazer consulta de um usuário através do nome do usuário. Sendo que o resultado da consulta será exibido em tela. [RF-25] Excluir Usuário Prioridade: Importante Solicitante: Administrador Descrição: O sistema deve permitir excluir um usuário a partir de uma consulta por nome do usuário. [RF-26] Logar no Sistema Prioridade: Essencial Solicitante: Usuário Descrição: O sistema deve permitir que o usuário faça login no mesmo, através de um login e uma senha, sendo que as funcionalidades do sistema serão acessíveis aos usuários de acordo com o seu nível de privilégios. [RF-27] Gerar Relatório Prioridade: Desejável Solicitante: Gerente Descrição: O sistema deve permitir gerar relatórios específicos, como de novos cadastros de hóspedes realizados em um determinado período, relatórios de gastos de uma empresa já cadastrada em um determinado período, entre outros.

5.2 Requisitos Não-Funcionais

Requisitos não funcionais, ao contrário dos funcionais, não expressam nenhuma

função (transformação) a ser implementada em um sistema, eles expressam condições de comportamento e restrições nos serviços do sistema, tais como restrições de tempo, restrições no processo de desenvolvimento, padrões, etc, que devem prevalecer. Segue abaixo os requisitos não funcionais do sistema e uma breve descrição dos mesmos. Quanto a Segurança:

[RNF-01] Confidencialidade dos dados Prioridade: Essencial Solicitante: Gerente Descrição: O sistema deve garantir a confidencialidade dos dados. Operacionalização: A confidencialidade dos dados será implementada através de uma

política de login e senha,

privilégio. [RNF-02] Integridade dos dados Prioridade: Essencial Solicitante: Gerente Descrição: O sistema deve garantir a integridade dos dados.

em que cada usuário poderá acessar dados conforme seu nível de

Operacionalização: A integridade dos dados será mantida através de uma política de armazenamento de dados removidos, que consistirá em ao invés de apagar os dados, apenas desativá-los, marcando-os como inativos. [RNF-03] Disponibilidade dos dados Prioridade: Desejável Solicitante: Gerente Descrição: O sistema deve garantir a disponibilidade dos dados. Operacionalização: A disponibilidade dos dados será realizada através de backups feitos em tempos programados, além da política de armazenamento de dados removidos. Quanto a Usabilidade:

[RNF-01] Deve ser fácil de utilizar Prioridade: Importante Solicitante: Recepcionista Descrição: O sistema deve ser fácil de ser usado e de localizar as operações desejadas. Operacionalização: Para ter agilidade ao acessar as funcionalidades mais utilizadas, haverá teclas de atalho, que também facilitarão o alcance dos menus e funções do sistema ao usuário. Bem como, as interfaces terão o padrão ATA, como esta descrito no apêndice D, com o objetivo de uma melhor visualização e entendimento do software. E também terá um manual de ajuda, descrevendo as funcionalidades do sistema. Quanto a Confiabilidade:

[RNF-01] Confiabilidade dos dados Prioridade: Importante Solicitante: Recepcionista Descrição: O sistema deve garantir a confiabilidade dos dados. Operacionalização: O sistema emitirá mensagens de confirmação da operação realizada, e também fará de tempos em tempos o backup dos dados. Quanto ao Custo:

[RNF-01] Deve ter um custo baixo Prioridade: Desejável Solicitante: Gerente Descrição: O sistema deve ter um custo baixo de desenvolvimento. Operacionalização: Para o custo de desenvolvimento ser baixo, o sistema irá utilizar apenas ferramentas gratuitas. Quanto a Performance:

[RNF-01] Configuração do Computador Prioridade: Importante Solicitante: Gerente Descrição: O sistema deve funcionar em uma configuração especifica de máquina. Operacionalização: Para ter uma boa performance o sistema deverá rodar em uma máquina com configuração A, a mesma esta detalhada no apêndice D. Quanto a Evolução:

[RNF-01] Fácil de Atualizar Prioridade: Essencial Solicitante: Gerente Descrição: O sistema deve garantir que futuramente possam ser atualizado. Operacionalização: O sistema irá utilizar o padrão de desenvolvimento MVC (Modelo, Visão e Controle), para obter uma maior modularidade do software, garantindo que alterações

e evoluções no sistema sejam possíveis com uma maior facilidade. E também, utiliza-rá Orientação a Objetos para uma melhor organização e entendimento do código fonte.

Capítulo 6 Caso de Uso do Sistema

O diagrama de caso de uso Figura (6.1) mostra a interação entre o sistema e os atores envolvidos. Serve para facilitar o entendimento mostrando sua visão externa, mostrando as funcionalidades que o sistema provê para cada ator, sendo uma das maneiras mais tradicionais de se documentar os requisitos. Este diagrama ajuda a formalizar as funções que o sistema precisa fazer.

Este diagrama ajuda a formalizar as funções que o sistema precisa fazer. Figura 6.1: Diagrama de

Figura 6.1: Diagrama de Caso de Uso.

6.1 Descrições Textuais dos Casos de Uso

Nesta sessão descreveremos os Casos de Uso do Sistema através de descrições textuais detalhadas:

Caso de uso 1: GERENCIAR HÓSPEDE Objetivo: Realizar o gerenciamento de um hóspede. Nível de Usuário Pré-condições: Recepcionista logado no sistema. Pós-condições: Hóspede devidamente gerenciado. Ator: Recepcionista Cenário Principal Passo 1: O recepcionista obtém os dados necessários do hóspede para o gerenciamento. Passo 2: O recepcionista escolhe a operação incluir um novo hóspede. Passo 3: O recepcionista obtém os dados do hóspede. Passo 4: O recepcionista insere os dados do hóspede no sistema. Passo 5: O sistema armazena as informações do hóspede. Passo 6: O sistema emite mensagem de operação efetuada. Cenário Secundário (Extensões) Passo 2.1: Recepcionista escolhe operação remover: caso de uso Remover. Passo 2.2: Recepcionista escolhe operação alterar: caso de uso Alterar. Passo 2.3: Recepcionista escolhe operação consultar: caso de uso Consultar. Passo 4.1: Dados do hóspede inválidos: o sistema notifica o erro ao recepcionista. Passo 5.1: Hóspede já cadastrado: o sistema cancela o cadastro e notifica o erro ao recepcionista.

Caso de uso 2: GERENCIAR EMPRESA Objetivo: Realizar o gerenciamento de uma empresa. Nível de Usuário Pré-condições: Recepcionista logado no sistema. Pós-condições: Empresa devidamente gerenciada. Ator: Recepcionista Cenário Principal Passo 1: O recepcionista obtém os dados necessários da empresa para o gerenciamento. Passo 2: O recepcionista escolhe a operação incluir uma nova empresa. Passo 3: O recepcionista obtém os dados da empresa. Passo 4: O recepcionista insere os dados da empresa no sistema. Passo 5: O sistema armazena as informações da empresa. Passo 6: O sistema emite mensagem de operação efetuada. Cenário Secundário (Extensões) Passo 2.1: Recepcionista escolhe operação remover: caso de uso Remover. Passo 2.2: Recepcionista escolhe operação alterar: caso de uso Alterar. Passo 2.3: Recepcionista escolhe operação consultar: caso de uso Consultar. Passo 4.1: Dados da empresa inválidos: o sistema notifica o erro ao recepcionista. Passo 5.1: Empresa já cadastrada: o sistema cancela o cadastro e notifica o erro ao recepcionista.

Nível de Usuário Pré-condições: Gerente logado no sistema. Pós-condições: Quarto devidamente gerenciado. Ator: Gerente Cenário Principal Passo 1: O gerente obtém os dados necessários do quarto para o gerenciamento. Passo 2: O gerente escolhe a operação incluir um novo quarto. Passo 3: O gerente obtém os dados do quarto. Passo 4: O gerente insere os dados do quarto no sistema. Passo 5: O sistema armazena as informações do quarto. Passo 6: O sistema emite mensagem de operação efetuada. Cenário Secundário (Extensões) Passo 2.1: Gerente escolhe operação remover: caso de uso Remover. Passo 2.2: Gerente escolhe operação alterar: caso de uso Alterar. Passo 2.3: Gerente escolhe operação consultar: caso de uso Consultar. Passo 4.1: Dados do quarto inválidos: o sistema notifica o erro ao gerente. Passo 5.1: Quarto já cadastrado: o sistema cancela o cadastro e notifica o erro ao gerente.

Caso de uso 4: GERENCIAR USUÁRIO Objetivo: Realizar o gerenciamento de um usuário. Nível de Usuário Pré-condições: Administrador logado no sistema. Pós-condições: Usuário devidamente gerenciado. Ator: Administrador Cenário Principal Passo 1: O administrador obtém os dados necessários do usuário para o gerenciamento. Passo 2: O administrador escolhe a operação incluir um novo usuário. Passo 3: O administrador obtém os dados do usuário. Passo 4: O administrador insere os dados do usuário no sistema. Passo 5: O sistema armazena as informações do usuário. Passo 6: O sistema emite mensagem de operação efetuada. Cenário Secundário (Extensões) Passo 2.1: Administrador escolhe operação remover: caso de uso Remover. Passo 2.2: Administrador escolhe operação alterar: caso de uso Alterar. Passo 2.3: Administrador escolhe operação consultar: caso de uso Consultar. Passo 4.1: Dados do usuário inválidos: o sistema notifica o erro ao administrador. Passo 5.1: Usuário já cadastrado: o sistema cancela o cadastro e notifica o erro ao administrador.

Caso de uso 5: GERENCIAR DIÁRIA Objetivo: Realizar o gerenciamento de uma diária. Nível de Usuário Pré-condições: Recepcionista logado no sistema, quarto disponível e hóspede cadastrado. Pós-condições: Diária devidamente gerenciada. Ator: Recepcionista Cenário Principal Passo 1: O recepcionista obtém os dados necessários da diária para o gerenciamento. Passo 2: O recepcionista escolhe a operação incluir uma nova diária.

Passo 3: O recepcionista obtém os dados da diária. Passo 4: O recepcionista insere os dados da diária no sistema. Passo 5: O sistema armazena as informações da diária. Passo 6: O sistema emite mensagem de operação efetuada. Cenário Secundário (Extensões) Passo 2.1: Recepcionista escolhe operação remover: caso de uso Remover. Passo 2.2: Recepcionista escolhe operação alterar: caso de uso Alterar. Passo 2.3: Recepcionista escolhe operação consultar: caso de uso Consultar. Passo 4.1: Dados da diária inválidos: o sistema notifica o erro ao recepcionista. Passo 5.1: Diária já cadastrada: o sistema cancela o cadastro e notifica o erro ao recepcionista.

Caso de uso 6: GERENCIAR RESERVA Objetivo: Realizar o gerenciamento de uma reserva. Nível de Usuário Pré-condições: Recepcionista logado no sistema, quarto disponível e hóspede cadastrado. Pós-condições: Reserva devidamente gerenciada. Ator: Recepcionista Cenário Principal Passo 1: O recepcionista obtém os dados necessários da reserva para o gerenciamento. Passo 2: O recepcionista escolhe a operação incluir uma nova reserva. Passo 3: O recepcionista obtém os dados da reserva. Passo 4: O recepcionista insere os dados da reserva no sistema. Passo 5: O sistema armazena as informações da reserva. Passo 6: O sistema emite mensagem de operação efetuada. Cenário Secundário (Extensões) Passo 2.1: Recepcionista escolhe operação remover: caso de uso Remover. Passo 2.2: Recepcionista escolhe operação alterar: caso de uso Alterar. Passo 2.3: Recepcionista escolhe operação consultar: caso de uso Consultar. Passo 4.1: Dados da reserva inválidos: o sistema notifica o erro ao recepcionista. Passo 5.1: Reserva já cadastrada: o sistema cancela o cadastro e notifica o erro ao recepcionista.

Caso de uso 7: RELATÓRIO Objetivo: Realizar a impressão ou exibição de relatórios, sendo estes disponíveis somente ao gerente. Nível de Usuário Pré-condições: Gerente logado no sistema. Pós-condições: Relatório impresso ou exibido com sucesso. Ator: Gerente. Cenário Principal Passo 1: O gerente seleciona o relatório desejado. Passo 2: O sistema recebe esta escolha do gerente e acessa o Banco de Dados. Passo 3: O gerente escolhe o modo de exibição, se vai ser em tela (exibido) ou impresso. Passo 4: Conforme a escolha do gerente o sistema exibe ou imprime o relatório. Cenário Secundário (Extensões) Passo 2.1: Falha no acesso ao banco de dados: o sistema cancela exibição e notifica o erro ao gerente.

Passo 4.1: Falha de hardware de impressão: o sistema cancela exibição do relatório e uma mensagem de erro é enviada ao gerente.

Caso de uso 8: FINALIZAR Objetivo: Realizar a finalização de uma diária. Nível de Usuário Pré-condições: Recepcionista logado no sistema. Pós-condições: A finalização da diária realizada com sucesso. Ator: Recepcionista. Cenário Principal Passo 1: O recepcionista visualiza no sistema a janela de diárias . Passo 2: O recepcionista seleciona o número do quarto, cuja diária será finalizar. Passo 3: O recepcionista finaliza a diária. Passo 4: O sistema captura os dados da diária que o recepcionista deseja finalizar no Banco de Dados. Passo 5: O sistema mostra em tela os dados da(s) diária(s) do hóspede naquele quarto, seus gastos extras e o total da(s) diária(s). Passo 6: Hóspede realiza o pagamento e o recepcionista confirma a finalização. Passo 7: O sistema armazena o valor recebido no Banco de Dados de acordo com quem está logado no sistema, e se o hospede é de alguma empresa. Passo 8: O sistema emite mensagem de diária finalizada. Cenário Secundário (Extensões) Passo 4.1: Falha no acesso ao banco de dados: o sistema cancela a operação e notifica o erro ao recepcionista. Passo 6.1: Hóspede não realiza o pagamento: o sistema cancela a operação. Passo 7.1: Falha no acesso ao banco de dados: o sistema cancela a operação e notifica o erro ao recepcionista.

Caso de uso 9: LOGIN Objetivo: Realizar o login no sistema disponibilizando acesso adequado as funcionalidades de acordo com o nível de privilégios. Nível de Usuário Pré-condições: Usuário cadastrado no sistema com um login e uma senha. Pós-condições: Usuário ligado com sucesso e com seu devido acesso autorizado. Ator: Usuário. Cenário Principal Passo 1: O usuário ingressa o login e a senha no sistema. Passo 2: O sistema recebe estes dados de login e acessa o Banco de Dados. Passo 3: O sistema permite ao usuário usar as funcionalidades de acordo com o seu nível de privilégio. Cenário Secundário (Extensões) Passo 2.1: Senha ou login incorretos: o sistema cancela o login e notifica o erro ao usuário. Passo 2.2: Falha no acesso ao banco de dados: o sistema cancela o login e notifica o erro ao usuário.

Pré-condições: Recepcionista logado no sistema. Pós-condições: Dados da entidade alterados com sucesso. Ator: Recepcionista. Cenário Principal Passo 1: Recepcionista obtém os novos dados da entidade a ser alterada. Passo 2: O sistema busca a entidade a ser alterada no Banco de Dados. Passo 3: O sistema exibe os dados cadastrais da entidade. Passo 4: O recepcionista altera os dados da entidade. Passo 5: O sistema captura os novos dados e atualiza estas informações. Passo 6: O sistema emite mensagem de dados atualizados. Cenário Secundário (Extensões) Passo 2.1: Empresa não localizada: o sistema cancela a operação e notifica ao recepcionista que a empresa não está cadastrada. Passo 2.2: Falha no acesso ao banco de dados: o sistema cancela a exibição do cadastro da empresa e notifica o erro ao recepcionista. Passo 5.1: Falha no acesso ao banco de dados: o sistema cancela a atualização e notifica o erro ao recepcionista.

Caso de uso 11: REMOVER Objetivo: Remove os dados de uma entidade. Nível de Usuário Pré-condições: Recepcionista logado no sistema. Pós-condições: Dados da entidade removidos com sucesso. Ator: Recepcionista Cenário Principal Passo 1: O recepcionista entra com os dados necessários para remoção. Passo 2: O sistema busca a entidade a ser excluída no Banco de Dados e o mostra em tela. Passo 3: O recepcionista confirma a exclusão. Passo 4: O sistema remove o cadastro da entidade (marcando como inativa). Passo 5: O sistema emite mensagem de sucesso. Cenário Secundário (Extensões) Passo 2.1: Entidade não localizada: o sistema cancela a operação e notifica a inexistência da entidade ao recepcionista. Passo 2.2: Falha no acesso ao banco de dados: o sistema cancela a remoção e notifica o erro ao recepcionista. Passo 3.1: Não confirmação de remoção: o sistema cancela a remoção.

Caso de uso 12: CONSULTAR Objetivo: Consultar os dados cadastrais de uma entidade. Nível de Usuário Pré-condições: Recepcionista logado no sistema. Pós-condições: Consulta realizada com sucesso com sucesso. Ator: Recepcionista. Cenário Principal Passo 1: O recepcionista entra com os dados da entidade para uma consulta no sistema. Passo 2: O sistema busca as informações da entidade. Passo 3: O sistema exibe os dados da entidade em tela. Cenário Secundário (Extensões)

Passo 2.1: Entidade não localizada: o sistema cancela a operação e notifica a inexistência da Entidade ao recepcionista.

Caso de uso 13: CANCELAR Objetivo: Realizar o cancelamento de uma diária ou reserva. Nível de Usuário Pré-condições: Recepcionista logado no sistema. Pós-condições: O cancelamento realizado com sucesso. Ator: Recepcionista. Cenário Principal Passo 1: O recepcionista visualiza no sistema as diárias ou as reservas. Passo 2: O recepcionista seleciona a reserva ou diária que deseja cancelar. Passo 3: O recepcionista cancela a diária ou a reserva. Passo 4: O sistema captura os dados da diária ou reserva que o recepcionista deseja cancelar. Passo 5: O sistema remove as informações. Passo 6: O sistema emite mensagem de sucesso. Cenário Secundário (Extensões) Passo 4.1: Diária ou reserva não localizada: o sistema cancela a operação e notifica a inexistência ao recepcionista.

Caso de uso 14: INCLUIR Objetivo: Realizar a inserção de uma entidade (hóspede, empresa, diária, reserva, quarto ou usuário). Nível de Usuário Pré-condições: Recepcionista logado no sistema. Pós-condições: Entidade inserida com sucesso. Ator: Recepcionista Cenário Principal Passo 1: O recepcionista obtém os dados cadastrais da entidade. Passo 2: O recepcionista insere os dados da entidade no sistema. Passo 3: O sistema insere os dados no Banco de Dados. Passo 4: O sistema emite mensagem de inserção efetuada. Cenário Secundário (Extensões) Passo 2.1: Dados da entidade inválidos: o sistema notifica o erro ao recepcionista. Passo 3.1: Falha no acesso ao banco de dados: o sistema cancela o cadastro e notifica o erro ao recepcionista. Passo 3.2: Entidade já cadastrada: o sistema cancela o cadastro e notifica o erro ao recepcionista.

Capítulo 7 Diagrama de Classe do Sistema

O diagrama de classes Figura (7.1) demonstra como será a representação e as relações entre as classes do sistema. Mostrando os métodos e atributos de cada classe, bem como os relacionamentos que ela possui.

7.1 Descrições Textuais das Classes do Sistema

Está sessão demonstra uma breve descrição textual das classes apresentadas no diagrama.

Hóspede

A classe hóspede talvez seja a mais importante do sistema, devido ao fato de que tudo

está relacionado direta ou indiretamente com ela, sendo o hóspede é o mais interessado no funcionamento do sistema. Ela tem uma agregação com a classe empresa, na qual um hóspede está relacionado somente com uma empresa, uma associação simples com a classe recepcionista que é quem gerencia a classe, e composições com as classes diária e reserva, nas quais podem haver zero ou mais diárias ou reservas.

Empresa Esta classe armazena e oferece informações sobre a empresa que um hóspede pertence. Ela tem uma agregação com a classe hóspede, na qual uma empresa está relacionada com vários hóspedes, e uma associação simples com a classe recepcionista que é quem gerencia a classe.

Usuário

É uma classe genérica, que tem atributos para a autenticação de um usuário, sendo a

classe da qual a classe administrador e recepcionista derivam. Tem uma associação simples com a classe administrador, que é quem a gerencia.

Administrador

É a classe que gerencia os usuários do sistema, tendo uma associação simples com a

classe usuário, da qual também é derivada.

Recepcionista

É a classe que gerencia todas as funções para o funcionamento básico do sistema,

sendo derivada da classe usuário. Tem associações simples com as classes: hóspede, empresa, reserva e diária, as quais gerencia.

Gerente Esta classe herda todas as funções e métodos da classe recepcionista. Além das funcionalidades herdadas, ela ainda tem uma associação simples com a classe quarto, a qual gerencia. Esta classe também gera os relatórios de empresa, hóspede e diárias.

Quarto É a classe que armazena e oferece informações a respeito de um quarto. Ela tem uma associação simples com a classe gerente, a qual a gerencia. Alem disso, ela tem composições com a classe reserva, sendo que um quarto está relacionado com zero ou mais reservas, e com a classe diária, sendo que também um quarto está relacionado com zero ou mais diárias.

Reserva Esta classe tem informações sobre a reserva de um quarto. Tem uma associação simples com a classe recepcionista, a qual a gerencia, e uma composição com a classe quarto, pois para cada quarto pode haver várias reservas, e para existir uma reserva é necessário um quarto disponível. Também tem uma composição com a classe hóspede, pois para reserva é necessário um hóspede.

Diária A classe diária, assim como a classe hóspede, também é uma das mais importantes para o funcionamento do sistema, pois é o objetivo principal do hóspede. Tem uma associação simples com a classe recepcionista, a qual a gerencia, e uma composição com a classe quarto, pois para cada quarto pode haver várias diárias, e para existir uma diária é necessário um quarto disponível. Também tem uma composição com a classe hóspede, pois para a diária é necessário um hóspede.

Figura 7.1: Diagrama de Classe.

Figura 7.1: Diagrama de Classe.

Capítulo 8 Conclusão

Este estudo e análise da engenharia de requisitos foi feito tomando como base que a alternativa escolhida para o desenvolvimento é a mais viável. Para ter uma visão geral da organização e um melhor entendimento de como é o funcionamento da empresa, foram feitos os diagramas de modelagem organizacional i*, incluindo os modelos de dependências e razões estratégicas. Os requisitos, tanto funcionais quanto não-funcionais foram elicitados a partir da entrevista realizada com o cliente, sendo que para os requisitos não-funcionais foi feito o uso do diagrama NFR Framework para uma melhor compreensão de como satisfazê-los. Para melhor entender como o usuário irá interagir com o sistema, foi feita a construção do diagrama de caso de uso, dando uma visão mais geral das necessidades que o usuário possui. Foi feita uma descrição para cada caso de uso, o que ajudou a compreender melhor todos os passos e a execução de cada funcionalidade/tarefa. Ainda foi utilizado um diagrama de classes para identificar as principais classes que o sistema deverá implementar, e como essas classes relacionam-se umas com as outras, bem como os atributos e operações que são relevantes a cada uma delas. Como este trabalho é a primeira parte de um todo, foi feito um cronograma de atividades baseado na metodologia em espiral, escolhida para o desenvolvimento do sistema, que ajudará no processo de desenvolvimento do sistema, durante as várias etapas, até que seja desenvolvido e entregue um protótipo final. Esta documentação servirá de apoio e base de referência para as próximas fases do desenvolvimento do sistema, desde o projeto, implementação e testes do mesmo.

Apêndice A Sobre o Hotel Real

O Hotel Real atualmente é dirigido pelas famílias Girardello e Vacari, tornando o hotel um ambiente familiar. Por se tratar de duas famílias, a divisão de serviços é feita da seguinte forma: em um determinado dia uma família cuida do hotel, e no outro dia é a outra família que deve cuidar, e assim sucessivamente. Os cômodos se dividem em quartos e apartamentos, destes, 24 são quartos e 11 são apartamentos. Os quartos se caracterizam pela ausência de banheiro, os banheiros são coletivos nos corredores e os apartamentos possuem banheiro no interior do ambiente. Ambos possuem televisão, ventilador, guarda roupa e o número de camas variam de 1 a 4, algumas de casal, outras de solteiro. Possui estacionamento fechado com vaga para aproximadamente 15 veículos. Conta também com serviço de reservas que podem ser efetuadas via telefone ou pessoalmente, deixando alguns dados, e no caso de eventos ou quando o hotel está lotado é necessário depositar uma porcentagem do valor total. Para ser efetuada a entrada no hotel é realizado um cadastro, caso o hóspede já esteja cadastrado é realizado apenas o registo no livro de diárias. Caso o hóspede não tenha bagagens o pagamento deve ser feito adiantado. O café da manhã é uma cortesia do hotel. Também nas dependências do hotel possui um bar, onde os produtos consumidos podem ser adicionados ao valor da diária. Por fim, as formas de pagamento podem ser feitas em dinheiro, cartão de crédito master card e em alguns casos sendo aceito cheques também. Atualmente todos os dados e serviços são controlados manualmente em livros de registros e cadernos de anotações, como: livro de cadastros, livro de diárias, caderno de reservas e caderno de gastos das empresas. Isso acaba tornando o sistema muito lento e impreciso, conforme é descrito no Apêndice C.

Apêndice B Entrevista

Após a definição da empresa, foi dado início ao processo de coleta de dados, sendo realizada uma entrevista. A entrevista foi realizada dia 18 de março de 2009 (Quarta-Feira) das 9:00 às 11:00 horas nas dependências do Hotel Real. A entrevista foi realizada com a sócia/gerente do hotel Clementina Aparecida Copini Girardello, portadora do CPF 762.282.829-72 e RG 7.067.283- 9. Por se tratar de uma sociedade familiar, todos os sócios desenvolvem diversas atividades dentro do hotel, desde zeladores até divisão de lucros, sendo assim, a entrevistada em questão tem conhecimento de todas atividades que ocorrem no hotel. As informações colhidas foram fundamentais para entender como funciona o hotel, seus principais problemas e como um software gerenciador hoteleiro poderia ajudar na solução dos mesmos. Abaixo relacionamos as questões levantadas e as respectivas respostas obtidas da entrevistada.

1. Como é feita a locação dos quartos do hotel?

R: Primeiro mostramos o quarto para a pessoa, se ela quiser ficar e é a primeira vez que vem

ao hotel ou seja, não tem cadastro ainda, então é feito um cadastro, e é marcado no livro de diárias a entrada da pessoa.

2. Onde é feito o cadastro do Hóspede?

R: O cadastro é feito em um livro que chamamos de livro de cadastros de Hóspedes.

3. Quais os dados necessários do Hóspede para o cadastro?

R: Nome, nacionalidade, estado civil, profissão, idade, data entrada, número do comodo(quarto), procedência, data de saída, destino, número do RG, e no campo observações é marcado o telefone da pessoa já que este campo não tem no livro,mas as vezes precisamos também marcar observações, e uma coisa que também não tem é o número da placa do carro, que deveria ter pois se a polícia precisa encontra-lo fica mais fácil de localiza-lo.

4. Como é feito o controle das diárias?

R: Temos um livro onde marcamos as diárias, cada folha é um dia onde tem os números de todos os quartos e mostra naqueles que estão ocupados: o nome da pessoa; o número de camas, se for mensalista(pessoa que aluga o quarto para o mês todo) no lugar é colocado um F para indicar que é fixo; temos a data da entrada da pessoa no hotel, se for mensalista no lugar colocamos a data que vence o mês. Ao lado do nome se a pessoa for de uma empresa colocamos o nome da empresa, se emprestarmos toalhas colocamos uns X's correspondentes ao número de toalhas, tem também marcado o consumo que ele teve na lanchonete acrescentados com +. É marcado também o valor da diária conforme o quarto escolhido e se

já esta pago ou não. Num cantinho bem em cima tem o número de pães e cucas que são

comprados para o café da manhã.

5. Como é realizado o pagamento?

R: Na hora de pagar temos que folhar o livro para ver quantas diárias a pessoa tem e vamos somando, e também somamos o consumo na lanchonete, se teve.

6.

Quais as formas de pagamento?

R:

Dinheiro, cartão Master e as vezes aceitamos cheque também.

7.

A pessoa pode pagar adiantado?

R: Sim, até se a pessoa não tem bagagem ou é má encarada nós cobramos antes o valor da diária como uma garantia, senão a pessoa que escolhe o horário de pagamento.

8. Como é feita a reserva adiantada dos quartos?

R: A pessoa liga e então é marcado em um outro livro o nome da pessoa, se é de alguma empresa é marcado também o nome da empresa, a data da prevista entrada, o telefone, o número de pessoas, observações, e principalmente a hora de prevista chegada pois se a pessoa não chegar até a hora marcada o quarto é liberado.

9. A pessoa tem que pagar adiantado para conseguir a reserva?

R: As vezes sim, depende do movimento no hotel, mas é cobrado um adiantamento, uma porcentagem que deve ser depositada na conta do hotel, como uma garantia de que a pessoa vai mesmo se hospedar, isso acontece em eventos, por exemplo na semana do Show Rural, que é quando o hotel fica cheio.

10. Quantos quartos o hotel tem? Se tem uma espectativa de aumentar o número de

quartos? R: Temos 24 quartos, que são quartos mais simples onde o banheiro é coletivo, e também temos 11 apartamentos que são quartos com banheiro, mais ajeitados e com internet. E tem sim a possibilidade de aumentar o número de quartos futuramente.

11. Os quartos tem valores diferentes?

R: Sim, os quartos tem diária de R$28,00 reais, e os apartamentos são R$40,00 reais, mas

conforme o número de pessoas por quarto, fazemos descontos.

12. Como é a hierarquia dentro da empresa?

R: Temos as zeladoras que cuidam da limpeza dos quartos. Mas no demais não se tem uma hierarquia, todo mundo faz tudo, mas possivelmente mais tarde pode haver uma recepcionista.

O que se tem é uma sociedade, onde um dia uma família cuida do hotel e no outro é a outra

família que cuida, e nos finais de semana de sexta, sábado e domingo é a mesma família que cuida sempre intercalando.

13. Como é feito o acerto entre os sócios? Os lucros são divididos entre as partes?

R: Não, cada sócio ganha o lucro pelos dias que cuidou, e essa distinção de quem cuidou do hotel é feita pela letra da pessoa que marcou as diárias no caderno de diárias. E esse acerto é semanal.

14.

É feito algum tipo de relatório, controle do hotel?

R: Temos um caderno para controle nosso de quanto uma empresa gastou no mês no hotel, marcamos neste caderno o nome da empresa no início da folha e depois o nome das pessoas(funcionários) com os dias(datas) que esse funcionário ficou no hotel e o valor gasto, e também se está pago ou não. E bem no final do caderno a soma total dos gastos de todos as diárias da empresa.

15. Vocês tem algum cadastro dessas empresas?

R: Sim, são as fichinhas verdes que ficam guardadas em uma pasta separadas por ordem alfabética.

16. Quais são os dados requisitados para o cadastro das empresas?

R: A razão social, o endereço da empresa, os telefones da empresa, o CNPJ da empresa, a inscrição estadual, o e-mail,site da empresa, com quem devemos falar quando ligarmos para a empresa o cargo desta empresa e também as vezes marcamos algumas observações sobre a empresa.

17. O que é este carimbo no livro de Cadastros dos Hóspedes?

R: É o carimbo da polícia, pois todo mês é levado este livro para a polícia, para eles verificarem as pessoas que passaram no hotel no mês, e é pago uma taxa por pessoa que é verificada. A gerente entrevistada pode ser contactada pelo telefone (45) 3223-0376 ou ainda no endereço do hotel: Av. Brasil, 4506, Centro de Cascavel-PR. A Figura (B.1) é um registro fotográfico da reunião que gerou a entrevista.

A Figura (B.1) é um registro fotográfico da reunião que gerou a entrevista. Figura B.1: Foto

Figura B.1: Foto da Entrevista.

Apêndice C Deficiências dos Livros de Registros

Durante a visita ao hotel foram observados vários problemas no sistema atual, que conta com um livro de registros, um livro de diárias e um caderno de reservas. Um dos problemas é quanto a consulta de hóspedes e empresas cadastradas. Atualmente os dados referentes aos hóspedes são armazenados em um livro de registros (Figura (C.1)) e os dados das empresas são armazenados em um arquivo de fichas (Figura (C.2)), o que torna inviável pesquisar informações sobre um determinado hóspede ou empresa. O controle de diárias (Figura (C.3)) é feito em um outro livro, onde todas as informações quanto a estadia do hóspede é colocada em uma única linha, o que se torna muitas vezes ilegível. O controle financeiro também é feito manualmente, somando os valores do livro de diárias com calculadora, o que torna o sistema suscetível a erros. O controle de reservas (Figura (C.4)) é feito em um caderno de anotações, o que torna a pesquisa demorada e imprecisa.

)) é feito em um caderno de anotações, o que torna a pesquisa demorada e imprecisa.

Figura C.1: Livro de registros.

Figura C.2: Ficha de cadastro de empresas. Figura C.3: Controle de diárias.

Figura C.2: Ficha de cadastro de empresas.

Figura C.2: Ficha de cadastro de empresas. Figura C.3: Controle de diárias.

Figura C.3: Controle de diárias.

Figura C.4: Controle de reservas.

Figura C.4: Controle de reservas.

Apêndice D Glossário

Computador com configuração A: CPU Intel 2,0GHz, 1GB de memória RAM, 40GB de HD, Teclado, Mouse, Monitor 15”.

Interfaces no padrão ATA: Os botões com as mesmas funcionalidades estarão localizados no mesmo lugar nas diferentes janelas. A interface terá uma aparência agradável, com cores neutras. Para melhor entendimento e visualização dos botões, eles terão figuras associadas. Os campos obrigatórios de cadastro serão identificados com um asterisco (*).

Formulário do Relatório da Equipe

Todos os membros da equipe desempenharam os mesmos papéis, com as mesmas contribuições, inclusive na criação e revisão de todos os textos e diagramas deste trabalho.

Nome

% Esforço da Equipe

Adriano D. Girardello

33,33%

Ana P. Fredrich

33,33%

Tiago A. S. Sippert

33,33%

Assinatura