Documento de Requisitos do sistema CondoMine

(1)

Universidade Federal de Pernambuco

Centro de Informática - CIn

Elicitação de requisitos e validação de sistemas

Professora Carla Silva

Documento de Requisitos do sistema

CondoMine

(2)

1. Introdução

Este presente documento tem como intuito primordial prover um estudo detalhado dos requisitos elicitados para o sistema tratado. O sistema em questão é uma solução para gerenciamento da burocracia e da segurança de condomínios, de nome CondoMine, desenvolvido pela organização SAMB.

Ainda nesta introdução, será dada uma motivação para a solução do problema, assim como uma explanação acerca do problema a ser combatido.

1.1 Motivação

Devido à valorização dos imóveis em geral no último século, uma solução que

se mostrou viável nos grandes centros urbanos foi a criação de condomínios cada vez

maiores. O aumento do tamanho dos condomínios elevou bastante o grau de

agrupamento de pessoas, trazendo por conseguinte, uma enorme dificuldade de

gerenciamento dessas verdadeiras “cidades”. As técnicas de gerenciamento, no

entanto, não acompanharam estas mudanças, não sendo raros os conflitos internos.

Dentre os diversos problemas, destaca-se a segurança. Sem uma ferramenta

moderna feita especificamente para este fim, o controle de entrada e saída de carros e

pessoas, bem como a vigilância do condomínio em si, tornam-se praticamente

impossíveis de serem executados satisfatoriamente.

1.2 O Problema Identificado

No presente documento, serão apresentadas e analisadas diferentes alternativas de solução dos problemas enfrentados pelos grandes e médios condomínios, tanto no que tange à segurança, como no que tange a outras esferas, como a administrativa e a orçamentária. Além do sistema CondoMine, projeto pertencente à empresa SAMB, da área de Tecnologia da Informação e Comunicação serão propostas outras duas alternativas, detalhadas no capítulo seguinte.

Para a elaboração das soluções alternativas ao sistema CondoMine, foram levadas em conta soluções já existentes no mercado. No processo de levantamento dos detalhes dos problemas, foram ouvidos moradores e funcionários de diferentes condomínios.

1.2.1 Modelo BPMN

Nessa sub-seção analisaremos dois casos que ocorrem na empresa como ela é atualmente. Para isso utilizamos a ferramenta BizAgi para construir os Modelos BPMN:

(3)

Comentário: Percebe-se que é um processo completamente manual e lento, pois o morador deve se deslocar até a área administrativa, o funcionário responsável deve procurar os papeis necessários, etc. O que torna esse procedimento muito lento.

Caso 2: Procedimento realizado quando um carro deseja entrar no condomínio:

Comentário: nota-se que o modelo atual tem alguns defeitos que tornam esse

(4)

função da memória do porteiro, que pode até deixar carros desconhecidos entrarem se achar parecido com algum do condomínio.

1.3 Sobre a Organização

A empresa SAMB foi fundada a pouco mais de um mês, e está se consolidando no mercardo de desenvolvimento de software, com o sistema CondoMine. A sigla é referente as iniciais dos nomes dos donos. É uma empresa pequena, mas que se encontra em constante ascenção, sendo sua sede localizada em Jaboatão dos Guararapes/PE. O número de telefone para contato com a recepção é (81) 8895-5221

1.4 Convenções para Identificação dos Requisitos

Nas seções a seguir, os requisitos seguirão um padrão de identificação: todos terão um identificador no formato [RFxx], para requisitos funcionais e [RNFxx], para requisitos não funcionais (xx representa o número do caso de uso em questão). Os requisitos também possuirão os nomes dos casos de uso relacionados.

1.5 Convenções para Identificação dos Casos de Uso

Nas seções a seguir, os casos de uso seguirão um padrão de identificação: todos terão um identificador no formato [UCxx], onde xx é o número do caso de uso.

Os casos de uso estão descritos no ANEXO A.

1.5.1 Estrutura dos casos de uso

Cada caso de uso terá o seguinte formato: ● Identificador: identifica o caso de uso

● Atores: Os modelos de usuário que utilizarão o caso de uso;

● Prioridade: Prioridade de implementação deste caso de uso [Essencial, Importante, Desejável];

● Pré-condições: Condições que devem ser satisfeitas antes de o caso de uso ser executado;

