SISTEMA TYR
Processo de Engenharia de Requisitos
Empresa: Academia Universitária
Processo e Engenharia de Software II(PES II)
4º Ano do Curso de Bacharelado em Informática
Cascavel
2009
Pedro Patitucci Finamore
Daniel Bordignon Cassanelli
Marco Antonio da Rosa
ESPECIFICAÇÃO DE REQUISITOS E MODELAGEM ORIENTADA A
OBJETOS
Especificação de requisitos e modelagem
orientada a objetos do sistema TYR, proposto
pela disciplina de Projeto e Engenharia de
Software II
Professor: Victor Francisco Araya Santander
Cascavel
2009
2
ÍNDICE
1- Motivação............................................................................................. 04
2- Introdução............................................................................................. 04
3- Metodologia.......................................................................................... 05
4- Cronograma.......................................................................................... 05
5- Requisitos Funcionais.......................................................................... 08
6- Modelagem Organizacional i*............................................................. 12
6.1 Diagrama SD............................................................................ 12
6.2 Diagrama SR............................................................................ 14
7- Requisitos Não-Funcionais.................................................................. 16
7.1 Grafo SIG ............................................................................... 18
8- Diagrama de Casos de Uso................................................................. 20
9- Diagrama de Classes........................................................................... 28
10- Conclusão......................................................................................... 31
Apêndice A............................................................................................. 32
3
1. Motivação
Atualmente, academias de musculação, quase sempre, possuem um
sistema de controle de treinamentos escasso, muitas vezes feito
manualmente e sem qualquer acompanhamento. Além disso, não é raro
encontrar academias que não possuem qualquer sistema de
informatização, gerenciando cadastros manualmente, por meio de
planilhas eletrônicas ou, em raras exceções, por meio de sistemas
privados de muitas funcionalidades.
Visto isso, o objetivo deste trabalho é a implementação de um sistema
que possibilite aos instrutores um maior controle de clientes, assim como
um melhor acompanhamento dos treinamentos, entre outras
funcionalidades.
2. Introdução
O projeto em estudo foi baseado na Academia Universitária, que se
encontra na Rua Universitária, nº1462, bairro Faculdade, CEP 85819110, na cidade de Cascavel, interior do Estado do Paraná, por saber das
deficiências tecnológicas da mesma e pelo desafio proporcionado aos
integrantes da equipe.
A empresa em questão não possui qualquer sistema de informação,
exceto planilhas eletrônicas, e faz o controle de seus clientes por meio
destas. Além do problema supracitado, o treinamento dos clientes é feito
em fichas de papel, com um treino único para todos os clientes da
academia, sem qualquer alteração no decorrer do treinamento. Outro
problema encontrado foi a precariedade do sistema de arquivamento de
dados dos clientes, que é feito manualmente e não guarda nada além dos
dados básicos de cada cliente.
Sendo assim, após entrevistas com os instrutores da academia, propôs-se
a implantação do sistema TYR, que fará o controle de clientes,
mensalidades e treinamentos. Os detalhes das entrevistas se encontram
no Apêndice A.
Neste documento será apresentado um estudo dos requisitos funcionais,
não funcionais e modelagem organizacional do sistema. Assim como os
diagramas de casos de uso e classes.
4
3. Metodologia
Como o projeto escolhido é um projeto de pequeno/médio porte, não foi
necessária a escolha de uma metodologia para sistemas robustos, como a
metodologia RUP. Visto isso, a metodologia escolhida pela equipe foi
baseada na escolha de uma metodologia ágil, para que todos
trabalhassem de forma igualitária e que o cliente também participasse do
desenvolvimento do sistema. Portanto, a metodologia adotada pela
equipe é a metodologia SCRUM. Como o projeto é de pequeno porte e a
equipe é pequena, fica viável a realização das Daily Meetings. Além
disso, visamos entregar um protótipo em curto espaço de tempo, a fim de
obter um feedback do cliente, possibilitando a integração do cliente no
time de desenvolvimento.
4. Cronograma
Os módulos do sistema foram divididos em Sprints, conforme
especificação da metodologia SCRUM. A partir do Sprint 04 será
entregue um protótipo utilizável para o cliente, em Sprints anteriores o
cliente apenas participará da implementação do software, não sendo
entregue protótipos utilizáveis. O cronograma a seguir foi feito após
primeiro contato com o cliente e definição de requisitos do sistema e
todos os módulos serão introduzidos ao cliente, assim como um
treinamento para o uso de cada módulo. O papel de Scrum Master ficará
a cargo do senhor Daniel Bordignon Cassanelli, pelo simples fato do
mesmo já ter tido contato, no passado, com este tipo de implementação.
As Daily Meetings (ou Stand Up Meetings) ocorrerão normalmente
durante o desenvolvimento do sistema, onde serão discutidos os detalhes
da implementação de cada Sprint, bem como o andamento do Sprint
corrente. A implementação do sistema se dará a partir do dia 28 de abril
de 2009 e o cronograma será explicitado a seguir:
[SPRINT01] Política de Login e senha
- Módulo fundamental para o funcionamento do sistema, todos os
outros dependem dele, neste módulo serão implementadas as
políticas de login e senha para o acesso ao banco de dados;
-Uma semana para a implementação do Sprint, a partir da
definição de requisitos, se iniciando no dia 18 de maio de 2009 e;
término no dia 01 de junho de 2009;
[SPRINT02] Semana de Adequação do Cronograma
- Semana dedicada a adequação do cronograma, avaliação do
ritmo de trabalho e retrospectiva do Sprint anterior.
5
[SPRINT03] Controle de Usuários;
- Módulo fundamental para o funcionamento do sistema, todos os
outros dependem dele;
- Para o controle de usuários, será necessário uma semana de
implementação, a partir do término do Sprint 01, se iniciando no
dia 08 de junho de 2009 e término no dia 22 de junho de 2009.
[SPRINT04] Semana de Adequação do Cronograma
- Semana dedicada a adequação do cronograma, avaliação do
ritmo de trabalho e retrospectiva do Sprint anterior
[SPRINT05] Controle de Serviços;
- Módulo fundamental para o funcionamento do sistema:
mensalidade, relatórios e treinamento dependem dele.
- Para o controle de usuários, será necessário uma semana de
implementação, a partir do término do Sprint 02, se iniciando no
dia 29 de junho de 2009 e término no dia 6 de julho de 2009.
[SPRINT06] Semana de Adequação do Cronograma
- Semana dedicada a adequação do cronograma, avaliação do
ritmo de trabalho e retrospectiva do Sprint anterior.
[SPRINT07] Controle de Clientes;
- Módulo fundamental para o funcionamento do sistema:
mensalidade e relatório dependem dele.
- Para o controle de usuários, serão necessárias três semanas de
implementação, a partir do término do Sprint 03, se iniciando no
dia 13 de julho de 2009 e término no dia 27 de julho de 2009.
[SPRINT09] Controle de Mensalidade;
- Módulo fundamental para o funcionamento do sistema: relatório
e cliente dependem dele.
- Para o controle de usuários, serão necessárias duas semanas de
implementação, a partir do término do Sprint 04, iniciando-se no
dia 03 de agosto de 2009 e término no dia 17 de agosto de 2009.
[SPRINT10] Semana de Adequação do Cronograma
6
- Semana dedicada a adequação do cronograma, avaliação do
ritmo de trabalho e retrospectiva do Sprint anterior.
[SPRINT011] Controle de Relatórios;
- Módulo essencial para o controle interno da academia;
- Duas semanas extras para estudo da ferramenta iReport,
iniciando-se no dia 24 de agosto de 2009 e término no dia 07 de
setembro de 2009.
- Para o controle de usuários, serão necessárias duas semanas de
implementação, a partir do término do Sprint 05, com inicio no
dia 24 de agosto de 2009 e término no dia 07 de setembro de
2009.
[SPRINT12] Semana de Adequação do Cronograma
- Semana dedicada a adequação do cronograma, avaliação do
ritmo de trabalho e retrospectiva do Sprint anterior.
[SPRINT13] Controle de Avaliação;
- Módulo essencial para o controle de treinamento;
- Uma semana extra para estudo de fórmulas básicas da
anamnese, com inicio no dia 14 de setembro de 2009 e término no
dia 28 de setembro de 2009;
- Para o controle de usuários, serão necessárias duas semanas de
implementação, a partir do término do Sprint 06, com inicio na
data de 14 de setembro de 2009 e término no dia 28 de setembro
de 2009;
[SPRINT14] Semana de Adequação do Cronograma
- Semana dedicada a adequação do cronograma, avaliação do
ritmo de trabalho e retrospectiva do Sprint anterior.
[SPRINT15] Controle de Treinamento;
- Módulo essencial para o Instrutor;
- Para o controle de usuários, serão necessárias duas semanas de
implementação, a partir do término do Sprint 07, com inicio no
dia 05 de outubro de 2009 e término no dia 19 de outubro de
2009.
[SPRINT16] Semana de Adequação do Cronograma
7
- Semana dedicada a adequação do cronograma, avaliação do
ritmo de trabalho e retrospectiva do Sprint anterior.
[SPRINT17] Implantação do Sistema de Treinamento dos Usuários do
Sistema;
- Módulo não fundamental para o funcionamento do sistema;
- Após a implantação do sistema, será iniciado o processo de
treinamento. O treinamento será administrado, pelo menos, duas
vezes por semana, com os dias a serem definidos, com o intervalo
de tempo entre os dias 26 de outubro de 2009 e o dia 09 de
novembro de 2009.
[SPRINT18] Semana de Adequação do Cronograma
- Semana dedicada a adequação do cronograma, avaliação do
ritmo de trabalho e retrospectiva do Sprint anterior.
[SPRINT19] Validação dos Requisitos Software pelo Cliente;
- Após o treinamento dado aos usuários do sistema e a
implantação do sistema, o gerente da academia validará os
requisitos do sistema.
- Após a validação dos requisitos, o sistema será entregue à
academia para testes e possíveis suportes. Caso hajam mudanças
durante o percurso do
desenvolvimento, novos sprints
serão gerados, conforme especificação da metodologia SCRUM.
- Este é o Sprint final e usará o tempo restante do projeto.
Após a validação dos requisitos, o sistema será entregue à academia para
testes e possíveis suportes. Caso haja mudanças durante o percurso do
desenvolvimento, novos sprints serão gerados, conforme especificação da
metodologia SCRUM.
5. Requisitos Funcionais do Sistema
Requisitos funcionais nada mais são do que as funcionalidades do
sistema, ou seja, tudo o que o sistema faz e executa. Nesta parte do
trabalho serão mostrados todos os requisitos do sistema, bem como uma
explicação breve de suas funcionalidades.
[RF-01] Cadastrar Cliente
O sistema deve permitir o cadastro de cliente através dos
seguintes dados:
8
- Nome;
- Idade;
- CPF;
- RG;
- Endereço;
- Telefone (Fixo e/ou Celular);
- Data de Vencimento da Mensalidade;
- Data de Nascimento;
- Serviço;
[RF-02] Gerar Número de Matrícula para o Cliente
Após cadastrar um cliente, o sistema deve gerar um número de
matrícula que deve ser feito seqüencialmente. Caso o cliente já
esteja cadastrado no sistema, uma mensagem de alerta aparecerá
informando a existência do cadastro.
[RF-03] Buscar Cliente
O sistema deve permitir a busca de um cliente pelo número da
matrícula ou pelo nome do mesmo. O resultado da busca deverá
aparecer na tela, caso o cliente não exista dentro do banco de
cadastros, uma mensagem de alerta aparecerá.
[RF-04] Excluir Cliente
O sistema deve permitir a exclusão de um cliente, que é feita após
uma busca pelo nome do mesmo. Ao excluir um cliente uma
mensagem aparecerá, para a confirmação da exclusão. Ao ser
excluído, o número de matrícula anteriormente ocupado pelo
cadastro, ficará disponibilizado.
[RF-05] Alterar Dados do Cliente
O sistema deve permitir a alteração de um cadastro, porém,
primeiramente uma busca deverá ser feita. Qualquer campo do
cadastro poderá ser alterado. Uma mensagem aparecerá para a
confirmação da alteração e outra indicando sucesso na tarefa.
[RF-06] Adicionar Treinamento
9
O sistema deve disponibilizar a adição de novos treinamentos
específicos, previamente feitos pelos instrutores.
[RF-07] Imprimir Treinamento do Cliente
O sistema deve permitir a impressão do treinamento do cliente,
para melhor acompanhamento do cliente.
[RF-08] Política de Login e Senha
Alguns privilégios serão requeridos para acessar determinadas
partes do sistema. Para isso, o sistema deve adicionar um item de
segurança essencial ao sistema, tal item é a política de login e
senha.
[RF-09] Cadastrar Instrutor
Um instrutor só poderá ser cadastrado pelo gerente da academia.
Para o cadastro ser realizado, o sistema deve coletar os seguintes
dados:
- Nome;
- RG;
- CPF;
- Telefone (fixo e/ou celular);
- Endereço;
Após o cadastramento do instrutor, será gerado para ele um login
e senha para o uso do sistema.
[RF-10] Buscar Instrutor
O sistema deve permitir que se busque um instrutor através do
nome ou do CPF do mesmo. O resultado da busca deverá ser
exibido na tela.
[RF-11] Excluir Instrutor
O sistema deve permitir que o cadastro de um instrutor seja
excluído imediatamente após ser efetuada uma busca pelo mesmo.
[RF-12] Alterar Dados do Instrutor
Alterações como novo endereço ou número de telefone deverão
ser efetuados após uma busca. As mensagens para confirmar a
10
alteração de dados do instrutor e o sucesso ou falha ao completar
a alteração serão exibidas.
[RF-13] Alterar Treinamento do Cliente
Um cronograma de treinamento deverá ser planejado pelo
instrutor e os treinos deverão seguir este cronograma, porém,
somente o instrutor poderá mudar o treinamento. O sistema TYR
deverá oferecer a possibilidade de o treinamento ser mudado.
[RF-14] Consultar Mensalidades
O sistema deve permitir que uma consulta às mensalidades seja
feita, para que as alterações no treinamento do cliente sejam
possíveis. Caso haja mensalidades pendentes, um aviso deverá ser
mostrado na tela e as alterações deverão ser bloqueadas.
[RF-15] Gerar Relatório
O sistema deverá gerar um relatório de mensalidades, que poderá
ser impresso ou visualizado na tela. O relatório só poderá ser
solicitado pelo gerente.
[RF-16] Dar Baixa em Mensalidades
O sistema deve permitir que o instrutor ou o gerente dê baixa na
mensalidade dos clientes da academia.
[RF-17] Aplicar Descontos
O sistema deve permitir que descontos sejam aplicados nas
mensalidades dos aniversariantes do mês e também nas
mensalidades daqueles que pagam adiantado. Este requisito
poderá ser desativado somente pelo gerente.
[RF-18] Aplicar Multas
O sistema deve implementar a aplicação de multas, para clientes
que não pagam a mensalidade em dia, automaticamente. Este
recurso só poderá ser desativado pelo gerente da academia.
[RF-19] Criar Avaliação Física
O sistema deve permitir que sejam criadas avaliações físicas para
os clientes da academia. Para tanto, uma verificação de existência
do cadastro é efetuada. A partir disso, os seguintes dados serão
coletados:
- Peso;
11
- Altura;
- Medidas: braço, pernas, glúteos, peitoral, ombros, coxas
e abdômen;
- Medicação;
- Atividade física;
- Objetivos;
- Observações.
Após a coleta de dados, um treinamento específico será
designado.
[RF–20] Refazer Avaliação Física
Depois de verificada a existência de avaliação prévia, o sistema
deve garantir que uma nova avaliação seja feita.
[RF–21] Buscar Avaliação Física
O sistema deve permitir que a busca de uma avaliação física seja
feita pelo nome ou pelo número da matrícula do cliente. O
resultado da busca deverá ser exibido na tela.
[RF–22] Criar Serviço
O sistema deve permitir que o gerente crie um novo serviço na
base de dados de Serviços. A criação de um novo serviço só
poderá ser realizada pelo gerente. Ao criar um serviço, um código
será atribuído ao mesmo.
[RF–23] Editar Serviço
O sistema deve permitir a edição de um serviço oferecido pela
academia. Consiste, basicamente, na edição do preço, descrição e
status do serviço. A edição de um serviço só poderá ser realizada
pelo gerente.
6. Modelagem Organizacional i*
Serão apresentados nesta seção os diagramas SD e SR, componentes da
modelagem organizacional, assim como a descrição dos mesmos.
6.1. Diagrama SD
Na página a seguir é apresentado o diagrama SD (Strategic
Dependency) que envolve o sistema TYR:
12
Figura 1: Diagrama de Dependências Estratégicas
13
O diagrama SD é composto por 05 atores, a saber: Cliente,
Instrutor, Gerente, Sistema e SGBD.
A utilização do sistema fica restrita ao Instrutor e ao Gerente,
como se pode verificar pelas dependências. Os clientes, por sua
vez, interagem com o instrutor, requisitando avaliações físicas e
solicitando cadastro.
O ator Instrutor precisa estar cadastrado no sistema para poder
utilizá-lo. Isso é feito pelo ator gerente que recolhe os dados do
instrutor, o cadastra e gera um nome de usuário e senha para o
ator Instrutor utilizar o sistema.
Após o cadastramento do Instrutor na base de dados, ele estará
apto a usar o sistema, podendo realizar as operações
gerenciamento de clientes, gerenciamento de treinamento e
gerenciamento de avaliação física. Para que o instrutor consiga
fazer estas operações de modo prático e dinâmico, o sistema
deverá ser rápido e fácil de usar, de modo que o Instrutor não
encontre dificuldades ao utilizar os comandos disponibilizados
pelo sistema.
Além de oferecer um nome de usuário e senha para o Instrutor, o
gerente será responsável pelas demais operações no
gerenciamento de dados do instrutor, além de coordenar a
empresa cadastrando novos serviços e gerando relatórios de
clientes.
Para que o instrutor possa gerenciar um cliente, este deve coletar
os dados do cliente. Coletados os dados, o Instrutor estará livre
para operar tanto sobre o gerenciamento de clientes quanto o
gerenciamento de avaliações. O Gerente também depende de um
sistema rápido para suas operações, além de oferecer um custo
que compense a implantação.
Finalmente, para que o sistema seja íntegro, rápido e confiável,
dependerá da qualidade do banco de dados em que ele será
implementado.
6.2. Diagrama SR
O único ator escolhido para a expansão foi o ator Sistema. O
diagrama SR (Strategic Rationale) segue na próxima página.
14
Figura 2: Modelo de Razões Estratégicas
15
O modelo SR, também conhecido como modelo de Razões
Estratégicas, complementa o modelo SD, pois expande os atores e
permite que estes sejam definidos mais detalhadamente.
Como dito anteriormente, o ator expandido foi o ator Sistema.
Pode ser visto no diagrama que os gerenciamentos de clientes e
instrutores possuem as mesmas subdivisões, a saber: cadastrar,
buscar, excluir e alterar.
A tarefa Logar no Sistema depende que sejam fornecidos um
nome de usuário (Login) e uma senha (Senha).
O modo de geração de relatórios é explicitado dentro da razão do
sistema, em forma de recursos, podendo ser gerado um
documento impresso ou visualizado na tela.
As operações de gerenciar serviço e treinamento, apesar de terem
nomes diferentes, subdividem-se de maneira igual: através da
criação ou da edição. No caso do treinamento, a edição será
específica para cada cliente.
O gerenciamento de avaliação física possui as divisões criar e
buscar.
A criação de um cadastro, seja ele de cliente ou de instrutor, deve
seguir uma série de passos, a saber: os dados são coletados, é feita
a inserção e atualização dos dados no banco de dados, verifica-se
se os dados inseridos já não estão presentes na tabela e o cadastro
é validado.
7. Requisitos Não-Funcionais
O projeto do sistema TYR conta com uma série de requisitos não
funcionais, sendo eles divididos em requisitos de processo e requisitos de
produto. Segue abaixo a especificação de cada um deles e,
posteriormente, o diagrama NFR
Requisitos do Processo:
[RNF 01] O sistema deverá ser implementado utilizando-se a tecnologia
Java de modo a ser compatível com o sistema operacional Windows.
[RNF-02] O sistema deverá ser implementado utilizando-se o MySQL
como sistema gerenciador de banco de dados.
[RNF-03] O sistema deverá ser implementado utilizando-se o padrão de
camadas MVC (Model-view-controller).
Requisitos do Produto:
16
Quanto à Usabilidade
[RNF-01] A interface com o usuário do sistema será amigável, simples e
objetiva. Para isto, serão utilizados componentes GUI (Graphic User
Interface) do Java.
[RNF-02] O sistema deverá ter botões intuitivos, contendo dicas de uso
sobre suas funcionalidades.
[RNF-03] Os módulos do sistema deverão ser divididos em abas. Este
conceito facilita o acesso a cada funcionalidade do sistema, pois todas as
funcionalidades estarão visíveis ao usuário, tornando o sistema mais
produtivo.
[RNF-04] Mensagens de erro ou mensagens de confirmação deverão ser
mostradas ao usuário. Mensagens de confirmação deverão aparecer
quando uma determinada operação for considerada arriscada e as
mensagens de erro deverão aparecer quando uma operação for feita de
modo inadequado, de modo explicativo para melhor orientação do
usuário.
Quanto ao Desempenho
[RNF-01] O sistema deverá disponibilizar que vários acessos sejam feitos
no banco de dados ao mesmo tempo, porém limitando o número de
conexões, deste jeito tornando o tempo de resposta mais rápido. Este
requisito fere a usabilidade do sistema, pois pode tornar o sistema
indisponível caso todas as conexões estejam sendo usadas.
Quanto à Segurança dos Dados
[RNF-01] A integridade dos dados será mantida pela utilização do banco
de dados MySQL.
[RNF-02] A disponibilidade de dados se dá através de um banco de
dados compartilhado, permitindo que usuários distintos do sistema
operem sobre o mesmo banco de dados.
[RNF-03] A confidencialidade dos dados do sistema será garantida
através de uma política de permissões.
Quanto à Segurança do Sistema
[RNF-01] A confidencialidade do sistema será garantida pela política de
login e senha.
[RNF-02] A integridade e a disponibilidade do sistema serão garantidos
pelo uso da tecnologia Java e do SGBD MySQL.
17
Quanto à Portabilidade
[RNF-01] O sistema poderá executar em qualquer plataforma, desde que
exista uma máquina virtual Java para a arquitetura e um SGBD MySQL.
Requisitos Externos:
[RNF-01] Como o propósito do sistema é acadêmico, não gerará custos
para os clientes.
7.1. Grafo SIG
O grafo SIG tem como objetivo uma ilustração para facilitar o
entendimento de como os requisitos não-funcionais são
decompostos e operacionalizados. O modelo pode ser conferido
na próxima página:
18
Figura 03: Diagrama SIG de Requisitos Não-Funcionais
19
Os requisitos não-funcionais foram validados pelo cliente de acordo com
suas necessidades. Alguns requisitos foram aceitos, tais como: a interface
baseada em abas, que melhora a navegabilidade do sistema; as
mensagens de erro, para que indique aos novos usuários do sistema e até
mesmo aos mais experientes os erros que estão sendo cometidos e o
porquê deles estarem acontecendo; a implementação efetuada na
linguagem Java, que soma de forma positiva o requisito de portabilidade;
dicas de uso, que devem ser implementadas a fim de instruir o usuário
nas decisões a serem tomadas; o uso de um SGBD robusto, que armazena
os dados com integridade, no caso específico o escolhido foi o SGBD
MySQL; um controle significativo de transações, para que um usuário,
no caso de um banco de dados compartilhado, alterar um dado do sistema
ao mesmo tempo que outro; definir um número limitado de conexões
com o banco de dados, para que não o sobrecarregue; políticas de
permissão definidas pelo gerente da academia, para que este atribua a um
usuário do sistema, determinadas responsabilidades de acordo com seu
nível de confiança; uma política de login e senha, previamente
explanada; um sistema tolerante a falhas, implementado em uma
linguagem confiável e certificada. Apenas o requisito de backup diário
foi rejeitado: o cliente não achou necessária a inclusão de backups diários
por não se tratar de um sistema crítico. Todos estes requisitos foram
validados pelo cliente de acordo com suas necessidades.
8. Diagrama dos Casos de Uso
Casos de Uso são utilizados para descrever o uso de um sistema por
atores. Um caso de uso descreve uma seqüência de passos/operações que
um usuário realiza quando interage com um sistema, visando realizar
uma determinada tarefa ou alcançar um objetivo. Dessa forma, o aspecto
comportamental de um sistema a ser desenvolvido pode ser descrito
através de casos de uso, porém, estas descrições não tratam da questão de
como as interações entre o usuário e o sistema serão implementadas.
Serão apresentados na próxima página os casos de uso do sistema,
através de um diagrama e de descrições detalhadas de cada caso de uso.
20
Figura 04: Diagrama de Casos de Uso
Caso de Uso 01: Cadastrar Cliente
Objetivo: Realizar a inserção de um novo cliente
Pré-Condições: Funcionário logado no sistema
Pós-Condições: Cadastro do novo cliente inserido no banco de dados
Ator: Funcionário
Cenário Principal:
1. O funcionário insere os dados do novo cliente.
2. O sistema insere o novo cadastro no banco de dados.
3. O sistema mostra uma mensagem de cadastro efetuado com sucesso.
Extensões:
21
2a. Cliente já cadastrado: O sistema cancela o cadastro e informa ao funcionário
que o cadastro já existe.
Caso de Uso 02: Atualizar Cadastro do Cliente
Objetivo: Alterar os dados cadastrais do cliente
Pré-Condições: Funcionário logado no sistema e cliente previamente cadastrado
Pós-Condições: Cadastro do cliente atualizado no banco de dados
Ator: Funcionário
Cenário Principal:
1. O funcionário busca o cliente (O caso de uso Buscar Cliente é incluído
<<include>>).
2. O funcionário altera os dados que desejar.
3. O funcionário confirma a alteração dos dados.
4. O sistema atualiza o cadastro do cliente no banco de dados.
5. O sistema mostra uma mensagem de atualização efetuada com sucesso.
Extensões:
Caso de Uso 03: Excluir Cliente
Objetivo: Realizar a exclusão de um cliente
Pré-Condições: Funcionário logado no sistema e cliente previamente cadastrado
Pós-Condições: Cadastro do cliente excluído do banco de dados
Ator: Funcionário
Cenário Principal:
1. O funcionário busca o cliente (O caso de uso Buscar Cliente é incluído
<<include>>).
2. O funcionário confirma a exclusão do cadastro.
3. O sistema remove o cadastro do cliente no banco de dados.
4. O sistema mostra uma mensagem de exclusão efetuada com sucesso.
Extensões:
Caso de Uso 04: Buscar Cliente
Objetivo: Realizar a busca do cadastro de um cliente
Pré-Condições: Funcionário logado no sistema
Pós-Condições: Sistema exibe o cadastro do cliente
Ator: Funcionário
Cenário Principal:
1. O funcionário entra com o nome do cliente ou o número da sua matrícula.
2. O sistema mostra uma lista com o nome completo dos clientes encontrados.
3. O funcionário escolhe o cliente desejado.
4. O sistema exibe o cadastro do cliente na tela.
Extensões:
2a. Cliente não cadastrado: O sistema informa ao funcionário que o cliente não foi
encontrado.
22
Caso de Uso 05: Login
Objetivo: Realizar o login no sistema e obter acesso adequado
Pré-Condições: Funcionário cadastrado
Pós-Condições: Funcionário logado com acesso autorizado
Ator: Funcionário
Cenário Principal:
1. O funcionário insere seu login e senha.
2. O sistema autentica o funcionário e atribui nível de acesso.
3. O sistema permite ao usuário utilizar as funcionalidades de acordo com o nível
de acesso.
Extensões:
2a. Login ou senha incorretos: O sistema informa ao funcionário que o login ou a
senha estão incorretos, e permite que ele entre com os dados novamente.
Caso de Uso 06: Cadastrar Instrutor
Objetivo: Realizar a inserção de um novo instrutor
Pré-Condições: Gerente logado no sistema
Pós-Condições: Cadastro do novo instrutor inserido no banco de dados
Ator: Gerente
Cenário Principal:
1. O gerente insere os dados do novo instrutor.
2. O sistema insere o cadastro do novo instrutor no banco de dados.
3. O sistema mostra uma mensagem de cadastro efetuado com sucesso.
Extensões:
2a. Instrutor já cadastrado: O sistema cancela o cadastro e informa ao gerente que
o instrutor já esta cadastrado.
Caso de Uso 07: Atualizar Cadastro do Instrutor
Objetivo: Alterar os dados cadastrais do instrutor
Pré-Condições: Gerente logado no sistema e instrutor previamente cadastrado
Pós-Condições: Cadastro do instrutor atualizado no banco de dados
Ator: Gerente
Cenário Principal:
1. O gerente busca o instrutor (O caso de uso Buscar Instrutor é incluído
<<include>>).
2. O gerente altera os dados que desejar.
3. O gerente confirma a alteração dos dados.
4. O sistema atualiza o cadastro do instrutor no banco de dados.
5. O sistema mostra uma mensagem de atualização efetuada com sucesso.
Extensões:
Caso de Uso 08: Excluir Instrutor
Objetivo: Realizar a exclusão de um instrutor
23
Pré-Condições: Gerente logado no sistema e instrutor previamente cadastrado
Pós-Condições: Cadastro do instrutor excluído do banco de dados
Ator: Gerente
Cenário Principal:
1. O gerente busca o instrutor (O caso de uso Buscar Instrutor é incluído
<<include>>).
2. O gerente confirma a exclusão do cadastro.
3. O sistema remove o cadastro do instrutor no banco de dados.
4. O sistema mostra uma mensagem de exclusão efetuada com sucesso.
Extensões:
Caso de Uso 09: Buscar Instrutor
Objetivo: Realizar a busca do cadastro de um instrutor
Pré-Condições: Gerente logado no sistema
Pós-Condições: Sistema exibe o cadastro do instrutor
Ator: Gerente
Cenário Principal:
1. O gerente insere os dados do instrutor a ser buscado.
2. O sistema mostra uma lista com o nome completo dos instrutores encontrados.
3. O gerente escolhe o instrutor desejado.
4. O sistema exibe o cadastro do instrutor na tela.
Extensões:
2a. Instrutor não cadastrado: O sistema informa ao gerente que o instrutor não foi
encontrado.
Caso de Uso 10: Criar Serviço
Objetivo: Disponibilizar para os clientes um novo serviço oferecido pela academia
Pré-Condições: Gerente logado no sistema
Pós-Condições: Novo serviço inserido no banco de dados
Ator: Gerente
Cenário Principal:
1. O gerente insere os dados do novo serviço.
2. O sistema insere o novo serviço no banco de dados.
3. O sistema mostra uma mensagem de sucesso.
Extensões:
2a. Serviço já cadastrado: O sistema cancela o cadastro e informa ao gerente que o
serviço já esta cadastrado.
Caso de Uso 11: Editar Serviço
Objetivo: Alterar um serviço cadastrado no sistema
Pré-Condições: Gerente logado no sistema e serviço previamente cadastrado
Pós-Condições: Serviço atualizado no banco de dados
Ator: Gerente
24
Cenário Principal:
1. O sistema exibe uma lista com todos os serviços cadastrados.
2. O gerente escolhe o serviço desejado.
3. O sistema exibe os detalhes do serviço.
4. O gerente altera os dados.
5. O gerente confirma a alteração dos dados.
6. O sistema atualiza o cadastro do serviço no banco de dados.
7. O sistema mostra uma mensagem de sucesso.
Extensões:
Caso de Uso 12: Gerar Relatório
Objetivo: Gerar um relatório contendo todos os clientes da academia e o histórico de
mensalidades dos respectivos clientes
Pré-Condições: Gerente logado no sistema
Pós-Condições: O relatório é gerado pelo sistema
Ator: Gerente
Cenário Principal:
1. O gerente solicita a geração do relatório.
2. O sistema exibe o relatório na tela.
3. O gerente tem a possibilidade de imprimir o relatório.
Extensões:
Caso de Uso 13: Adicionar Treinamento
Objetivo: Realizar a inclusão de um treinamento para o cliente
Pré-Condições: Instrutor logado no sistema e cliente previamente cadastrado
Pós-Condições: Treinamento adicionado ao cadastro do cliente no banco de dados
Ator: Instrutor
Cenário Principal:
1. O instrutor busca o cliente (O caso de uso Buscar Cliente é incluído
<<include>>).
2. O instrutor entra com a descrição do treino para cada dia da semana.
3. O sistema insere o treinamento no banco de dados.
4. O sistema mostra uma mensagem de sucesso.
Extensões:
Caso de Uso 14: Alterar Treinamento
Objetivo: Realizar a alteração do treinamento de um cliente
Pré-Condições: Instrutor logado no sistema
Pós-Condições: Treinamento atualizado no cadastro do cliente no banco de dados
Ator: Instrutor
Cenário Principal:
1. O instrutor busca o cliente (O caso de uso Buscar Cliente é incluído
<<include>>).
2. O sistema exibe o treinamento do cliente na tela.
3. O instrutor altera os dados que forem necessários.
25
4. O sistema atualiza o treinamento no banco de dados e mostra uma mensagem
de sucesso.
Extensões:
Caso de Uso 15: Dar Baixa na Mensalidade
Objetivo: Dar baixa nos débitos de um cliente
Pré-Condições: Gerente logado no sistema e cliente cadastrado
Pós-Condições: Atualizado os débitos no cadastro do cliente no banco de dados
Ator: Gerente
Cenário Principal:
1. O gerente busca o cliente (O caso de uso Buscar Cliente é incluído
<<include>>).
2. O sistema exibe as mensalidades do cliente e o total de débitos.
3. O gerente confirma o pagamento.
4. O sistema atualiza os débitos do cliente no banco de dados e mostra uma
mensagem de sucesso.
Extensões:
2a. Pagamento adiantado ou cliente de aniversário: Caso de uso Aplicar Desconto
<<extend>>.
2b. Pagamento atrasado: Caso de uso Aplicar Multa <<extend>>.
Caso de Uso 16: Aplicar Multa
Objetivo: Aplicar multa numa mensalidade que esteja sendo paga com atraso.
Pré-Condições: Gerente logado no sistema e cliente cadastrado
Pós-Condições: A multa é aplicada à mensalidade do cliente
Ator: Gerente
Cenário Principal:
1. O gerente entra com o cliente desejado.
2. O sistema verifica o tempo de atraso.
3. O sistema calcula o valor da multa.
4. O sistema aplica a multa à mensalidade.
Extensões:
Caso de Uso 17: Aplicar Desconto
Objetivo: Aplicar desconto na mensalidade de um cliente que esteja pagando adiantado,
ou o cliente seja um aniversariante no mês.
Pré-Condições: Gerente logado no sistema e cliente cadastrado
Pós-Condições: O desconto é aplicado à mensalidade do cliente
Ator: Gerente
Cenário Principal:
1. O gerente entra com o cliente desejado.
2. O sistema verifica se a mensalidade esta sendo paga adiantada ou o cliente é um
aniversariante do mês.
3. O sistema calcula o valor do desconto.
26
4. O sistema aplica o desconto à mensalidade.
Extensões:
Caso de Uso 18: Criar Avaliação Física
Objetivo: Gerar uma avaliação física do cliente
Pré-Condições: Instrutor logado no sistema e cliente cadastrado no sistema
Pós-Condições: Avaliação física criada e inserida no banco de dados
Ator: Instrutor
Cenário Principal:
1. O instrutor busca o cliente (O caso de uso Buscar Cliente é incluído
<<include>>).
2. O instrutor insere os dados coletados do cliente.
3. O sistema insere a avaliação física no banco de dados.
4. O sistema exibe uma mensagem de sucesso.
Extensões:
Caso de Uso 19: Alterar Avaliação Física
Objetivo: Atualizar uma avaliação física
Pré-Condições: Instrutor logado no sistema e avaliação física já criada
Pós-Condições: A avaliação física será alterada e atualizada no banco de dados
Ator: Instrutor
Cenário Principal:
1. O instrutor busca a avaliação física do cliente (O caso de uso Buscar Avaliação
Física é incluído <<include>>).
2. O instrutor insere os novos dados do cliente.
3. O sistema atualiza a avaliação física no banco de dados.
4. O sistema exibe uma mensagem de sucesso.
Extensões:
Caso de Uso 20: Buscar Avaliação Física
Objetivo: Realizar a busca da avaliação física de um cliente
Pré-Condições: Instrutor logado no sistema e avaliação física já criada
Pós-Condições: O sistema exibe a avaliação física do cliente na tela
Ator: Instrutor
Cenário Principal:
1. O instrutor entra com o nome do cliente ou o número da sua matrícula.
2. O sistema mostra uma lista com o nome completo dos clientes encontrados.
3. O funcionário escolhe o cliente desejado.
4. O sistema exibe a avaliação física do cliente na tela.
Extensões:
2a. Avaliação física inexistente: O sistema informa ao instrutor que a avaliação
física do cliente ainda não foi criada.
27
9. Diagrama de Classes
Concebido preliminarmente para estabelecer a relação entre os atores e os
requisitos, mostra a relação das classes levantadas nos passos anteriores. A
completude tende a variar durante o desenvolvimento.
Classe Pessoa
Os atores descendem dela e carregam suas características. Trata de dados
do indivíduo: nome, cpf, rg, telefone, endereço e data de nascimento. As
classes que descendem de pessoa são a Cliente e Usuário.
Classe Cliente
Representa o cliente da academia. Possui atributos mensalidade,
treinamento e avaliação, além dos presentes na classe pessoa.
Classe Usuario
Representa os usuários do sistema: Instrutor e Gerente. A diferenciação
se dá pelos atributos de permissão presentes nessa classe.
Classe Mensalidade
Responsável por representar a mensalidade do cliente. Possui atributos
que registram data de início, data de vencimento e serviços do cliente. O
cálculo da mensalidade será feito por uma classe de controle ainda em
desenvolvimento.
Classe Treinamento
A classe cliente usa para registrar o treinamento gerado pelo Instrutor. É
única para cada cliente.
Classe Avaliação
A classe cliente usa para registrar as avaliações geradas pelo Instrutor.
Podem haver várias avaliações, sendo usadas futuramente para
acompanhamento do progresso do cliente.
Classe Serviço
Responsável por representar os serviços prestados pela academia. Possui
atributos que registram a descição e o valor do mesmo. Esta classe é
usada pela classe Mensalidade para registro dos serviços contratodos pelo
cliente.
Classe Endereço
Classe especializada para tratamento de dados referentes ao endereco de
uma instância da classe Pessoa. Registra rua, número, cep, cidade,
estado.
Classe Telefone
Classe especializada para tratamento de dados referentes ao Telefone de
uma instância da classe Pessoa. Registra número e DDD.
O diagrama de classes será apresentado na próxima página.
28
Figura 05: Diagrama de Classes
29
10. Conclusão
Neste momento do projeto, após finalizada a elicitação de requisitos,
tem-se mais clareza sobre o que o cliente realmente precise e como isto
deverá ser alcançado.A partir da elaboração deste documento de
requisitos em conjunto com os diagramas, além de entrevistas com os
clientes interessados, conclui-se que há uma melhor interpretação do
problema, possibilitando o inicio da parte de implementação do projeto.
Com base nos protótipos gerados, esperamos o surgimento de requisitos
baseados em necessidades emergentes. Acreditamos que a metodologia
escolhida seja acertada para esse tipo de desafio, contribuindo para a
completude e comprimento de prazo do projeto.
A partir da elaboração deste documento de requisitos em conjunto com
os diagramas, além de entrevistas com os clientes interessados, concluise que há uma melhor interpretação do problema, tornando a
implementação significativamente mais simples, já que não é necessário
“tatear” à procura de requisitos.
30
Apêndice A
O primeiro contato ocorreu de maneira informal, onde foi proposto o sistema de
gerenciamento de clientes e treinamentos e várias idéias foram levadas em conta. A
entrevista se deu com a instrutora Lucila Donassolo e ficou acertado que em uma
próxima ocasião os requisitos seriam elicitados.
A elicitação de requisitos também se deu de maneira informal: foram levantados
os problemas encontrados pela falta de um sistema de informação para controle de
clientes e treinamento e após isto, cliente e desenvolvedores participaram em conjunto
para a elicitação dos requisitos funcionais e não-funcionais do sistema. Uma próxima
reunião foi marcada para a validação dos requisitos não-funcionais.
Após o planejamento e diagramação dos requisitos não-funcionais, uma nova
reunião ocorreu informalmente, onde foram validados ou rejeitados os requisitos
definidos pelo sistema.
31
Formulário do Relatório da Equipe
Após a elaboração das alternativas em conjunto, cada integrante teve maior participação
no estudo de viabilidade de uma delas, sempre com a ajuda dos outros da equipe. Então,
o grupo pôde fazer um estudo comparativo entre as possibilidades, de modo que a
melhor delas pudesse ser escolhida.
Nome
% de esforço na equipe
______________________________________
Pedro Patitucci Finamore
33,3%
______________________________________
Marco Antonio da Rosa
33,3%
______________________________________
Daniel Bordignon Cassanelli
33,3%
32