objectivos definição de requisito - fenix.tecnico.ulisboa.pt · antónio rito silva...

Engenharia de Software

Engenharia de Requisitos

António Rito [email protected]

Engenharia de Requisitos 2

SumárioCaracterização

ObjectivosProblemasQualidades

Factores Não-TécnicosTécnicasAvaliação e ValidaçãoCasos NotáveisExemploConclusões


ObjectivosIdentificação de quais são as características do sistema a desenvolverAssegurar que essas características correspondem aos objectivos do negócioVerificar se o sistema desenvolvido satisfaz ou não as características identificadas


Definição de RequisitoUm requisito é uma característica do sistema, ou a descrição de algo que o sistema é capaz de fazer para satisfazer os seus objectivosEm princípio os requisitos devem versar sobre o espaço do problema, o quê, e não sobre o espaço da solução, o como, contudo pode acontecer que os requisitos coloquem restrições ao espaço da solução


Tipos de RequisitosOs requisitos funcionais descrevem uma interacção entre o sistema e o seu ambienteOs requisitos não-funcionais descrevem restrições ao sistema que limitam as possibilidades de implementação. Têm impacto no desenhoOs requisitos do desenvolvimentodescrevem restrições ao processo de desenvolvimento do sistema e não são perceptíveis pelos utilizadores


Requisitos FuncionaisContexto do sistemaReacção a estímulos externosEstados do sistemaInformação manipulada pelo sistema...


Requisitos Não-FuncionaisUsabilidadeDesempenhoSegurançaRobustezFiabilidadeDisponibilidadePortabilidadeTecnologia de implementaçãoAmbiente físico da instalação...


Requisitos de DesenvolvimentoManutençãoEvoluçãoDocumentaçãoProcessoOrçamentoRecursos humanosRecursos computacionais...


Actividades1. Estudo de viabilidade – o sistema faz

sentido do ponto de vista do negócio e é realizável com o orçamento disponível

2. Análise de requisitos – entender como vai ser o sistema analisando diversas fontes

3. Definição de requisitos – descrever os requisitos de modo a serem entendido pelos utilizadores e clientes

4. Especificação de requisitos – descrever detalhadamente os requisitos de modo a permitir fazer a ponte com a solução


Análise de RequisitosFontes dos Requisitos

Clientes e utilizadoresOrganização e outros sistemas existentesDocumentação existenteMatriz de tipos de requisitosReutilização de requisitosModelos do domínioModelo do sistema actual


Análise de RequisitosIdentificar as pessoas, os processos e os recursos envolvidos no problema e documentar as suas relaçõesIdentificar a fronteira do sistemaSeparar os requisitos em três categorias:

Têm que ser satisfeitosÉ desejável que sejam satisfeitosPodem ser satisfeitos mas é possível eliminar


Documentos de RequisitosDefinição de Requisitos contém uma lista de tudo o que o cliente espera que o sistema faça. Define um entendimento entre o cliente e a equipa de desenvolvimento sobre o que é que o sistema deve fazer. É escrito pelos clientes e os analistas de requisitos.Especificação de Requisitos rescreve o documento de definição de requisitos em termos técnicos mais apropriados à equipa de desenvolvimento e às actividades de desenho. É escrito pelos analistas de requisitos.


Problemas dos RequisitosLinguagem natural é inevitável no levantamento de requisitos

Dificuldades comunicação entre os utilizadores e a equipa de desenvolvimentoOs utilizadores não concordam sobre os requisitos

Por vezes não é possível definir completamente o problemaOs requisitos evoluem durante o processo desenvolvimentoO levantamento de requisitos origina problemas de equilíbrio de poderA descrição do problema é influenciada pela solução


Qualidades dos RequisitosCoerência – não devem ser ambíguos ou incoerentesCompletude – todos os estados possíveis, alterações de estados, entradas, etc, devem ser descritos

Externamente Completos – todas as ligações com o ambiente desejadas pelo cliente estão descritasInternamente Completos – não existem referências indefinidas entre requisitos

Realismo – o que é pedido pelo cliente deve ser realizável


Qualidades dos RequisitosClareza – a descrição dos requisitos deve ser simples e clara para os utilizadoresValidade – o requisito deve descrever algo que é de facto relativo ao problemaCertificação – deve ser possível escrever testes que demonstram que o requisito foi satisfeitoRastreabilidade – deve ser possível relacionar o requisito com a solução e também saber qual é a origem do requisito


