Engenharia de Requisitos

Engenharia de Requisitos

Mestrado em Ciência da Computação

Disciplina: Engenharia de Software

Requisitos

Requisitos:

(IEEE)

1)Uma condição ou uma capacidade de que o usuário necessita, para solucionar um problema ou alcançar um objetivo.

2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente.

Engenharia de Requisitos

está relacionada com a identificação de metas a serem

atingidas pelo sistema a ser desenvolvido;

está relacionada com a operacionalização de tais metas em

serviços e restrições (princípios, técnicas, linguagens e

ferramentas) ;

está interessada com o relacionamento desses fatores para

fazer uma especificação do comportamento do software e

de sua evolução ao longo do tempo.

Níveis de Requisitos

Requisitos do usuário:

z Se destinam às pessoas envolvidas no uso e na

aquisição do sistema;

z Devem ser escritos usando linguagem natural, tabelas

e diagramas de modo que sejam compreensíveis.

z Exemplo:o software deve oferecer um meio de

Níveis de requisitos

Requisitos do sistema:

z

Se destinam a comunicar, de modo preciso as

funções que o sistema tem de fornecer

.

z

Podem ser escritos:

z em linguagem estruturada,

z formulário estruturado de linguagem natural,

z linguagem com base em alguma linguagem de

programação

z linguagem especial para especificação de

Níveis de requisitos

Exemplo: para o requisito do usuário definido no

item anterior, pode-se ter:

z 1.1. O usuário deve dispor de recursos para definir o

tipo dos arquivos externos;

z 1.2 Cada tipo de arquivo pode ter uma ferramenta

associada a ele;

z 1.3 Cada tipo de arquivo externo pode ser

Tipos de requisitos

Principais tipos:

z

Requisitos funcionais:

z dizem respeito à definição das funções que um sistema ou um componente de sistema deve fazer.

z descrevem as transformações a serem realizadas nas entradas de um sistema ou em um de seus

componentes, a fim de que se produzam saídas. z devem ser consistentes e completos

Tipos de requisitos

Requisitos não funcionais:

z dizem respeito às:

z restrições,

zaspectos de desempenho,

zinterfaces com o usuário,

zconfiabilidade,

zsegurança,

zmanutenibilidade,

zportabilidade,

zPadrões.

z são críticos: erros na elicitação destes se

Tipos de requisitos

Requisitos organizacionais:

z dizem respeito às metas da empresa, suas políticas

O processo de engenharia de

requisitos

propostas de modelos de processo:

Modelo de Processo de Engenharia de

Requisistos

2. Especificação aplicação de métodos de especificação

Modelo de Processo de Engenharia de

Requisistos

2) Proposta por Castro:

z elicitação de requisitos

z busca capturar os requisitos e obter conhecimento domínio do problema

z usa entrevista, descreve sistemas similares, se envolve no trabalho do usuário, observa, aprende e questiona, onsulta material existente

z só a entrevista não é suficiente.

z modelagem de requisitos,

z análise de requisitos obter uma especificação consistente e

completa

.

Modelo de Processo de Engenharia de

Requisistos

z

elicitação + validação de requisitos = fase de

aquisição de requsitos,

z

modelagem + análise de requistos = fase de

Modelo de Processo de Engenharia de

Requisistos

Segundo Castro, a elicitação de requisitos é uma

atividade de aprendizagem:

z a) do comportamento de sistemas existentes (

incluindo: procedimentos manuais, engenharia reversa de software existente e interfaces)

z b) do comportamento do domínio do problema que

está relacionado com o software a ser implementado,

z c) dos objetivos e restrições dos usuários (funcionais e

Modelo de Processo de Engenharia de

Requisistos

3) segundo Pressman:

as tarefas do engenheiro de requisitos :

reconhecimento do problema, avaliação e síntese,

modelagem, especificação e validação(revisão).

z reconhecimento do problema: entender os elementos

básicos de acordo com a percepção do cliente/usuário.

z avaliação e síntese de solução: são criados modelos

do sistema para melhor entender aspectos funcionais, de controle, de comportamento.

Modelo de Processo de Engenharia de

Requisistos

z especificação: prover uma representação do software

que possa ser revisada e aprovada pelo usuário.

z validação: descrição de critérios que demonstram que

