Você está na página 1de 175

Anlise Orientada a

Objetos
Engenharia de Requisitos

Objetivos
Introduzir a noo de requisitos do sistema
e o processo da engenharia de requisitos.
Explicar como a engenharia de requisitos se
encaixa no processo mais abrangente da
engenharia de sistemas
Explicar a importncia do documento de
requisitos

Motivao
No incio da computao no havia
nenhuma processo para a descoberta dos
requisitos
Os programadores sentavam-se e
comeavam a codificar.

Reconhecendo o cu$$$to
Quando comea um processo de desenvolvimento
de software, um lpis custa pouco mais de R$ 1,00 .

S que a borracha para efetuar os ajustes custa


milhes...

No fcil...
... entender a funcionalidade.

No fcil...
...obter a forma correta.

No fcil...
...entender problemas que voc no est
familiarizado
...entender os detalhes da soluo.

Requisitos do sistema
Definem o que solicitado ao sistema fazer e com quais
limitaes ele requisitado a operar.
Por exemplo:
O sistema deve manter registro de todos os materiais da
biblioteca incluindo livros, sries, jornais e revistas e
CDROMs. (requisito funcional)
O sistema deve permitir que os usurios pesquisem um item
atravs do ttulo, autor ou ISBN. (requisito funcional)
A interface de usurio do sistema deve ser implementada
para ser acessvel via browser de WWW (World-Wide-Web).
(requisito no-funcional)
O sistema deve suportar pelo menos 20 transaes por
segundo. (requisito no-funcional)

Tipos de requisitos
Funcionais
definem as funcionalidades do sistema.

Servios que o sistema deve fornecer


Como o sistema deve reagir a entradas especficas
Como o sistema deve se comportar em determinadas situaes
Ex.: O sistema deve permitir a realizao de compras de livros

No-Funcionais
dizem respeito restries de desenvolvimento, aspectos de
desempenho, interfaces com o usurio, confiabilidade,
segurana, manutenibilidade, portabilidade, padres a
serem seguidos
Ex.: O sistema deve possuir uma GUI que siga o padro de
interface do Windows

Exemplos de requisitos
funcionais
O usurio deve ser capaz de pesquisar em todo o
conjunto inicial de banco de dados ou selecionar
um subconjunto a partir dele
Para todo pedido deve ser alocado um
identificador nico (ORDER_ID) que o usurio
possa copiar para a rea de armazenamento
permanente da sua conta
O sistema deve fornecer telas apropriadas para o
usurio ler os documentos no repositrio de
documentos

Requisitos no-funcionais
Definem propriedades e restries de sistema
Ex: confiabilidade, tempo de resposta e requisitos de
armazenamento

Restries so capacidade de dispositivos de E/S,


representaes de sistema, etc.
Requisitos de processo podem tambm ser especificados,
impondo uma linguagem de programao, IDE ou mtodo
de desenvolvimento particular
Requisitos no-funcionais podem ser mais crticos do que
os requisitos funcionais

Tipos de requisitos nofuncionais

Tipos de requisitos
Organizacionais
dizem respeito s metas da empresa.
polticas estratgicas adotadas,
os empregados da empresa com seus respectivos
objetivos;
enfim toda a estrutura da organizao.
Ex.: O sistema visa aumentar os lucros da empresa

Problemas dos Requisitos


Os requisitos no refletirem as reais necessidades
dos clientes do sistema.
Os requisitos serem inconsistentes e/ou incompletos.
O custo alto para se fazer mudanas de requisitos
depois de terem sido concordados.
Existirem mal entendidos entre clientes, aqueles que
desenvolvem os requisitos do sistema e os
engenheiros de software que desenvolvem ou
mantm o sistema.

Impreciso de requisitos
Problemas surgem quando os requisitos no so
precisamente definidos
Requisitos ambguos podem ser interpretados de
maneiras diferentes pelos desenvolvedores e usurios
Considere o termo telas apropriadas
Inteno do usurio tela de propsito especial para cada tipo
diferente de documento
Interpretao do desenvolvedor fornece uma tela de texto que
mostra o contedo do documento

Requisitos completos e
consistentes
Em princpio, requisitos devem ser completos e
consistentes
Completude
Eles devem incluir descries de todos os recursos
requeridos

Consistncia
No deve haver conflitos ou contradies nas descries
dos recursos de sistema

Na prtica, impossvel produzir um documento de


requisitos completo e consistente

Questes mais frequentemente


perguntadas sobre requisitos
(FAQS)
O que so requisitos?
Uma descrio de um servio ou de uma limitao

O que a engenharia de requisitos?


O processo envolvido no desenvolvimento de
requisitos de um sistema

Quanto custa a engenharia de requisitos?


Cerca de 15% dos custos do desenvolvimento do
sistema.

FAQs continuao
O que o processo de engenharia de requisitos?
Um conjunto estruturado de atividades envolvidas no
desenvolvimento dos requisitos do sistema

O que acontece quando os requisitos esto errados?


Os sistema atrasam, ficam no confiveis e no satisfazem
as necessidades dos clientes.

Existe um processo de engenharia de requisitos ideal?


No - os processos precisam ser adaptados as necessidades
organizacionais.

O que um documento de requisitos?


Uma descrio formal dos requisitos do sistema.

FAQs continuao
O que so stakeholders do sistema?
Qualquer pessoa afetada de alguma forma pelo
sistema.

Qual o relacionamento entre requisitos e projeto?


Requisitos e projeto so interligados. Idealmente eles
deveriam ser separados, mas na prtica isto
impossvel.

O que gerenciamento dos requisitos?


O processo envolvido no gerenciamento das mudanas
dos requisitos

O que a Engenharia de
Requisitos?
Disciplina para desenvolver uma
especificao completa, consistente e no
ambgua - que sirva como base para um
acordo entre todas as partes envolvidas descrevendo o que o produto de software
ir fazer (mas no como ele ser feito).

Engenharia de Sistemas
Existe um relacionamento prximo entre
software e os requisitos mais gerais do sistema
Os sistemas baseados em computadores so
de duas categorias:
Sistemas configurados para o usurio, onde o
comprador compe um sistema a partir de
produtos de software existentes - COTS
Sistemas onde o cliente produz um conjunto de
requisitos para sistemas de software/hardware e a
um contratado desenvolve e entrega o sistema

O Processo da Engenharia de
Sistemas

Atividades da Engenharia de
Sistemas
Engenharia de Requisitos do Sistema
Os requisitos do sistema como um todo so
estabelecidos e escritos para serem entendidos por
todas as partes interessadas (stakeholders)

Projeto de arquitetura
O sistema decomposto em subsistemas

Partio de requisitos
Os requisitos so alocados a estes subsistemas

Engenharia de Requisitos de Software


Requisitos de software mais detalhados so derivados
para o software do sistema

Atividades da Engenharia de
Sistemas
Desenvolvimento de subsistemas
Os subsistemas de hardware e software so
projetados e implementados em paralelo.

Integrao de sistemas
Os subsistemas de hardware e software so
colocados juntos para compor o sistema.

Validao do sistema
O sistema validado em relao aos requisitos.

