Aula 02 - Engenharia de Requisitos

Engenharia de Requisitos

Alberto Sim˜es
o
alberto.simoes@eu.ipp.pt

Planeamento de Sistemas de Informa¸˜o
ca
Mestrado em Informa¸˜o Empresarial
ca
2012/2013

Alberto Sim˜es
o Engenharia de Requisitos 1/62

Parte I


Alberto Sim˜es

Tamb´m designada por An´lise de Sistemas;
e a

´
E o processo de definir as funcionalidades que o cliente
pretende que o sistema implemente, e as restri¸˜es que afetam
co
a opera¸õ e o desenvolvimento do sistema;
ca

O objetivo da fase de an´lise ´ o de compreender os requisitos
a e
do novo sistema e identifica-los de modo a desenvolver um
sistema que os satisfa¸a completamente;
c

A determina¸õ de requisitos ´ um dos passos mais cr´
ca e ıticos
nas fases do ciclo de desenvolvimento de software;

Alberto Sim˜es


O que ´ a Engenharia de Requisitos?
e
Processo que envolve a recolha e compila¸˜o dos requisitos de
ca
sistema

Alberto Sim˜es


e
ca
sistema
Quanto custa a Engenharia de Requisitos?
Habitualmente, cerca de 15% do custo de desenvolvimento do
sistema.

Alberto Sim˜es


e
ca
sistema
sistema.
O que ´ um processo de Engenharia de Requisitos?
e
Conjunto de actividades que envolve a recolha e compila¸˜o
ca
dos requisitos de sistema.

Alberto Sim˜es


e
ca
sistema
sistema.
e
ca
O que acontece quando os requisitos sõ mal identificados?
a
Os sistemas sõ entregues fora do prazo, sem qualidade e sem
a
responder `s necessidades dos clientes.
a

Alberto Sim˜es


e
ca
sistema
sistema.
e
ca
O que acontece quando os requisitos sõ mal identificados?
a
Os sistemas sõ entregues fora do prazo, sem qualidade e sem
a
responder `s necessidades dos clientes.
a
Existe algum processo de Engenharia de Requisitos ideal?
Nõ, o processo tem de ser configurado de acordo com as
a
necessidades de cada organiza¸õ.
ca
Alberto Sim˜es

Problemas na Engenharia de Requisitos
Como convencer o cliente da necessidade de usar tempo e dinheiro,
para recolher requisitos corretamente?

Alberto Sim˜es

Problemas na Engenharia de Requisitos
Como garantir que os requisitos recolhidos s˜o compreendidos de
a
igual modo por cliente e membros da equipa do projeto?

Alberto Sim˜es

Processo de Engenharia de Requisitos

Os processos utilizados na engenharia de requisitos sõ
a
dependentes do dom´ de aplica¸õ, das pessoas envolvidas
ınio ca
e das organiza¸õ que faz o levantamento dos requisitos.
ca

Alberto Sim˜es


Os processos utilizados na engenharia de requisitos sõ
a
dependentes do dom´ de aplica¸õ, das pessoas envolvidas
ınio ca
e das organiza¸õ que faz o levantamento dos requisitos.
ca

No entanto, existem algumas atividades gen´ricas, comuns a
e
todos os processos:
estudo de viabilidade;
levantamento e sele¸õ de requisitos;
ca
an´lise de requisitos;
a
valida¸õ de requisitos;
ca
gestõ de requisitos;
a

Alberto Sim˜es


Estudo de Análise de
Viabilidade Requisitos

Definição de
Requisitos

Especificação
Relatório de Modelos do de Requisitos
Viabilidade Sistema
Defnição dos
Requisitos

Especificação de
Documento de Requisitos
Requisitos

Alberto Sim˜es

Estudo de Viabilidade

Deve decidir se um sistema deve ser ou n˜o desenvolvido.
a

Alberto Sim˜es


a
Trata-se de um estudo espec´ıfico que verifica se o sistema
contribui para os objetivos da organiza¸õ;
ca
pode ser desenvolvido com a tecnologia atual;
pede ser desenvolvido dentro do or¸amento previsto;
c
pode ser integrado com os outros sistemas em produ¸õ;
ca

Alberto Sim˜es


