Aula 02 - Engenharia de Requisitos

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

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;

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.

Problemas na Engenharia de Requisitos

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

Como garantir que os requisitos recolhidos sao compreendidos deigual modo por cliente e membros da equipa do projeto?

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;

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;

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

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?

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.

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.

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.

Parte II

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

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;

Exemplos:

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.

Exemplos:

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;

fiabilidade;

tempo de resposta;

largura de banda;

fiabilidade;

tempo de resposta;

largura de banda;

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.

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

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.

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.

Exemplo:

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

Velocidade

Tamanho

Facilidade de uso

Confianca

Robustez

Portabilidade

Velocidade

Tamanho

Facilidade de uso

Confianca

Robustez

Portabilidade

Velocidade

Tamanho

Facilidade de uso

Confianca

Robustez

Portabilidade

Velocidade

Tamanho

Facilidade de uso

Confianca

Robustez

Portabilidade

Velocidade

Tamanho

Facilidade de uso

Confianca

Robustez

Portabilidade

Tipologia de RequisitosExercıcios

“Em todas as janelas o utilizador devera ter acesso a um botaopara aceder a documentacao contextual.”

Requisito Funcional

“Em todas as janelas o utilizador devera ter acesso a um botaopara aceder a documentacao contextual.”

Requisito Funcional

“Cada transacao com a base de dados nao pode usar mais que 100KB de largura de banda.”

Requisito Nao Funcional

“Cada transacao com a base de dados nao pode usar mais que 100KB de largura de banda.”

“Para cada cliente devera ser armazenado o numero fiscal.”

Requisito Nao Funcional (e possivelmente de domınio)

“Para cada cliente devera ser armazenado o numero fiscal.”

Requisito Nao Funcional (e possivelmente de domınio)

“O utilizador nao devera poder introduzir um cliente sem indicar oseu numero fiscal.”

Requisito Funcional

“O utilizador nao devera poder introduzir um cliente sem indicar oseu numero fiscal.”

Requisito Funcional

“O acesso ao sistema deve ser validado usando uma senha deseguranca.”

“Devera ser possıvel alterar a senha de seguranca pelo proprioutilizador.”

Requisito Funcional

“Devera ser possıvel alterar a senha de seguranca pelo proprioutilizador.”

Requisito Funcional

“A interface ao utilizador deve ter um aspeto amigavel, e coressobrias.”

Parte III

Recolha de Requisitos

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.

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?”

Processo

detalhe?”

Processo

detalhe?”

Processo

detalhe?”

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;

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;

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;

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;

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.

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)

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.

Parte IV

Especificacao de Requisitos

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.

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;

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;

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);

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);

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.

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.

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.

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.

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;

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.

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

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!

Cuidados!

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

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).

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.

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);. . .

Parte V

Diagramas de Caso de Uso

Diagramas de Caso de UsoAtores

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;

��

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;

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

��

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;

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;

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;

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;

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.

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.

��

� ��

��

� ��

��

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;

��

� ��

��

� ��

��

� ��

��

� ��

��

� ��

��

� ��

��

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!

��

� ��

��

� ��

��

� ��

��

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!��

��

� ��

��

� ��

��

� ��

��

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;

Na Generalizacao:

Aula 02 - Engenharia de Requisitos

Technology

Transcript of Aula 02 - Engenharia de Requisitos