Propriedades Emergentes
Propriedades do sistema como um todo
que somente emergem quando todos os
subsistemas estiverem integrados.
Exemplos de propriedades emergentes

Confiabilidade
Manutenabilidade
Desempenho (Performance)
Usabilidade
Segurana

Documento de Requisitos
Documento formal usado para comunicar os
requisitos aos clientes, engenheiros e
gerentes.
Descreve:
Os servios e funes que o sistema deve prover;
As limitaes sobre as quais o sistema deve operar;
Propriedades gerais do sistema, isto limitaes
nas propriedades emergentes;
Definies de outros sistemas com o qual o
sistema deve se integrar.

Documento de Requisitos
Descreve (continuao):
Informaes sobre o domnio da aplicao do sistema;
Ex.: como calcular um certo tipo de computao
Limitaes nos processos usados para desenvolver o
sistema;
Descries sobre o hardware no qual o sistema ir
executar.

Dever sempre conter uma captulo introdutrio


que prov um resumo do sistema, necessidades de
negcio suportadas pelo sistema e um glossrio que
explica a terminologia usada.

Usurios do documento de
requisitos
Clientes do Sistema
Especificam os requisitos e os leem para checar se
eles satisfazem suas necessidades.

Gerentes de Projeto
Usam os documentos de requisitos para
planejarem uma proposta para o sistema e o
processo de desenvolvimento do sistema.

Engenheiros de Sistema
Usam os requisitos para entenderem o sistema em
construo.

Usurios do documento de
requisitos (cont.)
Engenheiros de teste do sistema
Usam os requisitos para desenvolverem testes
de validao do sistema.

Engenheiros de manuteno do sistema


Usam os requisitos para entenderem o sistema.

Estrutura do documento de
requisitos
Padro IEEE/ANSI 830-1998 uma estrutura
para o documento de requisitos
1. Introduo
1.1 Propsito do documento de Requisitos
1.2 Escopo do produto
1.3 Definies, acrnimos e abreviaes
1.4 Referencias
1.5 Resumo do resto do documento

Estrutura do documento de
requisitos
2. Descrio Geral
2.1 Perspectiva do produto
2.2 Funes do produto
2.3 Caractersticas do usurio
2.4 Limitaes gerais
2.5 Suposies e dependncias

3. Requisitos especficos
Cobrem requisitos funcionais, no-funcionais e interface.

4. Apndices
ndice

Adaptando um padro
O padro do IEEE genrico e pretende ser
aplicado em uma variada gama de
documentos de requisitos.
Em geral, nem todas as partes do documento
so necessrias para todos os documentos de
requisitos.
Cada organizao dever adaptar o padro de
acordo com o tipo de sistema que desenvolve.
Considere uma companhia (XYZ) que
desenvolve equipamentos cientficos.

Padro da empresa XYZ


Prefcio
Define os leitores do documento e descreve a histria
das verses, incluindo um explicao da criao de
novas verses e um resumo das mudanas feitas em
cada verso.

Introduo
Define o produto no qual o software est embutido,
seu uso esperado e apresenta um resumo da
funcionalidade do software de controle.

Glossrio
Define todos os termos tcnicos e abreviaes usadas
no documento.

Padro da empresa XYZ


Requisitos gerais do usurio
Define os requisitos do ponto de vista dos usurios
do sistema. Isto inclui uma mistura de linguagem
natural e diagramas.

Arquitetura do sistema
Apresenta uma viso de alto nvel da arquitetura
prevista do sistema, mostrando a distribuio das
funes dos mdulos do sistema. Indica os
componentes da arquitetura que sero reusados.

Padro da empresa XYZ


Especificao de Hardware
Parte opcional que especifica o hardware que o
software dever controlar. Poder ser omitido se uma
plataforma padro de instrumento for ser utilizada.

Especificao detalhada de software


Descrio detalhada da funcionalidade esperada do
software. Poder incluir detalhes de algoritmos
especficos que devem ser usados na computao. Se
for ser usada uma abordagem de prototipao para o
desenvolvimento numa plataforma padro de
instrumento, esta seo poder ser omitida.

Padro da empresa XYZ


Quando apropriado, os seguintes apndices
podero ser adicionados:
Especificao da interface de Hardware;
Componentes de Software que devero ser reusados
na implementao do sistema;
Especificao da estrutura de dados;
Modelos de fluxo de dados do sistema de software;
Modelos detalhados de objetos do sistema de
software.

ndice

Escrevendo requisitos
Requisitos so geralmente escritos como
textos em linguagem natural complementados
por diagramas e equaes.
Problemas com os requisitos
Uso de clusulas condicionais complexas que
podem confundir;
Terminologia inconsistente;
Os escritores assumem que os leitores possuem
conhecimento do domnio.

O essencial da escrita
Requisitos so lidos mais frequentemente
do que so escritos. Voc dever investir
tempo lendo e entendendo os requisitos.
No assuma que todos os leitores dos
requisitos tenham o mesmo background e
usem a mesma terminologia sua.
Permita tempo para reviso e refeita do
documento de requisitos.

Escrevendo diretrizes
Defina templates (modelos) padres para
descrio de requisitos;
Use a linguagem de forma simples, consistente
e concisa;
Use diagramas de forma apropriada;
Complemente a linguagem natural com outras
descries de requisitos;
Especifique requisitos de forma quantitativa.

Pontos Principais
Requisitos definem o que o sistema deve prov
e define os limites do sistema;
Problemas nos requisitos causam a entrega
tardia dos sistemas e solicitaes de mudanas
depois que o sistema estiver em uso;
Engenharia de requisitos diz respeito a
elicitao, anlise e documentao dos
requisitos do sistema.

Pontos Principais

Engenharia de sistemas diz respeito ao sistema


como um todo, incluindo hardware, software e
processos operacionais;
O documento de requisitos a especificao
definitiva para os clientes, engenheiros e
gerentes;
O documento de requisitos deve incluir um
resumo, glossrio, definio de requisitos
funcionais e limitaes operacionais.

Referncias
SOMMERVILLE, Ian. Engenharia de Software. 8 ed. So Paulo:
Addison-Wesley, 2007.
Parte 2. Engenharia de Requisitos
Captulo 7

PRESSMAN, Roger S. Engenharia de Software. 5 ed. So Paulo:


McGraw-Hill, 2001.
Parte 3. Mtodos Convencionais para Engenharia de Software
Captulo 10. Engenharia de Sistemas
Seo 10.5.1 Elicitao de Requisitos

G. Kotonya and I. Sommerville, Requirements Engineering:


Processes and Techniques, John Wiley & Sons, 1998.

O PROCESSO DE ENGENHARIA
DE REQUISITOS

OBJETIVO DO
MDULO
Introduzir as noes de processos e
modelos de processo para a engenharia de
requisitos.
Explicar o papel crtico das pessoas no
processo de engenharia de requisitos.
Explicar porque a melhoria do processo
importante e sugerir um modelo de
melhoria de processo para a engenharia
de requisitos.

Processos
Processo um conjunto organizado de
atividades que transforma entradas em
sadas;
Descries de processos encapsulam
conhecimento e permitem que sejam
reusados;
Exemplos de descries de processo:
Manual de instruo de uma mquina de lavar,
receitas de bolo, ER, etc

