UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMTICA
Graduao em Cincia e Engenharia da Computao

Parking Manager
Especificao de Requisitos

Professor: Jaelson Freire Brelaz de Castro

Equipe:
Onildo Luciano de Souza Ferraz Filho
Thiago Ferreira Dantas Santos
{olsff, tfds} @cin.ufpe.br

Recife, 10 de Novembro de 2009

Parking Manager

Verso: 1.0
Data da verso:
10/08/2007

EspecificacaoRequisitos.doc

HISTRICO DE REVISES
Revis
o
01
02

Data

Descrio

Autor

10/11 Incio do Documento de Requisitos.

Descrio das tcnicas de coleta de
incio
das
descries
dos
31/07 dados;
requisitos.

olsff, tfds
apba.

03

Descrio das tcnicas de coleta de

01/08 dados; continuao das descries dos
requisitos.

apba.

04

10/11 Descrio dos Casos de uso.

olsff, tfds

05

05/08 Trmino da descrio dos requisitos.

apba,
brcr,
gval, mbs.

06

Modelagem
do
SR
06/08 InformaTurma expandido.

07

Modelagem do SR com ator Formando

08/08 expandido. Modelagem do diagrama NFR.
Reviso e continuao dos casos de uso.

08

Descrio de Casos de Uso e Coleta e

08/08 insero de informaes relativas a gval.
comisso

09
09

olsff, tfds

09/08 Finalizao dos casos de uso.

09/08 Reviso geral do documento.

Pgina 2

com

ator

apba, brcr.
apba,
brcr,
gval, mbs.

brcr.
brcr.

10/08/2007

Parking Manager

Verso: 1.0
Data da verso:
10/08/2007

EspecificacaoRequisitos.doc

ndice
1. INTRODUO................................................................................................................................6
1.1 MOTIVAO....................................................................................................................................6
1.2 O PROBLEMA IDENTIFICADO...........................................................................................................6
1.3 SOBRE A ORGANIZAO.................................................................................................................6
1.4 CONVENES PARA IDENTIFICAO DOS REQUISITOS...................................................................7
1.5 CONVENES PARA IDENTIFICAO DOS CASOS DE USO..............................................................7
1.5.1 Estrutura dos casos de uso....................................................................................................7
1.5.2 Prioridades dos casos de uso................................................................................................7
1.5.3 Descrio dos Atores.............................................................................................................8
2. REQUISITOS ORGANIZACIONAIS............................................................................................8
3. REQUISITOS FUNCIONAIS.........................................................................................................8
3.1 MAPAS DOS ANDARES EXIBIDOS AOS CLIENTES...........................................................................8
3.1.1 [RF01] Detectar e Exibir Ocupao de Vaga.....................................................................8
3.1.2 [RF03] Detectar e Exibir Desocupao de Vaga................................................................8
3.1.3 [RF04] Exibir Evento...........................................................................................................8
3.2 CENTRO DE CONTROLE DO ESTACIONAMENTO............................................................................10
3.2.1 [RF05] Efetuar logon.........................................................................................................10
3.2.2 [RF06] Efetuar logoff.........................................................................................................10
3.2.3 [RF08] Classificar vagas...................................................................................................10
3.2.4 [RF09] Gerar relatrio......................................................................................................10
3.2.5 [RF10] Cadastrar Gerente.................................................................................................10
3.2.6 [RF11] Cadastrar Operador..............................................................................................10
3.2.7 [RF12] Excluir Gerente......................................................................................................11
3.2.8 [RF13] Excluir Operador..................................................................................................11
3.2.9 [RF14] Alterar Senha de Gerente.....................................................................................11
3.2.10 [RF15] Alterar Senha de Operador.................................................................................11
3.2.11 [RF16] Listar Gerentes e Operadores..............................................................................11
4. REQUISITOS NO-FUNCIONAIS.............................................................................................12
4.1 REQUISITOS DE PROCESSO............................................................................................................12
4.1.1 [NFR01] Utilizar Extreme Programming como Metodologia de Desenvolvimento............12
4.1.2 [NFR02] Utilizar Linguagem C++.....................................................................................12
4.1.3 [NFR03] Utilizar Banco de Dados MySQL........................................................................12
4.2 REQUISITOS DE PRODUTO.............................................................................................................13
4.2.1 Usabilidade.........................................................................................................................13
4.2.1.1 - [NFR04] Mensagens de Erro.....................................................................................13
4.2.1.2 - [NFR05] Interface do Sistema para o Gerente...........................................................13
4.2.1.3 - [NFR06] Interface do Sistema para o Cliente............................................................13
4.2.1.4 - [NFR07] Intervalo para Liberao de Vaga...............................................................14
4.2.1.5 - [NFR08] Destacar Vagas Especiais...........................................................................14
4.2.2 Confiabilidade.....................................................................................................................14
4.2.2.1 - [NFR09] Disponibilidade.........................................................................................14
4.2.3 Segurana............................................................................................................................14
4.2.3.1 - [NFR10] Integridade..................................................................................................14
4.2.3.2 - [NFR11] Backup........................................................................................................15
4.2.3.3 - [NFR12] Privacidade.................................................................................................15
4.2.4 Desempenho........................................................................................................................15
4.2.4.1 - [NFR13] Tempo de Resposta.....................................................................................15
4.2.4.2 - [NFR14] Espao de armazenamento..........................................................................15
4.3 REQUISITOS EXTERNOS.................................................................................................................16
olsff, tfds

Pgina 3

10/08/2007

Parking Manager

Verso: 1.0
Data da verso:
10/08/2007

EspecificacaoRequisitos.doc

4.3.1 [NFR15] Oramento ..........................................................................................................16

