Acsi M1 TP01 G1

LISTA DE MEMBROS DO GRUPO:
Maria Beatriz Garcez Morais – PG54038 Luana Filipa Alves Borges – PG54001
Guilherme José de Sousa Barbosa – PG53853

Simão Daniel da Silva Dias – PG54234
Raul Mendes de Castro Pinto – PG54172
2
ÍNDICE
CONTEXTO ....................................................................................................................................... 4
VISÃO - BRT (BUS RAPID TRANSIT) ......................................................................................... 5
1. INTRODUÇÃO .......................................................................................................................... 5
2. POSICIONAMENTO ................................................................................................................ 5
3. DESCRIÇÃO DOS STAKEHOLDERS .................................................................................. 7
4. VISÃO GERAL DO PRODUTO ............................................................................................. 9
5. OUTROS REQUISITOS DO PRODUTO .............................................................................10
SUPPORTING REQUIREMENTS SPECIFICATION - TUB ...................................................... 11
1. INTRODUÇÃO .......................................................................................................................... 11
2. REQUISITOS FUNCIONAIS DE TODO O SISTEMA ........................................................ 11
3. SYSTEM QUALITIES .............................................................................................................. 12
4. INTERFACES DO SISTEMA ................................................................................................. 15
5. BUSINESS RULES .................................................................................................................. 19
6. SYSTEM CONSTRAINTS...................................................................................................... 20
7. SYSTEM COMPLIANCE ....................................................................................................... 21
8. SYSTEM DOCUMENTATION .............................................................................................. 22
MODELO DE CASOS DE USO ................................................................................................... 23
CASOS DE USO ............................................................................................................................. 28
PACKAGE 0: GERIR O NEGÓCIO .......................................................................................... 28
PACKAGE 1: CONTROLAR BRT ............................................................................................ 40
UC2: VERIFICAR VALIDAÇÃO DO TÍTULO DE VIAGEM ................................................ 45
PACKAGE 3: VIAJAR ................................................................................................................ 47
PACKAGE 4: GERIR BRT .......................................................................................................... 61
ESTUDO DO MERCADO .............................................................................................................64
GLOSSÁRIO .................................................................................................................................... 67
CONCLUSÃO .................................................................................................................................. 70
3
CONTEXTO
Neste documento, pretendemos apresentar a proposta de projeto referente aos desafios
apresentados pelos Transportes Urbanos de Braga (TUB).
Assim, a nossa proposta, foca-se na introdução dos BRT (Bus Rapid Transit) na cidade de Braga
como meio de transporte urbano. A nossa proposta visa melhorar a acessibilidade e
conveniência do sistema atual, como a falta de informação em tempo real para o público e a
ineficiência do processo de obtenção de títulos de viagem.
Para o desenvolvimento desta proposta de requisitos, usamos vários artefactos de Technical

Specification do OpenUp como o Glossário, Visão, System-Wide Requeriments, Modelos de
Caso de Uso e Casos de Uso.
As técnicas usadas para representação de Casos de Uso e Modelos de Caso de Uso é a

Linguagem UML.
As técnicas usadas para extrair os requisitos foram:
→ Reunião com o cliente (duração de 7 minutos);
→ Uso do modelo do OpenUP;
→ Contacto com pessoas experientes no tema.
4
VISÃO - BRT (BUS RAPID TRANSIT)
1. INTRODUÇÃO
Este documento representa a visão dos stakeholders da solução técnica a ser desenvolvida.
Através desta definição, delineamos as necessidades-chave e as características fundamentais
que a solução deve abordar para atender às expectativas e requisitos dos envolvidos.
2. POSICIONAMENTO
2.1. DECLARAÇÃO DO PROBLEMA
Problema Braga é uma cidade com uma crescente procura por serviços de
transporte público, e atualmente, existem desafios significativos
relacionados à eficiência, acessibilidade e conveniência deste
sistema, como a falta de informação em tempo real para o público,
a ineficiência do processo de obtenção de títulos de viagem e
pagamento destes, bem como a necessidade de modernização.
Quem é afetado A direção e colaboradores da TUB e os passageiros.
Qual é o impacto Congestionamento de Tráfego: As pessoas optam por usar por usar
veículos particulares devido à falta de eficiência, acessibilidade e
conveniência dos meios disponíveis.
Impacto Ambiental: Aumento do uso de veículos particulares e de

títulos de viagem não digitais, contribuindo para a emissão de
poluentes e desperdício de recursos (papel).
Insatisfação dos Passageiros: A falta de informações em tempo real

e processos de obtenção de títulos de viagem e pagamento
ineficientes podem causar insatisfação entre os utilizadores do
transporte público o que leva a uma redução do número de
passageiros.
Solução Desenvolver uma aplicação que permite comprar títulos de viagem

online, consultá-los/usufruir dos mesmos digitalmente, validá-los,
assim como consultar em tempo real a localização dos BRT´s para
que os passageiros acompanhem o percurso das viaturas.
Implementar máquinas de compra de títulos de viagem na

paragem, bem como validadores.
Implementar câmaras nos BRT´s para o controlo de entrada e saída

de passageiros, para combater a fraude.
Tabela 1: Declaração do Problema
5
2.2. DECLARAÇÃO DA POSIÇÃO DO PRODUTO
Para Transportes Urbanos de Braga (TUB)
Que Tornar os serviços de Transporte Urbanos de Braga mais eficientes,

acessíveis, sustentáveis e convenientes para todos os cidadãos.
Nome do Produto BRTicket
Descrição [BRT] - Aplicação de gestão dos BRT’s, gestão de viagens e de títulos

de viagem.
Ao contrário de myRNE – Aplicação de transporte rodoviário de passageiros da Rede

Expressos, que permite a compra de títulos de viagem online e
digitais, a visualização das rotas e respetivos horários de partida e
chegada, bem como o acesso a informações sobre promoções,
descontos e ofertas especiais oferecidas pela empresa.
FLIX BUS – Aplicação de transporte rodoviário que também permite

a compra de títulos de viagem online e digitais, a visualização das
rotas e horários e descontos exclusivos.
O nosso produto Pensado, estruturado e desenvolvido de forma a tornar-se numa

solução completa e à medida do cliente. Destacamo-nos pela
disponibilização ao público da localização em tempo real dos BRT´s
e pelo um maior controlo das viaturas BRT para a direção da TUB.
Tabela 2: Declaração da Posição do Produto
6
3. DESCRIÇÃO DOS STAKEHOLDERS
3.1. RESUMO DOS STAKEHOLDERS
Nome Descrição Responsabilidades
Equipa de trabalho Grupo de pessoas que se Fornecer soluções viáveis;

encontra responsável por
Satisfazer as necessidades do
desenvolver a solução.
cliente;
Garantir a qualidade do projeto;

Definição de requisitos;
Desenvolvimento da
Arquitetura;
Conceção do protótipo;
Testar e Validar a solução.
Equipa Docente Professor responsável por Avaliar o desempenho da

lecionar a unidade equipa responsável de acordo
curricular de Análise e com os objetivos propostos e
Conceção de Sistemas de orientar o desenvolvimento do
Informação: Francisco projeto;
Duarte
Intermediário com o cliente.
TUB (Transportes Urbanos Empresa de transporte de Ajudar a especificar a solução;

de Braga) passageiros, que serve os
Treinar os utilizadores finais para
cidadãos do concelho de
a utilização da solução;
Braga, e vai
Monitorização do desempenho
utilizar/explorar a nossa
do sistema após
solução.
implementação.
Passageiros Utilizadores dos BRT Apresentar feedback em relação

à solução apresentada.
Principais utilizadores da
solução.
Neadvance Empresa de tecnologia, Fornecimento de recursos.

focada na Indústria 4.0
Formação da Equipa de
que desenvolve e controla
Trabalho na plataforma Niop
sistemas e máquinas
inteligentes.
Tabela 3: Stakeholders
7
3.2. AMBIENTE DO UTILIZADOR
Quantidade de pessoas envolvidas na conclusão da tarefa:
Os principais utilizadores envolvidos são os passageiros que vão utilizar o sistema de transporte
público BRT. O número de passageiros pode variar dependendo do horário e da rota. Para já
temos o conhecimento que irão passar, em cada paragem, um BRT entre 7 e 10 minutos e que
estes vão ter uma capacidade esperada de 130 passageiros. (18 metros de comprimento).
Ciclo de tarefa e tempo gasto em cada atividade:
O objetivo com esta integração é diminuir os tempos de espera tanto na entrada dos
transportes públicos como na compra dos títulos de viagem que neste momento é realizada à
entrada do transporte público. Este processo, demora assim, muito tempo pois é realizado de
forma manual, pelo motorista, e atrasa cada vez mais o transporte. Na nossa integração
também pretendemos controlar o número de pessoas que utilizam os transportes de forma a
combater a fraude, algo que neste momento não é realizado. Iremos também permitir ao
motorista criar alertas de atraso ou acidente.
Plataformas de sistema em uso hoje e no futuro:
Atualmente, os passageiros utilizam diferentes tipos de plataformas, entre elas os smartphones,

computadores pessoais e caixas de compra de títulos de viagem nas estações. Como
conseguimos prever, o uso de smartphones é, e vai ser, cada vez mais predominante à medida
que a tecnologia evolui para resolver os problemas da sociedade, tornando assim o uso deste
tipo de aplicações mais recorrente.
Outras aplicações em uso e integração necessária:
Atualmente a TUB tem ao dispor dos seus utilizadores a TUBmobile, uma aplicação que permite
apenas consultar horários, portanto muito rudimentar. Com a nossa implementação,
pretendemos integrar um mapa que permita aos utilizadores consultarem a localização dos
BRT’s em tempo real. Assim como um sistema de CCTV para fazer o controlo da lotação dos
passageiros.
8
4. VISÃO GERAL DO PRODUTO
4.1. NECESSIDADES E REQUISITOS
Necessidade Prioridade (1-5) Requisitos Lançamento