Processo de ER
entradas e sadas
Informaes de
Sistemas Existentes
Requisitos
Acordados

Necessidades das
partes envolvidas

Padres
Organizacionais
Regulamentaes
Informaes do
Domnio

Processo de
Engenharia
de Requisitos

Especificao do
Sistema
Modelos de
Sistema

Descrio da entrada/sada
Entrada ou Sada

Tipo

Descrio

Informao sobre
Sistemas
Existentes

Entrada

Informao sobre a funcionalidade dos sistemas


a serem substitudos ou de outros sistemas que
interagem com o sistema que est sendo
especificado.

Necessidades dos
Participantes

Entrada

Descries do que os participantes necessitam do


sistema para suportar seus trabalhos

Padres da
Organizao

Entrada

Padres usados na organizao relativos s


prticas de desenvolvimento de sistemas,
gerenciamento da qualidade, etc.

Regulamentaes

Entrada

Regulamentaes externas tais como


regulamentaes de sade e segurana que se
aplicam ao sistema

Informao do
Domnio

Entrada

Informaes gerais sobre o domnio de aplicao


do sistema

Variao do Processo de
Requisitos
Os processos de requisitos variam radicalmente
de uma organizao para outra;
Fatores que contribuem para esta variao:

Maturidade Tcnica;
Envolvimento disciplinas;
Cultura Organizacional;
Domnio de aplicao.

Portanto no existe um processo ideal de


engenharia de requisitos.

Modelo de ER de alto nvel

Modelo de ER de alto nvel

Atividades do processo de
ER
Elicitao de Requisitos
Os requisitos so descobertos atravs da consulta com as
partes interessadas

Anlise e negociao de requisitos


Requisitos so analisados e os conflitos resolvidos atravs de
negociao

Documentao de requisitos
Um documento de requisitos produzido

Validao de requisitos
checada a consistncia e completude do documento de
requisitos

Modelo espiral do processo


de ER

Fatores Humanos e
Sociais
Os processos de engenharia de requisitos so
dominados por fatores humanos, sociais e
organizacionais
porque eles sempre envolvem um conjunto de partes
interessadas com backgrounds diferentes e com
objetivos organizacionais e individuais diferentes

As partes interessadas (stakeholders) pelo


sistema podem ter uma variedade de background
tcnico e no tcnico e de diferentes disciplinas

Fatores influenciando
requisitos
Personalidade e status dos stakeholders;
Os objetivos pessoais dos indivduos dentro
da empresa;
O grau de influncia poltica dentro de uma
organizao.

Melhoria de Processo
A melhoria de processo est relacionado
com a modificao do processo de forma a
alcanar algum objetivo de melhora;
Objetivos de melhora:
Melhoria de qualidade;
Reduo de prazo;
Reduo de recursos.

Planejando a melhoria do
processo
Quais so os problemas com os processos
atuais?
Quais so os objetivos de melhora?
Como o processo de melhora poder ser
introduzido para alcanar estes objetivos?
Como o processo de melhora poder ser
controlado e gerenciado?

Problemas do processo de
ER
Falta de envolvimento dos stakeholders;
As necessidades do negcio no so
consideradas;
Falta de gerenciamento dos requisitos;
Falta de definio de responsabilidades;

Problemas do processo de
ER
Problemas de comunicao dos
stakeholders;
Planejamento longo demais e baixa
qualidade dos documentos de
requisitos.

Um modelo de maturidade
de processo para ER

Nveis de maturidade da
ER
Nvel inicial
No h processo definido de ER. Sofre de
problemas tais como volatilidade dos
requisitos, stakeholders no satisfeitos e alto
custo de refeita dos sistemas. Depende de
habilidades e experincias individuais.

Nveis de maturidade da
ER
Nvel repetvel
Padres definidos para os documentos de
requisitos e polticas e procedimentos para o
gerenciamento de requisitos.

Nvel definido
Um processo definido de ER, baseado em boas
prticas e tcnicas. Em funcionamento um
processo ativo de melhoria.

Boas prticas para a


melhoria do processo de ER
Os processo de ER podem ser melhorados
pela sistemtica introduo de boas
prticas de engenharia de requisitos;
Cada ciclo de melhoria identificar
diretrizes prticas e trabalhar em direo
para a sua introduo na organizao.

Exemplos de diretrizes de
boas prticas
Defina uma estrutura de documento
padronizada;
Identifique de forma nica cada requisito;
Defina polticas para o gerenciamento de
requisitos;

Exemplos de diretrizes de
boas prticas
Use checklists durante a anlise de
requisitos;
Use cenrios para elicitar requisitos;
Especifique requisitos de forma
quantitativa;
Use prototipagem para animar requisitos;
Reuse requisitos.

Pontos principais
O processo de engenharia de requisitos estruturado
como um conjunto de atividades que leva a produo do
documento de requisitos.
As entradas do processo de engenharia de requisitos so
as informaes existentes dos sistemas, necessidade dos
stakeholders, padres organizacionais, regulamentaes e
informaes do domnio.
Os processos de engenharia de requisitos variam
radicalmente entre empresas. A maioria dos processos
incluem a elicitao de requisitos, anlise e negociao
dos requisitos e validao dos requisitos.

Pontos principais
Os modelos do processo de engenharia de requisitos so
descries simplificadas que so apresentadas de uma
perspectiva particular.
Fatores humanos, sociais e organizacionais so influncias
importantes no processo de engenharia de requisitos.
A melhoria do processo de engenharia de requisitos
difcil, sendo tratada melhor de forma incremental.
Os processos de engenharia de requisitos podem ser
classificados de acordo com seus graus de maturidade.

ELICITAO DE REQUISITOS

Objetivos
Descrever o processo da elicitao e anlise
requisitos.
Introduzir um nmero de tcnicas elicitao
de requisitos e anlise de requisitos.
Discutir como prottipos podem ser usados
no processo de ER.

Elicitao de requisitos
ELICITAR: descobrir, tornar explcito, obter o
mximo de informaes para o
conhecimento do objeto em questo
Cabe elicitao a tarefa de identificar os
fatos relacionados aos requisitos do
Sistema, de forma a prover o mais correto e
mais completo entendimento do que
demandado daquele software

Componentes da
elicitao de requisitos

Domnio da
aplicao
Necessidades
dos
stakeholders

Problema a
ser resolvido
Contexto do
negcio

Atividades da Elicitao
Entendimento do domnio da aplicao
O conhecimento do domnio da aplicao o
conhecimento geral onde o sistema ser
aplicado.

Entendimento do problema
Os detalhes dos problemas especficos do
problema do cliente onde o sistema ser
aplicado deve ser entendido.

Atividades da Elicitao
Entendimento do negcio
Voc de entender como os sistemas interagem e
contribuem de forma geral com os objetivos de
negcio.

Entendimento das necessidades e limitaes


dos stakeholders do sistema
Voc deve entender, em detalhe, as necessidades
especficas das pessoas que requerem suporte do
sistema no seu trabalho.