4.3.2 [NFR16] Tempo de desenvolvimento...................................................................................16
5. MODELAGEM ORGANIZACIONAL........................................................................................17
5.1 MODELAGEM DE DEPENDNCIA ESTRATGICA............................................................................17
5.2 MODELO ESTRATGICO DA RAZO..............................................................................................17
6. MODELAGEM DE REQUISITOS FUNCIONAIS (CASOS DE USO).....................................20
7. MODELAGEM DE REQUISITOS NO-FUNCIONAIS (NFR FRAMEWORK)...................21
8. CONCLUSO ................................................................................................................................23
REFERNCIAS................................................................................................................................24
RELATRIO DA EQUIPE..............................................................................................................24
ANEXO A TCNICAS UTILIZADAS NA COLETAS DE DADOS.........................................25
QUESTIONRIO...................................................................................................................................25
ENTREVISTA NARRATIVA...................................................................................................................25
COLETA DE ARTEFATOS.....................................................................................................................25
ANEXO B QUESTIONRIO........................................................................................................25
ANEXO C ENTREVISTA NARRATIVA....................................................................................26
ANEXO D ARTEFATOS COLETADOS.....................................................................................27
ANEXO E DESCRIO DOS CASOS DE USO.........................................................................29
CLIENTE..............................................................................................................................................29
[UC01] Estacionar......................................................................................................................29
[UC02] Ir Embora......................................................................................................................30
OPERADOR..........................................................................................................................................31
[UC03] Efetuar logon................................................................................................................31
[UC04] Efetuar logoff.................................................................................................................32
[UC05] Visualizar Interface do Andar........................................................................................33
[UC06] Classificar Vagas .........................................................................................................34
[UC07] Inserir Figura................................................................................................................35
[UC08] Remover Figura.............................................................................................................36
[UC09] Gerar Relatrio.............................................................................................................37
GERENTE............................................................................................................................................38
[UC10] Listar Gerentes e Operadores........................................................................................38
[UC11] Cadastrar Gerente.........................................................................................................39
[UC12] Excluir Gerente..............................................................................................................40
[UC13] Cadastrar Operador......................................................................................................41
[UC14] Excluir Operador...........................................................................................................42
[UC15] Alterar Senha de Gerente...............................................................................................43
[UC16] Alterar Senha de Operador............................................................................................44
ANEXO F GLOSSRIO................................................................................................................45

olsff, tfds

Pgina 4

10/08/2007

ndice de Figuras
FIGURA 1 MODELAGEM DE DEPENDNCIA ESTRATGICA.............................................17
FIGURA 2 MODELO ESTRATGICO DA RAZO COM ATOR CLIENTE EXPANDIDO.. 18
FIGURA 3 MODELO ESTRATGICO DA RAZO COM ATOR GERENTE EXPANDIDO.19
FIGURA 4 MODELAGEM DE REQUISITOS FUNCIONAIS (CASOS DE USO).....................20
FIGURA 5 MODELAGEM DE REQUISITOS NO FUNCIONAIS............................................21

ndice de Tabelas
TABELA 1 PORCENTAGEM DE ESFORO DOS MEMBROS DA EQUIPE..........................24

1.Introduo
O objetivo desde documento descrever o problema que foi identificado e
especificar os requisitos para a soluo 2 encontrada durante a fase de estudo de
viabilidade realizada previamente. Essa soluo tem como centro um sistema de
informao que deve ser construdo a partir das informaes capturadas pela
utilizao de algumas tcnicas descritas adiante.
O nosso objeto de estudo o Edifcio Garagem do Plaza Shopping Casa
Forte. Tendo em vista o grande nmero de veculos que nele trafegam nos
horrios de pico, o projeto vem com o objetivo de ajudar o motorista a encontrar
uma vaga rapidamente, sem perder tempo andando a esmo pelos andares.

1.1Motivao
Este projeto surge da necessidade de trazer de volta ao shopping clientes
que outrora desistiriam de comprar nele em determinado dia ou horrio para
evitar o estresse de arrumar uma vaga. E claro, queremos atrair novos clientes
em potencial que por conta do mesmo problema descartaram o shopping em
questo.

1.2O Problema Identificado

Detectamos, atravs de uso frequente deste shopping, que no horrio de
pico, quando o Edifcio Garagem est bastante cheio e movimentado, toma-se
muito tempo (entre 5 e 30 minutos) para se achar uma vaga disponvel. tempo
suficiente para perder um filme no cinema, ou se atrasar para um encontro.
Muitas vezes acaba-se encontrando uma vaga bem distante do acesso s lojas, o
que indesejvel para quem estaciona.

1.3Sobre a Organizao
Inaugurado em 1998, o Plaza Shopping Casa Forte localiza-se em uma rea
nobre da cidade, o bairro de Casa Forte, que conta com elevado nmero de
consumidores de alto nvel scio-cultural, predominantemente das classes A e B.
Desde ento o Plaza Shopping Casa Forte alcanou o objetivo de consolidar no
mercado a imagem de um shopping aconchegante, charmoso e diferenciado.

Figura 4 - Edifcio garagem esq., complexo de lojas dir. e passarela suspensa

interligando os dois, ao centro.

Hoje, o Plaza recebe diariamente um fluxo mdio de 20.000 pessoas,

provenientes principalmente de bairros como Casa Forte, Espinheiro, Graas,
Parnamirim, Jaqueira, Aflitos e Poo da Panela. Em sua estrutura, os visitantes
encontram mais de 150 operaes entre lojas, quiosques, 5 salas de cinema e
uma praa de alimentao.
Este shopping, com apenas 11 anos de idade, famoso por sua
impetuosidade em expandir e aperfeioar sua estrutura fsica. So de notvel
importncia nos ltimos 3 anos a construo do Edifcio Garagem com quase 900
vagas, interligado ao shopping por uma elegante passarela suspensa, a
ampliao do shopping com o levantamento de andares extras, repaginao
visual, inaugurao de nova praa de alimentao e de 5 salas de cinema.

1.4Convenes para Identificao dos Requisitos

Por conveno, os requisitos so indicados e referenciados por um
indicador no formato [FRxx], para os requisitos funcionais, e no formato [NFRxx],
para os no funcionais, onde xx se refere ao nmero do requisito. Os requisitos
tambm possuiro os nomes dos casos de uso relacionados.

1.5Convenes para Identificao dos Casos de Uso

Por conveno, os casos de uso so indicados e referenciados por um
indicador no formato [UCxx], onde xx se refere ao nmero do caso de uso.

1.5.1Estrutura dos casos de uso

Cada caso de uso ter o seguinte formato:

Atores: Os modelos de usurio que utilizaro o caso de uso;

Prioridade: Prioridade de implementao deste caso de uso;
Entradas: Variveis que sero passadas ao sistema;
Pr-condies: Condies que devem ser satisfeitas antes de o caso
de uso ser executado;
Fluxo de eventos: O passo a passo das aes realizadas para que o
caso de uso seja concludo, podendo incluir fluxos de eventos
secundrios e/ou alternativos;
Sadas: Sadas que devem ser fornecidas pelo sistema quando o caso
de uso for executado;
Ps-condies: Condies que devem ser satisfeitas depois de o caso
de uso ser finalizado.

1.5.2Prioridades dos casos de uso

