07 Processo Eng Requisitos 6x1

4/14/11
1
Ian Sommerville 2006 Engenharia de Software, 8. edio. Captulo 7 Slide 1
2007 by Pearson Education
Processos de Engenharia de
Requisitos
Processos de engenharia de
requisitos
!Os requisitos e as formas de obt-los e document-
los variam drasticamente de um projeto para o outro
!Contudo, existe uma srie de atividades genricas
comuns a todos os processos
! Elicitao de requisitos;
! Anlise de requisitos;
! Validao de requisitos;
! Gerenciamento de requisitos.
Engenharia de requisitos
Elicitao e anlise
!Envolve pessoal tcnico trabalhando com os clientes para
descobrir sobre o domnio da aplicao, os servios que o
sistema deve fornecer e sobre as restries operacionais.
!Pode envolver
! Usurios finais
! Gerentes
! Engenheiros envolvidos na manuteno
! especialistas de domnio
! representantes de sindicato, etc.
!Estes so chamandos stakeholders (partes interessadas)!
Problemas de anlise de requisitos
!Stakeholders no sabem o que eles realmente querem.
!Stakeholders expressam requisitos em seus prprios
termos.
!Diferentes stakeholders podem ter requisitos conflitantes.
!Fatores organizacionais e polticos podem influenciar os
requisitos de sistema.
!Mudanas de requisitos durante o processo de anlise
A espiral de requisitos
4/14/11
2
Atividades de processo
!Identificao (ou Elicitao) de requisitos
! Interao com os stakeholders para coletar seus requisitos. Os
requisitos de domnio so tambm descobertos neste estgio.
!Anlise e Negociao de requisitos
! Agrupa requisitos relacionados e organiza-os em conjuntos
coerentes.
! Priorizao de requisitos e resoluo de conflitos de requisitos.
!Documentao de requisitos
! Os requisitos so documentados e colocados na prxima volta da
espiral.
Identificao de requisitos
!Processo de reunir informaes sobre os sistemas
propostos e existentes
! Obter requisitos de usurio e de sistema a partir dessas
informaes.
!As fontes de informao incluem documentao,
stakeholders e as especificaes de sistemas similares.
!Prottipos tambm podem ser usados tanto para
descobrir quanto para validar requisitos
Stakeholders de caixa eletrnico
!Clientes do banco
!Representantes de outros bancos
!Gerentes de bancos
!Caixas do banco
!Administradores de banco de dados
!Gerentes de proteo (segurana das informaes)!
!Departamento de marketing
!Engenheiros de manuteno de hardware e de software
!Reguladores de banco
Pontos de vista
!Maneira de estruturar os requisitos para
representar as perspectivas de stakeholders
diferentes.
! Stakeholders podem ser classificados em diferentes
pontos de vista.
!Essa anlise de mltiplas perspectivas
importante, pois no h uma maneira nica de
analisar os requisitos
Tipos de pontos de vista
!Pontos de vista de interao so pessoas ou sistemas que
interagem diretamente com o sistema.
! Clientes e o banco de dados de contas so pontos de vista de
interao.
!Pontos de vista indiretos so os stakeholders que no usam o
sistema diretamente, mas afetam os requisitos.
! Gerncia, caixas do banco e pessoal de proteo so pontos de
vista indiretos.
!Pontos de vista de domnio so as caractersticas e restries
de domnio que influenciam os requisitos.
! Padres para comunicaes entre bancos representam pontos de
vista de domnio
Identificao de pontos de vista
!Identificar pontos de vista usando:
! Fornecedores e receptores de servios do sistema;
! Sistemas que devem interfacear diretamente com o
sistema que est sendo especificado;
! Regulamentos e padres;
! Fontes de requisitos de negcio e de requisitos no
funcionais;
! Engenheiros que tm de desenvolver e manter o sistema;
! Marketing e outros pontos de vista de negcio.
4/14/11
3
Hierarquia de pontos de vista do
LIBSYS
Entrevistas
!Em entrevista formal ou informal, a equipe de RE
formula questes para os stakeholders sobre os
sistemas que eles usam e o sistema a ser
desenvolvido.
!Existem dois tipos de entrevistas
! Entrevistas fechadas, onde um conjunto de
questes predefinidas so respondidas.
! Entrevistas abertas, onde no h um roteiro
predefinido e onde uma variedade de assuntos so
explorados com os stakeholders.
Entrevistas na prtica
!Normalmente, uma mistura de entrevistas fechadas e
abertas
!Entrevistas so boas para obteno de um entendimento
geral do que os stakeholders fazem e como eles podem
interagir com o sistema.
!Entrevistas no so ideais para a compreenso de
requisitos de domnio
! Os engenheiros de requisitos podem no entender a
terminologia especfica de domnio;
! Alguns conhecimentos de domnio so to especificos
que as pessoas acham difcil explicar ou pensam que
no vale a pena mencion-los
Cenrios
!Cenrios so simulaes de como um sistema poder
ser usado
!Eles devem incluir
! Uma descrio da situao inicial;
! Uma descrio do fluxo normal de eventos;
! Uma descrio do que pode dar errado;
! Informao sobre outras atividades concorrentes;
! Uma descrio do estado quando o cenrio termina.
!Para sistemas interativos, cenrios funcionam bem em
combinao com prottipos da GUI
Cenrio do LIBSYS
Casos de uso
!Os casos de uso constituem uma tcnica baseada em
cenrios que identificam os agentes em uma interao e
descrevem a interao em si.
! Apoiados pela UML
! Diagramas de casos de uso so usados para definir o escopo
! Especificaes de casos de uso so cenrios como o descrito
anteriormente
!Um conjunto de casos de uso deve descrever todas as
possveis interaes com o sistema.
4/14/11
4
Alguns casos de uso do LIBSYS
Fatores sociais e organizacionais
!Sistemas de software so usados em um contexto
social e organizacional. Isso pode influenciar, ou
mesmo dominar os requisitos de sistema.
!Fatores sociais e organizacionais no so um ponto
de vista nico, mas so influncias sobre todos os
pontos de vista.
! muito difcil saber se uma anlise de fatores
sociais e organizacionais est correta!
Etnografia
!Um analista despende um tempo considervel observando e
analisando como as pessoas realmente trabalham.
!As pessoas no tm de explicar seu trabalho.
!Fatores sociais e organizacionais de importncia podem ser
observados.
!Estudos de etnografia tm mostrado que o trabalho ,
geralmente, mais rico e mais complexo do que o sugerido
pelos modelos simples de sistema.
Escopo da etnografia
!So requisitos originados a partir do modo como as
pessoas realmente trabalham
! Independem de como definies de processo
sugerem que elas devam trabalhar.
!So requisitos originados a partir da cooperao e da
conscientizao das atividades de outras pessoas.
Mais Etnografia
!Etnografia funciona bem quando combinada com
prototipao
! O estudo etnogrfico fornece feedback rpido sobre a
aceitao e possveis melhorias para um prottipo
!O desenvolvimento de prottipo resulta em questes
no respondidas que tornam a anlise etnogrfica mais
focada
!O problema com a etnografia que ela estuda prticas
existentes que podem ter alguma base histrica que
no mais relevante.
! No to eficiente para descobrir requisitos novos
Validao de requisitos
!Dedica-se a mostrar que os requisitos definem o
sistema que o cliente realmente deseja.
!Custos de erros de requisitos so altos e, desse
modo, a validao muito importante
! O custo da reparao de um erro de requisitos depois da
entrega pode equivaler a muitas vezes o custo de
reparao de um erro de implementao
4/14/11
5
Verificao de requisitos
!Verificao de validade. O sistema fornece as funes que
melhor apiam as necessidades do cliente?
!Verificao de consistncia. Existe algum tipo de conflito de
requisitos? Para um mesmo requisito no pode haver
contradio
!Verificao de completude. Todas as funes requisitadas pelo
cliente foram includas?
!Verificao de exequibilidade. Os requisitos podem ser
implementados com o oramento e a tecnologia disponveis?
!Facilidade de verificao. Os requisitos podem ser verificados?
Usar conjunto de testes para demonstrar que a funcionalidade
entregue atende o requisito
Tcnicas de validao de requisitos
!Revises de requisitos
! Anlise manual sistemtica dos requisitos.
! Potencialmente acompanhada por stakeholders
!Prototipao
! Uso de um modelo executvel do sistema para verificar
requisitos
!Gerao de casos de teste.
! Desenvolvimento de testes para requisitos a fim de
verificar a testabilidade
! Testes de aceitao
Revises de requisitos
!Revises regulares devem ser feitas enquanto a
definio de requisitos est sendo formulada.
!Ambos, cliente e fornecedor, devem ser envolvidos
nas revises.
!Revises podem ser formais (com documentos
completos) ou informais. Uma boa comunicao entre
desenvolvedores, clientes e usurios podem resolver
problemas nos estgios iniciais.
Reviso de requisitos
!Facilidade de verificao. O requisito
realisticamente testvel?
!Facilidade de compreenso. O requisito
adequademente compreendido?
!Rastreabilidade. A origem do requisito claramente
estabelecida?
!Adaptabilidade. O requisito pode ser mudado sem um
grande impacto em outros requisitos
Gerenciamento de requisitos
!Gerenciamento de requisitos um processo para
compreender e controlar as mudanas de requisitos
!Requisitos so, inevitavelmente, incompletos e
inconsistentes
! Novos requisitos surgem durante o processo inteiro
! Os diferentes pontos de vista tm requisitos diferentes e
estes so freqentemente contraditrios.
Mudanas de requisitos
!Diferentes stakeholders atribuem diferentes
prioridades para os mesmos requisitos
!Os clientes do sistema podem especificar os
requisitos a partir de uma perspectiva de negcio
que conflita com os requisitos do usurio final.
!Os ambientes tcnico e de negcio do sistema
mudam durante seu desenvolvimento
! E frequentemente tm requisitos diferentes
4/14/11
6
Requisitos permanentes e volteis
! Requisitos permanentes. So requisitos estveis,
derivados da atividade central da organizao do cliente.
Por exemplo, um hospital ter sempre mdicos,
enfermeiros, etc. Podem ser derivados dos modelos de
domnio.
! Requisitos volteis. So requisitos que mudam durante o
desenvolvimento, ou quando o sistema estiver em
operao. Um exemplo seria, em um hospital, os
requisitos derivados da poltica de sade.
Classificao de requisitos volteis
Rastreabilidade
!A rastreabilidade tem a ver com relacionamentos entre os
requisitos, suas fontes e o projeto do sistema
! necessrio manter essa informao registrada nos locais
apropriados
!Rastreabilidade da fonte
! Ligam requisitos aos stakeholders que os propuseram ou aos
elementos externos que o criaram;
!Rastreabilidade de requisitos
! a ligao dos requisitos dependentes;
!Rastreabilidade de projeto
! Ligaes entre os requisitos e os mdulos de projeto.
Gerenciamento de mudanas de requisitos
!Deve ser aplicado a todas as mudanas propostas aos requisitos
! Especialmente importante para sistemas j prontos ou em estgios
avanados de desenvolvimento
!Estgios principais
! Anlise de problema: discutir problemas e mudanas de requisitos;
! Anlise de mudana e estimativa de custo: avaliar os efeitos das
mudanas sobre outros requisitos;
! Implementao de mudana: Modificar vrios artefatos para refletir
as mudanas.
!O impacto da mudana tem que ser avaliado para TODO O
SISTEMA!

07 Processo Eng Requisitos 6x1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

07 Processo Eng Requisitos 6x1

Uploaded by

Copyright:

Available Formats

4/14/11

You might also like