Levantamento de requisitos e o processo de desenvolvimento de software iterativo Leandro Ramos
Onde estamos? <ul><li>Outsourcing </li></ul><ul><li>Mão de obra especializada </li></ul><ul><ul><li>Carência de profission...
Objetivo <ul><li>construir  um software que  realmente  atenda às necessidades do usuário; </li></ul><ul><li>Fazer isso de...
O processo iterativo <ul><li>Deixa o usuário no controle do desenvolvimento </li></ul><ul><ul><li>Ele define quais funcion...
UCs no processo iterativo <ul><li>Em um processo de software que seja dirigido por UC, ele passa a servir de base para tod...
Fazer a coisa certa, fazer certo a coisa, iterativamente <ul><li>Fazer a coisa certa: </li></ul><ul><ul><li>definir o sist...
Especificar requisitos e mostrar o resultado <ul><li>No Processo Unificado, apenas 10% dos requisitos são investigados na ...
Provocar mudan ças no começo <ul><li>Especificar </li></ul>Analisar Projetar Testar Implementar e validar <ul><li>Receber ...
Provocar mudan ças no começo <ul><li>implementar, testar e validar PROVOCA a mudança logo no começo, isso facilia ajustar ...
Meta <ul><li>acolher as modificações para satisfazer o cliente </li></ul><ul><li>refina o entendimento das iterações futur...
O que mais um UC pode fazer? <ul><li>Captura  o que o sistema deve fazer do ponto de vista do usuário </li></ul><ul><li>Un...
Atividade de levantamento de requisitos A responsabilidade inicial de um Analista de Requisitos é levantar, analisar, docu...
Definir as necessidades de negócio Identificar os interessados e tipos de usuários Listar os requisitos Analisar os requis...
Definir as necessidades de negócio Identificar os interessados e tipos de usuários Listar os requisitos Analisar os requis...
Desenvolver iterativamente, sempre! Revista Visão Ágil -
Próximos SlideShares
Carregando em…5
×

Requisitos no Processo Iterativo

385 visualizações

Publicada em

Publicada em: Educação, Tecnologia, Negócios
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
385
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
1
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Requisitos no Processo Iterativo

  1. 1. Levantamento de requisitos e o processo de desenvolvimento de software iterativo Leandro Ramos
  2. 2. Onde estamos? <ul><li>Outsourcing </li></ul><ul><li>Mão de obra especializada </li></ul><ul><ul><li>Carência de profissionais com domínio no negócio; </li></ul></ul><ul><ul><li>Grande número de profissionais com domínio da tecnologia; </li></ul></ul><ul><li>Precisamos fazer quem sabe o que deve ser feito dar as diretrizes </li></ul>
  3. 3. Objetivo <ul><li>construir um software que realmente atenda às necessidades do usuário; </li></ul><ul><li>Fazer isso de maneira fluida, processual e repetível </li></ul><ul><ul><li>Garantir que pessoas com pouco conhecimento no processo possam participar sem maiores dificuldades </li></ul></ul><ul><li>Passar o controle do projeto para as mãos de quem realmente sabe o que deve ser feito: o cliente </li></ul>
  4. 4. O processo iterativo <ul><li>Deixa o usuário no controle do desenvolvimento </li></ul><ul><ul><li>Ele define quais funcionalidades são importantes, quais serão implementadas e quais serão deixadas de lado </li></ul></ul><ul><li>Garante entregas curtas </li></ul><ul><ul><li>O usuário pode parar de “sonhar” com o software a passar a homologar pequenas funcionalidades </li></ul></ul><ul><li>É totalmente centrado nos requisitos (UCs) </li></ul><ul><li>NOTA </li></ul><ul><li>Requisitos x UCs </li></ul><ul><ul><li>UC são requisitos; </li></ul></ul><ul><ul><li>Levantar requisitos é encontrar UCs; </li></ul></ul><ul><ul><li>Escrever UCs é levantar requisitos. </li></ul></ul>
  5. 5. UCs no processo iterativo <ul><li>Em um processo de software que seja dirigido por UC, ele passa a servir de base para todo processo de desenvolvimento </li></ul>
  6. 6. Fazer a coisa certa, fazer certo a coisa, iterativamente <ul><li>Fazer a coisa certa: </li></ul><ul><ul><li>definir o sistema e o que deve ser feito. </li></ul></ul><ul><li>Fazer certo a coisa: </li></ul><ul><ul><li>transição de um foco de requisitos para um foco de projeto e implementação. </li></ul></ul><ul><li>assim a visão e especificação começam a se estabilizar com base na programação, teste e realimentação iniciais. </li></ul>
  7. 7. Especificar requisitos e mostrar o resultado <ul><li>No Processo Unificado, apenas 10% dos requisitos são investigados na concepção </li></ul><ul><li>A investigação é mais aprofundada na primeira interação da elaboração, quando a ênfase é dada ao projeto da solução </li></ul>Rational Unified Process – IBM 2003
  8. 8. Provocar mudan ças no começo <ul><li>Especificar </li></ul>Analisar Projetar Testar Implementar e validar <ul><li>Receber feed-back do usuário </li></ul><ul><li>Rever requisitos </li></ul><ul><li>Ajustar escopo </li></ul><ul><li>Ajustar cronograma </li></ul><ul><li>Ajustar custo </li></ul>} Negociação
  9. 9. Provocar mudan ças no começo <ul><li>implementar, testar e validar PROVOCA a mudança logo no começo, isso facilia ajustar e acomodar o cronograma e custo para o projeto como um todo (ajudando a modelar o escopo) </li></ul>
  10. 10. Meta <ul><li>acolher as modificações para satisfazer o cliente </li></ul><ul><li>refina o entendimento das iterações futuras </li></ul><ul><li>estima-se que 80% dos requisitos REAIS estejam estabilizados ao fim da elaboração, ao contrário da especulação do modelo cascata. </li></ul>
  11. 11. O que mais um UC pode fazer? <ul><li>Captura  o que o sistema deve fazer do ponto de vista do usuário </li></ul><ul><li>Une as exigências e atividades de projeto </li></ul><ul><li>base para a realização de caso de uso </li></ul><ul><li>nos testes, o caso de uso constitui a base para identificar casos e procedimentos de teste </li></ul><ul><li>servem de base até para os manuais de usuário (uma vez que guardam a forma do usuário interagir com o sistema) </li></ul><ul><li>em GP é usado para definir os conteúdos de iterações, estimativa de esforço </li></ul><ul><li>além disso podemos derivar story-boards </li></ul>
  12. 12. Atividade de levantamento de requisitos A responsabilidade inicial de um Analista de Requisitos é levantar, analisar, documentar e validar as necessidades dos interessados no projeto¹ ¹Karl E. Wiegers
  13. 13. Definir as necessidades de negócio Identificar os interessados e tipos de usuários Listar os requisitos Analisar os requisitos Escrever especificações Modelar os requisitos Liderar a validação Facilitar a priorização Gerenciar requisitos
  14. 14. Definir as necessidades de negócio Identificar os interessados e tipos de usuários Listar os requisitos Analisar os requisitos Escrever especificações Modelar os requisitos Liderar a validação Facilitar a priorização Gerenciar requisitos
  15. 15. Desenvolver iterativamente, sempre! Revista Visão Ágil -

×