Engenharia de Requisitos

Engenharia de Requisitos

1. Requisitos

   • de USUARIO
     • descriçao em linguarem natural e com diagramas com ALTO NIVEL DE ABSTRAÇAO e poucos detalhes. para serem lidos por pessoas leitas
   • de SISTEMA
     • descriçoes DETALHADAS com baixo nivel da abstraçao que definem o que deve ser IMPLEMENTADO
   • class. qto a QUALIDADE
     • Normais
     • Esperados
       • Requisitos IMPLICITOS tais como interface intuitiva, velocidade de busca e facilidade de instaçao detre outros
     • Fascinantes
       • Recursos que vao alem da expectativa do cliente
   • class. qto a EVOLUÇÃO
     • Permanentes
       • tambem chamados de ESTAVEIS sao requisitos que fazem parte do DOMINIO PRINCIPAL DA EMPRESa
     • Volateis
       • Se modificam quando o sisttema esta em uso ou em desenvolvimento
       • Mutaveis
         • muda pq o enviroment muda, adaptaçao a leis e etc
       • Emergentes
         • muda no desenvolvimento quando o entendimento do produto melhora
       • Consequentes
         • o cliente percebe novas necessidades conforme vai usando o software
       • Compatibilidade
         • muda para se adequar a mudanças em outras partes do software
   • Class. qto a FUNCIONALIDADE
     • Funcionais
       • O QUE o sistema deve fazer
     • N~ao Funcionais
       • COMO O SISTEMA DEVE FAZER, sao restriçoes ou condiçoes estipuladas sobre as quais o sistema deve funcionar
       • ARQUITETURA TECNICA DO SISTEMA
       • CONFIABILIDADE, SEGURANÇA, USABILIDADE, PERFORMANCE, CUSTOS ROBUSTEZ
       • de produto
         • especificam o comportamento do produto. Entre os exemplos, estão requisitos de desempenho quanto à rapidez com que o sistema deve operar e quanto de memória ele requer, requisitos de confiabilidade que definem a taxa aceitável de falhas, requisitos de portabilidade e requisitos de usabilidade.
         • de confiabilidade
           • O sistema não deve ficar fora do ar por mais de cinco segundos durante o dia.
         • de proteçao
           • O sistema não deve permitir que os usuários modifiquem senhas de acesso que eles não criaram
         • de Eficiencia
           • Desempenho
             • O sistema deverá ser capaz de processar oitocentas requisições por segundo.
           • Armazenamento
         • usabilidade
           • Os usuários deverão operar todas as funcionalidades do sistema após 2 horas de treino.
       • organizacionais
         • são derivados de políticas e procedimentos da organização do cliente e do desenvolvedor. Entre os exemplos, estão padrões de processo que devem ser usados, linguagem de programação ou o método de projeto usado, e requisitos de entrega que especificam quando o produto e a sua documentação devem ser entregues.
         • ambientais
         • Operacionais
         • Implementaçao
       • externos
         • abrange todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Entre os exemplos, estão a interoperabilidade que define como o sistema interage com outros sistemas, requisitos legais que devem ser seguidos, requisitos éticos sistema para assegurar que ele será aceito por todos
         • Regulatorio
         • Legais
         • Eticos
     • Dominio
       • são requisitos derivados do domínio da aplicação e refletem características de sua área de negócio. Eles podem ser requisitos funcionais ou não-funcionais

2. Pressman

   • 1. Concepçao
   • 2. Levantamento
   • 3. Elaboraçao
   • 4. Negociaçao
   • 5. Especificaçao
   • 6. Validaçao
   • 7. Gestao

