Upload
alberto-simoes
View
417
Download
1
Embed Size (px)
DESCRIPTION
Segunda e Terceira aulas de Planeamento de Sistemas de Informação no Mestrado em Informação Empresarial
Citation preview
Engenharia de Requisitos
Alberto [email protected]
Planeamento de Sistemas de InformacaoMestrado em Informacao Empresarial
2012/2013
Alberto Simoes Engenharia de Requisitos 1/62
Parte I
Engenharia de Requisitos
Alberto Simoes Engenharia de Requisitos 2/62
Tambem designada por Analise de Sistemas;
E o processo de definir as funcionalidades que o clientepretende que o sistema implemente, e as restricoes que afetama operacao e o desenvolvimento do sistema;
O objetivo da fase de analise e o de compreender os requisitosdo novo sistema e identifica-los de modo a desenvolver umsistema que os satisfaca completamente;
A determinacao de requisitos e um dos passos mais crıticosnas fases do ciclo de desenvolvimento de software;
Alberto Simoes Engenharia de Requisitos 3/62
Engenharia de Requisitos
O que e a Engenharia de Requisitos?Processo que envolve a recolha e compilacao dos requisitos desistema
Quanto custa a Engenharia de Requisitos?Habitualmente, cerca de 15% do custo de desenvolvimento dosistema.
O que e um processo de Engenharia de Requisitos?Conjunto de actividades que envolve a recolha e compilacaodos requisitos de sistema.
O que acontece quando os requisitos sao mal identificados?Os sistemas sao entregues fora do prazo, sem qualidade e semresponder as necessidades dos clientes.
Existe algum processo de Engenharia de Requisitos ideal?Nao, o processo tem de ser configurado de acordo com asnecessidades de cada organizacao.
Alberto Simoes Engenharia de Requisitos 4/62
Engenharia de Requisitos
O que e a Engenharia de Requisitos?Processo que envolve a recolha e compilacao dos requisitos desistema
Quanto custa a Engenharia de Requisitos?Habitualmente, cerca de 15% do custo de desenvolvimento dosistema.
O que e um processo de Engenharia de Requisitos?Conjunto de actividades que envolve a recolha e compilacaodos requisitos de sistema.
O que acontece quando os requisitos sao mal identificados?Os sistemas sao entregues fora do prazo, sem qualidade e semresponder as necessidades dos clientes.
Existe algum processo de Engenharia de Requisitos ideal?Nao, o processo tem de ser configurado de acordo com asnecessidades de cada organizacao.
Alberto Simoes Engenharia de Requisitos 4/62
Engenharia de Requisitos
O que e a Engenharia de Requisitos?Processo que envolve a recolha e compilacao dos requisitos desistema
Quanto custa a Engenharia de Requisitos?Habitualmente, cerca de 15% do custo de desenvolvimento dosistema.
O que e um processo de Engenharia de Requisitos?Conjunto de actividades que envolve a recolha e compilacaodos requisitos de sistema.
O que acontece quando os requisitos sao mal identificados?Os sistemas sao entregues fora do prazo, sem qualidade e semresponder as necessidades dos clientes.
Existe algum processo de Engenharia de Requisitos ideal?Nao, o processo tem de ser configurado de acordo com asnecessidades de cada organizacao.
Alberto Simoes Engenharia de Requisitos 4/62
Engenharia de Requisitos
O que e a Engenharia de Requisitos?Processo que envolve a recolha e compilacao dos requisitos desistema
Quanto custa a Engenharia de Requisitos?Habitualmente, cerca de 15% do custo de desenvolvimento dosistema.
O que e um processo de Engenharia de Requisitos?Conjunto de actividades que envolve a recolha e compilacaodos requisitos de sistema.
O que acontece quando os requisitos sao mal identificados?Os sistemas sao entregues fora do prazo, sem qualidade e semresponder as necessidades dos clientes.
Existe algum processo de Engenharia de Requisitos ideal?Nao, o processo tem de ser configurado de acordo com asnecessidades de cada organizacao.
Alberto Simoes Engenharia de Requisitos 4/62
Engenharia de Requisitos
O que e a Engenharia de Requisitos?Processo que envolve a recolha e compilacao dos requisitos desistema
Quanto custa a Engenharia de Requisitos?Habitualmente, cerca de 15% do custo de desenvolvimento dosistema.
O que e um processo de Engenharia de Requisitos?Conjunto de actividades que envolve a recolha e compilacaodos requisitos de sistema.
O que acontece quando os requisitos sao mal identificados?Os sistemas sao entregues fora do prazo, sem qualidade e semresponder as necessidades dos clientes.
Existe algum processo de Engenharia de Requisitos ideal?Nao, o processo tem de ser configurado de acordo com asnecessidades de cada organizacao.
Alberto Simoes Engenharia de Requisitos 4/62
Problemas na Engenharia de Requisitos
Como convencer o cliente da necessidade de usar tempo e dinheiro,para recolher requisitos corretamente?
Alberto Simoes Engenharia de Requisitos 5/62
Problemas na Engenharia de Requisitos
Como convencer o cliente da necessidade de usar tempo e dinheiro,para recolher requisitos corretamente?
Alberto Simoes Engenharia de Requisitos 5/62
Problemas na Engenharia de Requisitos
Como garantir que os requisitos recolhidos sao compreendidos deigual modo por cliente e membros da equipa do projeto?
Alberto Simoes Engenharia de Requisitos 6/62
Problemas na Engenharia de Requisitos
Como garantir que os requisitos recolhidos sao compreendidos deigual modo por cliente e membros da equipa do projeto?
Alberto Simoes Engenharia de Requisitos 6/62
Processo de Engenharia de Requisitos
Os processos utilizados na engenharia de requisitos saodependentes do domınio de aplicacao, das pessoas envolvidase das organizacao que faz o levantamento dos requisitos.
No entanto, existem algumas atividades genericas, comuns atodos os processos:
estudo de viabilidade;levantamento e selecao de requisitos;analise de requisitos;validacao de requisitos;gestao de requisitos;
Alberto Simoes Engenharia de Requisitos 7/62
Processo de Engenharia de Requisitos
Os processos utilizados na engenharia de requisitos saodependentes do domınio de aplicacao, das pessoas envolvidase das organizacao que faz o levantamento dos requisitos.
No entanto, existem algumas atividades genericas, comuns atodos os processos:
estudo de viabilidade;levantamento e selecao de requisitos;analise de requisitos;validacao de requisitos;gestao de requisitos;
Alberto Simoes Engenharia de Requisitos 7/62
Processo de Engenharia de Requisitos
Estudo de Viabilidade
Relatório de Viabilidade
Análise de Requisitos
Modelos do Sistema
Definição de Requisitos
Especificação de Requisitos
Defnição dos Requisitos
Documento de Requisitos Especificação de Requisitos
Alberto Simoes Engenharia de Requisitos 8/62
Processo de Engenharia de RequisitosEstudo de Viabilidade
Deve decidir se um sistema deve ser ou nao desenvolvido.
Trata-se de um estudo especıfico que verifica se o sistema
contribui para os objetivos da organizacao;pode ser desenvolvido com a tecnologia atual;pede ser desenvolvido dentro do orcamento previsto;pode ser integrado com os outros sistemas em producao;
A implementacao assenta em questoes as pessoas daorganizacao:
o que acontece se o sistema nao for implementado?quais sao os problemas atuais com os processos?sera que o sistema proposto os ira resolver?quais serao os problemas de integracao?e necessaria nova tecnologia?
Alberto Simoes Engenharia de Requisitos 9/62
Processo de Engenharia de RequisitosEstudo de Viabilidade
Deve decidir se um sistema deve ser ou nao desenvolvido.
Trata-se de um estudo especıfico que verifica se o sistema
contribui para os objetivos da organizacao;pode ser desenvolvido com a tecnologia atual;pede ser desenvolvido dentro do orcamento previsto;pode ser integrado com os outros sistemas em producao;
A implementacao assenta em questoes as pessoas daorganizacao:
o que acontece se o sistema nao for implementado?quais sao os problemas atuais com os processos?sera que o sistema proposto os ira resolver?quais serao os problemas de integracao?e necessaria nova tecnologia?
Alberto Simoes Engenharia de Requisitos 9/62
Processo de Engenharia de RequisitosEstudo de Viabilidade
Deve decidir se um sistema deve ser ou nao desenvolvido.
Trata-se de um estudo especıfico que verifica se o sistema
contribui para os objetivos da organizacao;pode ser desenvolvido com a tecnologia atual;pede ser desenvolvido dentro do orcamento previsto;pode ser integrado com os outros sistemas em producao;
A implementacao assenta em questoes as pessoas daorganizacao:
o que acontece se o sistema nao for implementado?quais sao os problemas atuais com os processos?sera que o sistema proposto os ira resolver?quais serao os problemas de integracao?e necessaria nova tecnologia?
Alberto Simoes Engenharia de Requisitos 9/62
Processo de Engenharia de RequisitosLevantamento e Selecao de Requisitos
Consiste no trabalho realizado pelo pessoal tecnico em colaboracaocom os restantes intervenientes para determinar o domınio daaplicacao, as funcionalidades que devem ser suportadas e osconstrangimentos operacionais do sistema.
Problemas com a analise e selecao:
os stakeholders nao sabem o que pretendem;
os stakeholders definem os requisitos nas suas palavras;
diferentes stakeholders podem ter requisitos conflituosos;
os fatores polıticos e organizacionais podem afetar osrequisitos do sistema;
os requisitos podem mudar durante o processo de analise,assim como o ambiente de negocio ou mesmo os stakeholders.
Alberto Simoes Engenharia de Requisitos 10/62
Processo de Engenharia de RequisitosLevantamento e Selecao de Requisitos
Consiste no trabalho realizado pelo pessoal tecnico em colaboracaocom os restantes intervenientes para determinar o domınio daaplicacao, as funcionalidades que devem ser suportadas e osconstrangimentos operacionais do sistema.
Problemas com a analise e selecao:
os stakeholders nao sabem o que pretendem;
os stakeholders definem os requisitos nas suas palavras;
diferentes stakeholders podem ter requisitos conflituosos;
os fatores polıticos e organizacionais podem afetar osrequisitos do sistema;
os requisitos podem mudar durante o processo de analise,assim como o ambiente de negocio ou mesmo os stakeholders.
Alberto Simoes Engenharia de Requisitos 10/62
Processo de Engenharia de RequisitosLevantamento e Selecao de Requisitos
Consiste no trabalho realizado pelo pessoal tecnico em colaboracaocom os restantes intervenientes para determinar o domınio daaplicacao, as funcionalidades que devem ser suportadas e osconstrangimentos operacionais do sistema.
Problemas com a analise e selecao:
os stakeholders nao sabem o que pretendem;
os stakeholders definem os requisitos nas suas palavras;
diferentes stakeholders podem ter requisitos conflituosos;
os fatores polıticos e organizacionais podem afetar osrequisitos do sistema;
os requisitos podem mudar durante o processo de analise,assim como o ambiente de negocio ou mesmo os stakeholders.
Alberto Simoes Engenharia de Requisitos 10/62
Processo de Engenharia de RequisitosLevantamento e Selecao de Requisitos
Consiste no trabalho realizado pelo pessoal tecnico em colaboracaocom os restantes intervenientes para determinar o domınio daaplicacao, as funcionalidades que devem ser suportadas e osconstrangimentos operacionais do sistema.
Problemas com a analise e selecao:
os stakeholders nao sabem o que pretendem;
os stakeholders definem os requisitos nas suas palavras;
diferentes stakeholders podem ter requisitos conflituosos;
os fatores polıticos e organizacionais podem afetar osrequisitos do sistema;
os requisitos podem mudar durante o processo de analise,assim como o ambiente de negocio ou mesmo os stakeholders.
Alberto Simoes Engenharia de Requisitos 10/62
Processo de Engenharia de RequisitosLevantamento e Selecao de Requisitos
Consiste no trabalho realizado pelo pessoal tecnico em colaboracaocom os restantes intervenientes para determinar o domınio daaplicacao, as funcionalidades que devem ser suportadas e osconstrangimentos operacionais do sistema.
Problemas com a analise e selecao:
os stakeholders nao sabem o que pretendem;
os stakeholders definem os requisitos nas suas palavras;
diferentes stakeholders podem ter requisitos conflituosos;
os fatores polıticos e organizacionais podem afetar osrequisitos do sistema;
os requisitos podem mudar durante o processo de analise,assim como o ambiente de negocio ou mesmo os stakeholders.
Alberto Simoes Engenharia de Requisitos 10/62
Processo de Engenharia de RequisitosLevantamento e Selecao de Requisitos
Consiste no trabalho realizado pelo pessoal tecnico em colaboracaocom os restantes intervenientes para determinar o domınio daaplicacao, as funcionalidades que devem ser suportadas e osconstrangimentos operacionais do sistema.
Problemas com a analise e selecao:
os stakeholders nao sabem o que pretendem;
os stakeholders definem os requisitos nas suas palavras;
diferentes stakeholders podem ter requisitos conflituosos;
os fatores polıticos e organizacionais podem afetar osrequisitos do sistema;
os requisitos podem mudar durante o processo de analise,assim como o ambiente de negocio ou mesmo os stakeholders.
Alberto Simoes Engenharia de Requisitos 10/62
Processo de Engenharia de RequisitosEspecificacao de Requisitos
E nesta fase que se da a producao do documento deespecificacao de requisitos;
Documento com varios tipos de especificacoes:
especificacao de requisitos do utilizador;especificacao de requisitos do sistema;especificacao da arquitetura do sistema;
Usando diferentes tipos de abordagens:
Especificacao Textual;Casos de uso (UML);Diagramas de Atividade (UML) (de alto nıvel);Diagramas de Fluxo de Dados;Especificacao Formal;Prototipagem da interface.
Alberto Simoes Engenharia de Requisitos 11/62
Processo de Engenharia de RequisitosValidacao de Requisitos
Avalia se os requisitos definem o sistema que o clienterealmente pretende.
Os custos com os erros na identificacao dos requisitos saoelevados, o que demonstra a importancia da validacao.
Corrigir um erro de definicao de requisitos apos ainstalacao de um produto pode custar ate 100 vezes maisque corrigir um erro na especificacao.
Alberto Simoes Engenharia de Requisitos 12/62
Parte II
Tipologia de Requisitos
Alberto Simoes Engenharia de Requisitos 13/62
Tipologia de Requisitos
Requisitos funcionaisfuncionalidades que o sistema deve implementar: como osistema devera responder a cada operacao, e como se deveracomportar em determinadas situacoes
Requisitos nao funcionaisconstrangimentos as funcionalidades do sistema, comostandards, restricoes de tempo, restricoes do processo dedesenvolvimento, etc.propriedades comportamentais que o sistema deve garantir,como desempenho, seguranca, fiabilidade, etc.
Requisitos de domıniorequisitos resultantes do domınio de aplicacao do sistema
Alberto Simoes Engenharia de Requisitos 14/62
Tipologia de Requisitos
Requisitos funcionaisfuncionalidades que o sistema deve implementar: como osistema devera responder a cada operacao, e como se deveracomportar em determinadas situacoes
Requisitos nao funcionaisconstrangimentos as funcionalidades do sistema, comostandards, restricoes de tempo, restricoes do processo dedesenvolvimento, etc.propriedades comportamentais que o sistema deve garantir,como desempenho, seguranca, fiabilidade, etc.
Requisitos de domıniorequisitos resultantes do domınio de aplicacao do sistema
Alberto Simoes Engenharia de Requisitos 14/62
Tipologia de Requisitos
Requisitos funcionaisfuncionalidades que o sistema deve implementar: como osistema devera responder a cada operacao, e como se deveracomportar em determinadas situacoes
Requisitos nao funcionaisconstrangimentos as funcionalidades do sistema, comostandards, restricoes de tempo, restricoes do processo dedesenvolvimento, etc.propriedades comportamentais que o sistema deve garantir,como desempenho, seguranca, fiabilidade, etc.
Requisitos de domıniorequisitos resultantes do domınio de aplicacao do sistema
Alberto Simoes Engenharia de Requisitos 14/62
Tipologia de RequisitosRequisitos de Domınio
Requisitos resultantes do domınio de aplicacao do sistema eque refletem determinada caracterısticas que devem ser tidasem consideracao durante o desenvolvimento do sistema;
Nao derivam das necessidades especıficas dos utilizadores;
Para alem de se considerarem requisitos de domınio, podemser classificados como requisitos funcionais ou nao funcionais;
Exemplos:
no desenvolvimento de um registo clınico eletronico, aautenticacao pode ser considerada um requisito de domınioimposto pelo enquadramento de protecao de dados pessoais;
num sistema de faturacao, a exportacao do registo das faturasem formato SAF-T pode ser considerada um requisito dedomınio imposto pela autoridade tributaria;
Alberto Simoes Engenharia de Requisitos 15/62
Tipologia de RequisitosRequisitos de Domınio
Requisitos resultantes do domınio de aplicacao do sistema eque refletem determinada caracterısticas que devem ser tidasem consideracao durante o desenvolvimento do sistema;
Nao derivam das necessidades especıficas dos utilizadores;
Para alem de se considerarem requisitos de domınio, podemser classificados como requisitos funcionais ou nao funcionais;
Exemplos:
no desenvolvimento de um registo clınico eletronico, aautenticacao pode ser considerada um requisito de domınioimposto pelo enquadramento de protecao de dados pessoais;
num sistema de faturacao, a exportacao do registo das faturasem formato SAF-T pode ser considerada um requisito dedomınio imposto pela autoridade tributaria;
Alberto Simoes Engenharia de Requisitos 15/62
Tipologia de RequisitosRequisitos de Domınio
Requisitos resultantes do domınio de aplicacao do sistema eque refletem determinada caracterısticas que devem ser tidasem consideracao durante o desenvolvimento do sistema;
Nao derivam das necessidades especıficas dos utilizadores;
Para alem de se considerarem requisitos de domınio, podemser classificados como requisitos funcionais ou nao funcionais;
Exemplos:
no desenvolvimento de um registo clınico eletronico, aautenticacao pode ser considerada um requisito de domınioimposto pelo enquadramento de protecao de dados pessoais;
num sistema de faturacao, a exportacao do registo das faturasem formato SAF-T pode ser considerada um requisito dedomınio imposto pela autoridade tributaria;
Alberto Simoes Engenharia de Requisitos 15/62
Tipologia de RequisitosRequisitos Funcionais
Descrevem funcionalidades que o sistema deve implementar;
Dependem do tipo de software, das expectativas dosutilizadores, e do tipo de sistema onde o software ira serutilizado;
Exemplos:
O utilizador deve ser capaz de procurar nas bases de dados detodas as lojas de uma cadeia de supermercados, ou apenasnum conjunto de lojas selecionadas;
Deve ser atribuıdo um codigo unico a cada encomenda;
O sistema deve fornecer as ferramentas adequadas aoutilizador para facilitar a leitura dos documentos armazenados.
Alberto Simoes Engenharia de Requisitos 16/62
Tipologia de RequisitosRequisitos Funcionais
Descrevem funcionalidades que o sistema deve implementar;
Dependem do tipo de software, das expectativas dosutilizadores, e do tipo de sistema onde o software ira serutilizado;
Exemplos:
O utilizador deve ser capaz de procurar nas bases de dados detodas as lojas de uma cadeia de supermercados, ou apenasnum conjunto de lojas selecionadas;
Deve ser atribuıdo um codigo unico a cada encomenda;
O sistema deve fornecer as ferramentas adequadas aoutilizador para facilitar a leitura dos documentos armazenados.
Alberto Simoes Engenharia de Requisitos 16/62
Tipologia de RequisitosRequisitos Funcionais
Descrevem funcionalidades que o sistema deve implementar;
Dependem do tipo de software, das expectativas dosutilizadores, e do tipo de sistema onde o software ira serutilizado;
Exemplos:
O utilizador deve ser capaz de procurar nas bases de dados detodas as lojas de uma cadeia de supermercados, ou apenasnum conjunto de lojas selecionadas;
Deve ser atribuıdo um codigo unico a cada encomenda;
O sistema deve fornecer as ferramentas adequadas aoutilizador para facilitar a leitura dos documentos armazenados.
Alberto Simoes Engenharia de Requisitos 16/62
Tipologia de RequisitosRequisitos Funcionais
Descrevem funcionalidades que o sistema deve implementar;
Dependem do tipo de software, das expectativas dosutilizadores, e do tipo de sistema onde o software ira serutilizado;
Exemplos:
O utilizador deve ser capaz de procurar nas bases de dados detodas as lojas de uma cadeia de supermercados, ou apenasnum conjunto de lojas selecionadas;
Deve ser atribuıdo um codigo unico a cada encomenda;
O sistema deve fornecer as ferramentas adequadas aoutilizador para facilitar a leitura dos documentos armazenados.
Alberto Simoes Engenharia de Requisitos 16/62
Tipologia de RequisitosRequisitos Nao Funcionais
Definem as propriedades do sistema e os seusconstrangimentos.
Os requisitos nao funcionais podem ser mais crıticos que osrequisitos funcionais: caso nao sejam cumpridos, o sistemapode tornar-se inutil.
Exemplos de propriedades sao:
fiabilidade;
tempo de resposta;
espaco em disco necessario;
Exemplos de constrangimentos sao:
capacidade de input/output dos equipamentos;
espaco em disco disponıvel;
largura de banda;
Alberto Simoes Engenharia de Requisitos 17/62
Tipologia de RequisitosRequisitos Nao Funcionais
Definem as propriedades do sistema e os seusconstrangimentos.
Os requisitos nao funcionais podem ser mais crıticos que osrequisitos funcionais: caso nao sejam cumpridos, o sistemapode tornar-se inutil.
Exemplos de propriedades sao:
fiabilidade;
tempo de resposta;
espaco em disco necessario;
Exemplos de constrangimentos sao:
capacidade de input/output dos equipamentos;
espaco em disco disponıvel;
largura de banda;
Alberto Simoes Engenharia de Requisitos 17/62
Tipologia de RequisitosRequisitos Nao Funcionais
Definem as propriedades do sistema e os seusconstrangimentos.
Os requisitos nao funcionais podem ser mais crıticos que osrequisitos funcionais: caso nao sejam cumpridos, o sistemapode tornar-se inutil.
Exemplos de propriedades sao:
fiabilidade;
tempo de resposta;
espaco em disco necessario;
Exemplos de constrangimentos sao:
capacidade de input/output dos equipamentos;
espaco em disco disponıvel;
largura de banda;
Alberto Simoes Engenharia de Requisitos 17/62
Tipologia de RequisitosTipos de Requisitos Nao Funcionais
Requisitos de ProdutoEspecificam como se deve comportar o produto de acordocom um conjunto de parametros.ex.: velocidade de execucao, fiabilidade, etc.
Requisitos OrganizacionaisDerivam de polıticas e procedimentos da organizacao.ex.: regras internas, standards da organizacao, etc.
Requisitos ExternosResultam de fatores externos ao sistema e ao seu processo dedesenvolvimento.Muitas vezes correspondem a requisitos de domınio.ex.: requisitos de interoperabilidade, aspetos legais, etc.
Alberto Simoes Engenharia de Requisitos 18/62
Tipologia de RequisitosTipos de Requisitos Nao Funcionais
Requisitos de ProdutoEspecificam como se deve comportar o produto de acordocom um conjunto de parametros.ex.: velocidade de execucao, fiabilidade, etc.
Requisitos OrganizacionaisDerivam de polıticas e procedimentos da organizacao.ex.: regras internas, standards da organizacao, etc.
Requisitos ExternosResultam de fatores externos ao sistema e ao seu processo dedesenvolvimento.Muitas vezes correspondem a requisitos de domınio.ex.: requisitos de interoperabilidade, aspetos legais, etc.
Alberto Simoes Engenharia de Requisitos 18/62
Tipologia de RequisitosTipos de Requisitos Nao Funcionais
Requisitos de ProdutoEspecificam como se deve comportar o produto de acordocom um conjunto de parametros.ex.: velocidade de execucao, fiabilidade, etc.
Requisitos OrganizacionaisDerivam de polıticas e procedimentos da organizacao.ex.: regras internas, standards da organizacao, etc.
Requisitos ExternosResultam de fatores externos ao sistema e ao seu processo dedesenvolvimento.Muitas vezes correspondem a requisitos de domınio.ex.: requisitos de interoperabilidade, aspetos legais, etc.
Alberto Simoes Engenharia de Requisitos 18/62
Tipologia de RequisitosTipos de Requisitos Nao Funcionais
Requisitos NãoFuncionais
Requisitos deProduto
Requisitos da Organização
RequisitosExternos
Requisitos deUsabilidade
Requisitos de Fiabilidade
Requisitos de Portabilidade
Requisitos deEficiência
Requisitos deEspaço
Requisitos deExecução
Requisitos deDistribuição
Requisitos deImplementação
Requisitos dosStandards Usados
Requisitos deInteroperabilidade
RequisitosÉticos
RequisitosLegislativos
Requisitos dePrivacidade
Requisitos deSegurança
Alberto Simoes Engenharia de Requisitos 19/62
Tipologia de RequisitosEspecificacao de Requisitos Nao Funcionais
Devem ser especificados na forma de objetivo.(intencao geral do utilizador, como facilidade de utilizacao)
Sempre que possıvel, devem ser verificaveis:(devem incorporar uma medida que permita testar de formaobjetiva se o requisito esta corretamente implementado)
Tipicamente sao difıceis de definir com rigor, e portanto,difıceis de verificar.
Exemplo:
o sistema deve ser facil de utilizar por operadores experientese organizado de tal forma que minimize erros do utilizador.os operadores experientes devem ser capazes de utilizar todasas funcoes do sistema apos duas horas de formacao; depoisdessa formacao, o numero medio de erros realizados pelosoperadores nao deve exceder dois por dia.
Alberto Simoes Engenharia de Requisitos 20/62
Tipologia de RequisitosEspecificacao de Requisitos Nao Funcionais
Devem ser especificados na forma de objetivo.(intencao geral do utilizador, como facilidade de utilizacao)
Sempre que possıvel, devem ser verificaveis:(devem incorporar uma medida que permita testar de formaobjetiva se o requisito esta corretamente implementado)
Tipicamente sao difıceis de definir com rigor, e portanto,difıceis de verificar.
Exemplo:
o sistema deve ser facil de utilizar por operadores experientese organizado de tal forma que minimize erros do utilizador.os operadores experientes devem ser capazes de utilizar todasas funcoes do sistema apos duas horas de formacao; depoisdessa formacao, o numero medio de erros realizados pelosoperadores nao deve exceder dois por dia.
Alberto Simoes Engenharia de Requisitos 20/62
Tipologia de RequisitosEspecificacao de Requisitos Nao Funcionais
Devem ser especificados na forma de objetivo.(intencao geral do utilizador, como facilidade de utilizacao)
Sempre que possıvel, devem ser verificaveis:(devem incorporar uma medida que permita testar de formaobjetiva se o requisito esta corretamente implementado)
Tipicamente sao difıceis de definir com rigor, e portanto,difıceis de verificar.
Exemplo:
o sistema deve ser facil de utilizar por operadores experientese organizado de tal forma que minimize erros do utilizador.
os operadores experientes devem ser capazes de utilizar todasas funcoes do sistema apos duas horas de formacao; depoisdessa formacao, o numero medio de erros realizados pelosoperadores nao deve exceder dois por dia.
Alberto Simoes Engenharia de Requisitos 20/62
Tipologia de RequisitosEspecificacao de Requisitos Nao Funcionais
Devem ser especificados na forma de objetivo.(intencao geral do utilizador, como facilidade de utilizacao)
Sempre que possıvel, devem ser verificaveis:(devem incorporar uma medida que permita testar de formaobjetiva se o requisito esta corretamente implementado)
Tipicamente sao difıceis de definir com rigor, e portanto,difıceis de verificar.
Exemplo:
o sistema deve ser facil de utilizar por operadores experientese organizado de tal forma que minimize erros do utilizador.os operadores experientes devem ser capazes de utilizar todasas funcoes do sistema apos duas horas de formacao; depoisdessa formacao, o numero medio de erros realizados pelosoperadores nao deve exceder dois por dia.
Alberto Simoes Engenharia de Requisitos 20/62
Tipologia de RequisitosMedidas para Requisitos Nao Funcionais
Velocidade
transacoes processadas por segundotempo de resposta para determinado eventotempo de desenho do ecra
Tamanho
{tamanho de disco ocupado (MB)largura de banda usada (MB)
Facilidade de uso
{tempo de formacaonumero de paginas de documentacao
Confianca
tempo medio de falhaprobabilidade de nao disponibilidaderacio de ocorrencia de falhas
Robustez
tempo de reinıcio apos falhapercentagem de situacoes que provocam falhasprobabilidade de corrupcao de dados por falha
Portabilidade
{numero de plataformas alvoperc. de linhas de codigo especıficas
Alberto Simoes Engenharia de Requisitos 21/62
Tipologia de RequisitosMedidas para Requisitos Nao Funcionais
Velocidade
transacoes processadas por segundotempo de resposta para determinado eventotempo de desenho do ecra
Tamanho
{tamanho de disco ocupado (MB)largura de banda usada (MB)
Facilidade de uso
{tempo de formacaonumero de paginas de documentacao
Confianca
tempo medio de falhaprobabilidade de nao disponibilidaderacio de ocorrencia de falhas
Robustez
tempo de reinıcio apos falhapercentagem de situacoes que provocam falhasprobabilidade de corrupcao de dados por falha
Portabilidade
{numero de plataformas alvoperc. de linhas de codigo especıficas
Alberto Simoes Engenharia de Requisitos 21/62
Tipologia de RequisitosMedidas para Requisitos Nao Funcionais
Velocidade
transacoes processadas por segundotempo de resposta para determinado eventotempo de desenho do ecra
Tamanho
{tamanho de disco ocupado (MB)largura de banda usada (MB)
Facilidade de uso
{tempo de formacaonumero de paginas de documentacao
Confianca
tempo medio de falhaprobabilidade de nao disponibilidaderacio de ocorrencia de falhas
Robustez
tempo de reinıcio apos falhapercentagem de situacoes que provocam falhasprobabilidade de corrupcao de dados por falha
Portabilidade
{numero de plataformas alvoperc. de linhas de codigo especıficas
Alberto Simoes Engenharia de Requisitos 21/62
Tipologia de RequisitosMedidas para Requisitos Nao Funcionais
Velocidade
transacoes processadas por segundotempo de resposta para determinado eventotempo de desenho do ecra
Tamanho
{tamanho de disco ocupado (MB)largura de banda usada (MB)
Facilidade de uso
{tempo de formacaonumero de paginas de documentacao
Confianca
tempo medio de falhaprobabilidade de nao disponibilidaderacio de ocorrencia de falhas
Robustez
tempo de reinıcio apos falhapercentagem de situacoes que provocam falhasprobabilidade de corrupcao de dados por falha
Portabilidade
{numero de plataformas alvoperc. de linhas de codigo especıficas
Alberto Simoes Engenharia de Requisitos 21/62
Tipologia de RequisitosMedidas para Requisitos Nao Funcionais
Velocidade
transacoes processadas por segundotempo de resposta para determinado eventotempo de desenho do ecra
Tamanho
{tamanho de disco ocupado (MB)largura de banda usada (MB)
Facilidade de uso
{tempo de formacaonumero de paginas de documentacao
Confianca
tempo medio de falhaprobabilidade de nao disponibilidaderacio de ocorrencia de falhas
Robustez
tempo de reinıcio apos falhapercentagem de situacoes que provocam falhasprobabilidade de corrupcao de dados por falha
Portabilidade
{numero de plataformas alvoperc. de linhas de codigo especıficas
Alberto Simoes Engenharia de Requisitos 21/62
Tipologia de RequisitosMedidas para Requisitos Nao Funcionais
Velocidade
transacoes processadas por segundotempo de resposta para determinado eventotempo de desenho do ecra
Tamanho
{tamanho de disco ocupado (MB)largura de banda usada (MB)
Facilidade de uso
{tempo de formacaonumero de paginas de documentacao
Confianca
tempo medio de falhaprobabilidade de nao disponibilidaderacio de ocorrencia de falhas
Robustez
tempo de reinıcio apos falhapercentagem de situacoes que provocam falhasprobabilidade de corrupcao de dados por falha
Portabilidade
{numero de plataformas alvoperc. de linhas de codigo especıficas
Alberto Simoes Engenharia de Requisitos 21/62
Tipologia de RequisitosExercıcios
“Em todas as janelas o utilizador devera ter acesso a um botaopara aceder a documentacao contextual.”
Requisito Funcional
Alberto Simoes Engenharia de Requisitos 22/62
Tipologia de RequisitosExercıcios
“Em todas as janelas o utilizador devera ter acesso a um botaopara aceder a documentacao contextual.”
Requisito Funcional
Alberto Simoes Engenharia de Requisitos 22/62
Tipologia de RequisitosExercıcios
“Cada transacao com a base de dados nao pode usar mais que 100KB de largura de banda.”
Requisito Nao Funcional
Alberto Simoes Engenharia de Requisitos 23/62
Tipologia de RequisitosExercıcios
“Cada transacao com a base de dados nao pode usar mais que 100KB de largura de banda.”
Requisito Nao Funcional
Alberto Simoes Engenharia de Requisitos 23/62
Tipologia de RequisitosExercıcios
“Para cada cliente devera ser armazenado o numero fiscal.”
Requisito Nao Funcional (e possivelmente de domınio)
Alberto Simoes Engenharia de Requisitos 24/62
Tipologia de RequisitosExercıcios
“Para cada cliente devera ser armazenado o numero fiscal.”
Requisito Nao Funcional (e possivelmente de domınio)
Alberto Simoes Engenharia de Requisitos 24/62
Tipologia de RequisitosExercıcios
“O utilizador nao devera poder introduzir um cliente sem indicar oseu numero fiscal.”
Requisito Funcional
Alberto Simoes Engenharia de Requisitos 25/62
Tipologia de RequisitosExercıcios
“O utilizador nao devera poder introduzir um cliente sem indicar oseu numero fiscal.”
Requisito Funcional
Alberto Simoes Engenharia de Requisitos 25/62
Tipologia de RequisitosExercıcios
“O acesso ao sistema deve ser validado usando uma senha deseguranca.”
Requisito Nao Funcional
Alberto Simoes Engenharia de Requisitos 26/62
Tipologia de RequisitosExercıcios
“O acesso ao sistema deve ser validado usando uma senha deseguranca.”
Requisito Nao Funcional
Alberto Simoes Engenharia de Requisitos 26/62
Tipologia de RequisitosExercıcios
“Devera ser possıvel alterar a senha de seguranca pelo proprioutilizador.”
Requisito Funcional
Alberto Simoes Engenharia de Requisitos 27/62
Tipologia de RequisitosExercıcios
“Devera ser possıvel alterar a senha de seguranca pelo proprioutilizador.”
Requisito Funcional
Alberto Simoes Engenharia de Requisitos 27/62
Tipologia de RequisitosExercıcios
“A interface ao utilizador deve ter um aspeto amigavel, e coressobrias.”
Requisito Nao Funcional
Alberto Simoes Engenharia de Requisitos 28/62
Tipologia de RequisitosExercıcios
“A interface ao utilizador deve ter um aspeto amigavel, e coressobrias.”
Requisito Nao Funcional
Alberto Simoes Engenharia de Requisitos 28/62
Parte III
Recolha de Requisitos
Alberto Simoes Engenharia de Requisitos 29/62
Recolha de RequisitosTecnicas para a Recolha de Requisitos
Existem varias tecnicas para a recolha, selecao e especificacao derequisitos:
Entrevistas
Questionarios
Analise Documental
Observacao
Perspetivas
Cenarios
Prototipagem
O Analista de sistemas deve saber como e quando utilizar cadauma, assim como as combinar.
Alberto Simoes Engenharia de Requisitos 30/62
Recolha de RequisitosEntrevistas
Processo
Selecionar os entrevistados,baseado no tipo de informacaonecessaria, e garantindo diferentesperspetivas;
Desenvolver o Guiao da entrevista;
Definir Objetivos da entrevista;
Conduzir a entrevista;
Apresentar resultados daentrevista;
Conteudo da Entrevista
Questoes fechadas:“Quantas encomendas recebe portelefone diariamente?”
“Como sao feitas as encomendas?”
Questoes abertas:“O que acha do sistema atual?”
“Quais os problemas com que se
depara diariamente?”
Questoes de prova:“Pode-me dar um exemplo?”
“Pode-me explicar com mais
detalhe?”
Alberto Simoes Engenharia de Requisitos 31/62
Recolha de RequisitosEntrevistas
Processo
Selecionar os entrevistados,baseado no tipo de informacaonecessaria, e garantindo diferentesperspetivas;
Desenvolver o Guiao da entrevista;
Definir Objetivos da entrevista;
Conduzir a entrevista;
Apresentar resultados daentrevista;
Conteudo da Entrevista
Questoes fechadas:“Quantas encomendas recebe portelefone diariamente?”
“Como sao feitas as encomendas?”
Questoes abertas:“O que acha do sistema atual?”
“Quais os problemas com que se
depara diariamente?”
Questoes de prova:“Pode-me dar um exemplo?”
“Pode-me explicar com mais
detalhe?”
Alberto Simoes Engenharia de Requisitos 31/62
Recolha de RequisitosEntrevistas
Processo
Selecionar os entrevistados,baseado no tipo de informacaonecessaria, e garantindo diferentesperspetivas;
Desenvolver o Guiao da entrevista;
Definir Objetivos da entrevista;
Conduzir a entrevista;
Apresentar resultados daentrevista;
Conteudo da Entrevista
Questoes fechadas:“Quantas encomendas recebe portelefone diariamente?”
“Como sao feitas as encomendas?”
Questoes abertas:“O que acha do sistema atual?”
“Quais os problemas com que se
depara diariamente?”
Questoes de prova:“Pode-me dar um exemplo?”
“Pode-me explicar com mais
detalhe?”
Alberto Simoes Engenharia de Requisitos 31/62
Recolha de RequisitosEntrevistas
Processo
Selecionar os entrevistados,baseado no tipo de informacaonecessaria, e garantindo diferentesperspetivas;
Desenvolver o Guiao da entrevista;
Definir Objetivos da entrevista;
Conduzir a entrevista;
Apresentar resultados daentrevista;
Conteudo da Entrevista
Questoes fechadas:“Quantas encomendas recebe portelefone diariamente?”
“Como sao feitas as encomendas?”
Questoes abertas:“O que acha do sistema atual?”
“Quais os problemas com que se
depara diariamente?”
Questoes de prova:“Pode-me dar um exemplo?”
“Pode-me explicar com mais
detalhe?”
Alberto Simoes Engenharia de Requisitos 31/62
Recolha de RequisitosQuestionarios
Processo
Conjunto de questoes escritas,usualmente enviadas para umgrande numero de pessoas;
Podem ser em formato de papel oueletronico;
Selecionar participantesrepresentativos;
Desenvolver questoes claras e defacil analise;
Definir estrategias para obter umbom numero de respostas;
Mostrar o impacto do questionarioaos questionados;
Cuidados
Comecar com questoesinteressantes;
Agrupar em seccoes coerentes;
Nao colocar perguntas importantesno fim;
Nao encher demasiado as paginas;
Evitar o uso de abreviaturas;
Evitar fazer perguntastendenciosas;
Numerar as perguntas;
Fazer teste previo ao questionario;
Garantir anonimato nas respostas;
Alberto Simoes Engenharia de Requisitos 32/62
Recolha de RequisitosQuestionarios
Processo
Conjunto de questoes escritas,usualmente enviadas para umgrande numero de pessoas;
Podem ser em formato de papel oueletronico;
Selecionar participantesrepresentativos;
Desenvolver questoes claras e defacil analise;
Definir estrategias para obter umbom numero de respostas;
Mostrar o impacto do questionarioaos questionados;
Cuidados
Comecar com questoesinteressantes;
Agrupar em seccoes coerentes;
Nao colocar perguntas importantesno fim;
Nao encher demasiado as paginas;
Evitar o uso de abreviaturas;
Evitar fazer perguntastendenciosas;
Numerar as perguntas;
Fazer teste previo ao questionario;
Garantir anonimato nas respostas;
Alberto Simoes Engenharia de Requisitos 32/62
Recolha de RequisitosAnalise Documental
Documentos que contem informacao do sistema “as-is”(estado atual!)
Regulamentos, Relatorios internos, Registos periodicos,Formularios, Manuais de procedimentos, . . .
Procurar elementos adicionados pelos utilizadores aosformularios (notas a margem...)
Procurar elementos nao utilizados;
Dar particular atencao aos documentos:
Que descrevem a organizacao;Que descrevem os conteudos funcionais dos varios cargos;Que relatam as atividades da organizacao;Que constituem material publicitario e promocional daorganizacao;
Alberto Simoes Engenharia de Requisitos 33/62
Recolha de RequisitosAnalise Documental
Documentos que contem informacao do sistema “as-is”(estado atual!)
Regulamentos, Relatorios internos, Registos periodicos,Formularios, Manuais de procedimentos, . . .
Procurar elementos adicionados pelos utilizadores aosformularios (notas a margem...)
Procurar elementos nao utilizados;
Dar particular atencao aos documentos:
Que descrevem a organizacao;Que descrevem os conteudos funcionais dos varios cargos;Que relatam as atividades da organizacao;Que constituem material publicitario e promocional daorganizacao;
Alberto Simoes Engenharia de Requisitos 33/62
Recolha de RequisitosAnalise Documental
Documentos que contem informacao do sistema “as-is”(estado atual!)
Regulamentos, Relatorios internos, Registos periodicos,Formularios, Manuais de procedimentos, . . .
Procurar elementos adicionados pelos utilizadores aosformularios (notas a margem...)
Procurar elementos nao utilizados;
Dar particular atencao aos documentos:
Que descrevem a organizacao;Que descrevem os conteudos funcionais dos varios cargos;Que relatam as atividades da organizacao;Que constituem material publicitario e promocional daorganizacao;
Alberto Simoes Engenharia de Requisitos 33/62
Recolha de RequisitosAnalise Documental
Documentos que contem informacao do sistema “as-is”(estado atual!)
Regulamentos, Relatorios internos, Registos periodicos,Formularios, Manuais de procedimentos, . . .
Procurar elementos adicionados pelos utilizadores aosformularios (notas a margem...)
Procurar elementos nao utilizados;
Dar particular atencao aos documentos:
Que descrevem a organizacao;Que descrevem os conteudos funcionais dos varios cargos;Que relatam as atividades da organizacao;Que constituem material publicitario e promocional daorganizacao;
Alberto Simoes Engenharia de Requisitos 33/62
Recolha de RequisitosObservacao
Observacao dos processos a serem executados;
Utilizadores/gestores nao se lembram com exatidao de tudo oque fazem;
Valida a informacao recolhida com outros metodos;
Ter em atencao que o comportamento das pessoas mudaquando estao a ser observadas;
Tentar ser discreto;
Identificar perıodos mortos e picos;
Alberto Simoes Engenharia de Requisitos 34/62
Recolha de RequisitosPerspetivas
Forma de estruturar requisitos, mostrando as perspetivas dosdiferentes stakeholders;
Nenhuma perspetiva e a correta;
Tipos de Perspetivas:
Dos intervenientesE a visao segundo as pessoas ou outros sistemas que interagemcom o sistema;
Do domınioCaracterısticas e constrangimentos do domınio, que afetam osrequisitos.
Alberto Simoes Engenharia de Requisitos 35/62
Recolha de RequisitosCenarios
Exemplos da vida real, de como o sistema interage e pode serutilizado.
Devem incluir:
Descricao da situacao(quando esta situacao ocorre, quem lida com ela, etc.)Situacao de arranque(quais sao os pressupostos para que este cenario possa ocorrer)Fluxo normal dos eventos(quem da a informacao, quem a introduz, quais as acoesdespoletadas pelo sistema)Situacoes de erro(o que pode correr mal?)Final do cenario(estado do sistema quando o caso real termina)
Alberto Simoes Engenharia de Requisitos 36/62
Recolha de RequisitosPrototipagem
Alguns utilizadores tem dificuldade em visualizar o sistema;
Pode ser util preparar prototipos de interfaces com o utilizador(mockups) que permitam discutir as funcionalidadesdesejadas;
Em casos em que a percecao do processo de transformacao epreparacao de informacao seja difıcil, podera fazer sentidoimplementar pequenos prototipos para simular as variaspossibilidades disponıveis.
Alberto Simoes Engenharia de Requisitos 37/62
Parte IV
Especificacao de Requisitos
Alberto Simoes Engenharia de Requisitos 38/62
Especificacao de RequisitosLinguagem Natural
Possivelmente a forma mais simples de especificar requisitos;
Mas a forma menos fiavel de especificar requisitos;
Problemas no uso da Linguagem Naturalpara especificar requisitos:
Falta de clarezaE difıcil obter precisao sem tornar a leitura do documentodifıcil.
Confusao de requisitosOs requisitos funcionais e nao funcionais tendem a sermisturados.
Amalgama de requisitosVarios requisitos diferentes sao muitas vezes expressos emconjunto, usando ate a mesma frase. Isto dificulta a suacorreta identificacao.
Alberto Simoes Engenharia de Requisitos 39/62
Especificacao de RequisitosLinguagem Natural
Possivelmente a forma mais simples de especificar requisitos;
Mas a forma menos fiavel de especificar requisitos;
Problemas no uso da Linguagem Naturalpara especificar requisitos:
Falta de clarezaE difıcil obter precisao sem tornar a leitura do documentodifıcil.
Confusao de requisitosOs requisitos funcionais e nao funcionais tendem a sermisturados.
Amalgama de requisitosVarios requisitos diferentes sao muitas vezes expressos emconjunto, usando ate a mesma frase. Isto dificulta a suacorreta identificacao.
Alberto Simoes Engenharia de Requisitos 39/62
Especificacao de RequisitosLinguagem Natural
Possivelmente a forma mais simples de especificar requisitos;
Mas a forma menos fiavel de especificar requisitos;
Problemas no uso da Linguagem Naturalpara especificar requisitos:
Falta de clarezaE difıcil obter precisao sem tornar a leitura do documentodifıcil.
Confusao de requisitosOs requisitos funcionais e nao funcionais tendem a sermisturados.
Amalgama de requisitosVarios requisitos diferentes sao muitas vezes expressos emconjunto, usando ate a mesma frase. Isto dificulta a suacorreta identificacao.
Alberto Simoes Engenharia de Requisitos 39/62
Especificacao de RequisitosLinguagem Natural
Possivelmente a forma mais simples de especificar requisitos;
Mas a forma menos fiavel de especificar requisitos;
Problemas no uso da Linguagem Naturalpara especificar requisitos:
Falta de clarezaE difıcil obter precisao sem tornar a leitura do documentodifıcil.
Confusao de requisitosOs requisitos funcionais e nao funcionais tendem a sermisturados.
Amalgama de requisitosVarios requisitos diferentes sao muitas vezes expressos emconjunto, usando ate a mesma frase. Isto dificulta a suacorreta identificacao.
Alberto Simoes Engenharia de Requisitos 39/62
Especificacao de RequisitosLinguagem Natural
Possivelmente a forma mais simples de especificar requisitos;
Mas a forma menos fiavel de especificar requisitos;
Problemas no uso da Linguagem Naturalpara especificar requisitos:
Falta de clarezaE difıcil obter precisao sem tornar a leitura do documentodifıcil.
Confusao de requisitosOs requisitos funcionais e nao funcionais tendem a sermisturados.
Amalgama de requisitosVarios requisitos diferentes sao muitas vezes expressos emconjunto, usando ate a mesma frase. Isto dificulta a suacorreta identificacao.
Alberto Simoes Engenharia de Requisitos 39/62
Especificacao de RequisitosExemplos de mas especificacoes em LN
Requisito LIBSYSDeve fornecer um sistema de contabilidade financeira quemantenha os registos dos pagamentos realizados pelos utilizadoresdo sistema. Os gestores do sistema podem configura-lo de forma aque os utilizadores mais frequentes possam receber descontos.
Problemas:
descreve o conceito de sistema de contabilidade financeira aincluir no sistema de forma abstrata;
contudo, inclui tambem entrada detalhada que nao enecessario a este nıvel;
Alberto Simoes Engenharia de Requisitos 40/62
Especificacao de RequisitosExemplos de mas especificacoes em LN
Requisito LIBSYSDeve fornecer um sistema de contabilidade financeira quemantenha os registos dos pagamentos realizados pelos utilizadoresdo sistema. Os gestores do sistema podem configura-lo de forma aque os utilizadores mais frequentes possam receber descontos.
Problemas:
descreve o conceito de sistema de contabilidade financeira aincluir no sistema de forma abstrata;
contudo, inclui tambem entrada detalhada que nao enecessario a este nıvel;
Alberto Simoes Engenharia de Requisitos 40/62
Especificacao de RequisitosExemplos de mas especificacoes em LN
Requisito editor de grelhasPara facilitar o posicionamento de entidades num diagrama, outilizador pode configurar a grelha em centımetros ou polegadas,atraves de uma opcao no painel de controlo. Inicialmente, a grelhaesta desativada. A grelha pode ser ativada ou desativada aqualquer momento. Na vista “reduzir a dimensao”, a grelha teramenos linhas para nao saturar o diagrama de linhas.
Problemas:
requisitos funcionais conceptuais (a necessidade da grelha);
requisitos nao funcionais (as medidas da grelha);
requisitos nao funcionais de interface com o utilizador(ativacao da grelha);
Alberto Simoes Engenharia de Requisitos 41/62
Especificacao de RequisitosExemplos de mas especificacoes em LN
Requisito editor de grelhasPara facilitar o posicionamento de entidades num diagrama, outilizador pode configurar a grelha em centımetros ou polegadas,atraves de uma opcao no painel de controlo. Inicialmente, a grelhaesta desativada. A grelha pode ser ativada ou desativada aqualquer momento. Na vista “reduzir a dimensao”, a grelha teramenos linhas para nao saturar o diagrama de linhas.
Problemas:
requisitos funcionais conceptuais (a necessidade da grelha);
requisitos nao funcionais (as medidas da grelha);
requisitos nao funcionais de interface com o utilizador(ativacao da grelha);
Alberto Simoes Engenharia de Requisitos 41/62
Especificacao de RequisitosAlternativas ao uso da LN
Linguagem Natural EstruturadaConsiste em definir modelos para especificar os requisitos,usando estruturas frasicas rıgidas de facil interpretacao.
Linguagem de Descricao de ProjetoRecorrer a uma linguagem formal, do genero da usada emprogramacao ou algoritmia, mas mais abstrata, paraespecificar os requisitos.Notacoes GraficasDescrever os requisitos funcionais numa linguagem grafica epseudo-formal (ex: SADT ou UML), complementada comanotacoes textuais.Notacoes MatematicasNotacao formal, como por exemplo a teoria de conjuntos, paraeliminar qualquer ambiguidade. Levantam problemas nadificuldade de compreensao para pessoas nao familiarizadascom as notacoes usadas.
Alberto Simoes Engenharia de Requisitos 42/62
Especificacao de RequisitosAlternativas ao uso da LN
Linguagem Natural EstruturadaConsiste em definir modelos para especificar os requisitos,usando estruturas frasicas rıgidas de facil interpretacao.Linguagem de Descricao de ProjetoRecorrer a uma linguagem formal, do genero da usada emprogramacao ou algoritmia, mas mais abstrata, paraespecificar os requisitos.
Notacoes GraficasDescrever os requisitos funcionais numa linguagem grafica epseudo-formal (ex: SADT ou UML), complementada comanotacoes textuais.Notacoes MatematicasNotacao formal, como por exemplo a teoria de conjuntos, paraeliminar qualquer ambiguidade. Levantam problemas nadificuldade de compreensao para pessoas nao familiarizadascom as notacoes usadas.
Alberto Simoes Engenharia de Requisitos 42/62
Especificacao de RequisitosAlternativas ao uso da LN
Linguagem Natural EstruturadaConsiste em definir modelos para especificar os requisitos,usando estruturas frasicas rıgidas de facil interpretacao.Linguagem de Descricao de ProjetoRecorrer a uma linguagem formal, do genero da usada emprogramacao ou algoritmia, mas mais abstrata, paraespecificar os requisitos.Notacoes GraficasDescrever os requisitos funcionais numa linguagem grafica epseudo-formal (ex: SADT ou UML), complementada comanotacoes textuais.
Notacoes MatematicasNotacao formal, como por exemplo a teoria de conjuntos, paraeliminar qualquer ambiguidade. Levantam problemas nadificuldade de compreensao para pessoas nao familiarizadascom as notacoes usadas.
Alberto Simoes Engenharia de Requisitos 42/62
Especificacao de RequisitosAlternativas ao uso da LN
Linguagem Natural EstruturadaConsiste em definir modelos para especificar os requisitos,usando estruturas frasicas rıgidas de facil interpretacao.Linguagem de Descricao de ProjetoRecorrer a uma linguagem formal, do genero da usada emprogramacao ou algoritmia, mas mais abstrata, paraespecificar os requisitos.Notacoes GraficasDescrever os requisitos funcionais numa linguagem grafica epseudo-formal (ex: SADT ou UML), complementada comanotacoes textuais.Notacoes MatematicasNotacao formal, como por exemplo a teoria de conjuntos, paraeliminar qualquer ambiguidade. Levantam problemas nadificuldade de compreensao para pessoas nao familiarizadascom as notacoes usadas.
Alberto Simoes Engenharia de Requisitos 42/62
Especificacao de RequisitosDocumento de Requisitos
E uma declaracao oficial das funcionalidades do sistema, tendocomo principal destinatario quem vai desenvolver o software;
Resulta dos requisitos acordados entre as partes;
Nao e um documento de projeto do sistema: deve descrever Oque o sistema deve fazer, e nao como deve ser feito;
Alberto Simoes Engenharia de Requisitos 43/62
Especificacao de RequisitosDocumento de Requisitos
Descreve os requisitos para os stakeholders:
expresso em termos que eles os compreendam;compreensıvel de diferentes pontos de vista;revistos pelos proprios stakeholders;claro e nao ambıguo;
Descreve os requisitos para quem vai desenvolver o software:
tao preciso e especıfico quanto possıvel;expresso em termos que eles compreendam;facilitador de integracao de novos membros na equipa;
Regista requisitos para o futuro:
essencial para a evolucao do sistema;
Pode servir de documento contratual.
Alberto Simoes Engenharia de Requisitos 44/62
Especificacao de RequisitosDocumento de Requisitos - standard IEEE/ANSI 830-1993
Introducao
Objetivos do documentoAmbito do produtoDefinicao e abreviaturasReferencias
Descricao Geral
Perspetivas e funcoes do produtoCaraterısticas dos utilizadoresConstrangimentos geraisPressupostos e dependencias
Requisitos
Apendices
Alberto Simoes Engenharia de Requisitos 45/62
Especificacao de RequisitosPrototipagem da Interface
Esquematizar interfaces para as funcoes principais do software;
Servem como mecanismo de recolha e negociacao derequisitos;
Servem tambem como especificacao dos requisitos:
apresentam um conjunto de informacao que deve estardisponıvel;apresentam um conjunto de botoes/menus que correspondema funcionalidades que devem ser implementadas;
Cuidados!
usar uma ferramenta de desenho que nao se assemelhedemasiado a um produto final;caso contrario, cliente podera ter impressao que o softwareesta pronto!
Alberto Simoes Engenharia de Requisitos 46/62
Especificacao de RequisitosPrototipagem da Interface
Esquematizar interfaces para as funcoes principais do software;
Servem como mecanismo de recolha e negociacao derequisitos;
Servem tambem como especificacao dos requisitos:
apresentam um conjunto de informacao que deve estardisponıvel;apresentam um conjunto de botoes/menus que correspondema funcionalidades que devem ser implementadas;
Cuidados!
usar uma ferramenta de desenho que nao se assemelhedemasiado a um produto final;caso contrario, cliente podera ter impressao que o softwareesta pronto!
Alberto Simoes Engenharia de Requisitos 46/62
Especificacao de RequisitosPrototipagem da Interface
Esquematizar interfaces para as funcoes principais do software;
Servem como mecanismo de recolha e negociacao derequisitos;
Servem tambem como especificacao dos requisitos:
apresentam um conjunto de informacao que deve estardisponıvel;apresentam um conjunto de botoes/menus que correspondema funcionalidades que devem ser implementadas;
Cuidados!
usar uma ferramenta de desenho que nao se assemelhedemasiado a um produto final;caso contrario, cliente podera ter impressao que o softwareesta pronto!
Alberto Simoes Engenharia de Requisitos 46/62
Especificacao de RequisitosPrototipagem da Interface
Esquematizar interfaces para as funcoes principais do software;
Servem como mecanismo de recolha e negociacao derequisitos;
Servem tambem como especificacao dos requisitos:
apresentam um conjunto de informacao que deve estardisponıvel;apresentam um conjunto de botoes/menus que correspondema funcionalidades que devem ser implementadas;
Cuidados!
usar uma ferramenta de desenho que nao se assemelhedemasiado a um produto final;caso contrario, cliente podera ter impressao que o softwareesta pronto!
Alberto Simoes Engenharia de Requisitos 46/62
Especificacao de RequisitosPrototipagem da Interface - Exemplo
- + Adicionar Funcionário
Telefone : ...
Morada : ...
Nome : ...
S M T W T F S
1 2 3 4 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
March 2009
5Feminino
Sexo MasculinoData de Nascimento
Adicionar Cancelar
Alberto Simoes Engenharia de Requisitos 47/62
Especificacao de RequisitosEspecificacao Textual
Embora a linguagem natural seja ambıgua, e imprescindıveluma descricao textual dos requisitos;
Complementa os prototipos de interface ou os diagramasUML;
Devem ser descritos de forma organizada, e estruturada,usando linguagem clara;
Evitar o uso de gıria informatica;
Devem ser descritos usando a forma ativa dos verbos(presente, nao passado).
Alberto Simoes Engenharia de Requisitos 48/62
Especificacao de RequisitosEspecificacao Textual - Exemplo
3. Edicao de diagramas.
3.5 Adicionar um nodo num diagrama.
3.5.1 O editor deve permitir que o utilizador adicione nodos dedeterminado tipo ao seu diagrama.
3.5.2 A sequencia de acoes para adicionar um nodo deve ser:
O utilizador seleciona o tipo de nodo a ser adicionado.O utilizador move o cursor para uma posicao aproximada parao nodo, no diagrama, indicando que o sımbolo deve seradicionado nesse ponto.O utilizador posteriormente deve arraste o sımbolo para a suaposicao final.
3.5.3 Analise Logica: O utilizador e a melhor pessoa para decidir ondecolocar um nodo no diagrama. Esta abordagem da controlo diretosobre a selecao e posicionamento dos nodos.
Alberto Simoes Engenharia de Requisitos 49/62
Especificacao de RequisitosEspecificacao Textual - Exemplo
3. Edicao de diagramas.
3.5 Adicionar um nodo num diagrama.
3.5.1 O editor deve permitir que o utilizador adicione nodos dedeterminado tipo ao seu diagrama.
3.5.2 A sequencia de acoes para adicionar um nodo deve ser:
O utilizador seleciona o tipo de nodo a ser adicionado.O utilizador move o cursor para uma posicao aproximada parao nodo, no diagrama, indicando que o sımbolo deve seradicionado nesse ponto.O utilizador posteriormente deve arraste o sımbolo para a suaposicao final.
3.5.3 Analise Logica: O utilizador e a melhor pessoa para decidir ondecolocar um nodo no diagrama. Esta abordagem da controlo diretosobre a selecao e posicionamento dos nodos.
Alberto Simoes Engenharia de Requisitos 49/62
Especificacao de RequisitosEspecificacao Textual - Exemplo
3. Edicao de diagramas.
3.5 Adicionar um nodo num diagrama.
3.5.1 O editor deve permitir que o utilizador adicione nodos dedeterminado tipo ao seu diagrama.
3.5.2 A sequencia de acoes para adicionar um nodo deve ser:
O utilizador seleciona o tipo de nodo a ser adicionado.O utilizador move o cursor para uma posicao aproximada parao nodo, no diagrama, indicando que o sımbolo deve seradicionado nesse ponto.O utilizador posteriormente deve arraste o sımbolo para a suaposicao final.
3.5.3 Analise Logica: O utilizador e a melhor pessoa para decidir ondecolocar um nodo no diagrama. Esta abordagem da controlo diretosobre a selecao e posicionamento dos nodos.
Alberto Simoes Engenharia de Requisitos 49/62
Especificacao de RequisitosEspecificacao Textual - Exemplo
3. Edicao de diagramas.
3.5 Adicionar um nodo num diagrama.
3.5.1 O editor deve permitir que o utilizador adicione nodos dedeterminado tipo ao seu diagrama.
3.5.2 A sequencia de acoes para adicionar um nodo deve ser:
O utilizador seleciona o tipo de nodo a ser adicionado.O utilizador move o cursor para uma posicao aproximada parao nodo, no diagrama, indicando que o sımbolo deve seradicionado nesse ponto.O utilizador posteriormente deve arraste o sımbolo para a suaposicao final.
3.5.3 Analise Logica: O utilizador e a melhor pessoa para decidir ondecolocar um nodo no diagrama. Esta abordagem da controlo diretosobre a selecao e posicionamento dos nodos.
Alberto Simoes Engenharia de Requisitos 49/62
Especificacao de RequisitosEspecificacao Textual - Exemplo
3. Edicao de diagramas.
3.5 Adicionar um nodo num diagrama.
3.5.1 O editor deve permitir que o utilizador adicione nodos dedeterminado tipo ao seu diagrama.
3.5.2 A sequencia de acoes para adicionar um nodo deve ser:
O utilizador seleciona o tipo de nodo a ser adicionado.O utilizador move o cursor para uma posicao aproximada parao nodo, no diagrama, indicando que o sımbolo deve seradicionado nesse ponto.O utilizador posteriormente deve arraste o sımbolo para a suaposicao final.
3.5.3 Analise Logica: O utilizador e a melhor pessoa para decidir ondecolocar um nodo no diagrama. Esta abordagem da controlo diretosobre a selecao e posicionamento dos nodos.
Alberto Simoes Engenharia de Requisitos 49/62
Especificacao de RequisitosDiagramas
A especificacao textual devera ser complementada comdiagramas;
Existem diferentes notacoes:
Diagramas de Fluxo de Dados;Diagramas de Caso de Uso (UML);Diagramas de Atividade (UML);Diagramas de Sequencia (UML);. . .
Alberto Simoes Engenharia de Requisitos 50/62
Parte V
Diagramas de Caso de Uso
Alberto Simoes Engenharia de Requisitos 51/62
Diagramas de Caso de UsoAtores
Alberto Simoes Engenharia de Requisitos 52/62
Diagramas de Caso de UsoAtor
������������������
���
Representado por um stick-man, acompanhadode um nome;
O nome do ator devera ser facil de compreenderpelo cliente e pela equipa de desenvolvimento;
Nem todos os seres humanos que interagem como sistema sao atores (alguns fazem parte doproprio sistema);
Nem todos os atores sao seres humanos (porexemplo, outros sistemas que interagem com osistema a ser desenvolvido);
Por exemplo, o proprio relogio do sistema podeser visto como um ator, que despoleta acoes adeterminadas horas;
Alberto Simoes Engenharia de Requisitos 53/62
Diagramas de Caso de UsoAtor
������������������
���
Representado por um stick-man, acompanhadode um nome;
O nome do ator devera ser facil de compreenderpelo cliente e pela equipa de desenvolvimento;
Nem todos os seres humanos que interagem como sistema sao atores (alguns fazem parte doproprio sistema);
Nem todos os atores sao seres humanos (porexemplo, outros sistemas que interagem com osistema a ser desenvolvido);
Por exemplo, o proprio relogio do sistema podeser visto como um ator, que despoleta acoes adeterminadas horas;
Alberto Simoes Engenharia de Requisitos 53/62
Diagramas de Caso de UsoAtor
������������������
���
Representado por um stick-man, acompanhadode um nome;
O nome do ator devera ser facil de compreenderpelo cliente e pela equipa de desenvolvimento;
Nem todos os seres humanos que interagem como sistema sao atores (alguns fazem parte doproprio sistema);
Nem todos os atores sao seres humanos (porexemplo, outros sistemas que interagem com osistema a ser desenvolvido);
Por exemplo, o proprio relogio do sistema podeser visto como um ator, que despoleta acoes adeterminadas horas;
Alberto Simoes Engenharia de Requisitos 53/62
Diagramas de Caso de UsoAtor
������������������
���
Representado por um stick-man, acompanhadode um nome;
O nome do ator devera ser facil de compreenderpelo cliente e pela equipa de desenvolvimento;
Nem todos os seres humanos que interagem como sistema sao atores (alguns fazem parte doproprio sistema);
Nem todos os atores sao seres humanos (porexemplo, outros sistemas que interagem com osistema a ser desenvolvido);
Por exemplo, o proprio relogio do sistema podeser visto como um ator, que despoleta acoes adeterminadas horas;
Alberto Simoes Engenharia de Requisitos 53/62
Diagramas de Caso de UsoAtor
������������������
���
Representado por um stick-man, acompanhadode um nome;
O nome do ator devera ser facil de compreenderpelo cliente e pela equipa de desenvolvimento;
Nem todos os seres humanos que interagem como sistema sao atores (alguns fazem parte doproprio sistema);
Nem todos os atores sao seres humanos (porexemplo, outros sistemas que interagem com osistema a ser desenvolvido);
Por exemplo, o proprio relogio do sistema podeser visto como um ator, que despoleta acoes adeterminadas horas;
Alberto Simoes Engenharia de Requisitos 53/62
Diagramas de Caso de UsoGeneralizacao de Atores
������������������
��������
�������� ���
����������
�� ����
����������
��������
���������
�� ���������
Alguns atores sao capazes de realizartodas as operacoes que outros atores;
Por exemplo, e tıpico que umadministrador possa realizar todas asoperacoes de um utilizador normal (eoutras especıficas);
O chefe de caixa num supermercadotipicamente tambem e caixa: paraalem de fazer o que um caixa faz, temcapacidade de realizar outrasoperacoes;
Nestes casos, usa-se uma seta degeneralizacao (com um triangulo comoponta), que parte do ator mais generico,em direcao ao ator mais especıfico;
Alberto Simoes Engenharia de Requisitos 54/62
Diagramas de Caso de UsoCasos de Uso
������������������
������ � ��������� ��� ��� �
Um caso de uso, ou uma tarefa, e representadodentro de uma oval;
Pode ser tao simples como permitir que outilizador realize login;Pode ser tao complicado como executar umatransacao distribuıda por varias bases de dadosglobais;
E uma interacao completa, que inclui aintroducao de dados no sistema (ou pelo menoso pedido de determinada funcionalidade), e oretorno por parte do sistema;
Um caso de uso e qualquer coisa que providencia umresultado mensuravel para o utilizador ou um sistemaexterno
Alberto Simoes Engenharia de Requisitos 55/62
Diagramas de Caso de UsoCasos de Uso
������������������
������ � ��������� ��� ��� �
Um caso de uso, ou uma tarefa, e representadodentro de uma oval;
Pode ser tao simples como permitir que outilizador realize login;Pode ser tao complicado como executar umatransacao distribuıda por varias bases de dadosglobais;
E uma interacao completa, que inclui aintroducao de dados no sistema (ou pelo menoso pedido de determinada funcionalidade), e oretorno por parte do sistema;
Um caso de uso e qualquer coisa que providencia umresultado mensuravel para o utilizador ou um sistemaexterno
Alberto Simoes Engenharia de Requisitos 55/62
Diagramas de Caso de UsoCasos de Uso
������������������
������ � ��������� ��� ��� �
Um caso de uso, ou uma tarefa, e representadodentro de uma oval;
Pode ser tao simples como permitir que outilizador realize login;Pode ser tao complicado como executar umatransacao distribuıda por varias bases de dadosglobais;
E uma interacao completa, que inclui aintroducao de dados no sistema (ou pelo menoso pedido de determinada funcionalidade), e oretorno por parte do sistema;
Um caso de uso e qualquer coisa que providencia umresultado mensuravel para o utilizador ou um sistemaexterno
Alberto Simoes Engenharia de Requisitos 55/62
Diagramas de Caso de UsoCasos de Uso
������������������
������ � ��������� ��� ��� �
Um caso de uso, ou uma tarefa, e representadodentro de uma oval;
Pode ser tao simples como permitir que outilizador realize login;Pode ser tao complicado como executar umatransacao distribuıda por varias bases de dadosglobais;
E uma interacao completa, que inclui aintroducao de dados no sistema (ou pelo menoso pedido de determinada funcionalidade), e oretorno por parte do sistema;
Um caso de uso e qualquer coisa que providencia umresultado mensuravel para o utilizador ou um sistemaexterno
Alberto Simoes Engenharia de Requisitos 55/62
Diagramas de Caso de UsoLinhas de Comunicacao
������������������
��������
�������� ���
���� ���������
�����
Relacionam os atores com os casosde uso com que interagem;
Tipicamente os diagramas naorepresentam a ordem pela qual estainteracao e feita;
Uma linha de comunicacao significaapenas que o ator esta envolvidoem determinado uso do sistema;
Alberto Simoes Engenharia de Requisitos 56/62
Diagramas de Caso de UsoLimites do Sistema
������������������
������� ���
� �� �
��������� ����
����
������������������
������� Embora exista uma separacaoimplıcita entre atores e casos deuso, e habitual colocar estesultimos numa caixa;
Habitualmente nesta caixa einscrito o nome do sistema;
Alberto Simoes Engenharia de Requisitos 57/62
Diagramas de Caso de UsoDescricao dos Casos de Uso
Cada caso de uso devera ser acompanhado de uma descricaodetalhada do processo (como a definicao de um requisito).
Caso de uso: criar novo utilizador no blogObjetivo: um utilizador solicitou ao administrador um utilizador no blog
Condicao de Sucesso: um novo utilizador e criado para o autorCondicao de Falha: e rejeitada a requisicao de novo utilizador
Principal Ator: administradorAtores Secundarios: BD de credenciais
Processo:
1. O administrador escolhe a opcao de criar novo utilizador;
2. O administrador escolhe o tipo de utilizador;
3. O administrador preenche formulario com dados do utilizador;
4. Os detalhes do utilizador sao verificados na BD de credenciais;
5. O utilizador do blog e criado;
6. Sao enviados os detalhes do utilizador por e-mail para o utilizador;
Extensoes:
4.1. A BD de credenciais nao verifica os detalhes do utilizador;
4.2. A requisicao de novo utilizador e rejeitada;
Alberto Simoes Engenharia de Requisitos 58/62
Diagramas de Caso de UsoDescricao dos Casos de Uso
Cada caso de uso devera ser acompanhado de uma descricaodetalhada do processo (como a definicao de um requisito).
Caso de uso: criar novo utilizador no blogObjetivo: um utilizador solicitou ao administrador um utilizador no blog
Condicao de Sucesso: um novo utilizador e criado para o autorCondicao de Falha: e rejeitada a requisicao de novo utilizador
Principal Ator: administradorAtores Secundarios: BD de credenciais
Processo:
1. O administrador escolhe a opcao de criar novo utilizador;
2. O administrador escolhe o tipo de utilizador;
3. O administrador preenche formulario com dados do utilizador;
4. Os detalhes do utilizador sao verificados na BD de credenciais;
5. O utilizador do blog e criado;
6. Sao enviados os detalhes do utilizador por e-mail para o utilizador;
Extensoes:
4.1. A BD de credenciais nao verifica os detalhes do utilizador;
4.2. A requisicao de novo utilizador e rejeitada;
Alberto Simoes Engenharia de Requisitos 58/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
Considere-se o seguinte cenario:������������������
������� ���
� �� ���������� ��������
������������������
�������
� �� ����������������
���� ���������
Nao ha relacao entre os dois casos de uso?
Os casos de uso podem partilhar operacoes;
Por exemplo, para criar um utilizador no blog, ou um wikipessoal, sera necessario validar a identidade do utilizador;
Podemos colocar essa operacao em evidencia.
Alberto Simoes Engenharia de Requisitos 59/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
Considere-se o seguinte cenario:������������������
������� ���
� �� ���������� ��������
������������������
�������
� �� ����������������
���� ���������
Nao ha relacao entre os dois casos de uso?
Os casos de uso podem partilhar operacoes;
Por exemplo, para criar um utilizador no blog, ou um wikipessoal, sera necessario validar a identidade do utilizador;
Podemos colocar essa operacao em evidencia.
Alberto Simoes Engenharia de Requisitos 59/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
������������������
������� ���
� �� ���������� ��������
������������������ �������
� �� ����������������
���� ���������
�� ����� ����������
����������
����������
Ao separar os casos de uso partilhados e coloca-los em evidencia daenfase, por exemplo, a que apenas o caso de uso “verificaridentidade” tera de comunicar com a base de dados de credenciais;
Do mesmo modo, torna claro para o programador que poderadesenvolver um modulo separado que possa ser reaproveitadonoutras situacoes;
Na descricao textual do caso de uso remove-se os itens do processoque se referem a este novo caso de uso, e coloca-se uma nota:Include: Verificar Identidade;
Alberto Simoes Engenharia de Requisitos 60/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
������������������
������� ���
� �� ���������� ��������
������������������ �������
� �� ����������������
���� ���������
�� ����� ����������
����������
����������
Ao separar os casos de uso partilhados e coloca-los em evidencia daenfase, por exemplo, a que apenas o caso de uso “verificaridentidade” tera de comunicar com a base de dados de credenciais;
Do mesmo modo, torna claro para o programador que poderadesenvolver um modulo separado que possa ser reaproveitadonoutras situacoes;
Na descricao textual do caso de uso remove-se os itens do processoque se referem a este novo caso de uso, e coloca-se uma nota:Include: Verificar Identidade;
Alberto Simoes Engenharia de Requisitos 60/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
������������������
������� ���
� �� ���������� ��������
������������������ �������
� �� ����������������
���� ���������
�� ����� ����������
����������
����������
Ao separar os casos de uso partilhados e coloca-los em evidencia daenfase, por exemplo, a que apenas o caso de uso “verificaridentidade” tera de comunicar com a base de dados de credenciais;
Do mesmo modo, torna claro para o programador que poderadesenvolver um modulo separado que possa ser reaproveitadonoutras situacoes;
Na descricao textual do caso de uso remove-se os itens do processoque se referem a este novo caso de uso, e coloca-se uma nota:Include: Verificar Identidade;
Alberto Simoes Engenharia de Requisitos 60/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
������������������
������� ���
� �� ���������� ��������
������������������ �������
� �� ����������������
���� ���������
�� ����� ����������
����������
����������
Ao separar os casos de uso partilhados e coloca-los em evidencia daenfase, por exemplo, a que apenas o caso de uso “verificaridentidade” tera de comunicar com a base de dados de credenciais;
Do mesmo modo, torna claro para o programador que poderadesenvolver um modulo separado que possa ser reaproveitadonoutras situacoes;
Na descricao textual do caso de uso remove-se os itens do processoque se referem a este novo caso de uso, e coloca-se uma nota:Include: Verificar Identidade;
Alberto Simoes Engenharia de Requisitos 60/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
Os casos de uso podem ser tornados mais genericos: por exemplo, o
processo de criar um utilizador normal no blog, ou um editor, deve ser
semelhante!
������������������
������� ��� � �� ���������� �
�������
������������������ �������
� �� ���������
�������
���� ���������
�� �����
����������
����
������
����������
� �� ���������� �
�� ������
����
� �� ���������� �
����� ���
����
Alberto Simoes Engenharia de Requisitos 61/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
Os casos de uso podem ser tornados mais genericos: por exemplo, o
processo de criar um utilizador normal no blog, ou um editor, deve ser
semelhante!������������������
������� ��� � �� ���������� �
�������
������������������ �������
� �� ���������
�������
���� ���������
�� �����
����������
����
������
����������
� �� ���������� �
�� ������
����
� �� ���������� �
����� ���
����
Alberto Simoes Engenharia de Requisitos 61/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
Na Generalizacao:
mostra-se que um caso de uso e uma generalizacao de outrocaso de uso (um caso particular);
todos os passos do caso de uso generico devem ocorrer nocaso particular;
todas as relacoes include existentes para com o caso de usogenerico tambem sao validas para os casos especıficos;
Alberto Simoes Engenharia de Requisitos 62/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
Na Generalizacao:
mostra-se que um caso de uso e uma generalizacao de outrocaso de uso (um caso particular);
todos os passos do caso de uso generico devem ocorrer nocaso particular;
todas as relacoes include existentes para com o caso de usogenerico tambem sao validas para os casos especıficos;
Alberto Simoes Engenharia de Requisitos 62/62
Diagramas de Caso de UsoRelacoes entre Casos de Uso
Na Generalizacao:
mostra-se que um caso de uso e uma generalizacao de outrocaso de uso (um caso particular);
todos os passos do caso de uso generico devem ocorrer nocaso particular;
todas as relacoes include existentes para com o caso de usogenerico tambem sao validas para os casos especıficos;
Alberto Simoes Engenharia de Requisitos 62/62