● Fluxo de eventos: O passo a passo das ações realizadas para que o caso de uso seja concluído, podendo incluir fluxos de eventos secundários e/ou alternativos;

● Pós-condições: Condições que devem ser satisfeitas depois de o caso de uso ser finalizado.

1.5.2 Prioridades dos casos de uso

Os casos de uso são classificados como:

(5)

● Essencial: São os casos de uso que representam as funcionalidades básicas do sistema, que o tornam útil. Caso algum deles não seja implementado, o sistema perde seu próposito.

● Importante: São os casos de uso em que sua ausência não deixa o sistema inútil, porém vai desagradar os usuários, pois são requisitos importantes.

● Desejável: Não se trata de uma funcionalidade básica ou importante do sistema, logo espera-se que haja esforço para que esse requisito seja implementado no momento ou em versões posteriores.

1.5.3 Atores e seus Níveis de Acesso

Os atores são aqueles que interagem de alguma forma com o sistema, respeitando seus níveis de aceso. Eles são:

● Síndico - pode cadastrar qualquer tipo de usuario, alterar o nivel de acesso de qualquer usuário

● Funcionário Administrativo - pode fazer tudo que um funcionário comum pode, mais cadastrar e alterar usuários em níveis inferiores, mudar o nível de acesso de usuários de níveis inferiores, cadastrar, excluir, alterar, aprovar e rejeitar solicitações de reservas de espaços comuns.

● Funcionário Comum - pode fazer tudo que um morador faz mais pode liberar o portão para carros e o portão para pessoas.

● Morador- solicitar cadastro de novos moradores, solicitar reserva dos espaços comuns, consultar reservas dos espaços comuns, consultar alocação de vagas de garagem, consultar relação de moradores/residências, acessar website, criar tópicos de discussão no website, excluir tópicos criados por si, comentar tópicos.

2. Requisitos Organizacionais

Os requisitos organizacionais devem satisfazer os objetivos da organização e definir porque o sistema é necessário. Esses requisitos são:

● Aumentar a segurança do condomínio, de forma que os moradores se sintam mais tranquilos.

● Facilitar a comunicação entre todos os moradores e funcionários, para que assuntos em geral possam ser discutidos sem esperar até as reuniões de condomínio.

● Mostrar aos usuários informações sobre as contas do condomínio (um portal de transparência).

● Facilitar o pagamento das contas do condomínio.

(6)

3. Requisitos Funcionais

Aqui serão listadas as funções que o sistema deve ser capaz de realizar, além de sua prioridade. Os requisitos a seguir serão agrupados em duas áreas: Segurança e Website.

3.1 Segurança

3.1.1 [RF01] Cadastrar placas de carros

Identificação: [RF01] Cadastrar placas de carros Casos de Uso relacionados: [UC 02] Descrição: O porteiro ou o síndico cadastram uma nova placa no banco de dados do sistema, após verificarem que é o carro de um morador do condomínio.

Prioridade: Essencial Importante Desejável

3.1.2 [RF02] Remover placas de carros

Identificação: [RF02] Remover placas de carros Casos de Uso relacionados: [UC 02] Descrição: O porteiro ou o síndico removem do banco de dados a

(7)

placa do carro que não pertencer mais a um morador do condomínio.

3.1.3 [RF03] Abrir o portão para um carro

Identificação: [RF03] Abrir um

portão para um carro Casos de Uso

relacionados:

[UC 02]

Descrição: Quando um carro para em frente ao portão do condomínio, o sistema captura a placa do carro através de uma câmera, e procura essa placa em seu banco de dados, abrindo o portão quando a encontra.

3.1.4 [RF04] Fechar o portão

Identificação: [RF04] Fechar o portão Casos de Uso

relacionados:

[UC 02]

Descrição: Quando o portão for aberto, o sistema começa esperar o

(8)

sensor do portão avisar que algo passou por ele. Quando ele enviar o aviso, o portão é fechado, ou caso nada passe em um

determinado tempo

Prioridade: Essencial Import

ante

Desejável

3.1.5 [RF05] Acessar as câmeras de segurança

Identificação: [RF05] Acessar as

câmeras de segurança Casos de Uso

relacionados:

[UC 05]

Descrição: Os usuários podem acessar as câmeras de segurança em tempo real, através do website ou de seu televisor.

Prioridade: Essencial Importante Desejável

3.1.7 [RF07] Servidor do sistema no próprio condomínio