a
Trata-se de um estudo espec´ıfico que verifica se o sistema
contribui para os objetivos da organiza¸õ;
ca
pode ser desenvolvido com a tecnologia atual;
pede ser desenvolvido dentro do or¸amento previsto;
c
pode ser integrado com os outros sistemas em produ¸õ;
ca
A implementa¸õ assenta em quest˜es `s pessoas da
ca o a
organiza¸õ:
ca
o que acontece se o sistema nõ for implementado?
a
quais sõ os problemas atuais com os processos?
a
ser´ que o sistema proposto os ir´ resolver?
a a
quais serõ os problemas de integra¸õ?
a ca
´ necess´ria nova tecnologia?
e a

Alberto Sim˜es

Levantamento e Sele¸õ de Requisitos
ca

Consiste no trabalho realizado pelo pessoal tćnico em colabora¸õ
e ca
com os restantes intervenientes para determinar o dom´ da
ınio
aplica¸õ, as funcionalidades que devem ser suportadas e os
ca
constrangimentos operacionais do sistema.

Alberto Sim˜es

ca

e ca
ınio
ca

Problemas com a an´lise e sele¸˜o:
a ca
os stakeholders n˜o sabem o que pretendem;
a

Alberto Sim˜es

ca

e ca
ınio
ca

a ca
a
os stakeholders deﬁnem os requisitos nas suas palavras;

Alberto Sim˜es

ca

e ca
ınio
ca

a ca
a
diferentes stakeholders podem ter requisitos conﬂituosos;

Alberto Sim˜es

ca

e ca
ınio
ca

a ca
a
os fatores pol´
ıticos e organizacionais podem afetar os
requisitos do sistema;

Alberto Sim˜es

ca

e ca
ınio
ca

a ca
a
os fatores pol´
ıticos e organizacionais podem afetar os
requisitos do sistema;
os requisitos podem mudar durante o processo de an´lise,
a
assim como o ambiente de neg´cio ou mesmo os stakeholders.
o

Alberto Sim˜es

Especifica¸õ de Requisitos
ca

´
E nesta fase que se d´ a produ¸õ do documento de
a ca
especifica¸õ de requisitos;
ca
Documento com v´rios tipos de especifica¸˜es:
a co
especifica¸õ de requisitos do utilizador;
ca
especifica¸õ de requisitos do sistema;
ca
especifica¸õ da arquitetura do sistema;
ca
Usando diferentes tipos de abordagens:
Especifica¸õ Textual;
ca
Casos de uso (UML);
Diagramas de Atividade (UML) (de alto n´
ıvel);
Diagramas de Fluxo de Dados;
Especifica¸õ Formal;
ca
Prototipagem da interface.

Alberto Sim˜es

Valida¸õ de Requisitos
ca

Avalia se os requisitos definem o sistema que o cliente
realmente pretende.
Os custos com os erros na identifica¸õ dos requisitos sõ
ca a
elevados, o que demonstra a importˆncia da valida¸õ.
a ca

Corrigir um erro de defini¸õ de requisitos ap´s a
ca o
instala¸õ de um produto pode custar at´ 100 vezes mais
ca e
que corrigir um erro na especifica¸õ.
ca

Alberto Sim˜es

Parte II

Tipologia de Requisitos

Alberto Sim˜es


Requisitos funcionais
funcionalidades que o sistema deve implementar: como o
sistema dever´ responder a cada opera¸˜o, e como se dever´
a ca a
comportar em determinadas situa¸˜es
co

Alberto Sim˜es


a ca a
co

Requisitos n˜o funcionais
a
constrangimentos `s funcionalidades do sistema, como
a
standards, restri¸˜es de tempo, restri¸˜es do processo de
co co
desenvolvimento, etc.
propriedades comportamentais que o sistema deve garantir,
como desempenho, seguran¸a, ﬁabilidade, etc.
c

Alberto Sim˜es


a ca a
co