Os casos de uso so classificados como:

Essencial: o caso de uso indispensvel ao funcionamento do

sistema. Esse tipo de caso de uso deve ser implementado
impreterivelmente, caso contrrio, o projeto perder sua utilidade.
Importante: Sem este caso de uso, o sistema ainda capaz de ser
utilizado. Contudo, essa utilizao se d de forma no satisfatria pelo
cliente.

Desejvel: Esse tipo de caso de uso poder ser implementado em

verses posteriores do sistema, visto que, mesmo sem a sua
implementao, o sistema atende as suas funcionalidades bsicas.

1.5.3Descrio dos Atores

Os atores so aqueles que interagem de alguma forma com o sistema. Eles
so clientes (motoristas), operadores e gerentes.

2.Requisitos Organizacionais
Os requisitos organizacionais devem satisfazer os objetivos da organizao
e definir porque o sistema necessrio. Esses requisitos so:

Facilitar o estacionamento do cliente tornar a tarefa de estacionar o

veculo mais gil e tranqila;

Obter informaes sobre o uso do estacionamento colher e demonstrar

de forma organizada a forma como o estacionamento vem sendo usado;

3.Requisitos Funcionais
Neste captulo so definidas as funes que o sistema deve realizar. Os
requisitos esto agrupados de acordo com suas caractersticas.

3.1 Mapas dos Andares Exibidos aos Clientes

3.1.1 [RF01] Detectar e Exibir Ocupao de Vaga
Identificao:
Casos
de
relacionados:

[RF02] Detectar e Exibir Ocupao de Vaga

Uso

[UC 01]

Descrio:

Detecta que uma vaga livre foi ocupada. Atualiza o

mapa do andar com esta informao.

Prioridade:

Essencial

Importante

Desejvel

3.1.2 [RF03] Detectar e Exibir Desocupao de Vaga

Identificao:
Casos
de
relacionados:

[RF03] Detectar e Exibir Desocupao de Vaga

Uso

[UC 02]

Descrio:

Detecta que uma vaga ocupada foi desocupada.

Atualiza o mapa do andar com esta informao.

Prioridade:

Essencial

3.1.3 [RF04] Exibir Evento

Identificao:

[RF04] Exibir Evento

Importante

Desejvel

Casos
de
relacionados:

Uso

[UC 07], [UC 08]

Descrio:

Exibe atravs de uma figura no mapa exibido para os

Clientes uma rea onde est ocorrendo um evento
recreativo ou obra do estacionamento.

Prioridade:

Essencial

Importante

Desejvel

3.2 Centro de Controle do Estacionamento

3.2.1 [RF05] Efetuar logon
Identificao:
Casos
de
relacionados:

[RF03] Efetuar logon

Uso

[UC 03]

Descrio:

Permite que o gerente/operador tenha acesso ao

sistema de controle do estacionamento. Para isso, o
gerente deve informar login e senha.

Prioridade:

Essencial

Importante

Desejvel

3.2.2 [RF06] Efetuar logoff

Identificao:
Casos
de
relacionados:
Descrio:

[RF04] Efetuar logoff

Uso

[UC 04]
Permite que o gerente/operador saia do sistema.

Prioridade:

Essencial

Importante

Desejvel

3.2.3 [RF08] Classificar vagas

Identificao:
Casos
de
relacionados:

[RF06] Classificar vagas

Uso

[UC 06]

Descrio:

Classifica um conjunto de vagas de acordo com as

opes: normal, deficiente, idoso, inativa.

Prioridade:

Essencial

Importante

Desejvel

3.2.4 [RF09] Gerar relatrio

Identificao:
Casos
de
relacionados:
Descrio:

[RF09] Gerar relatrio

Uso

[UC 09]
Gera um relatrio do uso do estacionamento.

Prioridade:

Essencial

Importante

Desejvel

3.2.5 [RF10] Cadastrar Gerente

Identificao:
Casos
de
relacionados:
Descrio:
Prioridade:

[RF10] Cadastrar Gerente

Uso

[UC 11]
Cadastra um novo gerente.
Essencial

Importante

3.2.6 [RF11] Cadastrar Operador

Identificao:

[RF11] Cadastrar Operador

Desejvel

Casos
de
relacionados:
Descrio:

Uso

[UC 13]
Cadastra um novo operador.

Prioridade:

Essencial

Importante

Desejvel

3.2.7 [RF12] Excluir Gerente

Identificao:
Casos
de
relacionados:
Descrio:

[RF09] Excluir Gerente

Uso

[UC 12]
Remove um gerente j cadastrado.

Prioridade:

Essencial

Importante

Desejvel

3.2.8 [RF13] Excluir Operador

Identificao:
Casos
de
relacionados:
Descrio:

[RF13] Excluir Operador

Uso

[UC 14]
Remove um operador j cadastrado.

Prioridade:

Essencial

Importante

Desejvel

3.2.9 [RF14] Alterar Senha de Gerente

Identificao:
Casos
de
relacionados:
Descrio:

[RF14] Alterar Senha de Gerente

Uso

[UC 15]
Redefine a senha de um Gerente

Prioridade:

Essencial

Importante

Desejvel

3.2.10 [RF15] Alterar Senha de Operador

Identificao:
Casos
de
relacionados:
Descrio:

[RF15] Alterar Senha de Operador

Uso

[UC 16]
Redefine a senha de um Operador.

Prioridade:

Essencial

Importante

Desejvel

3.2.11 [RF16] Listar Gerentes e Operadores

Identificao:
Casos
de
relacionados:

[RF16] Listar Gerentes e Operadores

Uso

[UC 10]

Descrio:

Exibe uma lista completa dos Gerentes e Operadores

cadastrados.

Prioridade:

Essencial

Importante

Desejvel

4.Requisitos No-Funcionais
Este captulo descreve requisitos relacionados com restries e aspectos
de qualidade. A classificao desses requisitos segue o autor [Sommerville], que
agrupa os mesmos em trs grupos, a saber: requisitos de processo, requisitos de
produto e requisitos externos.

4.1Requisitos de Processo
4.1.1[NFR01] Utilizar Extreme Programming como Metodologia de
Desenvolvimento
[NFR01] Utilizar Extreme Programming (XP) como
Metodologia de Desenvolvimento

Identificao:
Casos
de
relacionados:

Uso

Todos.

Descrio:

O XP ser a metodologia empregada, pois permite