Identifica ção: [RF07] Servidor do sistema no próprio condomínio Casos de Uso relaciona dos:

NÃO ESPECIFICADOS NESTA VERSÃO DO DOCUMENTO

Descriçã o:

O servidor que mantém o sistema online deve estar

(9)

localizado no próprio

condomínio, por questões de segurança.

Prioridad e:

Essencial Importante Desejável

3.1.8 [RF08] Manutenção periódica pelo SAMB

Identificaçã

o:

[RF08] Manutenção períodica pelo SAMB Casos de Uso relacionado s: NÃO ESPECIFICADOS NESTA VERSÃO DO DOCUMENTO

Descrição: Periodicamente, o SAMB que é a empresa que desenvolve o sistema, deve prestar manutenção para evitar possíveis falhas no sistema.

3.2 WebSite

3.2.1 [RF09] Efetuar logon

Identificaçã o: [RF09] Efetuar logon Casos de Uso relacionado s: [UC 01] Descrição: As informações e

(10)

ferramentas do CondoMine só estão disponíveis para

moradores e funcionários do condomínio, logo é preciso que o usuário realize o logon no sistema para se identificar. Para isso ele precisára digitar seu nome de usuário, sua senha e clicar no botão Entrar.

3.2.2 [RF10] Efetuar logoff

Identifica ção: [RF10] Efetuar logoff Casos de Uso relaciona dos: [UC 01] Descriçã o:

Possibilita o usuário sair do sistema, é essencial por questões de segurança e privacidade.

Prioridad e:

3.2.3 [RF11] Cadastrar novos usuários

Identifica ção: [RF11] Cadastrar novos usuários Casos de Uso relaciona

(11)

dos: Descriçã o:

O síndico, ou o administrador responsável, cadastram novos usuários, sejam estes novos moradores ou novos

funcionários, solicitando

diversos dados que identifiquem completamente essa pessoa. Prioridad

e:

3.2.4 [RF012] Remover Usuário

Identifica ção: [RF012] Remover Formando Casos de Uso relaciona dos:

Descriçã o:

O síndico ou o administrador

removem o usuário, apagando suas informações no banco de dados do sistema.

Prioridad e:

3.2.5 [RF13] Remover Usuário

Identifica ção: [RF13] Remover Usuário Casos de Uso relaciona dos:

(12)

Descriçã o:

Permite remover completamente um usuário do sistema, apagando todas suas informações do banco de dados. Prioridad

e:

3.2.6 [RF14] Criar tópico no fórum de discussão

Identificação: [RF14] Criar tópico no fórum de

discussão Casos de

Uso

relacionados:

[UC 04]

Descrição: Qualquer usuário cadastrado no sistema e devidamente logado, pode criar um tópico novo no fórum do website, contato que ele tenha permissão para acessar a área do fórum desejada.

3.2.7 [RF15] Ler tópico no fórum de discussão

Identificação: [RF15] Ler tópico no fórum de

discussão Casos de Uso

relacionados:

[UC 04]

Descrição: Qualquer usuário cadastrado no sistema e devidamente logado, pode ler um tópico no fórum do website, contato que ele tenha permissão para acessar a área do fórum desejada.

(13)

3.2.8 [RF16] Emitir boletos de pagamento

Identificação: [RF16] Criar tópico no fórum de

discussão Casos de Uso

relacionados:

[UC 03]

Descrição: Qualquer usuário cadastrado no sistema e devidamente logado, tem acesso a todas suas contas, no formato pdf, para que possa imprimí-las em casa.

3.2.9 [RF17] Reservar área comum

Identificação: [RF17] Reservar área comum Casos de Uso

relacionados:

[UC 01]

Descrição: Qualquer usuário cadastrado no sistema e devidamente logado, tem acesso à opção de reservar área comum do condomínio (salão de festas, quadra de jogos, piscina, churrasqueira, etc), desde que marque uma data livre.

(14)

Identificação: [RF18] Efetuar pagamento online

Casos de Uso relacionados:

[UC 03]

Descrição: Qualquer usuário

cadastrado no sistema e devidamente logado, tem acesso à opção de realizar seus pagamentos online, de forma segura, através de seu cartão de crédito.

4. Requisitos Não-Funcionais

Este capítulo descreve requisitos relacionados com restrições e aspectos de qualidade. Os requisitos foram divididos entre as duas frentes do sistema CondoMine, segurança e website.