ocorrerá uma implementação satisfatória e que

3) Atividades:

descoberta análise negociação especificação requisito requisitos requisitos requisitos

declaração necessidade documento especificação sistema existente requisitos sistema

padrões usuários

Modelo de Processo de Engenharia de

Requisistos

5) Modelo proposto por Kotonya e Sommerville

fases : Elicitação, Análise, Documentação e Validação de Requisitos.

modelo espiral: cada atividade do processo é repetida até que seja tomada a decisão de que o documento de requisitos pode ser aceito.

as mudanças de requisitos são parte da fase de Gerenciamento de Requisitos.

Elicitação

Elicitação:

z

objetivos:

z obter conhecimento relevante para o problema

-prover o mais correto entendimento de o que é esperado do software;

z descobrir os requisitos através de comunicação

com os usuários:

z dificuldades derivadas da capacidade humana:

• armazenar e organizar grande quantidade de informaçõies;

Elicitação

z investigar e coletar informações sobre o sistema e

a organização que o envolve;

z identificar as necessidades de diferentes classes

de usuários.

z

problemas:

z entender as reais necessidades do usuário: ponto de vista do usuário diferente do anlista --> formação distinta z usuários não têm uma idéia precisa e explícita do

sistema a ser desenvolvido

Elicitação

z

Como proceder:

z

iniciar com encontro preliminar seguida de

outra técnica de elicitação

z Pressman, no encontro preliminar:

• questões que enfatizam o cliente, os objetivos e os benefícios do sistema;

Elicitação

z

Técnicas para elicitação:

z cenários: representar tarefas que executam e as

que desejam executar

z Técnicas tradicionais: questionários, entrevistas,

análise de documentação existente

z técnicas de elicitação de grupo: técnicas de

dinâmica de grupo: brainstorming

z prototipação: quando existe alto grau de incerteza e

Elicitação

z

técnicas cognitivas: aquisição de conhecimento

para sistemas baseados em conhecimento

z

técncias contextuais: técnicas de etnografia e

Técnicas tradicionais para elicitação

entrevistas:

z fonte produtiva de apuração de fatos

z podem ser usadas em uma ampla variedade de

domínios, sendo a mais utilizada

z vantagem: volume de informações que podem ser

elicitadas e

Técnicas tradicionais

análise das características do sistema objeto

:

z

produz bons resultados e provê uma estrutura

para a definição do problema.

z

pode-se:

z obter informações dos problemas e fatores chaves

do sucesso,

z definir os fatores que são críticos para o sucesso

Técnicas tradicionais

z

métodos existentes nesta técnica:

z

BSP (Business System Planning) - está baseada nos

Técnicas tradicionais

z

CSF (Critical Sucess Factor) - as informações

relevantes são derivadas dos fatores críticos para a

operação e gerenciamento da organização (sucesso

na execução de suas tarefas ou tomadas de decisões)

z E/M (End Means Analysis) - propõe a separação entre

Técnicas tradicionais

Outras Técnicas

:

z FAST (facilited application specification technique)

combina: identificação do problema, negociação e

especificação de um conjunto preliminar de requisitos.

z Diretrizes básicas:

z encontro de clientes e desenvolvedores em local

neutro

z estabelecer regras para preparação e participação; z é sugerida uma agenda cobrindo todos os pontos

importantes e que encoraja o livre fluxo de idéias;

Técnicas tradicionais

Estratégia de Loh

z combina entrevista e questionário, tendo como base um

conjunto de perguntas que se relacionam entre si e são divididas em três níveis de detalhe:

z perguntas genéricas: tratam de aspectos gerais da

organização (objetivos, divisões, clientes e fornecedores da organização);

z perguntas específicas: coletam informações mais detalhadas sobre aspectos da organização;

Técnicas tradicionais

Estratégia de Gilvaz:

aquisição de informações

independente de domínio; está baseada nas técnicas

de entrevista e análise do sistema objeto

z

Objetivo: preenchimento de um modelo

conceitual, representando aspectos do sistema

objeto baseado nos três métodos : BSP (Business

System Planning), CSF (Critical Sucess Factor) e

E/M (End Means Analysis)

z

Tipos de perguntas : de instanciação, de relação,

Técnicas tradicionais

z

Perguntas de instanciação:

z

Qual a área funcional? seus objetivos? suas