Planeado
Controlar a 4 Utilização da câmara CCTV para Versão 1

lotação dos BRT controlar a lotação do BRT para
perceber se os passageiros estão a
usufruir de forma correta do
transporte público (controlo de
fraude).
Desmaterializaçã 5 Representação dos títulos de Versão 1

o dos títulos de transporte numa aplicação de forma
transporte a aumentar a eficiência.
Sistemas 5 Comprar títulos de transporte de Versão 1

Integradores de forma rápida e segura com uma
Pagamentos variedade de métodos de
pagamento.
Bilheteria Digital 5 Comprar títulos de transporte de Versão 1

forma digital sem ter a necessidade
de recorrer a máquinas de venda de
títulos de viagem.
Sistema Self- 5 Comprar títulos de transporte Versão 1

Service recorrendo a máquinas de venda de
títulos de viagem.
Localização em 5 Representação da localização do BRT Versão 1

tempo real em tempo real.
Digital Twins 5 Representação em tempo real de um Versão 1

objeto físico, o BRT, num espaço
virtual.
Informação ao 5 Representação em tempo real de Versão 1

público diversas informações ao público tais
como horários, rotas, localização do
BRT, a sua lotação e se ocorreu
algum incidente.
Tabela 4: Necessidades e Requisitos
9
5. OUTROS REQUISITOS DO PRODUTO
Requisito Prioridade (1-5) Lançamento

Planeado
Cumprir padrões de segurança de dados 5 Versão 1
Garantir a suportabilidade dos diferentes 5 Versão 1

sistemas operativos
Garantir a usabilidade das soluções incorporada 4 Versão 1

para todos os utilizadores – aplicação intuitiva
Garantir a fiabilidade do Sistema 4 Versão 1
Garantir a precisão dos dados assim como a sua 5 Versão 1

relevância temporal
Disponibilidade – Sistema ativo 24h/dia 5 Versão 1
Apoio ao Cliente- Acompanhar o cliente e prestar 3 Versão 1

auxílio, se necessário
Tabela 5: Outros Requisitos
10
SUPPORTING REQUIREMENTS
SPECIFICATION - TUB
1. INTRODUÇÃO
Os requisitos de todo o sistema são requisitos que definem os atributos de qualidade do
Sistema necessários, como desempenho, segurança, usabilidade, confiabilidade, entre outros,
bem como requisitos funcionais globais que não são capturados em artefactos de requisitos
comportamentais como casos de uso.
2. REQUISITOS FUNCIONAIS DE TODO O SISTEMA

Os requisitos funcionais globais do sistema são todos aqueles requisitos do sistema que não
são expressos como casos de uso. Estes são:
Requisito Necessidade Descrição

Criar Conta Novo passageiro querer O sistema deve permitir a passageiros
criar conta. interessados na aplicação, criar um perfil
próprio, que lhe dará acesso aos
benefícios e ferramentas da mesma.
Autenticação Identificar se quem O sistema deve autenticar apenas pessoas
entra na aplicação é o com contas registadas. Com a existência
dono do perfil. do login, garantimos que apenas pessoas
autorizadas com acesso a credenciais
registadas é que conseguem aceder às
funcionalidades fulcrais (comprar títulos
de viagem, etc) do sistema.
Remover Conta Remover conta do O sistema deve permitir aos passageiros
passageiro na aplicação. eliminar a sua conta, previamente criada.
Inserir/Editar/Remover Saber mais informações O sistema deve permitir utilizador
Dados Pessoais sobre o utilizador. adicionar/atualizar/eliminar informações
sobre a sua conta. Exemplo: Método de
pagamento pré-definido.
Notificar Utilizadores Informar os utilizadores O sistema deve suportar notificações para
sobre eventos informar os utilizadores sobre eventos
importantes. importantes, atualizações ou mudanças
dentro do sistema. Essas notificações
podem ser entregues por e-mail,
notificações push ou outros canais
adequados.
Segurança e Criptografia de Assegurar a segurança O sistema deve implementar medidas de
Dados dos dados. segurança sólidas, incluindo criptografia
de dados (em trânsito e em repouso), para
proteger informações sensíveis do
utilizador e dados do sistema contra
acesso não autorizado ou violações
Backup e Recuperação de Evitar a perda de dados O sistema deve realizar regularmente
Dados críticos. backups de todos os dados críticos e
configurações. No caso de perda de dados
ou falha do sistema, deve existir um
processo de recuperação de dados bem
documentado e testado.
Tabela 6: Requisitos funcionais de todo o sistema
11
3. SYSTEM QUALITIES
Os sistemas de qualidade são requisitos utilizados para avaliar o desempenho do

sistema sendo estes a usabilidade, a fiabilidade, o desempenho, o suporte e a
segurança.
3.1. USABILIDADE
Para que o sistema seja considerado de boa usabilidade, este tem de ser fácil de usar. De tal
modo, existem alguns fatores importantes para garantir a usabilidade, tais como:
→ Após a primeira utilização da aplicação, o utilizador já deve dominar completamente o

sistema, independentemente da idade e da capacidade cognitiva. Para contribuir com uma
maior facilidade, o sistema deve utilizar imagens autoexplicativas. (ex: icon do caixote do lixo =
eliminar)
→ Os motoristas dos BRT’s, que em caso de avaria ou acidente devem ser capazes de alertar os
colegas motoristas e os passageiros gastando o menor tempo possível. Não deve demorar mais
do que 30s a ser executada, em condições normais de acesso à internet.
→ Os passageiros devem ser capazes de escolher o itinerário ou até mesmo comprar os títulos
de viagem, o mais rápido possível, para que não percam nenhuma viagem devido ao atraso do
sistema. Não deve demorar mais do que 30s a ser executada, em condições normais de acesso
à internet.
→ O utilizador tem de ser capaz de entender, de maneira fácil, as funcionalidades do sistema e

o que este faz. Para tal, a nossa solução será acompanhada de uma completa instrução de como
utilizá-la. A instrução deve ser curta e não deve demorar mais do que 10 minutos para ser lida e
compreendida.
→ O utilizador deve sentir-se satisfeito com a utilização do sistema. Logo, a classificação deve ser
igual ou superior a 4 estrelas no formulário de satisfação.
3.2. FIABILIDADE
A fiabilidade é definida como a probabilidade de um sistema operar sem falhas, num dado
ambiente e determinadas condições, durante um certo período de tempo.
→ O sistema deve estar disponível 24 horas por dia.
→ Deve existir uma equipa que preste suporte aos utilizadores, disponível a qualquer momento.
A equipa de suporte deve estar disponível 24horas por dia.
12
O sistema apresenta erros e estes são categorizados em “minor”, “significant” e “critical”
estando estes mencionados em ordem crescente de gravidade.
→ O sistema deve ser capaz de recuperar de uma falha:
Minor: Em menos de 15 minutos
Significant: Em menos de 10 minutos
Critical: Em menos de 5 minutos
→ O sistema deve efetuar backups diariamente e é preciso também garantir uma equipa de
funcionários com as competências e meios necessários para assegurar a reposição do sistema.
3.3. DESEMPENHO
Uma análise cuidadosa do desempenho é essencial para assegurar que nosso sistema atenda
às expectativas dos utilizadores e funcione de forma eficiente.
→ Os validadores devem validar os títulos de viagem em menos de 3s.
→ O tempo máximo para o pagamento em numerário nas MVA é de 1min.
→ O tempo para o envio do pedido de pagamento por MBWAY deve ser nó máximo 5s.
→ O sistema deve permitir que a compra do título de viagem na MVA deva ser realizada
em menos de 2min.
→ O sistema deve permitir que a compra do título de viagem digital na MVA deva ser
realizada em menos de 1min.
→ O sistema deve ser capaz de suportar o pagamento de viagens, em simultâneo de 2000
pessoas.
→ O sistema deve ser capaz de suportar 5 000 utilizadores em simultâneo, sem perder
performance.
→ O sistema deve ser capaz de contar 5 pessoas por segundo e por câmara.
→ O sistema deve ser capaz de contar o número de pessoas que entra e sai do BRT, em
simultâneo.
→ O tempo de atualizar a localização de cada BRT deve ser entre 0.5 e 1 segundos.
→ O tempo entre a notificação enviada pelo motorista em caso de incidente, e a receção
por parte dos passageiros, deve ser menor do que 5 segundos.
→ A internet deve ser distribuída uniformemente ao longo do BRT, (sem áreas
descobertas)
→ A velocidade de download e upload deve ser no mínimo de 25 Mbps.
13
3.4. SUPORTE
→ As MVA devem emitir um sinal de aviso para o sistema quando estão prestes a ficar sem
recursos (dinheiro, papel, tinteiro, cartões)
→ AS MVA após 30s de inatividade do passageiro devem cancelar o processo que estava em
curso e voltar para a interface inicial.
→ As MVA têm de ser compatíveis com RFID, terminais multibancos e enviar dados por wifi para
o sistema.
→ Os validadores devem ser compatíveis com RFID e QrCode, e enviar dados por wifi para o
sistema.
→ O sistema deve ser capaz de suportar o pagamento de viagens, em simultâneo de 2000
pessoas.
→ O sistema deve ser capaz de suportar 5 000 utilizadores em simultâneo, sem perder
performance.
→ O sistema deve ser capaz de contar 5 pessoas por segundo e por câmara.
→ As MVA devem estar instaladas em sítios estratégicos com condições específicas, tais como:
locais com rede, com vigilância, com um fluxo de pessoas que justifique a localização das
mesmas, entre outros.
→ Os passageiros podem interagir com as MVA através do touchscreen e/ou botões.
→ Os validadores devem estar instalados a uma distância máxima de 5 metros em relação ao
local de embarque.
→ Não existe qualquer restrição, nomeadamente restrições a nível geográfico. Qualquer
utilizador, independentemente da sua localização deve ser capaz de instalar e utilizar o sistema
sem qualquer restrição.
→ O sistema deve ser capaz de se adaptar às preferências e necessidades variadas dos
utilizadores.
→ Este sistema deve oferecer um suporte claro e acessível aos utilizadores, de maneira a ajudá-
los a compreender as diferentes funcionalidades disponíveis. Para tal, uma equipa de suporte
estará disponível 24 horas.
→ O sistema deve ser projetado para passar por atualizações e adaptações contínuas,
garantindo que esteja sempre alinhado com as necessidades em evolução dos utilizadores e
do mercado.
→ O sistema deve ser projetado para ser compatível em vários tipos de dispositivos
independentemente da sua versão e sistema operativo.
14
4. INTERFACES DO SISTEMA
4.1. INTERFACE DO UTILIZADOR
Descreve as interfaces de utilizador que devem ser implementadas pelo software. A intenção
desta secção é declarar os requisitos relacionados com a interface.
4.1.1. Look & Feel
A interface gráfica deve refletir o dinamismo dos BRT’s e, como tal, a conceção da solução
procura capturar a essência de conveniência, eficiência e modernidade.
O estilo da interface será minimalista, incorporando itens organizados e elementos visuais