4.1 Segurança

4.1.1 [NFR01] Prover um ambiente seguro de se viver, com

nenhum roubo ou furto.

Identificação: [NFR01] Prover um ambiente seguro de se viver, com nenhum roubo ou furto. Casos de Uso

relacionados:

[UC02] e [UC05].

Descrição: O sistema deve ajudar a prover segurança ao

(15)

condomínio de forma a evitar que existam roubos ou furtos.

4.1.2 [NFR02] Cadastro de carros e pessoas deve ser rápido e

simples

Identificaçã o:

[NFR02] Cadastro de carros e pessoas deve ser de forma simples. Casos de Uso relacionado s: Todos.

Descrição: O cadastro de carros e pessoas no banco de dados do

condomínio deve ser rápido e simples, para que os moradores não fiquem com preguiça de realizá-los quando necessário, o que daria mais trabalho para os funcionários terem que teriam que procurar essas pessoas.

Prioridade: Essencial Importante Desejável

4.1.3 [NFR03]

As câmeras de vigilância devem ter uma boa

resolução

Identificação: [NFR03] As câmeras de segurança devem

(16)

ter uma boa resolução Casos de Uso relacionados: [UC02] E [UC05]

Descrição: É importante que as câmeras do

condomínio tenham boa resolução por que o sistema de detecção de placas precisa identificar de forma clara qual a placa de cada carro, para evitar que problemas de detecção ocorram com frequência. Também é importante na questão da segurança, pois câmeras de boa resolução possibilitam identificar melhor os envolvidos nas ocorrências.

Prioridade: Essencial Importante Desejável

4.1.4 [NFR04] Poder adicionar novas câmeras de vigilância quando

preciso

Identificação: [NFR04] Poder adicionar novas câmeras de

vigilância quando preciso Casos de Uso

relacionados:

[UC02] E [UC05]

Descrição: Com possíveis expansões do condomínio ou a necessidade de adição de novas câmeras devido ao aumento de ocorrências, é desejável

(17)

que o sistema possa ser capaz de aceitar novas câmeras de vigilância.

Prioridade: Essencial Importante Desejável

4.1.5 [NFR05] Ser seguro, respeitando a privacidade dos moradores.

Identificação: [NFR05] Ser seguro,

respeitando a privacidade dos moradores.

[UC02] [UC03] [UC05]

Descrição: É essencial que o condomínio traga segurança tanto na questão da violência quanto na questão de privacidade dos dados de cada morador. Porém, deve-se sempre levar em consideração a privacidade dos moradores, não deixando que as câmeras de vigilância invadam a vida íntima deles, nem que seus dados no

website possam ser acessados por pessoas não autorizadas.

Prioridade: Essencial Importante Desejável

4.2 Website

4.2.1 [NFR06] Possuir interface amigável e intuitiva.

Identificação: [NFR06] Possuir interface

(18)

[UC01] [UC03] [UC4] [UC05]

Descrição: Como nem todas pessoas tem facilidade na hora de usar um computador, é essencial que o website possua uma interface amigável e intuitiva, para facilitar a vida dos moradores na hora de acessar a nossa ferramenta.

4.2.2 [NFR07] Responder rapidamente às solicitações.

Identificação: [NFR07] Responder

rapidamente às solicitações. Casos de Uso

relacionados:

[UC01] [UC03] [UC4] [UC05]

Descrição: Caso o sistema seja muito lento na hora de responder as solicitações, os moradores começarão a ficar instatisfeitos e sem vontade de usar o CondoMine, o que traria problemas para a

administração do condomínio, pois a participação dos

condôminos é essencial para o bom funcionamento da nossa solução.

4.2.3 [NFR08] Disponibilidade 24 horas nos sete dias da semana.

Identificação: [NFR08] Disponibilidade 24

(19)

horas nos sete dias da semana.

Todos

Descrição: Com o uso do CondoMine, todo o condomínio fica dependente do uso do

sistema, o que torna essencial que ele esteja sempre

disponível e funcional.

4.2.4 [NFR09] Manter a integridade dos dados.

Identificaç

ão:

[NFR09] Manter a integridade dos dados. Casos de Uso relacionad os: Todos

Descrição: Os dados dos moradores devem ser preservados por questões de segurança e privacidade.

Prioridade: Essencial Importante Desejável