Requisitos nõ funcionais
a
constrangimentos `s funcionalidades do sistema, como
a
standards, restri¸˜es de tempo, restri¸˜es do processo de
co co
desenvolvimento, etc.
propriedades comportamentais que o sistema deve garantir,
como desempenho, seguran¸a, fiabilidade, etc.
c

Requisitos de dom´ ınio
requisitos resultantes do dom´ de aplica¸õ do sistema
ınio ca

Alberto Sim˜es

Requisitos de Dom´
ınio

Requisitos resultantes do dom´ de aplica¸õ do sistema e
ınio ca
que refletem determinada caracter´ ısticas que devem ser tidas
em considera¸õ durante o desenvolvimento do sistema;
ca
Nõ derivam das necessidades espec´
a ıficas dos utilizadores;
Para al´m de se considerarem requisitos de dom´
e ınio, podem
ser classificados como requisitos funcionais ou nõ funcionais;
a

Alberto Sim˜es

Requisitos de Dom´
ınio

ınio ca
ca
e ınio, podem
a
Exemplos:
no desenvolvimento de um registo cl´
ınico eletrńico, a
o
autentica¸õ pode ser considerada um requisito de dom´
ca ınio
imposto pelo enquadramento de prote¸õ de dados pessoais;
ca

Alberto Sim˜es

Requisitos de Dom´
ınio

ınio ca
ca
e ınio, podem
a
Exemplos:
no desenvolvimento de um registo cl´
ınico eletrńico, a
o
autentica¸õ pode ser considerada um requisito de dom´
ca ınio
imposto pelo enquadramento de prote¸õ de dados pessoais;
ca
num sistema de fatura¸õ, a exporta¸õ do registo das faturas
ca ca
em formato SAF-T pode ser considerada um requisito de
dom´ imposto pela autoridade tribut´ria;
ınio a

Alberto Sim˜es

Requisitos Funcionais

Descrevem funcionalidades que o sistema deve implementar;
Dependem do tipo de software, das expectativas dos
utilizadores, e do tipo de sistema onde o software ir´ ser
a
utilizado;

Alberto Sim˜es


a
utilizado;
Exemplos:
O utilizador deve ser capaz de procurar nas bases de dados de
todas as lojas de uma cadeia de supermercados, ou apenas
num conjunto de lojas selecionadas;

Alberto Sim˜es


a
utilizado;
Exemplos:
Deve ser atribu´ um c´digo unico a cada encomenda;
ıdo o ´

Alberto Sim˜es


a
utilizado;
Exemplos:
Deve ser atribu´ um c´digo unico a cada encomenda;
ıdo o ´
O sistema deve fornecer as ferramentas adequadas ao
utilizador para facilitar a leitura dos documentos armazenados.

Alberto Sim˜es

Requisitos Nõ Funcionais
a

Definem as propriedades do sistema e os seus
constrangimentos.
Os requisitos nõ funcionais podem ser mais cr´
a ıticos que os
requisitos funcionais: caso nõ sejam cumpridos, o sistema
a
pode tornar-se in´til.
u

Alberto Sim˜es

a

constrangimentos.
a ıticos que os
a
u
Exemplos de propriedades s˜o:
a
ﬁabilidade;
tempo de resposta;
espa¸o em disco necess´rio;
c a

Alberto Sim˜es

a

constrangimentos.
a ıticos que os
a
u
Exemplos de propriedades sõ:
a
fiabilidade;
tempo de resposta;
espa¸o em disco necess´rio;
c a
Exemplos de constrangimentos sõ:
a
capacidade de input/output dos equipamentos;
espa¸o em disco dispon´
c ıvel;
largura de banda;
Alberto Sim˜es

Tipos de Requisitos Nõ Funcionais
a

Requisitos de Produto
Especificam como se deve comportar o produto de acordo
com um conjunto de parˆmetros.
a
ex.: velocidade de execu¸õ, fiabilidade, etc.
ca

Alberto Sim˜es

a

a
ca

Requisitos Organizacionais
Derivam de pol´ ıticas e procedimentos da organiza¸˜o.
ca
ex.: regras internas, standards da organiza¸˜o, etc.
ca

Alberto Sim˜es

a

a
ca

Requisitos Organizacionais
Derivam de pol´ ıticas e procedimentos da organiza¸˜o.
ca
ex.: regras internas, standards da organiza¸˜o, etc.
ca

Requisitos Externos
Resultam de fatores externos ao sistema e ao seu processo de
desenvolvimento.
Muitas vezes correspondem a requisitos de dom´ ınio.
ex.: requisitos de interoperabilidade, aspetos legais, etc.

Alberto Sim˜es

a

Requisitos Não
Funcionais

Requisitos da Requisitos de Requisitos
Organização Produto Externos

Requisitos de Requisitos de Requisitos de Requisitos de
Usabilidade Eﬁciência Fiabilidade Portabilidade

Requisitos de Requisitos de Requisitos dos Requisitos de Requisitos Requisitos
Distribuição Implementação Standards Usados Interoperabilidade Legislativos Éticos

Requisitos de Requisitos de Requisitos de Requisitos de
Espaço Execução Privacidade Segurança

Alberto Sim˜es

Especifica¸õ de Requisitos Nõ Funcionais
ca a

Devem ser especificados na forma de objetivo.
(inten¸õ geral do utilizador, como facilidade de utiliza¸õ)
ca ca

Alberto Sim˜es

ca a

ca ca

Sempre que poss´ ıvel, devem ser verific´veis:
a
(devem incorporar uma medida que permita testar de forma
objetiva se o requisito est´ corretamente implementado)
a

Tipicamente sõ dif´
a ıceis de definir com rigor, e portanto,
dif´
ıceis de verificar.

Alberto Sim˜es

ca a

ca ca

a
a

dif´
Exemplo:
o sistema deve ser f´cil de utilizar por operadores experientes
a
e organizado de tal forma que minimize erros do utilizador.

Alberto Sim˜es

ca a

ca ca

a
a

dif´
Exemplo:
o sistema deve ser fćil de utilizar por operadores experientes
a
e organizado de tal forma que minimize erros do utilizador.
os operadores experientes devem ser capazes de utilizar todas
as fun¸˜es do sistema ap´s duas horas de forma¸õ; depois
co o ca
dessa forma¸õ, o n´mero m´dio de erros realizados pelos
ca u e
operadores nõ deve exceder dois por dia.
a
Alberto Sim˜es

Medidas para Requisitos N˜o Funcionais
a

transa¸˜es processadas por segundo
co
Velocidade tempo de resposta para determinado evento
tempo de desenho do ecr˜a


Alberto Sim˜es

a

co
tempo de desenho do ecr˜
a


tamanho de disco ocupado (MB)
Tamanho
largura de banda usada (MB)

Alberto Sim˜es

a

co
tempo de desenho do ecrã


Tamanho
tempo de forma¸õ
ca
Facilidade de uso
n´mero de p´ginas de documenta¸õ
u a ca

Alberto Sim˜es

a

co
tempo de desenho do ecr˜ a


Tamanho
tempo de forma¸õ
ca
Facilidade de uso
u a ca

tempo m´dio de falha
e
Confian¸a probabilidade de nõ disponibilidade
c a
rćio de ocorrˆncia de falhas
a e


Alberto Sim˜es

a

co


Tamanho
tempo de forma¸˜o ca
Facilidade de uso
u a ca

e
c a
a e


tempo de rein´ ap´s falha
ıcio o
Robustez percentagem de situa¸˜es que provocam falhas
co
probabilidade de corrup¸˜o de dados por falha
ca


Alberto Sim˜es

a

co


Tamanho
tempo de forma¸õ ca
Facilidade de uso
u a ca

e
c a
a e


tempo de rein´ ap´s falha
ıcio o
Robustez percentagem de situa¸˜es que provocam falhas
co
probabilidade de corrup¸õ de dados por falha
ca


n´mero de plataformas alvo
u
Portabilidade
perc. de linhas de c´digo espec´
o ıficas
Alberto Sim˜es

Exerc´
ıcios

“Em todas as janelas o utilizador dever´ ter acesso a um bot˜o
a a
para aceder ` documenta¸˜o contextual.”
a ca