agilidade e participao ativa dos stakeholders. Alm
disso, como o sistema de fcil utilizao, no ser
necessria a gerao de uma documentao formal
extensa.

Prioridade:

Essencial

Importante

Desejvel

4.1.2[NFR02] Utilizar Linguagem C++

Identificao:
Casos
de
relacionados:
Descrio:

[NFR02] Utilizar Linguagem C++

Uso

Todos.
A aplicao dever ser toda desenvolvida em C++.

Prioridade:

Essencial

Importante

Desejvel

4.1.3 [NFR03] Utilizar Banco de Dados MySQL

Identificao:
Casos
de
relacionados:

[NFR03] Utilizar Banco de Dados MySQL

Uso

Todos.

Descrio:

Esse sistema de banco de dados oferece os recursos

bsicos necessrios aplicao e economicamente
vivel.

Prioridade:

Essencial

Importante

Desejvel

4.2Requisitos de Produto
4.2.1Usabilidade
4.2.1.1 -[NFR04] Mensagens de Erro

Identificao:
Casos
de
relacionados:

[NFR04] Mensagens de Erro

Uso

Casos de uso referentes a gerente/operador.

As mensagens de erro devero ser objetivas,
orientando o usurio a solucionar o problema. Elas
sero exibidas com um mnimo de impacto no fluxo da
aplicao.
Essencial
Importante
Desejvel

Descrio:
Prioridade:

4.2.1.2 -[NFR05] Interface do Sistema para o Gerente

Identificao:
Casos
de
relacionados:

[NFR05] Interface do Sistema para o Gerente

Uso

Casos de uso referentes a gerente/operador.

A Interface Grfica do Usurio (GUI) dever prover a
comunicao entre o usurio e o sistema para que ele
tenha fcil acesso a todas as funcionalidades do
sistema e de forma objetiva. A GUI dever seguir
regras de Usabilidade e as informaes devero estar
bem intuitivas.
Essencial
Importante
Desejvel

Descrio:

Prioridade:

4.2.1.3 -[NFR06] Interface do Sistema para o Cliente

Identificao:
Casos
de
relacionados:

[NFR06] Interface do Sistema para o Cliente

Uso

Casos de uso referentes ao Cliente.

Descrio:

A Interface Grfica do Usurio (GUI) dever conter um

mapa do andar em questo e a porcentagem de
ocupao do mesmo. O mapa dever ocupar espao
suficiente para ser facilmente visualizado pelo cliente
de dentro do seu carro. A orientao do mapa dever
estar de acordo com a direo do veculo do cliente.
O cliente fornece informao ao sistema de forma
transparente, simplesmente estacionando ou retirando
o carro da vaga.

Prioridade:

Essencial

Importante

Desejvel

4.2.1.4 -[NFR07] Intervalo para Liberao de Vaga

Identificao:
Casos
de
relacionados:

[NFR07] Intervalo para Liberao de Vaga

Uso

[UC02]

Descrio:

Uma vaga ocupada s dever constar como

desocupada no mapa, aps um intervalo de 10
segundos em que o sensor indique ausncia de
veculo. Para que um carro que manobra para sair no
passe informao errada.

Prioridade:

Essencial

Importante

Desejvel

4.2.1.5 -[NFR08] Destacar Vagas Especiais

Identificao:
Casos
de
relacionados:
Descrio:

[NFR08] Destacar Vagas Especiais

Uso

[UC 01], [UC 05], [UC 06]

As vagas para Idosos e Deficientes, devem ser exibidas
no mapa com cores diferentes das demais.
Essencial
Importante
Desejvel

Prioridade:

4.2.2Confiabilidade
4.2.2.1 - [NFR09] Disponibilidade

Identificao:
Casos
de
relacionados:
Descrio:

Prioridade:

[NFR09] Disponibilidade
Uso

Todos.
O Sistema no dever ficar indisponvel por erros de
utilizao dos usurios. Sua recuperao deve ser
imediata e os usurios devero ser orientados para
no tornar a repetir o erro. Alm disso, o sistema
dever estar no ar 98% do tempo.
Essencial
Importante
Desejvel

4.2.3Segurana
4.2.3.1 -[NFR10] Integridade

Identificao:

[NFR10] Integridade

Casos
de
relacionados:
Descrio:

Uso

Todos.
Os dados armazenados e consultados devero estar
corretos em relao aos dados fornecidos ao sistema.

Prioridade:

Essencial

Importante

Desejvel

4.2.3.2 -[NFR11] Backup

Identificao:
Casos
de
relacionados:

[NFR11] Backup
Uso

Todos.

Descrio:

A cpia de segurana do banco de dados para

recuperao ou armazenamento deve ser realizada
numa periodicidade de cada semana.

Prioridade:

Essencial

Importante

Desejvel

4.2.3.3 -[NFR12] Privacidade

Identificao:
Casos
de
relacionados:
Descrio:

[NFR12] Privacidade
Uso

Todos.
Apenas os Gerentes e Operadores podem gerar o
relatrio do uso do estacionamento.

Prioridade:

Essencial

Importante

Desejvel

4.2.4Desempenho
4.2.4.1 -[NFR13] Tempo de Resposta

Identificao:
Casos
de
relacionados:

[NFR13] Tempo de Resposta

Uso

Todos.

Descrio:

Aps a ocupao/desocupao de uma vaga, o sistema

dever receber a informao do sensor de presena
dentro de 1 segundo.

Prioridade:

Essencial

Importante

Desejvel

4.2.4.2 -[NFR14] Espao de armazenamento

Identificao:
Casos
de
relacionados:
Descrio:

[NFR14] Espao de armazenamento

Uso

Todos.
O espao de armazenamento utilizado para guardar as
informaes do sistema no deve exceder 85% da

capacidade de armazenamento do servidor.

De dadosPrioridade:

Essencial

Importante

Desejvel

4.3Requisitos Externos
4.3.1[NFR15] Oramento
Identificao:
Casos
de
relacionados:

[NFR15] Oramento
Uso

Todos.
O custo, com o desenvolvimento do sistema, no

Descrio:

poder superar o estimado no Estudo de Viabilidade.

Prioridade:

Essencial

Importante

Desejvel

4.3.2[NFR16] Tempo de desenvolvimento

Identificao:
Casos
de
relacionados:

[NFR16] Tempo de desenvolvimento

Uso

Todos.

Descrio:

O tempo com o desenvolvimento do sistema no

poder superar em mais de 30% o estimado no Estudo
de Viabilidade.

Prioridade:

Essencial

Importante