intuitivos. Queremos que os utilizadores sintam instantaneamente a facilidade de utilização e
a simplicidade no uso.
A paleta de cores escolhida será uma fusão de tons vibrantes e elegantes, iguais ao do logotipo
da TUB, ou seja, o vermelho (#e40c1c) e o azul (#0c7cb4).
A interação será fluida e responsiva. A prioridade é a eficiência, garantir que os utilizadores

possam realizar as suas ações com poucos toques. Interações suaves e animações discretas
serão incorporadas para tornar a experiência mais envolvente. Considerando a diversidade de
dispositivos utilizados pelos utilizadores, a interface será totalmente adaptável, proporcionando
uma experiência consistente em smartphones, tablets e computadores.
No caso da interface dos motoristas, como vão estar a conduzir, a informação apresentada deve
ser legível a uma certa distância do monitor. Aconselha-se o uso de tablet, para uma melhor
visualização. Salienta-se que o aparelho deve estar fixo no BRT, exibindo uma dashboard, com
cores de fácil visualização, ao motorista relativa a dados das pessoas, do próprio BRT e da
viagem que está a ser realizada. A interação do motorista com o sistema, apenas pode ser
efetuada aquando da paragem do BRT.
15
4.1.2. Requisitos de Layout e Navegação
Interface MVA:
→ Área para adquirir títulos de viagem
→ Área para troca de títulos de viagem
→ Área para carregamento de passe
→ Área para pagamento
→ Área principal com o menu de funcionalidades
Interface aplicação:
A interface deve incluir o logotipo da empresa, uma barra de navegação que permita ao
utilizador exibir as principais áreas:
→ Área de LOGIN
→ Área de dados pessoais
→ Área de títulos de viagem
→ Área de horários em vigor
→ Área do mapa da localização dos BRT’s
4.1.3. Consistency
A interface do sistema deverá ser consistente e intuitiva. O utilizador deve ainda prever o
funcionamento do sistema.
O sistema deve seguir padrões de navegação consistentes em todas as seções da aplicação,

como o uso navbar principal sempre localizado no canto inferior da tela.
O sistema deve utilizar uma terminologia padrão ao longo da interface do utilizador para
garantir que os mesmos termos sejam usados consistentemente, evitando confusão entre os
utilizadores.
O sistema deve aderir a padrões amplamente reconhecidos, como o símbolo do MBWAY para
o pagamento e o "caixote de lixo" para excluir.
Todo o texto na interface do utilizador deve seguir um alinhamento consistente, seja à

esquerda, centralizado ou à direita, conforme apropriado.
16
O sistema deve adotar um esquema de cores consistente em toda a aplicação, garantindo que
as cores representem significados uniformes em todas as áreas. Como por exemplo, o verde
para a aprovação e vermelho para a rejeição.
Sempre que uma ação do utilizador resultar numa resposta do sistema (por exemplo, enviar
um formulário), o sistema deve fornecer feedback consistente, como uma mensagem de
confirmação na parte superior da tela.
4.1.4. Requisitos de Personalização do Utilizador
Nem todos os utilizadores do sistema vão ter acesso às mesmas funcionalidades, ao fazer o
login, a aplicação reconhece o tipo de utilizador em questão e, dependendo do perfil do mesmo,
apresenta um layout específico.
Irão existir, pelo menos, 4 tipos de utilizadores: passageiros, motoristas, fiscais e

administradores.
No caso de ser um passageiro, é possível consultar os dados pessoais e mergulhar no histórico

detalhado das viagens passadas. Também é possível fazer o planeamento do itinerário,
personalizando a viagem quando desejado. É possível fazer a escolha do itinerário, selecionar a
partida e o destino desejados, o método de pagamento e o acompanhamento em tempo real
do BRT.
É exibida uma lista com todas as opções para que possa escolher o BRT que melhor se adapta
ao seu horário de viagem. E quando desejar, a nossa plataforma permite não apenas a compra
de títulos de viagem ou passes, mas também a escolha do método de pagamento que mais lhe
convém. É possível acompanhar o BRT em tempo real no mapa e receber notificações sobre o
tempo estimado de chegada, se assim o desejar.
No caso de ser um motorista, a informação exibida deve basear-se nas informações do trajeto,
o número de paragens, a paragem seguinte do BRT, o número de kms percorridos, etc.
Informações dos passageiros, como por exemplo: quantos passageiros estão no BRT, quantos
passageiros vão entrar e sair na próxima paragem. E ainda informações do próprio BRT. Os
motoristas têm ainda a funcionalidade de iniciar e terminar viagens e reportar incidentes que
ocorram durante o trajeto.
Quando o fiscal recebe um aviso do sistema a informar que há uma possível fraude, este deve
dirigir-se ao BRT e efetuar a verificação de todos os títulos de viagem ou passes dos passageiros.
No caso de ser o administrador, este pode criar contas para novos motoristas e fiscais, pode
adicionar rotas e viaturas ao sistema e pode ver os dados de todos os BRT’s e de todos os
passageiros. Ao contrário dos motoristas que só conseguem visualizar as informações do BRT
onde se encontram.
17
4.2. INTERFACES TO EXTERNAL SYSTEMS OR DEVICES
4.2.1. Software Interfaces
A aplicação que vamos desenvolver irá interagir bastante com a base de dados, onde estarão
guardadas as informações de todos os utilizadores, títulos de viagem, BRT’s. Existe uma elevada
transação de dados entre o sistema e a base de dados.
A base de dados terá de ser capaz de guardar os dados, ao mesmo que tempo que os exporta
para a API. A API será responsável por fazer as queries à base de dados, conforme os diversos
pedidos do utilizador. Vamos ainda precisar de um software de contagens de pessoas, com
base em imagens em tempo real dos BRT’s.
4.2.2. Hardware Interfaces
→ Relativamente ao hardware, é necessário um servidor onde a base de dados possa correr, um

servidor para correr a API do sistema, e ainda outro para o sistema de contagem de pessoas.
→ Vamos precisar de hotspots (Wifi) em cada BRT e nas paragens para ser possível a troca de
dados com o servidor.
→ Nos BRT’s, vão ser instaladas câmaras (com acesso Wifi), para controlar o tráfego de pessoas.
→ É preciso também, Máquinas de Venda Automática, para serem colocadas nas paragens.
→ Para a validação de títulos de viagem, vamos precisar de validadores próprios nas paragens.
→ Os motoristas vão possuir tablets com informação de suporte ao BRT.
→ Os utilizadores poderão utilizar a aplicação em qualquer tipo de dispositivo móvel.
→ Os fiscais deverão estar equipados com dispositivos móveis que suportem a leitura de RFID e
códigos QR.
4.2.3. Communications Interfaces
Como o sistema tem de estar globalmente conectado entre si, vamos usar a Internet para
estabelecer a comunicação entre os sistemas. Para os Cartões RFID (viagens ocasionais) e
Cartões (passe), que vão ser usados por quem não utiliza o telemóvel, a comunicação será feita
por Radiofrequência nos validadores, e posteriormente dos validadores para o servidor, pela
internet.
Todo o sistema é interligado com o wi-fi incluindo os dispositivos dos motoristas, fiscais,
passageiros e o administrador, e também com as MVA’s e com os validadores.
18
5. BUSINESS RULES
Títulos de Viagem
Unicidade do Cartão: O cartão é único por passageiro.
Validação do Título: Passageiros só podem validar o título após a aquisição.
Carregamento do Passe: Passageiros só podem validar se o passe estiver carregado.
Acesso ao BRT: Passageiros só podem entrar no BRT após validação do título ou passe.
Visualização de BRTs: Passageiros veem em tempo real apenas os BRTs do seu trajeto.
Variação de Preços: Preços variam por coroa da viagem e idade dos passageiros.
Tempo de Validade: Validação deve ocorrer no máximo 15 minutos antes da passagem do BRT.
Oferta de Pack: Compra de pack de 10 títulos oferece um título adicional.
Restrição RFID: Cartão RFID só pode ser carregado com um tipo de viagem.
Compra Móvel: Passageiros com telemóvel podem comprar vários tipos de títulos com
diferentes coroas.
Tempo entre Validações: Novo desconto só após tempo máximo permitido após 1ª validação.
Reutilização do Título: Passageiros podem fazer várias viagens com mesmo título dentro dos
limites definidos.
BRT
Registo de Incidentes: Motoristas devem registar incidentes.
Registo de Trajeto: Motoristas indicam hora de início e fim do trajeto.
Limite de Passageiros: Número máximo de passageiros no BRT.
Variação de Horários: Horários do BRT podem variar consoante dia da semana.
19
6. SYSTEM CONSTRAINTS
Restrições de linguagens de implementação
Parte da solução tem de ser desenvolvida na plataforma Niop (Plataforma de low code da
Neadvance)
Restrições de Hardware
Os equipamentos de Hardware, como por exemplo as câmaras devem ser adquiridas

exclusivamente à Neadvance.
As estações devem estar munidas com MVA e com Validadores.
Os fiscais devem estar equipados com dispositivos que permitam a leitura de RFID e QR code.
Restrições de Comunicações
O sistema deve estar em constante ligação à internet, uma vez que, é composto por vários
componentes diferentes, em constante troca de dados. Sem ligação à internet, pode haver
possíveis perdas de dados.
Os BRT’s têm de ter acesso à internet.
As MVA’s devem ler os títulos de viagem.
Os validadores devem validar os títulos de viagem.
Restrições de Pagamento
O pagamento por telemóvel deve ser por MBWAY ou Multibanco.
O pagamento nas MVA deve ser por MBWAY, numerário ou terminal de multibanco.
Restrições de Design
O sistema deve respeitar as cores da TUB, que consistem no vermelho (#e40c1c) e no azul
(#0c7cb4).
Além disso, na interface do motorista, os botões devem ser grandes e com cores apelativas,
para que, aquando da utilização, este não demore muito tempo.
Restrições de Terceiros
Como restrições de terceiros podemos encontrar o NeAdvance e a Universidade do Minho. Se

um dos nossos parceiros, desistir do projeto, vamos enfrentar restrições.
Restrições de Limites de Recursos
20
Para o planeamento e execução deste projeto, a equipa é constituída unicamente por 5
elementos.
Cada elemento apenas deve despender de 140 horas de trabalho na execução deste trabalho.
7. SYSTEM COMPLIANCE
7.1. LICENSING REQUIREMENTS
O sistema terá de funcionar em conformidade com as regras e limites impostos pelos canais
de comunicação com os quais irá colaborar. O sistema não poderá interferir com a dignidade
dos utilizadores; Para o desenvolvimento deste sistema serão necessárias licenças de Visual
Paradigm, Neadvance, Office 365.
7.2. LEGAL, COPYRIGHT, AND OTHER NOTICES
Todos os direitos de propriedade intelectual e patentes deste projeto estão protegidos e

reservados ao grupo 1 da UC de Análise e Conceção de Sistemas de Informação, alusivo ao curso
de Mestrado em Engenharia e Gestão de Sistemas de Informação.
Aqui declaramos que, durante todo o desenvolvimento e posterior utilização da aplicação,

encontrar-se-á prezado o Regulamento Geral sobre a Proteção de Dados.
7.3. APPLICABLE STANDARDS
Regulamento Geral sobre a Proteção de Dados (RGPD). A legalidade do sistema está garantida
na Constituição da República Portuguesa, artigo 35º, parágrafo 4: “É proibido o acesso a dados
pessoais de terceiros, salvo em casos excecionais previstos na lei”.
Lei n.º 28/2006, de 04 de Julho
TRANSGRESSÕES EM TRANSPORTES COLECTIVOS DE PASSAGEIROS (versão atualizada)
https://www.pgdlisboa.pt/leis/lei_mostra_articulado.php?nid=862&tabela=leis&so_miolo=
Lei n.º 95/2021 de 29 de dezembro
Regula a utilização e o acesso pelas forças e serviços de segurança e pela Autoridade Nacional
de Emergência e Proteção Civil a sistemas de videovigilância para captação, gravação e
tratamento de imagem e som, revogando a Lei n.º 1/2005, de 10 de janeiro
https://diariodarepublica.pt/dr/detalhe/lei/95-2021-176714548
21
8. SYSTEM DOCUMENTATION
Deve ser disponibilizada uma documentação abrangente para orientar os utilizadores nas
funcionalidades do sistema. Esta deve incluir instruções claras sobre a instalação, configuração
e casos de uso comuns.
Deve ser implementado um sistema de ajuda intuitivo e acessível dentro da interface do

software. Este deve estar bastante organizado para permitir aos utilizadores encontrar
informações relevantes para a tarefa atual.
Além disso, deverão ser definidos avisos ou mensagens de ajuda que auxiliem os utilizadores
na compreensão de funcionalidades específicas, em momentos oportunos, como por exemplo
aquando da criação de conta ou no momento do primeiro login.
Concluindo, a documentação deve ser clara, concisa, orientada para o utilizador final e deve ser
mantida atualizada para refletir alterações no sistema. A equipa de desenvolvimento de
software será responsável por realizar toda esta documentação do sistema.
22
MODELO DE CASOS DE USO
Neste artefacto é apresentada uma visão geral do comportamento pretendido do sistema.
Desta forma, vão ser usados diagramas de caso de uso, que são representações gráficas dos
casos de uso e servem para representar as principais funcionalidades do sistema, casos de uso,
e a relação com os atores do sistema.
Vai ser apresentado um modelo geral, neste modelo vai existir um maior grau de abstração
partindo-se depois para modelos mais específicos e com maior grau de detalhe.
No nosso sistema é possível identificar os seguintes atores Administrador, Fiscal, Motorista,

Passageiro e o Sistema (que representa todo o software que vai ser desenvolvido para suportar
a nossa solução).
Figura 1: Modelo de Caso de Uso BRT (Geral)
23
P0: GERIR NEGÓCIO
Este modelo de caso de uso agrupa todos os casos de uso que pertencem á área de Gerir o
negócio, que maioritariamente interage com o administrador. Representa então as
funcionalidades típicas do “Backoffice” (ex: Consultar, Listar, Editar, Eliminar, etc).
Figura 2: Modelo de caso de uso: Gerir o negócio
24
P1. CONTROLAR BRT
Este modelo de caso de uso contempla casos de uso que estão única e exclusivamente
relacionados com o sistema. Destas pode-se realçar o Alertar Fraude, onde o sistema realiza
todo o exercício associado a alertar um fiscal de uma fraude.
Figura 3: Modelo de caso de uso: Controlar BRT
25
P3. VIAJAR
Este modelo de caso de uso representa o core da nossa proposta sendo que aqui estão
presentes a maioria dos casos de uso e os mais importantes também. Tais como Adquirir Título
de Viagem, Validar Título de Viagem, Trocar Título de Viagem etc.
Figura 4: Modelo de caso de uso: Viajar
26
P4: GERIR BRT
Neste caso de uso estão descritos a maioria dos casos de uso que interagem com o motorista.
Tais como Consultar Viagens Alocadas, onde o motorista consulta a viagem a que foi alocado
ou Reportar Incidente, onde o motorista consegue os passageiros presentes no BRT ou que
pretendiam entrar (nas próximas paragens) de algum tipo de incidente com o BRT.
Figura 5: Modelo de caso de uso: Gerir BRT
27
CASOS DE USO
PACKAGE 0: GERIR O NEGÓCIO
UC0.0: CONSULTAR MAPA DOS BRT’S
1. Breve Descrição
Este caso de uso descreve o processo pelo qual o administrador consulta, em tempo
real, a localização dos BRT's (Bus Rapid Transit) num mapa.
2. Breve Descrição dos atores

2.1. Administrador: Representa o utilizador com permissões de visualizar a localização
de todos os BRT's em tempo real.
3. Pré-condições
• O utilizador deve ter permissões de administrador para consultar a localização em
tempo real dos BRT's.
• Os BRT's devem estar equipados com sistemas de localização para fornecer
localizações em tempo real.
4. Fluxo básico de eventos

i. O administrador inicia o processo de consulta do mapa em tempo real dos BRT's.
ii. O sistema obtém as informações de localização em tempo real dos BRT's disponíveis.
iii. O sistema exibe um mapa mostrando a posição atual de cada BRT em tempo real.
5. Fluxos alternativos
5.1 Dados de Localização Indisponíveis:
Se os dados de localização em tempo real dos BRT's não estiverem disponíveis, o sistema
notifica o administrador e fornece informações sobre o problema.
6. Subfluxos
6.1. Opções de Visualização:
O sistema oferece opções de visualização no mapa, como zoom e filtros para melhorar a
experiência do administrador.
7. Cenários Principais
7.1 Mapa Atualizado em Tempo Real:
O administrador visualiza o mapa que apresenta a posição atualizada em tempo real de cada
BRT.
8. Pós-Condições
8.1. O administrador consulta com sucesso o mapa em tempo real dos BRT's.
28
8.2. O mapa é exibido com as posições atualizadas dos BRT's.
8.3 O administrador não consegue visualizar com sucesso o mapa em tempo real dos
BRT’s.
8.4 O mapa não é exibido com as posições atualizadas dos BRT’s.
9. Requisitos Especiais
9.1. Sistemas de Rastreamento:
Os BRT's devem estar equipados com sistemas de localização para fornecer dados em tempo
real.
29
UC0.1: CONSULTAR LISTA DE TÍTULOS VIAGENS
Este caso de uso descreve o processo pelo qual o administrador consulta todas
viagens do sistema.

2.1. Administrador: Representa o utilizador com permissões para consultar viagens.
3. Pré-condições
• O utilizador deve ter permissões de administrador para consultar viagens do
sistema.
• Têm de existir viagens para este poder ter acesso às mesmas.

i.O administrador inicia o processo de consulta de viagens.
ii.O sistema apresenta uma interface com as viagens disponíveis.
iii.O administrador visualiza os dados apresentados.
5.1 Escolher viagens
O administrador pode escolher visualizar viagens dentro de certos parâmetros tais
como (ex: por utilizador, por hora, por zona, estado, etc).
6. Subfluxos
O sistema oferece opções de visualização das viagens existentes como filtros para
melhorar e facilitar a experiência do utilizador.
7.1. Consulta Bem-Sucedida:
O administrador consulta com sucesso os títulos de viagens apresentados no
sistema.
8. Pós-Condições
8.1. O administrador consulta com sucesso os títulos de viagens.
8.2. O administrador não consulta com sucesso os títulos de viagens.
9.1. Integridade de Dados
Os dados pessoais dos títulos de viagem devem ser omitidos.
30
UC0.2: LISTAR, ADICIONAR, EDITAR E ELIMINAR VIATURAS
Este caso de uso descreve o processo pelo qual o administrador lista, adiciona, edita e
elimina viaturas.

2.1. Administrador: Representa o utilizador com permissões para listar, adicionar, editar
e eliminar viaturas.
3. Pré-condições
O utilizador deve ter permissões de administrador para listar, adicionar, editar e/ou eliminar
viaturas do sistema.
Para listar, eliminar e editar viaturas estas têm de ser inseridas previamente no sistema pelo
administrador.

i. O administrador inicia o processo de listar, adicionar, editar e/ou eliminar viaturas.
ii. O sistema apresenta uma interface para:
Apresentar as viaturas disponíveis;
Adicionar viatura;
Eliminar viatura;
Editar viatura.
iii. O administrador visualiza os dados apresentados/ adiciona a viatura/edita os dados da
viatura/ elimina a viatura.
5.1 Viatura já existente:
Se a viatura que o administrador está a tentar registar já se encontra registado o
sistema notifica o administrador.
5.2 Escolher viatura:
O administrador pode escolher visualizar uma viatura dentro de certos parâmetros
tais como (ex: id de BRT, etc).
5.3 Cancelamento da eliminação:
Se o administrador decidir não eliminar a viatura, o processo é cancelado.
6. Subfluxos
O sistema oferece opções de visualização das viaturas existentes.
6.2. Atualização de Campos Específicos para a viatura:
31
O administrador pode escolher atualizar informações específicas, como a rota da
viatura.
6.3. Confirmação Adicional:
Antes da eliminação final, o sistema pode solicitar uma confirmação adicional por
parte do administrador para evitar eliminações acidentais.
O administrador consulta com sucesso as viaturas registadas no sistema.
7.2. Edição Bem-Sucedida:
O administrador edita com sucesso os detalhes da viatura.
7.3. Registo Bem-Sucedido:
O administrador adiciona com sucesso a viatura.
7.4. Eliminação Bem-Sucedida:
O administrador elimina com sucesso a viatura.
8. Pós-Condições
8.1. O administrador consulta com sucesso a viatura.
8.2. O administrador edita com sucesso a viatura.
8.3. O administrador elimina com sucesso a viatura.
8.4. O administrador adiciona com sucesso a viatura.
8.5. O administrador não consulta com sucesso a viatura.
8.6. O administrador não edita com sucesso a viatura.
8.7. O administrador não elimina com sucesso a viatura.
8.8. O administrador não adiciona com sucesso a viatura.
A confirmação adicional é uma camada de segurança para evitar eliminações
acidentais.
32
UC0.3: LISTAR, ADICIONAR, EDITAR E ELIMINAR ROTAS
Este caso de uso descreve o processo pelo qual o administrador lista, adiciona, edita e
elimina rotas.

2.1. Administrador: Representa o utilizador com permissões para listar, adicionar, editar
e eliminar rotas.
3. Pré-condições
• O utilizador deve ter permissões de administrador para listar, adicionar, editar
e eliminar rotas registadas no sistema.
• Para listar, eliminar e editar rotas estas têm de ser inseridas previamente no
sistema pelo administrador.

i. O administrador inicia o processo de listar, adicionar, editar e eliminar rotas.
Apresentar as rotas disponíveis;
Adicionar rota;
Eliminar rota;
Editar rota.
iii. O administrador visualiza os dados apresentados/ adiciona a rota/edita a rota/ elimina
a rota.
5.1 Escolher rota
O administrador pode escolher visualizar uma rota dentro de certos parâmetros tais
como (ex: pelo modelo, id de BRT, etc.).
Se o administrador decidir não eliminar a rota, o processo é cancelado.
6. Subfluxos
O sistema oferece opções de visualização das rotas existentes.
6.2. Atualização de Campos Específicos para a rota:
O administrador pode escolher atualizar informações específicas, como a viatura
associada á rota.
33
O administrador consulta com sucesso as rotas registadas no sistema.
O administrador edita com sucesso os detalhes da rota.
7.3. Adição Bem-Sucedida:
O administrador adiciona com sucesso a rota.
O administrador elimina com sucesso a rota.
8. Pós-Condições
8.1. O administrador consulta com sucesso a rota.
8.2. O administrador edita com sucesso a rota.
8.3. O administrador elimina com sucesso a rota.
8.4. O administrador adiciona com sucesso a rota.
8.5. O administrador não consulta com sucesso a rota.
8.6. O administrador não edita com sucesso a rota.
8.7. O administrador não elimina com sucesso a rota.
8.8. O administrador não adiciona com sucesso a rota.
acidentais.
34
UC0.4: LISTAR, ADICIONAR, EDITAR E ELIMINAR MOTORISTAS
Este caso de uso descreve o processo pelo qual o administrador lista, adiciona, edita
e/ou elimina motoristas.

2.1. Administrador: Representa o utilizador com permissões para listar, adicionar,
editar e eliminar motoristas do sistema.
2.2. Motorista: Representa o utilizador com permissões apenas de editar.
3. Pré-condições
• O utilizador deve ter permissões de administrador para listar, adicionar, editar e
eliminar motoristas do sistema.
• Para listar, eliminar e editar motoristas estes têm de ser inseridos previamente no
sistema pelo administrador.

i. O administrador inicia o processo de listar, adicionar, editar e/ou eliminar motoristas.
Apresentar os motoristas disponíveis;
Adicionar motorista;
Eliminar motorista;
Editar motorista.
iii. O administrador visualiza os dados apresentados/ adiciona a motorista/edita os dados
do motorista/ elimina o motorista.
5.1 Motorista já existente:
Se o motorista que o administrador está a tentar registar já se encontra registado o
5.2 Escolher motorista:
O administrador pode escolher visualizar um motorista dentro de certos parâmetros
tais como (ex: pelo nome, id de Motorista, etc).
Se o administrador decidir não eliminar o motorista, o processo é cancelado.
6. Subfluxos
O sistema oferece opções de visualização dos motoristas já registados.
6.2. Atualização de Campos Específicos do motorista:
35
O administrador pode escolher atualizar informações específicas, como o BRT
associado ao motorista.
7.1. Registo Bem-Sucedida:
O administrador regista com sucesso o motorista no sistema e este tem acesso ao
mesmo.
O administrador elimina com sucesso o motorista do sistema e este deixa de ter
acesso ao mesmo.
O administrador consulta com sucesso os motoristas registados no sistema.
O administrador edita com sucesso os detalhes do motorista.
8. Pós-Condições
8.1. O administrador regista com sucesso um motorista.
8.2. O administrador elimina com sucesso um motorista.
8.3. O administrador consulta com sucesso a viatura.
8.4. O administrador edita com sucesso a viatura.
8.5. O administrador não regista com sucesso um motorista.
8.6. O administrador não elimina com sucesso um motorista.
8.7. O administrador não consulta com sucesso a viatura.
8.8. O administrador não edita com sucesso a viatura.
acidentais.
36
UC0.5: LISTAR, ADICIONAR, EDITAR E ELIMINAR FISCAIS
Este caso de uso descreve o processo pelo qual o administrador lista, adiciona, edita
e/ou elimina fiscais.

2.1. Administrador: Representa o utilizador com permissões para listar, adicionar,
editar e eliminar motoristas do sistema.
2.2. Fiscal: Representa o utilizador com permissões apenas de editar.
3. Pré-condições
• O utilizador deve ter permissões de administrador para listar, adicionar, editar e
eliminar fiscais do sistema.
• Para listar, eliminar e editar fiscais estes têm de ser inseridos previamente no sistema
pelo administrador.

i. O administrador inicia o processo de listar, adicionar, editar e/ou eliminar fiscais.
Apresentar os fiscais disponíveis;
Adicionar fiscal;
Eliminar fiscal;
Editar fiscal.
iii. O administrador visualiza os dados apresentados/ adiciona a fiscal/edita os dados do
fiscal/ elimina o fiscal.
5.1. Fiscal já existente:
Se o fiscal que o administrador está a tentar registar já se encontra registado o
5.2. Escolher fiscal:
O administrador pode escolher visualizar um fiscal dentro de certos parâmetros tais
como (ex: pelo nome, id de Fiscal, etc).
Se o administrador decidir não eliminar o fiscal, o processo é cancelado.
6. Subfluxos
O sistema oferece opções de visualização dos fiscais já registados.
6.2. Atualização de Campos Específicos do fiscal:
37
O administrador pode escolher atualizar informações específicas, como o dispositivo
associado ao fiscal.
7.1. Registo Bem-Sucedida:
O administrador regista com sucesso o fiscal no sistema e este tem acesso ao mesmo.
O administrador elimina com sucesso o fiscal do sistema e este deixa de ter acesso ao
mesmo.
O administrador consulta com sucesso os fiscais registados no sistema.
O administrador edita com sucesso os detalhes do fiscal.
8. Pós-Condições
8.1. O administrador regista com sucesso um fiscal.
8.2. O administrador elimina com sucesso um fiscal.
8.3. O administrador consulta com sucesso um fiscal.
8.4. O administrador edita com sucesso um fiscal.
8.5. O administrador não regista com sucesso um fiscal.
8.6. O administrador não elimina com sucesso um fiscal.
8.7. O administrador não consulta com sucesso um fiscal.
8.8. O administrador não edita com sucesso um fiscal.
acidentais.
38
UC0.6: ALOCAR VIAGENS AO MOTORISTA
Este caso de uso descreve o processo pelo qual o administrador aloca viagens aos
motoristas.

2.1. Administrador: Representa o utilizador com permissões de alocar viagens ao
motorista.
2.2. Motorista: Representa o utilizador que lhe vai ser alocado as viagens.
2.3. Sistema: Responsável por alocar os motoristas disponíveis às viagens e notificar
estes.
3. Pré-condições
• O utilizador deve ter permissões de administrador para alocar viagens aos motoristas.
• O motorista deve ter disponibilidade de horário.

i. O administrador inicia o processo de alocação de viagens ao motorista.
ii. O sistema exibe a lista de viagens disponíveis.
iii. O administrador seleciona a viagem.
iv. O administrador seleciona o motorista, a partir da lista de motoristas disponíveis.
v. O sistema aloca a viagem ao motorista escolhido.
vi. O sistema notifica o motorista.
vii. O motorista confirma.
viii. O motorista fica alocado.
5.1 Motorista recusa a viagem
O motorista recusa a viagem por qualquer motivo, como conflitos de agenda ou falta
de interesse na viagem.
O sistema notifica o administrador da recusa do motorista e permite que este aloque a
viagem para outro motorista disponível.
7.1 O administrador aloca viagens aos motoristas.
8. Pós-Condições
8.1. O administrador aloca com sucesso o motorista à viagem.
8.2. O administrador não aloca com sucesso o motorista à viagem.
39
PACKAGE 1: CONTROLAR BRT
UC1.0: ALERTAR FRAUDES
Este caso de uso descreve o processo pelo qual o sistema alerta fraudes
às autoridades competentes(fiscal).

2.1. Fiscal: Representa o utilizador com permissões para verificar se a viagem do
passageiro foi validada.
2.2. Sistema: Representa todo o hardware e software responsável pelo funcionamento
da solução.
3. Pré-condições
• O utilizador deve ter permissões de fiscal para poder ser informado pelo sistema de
fraudes.
• O sistema de controlo de entradas e saídas do BRT deve estar a funcionar
corretamente.

i. O sistema calcula o rácio entre a lotação efetiva do BRT e o número de validações
efetuadas.
ii. Se o rácio for superior a 30%, o sistema inicia o processo de alertar uma fraude.
iii. O sistema envia uma notificação para o fiscal mais perto do BRT, avisando-o de
uma possível fraude.
5.1 O sistema não conseguir calcular o rácio
No caso de o sistema não ser capaz de calcular o rácio, deverá ser enviada
uma notificação para todos os fiscais, informando do erro.
5.2 O rácio é inferior a 30%
O sistema não envia notificação para o fiscal.
6. Subfluxos
6.1. Alertar o Administrador:
O sistema envia todas as notificações do alerta de fraude para o administrador e os
respetivos detalhes (Viagem, Fiscal Associado, BRT).
7.1. Alerta de fraude bem-sucedido:
O sistema alerta com sucesso os ficais sobre a fraude.
40
8. Pós-Condições
8.1. O sistema alerta a fraude com sucesso.
8.2. O sistema não alerta a fraude com sucesso.
9.1. Segurança:
A consulta de dados de localização do fiscal deve ser protegida para garantir a
privacidade e a segurança do mesmo.
41
UC1.1: CONTROLAR A LOTAÇÃO DO BRT
Este caso de uso descreve o processo de contagem de entrada e saída de passageiros
no BRT, através das câmaras instaladas no mesmo.

da solução.
2.2. Câmara CCTV: Responsável capturar todos os passageiros que entram e saem do
BRT.
3. Pré-condições
• As câmaras apontadas para as portas de embarque/desembarque.
• As câmaras estão a funcionar devidamente e conectadas ao sistema.

i. O passageiro entra/sai do BRT.
ii. A câmara grava o seu movimento.
iii. A câmara envia as imagens para o sistema.
iv. O sistema lê as imagens.
v. O sistema rastreia o movimento do passageiro e conclui se se trata de uma
entrada ou saída.
vi. O sistema adiciona/remove o número de pessoas presentes no BRT.
vii. O sistema descarta os dados recebidos pela câmara.
5.1 A câmara falha e não comunica as imagens.
O sistema não consegue contabilizar as entradas e saídas.
O sistema comunica um alerta para o administrador.
7.1. O sistema adiciona/remove o número de pessoas presentes no BRT, em cada
viagem.
8. Pós-Condições
8.1. Sucesso na contagem dos passageiros.
8.2. A câmara continua a emitir imagens para o sistema.
8.3. O sistema continua a contabilizar entradas e saídas do BRT.
8.2. Insucesso na contagem dos passageiros.
42
9.1. Ligação ao sistema:
A câmara deve estar sempre em comunicação com o sistema.
43
UC1.2: ENCONTRAR FISCAL MAIS PRÓXIMO
Este caso de uso descreve o processo pelo qual o sistema encontra o Fiscal mais
próximo.

da solução.
3. Pré-condições
• O sistema tem acesso à localização dos fiscais e do BRT.

i. O sistema compara a localização de todos os fiscais disponíveis com a localização
do BRT.
ii. O sistema calcula a distância entre os fiscais e o BRT.
iii. O sistema encontra o fiscal mais próximo do BRT.
5.1 O sistema não consegue calcular a distância
O sistema seleciona um fiscal aleatoriamente.
5.2 O sistema encontra fiscais com a mesma proximidade:
O sistema seleciona um fiscal aleatoriamente.
7.1. O sistema encontra um fiscal mais próximo.
8. Pós-Condições
8.1. O sistema encontra um fiscal mais próximo com sucesso.
8.2. O sistema não encontra um fiscal mais próximo.
9.1. Segurança:
A consulta de dados de localização do fiscal deve ser protegida para garantir a
privacidade e a segurança do mesmo.
44
UC2: VERIFICAR VALIDAÇÃO DO TÍTULO DE VIAGEM
Este caso de uso descreve o processo em que o fiscal verifica a validação dos títulos de
viagem dos passageiros no BRT.

2.1. Fiscal: Representa o utilizador com permissões para verificar se a viagem do
passageiro foi validada.
2.2. Leitor de títulos de viagem: É responsável por verificar se os títulos de viagem dos
passageiros estão validados
3. Pré-condições
• O utilizador deve ter permissões de fiscal para poder verificar a validação do
título de viagem.
• O sistema tem de alertar o fiscal.
• O fiscal tem o dispositivo para verificar a validação dos títulos de viagem.

i. O fiscal requisita o comprovativo de título de viagem ao passageiro.
ii. O fiscal utiliza a máquina para verificar a validação do título de viagem.
iii. O sistema exibe a validação do título de viagem na máquina do fiscal.
5.1 O passageiro utilizou o cartão/passe para a validação.
i. O fiscal requisita o cartão/passe ao passageiro.
ii. O fiscal utiliza a máquina para a verificar a validação do título de viagem.
iii. O sistema exibe a validação do título de viagem na máquina do fiscal.
iv. O fiscal confirma a validação na sua máquina
5.2 O título de viagem não é válido

O sistema exibe a mensagem de título de viagem não válido na máquina do fiscal.
O fiscal confirma a mensagem de invalidação na sua máquina
5.3 O sistema encontra fiscais com a mesma proximidade:

O sistema envia a notificação para um fiscal aleatoriamente.
7.1. Alerta de fraude bem-sucedido:
O sistema alerta com sucesso os fiscais sobre a fraude.
45
8. Pós-Condições
8.1. O fiscal verifica a validação do título de viagem.
8.2. O fiscal verifica a não validação do título de viagem.
9.1. Máquina do Fiscal:
A máquina do fiscal deve ler cartões RFID e QrCode
46
PACKAGE 3: VIAJAR
UC3.0: ADQUIRIR TÍTULO DE VIAGEM
Neste caso de uso, detalhado através de um diagrama de sequência, mostramos a sequência

de etapas que são realizadas para adquirir um título de viagem. Dividimos o caso de uso em
duas partes, adquirir título de viagem na Aplicação e na MVA.
Nota: Quando forem adquiridos 10 títulos de viagem, deve ser oferecido um título de viagem ao
passageiro. Este requisito não está representado nos diagramas para não aumentar a sua
complexidade.
Diagrama de Sequência- Adquirir título de viagem na Aplicação.
Figura 6: UC3.0: Adquirir título de viagem - Aplicação

47
Diagrama de Sequência- Adquirir título de viagem nas MVA
Figura 7: UC3.0: Adquirir título de viagem - MVA
48
UC3.1: CRIAR PASSE
Este caso de uso descreve o processo pelo qual um utilizador, passageiro, crie um
passe para circular nos BRT’s.

2.1. Passageiro: Representa o passageiro que deseja criar o passe.
3. Pré-condições
• O passageiro deve estar autenticado no sistema.
• O passageiro não deve ter nenhum passe digital associado.
• O passageiro tem comprovativo o seu estatuto (estudante, sub23, idoso, etc)
• O passageiro permitiu o uso da fotografia para a criação do passe.

i. O passageiro inicia o processo de compra de passe digital.
ii. O sistema apresenta uma interface com todas as opções de passe digital
disponíveis.
iii. O passageiro seleciona o passe digital que pretende adquirir.
iv. O sistema valida o comprovativo de estatuto.
v. O passageiro realiza o pagamento.
vi. O pagamento é bem-sucedido.
vii. O passe digital é criado.
5.1 O passageiro pretende adquirir passe físico:
O passageiro deve dirigir-se às instalações da TUB destinadas a este fim.
5.2 O pagamento falhou:
O passe digital não é criado.
O utilizador tem de voltar a fazer o pagamento.
5.3 O passageiro não apresenta os comprovativos necessários:
O passageiro tem de apresentar os comprovativos necessários para a criação
do passe.
O passe digital não é criado.
7.1. O passe é criado
O passe pode ser utilizado para validar viagens e viajar.
8. Pós-Condições
49
8.1. O passageiro cria com sucesso o passe.
8.2 O passageiro não cria com sucesso o passe.
9.1. Pagamento:
O pagamento deve ser realizado por MBWAY ou por Multibanco.
50
UC3.2: CARREGAR PASSE
Este caso de uso descreve o processo pelo qual um utilizador, passageiro, carregue o
passe para circular nos BRT’s.

2.1. Passageiro: Representa o utilizador que deseja carregar o passe.
2.2. Máquina de Venda Automática: Hardware que permite ao utilizador carregar o
passe.
3. Pré-condições
• O passageiro tem de ter um passe associado.
• O passageiro não tem a mensalidade em dia.

i. O passageiro inicia o processo de carregamento do passe digital.
ii. O sistema exibe o passe digital, indicando o prazo de expiração.
iii. O sistema exibe a possibilidade da renovação/pagamento mensal.
iv. O passageiro seleciona essa possibilidade.
v. O pagamento é bem-sucedido.
vi. O passe digital é carregado.
5.1 O passageiro possui passe físico:
O passageiro deve dirigir-se às MVA.
O passageiro introduz o passe físico na MVA
A MVA lê o passe.
A MVA exibe as funcionalidades disponíveis.
O passageiro seleciona a opção “Carregamento do Passe”
A MVA exibe os métodos de pagamento.
O pagamento é bem-sucedido.
O passe físico é carregado.
5.2 O pagamento falhou:
O passe fisico/digital não é carregado.
O passageiro tem de voltar a fazer o pagamento.
7.1. O passe é carregado.
51
8. Pós-Condições
8.1. O passageiro carrega o passe com sucesso.
8.2. O passageiro não carrega o passe com sucesso.
9.1. Pagamento:
O pagamento deve ser realizado por MBWAY ou por Multibanco.
52
UC3.3: CONSULTAR SALDO
Este caso de uso descreve o processo pelo qual um passageiro, consulta o seu saldo
no sistema.

2.1. Passageiro: Representa o utilizador que deseja consultar o seu saldo no sistema.
3. Pré-condições
• O utilizador deve estar autenticado no sistema.

i. O utilizador inicia o processo de consulta de saldo.
ii. O sistema apresenta uma interface com o saldo do utilizador.
iii. O utilizador visualiza o saldo apresentado.
5.1 O sistema não consegue apresentar o saldo do utilizador.
O sistema apresenta uma mensagem de Erro.
O utilizador visualiza o seu saldo de forma precisa.
8. Pós-Condições
8.1. O utilizador consulta com sucesso o seu saldo.
8.2. O utilizador não consulta com sucesso o seu saldo.
9.1. Segurança:
A consulta de saldo deve ser protegida para garantir a privacidade do utilizador.
53
UC3.4: VALIDAR TÍTULO DE VIAGEM
Este caso de uso descreve o processo pelo qual um passageiro, valida o título de
viagem para poder viajar no BRT.

2.1. Passageiro: Representa o passageiro que deseja carregar o passe.
2.2. Validador: É responsável por validar o título do passageiro.
3. Pré-condições
• O passageiro tem de ter título de viagem/passe válido.
• O passageiro não validou nenhum título de viagem.
• O passageiro tem de validar no máximo 15min antes de embarcar no BRT

i. O passageiro inicia o processo de validação do título de viagem.
ii. O sistema exibe os títulos de viagem disponíveis do utilizador.
iii. O passageiro seleciona o título de viagem que pretende validar.
iv. O sistema valida o título de viagem.
v. O sistema exibe o comprovativo de validação.
5.1 O passageiro tem passe digital:
i. O passageiro seleciona o passe.
ii. O sistema valida o título de viagem.
iii. O sistema exibe o comprovativo de validação
5.2 O passageiro não tem conta no sistema e utiliza os Cartões RFID/ passe físico:
O sistema encosta o cartão/passe ao Validador.
O título de viagem é validado
7.1. O título de viagem é validado.
8. Pós-Condições
8.1. O passageiro pode viajar.
8.2 O título de viagem é descontado ao passageiro.
9.1. Validador:
54
O validador deve ser capaz de ler títulos de títulos de viagem/passes físicos.
9.2. Comprovativo associado a um código QR
O comprovativo de validação deve conter um código QR para o fiscal conseguir fazer
a validação.
55
UC3.5: TROCAR TÍTULO DE VIAGEM
Neste caso de uso, detalhado através de um diagrama de sequência, mostramos a sequência
de etapas que são realizadas para trocar um título de viagem. Dividimos o caso de uso em duas
partes, trocar título de viagem na Aplicação e na MVA.
Diagrama de Sequência- Trocar título de viagem na aplicação
Figura 8: UC3.5: Trocar título de viagem - Aplicação
56
Diagrama de Sequência- Trocar título de viagem na MVA
Figura 9: UC3.5: Trocar título de viagem - MVA
57
UC3.6: CONSULTAR TÍTULOS DE VIAGEM ATIVOS
Neste caso de uso, detalhado através de um diagrama de atividades, mostramos o fluxo de
atividades para a realização da consulta de títulos de viagens ativos pelo passageiro.
Dividimos o caso de uso em duas partes, consultar título de viagem na Aplicação e na MVA.
Figura 10: UC3.6: Consultar títulos de viagem ativos - Aplicação
Figura 11: UC 3.6: Consultar títulos de viagem ativos - MVA
UC3.7: CONSULTAR HISTÓRICO DE TÍTULOS DE VIAGEM

atividades para realizar a consulta do histórico de títulos de viagens pelo passageiro, que inclui
informações sobre títulos de viagem de viagens anteriores.
Figura 12: UC3.7: Consultar histórico de títulos de viagem
58
UC3.8: CONSULTAR HORÁRIOS E ITINERÁRIOS
atividades para realizar a consulta dos horários e itinerários das viagens pelo passageiro.
Figura 13: UC3.8: Consultar horários e itinerários
UC3.9: VER O BRT EM TEMPO REAL

atividades para realizar a visualização do BRT em Tempo Real pelo passageiro.
Figura 14: UC3.9: Ver BRT em tempo real
59
UC3.10: PREENCHER FORMULÁRIO DE SATISFAÇÃO
atividades para o preenchimento do formulário pelo passageiro.
Figura 15: UC3.10: Preencher formulário de satisfação
UC3.11: REQUISITAR APOIO AO CLIENTE

atividades para requisitar apoio ao cliente pelo passageiro.
Figura 16: UC3.11: Requisitar apoio ao cliente
60
PACKAGE 4: GERIR BRT
UC4.0: CONSULTAR VIAGENS ALOCADAS
Este caso de uso descreve o processo pelo qual um motorista consulta as viagens que
lhe foram alocadas para o dia.

2.1. Motorista: Representa o utilizador que deseja visualizar as viagens que lhe estão
alocadas.
3. Pré-condições
• O motorista deve estar autenticado no sistema.
• O motorista tem de ter conexão à internet

i. O motorista seleciona a secção de viagens.
ii. O motorista seleciona o dia atual.
iii. O motorista visualiza as viagens que lhe são alocadas.
7.1. O motorista visualiza as viagens que lhe são alocadas.
8. Pós-Condições
8.1. O motorista consulta com sucesso as viagens alocadas.
8.2. O motorista não consulta com sucesso as viagens alocadas.
61
UC4.1: CONSULTAR PASSAGEIROS
Neste caso de uso, detalhado através de um diagrama de atividades, mostramos o fluxo de atividades
para a realização da consulta de passageiros da viagem ativa pelo motorista.
Figura 17: UC4.1: Consultar passageiros
UC4.2: VER GPS DO PERCURSO A FAZER

para o motorista ver o GPS da viagem ativa.
Figura 18: UC4.2: Ver GPS do percurso a fazer
UC4.3: CONSULTAR DADOS DA PRÓXIMA PARAGEM

para a realização da consulta de dados da próxima paragem pelo motorista.
Figura 19: UC4.3: Consultar dados da próxima paragem
62
UC4.4: INICIAR E TERMINAR O ITINERÁRIO
para a realização da iniciação e término da viagem.
Figura 20: UC4.4: Iniciar e terminar o itinerário
UC4.5: REPORTAR INCIDENTE

caso o motorista tenha de reportar um incidente, isto é, uma emergência ou um acidente.
Figura 21: UC4.5: Reportar incidente
63
ESTUDO DO MERCADO
POPULAÇÃO DE BRAGA
Para uma melhor compreensão do problema, e para podermos justificar as nossas opções,
resolvemos fazer um pequeno estudo de mercado. Vamos estudar a evolução da densidade
populacional em Braga, bem como a sua divisão por faixa etária. Para além disto, vamos
também analisar o relatório de contas da TUB, para uma maior noção da terminologia do
negócio da mesma.
Figura 22: População de Braga
(censos https://www.pordata.pt/censos/quadro-resumo-municipios-e-regioes/braga-378 )
Com base nesta tabela, obtida nos Censos, verificamos que existe uma tendência de aumento
da densidade populacional em Braga. Estes dados justificam cada vez mais, a necessidade dos
BRT´s em Braga.
Outro dado importante a ter em conta é a percentagem de Idosos. Como podemos observar,
cerca de 20% da população de Braga é idosa. Isto significa que a nossa solução terá de suportar
meios de utilização mais tradicionais para que estes consigam usufruir da mesma. Falamos
então das máquinas de venda automáticas, bem como o sistema de validadores. Para o resto
da população, a aplicação para compra e validação dos títulos de viagem é um meio justificável.
64
LOCALIZAÇÃO DAS MÁQUINAS DE VENDA AUTOMÁTICA
Como sabemos que as máquinas de venda automática representam um elevado custo no
projeto, é fundamental a escolha de locais estratégicos, de forma que os custos associados às
mesmas sejam reduzidos.
Segundo o relatório de contas de 2021 divulgado pela TUB, sabemos que, cerca de 61,39% das
validações de títulos de transporte ocorreram em apenas 12 linhas de entre as 74 linhas
regulares da rede de transporte publico do concelho, representando 5.050.237 passageiros
transportados.
Figura 23: Ranking de validações de títulos por Linhas
(relatório de contas https://tub.pt/templates/frontoffice/enterprise/pdf/rl2021.pdf )
Com base nestes dados, o objetivo é colocarmos as MVA nas linhas onde há mais validação de
títulos de transporte.
65
FLUTUAÇÃO DIÁRIA
Depois de realizarmos a análise da taxa da utilização de viaturas da TUB em 2021, concluímos
que os períodos diários em que os transportes são mais utilizados são: Ponta Manhã, Ponta
Almoço e Ponta Tarde. Existindo uma grande discrepância de valores entre estes e o horário
Noturno, como podemos verificar na seguinte tabela.
Figura 24: Flutuação diária
Concluímos também que existe uma grande quebra na utilização dos transportes públicos aos
sábados, domingos e feriados.
Estes dados ajudam-nos a decidir as melhores alturas para realizar atualizações e instalações
de novos patches no sistema. Verificamos também nesta tabela, os horários prováveis de uma
maior sobrecarga do sistema.
PASSAGEIROS TRANSPORTADOS POR TÍTULO

O objetivo do estudo dos passageiros transportados por título é averiguar quais as opções que
vão ser mais utilizadas para adquirir títulos de viagem.
Figura 25: Passageiros transportados por título
Com base nos dados apresentados, concluímos que maior parte dos passageiros opta pelo
sistema de passes, pelo que envolve um maior cuidado no desenvolvimento da solução.
66
GLOSSÁRIO
A
Ator - papel executado por um utilizador que interage com o sistema. Um ator tem associações
exclusivas para os casos de uso, e é representado por um boneco de pau.
B
BRT – A sigla BRT, que significa Bus Rapid Transit em inglês, pode ser traduzida para português
como autocarro de transporte rápido. A diferença dos BRT para os autocarros convencionais
são que estes andam em zonas reservadas para os mesmo assim como têm vantagens em
termos da semaforização etc.
C
Casos de uso - Casos de uso são descrições detalhadas de interações entre um sistema de
software e atores externos, que representam utilizadores, sistemas ou componentes que
interagem com o sistema. Cada caso de uso descreve um cenário específico de interação,
destacando as ações executadas pelo sistema e as respostas apropriadas. Os casos de uso são
usados para capturar requisitos funcionais de um sistema.
CCTV - Circuito fechado de televisão ou circuito interno de televisão é um sistema de televisão

que distribui sinais provenientes de câmaras localizadas em locais específicos, para um ou mais
pontos de visualização.
D
Digital Twins - é uma representação virtual que serve como contrapartida digital em tempo real
de um objeto ou processo físico
F
Fiscal – Pessoa que verifica a validação dos títulos de viagem nos BRTs.
FURPS+ - FURPS é um acrônimo na engenharia de software, representa um conjunto de
critérios essenciais para definir os requisitos de um projeto de software: Funcionalidade,
Usabilidade, Confiabilidade, Desempenho e Suporte. O + faz com que a classificação dos
requisitos se concentre mais na compreensão dos diferentes tipos de requisitos não funcionais.
M
MBWAY - É uma aplicação de pagamento móvel em Portugal que permite aos utilizadores
efetuar transações financeiras, como transferências e pagamentos, através de dispositivos
móveis.
MVA - Máquinas de venda automáticas
67
N
Neadvance - A Neadvance é uma empresa de visão artificial e sistemas inteligentes que
desenvolve soluções e plataformas de visão computacional e inteligência artificial para a
revolução digital e industrial a nível mundial.
Niop - A niop é a plataforma de low code que traz simplicidade, integridade e velocidade para
organizar a camada de tecnologia operacional de vários sectores. Permite a qualquer pessoa
programar as suas próprias máquinas que irão interagir com o ecossistema global da indústria.
Q
QR Code - O QR Code é uma versão bidimensional do código de barras, composto de padrões
de pixels em preto e branco, que pode ser facilmente scanned usando a maioria dos telefones
equipados com câmara.
R
Requisitos funcionais - Requisitos funcionais são declarações claras e concisas que descrevem
as funções específicas que um sistema, software ou produto deve executar e que atende às
necessidades do utilizador ou do cliente.
Requisitos não funcionais - Requisitos não funcionais são critérios que descrevem
características, qualidades e restrições de um sistema, software ou produto, que não se referem
diretamente a suas funcionalidades, mas impactam sua qualidade e desempenho.
RFID - (Radio-Frequency Identification) é uma tecnologia que utiliza comunicação por

radiofrequência para identificar, rastrear e gerir objetos, animais ou pessoas.
RGPD - O RGPD (Regulamento Geral de Proteção de Dados) é uma legislação de privacidade

da União Europeia que estabelece regras rígidas para a proteção de dados pessoais. Foi
implementado em 2018 e abrange consentimento, acesso, exclusão de dados e penalidades
para violações.
S
Stakeholder - representa grupos de interesse cujas necessidades devem ser satisfeitas pelo
projeto. É uma função que pode ser desempenhada por qualquer pessoa que seja afetada pelo
resultado do projeto.
T
TUB - Transportes Urbanos de Braga
68
Touchscreen - Um ecrã tátil ou tela sensível ao toque é um tipo de ecrã sensível à pressão,
dispensando, assim, a necessidade de outro periférico de entrada de dados, como o teclado.
U
UML - A UML é uma linguagem-padrão para a elaboração da estrutura de projetos de software.
Ela poderá ser utilizada para a visualização, a especificação, a construção e a documentação de
artefactos que façam uso de sistemas complexos de software.
V
Visão - É um documento essencial que estabelece a visão geral do projeto. Este documento
descreve a ideia do projeto, seus objetivos, âmbito, stakeholders envolvidos, requisitos de alto
nível e outros aspetos-chave.
Validador - Máquina que valida os títulos de viagem ou passes dos passageiros.
W
WIFI - Wi-Fi é uma tecnologia de rede sem fio que permite que computadores (laptops e
desktops), dispositivos móveis (smartphones e dispositivos vestíveis) e outros equipamentos
(impressoras e câmaras de vídeo) se conectem à Internet. O Wi-Fi permite que esses e muitos
outros dispositivos troquem informações entre si, criando uma rede.
69
CONCLUSÃO
Com o desenvolvimento deste primeiro momento, o relatório de requisitos, a nossa equipa foi
capaz de, através de diferentes processos de levantamento de requisitos tais como a consulta
de outros casos e a reunião com stakeholders, concentrar os requisitos principais do problema,
assim como as descrições pormenorizadas dos mesmos. Assim este relatório fornece uma base
sólida e importante para o desenvolvimento do projeto. Esperemos que se apresente completo
e coerente para os próximos passos do projeto.
70

Acsi M1 TP01 G1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Acsi M1 TP01 G1

Enviado por

Direitos autorais:

Formatos disponíveis

LISTA DE MEMBROS DO GRUPO:

Guilherme José de Sousa Barbosa – PG53853

Raul Mendes de Castro Pinto – PG54172

Para o desenvolvimento desta proposta de requisitos, usamos vários artefactos de Technical

As técnicas usadas para representação de Casos de Uso e Modelos de Caso de Uso é a

As técnicas usadas para extrair os requisitos foram:

→ Reunião com o cliente (duração de 7 minutos);

→ Uso do modelo do OpenUP;

→ Contacto com pessoas experientes no tema.

2.1. DECLARAÇÃO DO PROBLEMA

Quem é afetado A direção e colaboradores da TUB e os passageiros.

Impacto Ambiental: Aumento do uso de veículos particulares e de

Insatisfação dos Passageiros: A falta de informações em tempo real

Solução Desenvolver uma aplicação que permite comprar títulos de viagem

Implementar máquinas de compra de títulos de viagem na

Implementar câmaras nos BRT´s para o controlo de entrada e saída

Tabela 1: Declaração do Problema

Para Transportes Urbanos de Braga (TUB)

Que Tornar os serviços de Transporte Urbanos de Braga mais eficientes,

Nome do Produto BRTicket

Descrição [BRT] - Aplicação de gestão dos BRT’s, gestão de viagens e de títulos

Ao contrário de myRNE – Aplicação de transporte rodoviário de passageiros da Rede

FLIX BUS – Aplicação de transporte rodoviário que também permite

O nosso produto Pensado, estruturado e desenvolvido de forma a tornar-se numa

Tabela 2: Declaração da Posição do Produto

3.1. RESUMO DOS STAKEHOLDERS

Nome Descrição Responsabilidades

Equipa de trabalho Grupo de pessoas que se Fornecer soluções viáveis;

Garantir a qualidade do projeto;

Equipa Docente Professor responsável por Avaliar o desempenho da

TUB (Transportes Urbanos Empresa de transporte de Ajudar a especificar a solução;

Passageiros Utilizadores dos BRT Apresentar feedback em relação

Neadvance Empresa de tecnologia, Fornecimento de recursos.

Quantidade de pessoas envolvidas na conclusão da tarefa:

Ciclo de tarefa e tempo gasto em cada atividade:

Plataformas de sistema em uso hoje e no futuro:

Atualmente, os passageiros utilizam diferentes tipos de plataformas, entre elas os smartphones,

Outras aplicações em uso e integração necessária:

4.1. NECESSIDADES E REQUISITOS

Necessidade Prioridade (1-5) Requisitos Lançamento

Controlar a 4 Utilização da câmara CCTV para Versão 1

Desmaterializaçã 5 Representação dos títulos de Versão 1

Sistemas 5 Comprar títulos de transporte de Versão 1

Bilheteria Digital 5 Comprar títulos de transporte de Versão 1

Sistema Self- 5 Comprar títulos de transporte Versão 1

Localização em 5 Representação da localização do BRT Versão 1

Digital Twins 5 Representação em tempo real de um Versão 1

Informação ao 5 Representação em tempo real de Versão 1

Tabela 4: Necessidades e Requisitos

Requisito Prioridade (1-5) Lançamento

Cumprir padrões de segurança de dados 5 Versão 1

Garantir a suportabilidade dos diferentes 5 Versão 1

Garantir a usabilidade das soluções incorporada 4 Versão 1

Garantir a fiabilidade do Sistema 4 Versão 1

Garantir a precisão dos dados assim como a sua 5 Versão 1

Disponibilidade – Sistema ativo 24h/dia 5 Versão 1

Apoio ao Cliente- Acompanhar o cliente e prestar 3 Versão 1

Tabela 5: Outros Requisitos

2. REQUISITOS FUNCIONAIS DE TODO O SISTEMA

Requisito Necessidade Descrição

Tabela 6: Requisitos funcionais de todo o sistema

Os sistemas de qualidade são requisitos utilizados para avaliar o desempenho do

→ Após a primeira utilização da aplicação, o utilizador já deve dominar completamente o