Engenharia de Requisitos

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:
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
representar e acessar arquivos externos criados por
outras ferramentas
eng-requisitos-2003 Elisa Huzita
Níveis de requisitos
Requisitos do sistema:
z
z
Se destinam a comunicar, de modo preciso as
funções que o sistema tem de fornecer.
Podem ser escritos:
z
z
z
z
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:
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
representado como um ícone específico na tela
eng-requisitos-2003 Elisa Huzita
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
z
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
z
Requisitos não funcionais:
z
dizem respeito às:
z restrições,
z aspectos de desempenho,
z interfaces com o usuário,
z confiabilidade,
z segurança,
z manutenibilidade,
z portabilidade,
z Padrões.
z
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:
z
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
1. Elicitação
aplicação de
métodos de
aquisição de
informação
comunicação
Engenheira de
Requisitos
Usuário
'Enunciado do Problema'
2. Especificação
aplicação de métodos de especificação
3. Revisão
aplicação de
métodos de
revisão e
animação
desafios
modificações
comunicação
'Especificação de Requisitos'
Usuário
aprovação do documento
Projeto
eng-requisitos-2003 Elisa Huzita
Engenheira de
Requisitos
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.
z
validação de requisitos.
eng-requisitos-2003 Elisa Huzita
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
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:
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
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).
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.
z
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
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
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
requisito
requisitos
requisitos
declaração necessidade
documento
sistema existente
requisitos
padrões
usuários
experiência domínio
eng-requisitos-2003 Elisa Huzita
especificação
requisitos
especificação
sistema
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 interrelacionados que podem cobrir todo o ciclo de vida do
desenvolvimento de sistemas de software
eng-requisitos-2003 Elisa Huzita
eng-requisitos-2003 Elisa Huzita
Elicitação
Elicitação:
z
objetivos:
z
z
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:
z
dificuldades derivadas da capacidade humana:
• armazenar e organizar grande quantidade de
informaçõies;
• gerenciar conflitos.
eng-requisitos-2003 Elisa Huzita
Elicitação
z
z
z
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:
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
z
dificuldade dos usuários em descrever o conhecimento
que possui sobre o domínio do problema
eng-requisitos-2003 Elisa Huzita
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;
• 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
z
Técnicas para elicitação:
z
z
z
z
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
z
técnicas cognitivas: aquisição de conhecimento
para sistemas baseados em conhecimento
z
técncias contextuais: técnicas de etnografia e
análise social.
eng-requisitos-2003 Elisa Huzita
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
z
desvantagem: tempo que elas consomem.
eng-requisitos-2003 Elisa Huzita
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
z
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
z
métodos existentes nesta técnica:
z 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
z
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)
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:
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;
z
“facilitador”(cliente,desenvolvedor, ou elemento
externo) para controlar o encontro.
eng-requisitos-2003 Elisa Huzita
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;
z
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
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,
de complementação, de investigação e de
inconsistência.
eng-requisitos-2003 Elisa Huzita
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?
z
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?
z
Quais os elementos envolvidos na atividade?
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
z
z
z
z
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>?
z <informação> apóia <decisão>?
z
eng-requisitos-2003 Elisa Huzita
Técnicas tradicionais
z
Perguntas de investigação: questionam a
existência de informações não mencionadas.
<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
z
Existe mais alguma característica do
<elemento> além da <lista de características>?
eng-requisitos-2003 Elisa Huzita
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?
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:
z objetivo:
z
detectar incompletudes, omissões e redundâncias -
z
descobrir os requisitos necessários e desejados
z
técnicas utilizadas: lista de checagem, prototipação
eng-requisitos-2003 Elisa Huzita
Análise e Negociação dos Requisitos
negociação:
z
objetivos:
z
z
z
resolver conflitos entre usuários sem comprometer
a satisfação de cada um;
atribuir prioridades aos requisitos ----> de acordo
com as necessidades dos usuários;
atender aos requisitos mais críticos
eng-requisitos-2003 Elisa Huzita
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
sistemas, descrição do domínio.
eng-requisitos-2003 Elisa Huzita
Validação de Requisitos
validação de requisitos:
z
objetivos:
z
z
z
z
z
z
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:
z
obter consenso entre usuários com objetivos conflitantes
z
demonstrar a corretude
eng-requisitos-2003 Elisa Huzita
Validação de Requisitos
z
dificuldades:
z
z
z
obter consenso entre usuários com objetivos
conflitantes
demonstrar a corretude
técnicas usadas:
z
revisão de requisitos
z
protitipação
eng-requisitos-2003 Elisa Huzita
Gerenciamento de requisitos
gerenciamento de requisitos
z objetivos:
z
z
gerenciar e controlar as mudanças nos requisitos
z
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:
z
o que são:
z
z
descrições em linguagem natural ou modelos mais
complexos contendo informação comportamental
(ações, eventos e atividades) e objetos (entidade,
atributos)
objetivos:
z
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:
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:
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):
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
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:
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
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
z
z
z
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:
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;
z
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:
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
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:
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
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:
z
z
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,
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
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:
z clientes : validação dos requisitos.
z analistas :
consistencia, completude e corretude (na
especificação).
z 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.
z
z
z
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;
z operações sobre condições normais /anormais;
z procedimentos para controlar os modos de operação
/recuperação do sistema
z
2) Descrição do Ambiente e Objetivos do Sistema:
z
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.
z Contém, informações tais como:
z
z
z
atributos físicos do ambiente (tamanho,
localização);
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
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:
z
z
z
z
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
z
prazos de entrega;
critério de aceitação;
treinamento;
manuais;
z
suporte e manutenção.
z
z
z
4)
Restrições
Funcionais:
descrevem
as
propriedades necessárias ao comportamento do
sistema e incluem:
z performance;
z eficiencia;
z segurança;
z confiabilidade;
z 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 do sistema:
z padrões de hardware e software;
z uso de bibliotecas específicas;
z uso de um sistema operacional específico
z
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:
z Não ambiguidade: ter interpretação única
z Completude:
z
z
z
z
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,
requiatos refletem as suas idéias;
Modificação
eng-requisitos-2003 Elisa Huzita
e indicar se os
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.
2.
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
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:
z
Ambiente ou domínio da aplicação:
z
O que é:
z
z
z
é 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
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
causam no ambiente organizacional
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
z Problemas:
zO
que são:
z
diferença : algo como desejado x como percebido
z Características:
Fato: verdade
z Fenomeno:como se vê
z Fato + fenomeno + quem relata : possibilita
entender um problema
z
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
z Requsitos:
z
O que são:
z
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
Características:
z
Funções
z
Atributos
z
Restriçoes (critéios para aprovação ou recusa para
um produto)
eng-requisitos-2003 Elisa Huzita
Comentários Adicionais
z
Stkeholder:
z
Quem são:
z
z
pessoas que direta/indiretamente são afetadas pelo
sistema a ser construído para a solução de
problemas
Características:
z
Preferências
z
Expectativas
z
Prioridade
eng-requisitos-2003 Elisa Huzita
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,
avliação de riscos.
eng-requisitos-2003 Elisa Huzita