Desejvel

5.Modelagem Organizacional
A modelagem organizacional utilizada feita com base na notao i* (i
estrela).

5.1Modelagem de Dependncia Estratgica

Figura 1 Modelagem de Dependncia Estratgica.

Modelo de dependncia estratgica onde so apresentados trs atores: o
cliente, o gerente e o sistema. Conforme o nome do modelo, esto listadas as
dependncias entre os atores, onde a direo do da seta (D) indica que o ator
que est antes depende do ator apontado.
Neste modelo est representado que o cliente necessita do sistema para
obter informaes do estacionamento e espera que o sistema facilite a sua
atividade de estacionar. Enquanto o gerente precisa do sistema para as atividade
de registro de eventos e observao da ocupao do estacionamento. E o
sistema depende do gerente para obter a classificao das vagas e do cliente
para saber se as vagas esto ocupadas.

5.2Modelo Estratgico da Razo

Figura 2 Modelo estratgico da razo com ator Cliente expandido.

O modelo estratgico da razo difere do modelo de dependncias, pois ele
explicita como e porque o ator executa suas atividades.
Na figura acima apenas o cliente foi expandido, demonstrando sua
atividade principal de estacionar sendo dividida no ato de encontrar a vaga e de
colocar o carro na vaga. Em seguida para encontrar uma vaga o cliente precisa
procurar uma vaga e durante essa busca ele espera obter uma ajuda do sistema
para facilitar essa atividade. Portanto o cliente depende do sistema com as
informaes do estacionamento para procurar a vaga e ao colocar o carro na
vaga o sistema reconhece a vaga como ocupada.

Figura 3 Modelo estratgico da razo com ator Gerente expandido.

Na figura acima o ator gerente foi expandido, demonstrando sua atividade
principal de gerenciar o estacionamento, correspondendo atividade de
acompanhar a situao do estacionamento, a tentativa de melhorar o fluxo de
clientes e a meta de manter a informao atualizada para o cliente. Fornecendo
informao para o sistema ele conclui sua meta e ajuda no fluxo de clientes. As
vagas so classificadas pelo gerente, mantendo o sistema atualizado.

6.Modelagem de Requisitos Funcionais (Casos de Uso)

Neste captulo, os requisitos descritos anteriormente so modelados
atravs de diagramas de caso de uso. O detalhamento dos casos de uso
encontra-se no Anexo E deste documento.

Figura 4 Modelagem de Requisitos Funcionais (Casos de Uso)

7.Modelagem de Requisitos No-Funcionais (NFR Framework)

Este captulo contm os refinamentos dos requisitos no-funcionais,
descreve suas interdependncias e operacionalizaes.

Figura 5 Modelagem de Requisitos No Funcionais

Na figura acima esto listadas algumas necessidades do sistema, que so:
usabilidade, segurana, confiabilidade e desempenho; para cada uma delas so
decompostas em outras necessidades e descritas uma forma de atender a elas.
A usabilidade garantida atravs de outras necessidades atendidas:
simplicidade, expressividade, transparncia e consistncia. Onde a coleta de
informao de forma implcita, ou seja, o cliente no necessita informar o
sistema de forma explicita que estacionou o carro, ajuda na simplicidade, fornece
transparncia e ajuda na integridade do sistema. Para manter a simplicidade
todas as informaes sero mostradas em uma nica tela evitando a
necessidade do cliente navegar no sistema para obter tal informao e para que
toda a informao seja passada de forma eficiente sero usadas cores diferentes
para os tipo de vagas e demonstrar se est ocupada ou livre. Como o sistema
baseado em sensores para evitar que a situao da vaga pisque enquanto o
motorista esta fazendo a manobra foi proposto um intervalo para a liberao das
vagas.
Para garantir a segurana do sistema, as informaes s sero exibidas ao
operador aps ele registrar o login e senha. E para o sistema no perder

informaes importantes ser feito um backup das informaes com a freqncia

de uma vez por semana.
Para manter a confiabilidade foi proposto a realizao de treinamento para
os operadores do sistema e manter o sistema sempre disponvel.
O desempenho do sistema avaliado pelo tempo de resposta e o espao
de armazenamento onde indicado a compactao dos dados antigos para
reduzir o espao necessrio para o armazenamento.

8.Concluso
Atravs do documento de requisitos, foi possvel entender, atravs de uma
breve descrio nas sees 1 e 2, o problema a ser resolvido com o sistema
InformaTurma.
Em seguida foram apresentados todos os requisitos funcionais do sistema,
isto , todos os servios que o InformaTurma deve oferecer aos seus usurios,
segundo a definio do cliente.
Seguindo os requisitos funcionais, no captulo 4 foram apresentados os
requisitos no-funcionais, que iro definir restries de como o sistema ir
funcionar baseado em seus requisitos funcionais.
No captulo 5, foi abordada a modelagem organizacional do sistema
usando a notao i*, em que foram includos os modelos de dependncia
estratgica (SD) e o modelo estratgico de razo (SR) com os atores
InformaTurma e Formando expandidos.
No captulo 6, dando continuidade modelagem de requisitos funcionais,
atravs do diagrama de casos de uso, foram descritos os casos de uso do
sistema, incluindo seus fluxos de eventos e dependncias entre si.
Finalmente, no captulo 7, foi feita a modelagem dos requisitos nofuncionais utilizando a plataforma NFR, mostrando os refinamentos deles,
explicitando operacionalizaes e interdependncias entre eles.

Referncias
[Disciplina] Disciplina de Especificao de Requisitos e Validao de
Sistemas. Disponvel em: <http://www.cin.ufpe.br>. Acesso em: 31 jul. 07.
[Hackos] Hackos, Joann T. and Redish, Janice, User and Task Analysis for
Interface Design, John Wiley & Sons.
[i*] i* - An Agent-oriented Modelling Framework. Disponvel em:
<http://www.cs.toronto.edu/km/istar/>. Acesso em: 01 ago. 07.
[Projeto] Documento de Estudo de Viabilidade. Disponvel em:
<http://www.cin.ufpe.br/~apba>. Acesso em: 31 jul. 07.
[Sommerville] G. Kotonya and I. Sommerville, Requirements Engineering :
Processes and
Techniques , John Wiley & Sons, 1998.
[Wikipdia] Wikipdia. A enciclopdia livre. Disponvel em:
<http://www.wikipedia.org>. Acesso em: 01 ago. 07.

