Especificação de Requisitos Especificação de Requisitos e Validação de Sistemas
Equipe: Danilo Laurindo (dlsa) Paulo Ferreira (phmf) Thyago Porpino (tnp) Wagner Barros (wbas) Setembro de 2010
1
Sumário
1. MOTIVAÇÃO ................................................................................................................................ 3
2. O PROBLEMA IDENTIFICADO .................................................................................................... 3
3. SOBRE A ORGANIZAÇÃO ............................................................................................................ 4
4. REQUISITOS ORGANIZACIONAIS ................................................................................................... 5
5. REQUISITOS FUNCIONAIS .............................................................................................................. 5
6. REQUISITOS NÃO-FUNCIONAIS ..................................................................................................... 9
6.1. REQUISITOS DO PROCESSO ................................................................................................................. 9
6.1.1. [NFR-01] Utilizar linguagem C# e .NET framework ............................................................ 9
6.1.2. [NFR-02] Utilizar o banco de dados SQL Server ................................................................ 10
6.1.3. [NFR-03] Utilizar o SCRUM como metodologia de desenvolvimento ............................... 10
6.2. REQUISITOS DE PRODUTO ................................................................................................................ 10
6.2.1. Usabilidade ....................................................................................................................... 10 6.2.1.1. [NFR-04] Mensagens de Erro...................................................................................................... 10 6.2.1.2. [NFR-05] Interface do Sistema ................................................................................................... 10 6.2.1.3. [NFR-06] Manual do Usuário ...................................................................................................... 11
6.2.2. Disponibilidade ................................................................................................................. 11 6.2.2.1. [NFR-07] Disponibilidade ............................................................................................................ 11
6.2.1. Performance ..................................................................................................................... 11 6.2.1.1. [NFR-08] Tempo de Resposta ..................................................................................................... 11 6.2.1.2. [NFR-09] Espaço de armazenamento ......................................................................................... 12
6.2.2. Segurança ......................................................................................................................... 12 6.2.2.1. [NFR-10] Privacidade .................................................................................................................. 12 6.2.2.2. [NFR-11] Confidencialidade ........................................................................................................ 12 6.2.2.3. [NFR-12] Permissão .................................................................................................................... 12
6.2.3. Manutenabilidade ............................................................................................................ 13 6.2.3.1. [NFR-13] Modularidade .............................................................................................................. 13 6.2.3.2. [NFR-14] Legibilidade do Código ................................................................................................ 13 6.2.3.3. [NFR-15] Documentação ............................................................................................................ 13
6.3. REQUISITOS EXTERNOS .................................................................................................................... 14
6.3.1. [NFR-16] Tempo de desenvolvimento .............................................................................. 14
6.3.2. [NFR-17] Orçamento ........................................................................................................ 14
7. MODELAGEM ORGANIZACIONAL................................................................................................. 14
7.1. MODELAGEM DE DEPENDÊNCIA ESTRATÉGICA ..................................................................................... 14
7.2. MODELAGEM DE RAZÃO ESTRATÉGICA ............................................................................................... 15
8. MODELAGEM DE REQUISITOS FUNCIONAIS .......................................................................... 16
9. MODELAGEM DE REQUISITOS NÃO-FUNCIONAIS ................................................................. 17
10. CONCLUSÃO ........................................................................................................................... 18
11. RELATÓRIO DE PARTICIPAÇÃO .......................................................................................... 18
12. REFERÊNCIAS ........................................................................................................................ 19
Apêndice A – Descrição dos Casos de Uso ......................................................................................... 20
Apêndice B – Técnicas Utilizadas na Coletas de Dados ................................................................... 35 Questionário .................................................................................................................................................. 35
2
Entrevista Aberta ........................................................................................................................................... 35 Apêndice C – Questionário ................................................................................................................ 36
Apêndice D – Glossário ...................................................................................................................... 37
Apêndice E – Convenções .................................................................................................................. 38
3
1. Motivação
Hoje em dia, os sistemas de informação têm facilitado em muito as atividades
do nosso cotidiano. Profissionais de diversas áreas vêm recorrendo a sistemas
computacionais para auxiliá-los em suas atividades, estas que eram realizadas
manualmente. Um dos grandes problemas que surgiu no século XX, e que perdura até
hoje, é falta de mecanismos eficientes de gerência no trânsito. As quantidades de
automóveis e motoristas vêm crescendo muito nos últimos anos, os órgãos federais,
estaduais e municipais de trânsito, precisam cada vez mais melhorar os métodos de
gerenciamento, controle e fiscalização do trânsito. O uso de sistemas de informação
para auxiliar esses órgãos está se tornando uma prática corriqueira.
2. O Problema Identificado
A CTTU é um órgão de controle e fiscalização de trânsito da cidade do Recife,
que desde 2003 atua nas ruas como órgão regulador de trânsito, através do trabalho
de seus agentes.
Os agentes municipais da CTTU atuam nas ruas do Recife com o objetivo de
autuar os motoristas infratores. O auto de infração é feito todo ele a mão, ou seja, o
agente ao perceber que um motorista está desrespeitando alguma norma de trânsito,
pode surpreender o motorista em flagrante, ou ao perceber que determinado veículo
desrespeitou alguma norma, pode multá-lo mesmo que não seja em flagrante. Alguns
problemas podem ser citados em relação ao preenchimento manual do auto de
infração:
Em caso de flagrante, o agente deve parar o motorista por um longo
período de tempo, até que termine de preencher todos os dados,
confira o preenchimento dos dados, e logo em seguida peça para o
motorista assinar o auto de infração.
Mesmo em caso que não caracterize um flagrante, o agente perde
muito tempo preenchendo uma longa lista de dados sobre o veículo
autuado, tempo este que poderia ser mais bem aproveitado a serviço
da sociedade.
O agente precisa preencher uma longa lista de dados sem auxílio
nenhum, como código, descrição e observações da infração e descrição
do veículo (e.g. cor, cidade, estado, modelo e marca).
Local preciso da infração, com endereço completo, especificando
cruzamento, ou número próximo do local.
4
Qualquer erro no preenchimento do auto, pode abrir a possibilidade do
motorista multado entrar com um recurso, verificar o auto original, e
revogar a multa no caso do erro cometido ser identificado.
Agentes cansados e esgotados de um dia inteiro de trabalho costumam
perder muito tempo preenchendo uma multa, errar a marca ou modelo
do carro, preencher uma placa erroneamente, ou qualquer erro que um
ser humano está sujeito a cometer.
Os autos manuscritos são enviados ao DETRAN, onde precisam ser
feitos todos os procedimentos burocráticos para dar continuidade ao
processo.
Os agentes não são gerenciados de forma eficaz, de modo que não há
como saber se eles estão realmente nos lugares que deveriam,
realizando o serviço corretamente.
Justifica-se assim, a importância de um sistema de auxílio ao agente de trânsito,
que de certa forma dê agilidade a esse processo, evitando erros, prejuízos e desgastes
desnecessários. Ao mesmo tempo é importante que o sistema possa fornecer dados a
central de controle como localização dos agentes, dados que podem ser adquiridos a
partir de tecnologias modernas como GPS.
3. Sobre a Organização
Na década de 70, a Prefeitura do Recife, através da Companhia de Transporte
Urbano (CTU), era integralmente responsável pelo sistema de transportes público de
passageiros. A CTU, além de gestora, era empresa operadora do sistema trólebus.
Naquela época, o trânsito era gerido pelo Estado, através do Departamento Estadual
de Trânsito (DETRAN).
Na década de 80, ocorreu a delegação da gestão do transporte público para o
Estado, através da Empresa Metropolitana de Transportes Urbanos (EMTU). Em 1999,
a gestão do trânsito passou para a EMTU. Neste mesmo ano, no mês de novembro, foi
criada a subsidiária integral, a Companhia de Transporte Urbano Recife (CTUR). Com a
mudança das atribuições da CTU e da razão social, a empresa passou a se chamar
Companhia de Trânsito e Transporte Urbano do Recife (CTTU).
Desde janeiro de 2003, a CTTU está nas ruas como órgão regulador do trânsito.
Os Agentes Municipais contam com o apoio de policiais do BPTRAN e estão nas ruas,
dando prioridade às ações educativas. O processamento dos autos de infração é
realizado pelo DETRAN, sob coordenação da Prefeitura, através de convênio. Há
também o gerenciamento da Engenharia de Tráfego (implantação e manutenção da
5
sinalização gráfica e semafórica da cidade, definição de áreas de circulação de veículos
e pedestres, bem como definição de espaços para estacionamento).
4. Requisitos Organizacionais
Requisitos organizacionais mapeiam as metas, objetivos e políticas estratégicas
de uma empresa ou organização. Foram identificados através de entrevistas com o
diretor de projeto da CTTU os seguintes pontos, maiores detalhes estão no Apêndice B:
Aumentar a agilidade dos processos com os auto de infração.
Automatizar processos de autuação de motoristas no trânsito, assim
como gerenciar as informações de forma rápida e informatizada.
Diminuir os casos de erro dos agentes de trânsito, diminuindo os
problemas para a CTTU e para a sociedade.
Acompanhar a fiscalização dos veículos de forma mais eficaz, a partir de
dados estatísticos sobre o trânsito da cidade.
5. Requisitos Funcionais
Nesta seção trataremos dos requisitos funcionais do AIT (Auto de Infração de
Trânsito). Esses são os requisitos que descrevem as funcionalidades do sistema que
atendem as necessidades da CTTU. Os requisitos foram agrupados em categorias para
facilitar o entendimento e a manutenção da documentação do sistema. Os casos de
uso correspondentes estão descritos no Apêndice A. As convenções estão no Apêndice
E.
Identificação: [RF-01] Autenticar Usuário
Casos de Uso relacionados: [UC-01]
Descrição:
Requisita a autenticação do agente quando o mesmo tenta entrar
no sistema, de forma a não permitir acesso não autorizado. A
autenticação é feita com login e senha, logo após entrar no sistema,
o agente é requisitado a gravar sua assinatura.
Prioridade: Essencial Importante Desejável
Identificação: [RF-02] Inserir Auto de Infração
Casos de Uso relacionados: [UC-02]
6
Descrição:
Insere um auto de infração no banco de dados, gravando as
seguintes informações a respeito do veículo e da infração:
Número da placa e informações do veículo
Código da infração e descrição do código
Endereço do local da infração
Informação que indica caso houve um flagrante, em
caso de flagrante, o agente pode tirar fotos do veículo.
Prioridade: Essencial Importante Desejável
Identificação: [RF-03] Pesquisar Veículo
Casos de Uso relacionados: [UC-03]
Descrição: Permitir a pesquisa de um veículo no banco de dados através do
número da placa do mesmo.
Prioridade: Essencial Importante Desejável
Identificação: [RF-04] Alterar Auto de Infração
Casos de Uso relacionados: [UC-04]
Descrição:
Permite que um auto de infração tenha alguns dos seus parâmetros
alterados. Tanto o auto de infração atualizado quanto o antigo
devem ser armazenados pelo sistema.
Prioridade: Essencial Importante Desejável
Identificação: [RF-05] Deletar Auto de Infração
Casos de Uso relacionados: [UC-05]
Descrição:
Permite que um auto de infração seja removido. O auto de infração
removido deve ser armazenados pelo sistema com status de
deletado.
Prioridade: Essencial Importante Desejável
Identificação: [RF-06] Buscar Auto de Infração
Casos de Uso relacionados: [UC-06]
Descrição: Permitir a pesquisa de um auto de infração no banco de dados
através do número do auto de infração, da placa do carro, data ou
7
local.
Prioridade: Essencial Importante Desejável
Identificação: [RF-07] Tirar foto do veículo
Casos de Uso relacionados: [UC-07]
Descrição: Permite à captura e o armazenamento de uma foto do veículo
autuado caso houve o flagrante da infração.
Prioridade: Essencial Importante Desejável
Identificação: [RF-08] Registrar Assinatura
Casos de Uso relacionados: [UC-08]
Descrição: Permitir à captura e o armazenamento de assinaturas.
Prioridade: Essencial Importante Desejável
Identificação: [RF-09] Imprimir multa
Casos de Uso relacionados: [UC-09]
Descrição: Permitir a possibilidade da impressão de uma multa de trânsito logo
após o preenchimento de um auto de infração ou modificação.
Prioridade: Essencial Importante Desejável
Identificação: [RF-09] Reimprimir multa
Casos de Uso relacionados: [UC-10]
Descrição: Permitir a possibilidade da reimpressão de uma multa de trânsito.
Prioridade: Essencial Importante Desejável
Identificação: [RF-11] Visualizar quantidade de multas.
Casos de Uso relacionados: [UC-11]
Descrição:
Permitir a visualização da quantidade de multas aplicadas por um
agente em um determinado expediente de trabalho.
8
Prioridade: Essencial Importante Desejável
Identificação: [RF-12] Consultar Veículo estacionado.
Casos de Uso relacionados: [UC-12]
Descrição:
Checar através da placa do veículo, se ele possui permissão para
estacionar num local regulamentado.
Prioridade: Essencial Importante Desejável
Identificação: [RF-13] Cadastrar Agente
Casos de Uso relacionados: [UC-13]
Descrição:
Permite que um supervisor cadastre um agente no sistema. O
supervisor adiciona as informações (nome, CPF, RG, sexo, data de
nascimento, data de admissão, salário).
Prioridade: Essencial Importante Desejável
Identificação: [RF-14] Remover Agente
Casos de Uso relacionados: [UC-14]
Descrição: Permite que um determinado cadastro de um agente seja
removido.
Prioridade: Essencial Importante Desejável
Identificação: [RF-15] Atualizar Agente
Casos de Uso relacionados: [UC-15]
Descrição: Permite que um cadastro de um agente tenha seus dados alterados.
Prioridade: Essencial Importante Desejável
Identificação: [RF-16] Buscar Agente
Casos de Uso relacionados: [UC-16]
Descrição: Permitir a pesquisa do cadastro de um determinado agente através
do nome ou CPF.
9
Prioridade: Essencial Importante Desejável
Identificação: [RF-17] Gerar relatório estatístico.
Casos de Uso relacionados: [UC-17]
Descrição: Permitir a geração de um relatório relatando estatisticamente a
ocorrência de infrações em um determinado período ou local.
Prioridade: Essencial Importante Desejável
Identificação: [RF-18] Gerar relatório de Agentes.
Casos de Uso relacionados: [UC-18]
Descrição: Permitir a geração de um relatório relatando as infrações
registradas por cada agente.
Prioridade: Essencial Importante Desejável
6. Requisitos Não-Funcionais
Este seção descreve os requisitos relacionados a certas restrições do sistema e
aspectos de qualidade tanto do sistema quanto a processo de desenvolvimento. A
classificação desses requisitos segue o autor [Sommerville], que agrupa os mesmos em
três grupos, a saber: requisitos de processo, requisitos de produto e requisitos
externos. As convenções estão no Apêndice E.
6.1. Requisitos do Processo
6.1.1. [NFR-01] Utilizar linguagem C# e .NET framework
Identificação: [NFR-01] Utilizar linguagem C# e .NET framework
Casos de Uso relacionados: Todos.
Descrição: A linguagem C# e NET framework serão utilizados tanto
nos sistemas terminais móveis quanto no sistema de
gerenciamento na WEB.
Prioridade: Essencial Importante Desejável
10
6.1.2. [NFR-02] Utilizar o banco de dados SQL Server
Identificação: [NFR-02] Utilizar o banco de dados SQL Server
Casos de Uso relacionados: Todos.
Descrição: O Banco de dados SQL Server é compatível com o
framework de desenvolvimento da Microsoft.
Prioridade: Essencial Importante Desejável
6.1.3. [NFR-03] Utilizar o SCRUM como metodologia de desenvolvimento
Identificação: [NFR-03] Utilizar o SCRUM como metodologia de
desenvolvimento
Casos de Uso relacionados: Todos.
Descrição: A metodologia SCRUM é uma metodologia ágil que prevê
entregas incrementais, será necessário para o
desenvolvimento do projeto.
Prioridade: Essencial Importante Desejável
6.2. Requisitos de Produto
6.2.1. Usabilidade
6.2.1.1. [NFR-04] Mensagens de Erro
Identificação: [NFR-04] Mensagens de Erro
Casos de Uso relacionados: Todos.
Descrição:
As mensagens de erro deverão ser objetivas, orientando o
usuário a solucionar o problema e não impedindo o
progresso dele no sistema. Elas serão exibidas com um
mínimo de impacto no fluxo da aplicação.
Prioridade: Essencial Importante Desejável
6.2.1.2. [NFR-05] Interface do Sistema
Identificação: [NFR-05] Interface do Sistema
Casos de Uso relacionados: Todos.
Descrição: A Interface Gráfica do Usuário (GUI) deverá prover a
comunicação entre o usuário e o sistema para que ele tenha
fácil acesso a todas as funcionalidades do sistema e de
11
forma objetiva. A GUI deverá seguir regras de Usabilidade
e as informações deverão estar bem intuitivas.
Prioridade: Essencial Importante Desejável
6.2.1.3. [NFR-06] Manual do Usuário
Identificação: [NFR-06] Manual do Usuário
Casos de Uso relacionados: Todos.
Descrição: O manual do usuário do sistema deve ser bem estruturado.
Deve conter todas as informações relativas às
funcionalidades do sistema de forma clara e objetiva.
Prioridade: Essencial Importante Desejável
6.2.2. Disponibilidade
6.2.2.1. [NFR-07] Disponibilidade
Identificação: [NFR-07] Disponibilidade
Casos de Uso relacionados: Todos.
Descrição: O sistema não pode ficar indisponível por mais de 3
minutos.
Prioridade: Essencial Importante Desejável
6.2.1. Performance
6.2.1.1. [NFR-08] Tempo de Resposta
Identificação: [NFR-08] Tempo de Resposta
Casos de Uso relacionados: Todos.
Descrição: Nenhuma das consultas feitas ao sistema deverá exceder
4.5 segundos.
Prioridade: Essencial Importante Desejável
12
6.2.1.2. [NFR-09] Espaço de armazenamento
Identificação: [NFR-09] Espaço de armazenamento
Casos de Uso relacionados: Todos.
Descrição:
O espaço de armazenamento utilizado para guardar as
informações do sistema devera ser local com 4 gigabytes, e
também, distribuído sendo este um servidor que não poderá
ter armazenar mais que 75% de sua capacidade.
Prioridade: Essencial Importante Desejável
6.2.2. Segurança
6.2.2.1. [NFR-10] Privacidade
Identificação: [NFR-10] Privacidade
Casos de Uso relacionados: Todos.
Descrição: Somente os agentes e o supervisor podem ter acesso aos
dados do sistema.
Prioridade: Essencial Importante Desejável
6.2.2.2. [NFR-11] Confidencialidade
Identificação: [NFR-11] Confidencialidade
Casos de Uso relacionados: Todos.
Descrição: Todas as comunicações externas entre o servidor de dados do sistema e os terminais dos agentes devem ser criptografadas.
Prioridade: Essencial Importante Desejável
6.2.2.3. [NFR-12] Permissão
Identificação: [NFR-12] Permissão
Casos de Uso relacionados: Todos.
Descrição: Cada tipo de usuário, agente e supervisor, só pode acessar
as informações e as funcionalidades a ele permitidas.
Prioridade: Essencial Importante Desejável
13
6.2.3. Manutenabilidade
6.2.3.1. [NFR-13] Modularidade
Identificação: [NFR-13] Modularidade
Casos de Uso relacionados: Todos.
Descrição: O sistema deve ser implementado em camadas, de forma
modularizada, para facilitar manutenções corretivas e
incrementais.
Prioridade: Essencial Importante Desejável
6.2.3.2. [NFR-14] Legibilidade do Código
Identificação: [NFR-14] Legibilidade do Código
Casos de Uso relacionados: Todos.
Descrição: O código deve ser o mais simples e bem escrito possível
para que seja o mais legível e assim mais fácil de
identificar erros.
Prioridade: Essencial Importante Desejável
6.2.3.3. [NFR-15] Documentação
Identificação: [NFR-15] Documentação
Casos de Uso relacionados: Todos.
Descrição:
O sistema deve ser possuir de um manual técnico detalhado
explicando o sistema. O manual é um documento deve ser
completo e correto, e é voltado aos desenvolvedores que
vão fazer possíveis manutenções.
Prioridade: Essencial Importante Desejável
14
6.3. Requisitos externos
6.3.1. [NFR-16] Tempo de desenvolvimento
Identificação: [NFR-16] Tempo de desenvolvimento
Casos de Uso relacionados: Todos.
Descrição:
O tempo total para o desenvolvimento do sistema não
deverá ultrapassar em mais de 10% do cronograma
estimado no Estudo de Viabilidade.
Prioridade: Essencial Importante Desejável
6.3.2. [NFR-17] Orçamento
Identificação: [NFR17] Orçamento
Casos de Uso relacionados: Todos.
Descrição:
O custo total para o desenvolvimento do sistema não
deverá ultrapassar em mais de 10% do valor o estimado no
Estudo de Viabilidade.
Prioridade: Essencial Importante Desejável
7. Modelagem Organizacional
A modelagem organizacional utilizada é feita com base na notação i* (i estrela).
7.1. Modelagem de Dependência Estratégica
15
Figura 1 - Modelagem de Dependência Estratégica
7.2. Modelagem de Razão Estratégica
Figura 2 - Modelagem de Razão Estratégica
16
8. Modelagem de Requisitos Funcionais
Nessa seção, os requisitos funcionais descritos anteriormente são modelados
através de diagramas de caso de uso. O detalhamento dos casos de uso encontra-se no
Anexo E deste documento. Foi utilizada a ferramenta ASTAH® para a construção do
diagrama de caso de uso e utilizamos [Disciplina 6].
Figura 3 - Diagrama de Caso de Uso
17
9. Modelagem de Requisitos Não-Funcionais
Nessa seção, contém a modelagem dos requisitos não-funcionais utilizando o
framework NFR. Aqui ilustramos suas interdependências e operacionalizações. Na sua
construção, tivemos o auxílio de [Disciplina 3] e [Disciplina 4].
Figura 4 - Modelagem dos Requisitos Não funcionais
18
10. Conclusão
Através do documento de requisitos, foi possível entender, através de uma
breve descrição nas seções 1, 2 e 3, o problema a ser resolvido e em qual contexto o
nosso sistema, AIT, está inserido.
Antes da descrição dos requisitos e das modelagens, demonstramos, na seção
4, a organização da empresa com os seus objetivos e metas.
Em seguida foram apresentados, na seção 5, todos os requisitos funcionais do
sistema, isto é, todos os serviços que o AIT deve oferecer aos seus usuários, segundo a
definição do cliente.
Seguindo os requisitos funcionais, na seção 5 foram apresentados os requisitos
não-funcionais, que definem restrições de como o sistema deverá operar baseado em
seus requisitos funcionais.
Na seção 6, foi abordada a modelagem organizacional do sistema usando a
notação i*, em que foram incluídos os modelos de dependência estratégica (SD) e o
modelo estratégico de razão (SR) com os atores AIT, Supervisor e Agente.
Na seção 7, dando continuidade à modelagem de requisitos funcionais, através
do diagrama de casos de uso, foram descritos os casos de uso do sistema, incluindo
seus fluxos de eventos e dependências entre si.
Finalmente, na Seção 8, foi feita a modelagem dos requisitos não-funcionais
utilizando a plataforma NFR, mostrando os refinamentos deles, explicitando
operacionalizações e interdependências entre eles.
11. Relatório de Participação
Nome Esforço (%) Assinatura
Danilo Laurindo 25
Paulo Ferreira 25
Thyago Porpino 25
Wagner Barros 25
19
12. Referências
[Sommerville] G. Kotonya and I. Sommerville, Requirements Engineering : Processes and
Techniques , John Wiley & Sons, 1998.
[Disciplina 1] Slide Elicitação dos Requisitos (Cap. 3), Disciplina de Especificação de Requisitos
e Validação de Sistemas. Disponível em: <http://www.cin.ufpe.br/~if716>.
[Disciplina 2] Validação dos requistos (Cap. 4), Disciplina de Especificação de Requisitos e
Validação de Sistemas. Disponível em: <http://www.cin.ufpe.br/~if716>.
[Disciplina 3] Requisitos não funcionais (Cap. 8), Disciplina de Especificação de Requisitos e
Validação de Sistemas. Disponível em: <http://www.cin.ufpe.br/~if716>.
[Disciplina 4] Aula prática - NFR - Slides, Disciplina de Especificação de Requisitos e Validação
de Sistemas. Disponível em: <http://www.cin.ufpe.br/~if716>.
[Disciplina 5] i* Framework - Aula III, Disciplina de Especificação de Requisitos e Validação de
Sistemas. Disponível em: <http://www.cin.ufpe.br/~if716>.
[Disciplina 6] Modelagem de Caso de Uso, Disciplina de Especificação de Requisitos e
Validação de Sistemas. Disponível em: <http://www.cin.ufpe.br/~if716>.
20
Apêndice A – Descrição dos Casos de Uso
Identificador: [UC-01] Autenticar Usuário
Descrição: Requisita a autenticação do agente quando o mesmo tenta entrar no
sistema, de forma a não permitir acesso não autorizado. A autenticação é
feita com login e senha, logo após entrar no sistema, o agente é
requisitado a gravar sua assinatura.
Ator: Agente, Supervisor
Prioridade: Essencial
Pré-condições: Está na tela de autenticação
Pós-condições: Usuário autenticado
Fluxo de Eventos Principal
1. Usuário entra com o login e senha 2. Sistema autentica o usuário 3. Usuário assina na tela 4. Sistema entra na tela principal
Fluxo Secundário 1
1. No passo 1, o sistema verifica se o login existe e se a senha corresponde ao login 2. Caso ocorra algum erro, uma mensagem é exibida ao usuário, informando o ocorrido 3. O usuário apertar no botão “OK” para voltar à tela de autenticação
Requisitos Não Funcionais Específicos
21
Identificador: [UC-02] Inserir Auto de Infração
Descrição: Insere um auto de infração no banco de dados, gravando as seguintes
informações a respeito do veículo e da infração:
Número da placa e informações do veículo
Código da infração e descrição do código
Endereço do local da infração
Informação que indica caso houve um flagrante, em caso de
flagrante, o agente pode tirar fotos do veículo.
Ator: Agente
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Criação de um novo Auto de infração
Fluxo de Eventos Principal
1. Usuário seleciona opção “Auto de Infração” 2. Usuário seleciona opção “Inserir Auto de Infração” 3. Usuário informa os dados do auto de infração 4. Sistema registra auto de infração 5. Sistema questiona o usuário se ele deseja Tirar Foto do veículo autuado, caso o
usuário selecione “sim”, e ele entra no caso de uso Tirar Foto. 6. Sistema questiona o usuário se ele deseja ter assinatura do motorista autuado, caso o
usuário selecione “sim”, e ele entra no caso de uso Registrar Assinatura. 7. Sistema questiona o usuário se ele deseja imprimir o auto, caso o usuário selecione
“sim”, e ele entra no caso de uso de imprimir. 8. Sistema informa que a operação foi realizada com sucesso
Fluxo Secundário 1
1. No passo 4, se o sistema observar a falta de um dos dados essenciais (número da placa do veículo, código da infração e descrição do código, endereço do local da infração)
2. Uma mensagem é exibida ao usuário, detalhando o erro 3. O usuário apertar no botão “OK” para voltar à tela de inserir um auto
Requisitos Não Funcionais Específicos -
22
Identificador: [UC-03] Pesquisar Veículo
Descrição: Permitir a pesquisa de um veículo no banco de dados através do número
da placa do mesmo.
Ator: Agente
Prioridade: Essencial
Pré-condições: Usuário deve estar na tela principal
Pós-condições: Informações do veículo
Fluxo de Eventos Principal
1. Usuário seleciona opção “Pesquisar Veículo” 2. Usuário informa o número da placa do veículo 3. Sistema informa dados sobre o determina veículo
Fluxo Secundário 1
1. No passo 2, se o sistema verifica se existe determinada placa de veículo 2. Uma mensagem é exibida ao usuário informando 3. O usuário apertar no botão “OK” para voltar à tela pesquisar veículo
Requisitos Não Funcionais Específicos -
23
Identificador: [UC-04] Alterar Auto de Infração
Descrição: Permite que um auto de infração tenha alguns dos seus parâmetros
alterados. Tanto o auto de infração atualizado quanto o antigo devem ser
armazenados pelo sistema.
Ator: Agente, Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Auto de infração atualizado
Fluxo de Eventos Principal
1. Usuário seleciona opção “Auto de Infração” 2. Usuário seleciona opção “Alterar Auto de Infração” 3. Usuário informa o número do auto de infração, a placa do carro, data ou local 4. O sistema informa uma lista de autos de infração 5. Usuário seleciona o auto de infração a ser alterado 6. Usuário altera os dados do auto de infração 7. Sistema registra auto de infração como alterado e salva o novo auto de infração com
os dados alterados 8. Sistema questiona o usuário se ele deseja Tirar Foto do veículo autuado, caso o
usuário selecione “sim”, e ele entra no caso de uso Tirar Foto. 9. Sistema questiona o usuário se ele deseja ter assinatura do motorista autuado, caso o
usuário selecione “sim”, e ele entra no caso de uso Registrar Assinatura. 10. Sistema questiona o usuário se ele deseja imprimir o auto, caso o usuário selecione
“sim”, e ele entra no caso de uso de imprimir. 11. Sistema informa que a operação foi realizada com sucesso
Fluxo Secundário 1
1. No passo 4, se o sistema observar a falta de um dos dados essenciais 2. Uma mensagem é exibida ao usuário, detalhando o erro 3. O usuário apertar no botão “OK” para voltar à tela de alteração desse auto de infração
Requisitos Não Funcionais Específicos -
24
Identificador: [UC-05] Deletar Auto de Infração
Descrição: Permite que um auto de infração seja removido. O auto de infração
removido deve ser armazenados pelo sistema com status de deletado.
Ator: Agente, Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Auto de infração com status de Deletado
Fluxo de Eventos Principal
1. Usuário seleciona opção “Auto de Infração” 2. Usuário seleciona opção “Deletar Auto de Infração” 3. Usuário informa o número do auto de infração a placa do carro, data ou local 4. Sistema informa uma lista de autos de infração 5. Usuário seleciona o auto de infração a ser deletado 6. Usuário informa o motivo da remoção 7. Sistema registra auto de infração com o status de deletado e seu motivo 8. Sistema informa que a operação foi realizada com sucesso
Requisitos Não Funcionais Específicos -
25
Identificador: [UC-06] Buscar Auto de Infração
Descrição: Permitir a pesquisa de um auto de infração no banco de dados através do
número do auto de infração, da placa do carro, data ou local.
Ator: Agente, Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Visualização do dados do Auto de infração
Fluxo de Eventos Principal
1. Usuário seleciona opção “Auto de Infração” 2. Usuário seleciona opção “Buscar Auto de Infração” 3. Usuário informa o número do auto de infração, a placa do carro, data ou local 4. O sistema informa uma lista de autos de infração 5. Usuário seleciona o auto de infração a ser visualizado 6. Sistema informa os dados sobre o auto de infração selecionado
Requisitos Não Funcionais Específicos -
Identificador: [UC-07] Tirar foto do veículo
Descrição: Permite à captura e o armazenamento de uma foto do veículo autuado
caso houve o flagrante da infração.
Ator: Agente
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Foto armazenada junto com o auto de infração
Fluxo de Eventos Principal
1. Será mostrado ao usuário uma opção que permite que uma foto do veículo seja armazenada
2. Usuário seleciona a opção “Tirar Foto” para tirar a foto do veículo 3. Usuário seleciona a opção “Armazenar Foto” 4. Sistema confirma a operação e pergunta se vai quere tira mais uma foto
Requisitos Não Funcionais Específicos -
26
Identificador: [UC-08] Registrar assinatura
Descrição: Permitir o armazenamento da assinatura
Ator: Agente
Prioridade: Essencial
Pré-condições: O sistema ou usuário ter requisitado assinatura
Pós-condições: Assinaturas armazenadas junto com o auto de infração
Fluxo de Eventos Principal
1. Usuário faz a assinatura 2. Assinatura é armazenada 3. Sistema confirma a operação
Requisitos Não Funcionais Específicos -
Identificador: [UC-09] Imprimir multa
Descrição: Permitir a possibilidade da impressão de uma multa de trânsito logo após
o preenchimento de um auto de infração ou modificação.
Ator: Agente
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Multa foi impressa
Fluxo de Eventos Principal
1. Usuário seleciona a opção “Imprimir multa” 2. Multa é impressa
Requisitos Não Funcionais Específicos -
27
Identificador: [UC-10] Reimprimir multa
Descrição: Permitir a reimpressão de uma multa de uma infração que esteja no
banco de dados.
Ator: Agente
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Multa foi impressa
Fluxo de Eventos Principal
1. Usuário seleciona a opção “Reimprimir Multa” 2. Usuário realiza uma busca por um auto de infração no sistema 3. Usuário seleciona o auto de infração a ser visualizado. 4. Usuário seleciona a opção “reimprimir multa”. 5. Multa é impressa.
Requisitos Não Funcionais Específicos -
28
Identificador: [UC-11] Visualizar quantidade de multas.
Descrição: Permitir a visualização da quantidade de multas aplicadas pelo agente
que está requisitando o serviço em um determinado expediente de
trabalho.
Ator: Agente
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Multa foi imprimida
Fluxo de Eventos Principal
1. Usuário seleciona opção “Agente” 2. Usuário seleciona opção “Buscar Agente” 3. Usuário informa o número de registro ou nome do agente 4. O sistema informa uma lista de agentes 5. Usuário seleciona o agente a ser visualizado 6. Usuário seleciona opção “Visualizar Autos de Infração” 7. Usuário seleciona opção “Na Data...” 8. Usuário fornece a data do determinado expediente 9. O sistema fornece a lista com os autos de infração do agente naquele expediente
Requisitos Não Funcionais Específicos -
29
Identificador: [UC-12] Consultar Veículo estacionado.
Descrição: Checar através da placa do veículo, se ele possui permissão para
estacionar num local regulamentado.
Ator: Agente
Prioridade: Essencial
Pré-condições: Usuário deve estar autenticado pelo sistema
Pós-condições: Checagem de permissão foi feita
Fluxo de Eventos Principal
1. Usuário seleciona opção “Consultar Veículo estacionado” 2. Usuário fornece a placa do veículo 3. Sistema retorna o status do veículo no estacionamento
Requisitos Não Funcionais Específicos -
30
Identificador: [UC-13] Cadastrar Agente
Descrição: Permite que um supervisor cadastre um agente no sistema. O professor
adiciona as informações (nome, CPF, RG, sexo, data de nascimento, data
de admissão, salário, login, senha).
Ator: Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar na tela de agente
Pós-condições: Criação de um cadastro de agente
Fluxo de Eventos Principal
1. Usuário seleciona opção “Cadastrar Agente” 2. Usuário informa os dados do sobre o Agente 3. Sistema cadastra o agente 4. Sistema informa que a operação foi realizada com sucesso
Fluxo Secundário 1
4. No passo 3, se o sistema observar a falta de um dos dados essenciais 5. Uma mensagem é exibida ao usuário, detalhando o erro 6. O usuário apertar no botão “OK” para voltar à tela de cadastrar agente
Requisitos Não Funcionais Específicos -
31
Identificador: [UC-14] Remover Agente
Descrição: Permite que um determinado cadastro de um agente seja removido.
Ator: Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar na tela de agente
Pós-condições: Removido o cadastro do determinado agente
Fluxo de Eventos Principal
1. Usuário seleciona opção “Remover Agente” 2. Usuário informa nome ou CPF 3. Sistema informa o agente a ser removido e pede a confirmação do usuário 4. Usuário confirma a remoção 5. Sistema informa que a operação foi realizada com sucesso
Fluxo Secundário 1
1. No passo 2, se o sistema verificar se existe o agente 2. Uma mensagem é exibida ao usuário detalhando o erro, caso não exista o agente 3. O usuário apertar no botão “OK” para voltar à tela de remover agente
Requisitos Não Funcionais Específicos -
32
Identificador: [UC-15] Atualizar Agente
Descrição: Permite que um cadastro de um agente tenha seus dados alterados.
Ator: Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar na tela de agente
Pós-condições: Cadastro de Agente atualizado
Fluxo de Eventos Principal
1. Usuário seleciona opção “Atualizar Agente” 2. Usuário informa a nome ou CPF 3. Usuário informa os dados a ser alterado 4. Sistema salvo o cadastro do agente como os dados alterados 5. Sistema informa que a operação foi realizada com sucesso
Fluxo Secundário 1
1. No passo 2, o sistema verifica se o agente existe 2. Caso não exista, uma mensagem é exibida ao usuário, informando a inexistência 3. O usuário apertar no botão “OK” para voltar à tela de alteração do agente
Fluxo Secundário 2
1. No passo 3, o sistema verificar se o usuário escreveu os dados de forma correta e se não há ausência de algum dado essencial.
4. Uma mensagem é exibida ao usuário, detalhando o erro O usuário apertar no botão “OK” para voltar à tela de alteração do agente
Requisitos Não Funcionais Específicos
33
Identificador: [UC-16] Buscar Agente
Descrição: Permitir a pesquisa do cadastro de um determinado agente através do
nome ou CPF.
Ator: Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar na tela de agente
Pós-condições: Visualização dos dados sobre o agente
Fluxo de Eventos Principal
1. Usuário seleciona opção “Buscar Agente” 2. Usuário informa o nome ou CPF 3. O sistema informa os dados do determinado agente
Fluxo Secundário 1
1. No passo 2, se o sistema verificar se existe o agente 2. Uma mensagem é exibida ao usuário detalhando o erro, caso não exista o agente 3. O usuário apertar no botão “OK” para voltar à tela de Buscar agente
Requisitos Não Funcionais Específicos
34
Identificador: [UC-17] Gerar relatório estatístico.
Descrição: Permitir a geração de um relatório relatando estatisticamente a
ocorrência de infrações em um determinado período ou local.
Ator: Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar na tela Relatórios
Pós-condições: Geração de um relatório estatístico de infrações.
Fluxo de Eventos Principal
1. Usuário seleciona opção “Relatório Estatístico” 2. Usuário informa o período ou local 3. O sistema informa gera um relatório no formato PDF
Requisitos Não Funcionais Específicos
Identificador: [UC-18] Gerar relatório de Agentes.
Descrição: Permitir a geração de um relatório relatando as infrações registradas por
cada agente.
Ator: Supervisor
Prioridade: Essencial
Pré-condições: Usuário deve estar na tela Relatórios
Pós-condições: Geração de um relatório Infrações versus Agentes.
Fluxo de Eventos Principal
1. Usuário seleciona opção “Relatório Agente” 2. Usuário informa o período 3. O sistema informa gera um relatório no formato PDF
Requisitos Não Funcionais Específicos
35
Apêndice B – Técnicas Utilizadas na Coletas de Dados
Foram utilizadas três técnicas de coleta de dados: Questionário, Entrevista aberta e
Leitura de documentos [Disciplina 2]. As mesmas serão descritas a seguir.
Questionário
Questionário é uma técnica de investigação composta por um número relativamente
grande de questões apresentadas por escrito à pessoas que possuem conhecimento do
domínio, tendo por objetivo fornecer este conhecimento ao pesquisador. O questionário
aplicado à Manoel Damasceno, diretor de projeto da CTTU, encontra-se no Anexo B.
Entrevista Aberta
Técnica de coleta de dados que consiste numa entrevista informal com um ou vários
stakeholders, tendo por objetivo obter informações do sistema através de uma entrevista não
controlada, sem uma agenda pré-definida. O entrevistador conversa com o stakeholder sobre
o que o mesmo quer do sistema.
36
Apêndice C – Questionário
Serão apresentadas aqui, as perguntas que foram feitas no questionário que ajudou a
levantar os requisitos do sistema.
Fale um pouco sobre a CTTU e sua missão, assim como os resultados que organização
vem alcançando no trânsito de Recife.
Como é a rotina dos agentes de trânsito da CTTU?
Como a tecnologia poderia auxiliar o serviço desses agentes, evitar erros e melhorar o
rendimento no trabalho?
Como o sistema poderia evitar fraudes ou subornos aos agentes?
Que tipo de informações os guardas precisam anotar no talonário de multa?
Que tipo de dados deve ser automaticamente resgatado de um banco de dados a partir
da placa de um veículo?
Seria interessante registrar junto a infração provas de flagrante de infrações, como por
exemplo, fotos?
Como os supervisores podem acompanhar melhor o trabalho dos agentes, mensurando o
desempenho deles?
Como gerenciar toda essa informação e adquirir informações estatísticas de forma
eficaz?
37
Apêndice D – Glossário
AIT: Auto de infração de trânsito.
BPTRAN: Batalhão de Policiamento de Trânsito.
CTTU: Companhia de Trânsito e Transporte Urbano.
CTU: Companhia de Transporte Urbano.
CTUR: Companhia de Transporte Urbano do Recife.
DETRAN: Departamento de Trânsito.
EMTU: Empresa Metropolitana de Transportes Urbanos.
FR: Requisito Funcional.
GPS: Global Position System.
GUI: Graphic User Interface.
Login: Trata-se de uma seqüência de caracteres utilizada para identificar um usuário
de forma única.
NFR: Requisitos Não Funcionais.
Notação i*: Abordagem criada por John Mylopoulos e EricYu, na Universidade de
Toronto para descrição de requisitos organizacionais.
UC: Caso de Uso.
SCRUM: Metodologia de Desenvolvimento Ágil.
SQL : Structured Query Language.
38
Apêndice E – Convenções
Os requisitos, por convenção, são indicados e referenciados através de uma sigla
seguida de um número identificador. Dessa maneira, fica estabelecido que os requisitos
funcionais serão representados pelo formato [RF-xx], e os requisitos não funcionais, por sua
vez, possuirão a forma [NFR-xx], onde xx se refere ao número do requisito.
Os casos de uso do sistema serão indicados pela sigla UC (do inglês, Use Case) e um
número [UC-xx], onde xx se refere ao número do caso de uso.
A seguir, será apresentada a estrutura dos casos de uso e quais os tipos de prioridades
são encontrados nos casos de uso.