atividades? seus problemas?

z

Quais são as decisões associadas à atividade?

De onde provem a informação?

z

Quais são os fatores críticos de sucesso em

torno da atividade? problemas que impedem o

fator crítico de sucesso? informações que

garantem/apoiam o fator crítico de sucesso?

Técnicas tradicionais

z

Quais as características do elemento ?

descriçao do elemento? serviços que

operam o elemento? usuários do serviço?

z Quais são as informações utilizadas pelo

serviço?

z Quais são as etapas envolvidas na execução

do serviço? restrições que limitam o serviço?

z

Perguntas de relação procuram estabelecer

novas relações:

Técnicas tradicionais

z

Perguntas de investigação: questionam a

existência de informações não mencionadas

.

z

<fator crítico> é válido?

z

Existe mais algum objetivo além da <lista de

objetivos>?

z

Existe mais algum fator crítico além de <lista

de fatores críticos>?

z

Existe mais alguma informação que apóia

<fator critico> além da <lista de informações>?

z

Existe mais alguma característica do

Técnicas tradicionais

z

Perguntas de inconsistência: alertar inconsistências

ocorridas a respeito de uma resposta:

z

A <informação> foi respondida anteriormente como

sendo fornecida por <origem>! Confirma?

z

A <descrição> foi estabelecida anteriormente como

<descrição do elemento>! Confirma?

Elicitação

Resultado da elicitação de requisitos: “descrição dos

requisitos” que estabelece o que o sistema deverá

fazer, auxilia na atividade de especificação de

Análise e Negociação dos Requisitos

análise:

z

objetivo:

z detectar incompletudes, omissões e redundâncias

-z descobrir os requisitos necessários e desejados

Análise e Negociação dos Requisitos

negociação:

z

objetivos:

z resolver conflitos entre usuários sem comprometer

a satisfação de cada um;

z atribuir prioridades aos requisitos ----> de acordo

com as necessidades dos usuários;

Documentação

Documentação:

z

objetivo:

z documentar os requisitos

z

deve ser possível de entender por todos ---->

contrato entre usuários e desenvolvedores;

z

deve ser rastreável e gerenciável ao longo da

evolução do sistema;

z

descrever restrições, interfaces com outros

Validação de Requisitos

validação de requisitos:

z

objetivos:

z certificar que o documento de requisitos é consistente

com as necessiddes dos usuários,

z verificar a validade,

z a consistência, a completeza,

z o realismo;

z a facilidde de verificação.

z

dificuldades:

z obter consenso entre usuários com objetivos conflitantes

Validação de Requisitos

z

dificuldades:

z obter consenso entre usuários com objetivos

conflitantes

z demonstrar a corretude

z

técnicas usadas:

z revisão de requisitos

Gerenciamento de requisitos

gerenciamento de requisitos

z

objetivos

:

z gerenciar e controlar as mudanças nos requisitos

z gerenciar o relacionamento entre os requisitos

z

os requisitos devem ser identificados unicamente

Mais técnicas para elicitação e

validação

1) Cenários:

z

o que são:

z descrições em linguagem natural ou modelos mais

complexos contendo informação comportamental (ações, eventos e atividades) e objetos (entidade, atributos)

z

objetivos:

z descrever as ações em um ambiente relacionadas

Mais técnicas para elicitação e validação

o cenário pode incluir:

z descrição do estado do sistema no início do cenário;

z descrição do fluxo normal de eventos no cenário;

z descrição do que pode sair errado e de como lidar com isso;

z informações sobre outras atividades que possam estar em

andamento ao mesmo tempo;

z uma descrição do estado do sistema no final do cenário

exemplo: ( cenário do evento) iniciar transação:

exemplo..

o cliente insere o cartão e digita a senha. Se o

cartão for válido, o controle poderá passar para o

próximo estágio. Existem 3 possíveis exceções (

para cada um posso ter uma descrição detalhada e o

cenário correspondente):

z tempo esgotado: não forneceu a senha dentro do

tempo permitido

z cartão inválido: não é reconhecido e é devolvido

z cartão roubado: cartão é reconhecido como cartão

Mais técnicas para elicitação e

validação

principais técnicas utilizando cenários:

1) métodos para a análise de requisitos baseda em

cenários:

z