Elicitao de Requisitos:
Dificuldades
Usurios podem no ter uma idia precisa do
sistema por eles requerido;
Usurios tm dificuldades para descrever seu
conhecimento sobre o domnio do problema;
Usurios e analistas tm diferentes pontos de
vista do problema (por terem formaes
diferentes)
Usurios podem antipatizar com o novo sistema e
se negar a participar da elicitao (ou mesmo
fornecer informaes errneas).
Bacal

73

Elicitao, anlise e
negociao

O processo da elicitao
de requisitos

Estgios da Elicitao
Definir objetivos

Aquisio de conhecimento do background


Organizao do conhecimento
Coletar os requisitos dos stakeholders
Bacal

76

Estgios da Elicitao
Definir objetivos
Os objetivos organizacionais devem ser estabelecidos
incluindo objetivos gerais do negcio, um descrio
geral do problema a ser resolvidos porque o sistema
necessrio e as limitaes do sistema.

Aquisio de conhecimento do background


Informao de background do sistema inclui
informao acerca da organizao onde o sistema ser
instalado, o domnio de aplicao do sistema e
informao acerca de outros sistemas existente

Estgios da Elicitao
Organizao do conhecimento
A grande quantidade de conhecimento que foi

coletada nos estgios anteriores devem ser


organizadas e colocadas em ordem.
Coletar os requisitos dos stakeholders
Os stakeholders do sistema so consultados para

descoberta de seus requisitos.

Algumas tcnicas de
elicitao

Entrevistas
Questionrios
Brainstorm
Leitura de documentos
Cenrios
Observaes e anlise sociais (etnografia)
Reuso de requisitos
Prototipao

Entrevistas e questionrios
Defina onde comear
Sempre pergunte:
O que? Por que(m)? Como?

Pergunte o bvio
Organize as respostas: durante e depois
Observe
Seja humilde, procure aprender!

Brainstorm

No pode ter muita gente


Pessoas com diferentes perfis
Presena de um facilitador
Aceite todo tipo de sugesto e filtre depois!
Evite pensar em detalhes
Consulte todos
D sugestes

Cenrios
So estrias que explicam como um sistema
poder ser usado.
So exemplos de sesses de interao que
descrevem como o usurio interage com o
sistema.
O termo caso de uso ou use case (um caso
especfico de uso do sistema) usado s vezes
para se referir a um cenrio.

Exemplo de cenrio:
Sistema de livraria virtual
Entre no sistema
Escolha o comando pedido de documentos
Entre o nmero de referncia do documento
pedido
Selecione um ponto de entrega
Saia do sistema

Observao e anlise
social
As pessoas geralmente acham difcil descrever o que elas
fazem. s vezes, a melhor forma de entender ser
observ-las no trabalho.
Etnografia uma tcnica das cincias sociais que se
mostrou til no entendimento dos processos reais
realizados nos trabalhos.
Os processos reais de trabalho geralmente diferem
daqueles processos formais descritos.
Um etngrafo passa algum tempo observando as pessoas
no trabalho e constri uma imagem de como o trabalho
realizado.

Diretrizes para etnografia


Procure formas no padronizadas de trabalho.
Gaste algum tempo conhecendo as pessoas e estabelea
um relacionamento de confiana.
Tome nota, de forma detalhada, de todas as prticas de
trabalho. Analise-as e chegue a uma concluso a partir
delas.
Combine observao com entrevistas abertas.
Organize regularmente sesses de relato, onde o
etngrafo fala para pessoas externas ao processo.
Combine etnografia com outras tcnicas de elicitao.

Reuso de requisitos
Envolve considerar requisitos que foram
desenvolvidos para um sistema e us-los
em sistemas diferentes.
O reuso de requisitos economiza tempo e
esforo, pois requisitos reutilizados j foram
analisados e validados em outros sistemas.

Prototipao (na Elicitao)


Um prottipo uma verso inicial de um sistema
que poder ser usado para experimentao.
Prottipos so teis para elicitao de requisitos
porque os usurios podero experimentar o
sistema e mostrar os pontes fortes e fracos.
Eles tero algo concreto para criticar.
O desenvolvimento rpido dos prottipos
essencial para que eles fiquem disponveis logo
para o processo de elicitao.

Benefcios da prototipao
O prottipo permite que os usurios experimentem e
descubram o que eles realmente necessitam para suportar
o trabalho deles
Estabelece a viabilidade e utilidade antes que altos custos
de desenvolvimento tenham sido realizados
Essencial para desenvolvimento do aspecto look and feel
da interface do usurio
Pode ser usado para teste do sistema e desenvolvimento
da documentao
Fora um estudo detalhado dos requisitos, revelando
inconsistncias e omisses

Anlise de requisitos
O objetivo da anlise de requisitos descobrir problemas, incompletude
e inconsistncia nos requisitos elicitados.
Outro objetivo importante da anlise de requisitos descobrir as
interaes (rastreamento) entre requisitos e informar os conflitos e
sobreposies encontrados.
Os problemas existentes com os requisitos so retornados aos
stakeholders para resolv-los, atravs de um processo de negociao.
A anlise intercalada com elicitao, pois problemas so descobertos
quando os requisitos so elicitados.
Uma lista de verificao de problemas (checklist) poder ser usada para
ajudar a anlise. Cada requisito poder ser avaliado contra esta lista.

Anlise e negociao de
requisitos

Estgios da anlise dos


requisitos
Checagem da necessidade
A necessidade dos requisitos analisada. Em alguns
casos, alguns requisitos propostos podem no
contribuir para os objetivos de negcio da organizao
ou para o problema especfico tratado pelo sistema.

Checagem da consistncia e completude


Os requisitos so verificados entre si para determinar
consistncia e completude. Consistncia significa que
nenhum requisito deve ser contraditrio; completude
significa que nenhum servio (ou limitao) que seja
necessrio foi esquecido.

Estgios da anlise dos


requisitos
Checagem da viabilidade
Os requisitos so verificados para garantir que
so viveis dentro do oramento e tempo
disponvel para o desenvolvimento do sistema.

Uso de checklist para


anlise
Projeto prematuro
Os requisitos incluem informao prematura de projeto
ou implementao?

Requisitos combinados
A descrio do requisito descreve um requisito nico
ou este pode ser descrito em vrios requisitos
diferentes?

Requisitos desnecessrios
O requisito realmente necessrio, ou ser que uma
mera adio cosmtica ao sistema?

Uso de checklist para


anlise
Uso de hardware no padronizado
Os requisitos implicam no uso de uma plataforma de hardware
no padronizada? Para tomar esta deciso, voc precisa conhecer
os requisitos de plataforma do computador.

Est de acordo com os objetivos de negcio


O requisito consistente com os objetivos de negcio definidos no
documento de requisitos?

Ambiguidade de requisitos
O requisito ambguo, isto , pode ser lido de forma diferente por
pessoas diferentes? Quais so as possibilidades de interpretao
dos requisitos?

Uso de checklist para


anlise
Realismo dos requisitos
O requisito realstico em relao a tecnologia usada
para a implementao do sistema?

Teste dos requisitos


Podemos testar os requisitos, ou seja, eles foram
escritos de tal forma que um engenheiro de teste
poder derivar o teste que mostrar se o sistema
satisfaz os requisitos?