Relatrio da Equipe
Nesta ltima seo, segue a porcentagem de esforo de cada membro da
equipe. As atividades realizadas por cada um esto descritas no Histrico de
Revises deste documento.
Nome

Esforo da equipe (%)

Ana Alves

25%

Bruno Ribeiro

25%

Grasielle Valena

25%

Marcela Bezerra

25%

Assinatura

Tabela 1 Porcentagem de esforo dos membros da equipe.

Anexo A Tcnicas Utilizadas na Coletas de Dados

Foram utilizadas trs tcnicas de coleta de dados: Questionrio, Entrevista
narrativa e Coleta de Artefatos. As mesmas sero descritas a seguir.

Questionrio
Questionrio uma tcnica de investigao composta por um nmero
mais ou menos elevado de questes apresentadas por escrito a pessoas que tem
por objetivo propiciar determinado conhecimento ao pesquisador. [Wikipdia] O
questionrio aplicado Grasielle Valena, assim como as respostas dadas
encontram-se no Anexo B.

Entrevista Narrativa
Tcnica de coleta de dados que permite que o entrevistador obtenha
histrias de situaes e comportamentos reais em um curto intervalo de tempo.
Primeiro perguntado ao entrevistado para lembrar uma situao especfica.
Depois disso, so feitas questes que haviam sido planejadas. Volta-se a pedir
que o entrevistado lembre outra situao e depois mais perguntas so feitas.
Perguntar sobre situaes especficas permite que se concentre em
comportamentos e tarefas mesmo que no se esteja falando sobre ou
observando o trabalho. [Hackos]
As situaes que Grasielle Valena precisou relembrar esto transcritas no
Anexo C. Foram elas:

Cite um episdio em que houve atrito entre comisso e formandos para a

tomada de decises;

Cite um episdio em que houve falha de comunicao entre comissao e

formandos.

Coleta de Artefatos
Nessa tcnica o observador coleta artefatos que so mencionados durante
a descrio de um processo ou atividade, como anotaes feitas mo,
formulrios, relatrios, sadas de processos e registros que servem para o usurio
lembrar do progresso de trabalho. Os artefatos podem ser teis no entendimento
de como o processo feito e como o mesmo pode ser continuado ou melhorado
com o desenvolvimento de novos processos, softwares e documentao. Se for
planejada a mudana ou eliminao desses artefatos, deve-se antes estudar
como essa alterao pode afetar outras pessoas ou outros processos. [Hackos]
Os artefatos coletados esto no Anexo D. Foram eles:

Mensagens trocadas durante uma votao por e-mail;

Ata de reunio da comisso de formatura.

Anexo B Questionrio
1. Qual o maior problema encontrado na comisso?

O grande problema pra ns da comisso a comunicao, uma

questo to simples e complicada ao mesmo tempo. incrvel a
quantidade de mal entendido e insatisfaes que foi gerada por uma m
comunicao.
Em segundo vem o gerenciamento do nosso tempo e das funes
agregadas enquanto membro da comisso. H muito o que se organizar,
pensar e decidir, mas nem sempre se consegue fazer da melhor maneira.
2. Qual(is) o requisito(s) essencial(is) em um sistema que auxiliasse a
comisso a desenvolver essa funo?
Sem dvida a ferramenta no poderia deixar de ter um suporte a votao.
Tanto uma votao restrita a comisso como abrangendo todos os
formandos, Isso facilitaria bastante o trabalho. Muitas vezes queremos que
os formandos apenas diga sim ou no, mas a maioria das vezes
gerado threads enormes que no nos levam a canto nenhum.
3. Hoje em dia, qual o sistema utilizado pela comisso para realizar votaes
com o intuito de alguma tomada de deciso?
O mecanismo mais utilizado realmente o e-mail. No incio, quando os
alunos estavam mais na faculdade, pagando cadeiras obrigatrias, era
mais fcil realizar reunies presenciais. Pois tnhamos quase o mesmo
horrio, mas ainda assim o qurum nem sempre era razovel. E com o
incio das cadeiras eletivas, pronto, piorou de vez. No se conseguia nem
10% da turma. Foi quando resolvemos apelar de vez para os e-mails, mas
como j citei mais acima, sempre h muita disperso do objetivo principal.
Quase na totalidade so geradas discusses interminveis.
4. Quais os pontos positivos e negativos da utilizao de e-mail?
Bom, com o e-mail mais fcil saber a opinio das pessoas e registr-las.
Todavia o controle meio crtico, se perde muito tempo contabilizando os
votos, muitas vezes os formandos mandam e-mail para o lugar errado.
5.

Como a comisso se comunica entre si?

Bom, criamos um grupo no gmail e um e-mail, este tambm serve
para comunicao com os formandos. atravs do googlegroup que nos
comunicamos com maior freqncia, expomos nossas dvidas, emitimos
opinies e mesmo, votamos.

6. Voc poderia dizer que esse sistema de grupo suficiente para vocs?
No, ajuda bastante, mas ainda falta um maior controle dos tpicos.

Anexo C Entrevista Narrativa

Cite um episdio em que houve atrito entre comisso e formandos para a

tomada de decises;
Bom uma das maiores discusses geradas, rendendo uma thread com mais de
100 e-mails, foi relativa a roupa a se usar nas fotos. Primeiro queriam que

abrssemos votao para roupa da foto em grupo e depois que existissem

vrias opes de escolha para a foto oficial. Cada um que sugerisse uma coisa
diferente e achasse que deveramos acatar. E como sempre o objetivo inicial
di desvirtuado.

Cite um episdio em que houve falha de comunicao entre comisso e

formandos.
Esse fato tambm ocorreu h pouco tempo. Fizemos uma votao para o
professor homenageado, s que dois professores empataram. Colocamos o
resultado em um documento e nesse mesmo documento tinha um aviso pra
enviar um e-mail desempatando os professores, s q muita gente nem soube
dessa votao.

Anexo D Artefatos Coletados

A ata da Comisso um item confidencial.

Anexo E Descrio dos Casos de Uso

Cliente
[UC01] Estacionar
Identificador:

[UC 01]

Descrio:

Cliente estaciona na vaga e o sistema a reconhece como

ocupada.

Ator:

Cliente.

Prioridade:

Essencial

Pr-condies:

A vaga precisa estar classificada como ativa.

Ps-condies:

Vaga registrada como ocupada.

Fluxo de Eventos Principal

1. Sistema mostra as vagas livres no mapa do andar;