Hipótese: a integração de técnicas fornece o

melhor caminho para a engenharia de requisitos

z

técnicas utilizadas:

z entrevistas e técncias para descobrimento de

Mais técnicas para elicitação e

validação

z construção de protótipo: pode usar qualquer

ferramenta

z validação com clientes: utilizar protótipos para

validar os requisitos

z análise: efetuar a análise dos requisitos

alguns pontos:

z combinação de técnicas é útil na captura de requisitos;

z a utilização de cenários na descrição de situações

auxilia a manter a atenção dos clientes;

Mais técnicas para elicitação e

validação

2) Use case:

requisitos

3) Etnografia:

z técncia de observação que podeser utilizada na

compreensão dos requisitos sociais e organizacionais.

z o analista observa o trabalho diário in loco.

z ajuda a descobrir requisitos implícitos, que refletem

Mais técnicas para elicitação e

validação

4) orientado a pontos de vista:

z sistemas de médio ou grande porte--> diferentes tipos

de usuários --> diferentes interesses nos requisitos --->diferentes pontos de vista

z os diferents pontos de vista são utilizados para

Mais Técnicas para Elicitação e

validação

Vantagens:

z a utilização do sistema é heterogênea: diferentes

usuários

z pode ser usada para coletar e classificar informações

de diferentes tipos de domínio de aplicação,

z pode ser usado como um meio para estruturar o

processo de elicitação de requisitos

z pode ser usado para encapsular diferentes modelos

de sistema

z pode ser usado para estruturar descrição de

Princípios de Especificação de

Requisitos

Os usuários e os interesses

:

z

clientes

:

validação dos requisitos

.

z

analistas

:

z

consistencia, completude e corretude (na

especificação).

z

garantir a integridade do sistema (no projeto).

z

os projetistas e engenheiros:

nos requisitos (é

a base para a construção do sistema)

z

o gerente de projeto:

administrativas contidas

Princípios de Especificação de Requisitos

Conteúdo de uma Especificação de Requsitos:

1) Funcionalidade

:

fornecidos para o cliente/usuário

:

z procedimentos para inicializar , finalizar, testar o sistema;

z operações sobre condições normais /anormais;

z procedimentos para controlar os modos de operação /recuperação do sistema

2) Descrição do Ambiente e Objetivos do Sistema:

Princípios de Especificação de Requisitos

z

descrição do ambiente no qual o sistema irá

operar e o domínio da aplicação.

z

Contém, informações tais como:

z atributos físicos do ambiente (tamanho,

localização);

z atributos organizacionais (aplicação comercial,

aplicação militar);

z tipos de usuários em potencial;

z aspectos de segurança;

z mudanças no ambiente que irão perturbar a

Princípios de Especificação de Requisitos

3) Gerenciamento de Projeto:

garantir que a

construção do sistema será realizada de uma

maneira cuidadosa e controlada. Tratam:

a) do ciclo de vida do desenvolvimento: como

ocorrerá a construção do sistema e contém:

z padrões de documentação;

z procedimentos para teste e integração dos

módulos;

z procedimentos para o controle das mudanças e

z mudanças conjecturadas/esperadas.

b) da entrega e instalação do sistema,

Princípios de Especificação de Requisitos

prazos de entrega;

critério de aceitação;

treinamento;

manuais;

suporte e manutenção

.

4)

Restrições Funcionais

:

descrevem

as

propriedades necessárias ao comportamento do

sistema e incluem:

z

performance;

eficiencia;

z

segurança;

Princípios de Especificação de Requisitos

5) Restrições de Projeto:

são algumas condições,

além da funcionalidade, que influenciariam o projeto e

a construção do sistema

:

z

padrões de hardware e software;

uso de bibliotecas específicas;

z

uso de um sistema operacional específico

questões de compatibilidade

.

6) Protocolos de Dados e Comunicação:

Princípios de Especificação de Requisitos

Características Desejáveis em uma

Especificação de Requisitos:

z

Não ambiguidade

:

ter interpretação única

z

Completude

:

z descrever cada apecto significativo e relevante do

sistema e

z incluir detalhes a respeito de todas as informações.

z melhor juiz = usuário, mas este nem sempre sabe

muito além das funcionalidades e objetivos.

z natureza subjetiva da definição de completude

Princípios de Especificação de Requisitos