Alberto Sim˜es

Exerc´
ıcios

“Em todas as janelas o utilizador dever´ ter acesso a um bot˜o
a a
para aceder ` documenta¸˜o contextual.”
a ca

Requisito Funcional

Alberto Sim˜es

Exerc´
ıcios

“Cada transa¸˜o com a base de dados n˜o pode usar mais que 100
ca a
KB de largura de banda.”

Alberto Sim˜es

Exerc´
ıcios

“Cada transa¸õ com a base de dados nõ pode usar mais que 100
ca a
KB de largura de banda.”

Requisito Nõ Funcional
a

Alberto Sim˜es

Exerc´
ıcios

“Para cada cliente dever´ ser armazenado o n´mero ﬁscal.”
a u

Alberto Sim˜es

Exerc´
ıcios

“Para cada cliente dever´ ser armazenado o n´mero ﬁscal.”
a u

Requisito N˜o Funcional (e possivelmente de dom´
a ınio)

Alberto Sim˜es

Exerc´
ıcios

“O utilizador n˜o dever´ poder introduzir um cliente sem indicar o
a a
seu n´mero ﬁscal.”
u

Alberto Sim˜es

Exerc´
ıcios

“O utilizador n˜o dever´ poder introduzir um cliente sem indicar o
a a
seu n´mero ﬁscal.”
u

Requisito Funcional

Alberto Sim˜es

Exerc´
ıcios

“O acesso ao sistema deve ser validado usando uma senha de
seguran¸a.”
c

Alberto Sim˜es

Exerc´
ıcios

“O acesso ao sistema deve ser validado usando uma senha de
seguran¸a.”
c

a

Alberto Sim˜es

Exerc´
ıcios

“Dever´ ser poss´ alterar a senha de seguran¸a pelo pr´prio
a ıvel c o
utilizador.”

Alberto Sim˜es

Exerc´
ıcios

“Dever´ ser poss´ alterar a senha de seguran¸a pelo pr´prio
a ıvel c o
utilizador.”

Requisito Funcional

Alberto Sim˜es

Exerc´
ıcios

“A interface ao utilizador deve ter um aspeto amig´vel, e cores
a
s´brias.”
o

Alberto Sim˜es

Exerc´
ıcios

“A interface ao utilizador deve ter um aspeto amig´vel, e cores
a
s´brias.”
o

a

Alberto Sim˜es

Parte III

Recolha de Requisitos

Alberto Sim˜es

Tćnicas para a Recolha de Requisitos
e

Existem v´rias tćnicas para a recolha, sele¸õ e especifica¸õ de
a e ca ca
requisitos:
Entrevistas
Question´rios
a
An´lise Documental
a
Observa¸õ
ca
Perspetivas
Cen´rios
a
Prototipagem
O Analista de sistemas deve saber como e quando utilizar cada
uma, assim como as combinar.

Alberto Sim˜es

Entrevistas

Processo
Selecionar os entrevistados,
baseado no tipo de informa¸õ
ca
necess´ria, e garantindo diferentes
a
perspetivas;
Desenvolver o Guiõ da entrevista;
a
Definir Objetivos da entrevista;
Conduzir a entrevista;
Apresentar resultados da
entrevista;

Alberto Sim˜es

Entrevistas

Processo Conte´do da Entrevista
u
Selecionar os entrevistados, Quest˜es fechadas:
o
ca “Quantas encomendas recebe por
a telefone diariamente? ”
perspetivas; “Como s˜o feitas as encomendas? ”
a
a
Deﬁnir Objetivos da entrevista;
Conduzir a entrevista;
entrevista;

Alberto Sim˜es

Entrevistas

u
o
a
a Quest˜es abertas:
o
Deﬁnir Objetivos da entrevista; “O que acha do sistema atual? ”
“Quais os problemas com que se
Conduzir a entrevista; depara diariamente? ”
entrevista;

Alberto Sim˜es

Entrevistas

u
o
a
a Quest˜es abertas:
o
Deﬁnir Objetivos da entrevista; “O que acha do sistema atual? ”
“Quais os problemas com que se
Conduzir a entrevista; depara diariamente? ”
Quest˜es de prova:
o
entrevista;
“Pode-me dar um exemplo? ”
“Pode-me explicar com mais
detalhe? ”

Alberto Sim˜es

Question´rios
a

Processo
Conjunto de quest˜es escritas,
o
usualmente enviadas para um
grande n´mero de pessoas;
u
Podem ser em formato de papel ou
eletrńico;
o
Selecionar participantes
representativos;
Desenvolver quest˜es claras e de
o
fćil an´lise;
a a
Definir estrat´gias para obter um
e
bom n´mero de respostas;
u
Mostrar o impacto do question´rio
a
aos questionados;

Alberto Sim˜es

Question´rios
a

Processo Cuidados
Conjunto de quest˜es escritas,
o Come¸ar com quest˜es
c o
usualmente enviadas para um interessantes;
grande n´mero de pessoas;
u
Agrupar em seç˜es coerentes;
co
Podem ser em formato de papel ou
Nõ colocar perguntas importantes
a
eletrńico;
o
no fim;
Selecionar participantes
Nõ encher demasiado as p´ginas;
a a
representativos;
Evitar o uso de abreviaturas;
Desenvolver quest˜es claras e de
o
fćil an´lise;
a a Evitar fazer perguntas
tendenciosas;
Definir estrat´gias para obter um
e
bom n´mero de respostas;
u Numerar as perguntas;
Mostrar o impacto do question´rio
a Fazer teste pr´vio ao question´rio;
e a
aos questionados;
Garantir anonimato nas respostas;
Alberto Sim˜es

An´lise Documental
a

Documentos que contˆm informa¸˜o do sistema “as-is”
e ca
(estado atual!)
Regulamentos, Relat´rios internos, Registos peri´dicos,
o o
Formul´rios, Manuais de procedimentos, . . .
a

Alberto Sim˜es

An´lise Documental
a

e ca
(estado atual!)
o o
a
Procurar elementos adicionados pelos utilizadores aos
formul´rios (notas ` margem...)
a a