2. Cliente l o mapa e se dirige vaga;
3. Cliente pe o carro na vaga;
4. Sensor de presena acionado;
5. Sistema reconhece a vaga como ocupada.
Requisitos
Especficos

No

Funcionais -

[UC02] Ir Embora
Identificador:

[UC 02]

Descrio:

Ao cliente ir embora o sistema reconhece que a vaga est

livre.

Ator:

Cliente.

Prioridade:

Essencial

Pr-condies:

A vaga precisa estar classificada como ativa.

Ps-condies:

Vaga registrada como livre.

Fluxo de Eventos Principal

1. Cliente retira o carro da vaga;

2. Sensor de presena acionado;
3. Sensor acionado;
4. Sistema reconhece a vaga como livre.
Requisitos
Especficos

No

Funcionais -

Operador
[UC03] Efetuar logon
Identificador:

[UC 03]

Descrio:

Autentica o usurio no sistema.

Ator:

Operador, Gerente

Prioridade:

Essencial

Pr-condies:

No se aplica.

Ps-condies:

O ator ter acesso s funcionalidades do sistema que lhe

dizem respeito.
Fluxo de Eventos Principal

1. Estando na tela inicial do sistema, o ator deve preencher os campos

login e senha;
2. O ator ento clica no boto OK.
Fluxo Secundrio 1
1. O ator fornece um login no cadastrado no sistema;
2. A mensagem Usurio inexistente exibida;
3. Sistema retorna ao passo 1 do Fluxo de Eventos Principal.
Fluxo Secundrio 2
1. O ator fornece um login e uma senha no correspondentes;
2. A mensagem Senha incorreta exibida.
3. Sistema retorna ao passo 1 do Fluxo de Eventos Principal.
Requisitos
Especficos

No

Funcionais -

[UC04] Efetuar logoff

Identificador:

[UC 04]

Descrio:

Finaliza o acesso ao sistema.

Atores:

Operador, Gerente

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema

Ps-condies:

O ator deixa de ter acesso s funcionalidades do sistema. O

sistema retorna tela inicial.
Fluxo de Eventos Principal

1. O ator clica no boto Sair;

2. O sistema volta tela de logon.
Requisitos
Especficos

No

Funcionais -

[UC05] Visualizar Interface do Andar

Identificador:

[UC 05]

Descrio:

O ator visualiza um andar para fiscaliz-lo e edit-lo

Ator:

Operador, Gerente

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema.

Ps-condies:

Fluxo de Eventos Principal

1. Ator seleciona o andar que quer visualizar;

2. Sistema exibe o mapa do andar com a distribuio de vagas, sua
respectiva ocupao, e as opes de edio do andar;
Requisitos
Especficos

No

Funcionais -

[UC06] Classificar Vagas

Identificador:

[UC 06]

Descrio:

Classifica uma ou mais vagas

Atores:

Operador, Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema.

Ps-condies:

As vagas tero nova classificao, e portanto nova exibio

no mapa.
Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC05] Visualizar Andar;

3. Ator seleciona um conjunto de vagas;
4. Sistema exibe uma lista com as classificaes de vaga possveis;
5. Ator seleciona a nova classificao;
6. Sistema atualiza o mapa e exibe opo para salvar as alteraes;
7. Ator clica em Salvar;
8. Sistema salva as alteraes e as exibe automaticamente no mapa
exibido para os Clientes.
Requisitos
Especficos

No

Funcionais -

[UC07] Inserir Figura

Identificador:

[UC 07]

Descrio:

Insere uma figura no mapa de um andar, numa regio onde

no h vagas ativas.

Atores:

Operador, Gerente.

Prioridade:

Importante

Pr-condies:

O ator deve estar logado no sistema.

Ps-condies:

Uma figura ser exibida no mapa, para os Clientes que

estiverem no andar.
Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC05] Visualizar Andar;

2. Ator clica em Inserir Figura;
3. Sistema exibe uma janela para o ator procurar um arquivo no
computador;
4. Ator seleciona um arquivo de imagem;
5. Sistema exibe o mapa do andar ocupado pela figura e exibe opo para
salvar as alteraes;
6. Ator redimensiona a figura, de forma a no sobrepor nenhuma vaga
ativa;
7. Ator clica em Salvar;
8. Sistema salva as alteraes e as exibe automaticamente no mapa
exibido para os Clientes.
Fluxo Secundrio 1
1. No passo 7 do fluxo principal, a figura est sobrepondo pelo menos uma
vaga ativa;
2. A mensagem Figura no pode sobrepor vagas ativas exibida;
3. Ator clica ou aperta qualquer boto do teclado;
4. Sistema volta ao passo 5 do fluxo principal.
Fluxo Secundrio 2
1. No passo 4 do fluxo principal, o ator escolhe um tipo de arquivo no
suportado;
2. exibida uma mensagem com os tipos de arquivo suportados;
3. Ator clica ou aperta qualquer boto do teclado;
4. Sistema volta ao passo 3 do fluxo principal.
Requisitos
Especficos

No

Funcionais -

[UC08] Remover Figura

Identificador:

[UC 08]

Descrio:

Remove uma figura inserida no mapa de um andar.

Atores:

Operador, Gerente.

Prioridade:

Importante

Pr-condies:

O ator deve estar logado no sistema.

Ps-condies:

A figura do mapa no mais ser exibida para os Clientes que

estiverem no andar.
Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC05] Visualizar Andar;

2. Ator clica na figura;
3. Sistema exibe opo Remover Figura;
4. Ator seleciona a opo exibida;
5. Sistema exibe o mapa do andar sem a figura e exibe opo para salvar
as alteraes;
6. Ator clica em Salvar;
7. Sistema salva as alteraes e as exibe automaticamente no mapa
exibido para os Clientes.
Requisitos
Especficos

No

Funcionais -

[UC09] Gerar Relatrio

Identificador:

[UC 09]

Descrio:

Sistema gera um relatrio do uso do estacionamento a partir

de requisio do ator.

Ator:

Operador, Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema. O ator deve estar na tela

inicial.

Ps-condies:

Um relatrio gerado.
Fluxo de Eventos Principal

1. Ator clica em Gerar Relatrio;

2. Sistema gera relatrio, salva-o e o exibe na tela.
Requisitos
Especficos

No

Funcionais -

Gerente
[UC10] Listar Gerentes e Operadores
Identificador:

[UC 10]

Descrio:

Lista todos os Gerentes e Operadores do sistema.

Ator:

Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema. O ator deve estar na tela

inicial.

Ps-condies:

Uma lista de todos os Gerentes e Operadores do sistema

exibida.
Fluxo de Eventos Principal

1. Ator clica em Listar Gerentes;

2. Sistema exibe uma lista completa
cadastrados em ordem alfabtica;
Requisitos
Especficos

No

Funcionais -

dos

Gerentes

Operadores

[UC11] Cadastrar Gerente

Identificador:

[UC 11]

Descrio:

Cadastra um novo Gerente.

Ator:

Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema. O ator deve estar na tela

inicial.

Ps-condies:

Um novo Gerente estar habilitado a logar e usar o sistema.

Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC10] Listar Gerentes e

Operadores;
2. Ator clica em Cadastrar Gerente/Operador
3. Sistema exibe um formulrio para cadastro de novo gerente;
4. Ator preenche o formulrio;
5. Ator seleciona a opo "Gerente";
6. Ator clica em Ok;
7. Sistema exibe a lista atualizada de Gerentes e Operadores.
Fluxo Secundrio 1
1. No passo 6 do fluxo principal, h algum campo incompleto;
2. Sistema exibe a mensagem "preencha todos os campos";
3. Sistema volta ao formulrio semi-preenchido.
Requisitos
Especficos

No

Funcionais -

[UC12] Excluir Gerente

Identificador:

[UC 12]

Descrio:

Exclui um Gerente.

Ator:

Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema. O ator deve estar na tela

inicial.

Ps-condies:

Um Gerente excludo.
Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC10] Listar Gerentes e

Operadores;
2. O ator seleciona um Gerente da lista;
3. O ator clica em Excluir;
4. O sistema exibe uma janela pedindo confirmao;
5. O ator clica em Ok;
6. O sistema exclui o Gerente do sistema;
7. O sistema exibe a lista atualizada de Gerentes e Operadores.
Fluxo Secundrio 1
1. No passo 3 do fluxo principal, o Gerente tentou excluir a si prprio;
2. Sistema exibe a mensagem "Um Gerente no pode se excluir.";
3. Ator clica ou aperta qualquer boto do teclado;
4. Sistema volta a exibir a lista atualizada de Gerentes e Operadores.
Requisitos
Especficos

No

Funcionais -

[UC13] Cadastrar Operador

Identificador:

[UC 13]

Descrio:

Cadastra um novo Operador.

Ator:

Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema. O ator deve estar na tela

inicial.

Ps-condies:

Um novo Operador estar habilitado a logar e usar o sistema.

Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC10] Listar Gerentes e

Operadores;
2. Ator clica em Cadastrar Gerente/Operador
3. Sistema exibe um formulrio para cadastro de novo gerente;
4. Ator preenche o formulrio;
5. Ator seleciona a opo "Operador";
6. Ator clica em Ok;
7. Sistema exibe a lista atualizada de Gerentes e Operadores.
Fluxo Secundrio 1
1. No passo 6 do fluxo principal, h algum campo incompleto;
2. Sistema exibe a mensagem "preencha todos os campos";
3. Sistema volta ao formulrio semi-preenchido.
Requisitos
Especficos

No

Funcionais -

[UC14] Excluir Operador

Identificador:

[UC 14]

Descrio:

Exclui um Operador.

Ator:

Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema. O ator deve estar na tela

inicial.

Ps-condies:

Um Operador excludo.
Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC10] Listar Gerentes e

Operadores;
2. O ator seleciona um Operador da lista;
3. O ator clica em Excluir;
4. O sistema exibe uma janela pedindo confirmao;
5. O ator clica em Ok;
6. O sistema exclui o Operador do sistema;
7. O sistema exibe a lista atualizada de Gerentes e Operadores.
Requisitos
Especficos

No

Funcionais -

[UC15] Alterar Senha de Gerente

Identificador:

[UC 15]

Descrio:

Altera a senha de um Gerente.

Ator:

Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema. O ator deve estar na tela

inicial.

Ps-condies:

Um Gerente ter uma nova senha.

Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC10] Listar Gerentes e

Operadores;
2. Ator seleciona um Gerente da lista;
3. Ator clica em Nova Senha;
4. Sistema exibe um campo para o ator digitar a nova senha;
5. Ator digita a nova senha;
6. Ator clica em Ok;
7. Sistema guarda a nova senha do Gerente em questo;
8. Sistema exibe a lista atualizada de Gerentes e Operadores.
Fluxo Secundrio 1
1. No passo 6 do fluxo principal, o campo de senha est fazio;
2. Sistema exibe a mensagem "preencha todos os campos";
3. Sistema volta ao formulrio semi-preenchido.
Requisitos
Especficos

No

Funcionais -

[UC16] Alterar Senha de Operador

Identificador:

[UC 16]

Descrio:

Altera a senha de um Operador.

Ator:

Gerente.

Prioridade:

Essencial

Pr-condies:

O ator deve estar logado no sistema. O ator deve estar na tela

inicial.

Ps-condies:

Um Operador ter uma nova senha.

Fluxo de Eventos Principal

1. Incluir o fluxo de eventos do caso de uso [UC10] Listar Gerentes e

Operadores;
2. Ator seleciona um Operador da lista;
3. Ator clica em Nova Senha;
4. Sistema exibe um campo para o ator digitar a nova senha;
5. Ator digita a nova senha;
6. Ator clica em Ok;
7. Sistema guarda a nova senha do Operador selecionado;
8. Sistema exibe a lista atualizada de Gerentes e Operadores.
Fluxo Secundrio 1
1. No passo 6 do fluxo principal, o campo de senha est fazio;
2. Sistema exibe a mensagem "preencha todos os campos";
3. Sistema volta ao formulrio semi-preenchido.
Requisitos
Especficos

No

Funcionais -

Anexo F Glossrio

Banco de dados MySQL: O programa 'MySQL' um sistema de

gerenciamento de banco de dados relacionais baseado em comandos SQL
(Structured Query Language - Linguagem Estruturada para Pesquisas) que vem
ganhando grande popularidade, sendo atualmente um dos bancos de dados mais
populares, com mais de 4 milhes de instalaes.

Login: Trata-se de uma seqncia de caracteres utilizada para identificar

um usurio de forma nica.

Log on: Termo utilizado para demonstrar a ao de um usurio quando

entra no sistema dom login e senha.

Log off: Termo utilizado para demonstrar a ao de um usurio quando

este sai do sistema.

Notao i*: Abordagem criada por John Mylopoulos e EricYu, na

Universidade de Toronto para descrio de requisitos organizacionais.