Negociao de requisitos
Problemas nos requisitos so inevitveis quando
um sistema possui muitos stakeholders. Conflitos
no so falhas, mas refletem necessidades e
prioridades diferentes entre as partes
interessadas.
A negociao de requisitos o processo de
discusso dos conflitos de requisitos e a busca de
um compromisso no qual todas as partes
interessadas concordem.

Negociao de requisitos
No planejamento do processo de
engenharia de requisitos, importante
deixar tempo para negociao.
Alcanar um compromisso aceitvel pode
tomar um tempo considervel.

Estgios da negociao
Discusso dos requisitos
Os requisitos que foram identificados como problemticos so
discutidos e os stakeholders envolvidos apresentam seus pontos
de vista acerca dos requisitos.

Priorizao dos requisitos


Os requisitos disputados so priorizados para identificar requisitos
crticos e ajudar o processo de tomada de deciso.

Concordncia dos requisitos


Solues para os problemas dos requisitos so identificadas e um
conjunto de requisitos so acordados. Geralmente isto envolve
mudanas em alguns dos requisitos.

Encontros de negociao
A natureza dos problemas associados com os
requisitos so explicados.
As partes interessadas discutem como o problema
poder ser resolvido.
So atribudas prioridades aos requisitos.
As aes que dizem respeito ao requisito so
concordadas. Estas aes podem ser: deletar o
requisito, sugerir modificaes ao requisito ou
elicitar mais informaes sobre o requisito.

Documentao de
requisitos
O documento de requisitos a
documentao oficial que descreve os
requisitos do sistema
Na medida do possvel, ele deve definir O
QUE o sistema deve fazer em vez do COMO
ele deve fazer
Funciona como um acordo contratual entre
os clientes e fornecedores de um software

O essencial na escrita de um
documento de requisitos
Requisitos so lidos mais frequentemente do que
so escritos. Ento, deve-se investir tempo lendo
e entendendo os requisitos no documento
No assuma que todos os leitores dos requisitos
tenham o mesmo background e usem a mesma
terminologia sua
Permita tempo para reviso e ajustes do
documento de requisitos

Problemas com a documentao


em Linguagem Natural
Falta de clareza
Preciso difcil sem tornar o documento difcil
para leitura

Confuso entre requisitos


Requisitos funcionais e no funcionais tendem
a ser misturados

Fuso de requisitos
Vrios requisitos diferentes podem ser
expressos juntos

Problemas com a documentao


em Linguagem Natural
Ambiguidade
Os leitores e escritores do requisito devem interpretar as mesmas
palavras da mesma maneira. LN naturalmente ambgua o que
torna o seu uso muito difcil.

Flexibilidade
A mesma coisa pode ser dita de vrias formas diferentes na
especificao

Falta de modularizao
Estruturas de LN so inadequadas para estruturar requisitos do
sistema

Concluso: Necessidade de uma notao mais apropriada

Pontos principais
A elicitao de requisitos envolve a compreenso do
domnio da aplicao, o problema especfico a ser
resolvido, as necessidades e limitaes organizacionais e
as facilidades especificas necessrias para as partes
interessadas.
Os processos de elicitao de requisitos, anlise e
negociao so interativos e intercalados, precisando
serem repetidos vrias vezes.
Existem vrias tcnicas de elicitao de requisitos que
podem ser usadas, incluindo entrevistas, cenrios,
mtodos soft systems, prototipagem e observao dos
participantes.

Pontos principais
Prottipos so efetivos para a elicitao de requisitos pois
as partes interessadas tm algo para experimentar e
encontrar seus reais requisitos.
Listas de checagem so formas particularmente teis para
organizar o processo de validao dos requisitos. Elas
lembram ao analista o que deve ser checado quando da
leitura dos requisitos propostos.
Negociao dos requisitos sempre necessrio para
resolver conflitos e remover a sobreposio de requisitos.
Negociao envolve a troca de informao, discusso e
resoluo de conflitos.

VALIDAO DE REQUISITOS

Objetivos da Validao
Certificar que o documento de requisitos uma
descrio aceitvel do sistema a ser
implementado
Verificar as seguintes propriedades do
documento:

Completude e consistncia
Se est de acordo com os padres
Conflitos de requisitos
Erros tcnicos
Requisitos ambguos