Alberto Sim˜es

An´lise Documental
a

e ca
(estado atual!)
o o
a
a a
Procurar elementos n˜o utilizados;
a

Alberto Sim˜es

An´lise Documental
a

e ca
(estado atual!)
o o
a
a a
Procurar elementos nõ utilizados;
a
Dar particular aten¸õ aos documentos:
ca
Que descrevem a organiza¸õ;
ca
Que descrevem os conte´dos funcionais dos v´rios cargos;
u a
Que relatam as atividades da organiza¸õ;
ca
Que constituem material publicit´rio e promocional da
a
organiza¸õ;
ca

Alberto Sim˜es

Observa¸õ
ca

Observa¸õ dos processos a serem executados;
ca
Utilizadores/gestores nõ se lembram com exatidõ de tudo o
a a
que fazem;
Valida a informa¸õ recolhida com outros m´todos;
ca e
Ter em aten¸õ que o comportamento das pessoas muda
ca
quando estõ a ser observadas;
a
Tentar ser discreto;
Identificar per´
ıodos mortos e picos;

Alberto Sim˜es

Perspetivas

Forma de estruturar requisitos, mostrando as perspetivas dos
diferentes stakeholders;

Nenhuma perspetiva ´ a correta;
e

Tipos de Perspetivas:

Dos intervenientes
´
E a vis˜o segundo as pessoas ou outros sistemas que interagem
a
com o sistema;
Do dom´ ınio
Caracter´ ısticas e constrangimentos do dom´
ınio, que afetam os
requisitos.

Alberto Sim˜es

Cen´rios
a

Exemplos da vida real, de como o sistema interage e pode ser
utilizado.
Devem incluir:
Descri¸õ da situa¸õ
ca ca
(quando esta situa¸õ ocorre, quem lida com ela, etc.)
ca
Situa¸õ de arranque
ca
(quais sõ os pressupostos para que este cen´rio possa ocorrer)
a a
Fluxo normal dos eventos
(quem d´ a informa¸õ, quem a introduz, quais as a¸˜es
a ca co
despoletadas pelo sistema)
Situa¸˜es de erro
co
(o que pode correr mal?)
Final do cen´rio
a
(estado do sistema quando o caso real termina)

Alberto Sim˜es

Prototipagem

Alguns utilizadores tˆm dificuldade em visualizar o sistema;
e

Pode ser util preparar prot´tipos de interfaces com o utilizador
´ o
(mockups) que permitam discutir as funcionalidades
desejadas;

Em casos em que a perce¸õ do processo de transforma¸õ e
ca ca
prepara¸õ de informa¸õ seja dif´ poder´ fazer sentido
ca ca ıcil, a
implementar pequenos prot´tipos para simular as v´rias
o a
possibilidades dispon´
ıveis.

Alberto Sim˜es

Parte IV

ca

Alberto Sim˜es

ca
Linguagem Natural

Possivelmente a forma mais simples de especiﬁcar requisitos;

Alberto Sim˜es

ca
Linguagem Natural

Mas a forma menos ﬁ´vel de especiﬁcar requisitos;
a

Alberto Sim˜es

ca
Linguagem Natural

a
Problemas no uso da Linguagem Natural
para especiﬁcar requisitos:
Falta de clareza
´ ıcil
E dif´ obter precis˜o sem tornar a leitura do documento
a
dif´
ıcil.

Alberto Sim˜es

ca
Linguagem Natural

a
Falta de clareza
´ ıcil
a
dif´
ıcil.
Confus˜o de requisitos
a
Os requisitos funcionais e n˜o funcionais tendem a ser
a
misturados.

Alberto Sim˜es

ca
Linguagem Natural

a
Falta de clareza
´ ıcil
a
dif´
ıcil.
Confusõ de requisitos
a
Os requisitos funcionais e nõ funcionais tendem a ser
a
misturados.
Am´lgama de requisitos
a
V´rios requisitos diferentes sõ muitas vezes expressos em
a a
conjunto, usando at´ a mesma frase. Isto dificulta a sua
e
correta identifica¸õ.
ca
Alberto Sim˜es

ca
Exemplos de m´s especifica¸oes em LN
a c˜

Requisito LIBSYS
Deve fornecer um sistema de contabilidade financeira que
mantenha os registos dos pagamentos realizados pelos utilizadores
do sistema. Os gestores do sistema podem configura-lo de forma a
que os utilizadores mais frequentes possam receber descontos.

Alberto Sim˜es

ca
a c˜

Requisito LIBSYS
Deve fornecer um sistema de contabilidade financeira que
mantenha os registos dos pagamentos realizados pelos utilizadores
do sistema. Os gestores do sistema podem configura-lo de forma a
que os utilizadores mais frequentes possam receber descontos.