4.2.5 [NFR10] Salvar boletos em formato pdf, ou imprimir com boa

qualidade.

Identificação: [NFR10] Salvar boletos em formato pdf, ou imprimir com boa qualidade.

Casos de Uso

relacionados:

(20)

Descrição: Os boletos disponibilizados online devem possuir boa qualidade, assim os usuários não terão problemas na hora de pagar suas contas.

4.2.6 [NFR11] Transparência em relação a área financeira

Identificação: [NFR11] Transparência em

relação a área financeira Casos de

Uso

relacionados:

[UC04]

Descrição: O fórum deve possuir áreas para os administradores poderem mostrar os clientes que possuem débito e o valor, bem como as contas pagas e o dinheiro em conta.

4.2.7 [NFR12] Manutenção preventiva periódica do website provida

pela SAMB.

Identificação: [NFR12] Manutenção preventiva periódica do website provida pela SAMB. Casos de

Uso

relacionados:

[UC01] [UC03] [UC04] [UC05]

Descrição: A SAMB deve realizar manutenções periódicas no website, para evitar que

(21)

problemas futuros como mal funcionamento e site fora do ar.

5. Modelagem Organizacional

(22)

6. Modelagem de Requisitos

Funcionais (Casos de Uso)

Neste capítulo, cinco dos requisitos descritos anteriormente são modelados através de diagramas de caso de uso. O detalhamento dos casos de uso encontra-se no Anexo A deste documento.

(23)

7. Modelagem de Requisitos

Não-Funcionais (NFR Framework)

Este capítulo contém os refinamentos dos requisitos não-funcionais, descreve suas interdependências e operacionalizações. Será apresentado um modelo NFR para segurança e outro para o website.

Segurança:

(24)

Website:

(25)

8. Conclusão

Sabendo dos problemas enfrentados em termos de organização e segurança de médios e grandes condomínios, foi possível notar a urgência na resolução destes problemas exaustivamente expostos neste documento. A inovação da empresa SAMB ao criar o sistema CondoMine, apenas reafirma o propósito da tecnologia, que é auxiliar o homem em tarefas nas mais variadas áreas.

Este documento de requisitos fornece ao leitor uma visão detalhada do sistema

CondoMine, assim como a motivação para a criação do sistema e o problema que este

combate.

O sistema em questão foi especificado através de seus requisitos funcionais e não-funcionais elicitados, ambos detalhados ao longo do documento. Frameworks e notações foram utilizados para modelar o problema de acordo com os tipos de requisitos, foram eles o i* e o NFR. Outra abordagem utilizada foi a elaboração de casos de uso, também detalhados com precisão.

O uso de tais ferramentas força os engenheiros de requisitos a compreenderem a natureza do problema e realmente desenvolverem uma ideia concreta de como o sistema será contruído, além de manterem as informações catalogadas e organizadas devidamente. Não restam mais dúvidas acerca da não só importância, mas necessidade, do processo de

elicitação de requisitos utilizando todas as ferramentas pertinentes para que se tenha sucesso na construção de um sistema bom e organizado.

(26)

Referências

[Disciplina] https://sites.google.com/site/ervsif716/home

[Modelo de referência] http://www.cin.ufpe.br/~if716/arquivos/EspecificacaoRequisitos-Infoturma.doc

[Dúvidas] http://www.google.com.br

Relatório da Equipe

(27)

Anexo A – Descrição dos Casos de Uso

Identificador [CM01]

Nome Reserva de espaço comum

Descrição Este caso de uso é responsável

pela reserva de espaço comum do condomínio.

Ator Morador

Pré-condições O morador deve possuir um

cadastro(login e senha) no website.

Pós-condições O determinado espaço comum

estará reservado para o morador em questão.

Fluxo principal [FP]

1. Usuário autentica-se no site, através de seu login e senha. 2. Sistema mostrará a página inicial do wbsite.

3. O usuário já logado clicará no ícone de reservas do website. 4. Uma lista com os espaços comuns será dispinibilizada pelo sistema, para escolha.

5. O sistema apresentará ao usuário uma tabela em forma de calendário, que mostrará os dias e horários disponíveis, referente a aquele espaço comum.

6. Sistema efetua a reserva, e retorna ao passo 2.

Fluxo secundário [FS1]

1. Usuário digita senha ou login errado.

(28)

[FP] Fluxo secundário