Certificação de RequisitosOs requisitos devem ser escritos de uma forma que permita a sua verificação objectiva. Para isso devem seguir-se as seguintes regras:

Escrever uma quantidade para cada advérbio e adjectivo de modo a que o significado dos qualificadores seja claro e não ambíguoSubstituir pronomes por nomes de entidadesAssegurar que cada substantivo é definido exactamente uma única vez nos documentos de requisitos


Factores Sociais e OrganizacionaisO sistema vai levar à redução de gestores intermédios

Contudo, os gestores intermédios são uma importante fonte de informação sobre os requisitos do sistema

Os utilizadores e a equipa de desenvolvimento não constituem um todo partilhando os mesmos objectivos pelo que vão surgir preconceitos entre os intervenientes


IntervenientesExistem diferentes intervenientes:

Gestores de Processo, definem a calendarizaçãoClientes e Utilizadores, entendem os requisitosGestores do Negócio, entendem o impacto do sistema no negócioArquitectos do Sistema, usam os requisitos para a definição da arquitecturaAvaliadores do Sistema, recolhem dados para os testes e desenvolvem grupos de testes

Os diferentes intervenientes podem ter visões conflituosas sobre os requisitos, e.g., entre o cliente e o utilizador


Equipa -> UtilizadoresNão sabem o que queremNão são capazes de exprimir o que queremAs suas necessidades são políticasQuerem as coisas jáNão conseguem atribuir prioridades às necessidadesNão assumem responsabilidadesNão aceitam compromissos...


Utilizadores -> EquipaNão entendem as necessidades operacionaisDão demasiada importância aos aspectos técnicosTentam dizer-nos qual deve ser o nosso trabalhoNão conseguem implementar requisitos muito clarosEstão sempre fora do orçamentoEstão sempre atrasadosPedem tarefas aos utilizadores que os desviam da sua tarefa principal...


TécnicasRepresentação de RequisitosPrototipagemMatriz VolereCasos de UsoFiguras Densas (Rich Pictures)


Representação de RequisitosO objectivo das representações de requisitos é:

Reduzir a imprecisão associada à linguagem naturalSeparar a descrição do problema da construção da solução


RepresentaçõesAxiomáticaLinguagemDados AbstractosDiagramas de Fluxo de DadosTabelas de DecisãoDiagramas de TransiçãoBaseado em Objectos


AxiomáticaEspecifica as propriedades básicas do sistema, como axiomas, e como o comportamento gera novas propriedades, os teoremasExige que o conjunto de axiomas seja completo e coerenteParticularmente útil para sistemas peritos


LinguagemDescreve requisitos como cadeias de caracteres de uma linguagemPermite automatizar a verificação da completude e da coerência dos requisitosParticularmente útil no desenvolvimento de compiladores


Dados AbstractosDescreve o sistema baseado nos dadosPermite ignorar como os dados estão implementados e são manipuladosParticularmente útil quando o problema não está baseado em funções


Diagramas de Fluxo de DadosRepresenta

Processamento de dadosRelações de produção e consumo de dadosRepositórios de dados

Permite ignorar o fluxo de execução


Tabelas de DecisãoRepresentam regras estímulo/resposta quando um conjunto de condições se verifica


Diagramas de TransiçãoRepresentam o sistema em termos da sua reacção a eventos internos e externosPermite ignorar a sequência total de execução associada a cada interacção e, desta forma, o comportamento global do sistema


Diagramas de Transição


Baseado em ObjectosEstende a abordagem estática dos dados abstractos com os conceitos de:

EncapsulaçãoHierarquia de classesHerança Polimorfismo

Facilita a classificação de entidades


Baseado em Objectos

1Unidade

Pessoa

Orgão

Discente Funcionario

Cargo

Vínculo

Docente

1 *

*

*

1 *

1

*Função

FunçãoPrimaria FunçãoInerente

*

1 *


Escolher uma RepresentaçãoÉ necessário analisar as diferentes técnicas de representação de acordo com os seguintes itens:

Implementação: Ajuda na implementação?Testes: Ajuda nos testes?Legibilidade: A especificação é legível para os peritos do domínio?Manutenção: A especificação pode ser útil durante a manutenção?Modularidade: Permite decomposição?Expressividade: Com que facilidade representa as abstracções do problema?