3. SOMMERVILLE

   • Estudo de viabilidade
     • A fase de Estudo de Viabilidade trata da realização de uma avaliação relativamente rápida e barata para verificar se as necessidades identificadas dos usuários podem ser satisfeitas por meio das tecnologias atuais de sistemas de software e hardware.
   • Elicitaçao e analise de requisitos
     • trata do processo de levantamento e derivação de requisitos de sistema através da observação de sistemas existentes, discussões com usuários e compradores potenciais, análise de tarefas, entre outros
     • Obtençao de Requisitos
       • processo de interação com os stakeholders para coletar requisitos. Os requisitos de domínio também são descobertos durante essa atividade.
     • Classificaçao e organizaçao
       • esta atividade envolve a coleção de requisitos não estruturados, agrupa os requisitos relacionados e os organiza em conjuntos coerentes.
     • Priorizaçao e negociaçao
       • inevitavelmente, os requisitos serão conflitantes. Assim, busca-se priorizar os requisitos e resolver conflitos por meio da negociação. d.
     • Documentaçao de req
       • os requisitos são documentados e colocados na próxima volta da espiral. Podem ser produzidos documentos de requisitos formais ou informais.
   • Especificaçao
     • objetivo aqui é criar uma documentação que sirva como um contrato entre as partes.
     • essa documentação deve servir tanto para engenheiros de requisitos quanto para os clientes. Esse documento contém requisitos de usuário e requisitos de sistema, logo ambas as partes podem consultá-lo de maneira sistemática para verificar o que foi levantado, a análise de viabilidade, os requisitos mais abstratos, os requisitos mais técnicos, o que foi acordado entre as partes, entre outros
   • Validaçao
     • A atividade de Validação de Requisitos é responsável por verificar os requisitos em relação ao realismo, consistência, abrangência, validade, completude, etc. Durante esse processo, erros no documento de requisitos são inevitavelmente descobertos.
     • Este estágio é focado no cliente e está relacionado à descoberta de problemas com requisitos.
     • Técnicas de Validaçao de requsitos
       • Revisao de requisitos
       • Prototipaçao
         • Um modelo executável do sistema é apresentado para usuários finais e clientes. Eles podem experimentar o modelo para verificar se atende às suas necessidades reais. Também há desvantagens: o tempo gasto na sua implementação pode não justificar o seu uso, pode enviesar os usuários e pode ainda levar os programadores a cair na tentação de usar o protótipo para continuar o desenvolvimento do sistema.
       • Geraçao de casos testes
         • É importante destacar que os requisitos devem ser testáveis. Se os testes dos requisitos forem criados como parte do processo de validação, eles frequentemente revelarão problemas de requisitos
   • Teste