Consistência

:

não deve existir requisitos

contraditórios na especificação

;

Verificabilidade

:

deve ser possível verificar o que

projeto e implementação satisfazem os requisitos

originais;

Validação

:

possibilitar ao usuário de ler e entender

a especificação de requisitos, e indicar se os

requiatos refletem as suas idéias;

Princípios de Especificação de Requisitos

Compreensível:

todos os usuários devem ser

capazes de entender os requisitos

;

Teste

:

possibilitar quye sejam realizados testes;

Formato do documento de especificação de requisitos

sugerido pela IEEE/ANSI 830-1993

1.Introdução

1.1 propósito do documento de requisitos 1.2 escopo do produto

1.3 definições, acrônimos e abrviações 1.4 referências

Formato do documento de especificação de requisitos

sugerido pela IEEE/ANSI 830-1993

3. Requisitos Específicos

os requisitos podem documentar interfaces externas,

descrever funcionalidade e desempenho do sistema,

especificar requisitos lógicos de banco de

dados,restrições de projeto, caracterísitcs de

qualidade.

Formato do documento de especificação de requisitos

sugerido pela IEEE/ANSI 830-1993

Este padrão é bastante amplo

As informações incluídas em um documento de

Formato de documento de requisitos sugerido em

[Sommervile 2002]

1.

Prefácio: define o público a que se destina

o docuemtno, descreve seu histórico de

versão, l´gica para criação da versão e um

sumário das mudanças feitas

2.

Introdução: descreve brevemente cada

função e explica como deverá operar com

outros sistemas. Descreve como o sistema

se ajusta aos negócios em geral e aos

Formato de documento de requisitos sugerido em

[Sommmervile, 2002]

Glossário: definir os termos técnicos utilizados no

documento

Definição de requisitos do usuário: os serviços

fornecidos para o usuário e os requisitos não

funcionais. A descrição pode ser em linguagem

natural, diagramas ou outras notações. Padrões de

produtos e processo a serem seguidos devem ser

especificados.

Formato de documento de requisitos sugerido em

[Sommervile 2002]

5. Arquitetura de Sistemas: apresenta visão geral da

arquitetura com possíveis módulos. Os componentes

reutilizados, se houverem, devem ser indicados

6. Especificação de requisitos do sistema: descrever

Formato de documento de requisitos sugerido em

[Sommervile 2002

7. Modelos do sistemas: elaborar um ou mais

8. Evolução do sistema: descrever mudanças previstas

devida à evolução de hardware, mudnças ns

necessidades do usuário

9. Apêndices: podem incluir descrições de configurações

de hardware; requisitos de BD

Comentários Adicionais

O Contexto da Definição de Requisitos:

1) Elementos Fundamentais:

z

Ambiente ou domínio da aplicação:

z

O que é:

z é onde ocorrem os fenômenos que caracteerizam os

problemas referentes aos requisitos do cliente.

z É o primeiro elemento a ser conhecido e

representado pelo engenheiro de requisitos.

z Incluem aspectos sociais, economicos e políticos em

Comentários Adicionais

z

Características:

z Cultura organizacional: regras, comportamento,

hábitos e costumes

z Mudanças: dinâmica social e organizacional do

elemnto humano como agente de mudança do ambiente;

z Tecnologias: avanços tecnológicos e o impacto que

Comentários Adicionais

z

Problemas:

z

O que são:

z diferença : algo como desejado x como percebido

z

Características:

z

Fato: verdade

z

Fenomeno:como se vê

z

Fato + fenomeno + quem relata : possibilita

Comentários Adicionais

z

Requsitos:

z

O que são:

z declaração descritiva de exigências do ponto de

vista de alguém sobre o qual será provida tecnologia de informação para a solução do problema

z

Características:

z Funções z Atributos

z Restriçoes (critéios para aprovação ou recusa para

Comentários Adicionais

z

Stkeholder:

z

Quem são:

z pessoas que direta/indiretamente são afetadas pelo

sistema a ser construído para a solução de problemas

z

Características:

Comentários Adicionais

Processo de Engenharia de Requisitos

z

Envolve: a aplicção de técnicas; métodos,

normas e padrões e métricas e planejamento

Produto: documento de requisitos

z

Incluem: contexto organixacional, requisitos,