Escolher uma RepresentaçãoCorrecção: Permite a detecção de incorrecções ou incoerências?Verificação: A especificação é verificável formalmente?Geração: Se possui geração de código este é eficiente?Suporte Computacional: Possui suporte computacional?Incompleta: Suporta informação incompleta?Aprendizagem: Qual é a curva de aprendizagem?Disciplina: Conduz a uma disciplina de escrita de requisitos?


Protótipos para RequisitosOs protótipos permitem detalhar e completar a lista de requisitos A prototipagem pode ser aplicada a:

InterfacesValidar requisitos funcionaisValidar requisitos não funcionais como o desempenhoMostrar, à gestão, da viabilidade da aplicaçãoDesenho...


Tipos de ProtótiposConsideram-se dois tipos de protótipos:

Protótipo descartável – o principal objectivo é validar ou clarificar os requisitosProtótipo evolutivo – adicionalmente ao protótipo descartável também tem como objectivo o desenvolvimento incremental do sistema final


Técnicas para PrototipagemLinguagens de especificação executáveis – linguagens formais, e.g. ZLinguagens de alto nível – linguagens dinâmicas, e.g. SmalltalkGeradores de aplicações – geração de código, e.g. SQLComposição de componentes reutilizáveis – composição de componentes independentes, e.g. UNIX Shells


Matriz VolereEstrutura a linguagem naturalEnumera requisitos não funcionais tipo

Look and feelUsabilidadeDesempenhoOperacionaisManutenção e portabilidadeSegurançaCulturais e políticosLegais


Matriz Volere


Matriz VolereExemplos de medidas para verificação da conformância de requisitos

Requisito funcional – o resultado de um cálculo é o esperadoDesempenho – 98% das transacções têm um tempo de resposta inferior a 1,5 segundosOperacionais – 90% de um painel de trabalhadores conseguem utilizar o produto numa simulação das condições operacionais


Matriz VolereManutenção – cada 10 alterações ao código devem estar operacionais em 3 semanasSegurança – o produto deve estar conforme uma determinada norma Legal – o departamento jurídico deve certificar que o produto está de acordo com a legislaçãoLook and feel – está de acordo com uma norma


Casos de UsoOs casos de uso descrevem o sistema do ponto de vista do utilizador. As vantagens são:

Delimitam o sistemaCada caso de uso pode ser isolado dos restantes pelo que facilita a decomposição do espaço do problemaPodem ser usados para estimar o tempo e o esforço necessário ao desenho e codificação do sistemaO desenvolvimento do sistema pode ser seguido em termos dos seus casos de uso


CenáriosUma sequência de passos que descreve uma interacção entre um utilizador e um sistema

O utilizador acede a “Agrupamento”, onde Agrupamento é o nome do agrupamento. O sistema mostra no ecrã os turnos do agrupamento seleccionado. Para cada turno, são visualizados:

O nome do turno;As aulas a ele associadas (dia da semana, hora de início e de fim e sala);O número dos grupos inscritos no turno (quando não tem grupos aparece a mensagem “Sem Grupos”).


Caso de UsoÉ um conjunto de cenários agrupados de acordo com um objectivo do utilizador

Caso de Uso: Visualizar Turnos do AgrupamentoObjectivo: Esta funcionalidade permite ao utilizador visualizar, caso existam, os turnos associados ao agrupamento seleccionado e para cada turno o número dos grupos nele inscritos.Cenário 1: Existem turnosCenário 2: Não existem turnos


ActoresUm actor é um papel que um utilizador toma em relação com um sistema

HumanosOutros sistemas

Um utilizador pode ter vários papéisOs actores levam a cabo casos de usoOs actores podem ser facilmente identificados antes da identificação dos casos de usoOs eventos externos facilitam a identificação dos actores


Formato Caso de UsoO formato deve ser ajustado às necessidades.Um exemplo de formato:

NomeObjectivoActoresPré-condiçõesCenário PrincipalCenários AlternativosPós-condições


Visualizar Turnos do AgrupamentoObjectivo:

Esta funcionalidade permite ao utilizador visualizar, caso existam, os turnos associados ao agrupamento seleccionado e para cada turno o número dos grupos nele inscritos.

Actores: Qualquer utilizador do sistema Fénix

Pré-Condições: A disciplina seleccionada tem que ter pelo menos um agrupamento.


Visualizar Turnos do AgrupamentoCenário Principal:

1. O utilizador acede a “Agrupamento”, onde Agrupamento é o nome do agrupamento.

2. O sistema mostra no ecrã os turnos do agrupamento seleccionado.