Problemas:
descreve o conceito de sistema de contabilidade financeira a
incluir no sistema de forma abstrata;
contudo, inclui tamb´m entrada detalhada que nõ ´
e a e
necess´rio a este n´
a ıvel;

Alberto Sim˜es

ca
a c˜

Requisito editor de grelhas
Para facilitar o posicionamento de entidades num diagrama, o
utilizador pode configurar a grelha em cent´ımetros ou polegadas,
atrav´s de uma op¸õ no painel de controlo. Inicialmente, a grelha
e ca
est´ desativada. A grelha pode ser ativada ou desativada a
a
qualquer momento. Na vista “reduzir ` dimensõ”, a grelha ter´
a a a
menos linhas para nõ saturar o diagrama de linhas.
a

Alberto Sim˜es

ca
a c˜

Requisito editor de grelhas
Para facilitar o posicionamento de entidades num diagrama, o
utilizador pode configurar a grelha em cent´ımetros ou polegadas,
atrav´s de uma op¸õ no painel de controlo. Inicialmente, a grelha
e ca
est´ desativada. A grelha pode ser ativada ou desativada a
a
qualquer momento. Na vista “reduzir ` dimensõ”, a grelha ter´
a a a
menos linhas para nõ saturar o diagrama de linhas.
a

Problemas:
requisitos funcionais conceptuais (a necessidade da grelha);
requisitos nõ funcionais (as medidas da grelha);
a
requisitos nõ funcionais de interface com o utilizador
a
(ativa¸õ da grelha);
ca

Alberto Sim˜es

ca
Alternativas ao uso da LN

Linguagem Natural Estruturada
Consiste em definir modelos para especificar os requisitos,
usando estruturas fr´sicas r´
a ıgidas de fćil interpreta¸õ.
a ca

Alberto Sim˜es

ca

a ca
Linguagem de Descri¸õ de Projeto
ca
Recorrer a uma linguagem formal, do gńero da usada em
e
programa¸õ ou algoritmia, mas mais abstrata, para
ca
especificar os requisitos.

Alberto Sim˜es

ca

a ca
ca
e
ca
Nota¸˜es Gr´ﬁcas
co a
Descrever os requisitos funcionais numa linguagem gr´ﬁca e
a
pseudo-formal (ex: SADT ou UML), complementada com
anota¸˜es textuais.
co

Alberto Sim˜es

ca

a ca
ca
e
ca
Nota¸˜es Gr´ficas
co a
Descrever os requisitos funcionais numa linguagem gr´fica e
a
pseudo-formal (ex: SADT ou UML), complementada com
anota¸˜es textuais.
co
Nota¸˜es Matem´ticas
co a
Nota¸õ formal, como por exemplo a teoria de conjuntos, para
ca
eliminar qualquer ambiguidade. Levantam problemas na
dificuldade de compreensõ para pessoas nõ familiarizadas
a a
com as nota¸˜es usadas.
co
Alberto Sim˜es

ca

´
E uma declara¸õ oficial das funcionalidades do sistema, tendo
ca
como principal destinat´rio quem vai desenvolver o software;
a

Resulta dos requisitos acordados entre as partes;

Nõ ´ um documento de projeto do sistema: deve descrever O
a e
que o sistema deve fazer, e nõ como deve ser feito;
a

Alberto Sim˜es

ca

Descreve os requisitos para os stakeholders:
expresso em termos que eles os compreendam;
compreens´ de diferentes pontos de vista;
ıvel
revistos pelos pr´prios stakeholders;
o
claro e nõ amb´
a ıguo;
Descreve os requisitos para quem vai desenvolver o software:
tõ preciso e espec´
a ıfico quanto poss´
ıvel;
expresso em termos que eles compreendam;
facilitador de integra¸õ de novos membros na equipa;
ca
Regista requisitos para o futuro:
essencial para a evolu¸õ do sistema;
ca
Pode servir de documento contratual.

Alberto Sim˜es

ca
Documento de Requisitos - standard IEEE/ANSI 830-1993

Introdu¸õ
ca
Objetivos do documento
ˆ
Ambito do produto
Defini¸õ e abreviaturas
ca
Referˆncias
e
Descri¸õ Geral
ca
Perspetivas e fun¸˜es do produto
co
Carater´
ısticas dos utilizadores
Constrangimentos gerais
Pressupostos e dependˆncias
e
Requisitos
Apˆndices
e

Alberto Sim˜es

ca
Prototipagem da Interface

Esquematizar interfaces para as fun¸˜es principais do software;
co

Alberto Sim˜es

ca

co

Servem como mecanismo de recolha e negocia¸˜o de
ca
requisitos;

Alberto Sim˜es

ca

co

ca
requisitos;
Servem tamb´m como especifica¸õ dos requisitos:
e ca
apresentam um conjunto de informa¸õ que deve estar
ca
dispon´
ıvel;
apresentam um conjunto de bot˜es/menus que correspondem
o
a funcionalidades que devem ser implementadas;

Alberto Sim˜es

ca

co

ca
requisitos;
Servem tamb´m como especifica¸õ dos requisitos:
e ca
apresentam um conjunto de informa¸õ que deve estar
ca
dispon´
ıvel;
apresentam um conjunto de bot˜es/menus que correspondem
o
a funcionalidades que devem ser implementadas;
Cuidados!
usar uma ferramenta de desenho que nõ se assemelhe
a
demasiado a um produto final;
caso contr´rio, cliente poder´ ter impressõ que o software
a a a
est´ pronto!
a

