Análise de requisitos

Análise de requisitos

1. Abordagem sistemáticas para formulação, análise, documentação e manutenção de requisitos de um sistema

2. Definições de requisitos

   • Condição, característica ou capacidade, determinada no universo das necessidades de negócio do usuário
   • Segundo a Engenharia de SW:
     • Condição que deve ser satisfeita para se alcançar um objetivo, ou a qualidade que deve ser provida para ser útil a seus usuários
   • Segundo a Engenharia:
     • Propriedade ou comportamento que um produto ou serviço deve atender
   • Segundo o RUP:
     • Condição ou capacidade com a qual o sistema deve estar de acordo

3. Classificações

   • Quanto ao nível de abstração
     • Requisitos de usuário
       • Descrições de quais serviços o sistema deve fornecer e as restrições sob as quais deve operar
       • Possuem alto nível de abstração e poucos detalhes
       • Feitos para serem lidos por pessoas LEIGAS
       • Podem ser FUNCIONAIS ou NÃO-FUNCIONAIS
       • Exemplo: O software deve fornecer um meio de representar e acessar arquivos externos criados por outras ferramentas
     • Requisitos de sistema
       • Descrições DETALHADAS sobre as funções, operações e restrições de sistema que definem EXATAMENTE o que deve ser implementado
       • Possuem baixo nível de abstração e muitos detalhes
       • Feitos para serem lidos or pessoas EXPERIENTES
       • Podem ser FUNCIONAIS ou NÃO-FUNCIONAIS
       • Exemplo: O usuário deve dispor de tecnologia assistiva para acessar banco de dados externos
   • Quanto à qualidade
     • Normais
       • Requisitos que visam a satisfação do cliente
     • Esperados
       • São requisitos quase sempre IMPLÍCITOS, não declarados explicitamente pelo cliente, mas fundamentais para sua satisfação
     • Fascinantes
       • Vão além das expectativas do cliente
   • Quanto à evolução e manutenção
     • Permanentes
       • Estão diretamente ligados à atividade principal da organização
       • Em geral, são derivados do Modelo de Domínio
     • Voláteis
       • Mutáveis
         • Se modificam em função de mudanças no AMBIENTE no qual o sistema opera
         • Exemplo: Alterações legais que impactam no sistema
       • Emergentes
         • Não podem ser definidos na especificação do sistema e "emergem" à medida em que a compreensão do sistema se desenvolve
       • Consequentes
         • São percebidos quando o usuário utiliza o sistema (consequência do uso)
       • Compatibilidade
         • São requisitos que dependem de outro equipamento, processo, componente ou elemento
         • Caso o item de dependência mude, o requisito também mudará
   • Quanto à funcionalidade
     • Funcionais
       • São declarações dos serviços que um sistema DEVE FORNECER
       • Problemas
         • Falta de precisão
         • Ambiguidade
         • Requisitos incompletos
         • Inconsistência
       • Exemplos
         • Fornecer opção de filtrar e-mails por "assunto" e "anexos" (Outlook)
         • Reagir com suspensão de vídeos que ferem direitos autorais (Youtube)
         • Procurar a rua mais próxima, caso não encontre a desejada (Google Maps)
     • Não-funcionais
       • São RESTRIÇÕES nos serviços ou funções fornecidas pelo sistema
       • Problemas
         • Difíceis de especificar objetivamente
         • Conflitos entre requisitos não-funcionais
       • Subclassificações
         • De produto
           • Especificam o comportamento do produto
         • Organizacionais
           • São derivados de procedimentos da organização do cliente e do desenvolvedor
         • Externos
           • São derivados de fatores externos ao sistema e seu processo de desenvolvimento
       • Exemplos
         • Fornecer disponibilidade mínima de 99,8%
         • Deve ser desenvolvido na linguagem Java
         • Deve ser capa de rodar com apenas 1Gb de memória RAM
     • De domínio
       • Derivam do domínio da aplicação e refletem características de sua área de negócio
       • Podem ser FUNCIONAIS ou NÃO-FUNCIONAIS
       • Problemas
         • Podem ser omitidos por especialistas na área por entenderem que as informações são óbvias demais ou estão subentendidas
       • Exemplos
         • O sistema deverá calcular a nota final da prova de mestrado pela fórmula (1,74N1 + 2,17N2 + 2,59N3) / 3 * IRA
         • O sistema deverá calcular o valor do Título Público NTN-B multiplicado pelo valor da Taxa Selic do mês correspondente
         • O sistema deverá funcionar com uma câmera 4K capturando infravermelho e resistente à variações de temperatura

4. Fases

   • Segundo Pressman
     • Concepção
     • Levantamento
     • Elaboração
     • Negociação
     • Especificação
     • Validação
     • Gestão
   • Segundo Sommerville
     • Estudo de viabilidade
       • Decide se o sistema é viável ou não
       • Produz o RELATÓRIO DE VIABILIDADE
       • Para ser viável, 3 perguntas devem ser respondidas com "sim"
         • O sistema contribui para os objetivos gerais da organização?
         • O sistema pode ser implementado com tecnologia atual e dentro do custo e prazo?
         • O sistema pode ser integrado a outros sistemas já implantados?
     • Elicitação e análise de requisitos
       • É o processo de levantamento e derivação de requisitos do sistema
       • Produz MODELOS DE SISTEMA
       • Atividades
         • Obtenção de requisitos
           • Interação com os stakeholders para coletar requisitos
         • Classificação e organização de requisitos
           • Agrupa requisitos relacionados e os organiza em conjuntos coerentes
         • Priorização e negociação dos requisitos
           • Prioriza os requisitos e resolve conflitos por meio da negociação
         • Documentação de requisitos
           • Os requisitos são documentados, podendo ser separados em FORMAIS ou INFORMAIS
       • Técnicas
         • Entrevistas
           • Os stakeholders são entrevistados para que se levante informações sobre suas necessidades
         • Etnografia
           • O analisa é colocado no ambiente do usuário para observar o modo de trabalho
         • Cenários
           • É descrito um cenário de uso do sistema para que se levante detalhes da utilização
         • Brainstorming
           • Busca explorar a potencialidade criativa numa reunião onde é bem-vinda qualquer ideia
         • Prototipação
           • Os stakeholders visualizam um esboço da aplicação, facilitando a comunicação e identificando necessidades reais de uso
         • Histórias de usuário
           • Descrição no formato "Como um <papel>, eu quero <meta> de modo que <benefício>"
     • Especificação
       • Produz REQUISITOS DE USUÁRIO e DE SISTEMA
       • Traduz as informações coletadas na fase de elicitação em um documento que define o conjunto de requisitos
     • Validação
       • Procura erros no documento de requisitos, além de garantir que os requisitos definem realmente o que o usuário deseja no sistema
       • Produz o DOCUMENTO DE REQUISITOS
       • Técnicas
         • Revisão dos requisitos
         • Prototipação
         • Geração de casos de teste
       • Verificações
         • Validade
         • Consistência
         • Completeza
         • Realismo
         • Facilidade de verificação
     • Gestão
       • Gerencia os requisitos durante o desenvolvimento e uso do sistema
       • Deve permitir a rastreabilidade dos impactos nos requisitos
       • Indicado somente para projetos grandes, com centenas ou mais de requisitos

Imagens e arquivos do mapa