Requisito de sistemas

Prévia do material em texto

eng-requisitos-2003 Elisa Huzita
Engenharia de Requisitos
Mestrado em Ciência da Computação
Disciplina: Engenharia de Software
Profa. Dra. Elisa H. M. Huzita
eng-requisitos-2003 Elisa Huzita
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.
3) Uma representação documentada de uma condição 
ou capacidade, conforme os itens (1) e (2).
eng-requisitos-2003 Elisa Huzita
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. 
é uma área ampla e multidisciplinar: aspectos sociais e 
humanos são importantes
eng-requisitos-2003 Elisa Huzita
eng-requisitos-2003 Elisa Huzita
Níveis de Requisitos
Requisitos do usuário:
? Se destinam às pessoas envolvidas no uso e na 
aquisição do sistema;
? Devem ser escritos usando linguagem natural, tabelas 
e diagramas de modo que sejam compreensíveis.
? Exemplo:o software deve oferecer um meio de 
representar e acessar arquivos externos criados por 
outras ferramentas
eng-requisitos-2003 Elisa Huzita
Níveis de requisitos
Requisitos do sistema:
? Se destinam a comunicar, de modo preciso as 
funções que o sistema tem de fornecer.
? Podem ser escritos:
? em linguagem estruturada, 
? formulário estruturado de linguagem natural,
? linguagem com base em alguma linguagem de 
programação 
? linguagem especial para especificação de 
requisitos
eng-requisitos-2003 Elisa Huzita
Níveis de requisitos
Exemplo: para o requisito do usuário definido no 
item anterior, pode-se ter:
? 1.1. O usuário deve dispor de recursos para definir o 
tipo dos arquivos externos;
? 1.2 Cada tipo de arquivo pode ter uma ferramenta 
associada a ele;
? 1.3 Cada tipo de arquivo externo pode ser 
representado como um ícone específico na tela
eng-requisitos-2003 Elisa Huzita
Tipos de requisitos
Principais tipos:
? Requisitos funcionais:
? dizem respeito à definição das funções que um sistema 
ou um componente de sistema deve fazer. 
? 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.
? devem ser consistentes e completos
? Exemplo: o sistema fornecerá telas apropriadas para o 
usuário ler documentos no repositório de documentos. 
eng-requisitos-2003 Elisa Huzita
Tipos de requisitos
? Requisitos não funcionais:
? dizem respeito às:
? restrições, 
?aspectos de desempenho, 
? interfaces com o usuário, 
? confiabilidade, 
? segurança, 
?manutenibilidade, 
?portabilidade, 
?Padrões.
? são críticos: erros na elicitação destes se 
constituemn os mais caros e difíceis de corrigir, 
uma vez que um sistema tenha sido implementado
eng-requisitos-2003 Elisa Huzita
Tipos de requisitos
Requisitos organizacionais:
? dizem respeito às metas da empresa, suas políticas 
estratégicas adotadas, os relacionamentos entre os 
seus atores junto com seus respectivos objetivos
eng-requisitos-2003 Elisa Huzita
O processo de engenharia de 
requisitos
Processo de engenharia de requisitos = {estruturado 
de atividades que são seguidas com o objetivo de 
derivar, validar e manter um documento de requisito}
eng-requisitos-2003 Elisa Huzita
propostas de modelos de processo:
1) elicitação, especificação e revisão
eng-requisitos-2003 Elisa Huzita
Modelo de Processo de Engenharia de 
Requisistos
Problema
Usuário Engenheira de 
Requisitos
1. Elicitação
comunicação
'Enunciado do Problema'
2. Especificação aplicação de métodos de especificação
3. Revisão
modificações
Usuário Engenheira de 
Requisitos
comunicação
desafios
Projeto
'Especificação de Requisitos'
aprovação do documento
aplicação de 
métodos de 
aquisição de 
informação
aplicação de
métodos de
revisão e
animação
eng-requisitos-2003 Elisa Huzita
Modelo de Processo de Engenharia de
Requisistos
2) Proposta por Castro:
? elicitação de requisitos
? busca capturar os requisitos e obter conhecimento 
domínio do problema
? usa entrevista, descreve sistemas similares, se envolve
no trabalho do usuário, observa, aprende e questiona,
onsulta material existente 
? só a entrevista não é suficiente.
? modelagem de requisitos,
? análise de requisitos obter uma especificação consistente e
completa.
? validação de requisitos.
eng-requisitos-2003 Elisa Huzita
Modelo de Processo de Engenharia de
Requisistos
? elicitação + validação de requisitos = fase de
aquisição de requsitos,
? modelagem + análise de requistos = fase de
especificação de requistos.
eng-requisitos-2003 Elisa Huzita
Modelo de Processo de Engenharia de
Requisistos
Segundo Castro, a elicitação de requisitos é uma 
atividade de aprendizagem:
? a) do comportamento de sistemas existentes (
incluindo: procedimentos manuais, engenharia reversa
de software existente e interfaces) 
? b) do comportamento do domínio do problema que 
está relacionado com o software a ser implementado, 
? c) dos objetivos e restrições dos usuários (funcionais e
organizacionais).
eng-requisitos-2003 Elisa Huzita
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).
? reconhecimento do problema: entender os elementos 
básicos de acordo com a percepção do cliente/usuário.
? avaliação e síntese de solução: são criados modelos
do sistema para melhor entender aspectos funcionais, 
de controle, de comportamento.
? modelo: fundamentação para o projeto de software e 
base para a criação da especificação para o software.
eng-requisitos-2003 Elisa Huzita
Modelo de Processo de Engenharia de
Requisistos
? especificação: prover uma representação do software
que possa ser revisada e aprovada pelo usuário.
? validação: descrição de critérios que demonstram que 
ocorrerá uma implementação satisfatória e que 
servirão como base para o teste. Se não é possível um
protótipo, poderá ser produzido um Manual Preliminar
do Usuário.
eng-requisitos-2003 Elisa Huzita
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
experiência domínio
eng-requisitos-2003 Elisa Huzita
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. 
as atividades, consistem de processos iterativos e inter-
relacionados que podem cobrir todo o ciclo de vida do 
desenvolvimento de sistemas de software
eng-requisitos-2003 Elisa Huzita
eng-requisitos-2003 Elisa HuzitaElicitação
Elicitação:
? objetivos:
? obter conhecimento relevante para o problema -
prover o mais correto entendimento de o que é 
esperado do software;
? descobrir os requisitos através de comunicação
com os usuários:
? dificuldades derivadas da capacidade humana:
• armazenar e organizar grande quantidade de 
informaçõies;
• gerenciar conflitos.
eng-requisitos-2003 Elisa Huzita
Elicitação
? investigar e coletar informações sobre o sistema e 
a organização que o envolve;
? identificar as necessidades de diferentes classes 
de usuários.
? problemas:
? entender as reais necessidades do usuário: ponto de 
vista do usuário diferente do anlista --> formação distinta 
? usuários não têm uma idéia precisa e explícita do
sistema a ser desenvolvido
? dificuldade dos usuários em descrever o conhecimento 
que possui sobre o domínio do problema
eng-requisitos-2003 Elisa Huzita
Elicitação
? Como proceder:
? iniciar com encontro preliminar seguida de
outra técnica de elicitação
? Pressman, no encontro preliminar:
• questões que enfatizam o cliente, os 
objetivos e os benefícios do sistema; 
• questões que habilitam o analista a ganhar
um melhor entendimento do problema e o
cliente falar sobre a sua percepção
eng-requisitos-2003 Elisa Huzita
Elicitação
? Técnicas para elicitação:
? cenários: representar tarefas que executam e as
que desejam executar
? Técnicas tradicionais: questionários, entrevistas,
análise de documentação existente
? técnicas de elicitação de grupo: técnicas de
dinâmica de grupo: brainstorming
? prototipação: quando existe alto grau de incerteza e
necessita de um rápido feedback
eng-requisitos-2003 Elisa Huzita
Elicitação
? técnicas cognitivas: aquisição de conhecimento 
para sistemas baseados em conhecimento
? técncias contextuais: técnicas de etnografia e
análise social.
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais para elicitação
entrevistas:
? fonte produtiva de apuração de fatos 
? podem ser usadas em uma ampla variedade de
domínios, sendo a mais utilizada 
? vantagem: volume de informações que podem ser
elicitadas e
? desvantagem: tempo que elas consomem.
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
análise das características do sistema objeto:
? produz bons resultados e provê uma estrutura 
para a definição do problema.
? pode-se:
? obter informações dos problemas e fatores chaves
do sucesso, 
? definir os fatores que são críticos para o sucesso 
na execução de suas tarefas ou tomada de
decisão.
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
? métodos existentes nesta técnica: 
? BSP (Business System Planning) - está baseada nos 
processos de negócios. Os requisitos são derivados
dos objetivos do sistema objeto e da definição dos
processos de negócio (problemas e fatores chave de
sucesso).
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
? 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)
? E/M (End Means Analysis) - propõe a separação entre 
definição dos resultados ou saídas (produtos, serviços e
informações) gerados por um processo organizacional, e 
a definição dos meios (entradas e processos) usados para 
executá-los.
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
Outras Técnicas:
? FAST (facilited application specification technique)
combina: identificação do problema, negociação e
especificação de um conjunto preliminar de requisitos.
? Diretrizes básicas:
? encontro de clientes e desenvolvedores em local
neutro
? estabelecer regras para preparação e participação;
? é sugerida uma agenda cobrindo todos os pontos 
importantes e que encoraja o livre fluxo de idéias;
? “facilitador”(cliente,desenvolvedor, ou elemento 
externo) para controlar o encontro.
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
Estratégia de Loh
? 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:
? perguntas genéricas: tratam de aspectos gerais da 
organização (objetivos, divisões, clientes e fornecedores 
da organização);
? perguntas específicas: coletam informações mais 
detalhadas sobre aspectos da organização;
? perguntas sobre termos chaves: palavras ou verbos 
considerados importantes dentro do contexto, são 
identificados e fornecidos pelo usuário.
eng-requisitos-2003 Elisa Huzita
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
? 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)
? Tipos de perguntas : de instanciação, de relação, 
de complementação, de investigação e de
inconsistência.
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
? Perguntas de instanciação:
? Qual a área funcional? seus objetivos? suas 
atividades? seus problemas?
? Quais são as decisões associadas à atividade?
? De onde provem a informação?
? 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?
? Quais os elementos envolvidos na atividade?
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
? Quais as características do elemento ?
descriçao do elemento? serviços que 
operam o elemento? usuários do serviço?
? Quais são as informações utilizadas pelo 
serviço?
? Quais são as etapas envolvidas na execução
do serviço? restrições que limitam o serviço?
? Perguntas de relação procuram estabelecer
novas relações:
? <informação> apóia <fator crítico>?
? <informação> apóia <decisão>?
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
? Perguntas de investigação: questionam a
existência de informações não mencionadas.
? <fator crítico> é válido?
? Existe mais algum objetivo além da <lista de
objetivos>?
? Existe mais algum fator crítico além de <lista
de fatores críticos>?
? Existe mais alguma informação que apóia
<fator critico> além da <lista de informações>?
? Existe mais alguma característica do 
<elemento> além da <lista de características>?
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
? Perguntas de inconsistência: alertar inconsistências 
ocorridas a respeito de uma resposta:
? A <informação> foi respondida anteriormente como 
sendo fornecida por <origem>! Confirma?
? A <descrição> foi estabelecida anteriormente como
<descrição do elemento>! Confirma?
Outras perguntas podem ser definidas a partir de
heurísticas derivadas do próprio modelo, que analisam as
respostas alimentadas no modelo e procuram relações que 
façam sentido. 
eng-requisitos-2003 Elisa Huzita
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
requisitos, mas não propõe uma solução para o
problema
eng-requisitos-2003 Elisa Huzita
Análise e Negociação dos Requisitos
análise:
? objetivo:
? detectar incompletudes, omissões e redundâncias -
? descobrir os requisitos necessários e desejados
? técnicas utilizadas: lista de checagem, prototipação
eng-requisitos-2003 Elisa Huzita
Análise e Negociação dos Requisitos
negociação:
? objetivos:
? resolver conflitos entre usuários sem comprometer
a satisfação de cada um;
? atribuir prioridades aosrequisitos ----> de acordo
com as necessidades dos usuários;
? atender aos requisitos mais críticos
eng-requisitos-2003 Elisa Huzita
Documentação
Documentação:
? objetivo:
? documentar os requisitos
? deve ser possível de entender por todos ----> 
contrato entre usuários e desenvolvedores;
? deve ser rastreável e gerenciável ao longo da 
evolução do sistema;
? descrever restrições, interfaces com outros 
sistemas, descrição do domínio.
eng-requisitos-2003 Elisa Huzita
Validação de Requisitos
validação de requisitos:
? objetivos:
? certificar que o documento de requisitos é consistente
com as necessiddes dos usuários, 
? verificar a validade, 
? a consistência, a completeza,
? o realismo; 
? a facilidde de verificação.
? dificuldades:
? obter consenso entre usuários com objetivos conflitantes
? demonstrar a corretude
eng-requisitos-2003 Elisa Huzita
Validação de Requisitos
? dificuldades:
? obter consenso entre usuários com objetivos 
conflitantes
? demonstrar a corretude
? técnicas usadas: 
? revisão de requisitos 
? protitipação
eng-requisitos-2003 Elisa Huzita
Gerenciamento de requisitos
gerenciamento de requisitos
? objetivos:
? gerenciar e controlar as mudanças nos requisitos
? gerenciar o relacionamento entre os requisitos
? os requisitos devem ser identificados unicamente
---> possibilitar restrear e avaliar os impactos 
advindos de mudanças
eng-requisitos-2003 Elisa Huzita
Mais técnicas para elicitação e
validação
1) Cenários:
? o que são:
? descrições em linguagem natural ou modelos mais 
complexos contendo informação comportamental
(ações, eventos e atividades) e objetos (entidade,
atributos)
? objetivos:
? descrever as ações em um ambiente relacionadas 
ao sistma atual ou a um sistema a ser desenvolvido
eng-requisitos-2003 Elisa Huzita
Mais técnicas para elicitação e validação
o cenário pode incluir:
? descrição do estado do sistema no início do cenário;
? descrição do fluxo normal de eventos no cenário;
? descrição do que pode sair errado e de como lidar com isso;
? informações sobre outras atividades que possam estar em 
andamento ao mesmo tempo;
? uma descrição do estado do sistema no final do cenário
exemplo: ( cenário do evento) iniciar transação:
solicitar senha, validar usuário e selecionar serviço
eng-requisitos-2003 Elisa Huzita
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):
? tempo esgotado: não forneceu a senha dentro do 
tempo permitido
? cartão inválido: não é reconhecido e é devolvido
? cartão roubado: cartão é reconhecido como cartão 
roubado e é retido na máquina.
eng-requisitos-2003 Elisa Huzita
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:
? Hipótese: a integração de técnicas fornece o
melhor caminho para a engenharia de requisitos
? técnicas utilizadas:
? entrevistas e técncias para descobrimento de
fatos: elicitar dados suficientes para a
construção de protótipo
eng-requisitos-2003 Elisa Huzita
Mais técnicas para elicitação e
validação
? construção de protótipo: pode usar qualquer 
ferramenta
? validação com clientes: utilizar protótipos para 
validar os requisitos
? análise: efetuar a análise dos requisitos
alguns pontos:
? combinação de técnicas é útil na captura de requisitos;
? a utilização de cenários na descrição de situações 
auxilia a manter a atenção dos clientes;
? cenários são fracos para captura de requisitos não 
funcionais.
eng-requisitos-2003 Elisa Huzita
Mais técnicas para elicitação e
validação
2) Use case: baseados em cenário para a obtenção de
requisitos
3) Etnografia:
? técncia de observação que podeser utilizada na 
compreensão dos requisitos sociais e organizacionais. 
? o analista observa o trabalho diário in loco.
? ajuda a descobrir requisitos implícitos, que refletem 
processo reais ( muito além daquilo que consta na 
definição de um processo)
eng-requisitos-2003 Elisa Huzita
Mais técnicas para elicitação e
validação
4) orientado a pontos de vista:
? sistemas de médio ou grande porte--> diferentes tipos
de usuários --> diferentes interesses nos requisitos ---
>diferentes pontos de vista
? os diferents pontos de vista são utilizados para 
estruturar e organizar o processo de levantamento e
os próprios requisitos.
eng-requisitos-2003 Elisa Huzita
Mais Técnicas para Elicitação e 
validação
Vantagens:
? a utilização do sistema é heterogênea: diferentes 
usuários
? pode ser usada para coletar e classificar informações
de diferentes tipos de domínio de aplicação,
? pode ser usado como um meio para estruturar o
processo de elicitação de requisitos
? pode ser usado para encapsular diferentes modelos
de sistema
? pode ser usado para estruturar descrição de
requisitos e expor conflitos entre os diferentes 
requisitos.
eng-requisitos-2003 Elisa Huzita
Princípios de Especificação de
Requisitos
Os usuários e os interesses:
? clientes : validação dos requisitos.
? analistas :
? consistencia, completude e corretude (na 
especificação).
? garantir a integridade do sistema (no projeto).
? os projetistas e engenheiros: nos requisitos (é 
a base para a construção do sistema)
? o gerente de projeto: administrativas contidas 
nos requisitos e também restrições de tempo e
necessidades do cliente.
eng-requisitos-2003 Elisa Huzita
Princípios de Especificação de Requisitos
Conteúdo de uma Especificação de Requsitos:
1) Funcionalidade: descrevem os serviços que devem ser
fornecidos para o cliente/usuário:
? procedimentos para inicializar , finalizar, testar
o sistema;
? operações sobre condições normais /anormais;
? procedimentos para controlar os modos de operação
/recuperação do sistema
2) Descrição do Ambiente e Objetivos do Sistema:
? objetivos do sistema: razões fundamentais para ter um
sistema de computação.
eng-requisitos-2003 Elisa Huzita
Princípios de Especificação de Requisitos
? descrição do ambiente no qual o sistema irá 
operar e o domínio da aplicação.
? Contém, informações tais como:
? atributos físicos do ambiente (tamanho,
localização);
? atributos organizacionais (aplicação comercial,
aplicação militar);
? tipos de usuários em potencial;
? aspectos de segurança;
? mudanças no ambiente que irão perturbar a
operação do sistema,etc..
eng-requisitos-2003 Elisa Huzita
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:
? padrões de documentação;
? procedimentos para teste e integração dos
módulos;
? procedimentos para o controle das mudanças e
? mudanças conjecturadas/esperadas.
b) da entrega e instalação do sistema,
considerando os processos que ocorrem fora do
escopo de construção e incluem informações do
tipo:
eng-requisitos-2003 Elisa Huzita
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:
? performance;
? eficiencia;
? segurança;
? confiabilidade;
? qualidade.
eng-requisitos-2003 Elisa Huzita
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 dosistema:
? padrões de hardware e software;
? uso de bibliotecas específicas;
? uso de um sistema operacional específico 
? questões de compatibilidade.
6) Protocolos de Dados e Comunicação:
descrevem todos os tipos de fluxo de dados entre os 
componentes funcionais do sistema, e entre o
sistema e seu ambiente. Isto inclui:
eng-requisitos-2003 Elisa Huzita
Princípios de Especificação de Requisitos
Características Desejáveis em uma 
Especificação de Requisitos:
? Não ambiguidade: ter interpretação única
? Completude:
? descrever cada apecto significativo e relevante do
sistema e
? incluir detalhes a respeito de todas as informações.
? melhor juiz = usuário, mas este nem sempre sabe 
muito além das funcionalidades e objetivos.
? natureza subjetiva da definição de completude 
esta propriedade é impossível de ser garantida;
eng-requisitos-2003 Elisa Huzita
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;
Modificação
eng-requisitos-2003 Elisa Huzita
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;
Rastreamento: estabelecer referências entre os 
requisitos, aspectos de projeto e implementação,
para possibilitar controlar os efeitos das
modificações. 
eng-requisitos-2003 Elisa Huzita
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
1.5 visão geral do restante do docuemnto 
2.Descrição geral
2.1 perspectiva do produto
2.2 funções do produto
2.3 características do usuário
2.4 restrições gerais
2.5 suposições e dependências
eng-requisitos-2003 Elisa Huzita
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.
4. Apêndices
5. índice
eng-requisitos-2003 Elisa Huzita
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 
requisitos depende do tipo de software que está sendo 
desenvolvido
eng-requisitos-2003 Elisa Huzita
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 
objetivos estratégicos da organização que 
está encomendando o software.
eng-requisitos-2003 Elisa Huzita
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.
Ex. O editor deve fornecer um recurso aos usuários para 
adicionar nós de um tipo específico a seu desenho
eng-requisitos-2003 Elisa Huzita
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 
requisitos funcionais e não funcionais, podendo incluir 
interfaces com outros sistemas.
eng-requisitos-2003 Elisa Huzita
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
10. Índice: alfabético, diagramas
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
O Contexto da Definição de Requisitos:
1) Elementos Fundamentais:
? Ambiente ou domínio da aplicação: 
? O que é:
? é onde ocorrem os fenômenos que caracteerizam os 
problemas referentes aos requisitos do cliente. 
? É o primeiro elemento a ser conhecido e 
representado pelo engenheiro de requisitos. 
? Incluem aspectos sociais, economicos e políticos em 
que se insere a organização
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
? Características:
? Cultura organizacional: regras, comportamento, 
hábitos e costumes
? Mudanças: dinâmica social e organizacional do 
elemnto humano como agente de mudança do 
ambiente;
? Tecnologias: avanços tecnológicos e o impacto que 
causam no ambiente organizacional
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
?Problemas:
?O que são:
? diferença : algo como desejado x como percebido
?Características:
? Fato: verdade
? Fenomeno:como se vê
? Fato + fenomeno + quem relata : possibilita 
entender um problema
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
?Requsitos:
? O que são:
? 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
? Características:
? Funções
? Atributos
? Restriçoes (critéios para aprovação ou recusa para 
um produto)
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
? Stkeholder: 
? Quem são:
? pessoas que direta/indiretamente são afetadas pelo 
sistema a ser construído para a solução de 
problemas
? Características:
? Preferências
? Expectativas
? Prioridade
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
Processo de Engenharia de Requisitos
? Envolve: a aplicção de técnicas; métodos, 
normas e padrões e métricas e planejamento
Produto: documento de requisitos
? Incluem: contexto organixacional, requisitos, 
avliação de riscos.
	Engenharia de Requisitos
	Requisitos
	Engenharia de Requisitos
	Níveis de Requisitos
	Níveis de requisitos
	Níveis de requisitos
	Tipos de requisitos
	Tipos de requisitos
	Tipos de requisitos
	O processo de engenharia de requisitos
	propostas de modelos de processo:
	Modelo de Processo de Engenharia de Requisistos
	Modelo de Processo de Engenharia de Requisistos
	Modelo de Processo de Engenharia de Requisistos
	Modelo de Processo de Engenharia de Requisistos
	Modelo de Processo de Engenharia de Requisistos
	Modelo de Processo de Engenharia de Requisistos
	Modelo de Processo de Engenharia de Requisistos
	Elicitação
	Elicitação
	Elicitação
	Elicitação
	Elicitação
	Técnicas tradicionais para elicitação
	Técnicas tradicionais
	Técnicas tradicionais
	Técnicas tradicionais
	Técnicas tradicionais
	Técnicas tradicionais
	Técnicas tradicionais
	Técnicas tradicionais
	Técnicas tradicionais
	Técnicas tradicionais
	Técnicas tradicionais
	Elicitação
	Análise e Negociação dos Requisitos
	Análise e Negociação dos Requisitos
	Documentação
	Validação de Requisitos
	Validação de Requisitos
	Gerenciamento de requisitos
	Mais técnicas para elicitação e validaçãoMais técnicas para elicitação e validação
	exemplo..
	Mais técnicas para elicitação e validação
	Mais técnicas para elicitação e validação
	Mais técnicas para elicitação e validação
	Mais técnicas para elicitação e validação
	Mais Técnicas para Elicitação e validação
	Princípios de Especificação de Requisitos
	Princípios de Especificação de Requisitos
	Princípios de Especificação de Requisitos
	Princípios de Especificação de Requisitos
	Princípios de Especificação de Requisitos
	Princípios de Especificação de Requisitos
	Princípios de Especificação de Requisitos
	Princípios de Especificação de Requisitos
	Princípios de Especificação de Requisitos
	Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-1993
	Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-1993
	Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-1993
	Formato de documento de requisitos sugerido em [Sommervile 2002]
	Formato de documento de requisitos sugerido em [Sommmervile, 2002]
	Formato de documento de requisitos sugerido em [Sommervile 2002]
	Formato de documento de requisitos sugerido em [Sommervile 2002
	Comentários Adicionais
	Comentários Adicionais
	Comentários Adicionais
	Comentários Adicionais
	Comentários Adicionais
	Comentários Adicionais