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

Requisitos no Processo Iterativo

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