3. Para cada turno, são visualizados:1. O nome do turno;2. As aulas a ele associadas (dia da semana,

hora de início e de fim e sala);3. O número dos grupos inscritos no turno

(quando não tem grupos aparece a mensagem “Sem Grupos”).


Visualizar Turnos do AgrupamentoCenário Alternativo: 1. Passo 1 do Cenário Principal.2. Como não existem turnos do agrupamento

seleccionado, o sistema mostra no ecrã a mensagem “Não existem turnos”.

Pós-Condições:O estado do sistema permanece inalterado


Diagramas de Casos de Uso

Diagrama Casos de Uso - Estudante

Estudante

Visualizar Agrupamentos da Disciplina

Visualizar Turnos do Agrupamento

Visualizar Grupo do Turno

Criar Grupo

Inscrever em Grupo

Alterar Turno

Remover Inscrição

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>


Relações entre Casos de UsoInclusão – quando nos estamos a repetir em dois os mais casos de usoGeneralização – uma variação (alternativa) de um comportamento que se pretende representar fora do caso de usoExtensão - uma variação de um comportamento que se pretende representar fora do caso de uso de forma controlada, indicando os pontos de extensão


Casos de Uso RevisitadosOs casos de uso descrevem o sistema do ponto de vista do utilizador. As vantagens são:

Delimitam o sistemaCada caso de uso pode ser isolado dos restantes pelo que facilita a decomposição do espaço do problemaPodem ser usados para estimar o tempo e o esforço necessário ao desenho e codificação do sistemaO desenvolvimento do sistema pode ser seguido em termos dos seus casos de uso


Figuras DensasPermitem fazer uma análise do negócio ao nível de abstracção dos clientes e utilizadores

Registar e raciocinar sobre o contexto do trabalho e a forma como este influência o desenho

Início da ponte entre o negócio e os requisitosTécnica que facilita a interacção e a comunicação entre os clientes e a equipa


Figuras DensasConsideram os seguintes elementos

Estrutura – refere os aspectos do contexto do trabalho que vão ser alteradosProcesso – refere as transformações que ocorrem no processo de trabalhoObjectivos – refere as motivações de cada um dos intervenientes

Devem-se captar as tensões entre os intervenientes


Figuras Densas


Validação de RequisitosA validação de requisitos é o processo que determina se a especificação de requisitos é coerente com a definição de requisitos, ou seja, se os requisitos satisfazem as necessidades dos clientes:

Cada especificação está relacionada com um requisito no documento de definição de requisitosCada requisito está tratado no documento de especificação de requisitos


Técnicas de ValidaçãoTécnicas manuais

LeituraCruzamento de informaçãoEntrevistasRevisõesListas de verificaçãoCenáriosModelos pré-definidosDemonstração matemática


Técnicas de ValidaçãoTécnicas automáticas são possíveis se os requisitos estiverem representados de modo a poderem ser tratados computacionalmente – bases de dados, linguagens formais, protótipos

Cruzamento de informaçãoModelos pré-definidosPrototipagemSimulaçãoDemonstração matemática


Revisão de RequisitosJuntar representantes da equipa de desenvolvimento, do cliente e dos utilizadores para:

Rever objectivos do sistemaComparar os requisitos com os objectivos para confirmar se são todos necessáriosVerificar a completude e correcção dos requisitosSe foram identificados riscos avaliar com o cliente se a abordagem de solução proposta é a melhorDefinir como é que a satisfação de requisitos vai ser verificada durante o desenvolvimento


Métricas para RequisitosDesempenho – transacções processadas por segundo, tempo de resposta a um pedido do utilizador, tempo de refrescar o ecrãUsabilidade – tempo de treino, número de menus de ajudaRobustez – tempo de recomeçar após faltasPortabilidade – número de sistemas alvo, número de comandos dependentes do alvoTempo de desenvolvimento – uma função do número de requisitos dá uma estimativa do esforço de desenvolvimento, e.g., COCOMO


Métricas para RequisitosImpacto – qual o impacto que a alteração de um particular tipo de requisitos tem no sistemaComplexidade – qual a complexidade associada à implementação dos requisitos. Para isso pode-se perguntar aos arquitectos e avaliadores sobre cada requisito:

ConhecidoNovo mas parecidoNovo mas será possível encontrar uma soluçãoNão se entende e não se sabe se será possível encontrar uma soluçãoNão se entende e não é possível encontrar uma solução

objectivos definição de requisito - fenix.tecnico.ulisboa.pt · antónio rito silva...

Documents