Anlise e validao
Anlise trabalha com os dados crus` que foram
elicitados dos stakeholders do sistema
Neste estgio a pergunta chave a ser respondida
Temos os requisitos certos?

Validao usa uma verso final do documento de


requisitos, como os requisitos que foram
negociados e concordados
Neste estgio a pergunta chave a ser respondida
Temos certo os requisitos?

Entradas e sadas da
validao

Entradas da validao
Documento de requisitos
Deve ser um verso completa do documento, no uma
verso preliminar. Formatada e organizada de acordo com os
padres organizacionais.

Conhecimento organizacional
Conhecimento, frequentemente implcito, da organizao
que poder ser usado para julgar o realismo dos requisitos

Padres organizacionais
Padres locais, ex. para a organizao do documento de
requisitos

Sadas da validao
Lista de problemas
Lista dos problemas descobertos no
documento de requisitos

Aes concordadas
Lista de aes que foram acertadas em
resposta aos problemas dos requisitos. Alguns
problemas podem ter vrias aes corretivas;
alguns problemas podem no ter aes
associadas.

Exemplo 1
O Gerenciador de Tarefas deve fornecer
mensagens de status a intervalos regulares e no
menos que a cada 60 segundos
Problemas:

Quais so as mensagens de status?


Quais as condies para fornecer a mensagem?
Como elas so fornecidas?
Por quanto tempo as mensagens so exibidas?
Intervalo de 80 segundos satisfaz o requisito. Intervalo
de 80 dias tambm

Exemplo 2
O Editor XML deve alternar entre exibir e esconder
caracteres no-imprimveis, instantaneamente
Problemas:
Instantneo?
O que provoca a mudana? temporizado, acionado pelo
usurio?
O que ser alterado? O texto selecionado, o documento
inteiro, a pgina atual, etc.
Quais so os caracteres no imprimveis? Texto oculto,
comentrios, tags, etc.

Exemplo 3
O Parser de XML deve produzir um relatrio de erros
de marcadores que permite uma rpida resoluo dos
erros quando usado por usurios novatos em XML
Problemas:

Quo rpido?
Qual o contedo do relatrio de erros?
Quando o relatrio gerado?
Como testar esse requisito?

Exemplo 3
O Parser de XML deve produzir um relatrio de erros
de marcadores que permite uma rpida resoluo dos
erros quando usado por usurios novatos em XML
Melhoria:
1. Depois que o Parser de XML tiver terminado de analisar
um arquivo, ele deve gerar um relatrio de erros que
contm o nmero da linha e o texto de qualquer erro de
XML encontrado no arquivo analisado, assim como a
descrio de cada erro encontrado
2. Se nenhum erro de anlise for encontrado, o Parser no
dever gerar um relatrio de erros

IMPORTNCIA DA VALIDAO
DE REQUISITOS

Mariner Bugs Out (1962)


Cost: $18.5 million
Disaster: The Mariner 1 rocket with a space probe headed
for Venus diverted from its intended flight path shortly
after launch. Mission Control destroyed the rocket 293
seconds after liftoff.
Cause: A programmer incorrectly transcribed a
handwritten formula into computer code, missing a single
superscript bar. Without the smoothing function indicated
by the bar, the software treated normal variations of
velocity as if they were serious, causing faulty corrections
that sent the rocket off course.

Hartford Coliseum Collapse


Cost: $70 million, plus another $20 million damage to the
local economy
Disaster: Just hours after thousands of fans had left the
Hartford Coliseum, the steel-latticed roof collapsed under
the weight of wet snow.
Cause: The programmer of the CAD software used to
design the coliseum, incorrectly assumed the steel roof
supports would only face pure compression. But when one
of the supports unexpectedly buckled from the snow, it set
off a chain reaction that brought down the other roof
sections like dominoes.

Wall Street Crash (1987)


Cost: $500 billion in one day
Disaster: On Black Monday (October 19, 1987), the Dow
Jones Industrial Average plummeted 508 points, losing
2.6% of its total value. The S&P 500 dropped 20.4%. This
was the greatest loss Wall Street ever suffered in a single
day.
Cause: A long bull market was halted by a rash of SEC
investigations of insider trading and by other market
forces. As investors fled stocks in a mass exodus, computer
trading programs generated a flood of sell orders,
overwhelming the market, crashing systems and leaving
investors effectively blind.

Como realizar a validao?

Reviso de requisitos
Prototipagem
Validao de modelos
Teste de requisitos

Reviso de requisitos
Um grupo de pessoas l e analisa os
requisitos, procura problemas, se
rene, discute os problemas e
concorda nas aes para tratar estes
problemas

Processo de reviso de
requisitos

Atividades de Reviso
Planejar a reviso
Selecionar time de reviso, hora e local para o encontro
de reviso.

Distribuir os documentos
O documento de requisitos distribudo entre os
membros do time de reviso

Preparar para reviso


Cada revisor individualmente l os requisitos e
encontra conflitos, omisses, inconsistncias e desvios
dos padres e outros problemas.

Atividades de Reviso
Realizar o encontro de reviso
Os problemas e comentrios individuais so discutidos e um
conjunto de aes para tratar dos problemas concordado.

Aes de acompanhamento
O chefe da reviso verifica se todas as aes acertadas foram
executadas.

Revisar o documento
O documento de requisitos revisado para refletir as aes
concordadas. Nestes estgio, pode ser aceito ou revisado
novamente

Aes para os problemas


Clarificao dos requisitos
O requisito pode ter sido mal escrito ou pode ter acidentalmente omitido
alguma informao que foi coletada durante a fase de requisitos.

Falta de informao
Alguma informao est faltando no documento de requisitos.
responsabilidade do engenheiro de requisitos que est revisando o
documento descobrir esta informao dos stakeholders do sistema.

Conflito de requisitos
Existe um conflito significante entre requisitos. Os stakeholders
envolvidos devem negociar para resolver o conflito.

Requisito no realstico
O requisito no poder ser implementado com a tecnologia disponvel ou
dentro da limitaes do sistema. Os stakeholders devem ser consultados
para decidir como tornar o requisito mais realstico.

Cheque de pr-reviso
Revises so caras porque envolvem um nmero de
pessoas que gastar tempo lendo e verificando o
documento de requisitos
Estes gastos podem ser reduzidos usando uma prreviso, onde uma pessoa verifica o documento e
procura por problemas mais simples tais como: erros
tipogrficos, falta de aderncia ao padro, falta de
algum requisito, etc.
O documento poder ser retornado para correo ou
enviada a lista de problemas para os revisores

Cheque de pr-reviso

Participantes do time de
reviso
Os revisores devem incluir um nmero de
stakeholders com backgrounds diferentes
Pessoas com backgrounds diferentes trazem seus
conhecimentos e habilidades para a reviso
Os stakeholders se sentem envolvidos no
processo e ER e desenvolvem um entendimento
das necessidades dos outros stakeholders
O time de reviso deve sempre incluir um
especialista no domnio e um usurio final Time
independente

Critrios de reviso
Entendimento
Os leitores do documento podem entender o que o requisito significa?

Redundncia
A informao est desnecessariamente repetida no documento?

Completude
O revisor conhece algum requisito que est faltando ou existe alguma
informao que est faltando na descrio individual de um requisito?

Ambiguidade
Os requisitos foram expressos usando termos que esto claramente
definidos? possvel que leitores de backgrounds diferentes fazerem
interpretaes diferentes dos requisitos?

Critrios de reviso
Consistncia
As descries dos diferentes requisitos incluem contradies? Existem
contradies entre requisitos individuais e requisitos gerais do sistema?

Organizao
O documento est estruturado de uma forma apropriada? As descries dos
requisitos esto organizadas de forma que requisitos relacionados estejam
agrupados?

Conformidade a padres
O documento de requisitos ou os requisitos individuais esto conforme o
padro definido? Os desvios do padro esto justificados?

Rastreamento
Os requisitos esto identificados de forma no ambgua, incluindo links a outros
requisitos relacionados e s razes porque os requisitos foram includos?

Questes para o checklist


Cada requisito est unicamente identificado?
Os termos especializados esto definidos no glossrio?
O requisito sozinho faz sentido, ou precisamos examinar outros
requisitos para entend-lo?
Os requisitos individuais usam os termos de forma consistente?
O mesmo servio solicitado em requisitos diferentes? Existem
contradies nestas solicitaes?
Se um requisitos faz referncia a alguma outra facilidade, elas so
descritas em outra parte do documento?
Os requisitos que so relacionados esto agrupados? Se no, h um
referncia entre eles?

Exemplo de checklist
OBS: na prtica, checklists no devem ser to grandes!
Organizao e completude
Todas as referncias a outros requisitos esto corretas?
Todos os requisitos esto escritos em um nvel de detalhamento apropriado e
consistente?
Os algoritmos intrnsecos a requisitos funcionais esto definidos?
A especificao inclu todas as necessidades do sistema e do cliente?

Corretude
Cada requisito est escrito com uma linguagem clara, concisa e no ambgua?
A satisfao de cada requisito pode ser verificada atravs de testes, demonstrao, reviso
ou anlise?
Cada requisito est dentro do escopo do projeto?

Rastreabilidade
Cada requisito est unicamente e corretamente identificado?
Cada requisito funcional de software est ligado um requisito de mais alto nvel?

Prototipagem
Prottipos para validao de requisitos
demonstram os requisitos e ajudam aos
stakeholders a descobrirem problemas
Prottipos para validao devem ser completos,
razoavelmente eficientes e robustos. Dever ser
possvel us-los da mesma forma que o sistema
requerido
Documentos do usurio e treinamento devem ser
providenciados

Prototipagem para
validao

Atividade de Prototipagem
Escolha os testadores do prottipo
Os melhores testadores so os usurios bem experientes e que
tenham cabea aberta sobre o uso do novo sistema.
Usurios finais que tm funes diferentes devem estar envolvidos
para que diferentes reas da funcionalidade do sistema possam ser
cobertas.

Desenvolva os cenrios de teste


necessrio um planejamento detalhado para preparar um conjunto
de cenrios de teste amplo, que faa cobertura de uma grande
quantidade de requisitos.
Os usurios finais no devem apenas brincar com o sistema, pois isto
poder no exercitar aspectos crticos do sistema.

Atividade de Prototipagem
Execute cenrios
Os usurios do sistema, geralmente sozinhos, passa a
testar o sistema atravs da execuo do cenrio
planejado.

Documente problemas
melhor definir algum formulrio de problemas
(eletrnico ou em papel) para que os usurios possam
preencher ao encontrar um problema.

Desenvolvimento do
manual de usurio
A escrita de um manual de usurio a partir de
requisitos fora uma anlise detalhada dos requisitos
e assim poder revelar problemas com os requisitos
Informao do manual de usurios

Descrio da funcionalidade e como ela implementada


Que partes do sistema no foi implementada
Como resolver problemas
Como instalar e comear o sistema

Validao do Modelo
Validao dos modelos do sistema uma parte essencial
do processo de validao
Objetivos da validao dos modelos
Demonstrar que cada modelo auto consistente
Se existem vrios modelos do sistema, demonstrar que eles so
internamente e externamente consistentes
Demonstrar que os modelos refletem de forma precisa os reais
requisitos dos stakeholders do sistema

Alguma verificao possvel com ferramentas


automticas
Parafrasear o modelo uma forma efetiva de checagem

Teste dos requisitos


Cada requisito deve ser testvel, isto dever ser
possvel definir um teste para verificar se o requisito
foi ou no alcanado.
A inveno de testes de requisitos uma tcnica
efetiva de validao, pois informao ambgua ou
incompleta dificulta a formulao dos testes
Cada requisito funcional deve ter um teste associado

Definio de caso de teste


Qual cenrio de uso poder ser usado para testar
um requisito?
O requisito, sozinho, inclui informao suficiente
para a definio de um teste?
possvel testar o requisito usando um nico
teste ou so necessrios mltiplos testes?
O requisito poder ser reescrito para tornar os
casos de teste mais bvios?

Formulrio de teste de
requisito
O identificador do requisito
Deve haver pelo menos um para cada requisito.

Requisitos relacionados
Devem ser referenciados, pois o teste poder ser relevante tambm a
estes requisitos.

Descrio do teste
Uma breve descrio do teste. Deve incluir as entradas do sistema e as
sadas correspondentes.

Problemas do requisito
Uma descrio dos problemas que tornaram difcil ou impossvel a
definio do teste.

Comentrios e recomendaes
So conselhos de como resolver os problemas dos requisitos que foram
descobertos.

Exemplo de teste de
requisitos
Quando os usurios acessarem o sistema,
eles sero apresentados a pginas web com
todos os servios disponveis para eles.

Formulrio de teste de
requisitos

Requisitos difceis de
testar
Requisitos do sistema
Requisitos que se aplicam ao sistema como um
todo.
Em geral, estes so os requisitos mais difceis de
validar independentemente do mtodo usado, pois
podem ser influenciados por quaisquer dos
requisitos funcionais.

Testes que no so executveis, no podem


testar caractersticas gerais no-funcionais do
sistema, tais como usabilidade.

Requisitos difceis de
testar
Requisitos excluso
Existem requisitos que excluem
comportamentos especficos.
Por exemplo, um requisito poderia dizer que
falhas do sistema nunca devem corromper o
banco de dados. No ser possvel testar
este requisito exaustivamente.

Requisitos difceis de
testar
Alguns requisitos no-funcionais
Alguns requisitos no-funcionais, tais
como requisitos de confiabilidade s
podem ser testados com um grande
conjunto de teste.
O projeto destes testes no ajuda a validao dos
requisitos.

Pontos principais
A validao de requisitos deve focar em verificar se a verso
final do documento de requisitos apresenta conflitos, omisses
ou desvios dos padres.
As entradas do processo de validao so os documentos de
requisitos, padres organizacionais, e conhecimento implcito
da organizao. As sadas so uma lista de problemas dos
requisitos e as aes concordadas para tratar estes problemas.
Revises envolvem um grupo de pessoas fazendo anlise
detalhada dos requisitos.
Os custos de reviso podem ser reduzidos se forem verificados,
antes da reviso, desvios do padro organizacional.

Pontos principais
Checklists sobre o que procurar podem ser usadas para guiar o
processo de reviso de requisitos.
Prototipagem efetivo para validao de requisitos se um
prottipo for desenvolvido durante o estgio de elicitao de
requisitos.
Os modelos do sistema so validados atravs do seu
parafraseamento. Isto significa que eles so sistematicamente
traduzidos em uma descrio em linguagem natural.
Projetando testes para requisitos pode revelar problemas com
os requisitos. Se um requisito no estiver claro, poder ser
impossvel definir uma teste para ele.

GERENCIAMENTO DE
REQUISITOS

Gerenciamento de
requisitos
Relaciona-se ao processo de gerenciar a mudana dos
requisitos de um sistema
As principais preocupaes do gerenciamento de
requisitos so:
Gerenciar mudanas nos requisitos que foram concordados
Gerenciar o relacionamento entre requisitos
Gerenciar as dependncias entre os documentos de requisitos e
outros documentos (artefatos)
Analisar impactos e custos relacionados aos requisitos que
mudaram

Gerenciamento x
rastreamento de requisitos
Requisitos no podem ser gerenciados
efetivamente sem rastreamento de
requisitos.
Um requisito rastrevel se voc puder
descobrir quem sugeriu o requisito, porque ele
existe, quais os requisitos relacionados a ele e
como o requisito est relacionado com outras
informaes tais como: projeto do sistema,
implementaes e documentao do usurio.

Rastreamento
Rastreamento aquela informao que
ajuda a analisar o impacto de uma
mudana de requisito.
Rastreamento relaciona requisitos entre si e
entre outras representaes do sistema (ex:
cdigo, casos de teste, etc.).

Matrizes de rastreamento
Mostram os relacionamentos (interaes)
entre requisitos ou entre requisitos e
componentes de projeto
Os requisitos so listados ao longo dos
eixos horizontais e/ou verticais e os
relacionamentos so marcados nas clulas
da matriz

Uma matriz de rastreamento

Polticas de rastreamento
As polticas de rastreamento definem o que e como a
informao de rastreamento ser mantida.
As polticas de rastreamento podem incluir
A informao de rastreamento que deve ser mantida.
Tcnicas, tais como matrizes de rastreamento, que devem ser usadas
para manter o rastreamento.
Uma descrio de quando a informao de rastreamento deve ser
coletada durante o desenvolvimento do sistema.
A definio do papel das pessoas responsveis pelo rastreamento.
Uma descrio de como lidar e documentar excees poltica.

Fatores que influenciam a


poltica de rastreamento
Nmero de requisitos
Quanto maior o nmero de requisitos, maior a
necessidade de polticas formais de
rastreamento.

Vida til estimada do sistema


Para sistemas com longa vida til ser
necessrio definir polticas mais abrangentes.

Fatores que influenciam a


poltica de rastreamento
Nvel de maturidade das organizaes
Polticas detalhadas sero mais efetivas em organizaes com
um alto nvel de maturidade nos processos de
desenvolvimento.

Tamanho e composio do time de projeto


Com um pequeno time, poder ser possvel avaliar o impacto
de mudanas propostas informalmente, sem uma estrutura
de informao de rastreamento. Com grande times, contudo,
ser necessrio polticas mais formais de rastreamento.

Fatores que influenciam a


poltica de rastreamento
Tipo do sistema
Sistemas crticos (ex: de controle de tempo
real) precisam de polticas mais abrangentes do
que sistemas no crticos.

Requisitos especficos do cliente


Alguns clientes podem especificar que a
informao de rastreamento dever ser
entregue como parte do sistema.

Atributos dos requisitos


So informaes a cerca do contexto e das
propriedades dos requisitos.

Data de criao
Identificador
Nmero de verso
Autor
Status (ex: proposto, aprovado, rejeitado)
Origem
Justificativa
Subsistemas correlatos

Atributos dos requisitos


So informaes a cerca do contexto e das
propriedades dos requisitos.

Subsistemas correlatos
Release correlatas
Prioridade
Estabilidade
Custo
Complexidade

Matrizes de atributos so usadas para mostrar o


relacionamento entre requisitos e seus atributos.

Gerenciamento de
mudana
est relacionado com os procedimentos, processos e padres
que sero usados para gerenciar as mudanas (inclusive de
requisitos) do Sistema
A poltica de gerenciamento de mudanas poder incluir:
O processo de solicitao de mudanas e a informao necessria para
processar cada solicitao de mudana
O processo usado para analisar o impacto e custo da mudana e a
informao de rastreamento associada
Definio dos membros do comit que formalmente considera as
solicitaes de mudanas
O suporte de software necessrio para o processo de controle de
mudana

Requisitos estveis e
volteis
Mudanas nos requisitos ocorrem enquanto eles
esto sendo elicitados, analisados, validados e
aps o sistema entrar em servio (produo).
Alguns requisitos so mais sujeitos a mudanas do
que outros
Requisitos estveis so aqueles relacionados com a
essncia do sistema e seu domnio de aplicao. Eles
mudam mais devagar que os requisitos volteis.
Requisitos volteis so especficos a instanciao do
sistema em um ambiente em particular e para um
cliente em particular.

Fatores para a
mudana dos requisitos
Erros, conflitos e inconsistncias nos requisitos
Quando os requisitos so analisados e implementados, erros
e inconsistncias emergem e devem ser corrigidos. Eles
podem ser descobertos durante a anlise e validao de
requisitos ou mais tarde durante o processo de
desenvolvimento.

Evoluo do conhecimento do cliente/usurio-final do


sistema
Ao se desenvolver os requisitos, clientes e usurios-finais
desenvolvem um melhor entendimento do que eles
realmente querem do sistema.

Fatores para a
mudana dos requisitos
Problemas tcnicos, de custo e prazo
Problemas podem ser encontrados quando da
implementao de um requisito. Pode ser muito
caro ou demorar demais para implementar certo
requisito.

Mudana na prioridade dos clientes


A prioridade dos clientes pode mudar durante o
desenvolvimento do sistema como resultado de
mudanas no ambiente de negcios, o surgimento
de novos competidores, mudanas na equipe, etc.

Fatores para a
mudana dos requisitos
Mudanas ambientais
O ambiente no qual o sistema ser instalado poder
mudar de modo que os requisitos de sistema
precisem ser alterados para manter a
compatibilidade

Mudanas organizacionais
A organizao que pretende usar o sistema pode
precisar mudar sua estrutura e processos,
resultando em novos requisitos do sistema

Estgios do gerenciamento
de mudanas

Estgios do gerenciamento
de mudanas
Algum problema identificado
Isto pode ser oriundo de uma anlise do documento de requisitos,
novas necessidades dos clientes, ou problemas operacionais com
o sistema. Com base no problema, mudanas so propostas.

As mudanas propostas so analisadas


Verifica-se quantos requisitos (e se necessrio, componentes de
sistema) sero afetados pela mudana e calcula-se de forma
aproximada quanto custar, em tempo e dinheiro, realizar a
mudana.

A mudana implementada
Um conjunto de alteraes e uma nova verso do documento de
requisitos so produzidos.

Custo e anlise de mudana

Ferramentas CASE para o


gerenciamento de requisitos
O gerenciamento de requisitos envolve a coleta,
armazenamento e manuteno de grande quantidade de
informao.
Existe um grande nmero de ferramentas CASE disponveis
que foram projetadas para suportar o gerenciamento de
requisitos.
Outras ferramentas CASE, tais como sistemas de
gerenciamento de configurao e verso e sistemas de
gerenciamento de mudanas podem ser adaptadas para
a engenharia de requisitos.

Um sistema de gerenciamento
de requisitos

Vantagens do Uso de Ferramentas de


Gerenciamento de Requisitos
Captura e Identificao dos Requisitos
Classificao dos requisitos;
Identificao semiautomtica dos requisitos.

Anlise de Rastreamento
Identificao de inconsistncia;
Verificao de requisitos.

Gerenciamento de Configurao
Histrico das mudanas dos requisitos: quem, o que, quando,
onde, por que e como;
Controle de verso dos requisitos;
Controle de acesso.

Pontos principais
A mudana dos requisitos inevitvel quando os clientes
desenvolvem uma melhor entendimento das suas reais
necessidades e quando ocorrem mudanas nas polticas,
ambiente tcnico e organizacional no qual o sistema ir ser
instalado.
Requisitos que esto relacionados com a essncia do sistema
so mais provveis de serem estveis do que aqueles que esto
relacionados de como o sistema ser implantado num
determinado ambiente.
Os requisitos volteis incluem os seguintes tipos: requisitos
mutveis, requisitos emergentes, requisitos de consequncia e
requisitos de compatibilidade.

Pontos principais
O gerenciamento de requisitos requer que cada requisitos seja
identificado de forma nica.
Se o nmero de requisitos for grande, os requisitos devem ser
armazenados num banco de dados e se deve manter
relacionamentos entre os requisitos.
A polticas de gerenciamento de mudana devem definir o
processo usado para gerenciamento de mudana e a
informao que deve est associado com uma solicitao de
mudana. Devem tambm definir que responsvel por fazer o
que no processo de gerenciamento de mudana.

Pontos principais
Algum suporte automtico para gerenciamento de mudana
deve ser provido. Isto pode ser atravs de ferramentas
especializados de gerenciamento de requisitos ou pela
configurao de ferramentas existentes para suportar o
gerenciamento de mudana.
A informao de rastreamento guarda as dependncias entre
requisitos e as fontes desses requisitos, dependncias entre
requisitos e dependncias entre requisitos e a implementao
do sistema.

Pontos principais
Matrizes de rastreamento so usadas para registrar a
informao de rastreamento.
A coleta e manuteno de informao de
rastreamento caro. Para ajudar a controlar estes
custos, as empresas deve definir um conjunto de
polticas de rastreamento que definem qual a
informao a ser coletada e como ela ser mantida.