Especificação de Requisitos. Especificação de Requisitos e Validação de Sistemas

(1)

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)

(2)

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

(3)

2

Entrevista Aberta ... 35

Apêndice C – Questionário ... 36

Apêndice D – Glossário ... 37

(4)

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.

(5)

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

(6)

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

(7)

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

_[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

_[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

_[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

_[UC-06]

Descrição: Permitir a pesquisa de um auto de infração no banco de dados

(8)

7 local.

Prioridade:

 Essencial

 Importante

 Desejável

Identificação: [RF-07] Tirar foto do veículo

_[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

[UC-08]

Descrição: Permitir à captura e o armazenamento de assinaturas.

Prioridade:

 Essencial

 Importante

 Desejável

Identificação: [RF-09] Imprimir multa

_[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

_[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.

_[UC-11]

Descrição:

Permitir a visualização da quantidade de multas aplicadas por um agente em um determinado expediente de trabalho.

(9)

8

Prioridade:

 Essencial

 Importante

 Desejável

Identificação: [RF-12] Consultar Veículo estacionado.

_[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

_[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

_[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

_[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

[UC-16]

Descrição: Permitir a pesquisa do cadastro de um determinado agente através

(10)

9

Prioridade:

 Essencial

 Importante

 Desejável

Identificação: [RF-17] Gerar relatório estatístico.

_[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.

_[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

_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.

(11)

10

6.1.2. [NFR-02] Utilizar o banco de dados SQL Server

Identificação: [NFR-02] Utilizar o banco de dados SQL Server

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

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

_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

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}

(12)

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

_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

_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

_Todos.

Descrição:

Nenhuma das consultas feitas ao sistema deverá exceder

4.5 segundos.

(13)

12

6.2.1.2. [NFR-09] Espaço de armazenamento

Identificação: [NFR-09] Espaço de armazenamento

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

_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

_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

_Todos.

Descrição:

Cada tipo de usuário, agente e supervisor, só pode acessar

as informações e as funcionalidades a ele permitidas.

(14)

13

6.2.3. Manutenabilidade

6.2.3.1. [NFR-13] Modularidade

Identificação: [NFR-13] Modularidade

_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

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

_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.

(15)

14

6.3. Requisitos externos

6.3.1. [NFR-16] Tempo de desenvolvimento

Identificação: [NFR-16] Tempo de desenvolvimento

_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

_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).

(16)

15

Figura 1 - Modelagem de Dependência Estratégica

7.2. Modelagem de Razão Estratégica

(17)

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]

.

(18)

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].

(19)

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

(20)

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

(21)

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

(22)

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

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

(23)

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

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

(24)

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.

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.

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

(25)

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.

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

(26)

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.

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

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

(27)

26

Identificador: [UC-08] Registrar assinatura

Descrição: Permitir o armazenamento da assinatura

Ator: Agente

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

Pós-condições: Multa foi impressa

Fluxo de Eventos Principal

1. Usuário seleciona a opção “Imprimir multa” 2. Multa é impressa

(28)

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

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.

(29)

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

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

(30)

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

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

(31)

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

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

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

(32)

31

Identificador: [UC-14] Remover Agente

Descrição: Permite que um determinado cadastro de um agente seja removido.

Ator: Supervisor

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

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

(33)

32

Identificador: [UC-15] Atualizar Agente

Descrição: Permite que um cadastro de um agente tenha seus dados alterados.

Ator: Supervisor

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

(34)

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

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

(35)

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

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

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

(36)

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.

(37)

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?

(38)

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.

(39)

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.