Alberto Sim˜es

ca
Prototipagem da Interface - Exemplo

- + Adicionar Funcionário
Nome : ...

Morada : ...

Telefone : ...

Data de Nascimento March 2009
Sexo Masculino
S M T W T F S
Feminino
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Adicionar Cancelar

Alberto Sim˜es

ca
Especifica¸õ Textual
ca

Embora a linguagem natural seja amb´ ıgua, ´ imprescind´
e ıvel
uma descri¸õ textual dos requisitos;
ca
Complementa os prot´tipos de interface ou os diagramas
o
UML;
Devem ser descritos de forma organizada, e estruturada,
usando linguagem clara;
Evitar o uso de g´ inform´tica;
ıria a
Devem ser descritos usando a forma ativa dos verbos
(presente, nõ passado).
a

Alberto Sim˜es

ca
Especifica¸õ Textual - Exemplo
ca

3. Edi¸õ de diagramas.
ca

Alberto Sim˜es

ca
ca

ca
3.5 Adicionar um nodo num diagrama.

Alberto Sim˜es

ca
ca

ca
3.5.1 O editor deve permitir que o utilizador adicione nodos de
determinado tipo ao seu diagrama.

Alberto Sim˜es

ca
ca

ca
3.5.2 A sequˆncia de a¸˜es para adicionar um nodo deve ser:
e co
O utilizador seleciona o tipo de nodo a ser adicionado.
O utilizador move o cursor para uma posi¸õ aproximada para
ca
o nodo, no diagrama, indicando que o s´ ımbolo deve ser
adicionado nesse ponto.
O utilizador posteriormente deve arraste o s´ımbolo para a sua
posi¸õ final.
ca

Alberto Sim˜es

ca
ca

ca
3.5.2 A sequˆncia de a¸˜es para adicionar um nodo deve ser:
e co
O utilizador seleciona o tipo de nodo a ser adicionado.
O utilizador move o cursor para uma posi¸õ aproximada para
ca
o nodo, no diagrama, indicando que o s´ ımbolo deve ser
adicionado nesse ponto.
O utilizador posteriormente deve arraste o s´ımbolo para a sua
posi¸õ final.
ca
3.5.3 An´lise L´gica: O utilizador ´ a melhor pessoa para decidir onde
a o e
colocar um nodo no diagrama. Esta abordagem d´ controlo direto
a
sobre a sele¸õ e posicionamento dos nodos.
ca

Alberto Sim˜es

ca
Diagramas

A especiﬁca¸˜o textual dever´ ser complementada com
ca a
diagramas;
Existem diferentes nota¸˜es:
co
Diagramas de Fluxo de Dados;
Diagramas de Caso de Uso (UML);
Diagramas de Atividade (UML);
Diagramas de Sequˆncia (UML);
e
...

Alberto Sim˜es

Parte V

Diagramas de Caso de Uso

Alberto Sim˜es

Atores

Alberto Sim˜es

Ator

Representado por um stick-man, acompanhado
de um nome;

Alberto Sim˜es

Ator

de um nome;
O nome do ator dever´ ser f´cil de compreender
a a
pelo cliente e pela equipa de desenvolvimento;

Alberto Sim˜es

Ator

de um nome;
a a
Nem todos os seres humanos que interagem com
o sistema s˜o atores (alguns fazem parte do
a
pr´prio sistema);
o

Alberto Sim˜es

Ator

de um nome;
a a
a
pr´prio sistema);
o
Nem todos os atores s˜o seres humanos (por
a
exemplo, outros sistemas que interagem com o
sistema a ser desenvolvido);

Alberto Sim˜es

Ator

de um nome;
a a
a
pr´prio sistema);
o
Nem todos os atores s˜o seres humanos (por
a
exemplo, outros sistemas que interagem com o
sistema a ser desenvolvido);
Por exemplo, o pr´prio rel´gio do sistema pode
o o
ser visto como um ator, que despoleta a¸˜es a
co
determinadas horas;

Alberto Sim˜es

Generaliza¸õ de Atores
ca

Alguns atores sõ capazes de realizar
a
todas as opera¸˜es que outros atores;
co
Por exemplo, ´ t´
e ıpico que um
administrador possa realizar todas as
opera¸˜es de um utilizador normal (e
co
outras espec´
ıficas);
O chefe de caixa num supermercado
tipicamente tamb´m ´ caixa: para
e e
al´m de fazer o que um caixa faz, tem
e
capacidade de realizar outras
opera¸˜es;
co
Nestes casos, usa-se uma seta de
generaliza¸õ (com um triˆngulo como
ca a
ponta), que parte do ator mais gen´rico,
e
em dire¸õ ao ator mais espec´
ca ıfico;
Alberto Sim˜es

Casos de Uso

Um caso de uso, ou uma tarefa, ´ representado
e
dentro de uma oval;

Alberto Sim˜es

Casos de Uso

e
dentro de uma oval;
Pode ser tõ simples como permitir que o
a
utilizador realize login;
Pode ser tõ complicado como executar uma
a
transa¸õ distribu´ por v´rias bases de dados
ca ıda a
globais;

Alberto Sim˜es

Casos de Uso