4. Técnicas de OBTENÇAO /LEVANTAMENTO DE REQUISITOS

   • Entrevistas
     • Nessas entrevistas, a equipe de engenharia de requisitos formula questões para os stakeholders sobre o sistema que eles usam e o sistema a ser desenvolvido. Os requisitos são derivados a partir das respostas dessas questões.
     • Abertas
       • não há um roteiro predefinido
     • Fechadas
       • com um roteiro definido
   • Etnografia
     • Coloca-se o analista dentro do campo de atuação dos usuários, observando o trabalho diário anotando as tarefas reais em que os participantes estão envolvidos
   • Cenarios
     • Elas podem compreender e criticar um cenário de como interagiriam com um sistema de software
     • O uso de cenários para descrever requisitos é parte integrante dos métodos ágeis, como a Extreme Programming. 
   • Questionarios
     • Formulários distribuídos aos stakeholders com questões pré-definidas. Torna-se útil quando a quantidade de stakeholders é muito grande.
   • Workshop de Requisitos
     • Reunião estruturada e intensiva entre analistas e usuários com o intuito de obter um conjunto de requisitos bem definidos. Possui um facilitador neutro responsável pelas atividades de logística e promoção de momentos de descontração, como forma de dinamizar o trabalho em equipe. Permite utilizar outras técnicas em conjunto como brainstorming ou interpretação de papéis.
   • Brainstorming
     • durante cerca de 15 minutos em que toda a ideia deve ser levada em consideração, sendo proibida a crítica a qualquer sugestão dada, e encorajada, inclusive, a criação de ideias que pareçam estranhas ou exóticas. Busca-se explorar a potencialidade criativa de um grupo – um facilitador organiza e prioriza os resultados.
   • Leitura de documentos
   • JAD (joint Appication Design)
     • Similar à técnica de workshop de requisitos e registrada pela IBM, ela busca reunir os usuários e desenvolvedores em um workshop estruturado para levantar requisitos e promover a tomada de decisões por meio de diversos tipos de dinâmicas de grupo, técnicas visuais, processos racionais e até documentação. É bastante interativa e promove a participação ativa dos envolvidos – inclusive dos tímidos.
     • O processo consiste em três fases principais: customização, sessões e agrupamento. Na customização, o analista prepara as tarefas para as sessões como organizar os times, preparar o material, entre outros. Na fase de sessões, o analista marca uma ou mais reuniões com os stakeholders. No início da sessão, o engenheiro de requisitos provê uma visão genérica sobre o sistema. A discussão com os stakeholders continua até o fim do levantamento de requisitos. Na fase de agrupamento todos os requisitos levantados nas fases anteriores são convertidos em documentos de especificação de requisitos
   • Prototipaçao
     • Técnica de elicitação, independente de tecnologia, utilizada no estágio inicial do projeto, ajudando stakeholders a desenvolverem uma forte noção sobre a aplicação a ser implementada. Por meio da visualização de um esboço da aplicação, podem-se identificar requisitos reais e fluxos de trabalho do sistema. São frequentemente utilizadas quando os usuários são incapazes de expressar suas necessidades.
     • Horizontal
       •  Um protótipo que apresenta uma visão superficial e possivelmente abrangente da funcionalidade do sistema, mas que geralmente não suporta nenhum uso ou interação de fato
     • Vertical
       • Um protótipo que mergulha nos detalhes da interface, da funcionalidade ou de ambos
     • evolutiva
       • sofrerá constante evolução até se tornar o produto final
     • descartavel
       • (mais comum), será descartada após cumprir seus objetivos, feitos c/ ferramentas específicas.
   • Reuso de Requisitos
     • O reuso de requisitos trata do estudo e reutilização de especificações e glossários referentes a projetos de sistemas legados ou sistemas de mesma família ou com funcionalidades de negócio similares. Estudos mostram que sistemas similares podem reutilizar mais de 80% de seus requisitos. Dessa forma, eles têm chances maiores de serem compreendidos pelos stakeholders – o que é uma excelente vantagem.
   • Historias de usuarios
     • Introduzida inicialmente pela Metodologia XP (Extreme Programming), nada mais é do que uma história contada na linguagem do usuário final, que deve ser capaz de capturar aquilo que o usuário de fato necessita fazer para realizar seu trabalho. Deve ser concisa o suficiente para caber em um post-it. Um padrão seria: “Como um <papel>, eu quero <meta> de modo que <benefício>”.
   • Participaçao ativa de usuarios
     • A técnica de participação ativa de usuários permite a incorporação dos usuários e clientes ao grupo de engenharia de requisitos. Os usuários precisam aprender as linguagens de modelagem utilizadas para ser capaz de ler as descrições e criticá-las. Permite uma interação real entre clientes e usuários, no entanto necessita de um certo treinamento aos usuários participantes.
   • Encenaçao
     • Um facilitador mostra uma encenação para o grupo e este último faz comentários. Ajuda a restringir requisitos, estimula soluções mais criativas e a revisão em equipe, facilita o processo de entrevista, entre outros.
   • Interpretaçao de papeis
     • A técnica de interpretação de papeis é uma abordagem que atribui a cada membro do grupo um papel de interesse para o sistema. O grupo inspecionará então como o sistema é usado. Ao longo do caminho, haverá discussões sobre quem é responsável por o quê. O Analista de Sistemas interpreta o papel do usuário, o que o ajuda a obter um discernimento real do domínio do problema.
   • Grupo focal
     • A técnica de grupo focal trata de um grupo de discussão informal e de tamanho reduzido (geralmente até 12 pessoas), com o propósito de obter informação qualitativa em profundidade. As pessoas são convidadas para participar da discussão sobre determinado assunto.
   • Analise de protocolos
     • Essa técnica consiste em analisar o trabalho de determinada pessoa por meio de verbalização, estabelecendo a racionalidade utilizada na execução de tarefas.
   • Pontos de vista
     • A técnica de pontos de vista (também chamada de VORD) considera as perspectivas de diversas partes interessadas sobre os requisitos do sistema de software

5. GERENCIAMENTO DE REQUISITOS

   • esse é o processo responsável por compreender, acompanhar e controlar as mudanças dos requisitos de sistema, identificando inconsistências
   • O processo de gerenciamento de requisitos deve se iniciar assim que uma versão inicial do documento de requisitos esteja disponível.
   • CONTROLE DE MUDANÇAS
     • mATRIZ DE RASTREABILIDADE
       • Matriz de rastreabilidade de requisitos é uma ferramenta que explicita a relação direta dos requisitos entre si ou com os outros componentes do projeto. Assim, caso alguma alteração seja feita no projeto, sabe-se quais requisitos serão afetados com tal mudança.
   • RASTREABILIDADE
   • PRIORIZAÇAO

Bilder und Dateien der Mindmap