[FS2]

1. Usuário escolhe um dia e hora que já possui reserva, e o sistema emite uma mensagem de erro. 2. Sistema retorna ao passo 4 do [FP]

1. Morador não está com as taxas obrigatórias do condomínio em dia. 2. Sistema mostra um aviso na tela, e retorna para o passo 2 do [FP]

(29)

Nome Entrar no condomínio.

Descrição Procedimento realizado para

identificar um carro que chega, abrindo ou não o portão para ele.

Ator Morador.

Pré-condições Nenhuma (qualquer carro que

parar frente as câmeras terá sua placa analisada).

Pós-condições Sistema abre o portão para o

carro entrar e fecha quando ele passar.

1. Carro para em frente ao portão. 2. O sistema, que está sempre tentando identificar uma placa na imagem fornecida pela câmera, captura a placa.

3. Sistema confere em seu banco de dados

se a placa está cadastrada. 4. Sistema abre o portão do condomínio

5. Carro entra e ativa o sensor que avisa o sistema que o carro já passou pelo portão.

6. Sistema fecha o portão. Fluxo

secundário [FS]

1. câmera não identifica a placa no passo [FP] 2.

2. O porteiro recebe um aviso em seu computador (na portaria) e assume o controle da situação.

(30)

Nome Emitir boleto da taxa de

condomínio.

Descrição Este caso de uso é

responsável por emitir o boleto para pagamento da taxa do condomínio.

Ator Morador

Pré-condições O morador deve possuir um

cadastro(login e senha) no website.

Pós-condições O boleto para pagamento da

taxa será emitido.

Fluxo principal [FP] 1. Usuário autentica-se no site, através de seu login e senha.

2. Sistema mostrará a página inicial do website.

3. Usuário clica no ícone de pagamentos.

4. Sistema mostra na tela todas as taxas que

poderão/deverão ser pagas pelo usuário.

5. Usuário clicará na taxa que deseja emitir o boleto.

6. Sistema emite boleto em formato pdf e retorna ao passo 5.

(31)

2. Sistema retorna ao passo 1 do [FP]

(32)

Nome Criar tópico no fórum do

website.

Descrição Caso de uso responsável

pela criação de um tópico no fórum do website por um usuário do sistema.

Ator Todos atores.

Pré-condições O ator deve possuir um

cadastro (login e senha) no website.

Pós-condições O tópico será postado no

fórum, ficando visível para todos com permissão para tal.

1. Usuário autentica-se no site, através de seu login e senha.

2. Sistema mostrará a página inicial do website.

3. Usuário clica no ícone do fórum.

4. Usuário escolhe clica na área que deseja ir no fórum (somente as que tem acesso).

5. Usuário clica no botão “Criar Tópico”.

6. Usuário escreve o título e o texto.

7. Usuário clica no botão “Criar”.

(33)

8. Tópico é criado. Fluxo secundário

[FS1]

1. Usuário clicou em uma área mas não pôde entrar nela, no passo [FP] 4 (as áreas administrativas são restritas apenas aos funcionários)

2. Sistema mostra

mensagem de erro e retorna para página anterior, onde estava no [FP] 4.

1.Usuário digita senha ou login errado no

[FP] 1.

2. Sistema retorna ao passo 1 do [FP]err, e o sistema volta ao passo 4 do [FP].

(34)

Identificador [CM05]

Nome Acessar câmeras de vigilância pelo

website.

Descrição Este caso de uso é responsável por

fazer com que o usuário veja o que cada câmera de vigilância está filmando, através do website.

Ator Morador, Funcionário administrativo

e porteiro.

Pré-condições

Os atores devem possuir um cadastro(login e senha) no website.

Pós-condições

A visualização em tempo real de cada câmera será mostrado.. Fluxo

principal [FP]

1. Usuário autentica-se no site, através de seu login e senha. 2. Sistema mostrará a página inicial do website.

3. Usuário clica no ícone de acesso as câmeras de vigilância.

4. Sistema mostra na tela ícones referentes as câmeras.

5. Usuário clicará na câmera que deseja acompanhar.

6. Sistema disponibilizará a imagem e um botão de finalizar a exibição. 7. Usuário aperta o botão de finalizar.

8. O sistema volta ao passo 4. Fluxo

secundário

(35)

[FS1]

2. Sistema retorna ao passo 1 do [FP]