e
dentro de uma oval;
a
a
ca ıda a
globais;
´
E uma intera¸˜o completa, que inclui a
ca
introdu¸˜o de dados no sistema (ou pelo menos
ca
o pedido de determinada funcionalidade), e o
retorno por parte do sistema;

Alberto Sim˜es

Casos de Uso

e
dentro de uma oval;
a
a
ca ıda a
globais;
´
E uma intera¸˜o completa, que inclui a
ca
introdu¸˜o de dados no sistema (ou pelo menos
ca
o pedido de determinada funcionalidade), e o
retorno por parte do sistema;
Um caso de uso ´ qualquer coisa que providencia um
e
resultado mensur´vel para o utilizador ou um sistema
a
externo

Alberto Sim˜es

Linhas de Comunica¸õ
ca

Relacionam os atores com os casos
de uso com que interagem;
Tipicamente os diagramas nõ
a
representam a ordem pela qual esta
intera¸õ ´ feita;
ca e
Uma linha de comunica¸õ significa
ca
apenas que o ator est´ envolvido
a
em determinado uso do sistema;

Alberto Sim˜es

Limites do Sistema

Embora exista uma separa¸˜o ca
impl´ıcita entre atores e casos de
uso, ´ habitual colocar estes
e
ultimos numa caixa;
´
Habitualmente nesta caixa ´e
inscrito o nome do sistema;

Alberto Sim˜es

Descri¸õ dos Casos de Uso
ca

Cada caso de uso dever´ ser acompanhado de uma descri¸õ
a ca
detalhada do processo (como a defini¸õ de um requisito).
ca

Alberto Sim˜es

Descri¸õ dos Casos de Uso
ca

Cada caso de uso dever´ ser acompanhado de uma descri¸õ
a ca
detalhada do processo (como a defini¸õ de um requisito).
ca

Caso de uso: criar novo utilizador no blog
Objetivo: um utilizador solicitou ao administrador um utilizador no blog
Condi¸õ de Sucesso:
ca um novo utilizador ´ criado para o autor
e
Condi¸õ de Falha:
ca ´ rejeitada a requisi¸õ de novo utilizador
e ca
Principal Ator: administrador
Atores Secund´rios:
a BD de credenciais
Processo:
1. O administrador escolhe a op¸õ de criar novo utilizador;
ca
2. O administrador escolhe o tipo de utilizador;
3. O administrador preenche formul´rio com dados do utilizador;
a
4. Os detalhes do utilizador sõ verificados na BD de credenciais;
a
5. O utilizador do blog ´ criado;
e
6. Sõ enviados os detalhes do utilizador por e-mail para o utilizador;
a

Extens˜es:
o
4.1. A BD de credenciais nõ verifica os detalhes do utilizador;
a
4.2. A requisi¸õ de novo utilizador ´ rejeitada;
ca e

Alberto Sim˜es

Rela¸˜es entre Casos de Uso
co

Considere-se o seguinte cen´rio:
a

N˜o h´ rela¸˜o entre os dois casos de uso?
a a ca

Alberto Sim˜es

co

Considere-se o seguinte cen´rio:
a

Nõ h´ rela¸õ entre os dois casos de uso?
a a ca
Os casos de uso podem partilhar opera¸˜es;
co
Por exemplo, para criar um utilizador no blog, ou um wiki
pessoal, ser´ necess´rio validar a identidade do utilizador;
a a
Podemos colocar essa opera¸õ em evidˆncia.
ca e

Alberto Sim˜es

co

Alberto Sim˜es

co

Ao separar os casos de uso partilhados e coloc´-los em evidˆncia d´
a e a
ˆnfase, por exemplo, a que apenas o caso de uso “veriﬁcar
e
identidade” ter´ de comunicar com a base de dados de credenciais;
a

Alberto Sim˜es

co

a e a
e
a
Do mesmo modo, torna claro para o programador que poder´ a
desenvolver um m´dulo separado que possa ser reaproveitado
o
noutras situa¸˜es;
co

Alberto Sim˜es

co

a e a
e
a
Do mesmo modo, torna claro para o programador que poder´ a
desenvolver um m´dulo separado que possa ser reaproveitado
o
noutras situa¸˜es;
co
Na descri¸˜o textual do caso de uso remove-se os itens do processo
ca
que se referem a este novo caso de uso, e coloca-se uma nota:
Include: Verificar Identidade;
Alberto Sim˜es

co

Os casos de uso podem ser tornados mais gen´ricos: por exemplo, o
e
processo de criar um utilizador normal no blog, ou um editor, deve ser
semelhante!

Alberto Sim˜es

co

Na Generaliza¸˜o:
ca
mostra-se que um caso de uso ´ uma generaliza¸˜o de outro
e ca
caso de uso (um caso particular);

Alberto Sim˜es

co

Na Generaliza¸˜o:
ca
e ca
todos os passos do caso de uso gen´rico devem ocorrer no
e
caso particular;

Alberto Sim˜es

co

Na Generaliza¸õ:
ca
e ca
todos os passos do caso de uso gen´rico devem ocorrer no
e
caso particular;
todas as rela¸˜es include existentes para com o caso de uso
co
gen´rico tamb´m sõ v´lidas para os casos espec´
e e a a ıficos;

Alberto Sim˜es

Aula 02 - Engenharia de Requisitos

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Aula 02 - Engenharia de Requisitos (20)

Mais de Alberto Simões (20)

Último (8)

Aula 02 - Engenharia de Requisitos